One document matched: draft-ietf-kitten-sasl-openid-08.xml
<?xml version="1.0"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd"[
<!ENTITY W3C.REC-html401-19991224 SYSTEM "http://xml.resource.org/public/rfc/bibxml4/reference.W3C.REC-html401-19991224.xml">
<!ENTITY RFC1939 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.1939.xml">
<!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 RFC3501 SYSTEM
"http://xml.resource.org/public/rfc/bibxml/reference.RFC.3501.xml">
<!ENTITY RFC6120 SYSTEM
"http://xml.resource.org/public/rfc/bibxml/reference.RFC.6120.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 RFC3987 SYSTEM
"http://xml.resource.org/public/rfc/bibxml/reference.RFC.3987.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 RFC4959 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4959.xml">
<!ENTITY RFC5246 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5246.xml">
<!ENTITY RFC5280 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5280.xml">
<!ENTITY RFC5587 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5587.xml">
<!ENTITY RFC5801 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5801.xml">
<!ENTITY RFC6125 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6125.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-ietf-kitten-sasl-openid-08" category="std">
<front>
<title abbrev="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="2012"/>
<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 web-based 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 <xref target="RFC3501">IMAP</xref>, <xref target="RFC1939">POP</xref>
and <xref target="RFC6120">XMPP</xref>,
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="RFC5801">GS2</xref>. This
means that this document defines both a SASL mechanism and
a GSS-API mechanism. Implementors of the SASL component MAY
implement the GSS-API interface as well.
</t>
<t>This mechanism specifies
interworking between SASL and OpenID in order to assert
identity and other attributes to relying parties. As such,
while SASL 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 OpenID mechanism to the maximum extent and therefore does
not establish a separate authentication, integrity and
confidentiality mechanism. It is anticipated that existing
security layers, such as <xref target="RFC5246">Transport
Layer Security (TLS)</xref>, continue to be used.
Minimal changes are required to non-web applications, as most
of the transaction occurs through a normal web browser.
Hence, this specification is only appropriate for use when
such a browser is available.
</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 through the SASL/GSS-API mechanism.</t>
<t>
<figure anchor="overview" title="Interworking Architecture">
<artwork><![CDATA[
+-----------+
| Relying |
>| Party / |
/ | SASL |
// | Server |
// +-----------+
// ^
OpenID // +--|--+
// | O| | G
/ S | p| | S
// A | e| | S
// S | n| | A
// L | I| | P
// | D| | I
</ +--|--+
+------------+ 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 TLS, and the client MUST
successfully validate the server certificate. <xref target="RFC5280" /><xref target="RFC6125" /></t>
</section>
</section>
<section title="Applicability for application protocols other than
HTTP">
<t>OpenID was originally envisioned for <xref target="RFC2616">HTTP</xref> and <xref target="W3C.REC-html401-19991224">HTML</xref> 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 can be found in Section 3 of
the <xref target="OpenID">OpenID 2.0 specification</xref>.
The reader is strongly encouraged to be familiar with the
specification before continuing.
</t>
<t>When considering that flow in the context of SASL, we note
that while the RP and the client both need to change their code
to implement this SASL mechanism, it is a design constraint
that the OP behavior remain untouched, in order for
implementations to interoperate with existing IdPs. 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 for a SASL client to invoke
to another application. This will be discussed below. By
doing so, we externalize much of the authentiction from SASL.
</t><t>
The steps are listed below:</t>
<t>
<list style="numbers">
<t>The SASL server advertises support for
the SASL OpenID mechanism to the client. </t>
<t>The client initiates a SASL authentication and transmits
the User-Supplied Identifier as its first response. The
SASL mechanism is client-first, and as explained in <xref
target="RFC4422"/> the server will send an empty challenge
if needed.</t>
<t>After normalizing the User-Supplied Identifier as
discussed in <xref target="OpenID" />, 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 validate
those messages through the use of an HMAC; 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> Note that any Internationalized Resource
Identifiers (IRIs) must be normalized to URIs by the SASL
client, as specified in <xref target="RFC3987" />, prior
to transmitting them to the SASL server.
</t>
<t>The SASL client now sends an response consisting of "=", to indicate that
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. For reasons of its own the OP has the option of
not authenticating a request.
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/TLS 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 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. RP/Client OP
|>-----(1)----->| | Advertisement
| | |
|<-----(2)-----<| | Initiation
| | |
|> - - (3) - - - - - - - - - ->| Discovery
| |
|>- - -(4)- - - - - - - - - - >| Association
|<- - -(4)- - - - - - - - - - <|
| | |
|>-----(5)----->| | Indirect Auth Request
| | |
|<-----(6)-----<| | Client "=" Response
| | |
| |>- - (7)- - ->| Client GET to the OP (ext)
| | |
| |<- - (8)- - ->| Client / OP Auth. (ext.)
| | |
|<- - -(9)- - - + - - - - - - <| HTTPs Indirect id_res
| | |
|<- - -(10)- - - - - - - - - ->| Optional check_authenticate
| | |
|>-----(11)---->| | SASL completion with status
----- = SASL
- - - = HTTPS
]]>
</artwork></figure>
</t>
<t>Note the directionality in SASL is such that the client MUST send the "="
response. Specifically, the SASL client 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>
OpenID is meant to be used in serial within the web, where browser
cookies are easily accessible. As such,
there are no transaction-ids within the protocol.
To ensure that a specific request is bound, and in particular to
ease interprocess communication, the relying
party MUST encode a nonce or transaction-id in the URIs it
transmits through the client for success or failure, either as a
base URI or fragment component to the "return_to" URI. This value
is to be used to uniquely identify each authentication transaction.
The nonce value MUST be at least 2^32 large and large enough to
handle well in excess of the number of concurrent transactions a
SASL server shall see.
</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 ensure 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 "=" client SASL
response. This is not to say that nothing is happening, but rather
that authentication flow has shifted from SASL and the client
application to OpenID within the browser, and
will return to the client application when the server has an outcome
to hand to the client.
The alternative to this flow would be some sort of signal from the
HTML browser to the SASL client of the results that would in turn be
passed to the SASL server. The inter-process communication issue
this raises is substantial. Better, we conclude, to externalize the
authentication to the browser, and have an "=" client response.
</t>
</section>
</section>
<section title="OpenID SASL Mechanism Specification">
<t>This section specifies the details of the OpenID SASL
mechanism. Recall section 5 of <xref target="RFC4422"/> for
what needs to be described here.</t>
<t>The name of this mechanism "OPENID20". The
mechanism is capable of transferring an authorization identity
(via "gs2-header"). The mechanism does not offer a security
layer.</t>
<t>The mechanism is client-first. The first mechanism message
from the client to the server is the "initial-response"
described below. As described in <xref target="RFC4422"/>, if
the application protocol does not support sending a
client-response together with the authentication request, the
server will send an empty server-challenge to let the client
begin.</t>
<t>The second mechanism message is from the server to the
client, the "authentication_request" described below.</t>
<t>The third mechanism message is from client to the server, and
is the fixed message consisting of "=".</t>
<t>The fourth mechanism message is from the server to the
client, described below as "outcome_data" (with SREG
attributes), sent as additional data when indicating a
successful outcome.</t>
<section title="Initiation" anchor="initiation">
<t>A client initiates an OpenID authentication with SASL by
sending the GS2 header followed by the URI, as
specified in the OpenID specification.</t>
<figure>
<artwork><![CDATA[
initial-response = gs2-header Auth-Identifier
Auth-Identifier = Identifier ; authentication identifier
Identifier = URI ; Identifier is specified in
; Sec. 7.2 of the OpenID 2.0 spec.
]]></artwork>
</figure>
<t>The syntax and semantics of the "gs2-header" are specified in
<xref target="RFC5801"/>, and we use it here with the following
limitations: The "gs2-nonstd-flag" MUST NOT be
present. The "gs2-cb-flag" MUST be "n" because channel binding
is not supported by this mechanism.</t>
<t>
URI is specified in <xref target="RFC3986" />. <xref target="XRI2.0">XRIs MUST NOT be used.</xref>
</t>
</section>
<section title="Authentication Request" anchor="request">
<t>The SASL Server sends the URL resulting from the OpenID
authentication request, containing an "openid.mode"
of either "checkid_immediate" or
"checkid_setup", as specified in Section 9.1 of the
OpenID 2.0 specification.</t>
<figure>
<artwork><![CDATA[
authentication-request = URI
]]></artwork>
</figure>
<t>As part of this request, the SASL server MUST append a
unique transaction id to the "return_to" portion of
the request. The form of this transaction is left to the RP
to decide, but SHOULD be large enough to be resistant to being
guessed or attacked.
</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 by the
RP via this SASL mechanism.</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/TLS, as
specified previously in the transaction ("return_to"). </t>
</section>
<section title="Server Response" anchor="response2">
<t>The Relying Party now validates the response it received
from the client via HTTP/TLS, as specified in the OpenID
specification, using the "return_to" URI given previsiously in
the transaction.</t>
<t>The response by the Relying Party constitutes a SASL
mechanism outcome, and SHALL be used to set state in the
server accordingly, and it SHALL be used by the server to
report that state to the SASL client as described in [RFC4422]
Section 3.6. In the additional data, the server MAY include
OpenID Simple Registry (SREG) attributes that are listed in
Section 4 of <xref target="SREG1.0" />.SREG
attributes 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 ampersand (&) 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>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 3986
; unreserved from Section 2.3 of RFC 3986
]]></artwork></figure>
</t>
<t>A client who does not support SREG MUST ignore SREG attributes
sent by the server. Similarly, a client MUST ignore unknown
attributes.
</t>
<t>In the case of failures, the response MUST follow this syntax:
<figure><artwork><![CDATA[
outcome_data = "openid.error" "=" sreg_val *( "," sregp_avp )
]]></artwork></figure>
</t>
</section>
<section title="Error Handling">
<t>
<xref target="RFC4422" /> Section 3.6 explicitly prohibits
additional information in an unsuccessful authentication
outcome. Therefore, the openid.error and openid.error_code
are to be sent as an additional challenge in the event of an
unsuccessful outcome. In this case, as the protocol is lock
step, the client will follow with an additional exchange
containing "=", after which the server will respond with an
application-level outcome.
</t>
</section>
</section>
<section title="OpenID GSS-API Mechanism Specification">
<t>This section and its sub-sections and appropriate
references of it not referenced elsewhere in this document are
not required for SASL implementors, but this section MUST be
observed to implement the GSS-API mechanism discussed below.</t>
<t>The OpenID SASL mechanism is actually also a GSS-API
mechanism. The OpenID user takes the role of the GSS-API
Initiator and the OpenID Relying Party takes the role of the
GSS-API Acceptor. The OpenId Provider does not have a role in
GSS-API, and is considered an internal matter for the OpenID
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 OID-TBD (IANA to
assign: see IANA considerations).
</t>
<t>OpenID security contexts MUST have the mutual_state flag
(GSS_C_MUTUAL_FLAG) set to TRUE. OpenID does not support
credential delegation, therefore OpenID security contexts
MUST have the deleg_state flag (GSS_C_DELEG_FLAG) set to
FALSE.
</t>
<t>The mutual authentication property of this mechanism relies
on successfully comparing the TLS server identity with the
negotiated target name. Since the TLS channel is managed by the
application outside of the GSS-API mechanism, the mechanism
itself is unable to confirm the name while the application is
able to perform this comparison for the mechanism. For this
reason, applications MUST match the TLS server identity with the
target name, as discussed in <xref target="RFC6125" />.</t>
<t>The OpenID mechanism does not support per-message tokens or
GSS_Pseudo_random.</t>
<t>The <xref target="RFC5587" /> mechanism attributes for this
mechanism are GSS_C_MA_MECH_CONCRETE, GSS_C_MA_ITOK_FRAMED, and
GSS_C_MA_AUTH_INIT.</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.
For example, the OpenID identifier "https://openid.example/" will
have a GSS_C_NT_USER_NAME value of
"https://openid.example/".
</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 https://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 RP
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. Note the use of <xref target="RFC4959" /> for initial
response. 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 biwsaHR0cHM6Ly9vcGVuaWQuZXhhbXBsZS8=
[ This is the base64 encoding of "n,,https://openid.example/".
Server performs discovery on http://openid.example/ ]
S: + aHR0cHM6Ly9vcGVuaWQuZXhhbXBsZS9vcGVuaWQvP29wZW5pZC5ucz1
odHRwOi8vc3BlY3Mub3BlbmlkLm5ldC9hdXRoLzIuMCZvcGVuaWQucm
V0dXJuX3RvPWh0dHBzOi8vbWFpbC5leGFtcGxlL2NvbnN1bWVyLzFlZ
jg4OGMmb3BlbmlkLmNsYWltZWRfaWQ9aHR0cHM6Ly9vcGVuaWQuZXhh
bXBsZS8mb3BlbmlkLmlkZW50aXR5PWh0dHBzOi8vb3BlbmlkLmV4YW1
wbGUvJm9wZW5pZC5yZWFsbT1pbWFwOi8vbWFpbC5leGFtcGxlJm9wZW
5pZC5tb2RlPWNoZWNraWRfc2V0dXA=
[ This is the base64 encoding of "https://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: PQ==
[ The client now sends the URL it received to a browser for
processing. The user logs into https://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 the "="
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 in response added in this example for clarity. ]
C:
[ In IMAP client must send a blank response after receiving the
SREG data. ]
S: C2 OK
]]></artwork></figure>
<t>
In this example, the SASL server / RP has made use of a transaction id
1ef888c.
</t>
</section>
<section title="Security Considerations">
<t>
This section will address only security considerations associated with
the use of OpenID with SASL and GSS-API. For considerations relating
to OpenID in general, the reader is referred to the OpenID
specification and to other literature
<eref target="http://sites.google.com/site/openidreview/resources" />.
Similarly, for general <xref target="RFC4422">SASL</xref>
and <xref target="RFC5801">GSS-API</xref> Security Considerations, the reader is referred to those
specifications.
</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 a
registration process takes place in advance that binds specific
OpenIDs to specific authorization identities, or that only specific
trusted OpenID Providers be allowed, where a mapping is predefined.
For example, it could be pre-arranged between an IdP and RP that
"https://example.com/user" maps to "user" for purposes of authorization.
</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 contain an unauthorized host or even the
local host. The URL could contain a protocol other than http or
https, such as file or ftp.
</t>
<t> One mitigation would be for RPs to have a list of authorized
URI bases. OPs SHOULD only redirect to RPs with the same domain
component of the base URI. RPs MUST NOT automatically retry on failed
attempts. 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. Applications SHOULD NOT invoke
browsers to communicate with OPs that they are not themselves
configured with.
</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 able to 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 principals.
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 update the SASL Mechanism Registry
using the following template, as described in <xref
target="RFC4422"/>.</t>
<t/>
<t>SASL mechanism name: OPENID20</t>
<t>Security Considerations: See this document</t>
<t>Published specification: See this document</t>
<t>Person & email address to contact for further information:
Authors of this document</t>
<t>Intended usage: COMMON</t>
<t>Owner/Change controller: IETF</t>
<t>Note: None</t>
<t>The IANA is further requested to assign an OID for this GSS
mechanism in the SMI numbers registry, with the prefix of
iso.org.dod.internet.security.mechanisms (1.3.6.1.5.5) and to
reference this specification in the registry.
</t>
</section>
<section title="Acknowledgments">
<t>The authors would like to thank Alexey Melnikov, Joe
Hildebrand, Mark Crispin, Chris Newman, Leif Johansson, Sam
Hartman, Nico Williams, Klaas Wierenga, Stephen Farrell,
and Stephen Kent 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://specs.openid.net/auth/2.0" />
</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/sreg/1.0" />
</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;
&RFC3987;
&RFC5246;
&RFC5280;
&RFC5587;
&RFC5801;
&RFC6125;
</references>
<references title="Informative References">
&W3C.REC-html401-19991224;
&RFC1939;
&RFC3501;
&RFC6120;
&RFC4959;
</references>
<section title="Changes">
<t>This section to be removed prior to publication.</t>
<t>
<list style="symbols">
<t>04 - 07 04 - 07 address LC and review comments,
including those of Stephen Farrell, Steve Kent, and Brian
Carpenter.
</t>
<t>03 Clarifies messages and ordering, and replace the empty
message with a "=" message.</t>
<t>02 Address all WGLC comments.</t>
<t>01 Specific text around possible improvements for OOB
browser control in security considerations. Also talk about
transaction id.</t>
<t>00 WG -00 draft. Slight wording modifications abou
design constraints per Alexey.</t>
<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 10:57:45 |