One document matched: draft-lear-ietf-sasl-openid-02.xml
<?xml version="1.0"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd"[
<!ENTITY RFC2119 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!ENTITY RFC2743 SYSTEM
"http://xml.resource.org/public/rfc/bibxml/reference.RFC.2743.xml">
<!ENTITY RFC4422 SYSTEM
"http://xml.resource.org/public/rfc/bibxml/reference.RFC.4422.xml">
<!ENTITY RFC3986 SYSTEM
"http://xml.resource.org/public/rfc/bibxml/reference.RFC.3986.xml">
<!ENTITY RFC2606 SYSTEM
"http://xml.resource.org/public/rfc/bibxml/reference.RFC.2606.xml">
<!ENTITY RFC2616 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2616.xml">
<!ENTITY RFC5246 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5246.xml">
<!ENTITY GS2 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-sasl-gs2.xml'>
]>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<?rfc toc="yes"?>
<?rfc symrefs="yes"?>
<?rfc compact="no" ?>
<?rfc sortrefs="yes" ?>
<?rfc strict="yes" ?>
<?rfc linkmailto="yes" ?>
<rfc ipr="trust200902" docName="draft-lear-ietf-sasl-openid-02" category="std">
<front>
<title abbrev="A SASL & GSS-API Mechanism for OpenID">
A SASL & GSS-API Mechanism for OpenID
</title>
<author fullname="Eliot Lear" initials="E." surname="Lear">
<organization>Cisco Systems GmbH</organization>
<address>
<postal>
<street>Richtistrasse 7</street>
<city>Wallisellen</city>
<code>CH-8304</code>
<region>ZH</region>
<country>Switzerland</country>
</postal>
<phone>+41 44 878 9200</phone>
<email>lear@cisco.com</email>
</address>
</author>
<author initials="H." surname="Tschofenig" fullname="Hannes Tschofenig">
<organization>Nokia Siemens Networks</organization>
<address>
<postal>
<street>Linnoitustie 6</street>
<city>Espoo</city>
<code>02600</code>
<country>Finland</country>
</postal>
<phone>+358 (50) 4871445</phone>
<email>Hannes.Tschofenig@gmx.net</email>
<uri>http://www.tschofenig.priv.at</uri>
</address>
</author>
<author initials="H." surname="Mauldin" fullname="Henry Mauldin">
<organization>Cisco Systems, Inc.</organization>
<address>
<postal>
<street>170 West Tasman Drive</street>
<city>San Jose</city>
<region>CA</region>
<code>95134</code>
<country>USA</country>
</postal>
<phone>+1 (800) 553-6387</phone>
<email>hmauldin@cisco.com</email>
</address>
</author>
<author initials="S." surname="Josefsson" fullname="Simon Josefsson">
<organization>SJD AB</organization>
<address>
<postal>
<street>Hagagatan 24</street>
<city>Stockholm</city>
<code>113 47</code>
<country>SE</country>
</postal>
<email>simon@josefsson.org</email>
<uri>http://josefsson.org/</uri>
</address>
</author>
<date year="2010"/>
<abstract>
<t>OpenID has found its usage on the Internet for Web Single Sign-On. Simple Authentication
and Security Layer (SASL) and the Generic Security Service Application Program Interface (GSS-API) are application frameworks to generalize authentication. This
memo specifies a SASL and GSS-API mechanism for OpenID that allows the integration of existing OpenID
Identity Providers with applications using SASL and GSS-API.</t>
</abstract>
</front>
<middle>
<section title="Introduction">
<t>
<xref target="OpenID">OpenID</xref> is a three-party protocol that provides a
means for a user to offer identity assertions and other attributes to a web server (Relying
Party) via the help of an identity provider. The purpose of this system is to provide a way
to verify that an end user controls an identifier.</t>
<t>
<xref target="RFC4422">Simple Authentication and Security Layer (SASL)</xref> (SASL) is used by application protocols such IMAP, POP and XMPP,
with the goal of modularizing authentication and security
layers, so that newer mechanisms can be added
as needed. This memo specifies just such a
mechanism. </t>
<t>The <xref target="RFC2743">Generic Security Service
Application Program Interface (GSS-API)</xref> provides a
framework for applications to support multiple
authentication mechanisms through a unified interface. This
document defines a pure SASL mechanism for OpenID, but it
conforms to the new bridge between SASL and the GSS-API
called <xref target="I-D.ietf-sasl-gs2">GS2</xref>. This
means that this document defines both a SASL mechanism and
a GSS-API mechanism. We want to point out that the GSS-API
interface is optional for SASL implementers, and the GSS-API
considerations can be avoided in environments that uses SASL
directly without GSS-API.
</t>
<t> As currently envisioned, this mechanism is to allow the interworking between SASL and OpenID
in order to assert identity and other attributes to relying parties. As such, while servers (as relying parties) will advertise SASL
mechanisms, clients will select the OpenID mechanism. </t>
<t>The OpenID mechanism described in this memo aims to re-use the available OpenID
specification to a maximum extent and therefore does not establish a separate
authentication, integrity and confidentiality mechanism. It is anticipated that existing
security layers, such as Transport Layer Security (TLS), will continued to be used.</t>
<t><xref target="overview"/> describes the interworking between
OpenID and SASL. This document
requires enhancements to the Relying Party and to the Client (as the two SASL communication
end points) but no changes to the OpenID Provider (OP) are necessary. To accomplish this goal
indirect messaging required by the OpenID specification is tunneled within SASL.</t>
<t>
<figure anchor="overview" title="Interworking Architecture">
<artwork><![CDATA[
+-----------+
| |
>| Relying |
/ | Party |
// | |
// +-----------+
// ^
OpenID // +--|--+
// | O| |
/ S | p| |
// A | e| |
// S | n| |
// L | I| |
// | D| |
</ +--|--+
+------------+ v
| | +----------+
| OpenID | OpenID | |
| Provider |<--------------->| Client |
| | | |
+------------+ +----------+
]]></artwork>
</figure>
</t>
<section anchor="terminology" title="Terminology">
<t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT",
"RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in
RFC 2119 <xref target="RFC2119"/>.</t>
<t>The reader is assumed to be familiar with the terms used in the OpenID 2.0
specification.</t>
</section>
<section anchor="applicability" title="Applicability">
<t>Because this mechanism transports information that should not
be controlled by an attacker, the OpenID mechanism MUST only
be used over channels protected
by <xref target="RFC5246">TLS</xref>, and the client MUST
successfully validate the server certificate, or similar
integrity protected and authenticated channels.</t>
</section>
</section>
<section title="Applicability for non-HTTP Use Cases">
<t>OpenID was originally envisioned for HTTP/HTML based communications, and with the associated
semantic, the idea being that the user would be redirected by the Relying Party to an identity provider who
authenticates the user, and then sends identity information and other attributes (either directly or indirectly) to the
Relying Party. The identity provider in
the OpenID specifications is referred to as an OpenID Provider (OP). The actual protocol flow, as copied from the OpenID 2.0 specification, is as
follows: </t>
<t>
<list style="numbers">
<t>The end user initiates authentication by presenting a User-Supplied Identifier to the
Relying Party via their User-Agent (e.g., http://user.example.com).</t>
<t>After normalizing the User-Supplied Identifier, the Relying Party performs discovery on
it and establishes the OP Endpoint URL that the end user uses for authentication. It
should be noted that the User-Supplied Identifier may be an OP Identifier, which allows
selection of a Claimed Identifier at the OP or for the protocol to proceed without a
Claimed Identifier if something else useful is being done via an extension. </t>
<t>The Relying Party and the OP optionally establish an association -- a shared secret
established using Diffie-Hellman Key Exchange. The OP uses an association to sign
subsequent messages and the Relying Party to verify those messages; this removes the
need for subsequent direct requests to verify the signature after each authentication
request/response. </t>
<t anchor="rpr">The Relying Party redirects the end user's User-Agent to the OP with an OpenID
Authentication request. This occurs as stated in Section
10.3 of <xref target="RFC2616" />.</t>
<t>The OP authenticates the end user and establishes whether
the end user will authenticate to, and share specific
attributes with, the Relying Party. For
instance, the OP often asks the user what to do.
The manner in which the end user authenticates to their OP
and any policies surrounding such authentication is out of
scope of OpenID. </t>
<t anchor="rpr2">The OP redirects the end user's User-Agent back to the Relying Party with either an
assertion that authentication is approved or a message that authentication failed.</t>
<t>The Relying Party verifies the information received from the OP including checking the
Return URL, verifying the discovered information, checking the nonce, and verifying the
signature by using either the shared key established during the association or by
sending a direct request to the OP. </t>
</list>
</t>
<t>When considering this flow in the context of SASL, we note
that while the RP and the client both must change their code
to implement this SASL mechanism, the OP must remain
untouched. Hence, an analog flow that
interfaces the three parties needs to be created. In the
analog, we note that unlike a web server, the SASL server
already has some sort of session
(probably a TCP connection) established with the client.
However, it may be necessary to redirect a SASL client
to another application. This will be discussed below. By
doing so, we externalize much of the authentiction from SASL.
</t><t>
The steps are shown from below:</t>
<t>
<list style="numbers">
<t>The Relying Party or SASL server advertises support for
the SASL OpenID mechanism to the client. </t>
<t>The client initiates a SASL authentiation and transmits
the User-Supplied Identifier as well as an optional return_to
parameter.</t>
<t>After normalizing the User-Supplied Identifier, the Relying Party performs discovery on
it and establishes the OP Endpoint URL that the end user uses for authentication.</t>
<t>The Relying Party and the OP optionally establish an association -- a shared secret
established using Diffie-Hellman Key Exchange. The OP uses an association to sign
subsequent messages and the Relying Party to verify those messages; this removes the
need for subsequent direct requests to verify the signature after each authentication
request/response. </t>
<t>The Relying Party transmits an authentication request to the OP to obtain an assertion
in the form of an indirect request. These messages are passed through the client rather
than directly between the RP and the OP. OpenID defines two methods for indirect
communication, namely HTTP redirects and HTML form submission. Both mechanisms are not
directly applicable for usage with SASL. To ensure that a standard OpenID 2.0 capable OP
can be used a new method is defined in this document that requires the OpenID message
content to be encoded using
a <xref target="RFC3986">Universal Resource Idenitifier
(URI).</xref>
</t>
<t>The SASL client now sends an empty response, as
authentication continues via the normal OpenID flow.
</t><t>
At this point the client application MUST construct a URL containing
the content received in the previous message from the
RP. This URL is transmitted to the OP either by
the SASL client application or an appropriate handler, such
as a browser.</t>
<t>Next the client optionally authenticates to the OP and
then approves or disapproves authentication to the Relying
Party. The manner in which the end user is authenticated
to their respective OP and any
policies surrounding such authentication is out of scope of OpenID and and hence also
out of scope for this specification. This step happens
out of band from SASL.</t>
<t>The OP will convey information about the success or failure of the
authentication phase back to the RP, again using an indirect
response via the client browser or handler.
The client transmits over HTTP the redirect of the OP
result to the RP. This step happens out of band from
SASL.</t>
<t>The RP MAY send an OpenID check_authentication request
directly to the OP, if no association has been established,
and the OP should be expected to respond. Again this step
happens out of band from SASL.</t>
<t>The SASL server sends an appropriate SASL response to the
client, with optional Open Simple Registry (SREG) attributes. </t>
</list>
</t>
<t>
<figure>
<artwork><![CDATA[
SASL Serv. Client OP
|>-----(1)----->| | Advertisement
| | |
|<-----(2)-----<| | Initiation
| | |
|> - - (3) - - - - - - - - - ->| Discovery
| |
|>- - -(4)- - - - - - - - - - >| Association
|<- - -(4)- - - - - - - - - - <|
| | |
|>-----(5)----->| | Indirect Auth Request
| | |
|<-----(6)-----<| | Client Empty Response
| | |
| |>- - (7)- - ->| Client GET to the OP (ext)
| | |
| |<- - (8)- - ->| Client / OP Auth. (ext.)
| | |
|<- - -(9)- - - + - - - - - - <| HTTP(s) Indirect id_res
| | |
|<- - -(10)- - - - - - - - - ->| Optional check_authenticate
| | |
|>-----(11)---->| | SASL completion with status
----- = SASL
- - - = HTTP or SSL
]]>
</artwork></figure>
</t>
<t>Note the directionality in SASL is such that the client MUST send an
empty response. Specifically, it processes the redirect and
then awaits a final SASL decision, while the rest of the OpenID
authentication process continues.
</t>
<section title="Binding SASL to OpenID in the Relying Party" >
<t>
To ensure that a specific request is bound, and in particular to
ease interprocess communication, it may be necessary for the relying
party to encode some sort of nonce in the URIs it transmits through
the client for success or failure. This can be done in any number
of ways. Examples would include making changes to the base URI or
otherwise including an additional fragment.
</t>
</section>
<section title="Discussion">
<t>
As mentioned above OpenID is primarily designed to interact with
web-based applications. Portions of the authentication stream are
only defined in the crudest sense. That is, when one is prompted to
approve or disapprove an authentication, anything that one might find
on a browser is allowed, including JavaScript, fancy style-sheets,
etc. Because of this lack of structure, implementations will need to
invoke a fairly rich browser in order to insure that the
authentication can be completed.
</t>
<t>Once there is an outcome, the SASL server needs to know about it.
The astute will hopefully by now have noticed an empty client SASL
challenge. This is not to say that nothing is happening, but rather
that authentication flow has shifted from SASL to OpenID, and
will return when the server has an outcome to hand to the client.
The alternative to this flow is some signal from the
HTML browser to the SASL client of the results that is in turn
passed to the SASL server. The IPC issue this raises is
substantial. Better, we conclude, to externalize the authentication
to the browser, and have an empty client challenge.
</t>
</section>
</section>
<section title="OpenID SASL Mechanism Specification">
<t>Based on the previous figure, the following operations are performed with the OpenId SASL mechanism: </t>
<section title="Advertisement" anchor="advertisement">
<t> To advertise that a server supports OpenID, during application session initiation, it
displays the name "OPENID20" in the list of supported SASL mechanisms.
</t>
</section>
<section title="Initiation" anchor="initiation">
<t> A client initiates an OpenID authentication with SASL by sending the GS2 header followed by the XRI or URI, as specified in
the OpenID specification. The GS2 header carries the optional authorization identity.</t>
<figure>
<artwork><![CDATA[
initial-response = gs2-header Auth-Identifier
Auth-Identifier = Identifier ; authentication identifier
Identifier = URI | XRI ; Identifer is specified in
; Sec. 7.2 of the OpenID 2.0 spec.
]]></artwork>
</figure>
<t>The "gs2-header" is specified in
<xref target="I-D.ietf-sasl-gs2"/>, and it is used as follows.
The "gs2-nonstd-flag" MUST NOT be present. The "gs2-cb-flag"
MUST be "n" because channel binding is not supported by this
mechanism. The "gs2-authzid" carries the optional
authorization identity.</t>
<t>The XRI syntax is defined in <xref target="XRI2.0" />. URI is
specified in <xref target="RFC3986" />.
</t>
</section>
<section title="Authentication Request" anchor="request">
<t> The SASL Server sends an OpenID message that contains an
openid.mode of either "checkid_immediate" or
"checkid_setup", as specified in Section 9.1 of
the OpenID 2.0 specification.</t>
<t>The client now sends that request via an HTTP GET to the OP, as
if redirected to do so from an HTTP server.</t>
<t>The client MUST handle both user authentication to the OP
and confirmation or rejection of the authentiation of the RP.</t>
<t> After all authentication has been completed by the OP, and
after the response has been sent to the client, the client
will relay the response to the Relying Party via HTTP or SSL. </t>
</section>
<section title="Server Response" anchor="response2">
<t>The Relying Party now validates the response it received
from the client via HTTP or SSL, as specified in the OpenID specification.</t>
<t>The response by the Relying Party consists of an application specific response code indicating success or
failure of authentication. In the additional data, the
server MAY include OpenID Simple Registry (SREG) attributes
that are listed in Section 4
of <xref target="SREG1.0" />.
They are encoded as follows:
</t>
<t>
<list style="numbers">
<t>Strip "openid.sreg." from each attribute name.</t>
<t>Treat the concatentation of results as URI parameters that are
separated by an ambersand (&) and encode as one would a URI,
absent the scheme, authority, and the question mark.
</t>
</list>
</t>
<t>
</t>
<t>
For example: email=lear@example.com&fullname=Eliot%20Lear
</t>
<t>
</t>
<t>More formally:
<figure><artwork><![CDATA[
outcome_data = [ sreg_avp *( "," sreg_avp ) ]
sreg_avp = sreg_attr "=" sreg_val
sreg_attr = sreg_word
sreg_val = sreg_word
sreg_word = 1* ( unreserved / pct-encoded )
; pct-encoded from Section 2.1 of RFC 3896
; unreserved from Section 2.3 of RFC 3896
]]></artwork></figure>
</t>
<t>
If the application protocol allows, openid.error and
openid.error_code and any other useful diagnostic information SHOULD be included in
authentication failures. </t>
</section>
</section>
<section title="OpenID GSS-API Mechanism Specification">
<t>This section and its sub-sections and all normative
references of it not referenced elsewhere in this document are
INFORMATIONAL for SASL implementors, but they are NORMATIVE
for GSS-API implementors.</t>
<t>The OpenID SASL mechanism is actually also a GSS-API
mechanism. The messages are the same, but a) the GS2 header
on the client's first message and channel binding data is
excluded when OpenID is used as a GSS-API mechanism, and b)
the RFC2743 section 3.1 initial context token header is
prefixed to the client's first authentication message (context
token).</t>
<t>The GSS-API mechanism OID for OpenID is
1.3.6.1.4.1.11591.4.5.</t>
<t>OpenID security contexts always have the mutual_state flag
(GSS_C_MUTUAL_FLAG) set to TRUE. OpenID does not support
credential delegation, therefore OpenID security contexts
alway have the deleg_state flag (GSS_C_DELEG_FLAG) set to
FALSE.
</t>
<t>The OpenID mechanism does not support per-message tokens or
GSS_Pseudo_random.</t>
<section title="GSS-API Principal Name Types for OpenID">
<t>OpenID supports standard generic name syntaxes for
acceptors such as GSS_C_NT_HOSTBASED_SERVICE (see
<xref target="RFC2743" />, Section 4.1).</t>
<t>OpenID supports only a single name type for initiators:
GSS_C_NT_USER_NAME. GSS_C_NT_USER_NAME is the default name
type for OpenID.</t>
<t>OpenID name normalization is covered by the OpenID
specification, see <xref target="OpenID" /> section 7.2.</t>
<t>The query, display, and exported name syntaxes for OpenID
principal names are all the same. There are no
OpenID-specific name syntaxes -- applications should use
generic GSS-API name types such as GSS_C_NT_USER_NAME and
GSS_C_NT_HOSTBASED_SERVICE (see <xref target="RFC2743" />,
Section 4). The exported name token does, of course,
conform to <xref target="RFC2743" />, Section 3.2, but the
"NAME" part of the token should be treated as a potential
input string to the OpenID name normalization rules.</t>
<t>GSS-API name attributes may be defined in the future to
hold the normalized OpenID Identifier.</t>
</section>
</section>
<section title="Example">
<t>Suppose one has an OpenID of http://openid.example, and
wishes to authenticate his IMAP connection to mail.example
(where .example is the top level domain specified in
<xref target="RFC2606"/>). The user would input his Openid into
his mail user agent, when he configures the account. In this
case, no association is attempted between the OpenID Consumer
and the OP. The client will make use of the return_to attribute
to capture results of the authentication to be redirected to the
server. The authentication on the wire would then look
something like the following:
</t>
<figure><artwork>
<![CDATA[
(S = IMAP server; C = IMAP client)
C: < connects to IMAP port>
S: * OK
C: C1 CAPABILITY
S: * CAPABILITY IMAP4rev1 SASL-IR SORT [...] AUTH=OPENID20
S: C1 OK Capability Completed
C: C2 AUTHENTICATE OPENID biwsaHR0cDovL29wZW5pZC5leGFtcGxlLw==
[ This is the base64 encoding of "n,,http://openid.example/".
Server performs discovery on http://openid.example/ ]
S: + aHR0cDovL29wZW5pZC5leGFtcGxlL29wZW5pZC8/b3BlbmlkLm5z
PWh0dHA6Ly9zcGVjcy5vcGVuaWQubmV0L2F1dGgvMi4wJm9wZW5p
ZC5yZXR1cm5fdG89aHR0cHM6Ly9tYWlsLmV4YW1wbGUvY29uc3Vt
ZXIvMWVmODg4YyZvcGVuaWQuY2xhaW1lZF9pZD1odHRwczovL29w
ZW5pZC5leGFtcGxlLyZvcGVuaWQuaWRlbnRpdHk9aHR0cHM6Ly9v
cGVuaWQuZXhhbXBsZS8mb3BlbmlkLnJlYWxtPWltYXA6Ly9tYWls
LmV4YW1wbGUmb3BlbmlkLm1vZGU9Y2hlY2tpZF9zZXR1cA==
[ This is the base64 encoding of "http://openid.example/openid/
?openid.ns=http://specs.openid.net/auth/2.0
&openid.return_to=https://mail.example/consumer/1ef888c
&openid.claimed_id=https://openid.example/
&openid.identity=https://openid.example/
&openid.realm=imap://mail.example
&openid.mode=checkid_setup"
with line breaks and spaces added here for readibility.
]
C:
[ The client now sends the URL it received to a browser for
processing. The user logs into http://openid.example, and
agrees to authenticate imap://mail.example. A redirect is
passed back to the client browser who then connects to
https://imap.example/consumer via SSL with the results.
From an IMAP perspective, however, the client sends an empty
response, and awaits mail.example.
Server mail.example would now contact openid.example with an
openid.check_authenticate message. After that...
]
S: + ZW1haWw9bGVhckBtYWlsLmV4YW1wbGUsZnVsbG5hbWU9RWxp
b3QlMjBMZWFy
[ Here the IMAP server has returned an SREG attribute of
email=lear@mail.example,fullname=Eliot%20Lear.
Line break added in this example for clarity. ]
C:
[ In IMAP client must send a blank response to receive data
that is included in a success response. ]
S: C2 OK
]]></artwork></figure>
</section>
<section title="Security Considerations">
<t>
This section will address only security considerations associated with
the use of OpenID with SASL applications. For considerations relating
to OpenID in general, the reader is referred to the OpenID
specification and to other literature. Similarly, for general SASL
Security Considerations, the reader is referred to that specification.
</t>
<section title="Binding OpenIDs to Authorization Identities">
<t>As specified in <xref target="RFC4422" />, the server is
responsible for binding credentials to a specific authorization
identity. It is therefore necessary that either some
sort of registration process takes place to register specific
OpenIDs, or that only specific trusted OpenID Providers be allowed.
Some out of band knowledge may help this process along. For
instance, users of a particular domain may utilize a particular OP
that enforces a mapping.
</t>
</section>
<section title="RP redirected by malicious URL to take an improper action">
<t>
In the initial SASL client response a user or host can transmit a
malicious response to the RP for purposes of
taking advantage of weaknesses in the RP's OpenID implementation.
It is possible to add port numbers to the URL so that the outcome is
the RP does a port scan of the site.
The URL could send the connection to an internal host or even the
local host, which the attacker would not normally have access to. The
URL could contain a protocol other than http or https, such as file or
ftp.
</t>
<t>To mitigate this attack, implementations should carefully analyze
URLs received, eliminating any that would in some way be
privileged. A log of those sites that fail SHOULD be kept, and
limitations on queries from clients should be imposed, just as with
any other authentication attempt.
</t>
</section>
<!--
<section title="Man-in-the-middle attack">
<t>
The optional establishment of an association between the OP and the RP
uses the Diffie-Hellman key exchange. The Diffie-Hellman key exchange
is vulnerable to interception attacks. Using Diffie-Hellman without
proper authentication introduces the possibility of OP Massqurade.
</t>
<t>The appropriate mitigation is to make use of OPs that support
SSL.
</t>
</section>
-->
<!--
<section title="Phishing of the OP site">
<t>
There are two common phishing attacks.
<list style="symbols">
<t>Phished OP Page: The normal flow has the RP redirecting the user to
an OP for authentication. A malicious RP could redirect the user to
identically looking, but phished OP page with the intent to steal the
user's credentials. The appropriate mitigation is for some form of
secondary mutual authentication to take place on the OP, such as
branding, client-side authentication, or a record of legitimate site
being associated with a given identity. The latter would probably
require substantial client extensions.
</t>
<t>Realm Spoofing: A malicious RP can create an authentication request
with an openid.realm set to a trusted domain and the return_to
pointing back to itself. If the OP does not do a Realm return_to
validation, then the OP will assert to the user that they are signing
into a trusted domain. However, the user is in reality being
redirected back to the malicious RP. XXX mitigation?
</t>
</list>
</t>
</section>
-->
<section title="Session Swapping (Cross-Site Request Forgery)">
<t>
There is no defined mechanism in the OpenID protocol to bind the
OpenID session to the user's browser. An attacker may forge a
cross-site request in the log-in form, which has the user logging into
a proper RP as the attacker. The user would not recognize they are
logged into the site as the attacker, and so may reveal information at
the RP. Cross-site request forgery is a widely exploited
vulnerability at web sites. This is only concern in the context SASL
in as much as the client is not configured with the Relying Party
(e.g., SASL server) in a safe manner.
</t>
</section>
<!--
<section title="Use of DNS poisoning attack to impersonate user at RP">
<t>
If not using a secure https identifier, an attacker can use a DNS
poisoning attack to impersonate the user on some RP by tricking the RP
into thinking the attacker is hosting the user's IdP. XXX is this
solved by SSL or DNSSEC?
</t>
</section>
-->
<section title="User Privacy">
<t>
The OP is aware of each RP that a user logs into. There
is nothing in the protocol to hide this information from the OP. It
is not a requirement to track the visits, but there is nothing that
prohibits the collection of information. SASL servers should be aware
that OpenID Providers will be track - to some extent - user access to
their services and any additional information that OP provides.
</t>
</section>
<section title="Collusion between RPs">
<t>
It is possible for RPs to link data that they have collected on you.
By using the same identifier to log into every RP, collusion between
RPs is possible. In OpenID 2.0, directed identity was introduced.
Directed identity allows the OP to transform the identifier the user
typed in to another identifier. This way the RP would never see the
actual user identifier, but a randomly generated identifier. This is
an option the user has to understand and decide to use if the OP is
supporting it.
</t>
</section>
</section>
<section title="IANA Considerations">
<t> The IANA is requested to register the following SASL profile: </t>
<t/>
<t>SASL mechanism profile: OPENID20</t>
<t>Security Considerations: See this document</t>
<t>Published Specification: See this document</t>
<t>For further information: Contact the authors of this document.</t>
<t>Owner/Change controller: the IETF</t>
<t>Note: None</t>
</section>
<section title="Acknowledgments">
<t>The authors would like to thank Alexey Melenkov, Joe
Hildebrand, Mark Crispin, Chris Newman, Leif Johansson, and
Klaas Wierenga for their review and contributions.
</t>
</section>
</middle>
<back>
<references title="Normative References">
<reference anchor="OpenID">
<front>
<title>OpenID Authentication 2.0 - Final</title>
<author>
<organization>OpenID Foundation</organization>
<address>
<uri>http://www.openid.net</uri>
</address>
</author>
<date month="December" day="5" year="2007" />
</front>
<format type="HTML"
target="http://openid.net/specs/openid-authentication-2_0.html" />
</reference>
<reference anchor="SREG1.0">
<front>
<title>OpenID Simple Registration Extension version
1.0</title>
<author>
<organization>OpenID Foundation</organization>
<address>
<uri>http://www.openid.net</uri>
</address>
</author>
<date year="2006" month="June" day="30" />
</front>
<format type="HTML"
target="http://openid.net/specs/openid-simple-registration-extension-1_0.html"
/>
</reference>
<reference anchor="XRI2.0">
<front>
<title>Extensible Resource Identifier (XRI) Syntax
V2.0</title>
<author fullname="Drummond Reed" initials="D."
surname="Reed">
<organization>Cordance</organization>
<address>
<email>drummond.reed@cordance.net</email>
</address>
</author>
<author fullname="Dave McAlpin" initials="D." surname="McAlpin">
<organization>Epok</organization>
<address>
<email>dave.mcalpin@epokinc.com</email>
</address>
</author>
<date year="2005" month="September" day="14" />
</front>
<seriesInfo name="OASIS Standard" value="xri-syntax-V2.0-cs"
/>
<format type="HTML"
target="http://www.oasis-open.org/committees/download.php/15376/xri-syntax-V2.0-cs.html"
/>
</reference>
&RFC2119;
&RFC2743;
&RFC4422;
&RFC2606;
&RFC2616;
&RFC3986;
&RFC5246;
&GS2;
</references>
<section title="Changes">
<t>This section to be removed prior to publication.</t>
<t>
<list style="symbols">
<t>02 Correct single (significant) error on mechanism name.</t>
<t>01 Add nonce discussion, add authorized identity, explain
a definition. Add gs2 support.</t>
<t>00 Initial Revision. </t>
</list>
</t>
</section>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-23 08:34:24 |