idnits 2.17.1
draft-ietf-kitten-sasl-saml-09.txt:
Checking boilerplate required by RFC 5378 and the IETF Trust (see
https://trustee.ietf.org/license-info):
----------------------------------------------------------------------------
No issues found here.
Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt:
----------------------------------------------------------------------------
No issues found here.
Checking nits according to https://www.ietf.org/id-info/checklist :
----------------------------------------------------------------------------
== There are 1 instance of lines with non-RFC2606-compliant FQDNs in the
document.
Miscellaneous warnings:
----------------------------------------------------------------------------
== The copyright year in the IETF Trust and authors Copyright Line does not
match the current year
-- The document date (February 20, 2012) is 4442 days in the past. Is this
intentional?
Checking references for intended status: Proposed Standard
----------------------------------------------------------------------------
(See RFCs 3967 and 4897 for information about using normative references
to lower-maturity documents in RFCs)
** Obsolete normative reference: RFC 2616 (Obsoleted by RFC 7230, RFC 7231,
RFC 7232, RFC 7233, RFC 7234, RFC 7235)
** Obsolete normative reference: RFC 2818 (Obsoleted by RFC 9110)
** Obsolete normative reference: RFC 5246 (Obsoleted by RFC 8446)
** Obsolete normative reference: RFC 6125 (Obsoleted by RFC 9525)
-- Obsolete informational reference (is this intentional?): RFC 3501
(Obsoleted by RFC 9051)
Summary: 4 errors (**), 0 flaws (~~), 2 warnings (==), 2 comments (--).
Run idnits with the --verbose option for more detailed information about
the items above.
--------------------------------------------------------------------------------
2 Network Working Group K. Wierenga
3 Internet-Draft Cisco Systems, Inc.
4 Intended status: Standards Track E. Lear
5 Expires: August 23, 2012 Cisco Systems GmbH
6 S. Josefsson
7 SJD AB
8 February 20, 2012
10 A SASL and GSS-API Mechanism for SAML
11 draft-ietf-kitten-sasl-saml-09.txt
13 Abstract
15 Security Assertion Markup Language (SAML) has found its usage on the
16 Internet for Web Single Sign-On. Simple Authentication and Security
17 Layer (SASL) and the Generic Security Service Application Program
18 Interface (GSS-API) are application frameworks to generalize
19 authentication. This memo specifies a SASL mechanism and a GSS-API
20 mechanism for SAML 2.0 that allows the integration of existing SAML
21 Identity Providers with applications using SASL and GSS-API.
23 Status of this Memo
25 This Internet-Draft is submitted in full conformance with the
26 provisions of BCP 78 and BCP 79.
28 Internet-Drafts are working documents of the Internet Engineering
29 Task Force (IETF). Note that other groups may also distribute
30 working documents as Internet-Drafts. The list of current Internet-
31 Drafts is at http://datatracker.ietf.org/drafts/current/.
33 Internet-Drafts are draft documents valid for a maximum of six months
34 and may be updated, replaced, or obsoleted by other documents at any
35 time. It is inappropriate to use Internet-Drafts as reference
36 material or to cite them other than as "work in progress."
38 This Internet-Draft will expire on August 23, 2012.
40 Copyright Notice
42 Copyright (c) 2012 IETF Trust and the persons identified as the
43 document authors. All rights reserved.
45 This document is subject to BCP 78 and the IETF Trust's Legal
46 Provisions Relating to IETF Documents
47 (http://trustee.ietf.org/license-info) in effect on the date of
48 publication of this document. Please review these documents
49 carefully, as they describe your rights and restrictions with respect
50 to this document. Code Components extracted from this document must
51 include Simplified BSD License text as described in Section 4.e of
52 the Trust Legal Provisions and are provided without warranty as
53 described in the Simplified BSD License.
55 Table of Contents
57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
58 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4
59 1.2. Applicability . . . . . . . . . . . . . . . . . . . . . . 4
60 2. Authentication flow . . . . . . . . . . . . . . . . . . . . . 6
61 3. SAML SASL Mechanism Specification . . . . . . . . . . . . . . 9
62 3.1. Initial Response . . . . . . . . . . . . . . . . . . . . . 9
63 3.2. Authentication Request . . . . . . . . . . . . . . . . . . 10
64 3.3. Outcome and parameters . . . . . . . . . . . . . . . . . . 11
65 4. SAML GSS-API Mechanism Specification . . . . . . . . . . . . . 12
66 4.1. GSS-API Principal Name Types for SAML . . . . . . . . . . 13
67 5. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
68 5.1. XMPP . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
69 5.2. IMAP . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
70 6. Security Considerations . . . . . . . . . . . . . . . . . . . 22
71 6.1. Man in the middle and Tunneling Attacks . . . . . . . . . 22
72 6.2. Binding SAML subject identifiers to Authorization
73 Identities . . . . . . . . . . . . . . . . . . . . . . . . 22
74 6.3. User Privacy . . . . . . . . . . . . . . . . . . . . . . . 22
75 6.4. Collusion between RPs . . . . . . . . . . . . . . . . . . 22
76 6.5. GSS-API specific security considerations . . . . . . . . . 22
77 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24
78 7.1. IANA mech-profile . . . . . . . . . . . . . . . . . . . . 24
79 7.2. IANA OID . . . . . . . . . . . . . . . . . . . . . . . . . 24
80 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 25
81 8.1. Normative References . . . . . . . . . . . . . . . . . . . 25
82 8.2. Informative References . . . . . . . . . . . . . . . . . . 26
83 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 28
84 Appendix B. Changes . . . . . . . . . . . . . . . . . . . . . . . 29
85 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 30
87 1. Introduction
89 Security Assertion Markup Language (SAML) 2.0
90 [OASIS.saml-core-2.0-os] is a set of specifications that provide
91 various means for a user to be identified to a relying party (RP)
92 through the exchange of (typically signed) assertions issued by an
93 identity provider (IdP). It includes a number of protocols, protocol
94 bindings [OASIS.saml-bindings-2.0-os], and interoperability profiles
95 [OASIS.saml-profiles-2.0-os] designed for different use cases.
97 Simple Authentication and Security Layer (SASL) [RFC4422] is a
98 generalized mechanism for identifying and authenticating a user and
99 for optionally negotiating a security layer for subsequent protocol
100 interactions. SASL is used by application protocols like IMAP
101 [RFC3501], POP [RFC1939] and XMPP [RFC6120]. The effect is to make
102 modular authentication, so that newer authentication mechanisms can
103 be added as needed. This memo specifies just such a mechanism.
105 The Generic Security Service Application Program Interface (GSS-API)
106 [RFC2743] provides a framework for applications to support multiple
107 authentication mechanisms through a unified programming interface.
108 This document defines a pure SASL mechanism for SAML, but it conforms
109 to the new bridge between SASL and the GSS-API called GS2 [RFC5801].
110 This means that this document defines both a SASL mechanism and a
111 GSS-API mechanism. The GSS-API interface is OPTIONAL for SASL
112 implementers, and the GSS-API considerations can be avoided in
113 environments that use SASL directly without GSS-API.
115 As currently envisioned, this mechanism enables interworking between
116 SASL and SAML in order to assert the identity of the user and other
117 attributes to relying parties. As such, while servers (as relying
118 parties) will advertise SASL mechanisms (including SAML), clients
119 will select the SAML SASL mechanism as their SASL mechanism of
120 choice.
122 The SAML mechanism described in this memo aims to re-use the Web
123 Browser SSO profile defined in section 4.1 of the SAML profiles 2.0
124 specification [OASIS.saml-profiles-2.0-os] to the maximum extent and
125 therefore does not establish a separate authentication, integrity and
126 confidentiality mechanism. The mechanism assumes a security layer,
127 such as Transport Layer Security (TLS [RFC5246]), will continue to be
128 used. This specification is appropriate for use when a browser
129 instance is available. In the absence of a browser instance, SAML
130 profiles that don't require a browser such as the Enhanced Client or
131 Proxy profile (as defined in section 4.2 of the SAML profiles 2.0
132 specification [OASIS.saml-profiles-2.0-os] may be used, but that is
133 outside the scope of this specification.
135 Figure 1 describes the interworking between SAML and SASL: this
136 document requires enhancements to the Relying Party (the SASL server)
137 and to the Client, as the two SASL communication end points, but no
138 changes to the SAML Identity Provider are necessary. To accomplish
139 this goal some indirect messaging is tunneled within SASL, and some
140 use of external methods is made.
142 +-----------+
143 | |
144 >| Relying |
145 / | Party |
146 // | |
147 // +-----------+
148 SAML/ // ^
149 HTTPS // +--|--+
150 // | S| |
151 / S | A| |
152 // A | M| |
153 // S | L| |
154 // L | | |
155 // | | |
156 +--|--+
157 +------------+ v
158 | | +----------+
159 | SAML | HTTPS | |
160 | Identity |<--------------->| Client |
161 | Provider | | |
162 +------------+ +----------+
164 Figure 1: Interworking Architecture
166 1.1. Terminology
168 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
169 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
170 document are to be interpreted as described in RFC 2119 [RFC2119].
172 The reader is assumed to be familiar with the terms used in the SAML
173 2.0 specification [OASIS.saml-core-2.0-os].
175 1.2. Applicability
177 Because this mechanism transports information that should not be
178 controlled by an attacker, the SAML mechanism MUST only be used over
179 channels protected by TLS, or over similar integrity protected and
180 authenticated channels. In addition, when TLS is used the client
181 MUST successfully validate the server certificate ([RFC5280],
182 [RFC6125])
184 Note: An Intranet does not constitute such an integrity protected and
185 authenticated channel!
187 2. Authentication flow
189 While SAML itself is merely a markup language, its common use case
190 these days is with HTTP [RFC2616] or HTTPS [RFC2818] and HTML
191 [W3C.REC-html401-19991224]. What follows is a typical flow:
193 1. The browser requests a resource of a Relying Party (RP) (via an
194 HTTP request).
196 2. The Relying Party redirects the browser via an HTTP redirect (as
197 described in Section 10.3 of [RFC2616]) to the Identity Provider
198 (IdP) or an IdP discovery service. When it does so, it includes
199 the following parameters: (1) an authentication request that
200 contains the name of resource being requested, (2) a browser
201 cookie, and (3) a return URL as specified in Section 3.1 of the
202 SAML profiles 2.0 specification [OASIS.saml-profiles-2.0-os].
204 3. The user authenticates to the IdP and perhaps authorizes the
205 release of user attributes to the Relying Party.
207 4. In its authentication response, the IdP redirects (via an HTTP
208 redirect) the browser back to the RP with an authentication
209 assertion (stating that the IdP vouches that the subject has
210 successfully authenticated), optionally along with some
211 additional attributes.
213 5. The Relying Party now has sufficient identity information to
214 approve access to the resource or not, and acts accordingly. The
215 authentication is concluded.
217 When considering this flow in the context of SASL, we note that while
218 the Relying Party and the client both must change their code to
219 implement this SASL mechanism, the IdP can remain untouched. The
220 Relying Party already has some sort of session (probably a TCP
221 connection) established with the client. However, it may be
222 necessary to redirect a SASL client to another application or
223 handler. The steps are as follows:
225 1. The SASL server (Relying Party) advertises support for the SASL
226 SAML20 mechanism to the client
228 2. The client initiates a SASL authentication with SAML20 and sends
229 a domain name that allows the SASL server to determine the
230 appropriate IdP
232 3. The SASL server transmits an authentication request encoded using
233 a Uniform Resource Identifier (URI) as described in RFC 3986
234 [RFC3986] and an HTTP redirect to the IdP corresponding to the
235 domain
237 4. The SASL client now sends an empty response, as authentication
238 continues via the normal SAML flow and the SASL server will
239 receive the answer to the challenge out-of-band from the SASL
240 conversation.
242 5. At this point the SASL client MUST construct a URL containing the
243 content received in the previous message from the SASL server.
244 This URL is transmitted to the IdP either by the SASL client
245 application or an appropriate handler, such as a browser.
247 6. Next the user authenticates to the IdP. The manner in which the
248 end user is authenticated to the IdP and any policies surrounding
249 such authentication is out of scope for SAML and hence for this
250 draft. This step happens out of band from SASL.
252 7. The IdP will convey information about the success or failure of
253 the authentication back to the the SASL server (Relying Party) in
254 the form of an Authentication Statement or failure, using a
255 indirect response via the client browser or the handler (and with
256 an external browser client control should be passed back to the
257 SASL client). This step happens out of band from SASL.
259 8. The SASL Server sends an appropriate SASL response to the client,
260 along with an optional list of attributes
262 Please note: What is described here is the case in which the client
263 has not previously authenticated. It is possible that the client
264 already holds a valid SAML authentication token so that the user does
265 not need to be involved in the process anymore, but that would still
266 be external to SASL. This is classic Web Single Sign-On, in which
267 the Web Browser client presents the authentication token (cookie) to
268 the RP without renewed user authentication at the IdP.
270 With all of this in mind, the flow appears as follows in Figure 2:
272 SASL Serv. Client IdP
273 |>-----(1)----->| | Advertisement
274 | | |
275 |<-----(2)-----<| | Initiation
276 | | |
277 |>-----(3)----->| | Authentication Request
278 | | |
279 |<-----(4)-----<| | Empty Response
280 | | |
281 | |< - -(5,6) - ->| Client<>IDP
282 | | | Authentication
283 | | |
284 |<- - - - - - - - - - -(7)- - -| Authentication Statement
285 | | |
286 |>-----(8)----->| | SASL completion with
287 | | | status
288 | | |
290 ----- = SASL
291 - - - = HTTP or HTTPS (external to SASL)
293 Figure 2: Authentication flow
295 3. SAML SASL Mechanism Specification
297 This section specifies the details of the SAML SASL mechanism. See
298 section 5 of [RFC4422] for what is described here.
300 The name of this mechanism is "SAML20". The mechanism is capable of
301 transferring an authorization identity (via the "gs2-header"). The
302 mechanism does not offer a security layer.
304 The mechanism is client-first. The first mechanism message from the
305 client to the server is the "initial-response". As described in
306 [RFC4422], if the application protocol does not support sending a
307 client-response together with the authentication request, the server
308 will send an empty server-challenge to let the client begin. The
309 second mechanism message is from the server to the client, containing
310 the SAML "authentication-request". The third mechanism message is
311 from client to the server, and is the fixed message consisting of "="
312 (i.e., an empty response). The fourth mechanism message is from the
313 server to the client, indicating the SASL mechanism outcome.
315 3.1. Initial Response
317 A client initiates a "SAML20" authentication with SASL by sending the
318 GS2 header followed by the authentication identifier (message 2 in
319 Figure 2) and is defined as follows:
321 initial-response = gs2-header Idp-Identifier
322 IdP-Identifier = domain ; domain name with corresponding IdP
324 The "gs2-header" is used as follows:
326 - The "gs2-nonstd-flag" MUST NOT be present.
328 - The "gs2-cb-flag" MUST be set to "n" because channel binding
329 [RFC5056] data cannot be integrity protected by the SAML
330 negotiation. (Note: In theory channel binding data could be
331 inserted in the SAML flow by the client and verified by the
332 server, but that is currently not supported in SAML.)
334 - The "gs2-authzid" carries the optional authorization identity as
335 specified in [RFC5801] (not to be confused with the IdP-
336 Identifier).
338 Domain name is specified in [RFC1035]. A domain name is either a
339 "traditional domain name" as described in [RFC1035] or an
340 "internationalized domain name" as described in [RFC5890]. Clients
341 and servers MUST treat the IdP-Identifier as a domain name slot
342 [RFC5890]. They also SHOULD support internationalized domain names
343 (IDNs) in the Idp-Identifier field; if they do so, all of the domain
344 name's labels MUST be A-labels or NR-LDH labels [RFC5890], if
345 necessary internationalized labels MUST be converted from U-labels to
346 A-labels by using the Punycode encoding [RFC3492] for A-labels prior
347 to sending them to the SASL-server as described in the protocol
348 specification for Internationalized Domain Names in Applications
349 [RFC5891].
351 3.2. Authentication Request
353 The SASL Server transmits to the SASL client a URI that redirects the
354 SAML client to the IdP (corresponding to the domain that the user
355 provided), with a SAML authentication request as one of the
356 parameters (message 3 in Figure 2) in the following way:
358 authentication-request = URI
360 URI is specified in [RFC3986] and is encoded according to Section 3.4
361 (HTTP Redirect) of the SAML bindings 2.0 specification
362 [OASIS.saml-bindings-2.0-os]. The SAML authentication request is
363 encoded according to Section 3.4 (Authentication Request) of the SAML
364 core 2.0 specification [OASIS.saml-core-2.0-os]. Should the client
365 support Internationalized Resource Identifiers (IRIs) [RFC3987] it
366 MUST first convert the IRI to a URI before transmitting it to the
367 server [RFC5890].
369 Note: The SASL server may have a static mapping of domain to
370 corresponding IdP or alternatively a DNS-lookup mechanism could be
371 envisioned, but that is out-of-scope for this document.
373 Note: While the SASL client MAY sanity check the URI it received,
374 ultimately it is the SAML IdP that will be validated by the SAML
375 client which is out-of-scope for this document.
377 The client then sends the authentication request via an HTTP GET
378 (sent over a server-authenticated TLS channel) to the IdP, as if
379 redirected to do so from an HTTP server and in accordance with the
380 Web Browser SSO profile, as described in section 3.1 of SAML profiles
381 2.0 specification [OASIS.saml-profiles-2.0-os] (message 5 and 6 in
382 Figure 2).
384 The client handles both user authentication to the IdP and
385 confirmation or rejection of the authentiation of the RP (out-of-
386 scope for this document).
388 After all authentication has been completed by the IdP, the IdP will
389 send a redirect message to the client in the form of a URI
390 corresponding to the Relying Party as specified in the authentication
391 request ("AssertionConsumerServiceURL") and with the SAML response as
392 one of the parameters (message 7 in Figure 2).
394 Please note: this means that the SASL server needs to implement a
395 SAML Relying Party. Also, the SASL server needs to correlate the
396 session it has with the SASL client with the appropriate SAML
397 authentication result. It can do so by comparing the ID of the SAML
398 authentication request it has issued with the one it receives in the
399 SAML authentication statement.
401 3.3. Outcome and parameters
403 The SASL server (in its capacity as a SAML Relying Party) now
404 validates the SAML authentication response it received from the SAML
405 client via HTTP or HTTPS.
407 The outcome of that validation by the SASL server constitutes a SASL
408 mechanism outcome, and therefore (as stated in [RFC4422]) SHALL be
409 used to set state in the server accordingly, and it SHALL be used by
410 the server to report that state to the SASL client as described in
411 [RFC4422] Section 3.6 (message 8 in Figure 2).
413 4. SAML GSS-API Mechanism Specification
415 This section and its sub-sections are not required for SASL
416 implementors, but this section MUST be observed to implement the GSS-
417 API mechanism discussed below.
419 This section specify a GSS-API mechanism that when used via the GS2
420 bridge to SASL behaves like the SASL mechanism defined in this
421 document. Thus, it can loosely be said that the SAML SASL mechanism
422 is also a GSS-API mechanism. The SAML user takes the role of the
423 GSS-API Initiator and the SAML Relying Party takes the role of the
424 GSS-API Acceptor. The SAML Identity Provider does not have a role in
425 GSS-API, and is considered an internal matter for the SAML mechanism.
426 The messages are the same, but
428 a) the GS2 header on the client's first message and channel binding
429 data is excluded when SAML is used as a GSS-API mechanism, and
431 b) the RFC2743 section 3.1 initial context token header is prefixed
432 to the client's first authentication message (context token).
434 The GSS-API mechanism OID for SAML is OID-TBD (IANA to assign: see
435 IANA considerations).
437 SAML20 security contexts MUST have the mutual_state flag
438 (GSS_C_MUTUAL_FLAG) set to TRUE. SAML does not support credential
439 delegation, therefore SAML security contexts MUST have the
440 deleg_state flag (GSS_C_DELEG_FLAG) set to FALSE.
442 The mutual authentication property of this mechanism relies on
443 successfully comparing the TLS server identity with the negotiated
444 target name. Since the TLS channel is managed by the application
445 outside of the GSS-API mechanism, the mechanism itself is unable to
446 confirm the name while the application is able to perform this
447 comparison for the mechanism. For this reason, applications MUST
448 match the TLS server identity with the target name, as discussed in
449 [RFC6125]. More precisely, to pass identity validation the client
450 uses the securely negotiated targ_name as the reference identifier
451 and match it to the DNS-ID of the server certificate, and MUST reject
452 the connection if there is a mismatch. For compatibility with
453 deployed certificate hierarchies, the client MAY also perform a
454 comparison with the CN-ID when there is no DNS-ID present. Wildcard
455 matching is permitted. The targ_name reference identifier is a
456 "traditional domain names" thus the comparison is made using case-
457 insensitive ASCII comparison.
459 The SAML mechanism does not support per-message tokens or
460 GSS_Pseudo_random.
462 4.1. GSS-API Principal Name Types for SAML
464 SAML supports standard generic name syntaxes for acceptors such as
465 GSS_C_NT_HOSTBASED_SERVICE (see [RFC2743], Section 4.1). SAML
466 supports only a single name type for initiators: GSS_C_NT_USER_NAME.
467 GSS_C_NT_USER_NAME is the default name type for SAML. The query,
468 display, and exported name syntaxes for SAML principal names are all
469 the same. There are no SAML-specific name syntaxes -- applications
470 should use generic GSS-API name types such as GSS_C_NT_USER_NAME and
471 GSS_C_NT_HOSTBASED_SERVICE (see [RFC2743], Section 4). The exported
472 name token does, of course, conforms to [RFC2743], Section 3.2.
474 5. Examples
476 5.1. XMPP
478 Suppose the user has an identity at the SAML IdP saml.example.org and
479 a Jabber Identifier (JID) "somenode@example.com", and wishes to
480 authenticate his XMPP connection to xmpp.example.com. The
481 authentication on the wire would then look something like the
482 following:
484 Step 1: Client initiates stream to server:
486
490 Step 2: Server responds with a stream tag sent to client:
492
496 Step 3: Server informs client of available authentication mechanisms:
498
499
500 DIGEST-MD5
501 PLAIN
502 SAML20
503
504
506 Step 4: Client selects an authentication mechanism and provides the
507 initial client response containing the according to the definition in
508 Section 4 ofBASE64 [RFC4648] encoded gs2-header and domain:
510
511 biwsZXhhbXBsZS5vcmc
513 The decoded string is: n,,example.org
514 Step 5: Server sends a BASE64 encoded challenge to client in the form
515 of an HTTP Redirect to the SAML IdP corresponding to example.org
516 (https://saml.example.org) with the SAML Authentication Request as
517 specified in the redirection url:
519 aHR0cHM6Ly9zYW1sLmV4YW1wbGUub3JnL1NBTUwvQnJvd3Nlcj9TQU1MUmVx
520 dWVzdD1QSE5oYld4d09rRjFkR2h1VW1WeGRXVnpkQ0I0Yld4dWN6cHpZVzFz
521 Y0QwaWRYSnVPbTloYzJsek9tNWhiV1Z6T25Sak9sTkJUVXc2TWk0d09uQnli
522 M1J2WTI5c0lnMEtJQ0FnSUVsRVBTSmZZbVZqTkRJMFptRTFNVEF6TkRJNE9U
523 QTVZVE13Wm1ZeFpUTXhNVFk0TXpJM1pqYzVORGMwT1RnMElpQldaWEp6YVc5
524 dVBTSXlMakFpRFFvZ0lDQWdTWE56ZFdWSmJuTjBZVzUwUFNJeU1EQTNMVEV5
525 TFRFd1ZERXhPak01T2pNMFdpSWdSbTl5WTJWQmRYUm9iajBpWm1Gc2MyVWlE
526 UW9nSUNBZ1NYTlFZWE56YVhabFBTSm1ZV3h6WlNJTkNpQWdJQ0JRY205MGIy
527 TnZiRUpwYm1ScGJtYzlJblZ5YmpwdllYTnBjenB1WVcxbGN6cDBZenBUUVUx
528 TU9qSXVNRHBpYVc1a2FXNW5jenBJVkZSUUxWQlBVMVFpRFFvZ0lDQWdRWE56
529 WlhKMGFXOXVRMjl1YzNWdFpYSlRaWEoyYVdObFZWSk1QUTBLSUNBZ0lDQWdJ
530 Q0FpYUhSMGNITTZMeTk0YlhCd0xtVjRZVzF3YkdVdVkyOXRMMU5CVFV3dlFY
531 TnpaWEowYVc5dVEyOXVjM1Z0WlhKVFpYSjJhV05sSWo0TkNpQThjMkZ0YkRw
532 SmMzTjFaWElnZUcxc2JuTTZjMkZ0YkQwaWRYSnVPbTloYzJsek9tNWhiV1Z6
533 T25Sak9sTkJUVXc2TWk0d09tRnpjMlZ5ZEdsdmJpSStEUW9nSUNBZ0lHaDBk
534 SEJ6T2k4dmVHMXdjQzVsZUdGdGNHeGxMbU52YlEwS0lEd3ZjMkZ0YkRwSmMz
535 TjFaWEkrRFFvZ1BITmhiV3h3T2s1aGJXVkpSRkJ2YkdsamVTQjRiV3h1Y3pw
536 ellXMXNjRDBpZFhKdU9tOWhjMmx6T201aGJXVnpPblJqT2xOQlRVdzZNaTR3
537 T25CeWIzUnZZMjlzSWcwS0lDQWdJQ0JHYjNKdFlYUTlJblZ5YmpwdllYTnBj
538 enB1WVcxbGN6cDBZenBUUVUxTU9qSXVNRHB1WVcxbGFXUXRabTl5YldGME9u
539 Qmxjbk5wYzNSbGJuUWlEUW9nSUNBZ0lGTlFUbUZ0WlZGMVlXeHBabWxsY2ow
540 aWVHMXdjQzVsZUdGdGNHeGxMbU52YlNJZ1FXeHNiM2REY21WaGRHVTlJblJ5
541 ZFdVaUlDOCtEUW9nUEhOaGJXeHdPbEpsY1hWbGMzUmxaRUYxZEdodVEyOXVk
542 R1Y0ZEEwS0lDQWdJQ0I0Yld4dWN6cHpZVzFzY0QwaWRYSnVPbTloYzJsek9t
543 NWhiV1Z6T25Sak9sTkJUVXc2TWk0d09uQnliM1J2WTI5c0lpQU5DaUFnSUNB
544 Z0lDQWdRMjl0Y0dGeWFYTnZiajBpWlhoaFkzUWlQZzBLSUNBOGMyRnRiRHBC
545 ZFhSb2JrTnZiblJsZUhSRGJHRnpjMUpsWmcwS0lDQWdJQ0FnZUcxc2JuTTZj
546 MkZ0YkQwaWRYSnVPbTloYzJsek9tNWhiV1Z6T25Sak9sTkJUVXc2TWk0d09t
547 RnpjMlZ5ZEdsdmJpSStEUW9nb0NBZ0lDQjFjbTQ2YjJGemFYTTZibUZ0WlhN
548 NmRHTTZVMEZOVERveUxqQTZZV002WTJ4aGMzTmxjenBRWVhOemQyOXlaRkJ5
549 YjNSbFkzUmxaRlJ5WVc1emNHOXlkQTBLSUNBOEwzTmhiV3c2UVhWMGFHNURi
550 MjUwWlhoMFEyeGhjM05TWldZK0RRb2dQQzl6WVcxc2NEcFNaWEYxWlhOMFpX
551 UkJkWFJvYmtOdmJuUmxlSFErSUEwS1BDOXpZVzFzY0RwQmRYUm9ibEpsY1hW
552 bGMzUSs=
554 The decoded challenge is:
556 https://saml.example.org/SAML/Browser?SAMLRequest=PHNhbWxwOk
557 F1dGhuUmVxdWVzdCB4bWxuczpzYW1scD0idXJuOm9hc2lzOm5hbWVzOnRjOl
558 NBTUw6Mi4wOnByb3RvY29sIg0KICAgIElEPSJfYmVjNDI0ZmE1MTAzNDI4OT
559 A5YTMwZmYxZTMxMTY4MzI3Zjc5NDc0OTg0IiBWZXJzaW9uPSIyLjAiDQogIC
560 AgSXNzdWVJbnN0YW50PSIyMDA3LTEyLTEwVDExOjM5OjM0WiIgRm9yY2VBdX
561 Robj0iZmFsc2UiDQogICAgSXNQYXNzaXZlPSJmYWxzZSINCiAgICBQcm90b2
562 NvbEJpbmRpbmc9InVybjpvYXNpczpuYW1lczp0YzpTQU1MOjIuMDpiaW5kaW
563 5nczpIVFRQLVBPU1QiDQogICAgQXNzZXJ0aW9uQ29uc3VtZXJTZXJ2aWNlVV
564 JMPQ0KICAgICAgICAiaHR0cHM6Ly94bXBwLmV4YW1wbGUuY29tL1NBTUwvQX
565 NzZXJ0aW9uQ29uc3VtZXJTZXJ2aWNlIj4NCiA8c2FtbDpJc3N1ZXIgeG1sbn
566 M6c2FtbD0idXJuOm9hc2lzOm5hbWVzOnRjOlNBTUw6Mi4wOmFzc2VydGlvbi
567 I+DQogICAgIGh0dHBzOi8veG1wcC5leGFtcGxlLmNvbQ0KIDwvc2FtbDpJc3
568 N1ZXI+DQogPHNhbWxwOk5hbWVJRFBvbGljeSB4bWxuczpzYW1scD0idXJuOm
569 9hc2lzOm5hbWVzOnRjOlNBTUw6Mi4wOnByb3RvY29sIg0KICAgICBGb3JtYX
570 Q9InVybjpvYXNpczpuYW1lczp0YzpTQU1MOjIuMDpuYW1laWQtZm9ybWF0On
571 BlcnNpc3RlbnQiDQogICAgIFNQTmFtZVF1YWxpZmllcj0ieG1wcC5leGFtcG
572 xlLmNvbSIgQWxsb3dDcmVhdGU9InRydWUiIC8+DQogPHNhbWxwOlJlcXVlc3
573 RlZEF1dGhuQ29udGV4dA0KICAgICB4bWxuczpzYW1scD0idXJuOm9hc2lzOm
574 5hbWVzOnRjOlNBTUw6Mi4wOnByb3RvY29sIiANCiAgICAgICAgQ29tcGFyaX
575 Nvbj0iZXhhY3QiPg0KICA8c2FtbDpBdXRobkNvbnRleHRDbGFzc1JlZg0KIC
576 AgICAgeG1sbnM6c2FtbD0idXJuOm9hc2lzOm5hbWVzOnRjOlNBTUw6Mi4wOm
577 Fzc2VydGlvbiI+DQogICAgICAgICAgIHVybjpvYXNpczpuYW1lczp0YzpTQU
578 1MOjIuMDphYzpjbGFzc2VzOlBhc3N3b3JkUHJvdGVjdGVkVHJhbnNwb3J0DQ
579 ogIDwvc2FtbDpBdXRobkNvbnRleHRDbGFzc1JlZj4NCiA8L3NhbWxwOlJlcX
580 Vlc3RlZEF1dGhuQ29udGV4dD4gDQo8L3NhbWxwOkF1dGhuUmVxdWVzdD4=
582 Where the decoded SAMLRequest looks like:
584
591
592 https://xmpp.example.com
593
594
597
600
602 urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport
603
604
605
607 Note: the server can use the request ID
608 (_bec424fa5103428909a30ff1e31168327f79474984) to correlate the SASL
609 session with the SAML authentication.
611 Step 5 (alternative): Server returns error to client if no SAML
612 Authentication Request can be constructed:
614
615
616
617
619 Step 6: Client sends the empty response to the challenge encoded as a
620 single =:
622
623 =
624
626 The following steps between brackets are out of scope for this
627 document but included to better illustrate the entire flow.
629 [The client now sends the URL to a browser instance for processing.
630 The browser engages in a normal SAML authentication flow (external to
631 SASL), like redirection to the Identity Provider
632 (https://saml.example.org), the user logs into
633 https://saml.example.org, and agrees to authenticate to
634 xmpp.example.com. A redirect is passed back to the client browser
635 who sends the AuthN response to the server, containing the subject-
636 identifier as an attribute. If the AuthN response doesn't contain
637 the JID, the server maps the subject-identifier received from the IdP
638 to a JID]
640 Step 7: Server informs client of successful authentication:
642
644 Step 7 (alt): Server informs client of failed authentication:
646
647
648
649
651 Please note: line breaks were added to the base64 for clarity.
653 5.2. IMAP
655 The following describes an IMAP exchange. Lines beginning with 'S:'
656 indicate data sent by the server, and lines starting with 'C:'
657 indicate data sent by the client. Long lines are wrapped for
658 readability.
660 S: * OK IMAP4rev1
661 C: . CAPABILITY
662 S: * CAPABILITY IMAP4rev1 STARTTLS
663 S: . OK CAPABILITY Completed
664 C: . STARTTLS
665 S: . OK Begin TLS negotiation now
666 C: . CAPABILITY
667 S: * CAPABILITY IMAP4rev1 AUTH=SAML20
668 S: . OK CAPABILITY Completed
669 C: . AUTHENTICATE SAML20
670 S: +
671 C: biwsZXhhbXBsZS5vcmc
672 S: + aHR0cHM6Ly9zYW1sLmV4YW1wbGUub3JnL1NBTUwvQnJvd3Nlcj9TQU1M
673 UmVxdWVzdD1QSE5oYld4d09rRg0KMWRHaHVVbVZ4ZFdWemRDQjRiV3h1Y3pwe
674 llXMXNjRDBpZFhKdU9tOWhjMmx6T201aGJXVnpPblJqT2xOQg0KVFV3Nk1pNH
675 dPbkJ5YjNSdlkyOXNJZzBLSUNBZ0lFbEVQU0pmWW1Wak5ESTBabUUxTVRBek5
676 ESTRPVEE1WQ0KVE13Wm1ZeFpUTXhNVFk0TXpJM1pqYzVORGMwT1RnMElpQlda
677 WEp6YVc5dVBTSXlMakFpRFFvZ0lDQWdTWA0KTnpkV1ZKYm5OMFlXNTBQU0l5T
678 URBM0xURXlMVEV3VkRFeE9qTTVPak0wV2lJZ1JtOXlZMlZCZFhSb2JqMA0KaV
679 ptRnNjMlVpRFFvZ0lDQWdTWE5RWVhOemFYWmxQU0ptWVd4elpTSU5DaUFnSUN
680 CUWNtOTBiMk52YkVKcA0KYm1ScGJtYzlJblZ5YmpwdllYTnBjenB1WVcxbGN6
681 cDBZenBUUVUxTU9qSXVNRHBpYVc1a2FXNW5jenBJVg0KRlJRTFZCUFUxUWlEU
682 W9nSUNBZ1FYTnpaWEowYVc5dVEyOXVjM1Z0WlhKVFpYSjJhV05sVlZKTVBRME
683 tJQw0KQWdJQ0FnSUNBaWFIUjBjSE02THk5dFlXbHNMbVY0WVcxd2JHVXVZMjl
684 0TDFOQlRVd3ZRWE56WlhKMGFXOQ0KdVEyOXVjM1Z0WlhKVFpYSjJhV05sSWo0
685 TkNpQThjMkZ0YkRwSmMzTjFaWElnZUcxc2JuTTZjMkZ0YkQwaQ0KZFhKdU9tO
686 WhjMmx6T201aGJXVnpPblJqT2xOQlRVdzZNaTR3T21GemMyVnlkR2x2YmlJK0
687 RRb2dJQ0FnSQ0KR2gwZEhCek9pOHZlRzF3Y0M1bGVHRnRjR3hsTG1OdmJRMEt
688 JRHd2YzJGdGJEcEpjM04xWlhJK0RRb2dQSA0KTmhiV3h3T2s1aGJXVkpSRkJ2
689 YkdsamVTQjRiV3h1Y3pwellXMXNjRDBpZFhKdU9tOWhjMmx6T201aGJXVg0Ke
690 k9uUmpPbE5CVFV3Nk1pNHdPbkJ5YjNSdlkyOXNJZzBLSUNBZ0lDQkdiM0p0WV
691 hROUluVnlianB2WVhOcA0KY3pwdVlXMWxjenAwWXpwVFFVMU1Pakl1TURwdVl
692 XMWxhV1F0Wm05eWJXRjBPbkJsY25OcGMzUmxiblFpRA0KUW9nSUNBZ0lGTlFU
693 bUZ0WlZGMVlXeHBabWxsY2owaWVHMXdjQzVsZUdGdGNHeGxMbU52YlNJZ1FXe
694 HNiMw0KZERjbVZoZEdVOUluUnlkV1VpSUM4K0RRb2dQSE5oYld4d09sSmxjWF
695 ZsYzNSbFpFRjFkR2h1UTI5dWRHVg0KNGRBMEtJQ0FnSUNCNGJXeHVjenB6WVc
696 xc2NEMGlkWEp1T205aGMybHpPbTVoYldWek9uUmpPbE5CVFV3Ng0KTWk0d09u
697 QnliM1J2WTI5c0lpQU5DaUFnSUNBZ0lDQWdRMjl0Y0dGeWFYTnZiajBpWlhoa
698 FkzUWlQZzBLSQ0KQ0E4YzJGdGJEcEJkWFJvYmtOdmJuUmxlSFJEYkdGemMxSm
699 xaZzBLSUNBZ0lDQWdlRzFzYm5NNmMyRnRiRA0KMGlkWEp1T205aGMybHpPbTV
700 oYldWek9uUmpPbE5CVFV3Nk1pNHdPbUZ6YzJWeWRHbHZiaUkrRFFvZ0lDQQ0K
701 Z0lDQjFjbTQ2YjJGemFYTTZibUZ0WlhNNmRHTTZVMEZOVERveUxqQTZZV002W
702 TJ4aGMzTmxjenBRWVhOeg0KZDI5eVpGQnliM1JsWTNSbFpGUnlZVzV6Y0c5eW
703 RBMEtJQ0E4TDNOaGJXdzZRWFYwYUc1RGIyNTBaWGgwUQ0KMnhoYzNOU1pXWSt
704 EUW9nUEM5ellXMXNjRHBTWlhGMVpYTjBaV1JCZFhSb2JrTnZiblJsZUhRK0lB
705 MEtQQw0KOXpZVzFzY0RwQmRYUm9ibEpsY1hWbGMzUSs=
706 C:
707 S: . OK Success (tls protection)
708 The decoded challenge is:
710 https://saml.example.org/SAML/Browser?SAMLRequest=PHNhbWxwOkF
711 1dGhuUmVxdWVzdCB4bWxuczpzYW1scD0idXJuOm9hc2lzOm5hbWVzOnRjOlNB
712 TUw6Mi4wOnByb3RvY29sIg0KICAgIElEPSJfYmVjNDI0ZmE1MTAzNDI4OTA5Y
713 TMwZmYxZTMxMTY4MzI3Zjc5NDc0OTg0IiBWZXJzaW9uPSIyLjAiDQogICAgSX
714 NzdWVJbnN0YW50PSIyMDA3LTEyLTEwVDExOjM5OjM0WiIgRm9yY2VBdXRobj0
715 iZmFsc2UiDQogICAgSXNQYXNzaXZlPSJmYWxzZSINCiAgICBQcm90b2NvbEJp
716 bmRpbmc9InVybjpvYXNpczpuYW1lczp0YzpTQU1MOjIuMDpiaW5kaW5nczpIV
717 FRQLVBPU1QiDQogICAgQXNzZXJ0aW9uQ29uc3VtZXJTZXJ2aWNlVVJMPQ0KIC
718 AgICAgICAiaHR0cHM6Ly9tYWlsLmV4YW1wbGUuY29tL1NBTUwvQXNzZXJ0aW9
719 uQ29uc3VtZXJTZXJ2aWNlIj4NCiA8c2FtbDpJc3N1ZXIgeG1sbnM6c2FtbD0i
720 dXJuOm9hc2lzOm5hbWVzOnRjOlNBTUw6Mi4wOmFzc2VydGlvbiI+DQogICAgI
721 Gh0dHBzOi8veG1wcC5leGFtcGxlLmNvbQ0KIDwvc2FtbDpJc3N1ZXI+DQogPH
722 NhbWxwOk5hbWVJRFBvbGljeSB4bWxuczpzYW1scD0idXJuOm9hc2lzOm5hbWV
723 zOnRjOlNBTUw6Mi4wOnByb3RvY29sIg0KICAgICBGb3JtYXQ9InVybjpvYXNp
724 czpuYW1lczp0YzpTQU1MOjIuMDpuYW1laWQtZm9ybWF0OnBlcnNpc3RlbnQiD
725 QogICAgIFNQTmFtZVF1YWxpZmllcj0ieG1wcC5leGFtcGxlLmNvbSIgQWxsb3
726 dDcmVhdGU9InRydWUiIC8+DQogPHNhbWxwOlJlcXVlc3RlZEF1dGhuQ29udGV
727 4dA0KICAgICB4bWxuczpzYW1scD0idXJuOm9hc2lzOm5hbWVzOnRjOlNBTUw6
728 Mi4wOnByb3RvY29sIiANCiAgICAgICAgQ29tcGFyaXNvbj0iZXhhY3QiPg0KI
729 CA8c2FtbDpBdXRobkNvbnRleHRDbGFzc1JlZg0KICAgICAgeG1sbnM6c2FtbD
730 0idXJuOm9hc2lzOm5hbWVzOnRjOlNBTUw6Mi4wOmFzc2VydGlvbiI+DQogICA
731 gICB1cm46b2FzaXM6bmFtZXM6dGM6U0FNTDoyLjA6YWM6Y2xhc3NlczpQYXNz
732 d29yZFByb3RlY3RlZFRyYW5zcG9ydA0KICA8L3NhbWw6QXV0aG5Db250ZXh0Q
733 2xhc3NSZWY+DQogPC9zYW1scDpSZXF1ZXN0ZWRBdXRobkNvbnRleHQ+IA0KPC
734 9zYW1scDpBdXRoblJlcXVlc3Q+
736 Where the decoded SAMLRequest looks like:
738
745
746 https://xmpp.example.com
747
748
751
754
756 urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport
757
758
759
761 6. Security Considerations
763 This section addresses only security considerations associated with
764 the use of SAML with SASL applications. For considerations relating
765 to SAML in general, the reader is referred to the SAML specification
766 and to other literature. Similarly, for general SASL Security
767 Considerations, the reader is referred to that specification.
769 6.1. Man in the middle and Tunneling Attacks
771 This mechanism is vulnerable to man-in-the-middle and tunneling
772 attacks unless a client always verifies the server identity before
773 proceeding with authentication (see [RFC6125]). Typically TLS is
774 used to provide a secure channel with server authentication.
776 6.2. Binding SAML subject identifiers to Authorization Identities
778 As specified in [RFC4422], the server is responsible for binding
779 credentials to a specific authorization identity. It is therefore
780 necessary that only specific trusted IdPs be allowed. This is
781 typical part of SAML trust establishment between Relying Parties and
782 IdP.
784 6.3. User Privacy
786 The IdP is aware of each Relying Party that a user logs into. There
787 is nothing in the protocol to hide this information from the IdP. It
788 is not a requirement to track the visits, but there is nothing that
789 prohibits the collection of information. SASL server implementers
790 should be aware that SAML IdPs will be able to track - to some extent
791 - user access to their services.
793 6.4. Collusion between RPs
795 It is possible for Relying Parties to link data that they have
796 collected on the users. By using the same identifier to log into
797 every Relying Party, collusion between Relying Parties is possible.
798 In SAML, targeted identity was introduced. Targeted identity allows
799 the IdP to transform the identifier the user typed in to a Relying
800 Party specific opaque identifier. This way the Relying Party would
801 never see the actual user identifier, but a randomly generated
802 identifier.
804 6.5. GSS-API specific security considerations
806 Security issues inherent in GSS-API (RFC 2743) and GS2 (RFC 5801)
807 apply to the SAML GSS-API mechanism defined in this document.
808 Further, and as discussed in section 4, proper TLS server identity
809 verification is critical to the security of the mechanism.
811 7. IANA Considerations
813 7.1. IANA mech-profile
815 The IANA is requested to register the following SASL profile:
817 SASL mechanism profile: SAML20
819 Security Considerations: See this document
821 Published Specification: See this document
823 For further information: Contact the authors of this document.
825 Owner/Change controller: the IETF
827 Intended usage: COMMON
829 Note: None
831 7.2. IANA OID
833 The IANA is further requested to assign a new entry for this GSS
834 mechanism in the sub-registry for SMI Security for Mechanism Codes,
835 whose prefix is iso.org.dod.internet.security.mechanisms
836 (1.3.6.1.5.5) and to reference this specification in the registry.
838 8. References
840 8.1. Normative References
842 [OASIS.saml-bindings-2.0-os]
843 Cantor, S., Hirsch, F., Kemp, J., Philpott, R., and E.
844 Maler, "Bindings for the OASIS Security Assertion Markup
845 Language (SAML) V2.0", OASIS
846 Standard saml-bindings-2.0-os, March 2005.
848 [OASIS.saml-core-2.0-os]
849 Cantor, S., Kemp, J., Philpott, R., and E. Maler,
850 "Assertions and Protocol for the OASIS Security Assertion
851 Markup Language (SAML) V2.0", OASIS Standard saml-core-
852 2.0-os, March 2005.
854 [OASIS.saml-profiles-2.0-os]
855 Hughes, J., Cantor, S., Hodges, J., Hirsch, F., Mishra,
856 P., Philpott, R., and E. Maler, "Profiles for the OASIS
857 Security Assertion Markup Language (SAML) V2.0", OASIS
858 Standard OASIS.saml-profiles-2.0-os, March 2005.
860 [RFC1035] Mockapetris, P., "Domain names - implementation and
861 specification", STD 13, RFC 1035, November 1987.
863 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
864 Requirement Levels", BCP 14, RFC 2119, March 1997.
866 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
867 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext
868 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
870 [RFC2743] Linn, J., "Generic Security Service Application Program
871 Interface Version 2, Update 1", RFC 2743, January 2000.
873 [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000.
875 [RFC3492] Costello, A., "Punycode: A Bootstring encoding of Unicode
876 for Internationalized Domain Names in Applications
877 (IDNA)", RFC 3492, March 2003.
879 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
880 Resource Identifier (URI): Generic Syntax", STD 66,
881 RFC 3986, January 2005.
883 [RFC3987] Duerst, M. and M. Suignard, "Internationalized Resource
884 Identifiers (IRIs)", RFC 3987, January 2005.
886 [RFC4422] Melnikov, A. and K. Zeilenga, "Simple Authentication and
887 Security Layer (SASL)", RFC 4422, June 2006.
889 [RFC5056] Williams, N., "On the Use of Channel Bindings to Secure
890 Channels", RFC 5056, November 2007.
892 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security
893 (TLS) Protocol Version 1.2", RFC 5246, August 2008.
895 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
896 Housley, R., and W. Polk, "Internet X.509 Public Key
897 Infrastructure Certificate and Certificate Revocation List
898 (CRL) Profile", RFC 5280, May 2008.
900 [RFC5801] Josefsson, S. and N. Williams, "Using Generic Security
901 Service Application Program Interface (GSS-API) Mechanisms
902 in Simple Authentication and Security Layer (SASL): The
903 GS2 Mechanism Family", RFC 5801, July 2010.
905 [RFC5890] Klensin, J., "Internationalized Domain Names for
906 Applications (IDNA): Definitions and Document Framework",
907 RFC 5890, August 2010.
909 [RFC5891] Klensin, J., "Internationalized Domain Names in
910 Applications (IDNA): Protocol", RFC 5891, August 2010.
912 [RFC6125] Saint-Andre, P. and J. Hodges, "Representation and
913 Verification of Domain-Based Application Service Identity
914 within Internet Public Key Infrastructure Using X.509
915 (PKIX) Certificates in the Context of Transport Layer
916 Security (TLS)", RFC 6125, March 2011.
918 [W3C.REC-html401-19991224]
919 Hors, A., Raggett, D., and I. Jacobs, "HTML 4.01
920 Specification", World Wide Web Consortium
921 Recommendation REC-html401-19991224, December 1999,
922 .
924 8.2. Informative References
926 [RFC1939] Myers, J. and M. Rose, "Post Office Protocol - Version 3",
927 STD 53, RFC 1939, May 1996.
929 [RFC3501] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION
930 4rev1", RFC 3501, March 2003.
932 [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data
933 Encodings", RFC 4648, October 2006.
935 [RFC6120] Saint-Andre, P., "Extensible Messaging and Presence
936 Protocol (XMPP): Core", RFC 6120, March 2011.
938 Appendix A. Acknowledgments
940 The authors would like to thank Scott Cantor, Joe Hildebrand, Josh
941 Howlett, Leif Johansson, Thomas Lenggenhager, Diego Lopez, Hank
942 Mauldin, RL 'Bob' Morgan, Stefan Plug and Hannes Tschofenig for their
943 review and contributions.
945 Appendix B. Changes
947 This section to be removed prior to publication.
949 o 09 Fixed text per IESG review
951 o 08 Fixed text per Gen-Art review
953 o 07 Fixed text per comments Alexey Melnikov
955 o 06 Fixed text per AD comments
957 o 05 Fixed references per ID-nits
959 o 04 Added request for IANA assignment, few text clarifications
961 o 03 Number of cosmetic changes, fixes per comments Alexey Melnikov
963 o 02 Changed IdP URI to domain per Joe Hildebrand, fixed some typos
965 o 00 WG -00 draft. Updates GSS-API section, some fixes per Scott
966 Cantor
968 o 01 Added authorization identity, added GSS-API specifics, added
969 client supplied IdP
971 o 00 Initial Revision.
973 Authors' Addresses
975 Klaas Wierenga
976 Cisco Systems, Inc.
977 Haarlerbergweg 13-19
978 Amsterdam, Noord-Holland 1101 CH
979 Netherlands
981 Phone: +31 20 357 1752
982 Email: klaas@cisco.com
984 Eliot Lear
985 Cisco Systems GmbH
986 Richtistrasse 7
987 Wallisellen, ZH CH-8304
988 Switzerland
990 Phone: +41 44 878 9200
991 Email: lear@cisco.com
993 Simon Josefsson
994 SJD AB
995 Hagagatan 24
996 Stockholm 113 47
997 SE
999 Email: simon@josefsson.org
1000 URI: http://josefsson.org/