7 INTERNET-DRAFT A. Melnikov, Ed.
8 Intended Category: Standards Track ISODE Limited
9 Expires: July 2006 K. Zeilenga, Ed.
10 Obsoletes: RFC 2222 OpenLDAP Project
15 Simple Authentication and Security Layer (SASL)
16 <draft-ietf-sasl-rfc2222bis-15.txt>
21 By submitting this Internet-Draft, each author represents that any
22 applicable patent or other IPR claims of which he or she is aware have
23 been or will be disclosed, and any of which he or she becomes aware
24 will be disclosed, in accordance with Section 6 of BCP 79.
26 Internet-Drafts are working documents of the Internet Engineering Task
27 Force (IETF), its areas, and its working groups. Note that other
28 groups may also distribute working documents as Internet-Drafts.
30 Internet-Drafts are draft documents valid for a maximum of six months
31 and may be updated, replaced, or obsoleted by other documents at any
32 time. It is inappropriate to use Internet-Drafts as reference material
33 or to cite them other than as "work in progress."
35 The list of current Internet-Drafts can be accessed at
36 http://www.ietf.org/1id-abstracts.html
38 The list of Internet-Draft Shadow Directories can be accessed at
39 http://www.ietf.org/shadow.html
42 Copyright (C) The Internet Society (2006). All Rights Reserved.
44 Please see the Full Copyright section near the end of this document
50 The Simple Authentication and Security Layer (SASL) is a framework for
51 providing authentication and data security services in
52 connection-oriented protocols via replaceable mechanisms. It provides
53 a structured interface between protocols and mechanisms. The
54 resulting framework allows new protocols to reuse existing mechanisms
58 Melnikov & Zeilenga SASL [Page 1]
60 INTERNET-DRAFT draft-ietf-sasl-rfc2222bis-15.txt 23 January 2006
63 and allows old protocols to make use of new mechanisms. The framework
64 also provides a protocol for securing subsequent protocol exchanges
65 within a data security layer.
67 This document describes how a SASL mechanism is structured, describes
68 how protocols include support for SASL, and defines the protocol for
69 carrying a data security layer over a connection. Additionally, this
70 document defines one SASL mechanism, the EXTERNAL mechanism.
72 This document obsoletes RFC 2222.
76 [[Page numbers to be filled in by RFC-Editor]]
81 1.1. Document Audiences
82 1.2. Relationship to Other Documents
85 3. The Authentication Exchange
87 3.2. Mechanism Negotiation
88 3.3. Request Authentication Exchange
89 3.4. Challenges and Responses
90 3.4.1. Authorization Identity String
91 3.5. Aborting Authentication Exchanges
92 3.6. Authentication Outcome
94 3.8. Multiple Authentications
95 4. Protocol Requirements
96 5. Mechanism Requirements
97 6. Security Considerations
99 6.1.1. Man-in-the-middle Attacks
100 6.1.2. Replay Attacks
101 6.1.3. Truncation Attacks
104 6.4. Other considerations
105 7. IANA Considerations
109 A. The SASL EXTERNAL Mechanism
110 B. Changes since RFC 2222
114 Melnikov & Zeilenga SASL [Page 2]
116 INTERNET-DRAFT draft-ietf-sasl-rfc2222bis-15.txt 23 January 2006
121 The Simple Authentication and Security Layer (SASL) is a framework for
122 providing authentication and data security services in
123 connection-oriented protocols via replaceable mechanisms. SASL
124 provides a structured interface between protocols and mechanisms.
125 SASL also provides a protocol for securing subsequent protocol
126 exchanges within a data security layer. The data security layer can
127 provide data integrity, data confidentiality, and other services.
129 SASL's design is intended to allow new protocols to reuse existing
130 mechanisms without requiring redesign of the mechanisms and allows
131 existing protocols to make use of new mechanisms without redesign of
134 SASL is conceptually a framework which provides an abstraction layer
135 between protocols and mechanisms as illustrated in the following
138 SMTP LDAP XMPP Other protocols ...
141 SASL abstraction layer
144 EXTERNAL GSSAPI PLAIN Other mechanisms ...
146 It is through the interfaces of this abstraction layer that the
147 framework allows any protocol to utilize any mechanism. While this
148 layer does generally hide the particulars of protocols from mechanisms
149 and the particulars of mechanisms from protocols, this layer does not
150 generally hide the particulars of mechanisms from protocol
151 implementations. For example, different mechanisms require different
152 information to operate, some of them use password-based
153 authentication, some of then require realm information, others make
154 use of Kerberos tickets, certificates, etc.. Also, in order to
155 perform authorization, server implementations generally have to
156 implement identity mapping between authentication identities, whose
157 form is mechanism-specific, and authorization identities, whose form
158 is application protocol specific. Section 2 discusses identity
161 It is possible to design and implement this framework in ways which do
162 abstract away particulars of similar mechanisms. Such a framework
163 implementation, as well as mechanisms implementations, could be
164 designed not only to be shared by multiple implementations of a
165 particular protocol, but be shared by implementations of multiple
170 Melnikov & Zeilenga SASL [Page 3]
172 INTERNET-DRAFT draft-ietf-sasl-rfc2222bis-15.txt 23 January 2006
175 The framework incorporates interfaces with both protocols and
176 mechanisms in which authentication exchanges are carried out. Section
177 3 discusses SASL authentication exchanges.
179 To use SASL, each protocol (amongst other items) provides a method for
180 identifying which mechanism is to be used, provides a method for
181 exchange of mechanism-specific server-challenges and client-responses,
182 and a method for communicating the outcome of the authentication
183 exchange. Section 4 discusses SASL protocol requirements.
185 Each SASL mechanism defines (amongst other items) a series of server
186 challenges and client responses which provide authentication services
187 and negotiate data security services. Section 5 discusses SASL
188 mechanism requirements.
190 Section 6 discusses security considerations. Section 7 discusses IANA
191 considerations. Appendix A defines the SASL EXTERNAL mechanism.
194 1.1. Document Audiences
196 This document is written to serve several different audiences:
198 - protocol designers using this specification to support
199 authentication in their protocol,
201 - mechanism designers that define new SASL mechanisms, and
203 - implementors of clients or servers for those protocols which
206 While the document organization is intended to allow readers to focus
207 on details relevant to their engineering, readers are encouraged to
208 read and understand all aspects of this document.
211 1.2. Relationship to other documents
213 This document obsoletes RFC 2222. It replaces all portions of RFC
214 2222 excepting sections 7.1 (the KERBEROS_IV mechanism), 7.2 (the
215 GSSAPI mechanism), 7.3 (the SKEY mechanism). The KERBEROS_IV and SKEY
216 mechanisms are now viewed as obsolete and their specifications
217 provided in RFC 2222 are Historic. The GSSAPI mechanism is now
218 separately specified [SASL-GSSAPI].
220 Appendix B provides a summary of changes since RFC 2222.
226 Melnikov & Zeilenga SASL [Page 4]
228 INTERNET-DRAFT draft-ietf-sasl-rfc2222bis-15.txt 23 January 2006
233 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
234 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
235 document are to be interpreted as described in BCP 14 [RFC2119].
237 Character names in this document use the notation for code points and
238 names from the Unicode Standard [Unicode]. For example, the letter
239 "a" may be represented as either <U+0061> or <LATIN SMALL LETTER A>.
241 Note: a glossary of terms used in Unicode can be found in [Glossary].
242 Information on the Unicode character encoding model can be found in
245 In examples, "C:" and "S:" indicate lines of data to be sent by the
246 client and server respectively. Lines have been wrapped for improved
252 In practice, authentication and authorization may involve multiple
253 identities, possibly in different forms (simple username, Kerberos
254 principal, X.500 Distinguished Name, etc.), possibly with different
255 representations (e.g.: ABNF-described UTF-8 encoded Unicode character
256 string, BER-encoded Distinguished Name). While technical
257 specifications often prescribe both the identity form and
258 representation used on the network, different identity forms and/or
259 representations may (and often are) used within implementations. How
260 identities of different forms relate to each other is, generally, a
261 local matter. Additionally, the forms and representations used within
262 an implementation is a local matter.
264 However, conceptually, SASL framework involves two identities:
265 1) an identity associated with the authentication credentials
266 (termed the authentication identity), and
267 2) an identity to act as (termed the authorization identity).
269 SASL mechanism specifications describe the credential form(s) (e.g.,
270 X.509 certificates, Kerberos tickets, simple username/password) used
271 to authenticate the client, including (where appropriate) the syntax
272 and semantics of authentication identities carried in the credentials.
273 SASL protocol specifications describe the identity form(s) used in
274 authorization and, in particular, prescribe the syntax and semantics
275 of the authorization identity character string to be transferred by
278 The client provides its credentials (which include or imply an
282 Melnikov & Zeilenga SASL [Page 5]
284 INTERNET-DRAFT draft-ietf-sasl-rfc2222bis-15.txt 23 January 2006
287 authentication identity) and, optionally, a character string
288 representing the requested authorization identity as part of the SASL
289 exchange. When this character string is omitted or empty, the client
290 is requesting to act as the identity associated with the credentials
291 (e.g., the user is requesting to act as the authentication identity).
293 The server is responsible for verifying the client's credentials and
294 verifying that the identity it associates with the client's
295 credentials (e.g., the authentication identity) is allowed to act as
296 the authorization identity. A SASL exchange fails if either (or both)
297 of these verifications fails. (The SASL exchange may fail for other
298 reasons, such as service authorization failure.)
300 However, the precise form(s) of the authentication identities (used
301 within the server in its verifications, or otherwise) and the precise
302 form(s) of the authorization identities (used in making authorization
303 decisions, or otherwise) is beyond the scope of SASL and this
304 specification. In some circumstances, the precise identity forms used
305 in some context outside of the SASL exchange may be dictated by other
306 specifications. For instance, an identity assumption authorization
307 (proxy authorization) policy specification may dictate how
308 authentication and authorization identities are represented in policy
312 3. The Authentication Exchange
314 Each authentication exchange consists of a message from the client to
315 the server requesting authentication via a particular mechanism,
316 followed by one or more pairs of challenges from the server and
317 responses from the client, followed by a message from the server
318 indicating the outcome of the authentication exchange. (Note:
319 exchanges may also be aborted as discussed in Section 3.5.)
321 The following illustration provides a high-level overview of an
322 authentication exchange.
324 C: Request authentication exchange
327 <additional challenge/response messages>
328 S: Outcome of authentication exchange
330 If the outcome is successful and a security layer was negotiated, this
331 layer is then installed (see Section 3.7). This also applies to the
332 following illustrations.
334 Some mechanisms specify that the first data sent in the authentication
338 Melnikov & Zeilenga SASL [Page 6]
340 INTERNET-DRAFT draft-ietf-sasl-rfc2222bis-15.txt 23 January 2006
343 exchange is from the client to the server. Protocols may provide an
344 optional initial response field in the request message to carry this
345 data. Where the mechanism specifies the first data sent in the
346 exchange is from the client to the server, the protocol provides an
347 optional initial response field, and the client uses this field, the
348 exchange is shortened by one round-trip:
350 C: Request authentication exchange + Initial response
351 <additional challenge/response messages>
352 S: Outcome of authentication exchange
354 Where the mechanism specifies the first data sent in the exchange is
355 from the client to the server and this field is unavailable or unused,
356 the client request is followed by an empty challenge.
358 C: Request authentication exchange
361 <additional challenge/response messages>
362 S: Outcome of authentication exchange
364 Should a client include an initial response in its request where the
365 mechanism does not allow the client to send data first, the
366 authentication exchange fails.
368 Some mechanisms specify that the server is to send additional data to
369 the client when indicating a successful outcome. Protocols may
370 provide an optional additional data field in the outcome message to
371 carry this data. Where the mechanism specifies the server is to
372 return additional data with the successful outcome, the protocol
373 provides an optional additional data field in the outcome message, and
374 the server uses this field, the exchange is shortened by one
377 C: Request authentication exchange
380 <additional challenge/response messages>
381 S: Outcome of authentication exchange with
382 additional data with success
384 Where the mechanism specifies the server is to return additional data
385 to the client with a successful outcome and this field is unavailable
386 or unused, the additional data is sent as a challenge whose response
387 is empty. After receiving this response, the server then indicates
388 the successful outcome.
390 C: Request authentication exchange
394 Melnikov & Zeilenga SASL [Page 7]
396 INTERNET-DRAFT draft-ietf-sasl-rfc2222bis-15.txt 23 January 2006
401 <additional challenge/response messages>
402 S: Additional data challenge
404 S: Outcome of authentication exchange
407 Where mechanisms specify the first data sent in the exchange is from
408 the client to the server and additional data is sent to the client
409 along with indicating a successful outcome, and the protocol provides
410 fields supporting both, then the exchange takes two fewer round-trips:
412 C: Request authentication exchange + Initial response
413 <additional challenge/response messages>
414 S: Outcome of authentication exchange
415 with additional data with success
419 C: Request authentication exchange
422 <additional challenge/response messages>
423 S: Additional data challenge
425 S: Outcome of authentication exchange
428 3.1. Mechanism Naming
430 SASL mechanisms are named by character strings, from 1 to 20
431 characters in length, consisting of ASCII [ASCII] uppercase letters,
432 digits, hyphens, and/or underscores. In the following Augmented
433 Backus-Naur Form (ABNF) [RFC4234] grammar, the <sasl-mech> production
434 defines the syntax of a SASL mechanism name.
436 sasl-mech = 1*20mech-char
437 mech-char = UPPER-ALPHA / DIGIT / HYPHEN / UNDERSCORE
438 ; mech-char is restricted to A-Z (uppercase only), 0-9, -, and _
439 ; from ASCII character set.
441 UPPER-ALPHA = %x41-5A ; A-Z (uppercase only)
442 DIGIT = %x30-39 ; 0-9
443 HYPHEN = %x2D ; hyphen (-)
444 UNDERSCORE = %x5F ; underscore (_)
446 SASL mechanisms names are registered as discussed in Section 7.1.
450 Melnikov & Zeilenga SASL [Page 8]
452 INTERNET-DRAFT draft-ietf-sasl-rfc2222bis-15.txt 23 January 2006
455 3.2. Mechanism Negotiation
457 Mechanism negotiation is protocol-specific.
459 Commonly, a protocol will specify that the server advertises supported
460 and available mechanisms to the client via some facility provided by
461 the protocol and the client will then select the "best" mechanism from
462 this list which its supports and finds suitable.
464 It is noted that the mechanism negotiation is not protected by the
465 subsequent authentication exchange and hence is subject to downgrade
466 attacks if not protected by other means.
468 To detect downgrade attacks, a protocol can allow the client to
469 discover available mechanisms subsequent to the authentication
470 exchange and installation of data security layers with at least data
471 integrity protection. This allows the client to detect changes to the
472 list of mechanisms supported by the server.
475 3.3. Request Authentication Exchange
477 The authentication exchange is initiated by the client by requesting
478 authentication via a mechanism it specifies. The client sends a
479 message that contains the name of the mechanism to the server. The
480 particulars of the message are protocol specific.
482 It is noted that the name of the mechanism is not protected by the
483 mechanism, and hence subject to alteration by an attacker if not
484 integrity protected by other means.
486 Where the mechanism is defined to allow the client to send data first,
487 and the protocol's request message includes an optional initial
488 response field, the client may include the response to the initial
489 challenge in the authentication request message.
492 3.4. Challenges and Responses
494 The authentication exchange involves one or more pairs of
495 server-challenges and client-responses, the particulars of which are
496 mechanism specific. These challenges and responses are enclosed in
497 protocol messages, the particulars of which are protocol specific.
499 Through these challenges and responses, the mechanism may:
500 - authenticate the client to the server,
501 - authenticate the server to the client,
502 - transfer an authorization identity string,
506 Melnikov & Zeilenga SASL [Page 9]
508 INTERNET-DRAFT draft-ietf-sasl-rfc2222bis-15.txt 23 January 2006
511 - negotiate a security layer, and
512 - provide other services.
514 The negotiation of the security layer may involve negotiation of the
515 security services to be provided in the layer, how these services will
516 be provided, and negotiation of a maximum cipher-text buffer size each
517 side is able to receive in the layer (see Section 3.6).
519 After receiving an authentication request or any client response, the
520 server may issue a challenge, abort the exchange, or indicate the
521 outcome of an exchange. After receiving a challenge, a client
522 mechanism may issue a response or abort the exchange.
525 3.4.1. Authorization Identity String
527 The authorization identity string is a sequence of zero or more
528 Unicode [Unicode] characters, excluding the NUL (U+0000) character,
529 representing the identity to act as.
531 If the authorization identity string is absent, the client is
532 requesting to act as the identity the server associates with the
533 client's credentials. An empty string is equivalent to an absent
534 authorization identity.
536 Non-empty authorization identity string indicates the client wishes to
537 act as the identity represented by the string. In this case, the form
538 of identity represented by the string, as well as the precise syntax
539 and semantics of the string, is protocol specific.
541 While the character encoding schema used to transfer the authorization
542 identity string in the authentication exchange is mechanism specific,
543 mechanisms are expected to be capable of carrying the entire Unicode
544 repertoire (with the exception of the NUL character).
547 3.5. Aborting Authentication Exchanges
549 A client or server may desire to abort an authentication exchange if
550 it is unwilling or unable to continue (or enter into).
552 A client may abort the authentication exchange by sending a message,
553 the particulars of which are protocol-specific, to the server,
554 indicating the exchange is aborted. The server may be required by the
555 protocol to return a message in response to the client's abort
558 Likewise, a server may abort the authentication exchange by sending a
562 Melnikov & Zeilenga SASL [Page 10]
564 INTERNET-DRAFT draft-ietf-sasl-rfc2222bis-15.txt 23 January 2006
567 message, the particulars of which are protocol-specific, to the
568 client, indicating the exchange is aborted.
571 3.6. Authentication Outcome
573 At the conclusion of the authentication exchange, the server sends a
574 message, the particulars of which are protocol specific, to the client
575 indicating the outcome of the exchange.
577 The outcome is not successful if
578 - the authentication exchange failed for any reason,
579 - the clients credentials could not be verified,
580 - the server cannot associate an identity with the client's
582 - the client-provided authorization identity string is malformed,
583 - the identity associated with the client's credentials is not
584 authorized to act as the requested authorization identity,
585 - the negotiated security layer (or lack thereof) is not suitable,
587 - the server is not willing to provide service to the client for any
590 The protocol may include an optional additional data field in this
591 outcome message. This field can only include additional data when the
592 outcome is successful.
594 If the outcome is successful and a security layer was negotiated, this
595 layer is then installed. If the outcome is unsuccessful, or a
596 security layer was not negotiated, any existing security is left in
599 The outcome message provided by the server can provide a way for the
600 client to distinguish between errors which are best dealt with by re-
601 prompting the user for her credentials, errors which are best dealt
602 with by telling the user to try again later, and errors where the user
603 must contact a system administrator for resolution (see The SYS and
604 AUTH POP Response Codes [RFC3206] specification for an example). This
605 distinction is particularly useful during scheduled server maintenance
606 periods as it reduces support costs. It is also important that the
607 server can be configured such that the outcome message will not
608 distinguish between a valid user with invalid credentials and an
614 SASL mechanisms may offer a wide range of services in security layers.
618 Melnikov & Zeilenga SASL [Page 11]
620 INTERNET-DRAFT draft-ietf-sasl-rfc2222bis-15.txt 23 January 2006
623 Typical services include data integrity and data confidentiality.
624 SASL mechanisms which do not provide a security layer are treated as
625 negotiating no security layer.
627 If use of a security layer is negotiated in the authentication
628 protocol exchange, the layer is installed by the server after
629 indicating the outcome of the authentication exchange and installed by
630 the client upon receipt the outcome indication. In both cases, the
631 layer is installed before transfer of further protocol data. The
632 precise position that the layer takes effect in the protocol data
633 stream is protocol specific.
635 Once the security layer is in effect in the protocol data stream, it
636 remains in effect until either a subsequently negotiated security
637 layer is installed, or the underlying transport connection is closed.
639 When in effect, the security layer processes protocol data into
640 buffers of protected data. If at any time the security layer is
641 unable or unwilling to continue producing buffers protecting protocol
642 data, the underlying transport connection MUST be closed. If the
643 security layer is not able to decode a received buffer, the underlying
644 connection MUST be closed. In both cases the underlying transport
645 connection SHOULD be closed gracefully.
647 Each buffer of protected data is transferred over the underlying
648 transport connection as a sequence of octets prepended with a four
649 octet field in network byte order that represents the length of the
650 buffer. The length of the protected data buffer MUST be no larger
651 than the maximum size the other side expects. Upon the receipt of a
652 length field whose value is greater than maximum size, the receiver
653 SHOULD close the connection, as this might be a sign of an attack.
655 The maximum size each side expects is fixed by the mechanism, either
656 through negotiation or by its specification.
659 3.8. Multiple Authentications
661 Unless explicitly permitted in the protocol (as stated in the
662 protocol's technical specification), only one successful SASL
663 authentication exchange may occur in a protocol session. In this
664 case, once an authentication exchange has successfully completed,
665 further attempts to initiate an authentication exchange fail.
667 Where multiple successful SASL authentication exchanges are permitted
668 in the protocol, then in no case may multiple SASL security layers be
669 simultaneously in effect. If a security layer is in effect and a
670 subsequent SASL negotiation selects a second security layer, then the
674 Melnikov & Zeilenga SASL [Page 12]
676 INTERNET-DRAFT draft-ietf-sasl-rfc2222bis-15.txt 23 January 2006
679 second security layer replaces the first. If a security layer is in
680 effect and a subsequent SASL negotiation selects no security layer,
681 the original security layer remains in effect.
683 Where multiple successful SASL negotiations are permitted in the
684 protocol, the effect of a failed SASL authentication exchange upon the
685 previously established authentication and authorization state is
686 protocol specific. The protocol's technical specification should be
687 consulted to determine whether the previous authentication and
688 authorization state remains in force, or changed to an anonymous
689 state, or otherwise effected. Regardless of the protocol-specific
690 effect upon previously established authentication and authorization
691 state, the previously negotiated security layer remains in effect.
694 4. Protocol Requirements
696 In order for a protocol to offer SASL services, its specification MUST
697 supply the following information:
699 1) A service name, to be selected from registry of "service" elements
700 for the GSSAPI host-based service name form, as described in
701 Section 4.1 of [RFC2743]. Note that this registry is shared by all
702 GSSAPI and SASL mechanisms.
704 2) Detail any mechanism negotiation facility the protocol provides
707 A protocol SHOULD specify a facility through which the client may
708 discover, both before initiation of the SASL exchange and after
709 installing security layers negotiated by the exchange, the names of
710 the SASL mechanisms the server makes available to the client. The
711 latter is important to allow the client to detect downgrade
712 attacks. This facility is typically provided through the
713 protocol's extensions or capabilities discovery facility.
716 3) Definition of the messages necessary for authentication exchange,
719 a) A message to initiate the authentication exchange (see Section
722 This message MUST contain a field for carrying the name of the
723 mechanism selected by the client.
725 This message SHOULD contain an optional field for carrying an
726 initial response. If the message is defined with this field,
730 Melnikov & Zeilenga SASL [Page 13]
732 INTERNET-DRAFT draft-ietf-sasl-rfc2222bis-15.txt 23 January 2006
735 the specification MUST describe how messages with an empty
736 initial response are distinguished from messages with no initial
737 response. This field MUST be capable of carrying arbitrary
738 sequences of octets (including zero length sequences and
739 sequences containing zero-valued octets).
741 b) Messages to transfer server challenges and client responses.
744 Each of these messages MUST be capable of carrying arbitrary
745 sequences of octets (including zero length sequences and
746 sequences containing zero-valued octets).
748 c) A message to indicate the outcome of the authentication exchange
751 This message SHOULD contain an optional field for carrying
752 additional data with a successful outcome. If the message is
753 defined with this field, the specification MUST describe how
754 messages with an empty additional data are distinguished from
755 messages with no additional data. This field MUST be capable of
756 carrying arbitrary sequences of octets (including zero length
757 sequences and sequences containing zero-valued octets).
760 4) Prescribe the syntax and semantics of non-empty authorization
761 identity strings (see Section 3.4.1).
763 In order to avoid interoperability problems due to differing
764 normalizations, the protocol specification MUST detail precisely
765 the how and where (client or server) non-empty authorization
766 identity strings are prepared, including all normalizations, for
767 comparison and other applicable functions to ensure proper
770 Specifications are encouraged to prescribe use of existing
771 authorization identity forms as well as existing string
772 representations, such as simple user names [RFC4013].
774 Where the specification does not precisely prescribe how identities
775 in SASL relate to identities used elsewhere in the protocol, for
776 instance in access control policy statements, it may be appropriate
777 for the protocol to provide a facility by which the client can
778 discover information (such as the representation of the identity
779 used in making access control decisions) about established
780 identities for these uses.
786 Melnikov & Zeilenga SASL [Page 14]
788 INTERNET-DRAFT draft-ietf-sasl-rfc2222bis-15.txt 23 January 2006
791 5) Detail any facility the protocol provides that allows the client
792 and/or server to abort authentication exchange (see Section 3.5).
794 Protocols which support multiple authentications typically allow a
795 client to abort an on-going authentication exchange by initiating a
796 new authentication exchange. Protocols which do not support
797 multiple authentications may require the client to close the
798 connection and start over to abort an on-going authentication
801 Protocols typically allow the server to abort on-going
802 authentication exchanges by returning a non-successful outcome
806 6) Identify precisely where newly negotiated security layers start to
807 take effect, in both directions (see Section 3.7).
809 Typically, specifications require security layer to start taking
810 effect, in data being sent by the server, on the first octet
811 following the outcome message and, in data being sent by the
812 client, on the first octet sent after receipt of the outcome
816 7) If the protocol supports other layered security services, such as
817 Transport Layer Security (TLS) [RFC2246], the specification MUST
818 prescribe the order in which security layers are applied to
821 For instance, where a protocol supports both TLS and SASL security
822 layers, the specification could prescribe any of the following:
823 a) SASL security layer is always applied first to data being sent
824 and, hence, applied last to received data,
825 b) SASL security layer is always applied last to data being sent
826 and, hence, applied first to received data,
827 c) Layers are applied in the order in which they were installed,
828 d) Layers are applied in the reverse order in which they were
830 e) Both TLS and SASL security layers cannot be installed.
833 8) Indicate whether the protocol supports multiple authentications
834 (see Section 3.8). If so, the protocol MUST detail the effect a
835 failed SASL authentication exchange will have upon previously
836 established authentication and authorization state.
842 Melnikov & Zeilenga SASL [Page 15]
844 INTERNET-DRAFT draft-ietf-sasl-rfc2222bis-15.txt 23 January 2006
847 Protocol specifications SHOULD avoid stating implementation
848 requirements which would hinder replacement of applicable mechanisms.
849 In general, protocol specification SHOULD be mechanism neutral. There
850 are a number reasonable exceptions to this recommendation, including:
851 - detailing how credentials (which are mechanism-specific) are
852 managed in the protocol,
853 - detailing how authentication identities (which are
854 mechanism-specific) and authorization identities (which are
855 protocol-specific) relate to each other, and
856 - detailing which mechanisms are applicable to the protocol.
859 5. Mechanism Requirements
861 SASL mechanism specifications MUST supply the following information:
863 1) The name of the mechanism (see Section 3.1). This name MUST be
864 registered as discussed in Section 7.1.
867 2) A definition of the server-challenges and client-responses of the
868 authentication exchange, as well as:
870 a) An indication whether mechanism is client-first, variable, or
871 server-first. If a SASL mechanism is defined as client-first
872 and the client does not send an initial response in the
873 authentication request, then the first server challenge MUST be
874 empty (the EXTERNAL mechanism is an example of this case). If a
875 SASL mechanism is defined as variable, then the specification
876 needs to state how the server behaves when the initial client
877 response in the authentication request is omitted (the
878 DIGEST-MD5 mechanism [DIGEST-MD5] is an example of this case).
879 If a SASL mechanism is defined as server-first then the client
880 MUST NOT send an initial client response in the authentication
881 request (the CRAM-MD5 mechanism [CRAM-MD5] is an example of this
885 b) An indication whether the server is expected to provide
886 additional data when indicating a successful outcome. If so, if
887 the server sends the additional data as a challenge, the
888 specification MUST indicate the response to this challenge is an
891 SASL mechanisms SHOULD be designed to minimize the number of
892 challenges and responses necessary to complete the exchange.
898 Melnikov & Zeilenga SASL [Page 16]
900 INTERNET-DRAFT draft-ietf-sasl-rfc2222bis-15.txt 23 January 2006
903 3) An indication of whether the mechanism is capable of transferring
904 authorization identity strings (see Section 3.4.1). While some
905 legacy mechanisms are incapable of transmitting an authorization
906 identity (which means that for these mechanisms the authorization
907 identity is always the empty string), newly defined mechanisms
908 SHOULD be capable of transferring authorization identity strings.
909 The mechanism SHOULD NOT be capable of transferring both no
910 authorization identity string and an empty authorization identity.
912 Mechanisms which are capable of transferring an authorization
913 identity string MUST be capable of transferring arbitrary non-empty
914 sequences of Unicode characters, excluding those which contain the
915 NUL (U+0000) character. Mechanisms SHOULD use the UTF-8 [RFC3629]
916 transformation format. The specification MUST detail how any
917 Unicode code points special to the mechanism which might appear in
918 the authorization identity string are escaped to avoid ambiguity
919 during decoding of the authorization identity string. Typically,
920 mechanisms which have special characters require these special
921 characters to be escaped or encoded in the character string (after
922 encoding it a particular Unicode transformation format) using a
923 data encoding scheme such as Base64 [RFC3548].
926 4) The specification MUST detail whether or not the mechanism offers a
927 security layer. If the mechanism does, the specification MUST
928 detail the security and other services offered in the layer as well
929 as how these services are to be implemented.
932 5) If the underlying cryptographic technology used by a mechanism
933 supports data integrity, then the mechanism specification MUST
934 integrity protect the transmission of an authorization identity and
935 the negotiation of the security layer.
938 SASL mechanisms SHOULD be protocol neutral.
940 SASL mechanisms SHOULD reuse existing credential and identity forms,
941 as well as associated syntaxes and semantics.
943 SASL mechanisms SHOULD use UTF-8 transformation format [RFC3629] for
944 encoding Unicode [Unicode] code points for transfer.
946 In order to avoid interoperability problems due to differing
947 normalizations, when a mechanism calls for character data (other than
948 the authorization identity string) to be used as input to a
949 cryptographic and/or comparison function, the specification MUST
950 detail precisely how and where (client or server) the character data
954 Melnikov & Zeilenga SASL [Page 17]
956 INTERNET-DRAFT draft-ietf-sasl-rfc2222bis-15.txt 23 January 2006
959 is to be prepared, including all normalizations, for input into the
960 function to ensure proper operation.
962 For simple user names and/or passwords in authentication credentials,
963 SASLprep [RFC4013] (a profile of the StringPrep [RFC3454] preparation
964 algorithm), SHOULD be specified as the preparation algorithm.
966 The mechanism SHOULD NOT use the authorization identity string in
967 generation of any long-term cryptographic keys or hashes as there is
968 no requirement that the authorization identity string be canonical.
969 Long-term, here, means a term longer than the duration of the
970 authentication exchange in which they were generated in. That is, as
971 different clients (of the same or different protocol) may provide
972 different authorization identity strings which are semantically
973 equivalent, use of authorization identity strings in generation of
974 cryptographic keys and hashes will likely lead to interoperability and
978 6. Security Considerations
980 Security issues are discussed throughout this memo.
982 Many existing SASL mechanisms do not provide adequate protection
983 against passive attacks, let alone active attacks, in the
984 authentication exchange. Many existing SASL mechanisms do not offer
985 security layers. It is hoped that future SASL mechanisms will provide
986 strong protection against passive and active attacks in the
987 authentication exchange, as well as security layers with strong basic
988 data security features (e.g., data integrity and data confidentiality)
989 services. It is also hoped that future mechanisms will provide more
990 advanced data security services like re-keying (see Section 6.3).
992 Regardless, the SASL framework is suspectable to downgrade attacks.
993 Section 6.1.2 offers a variety of approaches for preventing or
994 detecting these attacks. In some cases, it is appropriate to use data
995 integrity protective services external to SASL (e.g., TLS [TLS]) to
996 protect against downgrade attacks in SASL. Use of external protective
997 security services is also important when the mechanisms available do
998 not themselves offer adequate integrity and/or confidentiality
999 protection of the authentication exchange and/or protocol data.
1004 6.1.1. Hijack Attacks
1006 When the client selects a SASL security layer with at least integrity
1010 Melnikov & Zeilenga SASL [Page 18]
1012 INTERNET-DRAFT draft-ietf-sasl-rfc2222bis-15.txt 23 January 2006
1015 protection, this protect serves as a counter-measure against an active
1016 attacker hijacking the connection and modifying protocol data sent
1017 after establishment of the security layer. Implementations should
1018 close the connection when the security services in an SASL security
1019 layer report protocol data report lack of data integrity.
1022 6.1.2. Downgrade Attacks
1024 It is important that any security-sensitive protocol negotiations be
1025 performed after installation of a security layer with data integrity
1026 protection. Protocols should be designed such that negotiations
1027 performed prior to this installation should be revalidated after
1028 installation is complete. Negotiation of the SASL mechanism is
1031 When a client negotiates the authentication mechanism with the server
1032 and/or other security features, it is possible for an active attacker
1033 to cause a party to use the least secure security services available.
1034 For instance, an attacker can modify the server-advertised mechanism
1035 list or can modify client-advertised security feature list within a
1036 mechanism response. To protect against this sort of attack,
1037 implementations should not advertise mechanisms and/or features which
1038 cannot meet their minimum security requirements, should not enter into
1039 or continue authentication exchanges which cannot meet their minimum
1040 security requirements, and should verify that completed authentication
1041 exchanges result in security services that meet their minimum security
1042 requirements. Note that each endpoint needs to independently verify
1043 that its security requirements are met.
1045 In order to detect downgrade attacks to the least (or less) secure
1046 mechanism supported, the client may discover the SASL mechanisms the
1047 server makes available both before the SASL authentication exchange
1048 and after the negotiated SASL security layer (with at least data
1049 integrity protection) has been installed through the protocol's
1050 mechanism discovery facility. If the client finds that the integrity
1051 protected list (the list obtained after the security layer was
1052 installed) contains a stronger mechanism than those in the previously
1053 obtained list, the client should assume the previously obtained list
1054 was modified by an attacker and should close the underlying transport
1057 The client's initiation of the SASL exchange, including the selection
1058 of a SASL mechanism, is done in the clear and may be modified by an
1059 active attacker. It is important for any new SASL mechanisms to be
1060 designed such that an active attacker cannot obtain an authentication
1061 with weaker security properties by modifying the SASL mechanism name
1062 and/or the challenges and responses.
1066 Melnikov & Zeilenga SASL [Page 19]
1068 INTERNET-DRAFT draft-ietf-sasl-rfc2222bis-15.txt 23 January 2006
1071 Multi-level negotiation of security features is prone to downgrade
1072 attack. Protocol designers should avoid offering higher level
1073 negotiation of security features in protocols (e.g., above SASL
1074 mechanism negotiation) and mechanism designers should avoid lower
1075 level negotiation of security features in mechanisms (e.g., below SASL
1076 mechanism negotiation).
1079 6.1.3. Replay Attacks
1081 Some mechanisms may be subject to replay attacks unless protected by
1082 external data security services (e.g., TLS).
1085 6.1.4. Truncation Attacks
1087 Most existing SASL security layers do not themselves offer protection
1088 against truncation attack. In a truncation attack, the active
1089 attacker causes the protocol session to be closed, causing a
1090 truncation of the possibly integrity protected data stream that leads
1091 to behavior of one or both the protocol peers that inappropriately
1092 benefits the attacker. Truncation attacks are fairly easy to defend
1093 against in connection-oriented application-level protocols. A
1094 protocol can defend against these attacks by ensuring that each
1095 information exchange has a clear final result and that each protocol
1096 session has a graceful closure mechanism, and that these are integrity
1100 6.1.5. Other Active Attacks
1102 When use of a security layer is negotiated by the authentication
1103 protocol exchange, the receiver should handle gracefully any protected
1104 data buffer larger than the defined/negotiated maximal size. In
1105 particular, it must not blindly allocate the amount of memory
1106 specified in the buffer size field, as this might cause the "out of
1107 memory" condition. If the receiver detects a large block, it should
1108 close the connection.
1111 6.2. Passive Attacks
1113 Many mechanisms are subject to various passive attacks, including
1114 simple eavesdropping of unprotected credential information as well as
1115 online and offline dictionary attacks of protected credential
1122 Melnikov & Zeilenga SASL [Page 20]
1124 INTERNET-DRAFT draft-ietf-sasl-rfc2222bis-15.txt 23 January 2006
1129 The secure or administratively permitted lifetimes of SASL mechanisms'
1130 security layers are finite. Cryptographic keys weaken as they are
1131 used and as time passes; the more time and/or cipher-text that a
1132 cryptanalyst has after the first use of the a key, the easier it is
1133 for the cryptanalyst to mount attacks on the key.
1135 Administrative limits on a security layer's lifetime may take the form
1136 of time limits expressed in X.509 certificates, Kerberos V tickets, or
1137 in directories, and are often desired. In practice one likely effect
1138 of administrative lifetime limits is that applications may find that
1139 security layers stop working in the middle of application protocol
1140 operation, such as, perhaps, during large data transfers. As the
1141 result of this the connection will be closed (see Section 3.7), which
1142 will result in unpleasant user experience.
1144 Re-keying (key renegotiation process) is a way of addressing the
1145 weakening of cryptographic keys. SASL framework does not itself
1146 provide for re-keying, SASL mechanisms may. Designers of future SASL
1147 mechanisms should consider providing re-keying services.
1149 Applications that wish to re-key SASL security layers where the
1150 mechanism does not provide for re-keying should reauthenticate the
1151 same IDs and replace the expired or soon-to-expire security layers.
1152 This approach requires support for reauthentication in the application
1153 protocols (see Section 3.8).
1156 6.4. Other Considerations
1158 Protocol designers and implementors should understand the security
1159 considerations of mechanisms so they may select mechanisms which are
1160 applicable to their needs.
1162 Distributed server implementations need to be careful in how they
1163 trust other parties. In particular, authentication secrets should
1164 only be disclosed to other parties that are trusted to manage and use
1165 those secrets in manner acceptable to disclosing party. Applications
1166 using SASL assume that SASL security layers providing data
1167 confidentiality are secure even when an attacker chooses the text to
1168 be protected by the security layer. Similarly applications assume
1169 that the SASL security layer is secure even if the attacker can
1170 manipulate the cipher-text output of the security layer. New SASL
1171 mechanisms are expected to meet these assumptions.
1173 Unicode security considerations [UTR36] apply to authorization
1174 identity strings, and well as UTF-8 [RFC3629] security considerations
1178 Melnikov & Zeilenga SASL [Page 21]
1180 INTERNET-DRAFT draft-ietf-sasl-rfc2222bis-15.txt 23 January 2006
1183 where UTF-8 is used. SASLprep [RFC4013] and StringPrep [RFC3454]
1184 security considerations also apply where used.
1187 7. IANA Considerations
1189 7.1. SASL Mechanism Registry
1191 SASL mechanism registry is maintained by IANA. The registry is
1192 currently available at
1193 <http://www.iana.org/assignments/sasl-mechanisms>.
1195 The purpose of this registry is not only to ensure uniqueness of
1196 values used to name SASL mechanisms, but to provide a definitive
1197 references to technical specifications detailing each SASL mechanism
1198 available for use on the Internet.
1200 There is no naming convention for SASL mechanisms; any name that
1201 conforms to the syntax of a SASL mechanism name can be registered.
1203 The procedure detailed in Section 7.1.1 is to be used for registration
1204 of a value naming a specific individual mechanism.
1206 The procedure detailed in Section 7.1.2 is to be used for registration
1207 of a value naming a family of related mechanisms.
1209 Comments may be included in the registry as discussed in Section 7.1.3
1210 and may be changed as discussed in Section 7.1.4.
1212 It is requested that the SASL mechanism registry be updated to reflect
1213 that this document provides the definitive technical specification for
1214 SASL and that this section provides the registration procedures for
1218 7.1.1. Mechanism Name Registration Procedure
1220 IANA will register new SASL mechanism names on a First Come First
1221 Served basis, as defined in BCP 26 [RFC2434]. IANA has the right to
1222 reject obviously bogus registration requests, but will perform no
1223 review of claims made in the registration form.
1225 Registration of a SASL mechanism is requested by filling in the
1228 Subject: Registration of SASL mechanism X
1230 SASL mechanism name (or prefix for the family):
1234 Melnikov & Zeilenga SASL [Page 22]
1236 INTERNET-DRAFT draft-ietf-sasl-rfc2222bis-15.txt 23 January 2006
1239 Security considerations:
1241 Published specification (recommended):
1243 Person & email address to contact for further information:
1245 Intended usage: (One of COMMON, LIMITED USE or OBSOLETE)
1247 Owner/Change controller:
1249 Note: (Any other information that the author deems relevant may be
1252 and sending it via electronic mail to IANA at <iana@iana.org>.
1254 While this registration procedures do not require expert review,
1255 authors of SASL mechanisms are encouraged to seek community review and
1256 comment whenever that is feasible. Authors may seek community review
1257 by posting a specification of their proposed mechanism as an
1258 Internet-Draft. SASL mechanisms intended for widespread use should be
1259 standardized through the normal IETF process, when appropriate.
1262 7.1.2. Family Name Registration Procedure
1264 As noted above, there is no general naming convention for SASL
1265 mechanisms. However, specifications may reserve a portion of the SASL
1266 mechanism namespace for a set of related SASL mechanisms, a "family"
1267 of SASL mechanisms. Each family of SASL mechanisms is identified by a
1268 unique prefix, such as X-. Registration of new SASL mechanism family
1269 names requires Expert Review as defined in BCP 26 [RFC2434].
1271 Registration of a SASL family name is requested by filling in the
1274 Subject: Registration of SASL mechanism family X
1276 SASL family name (or prefix for the family):
1278 Security considerations:
1280 Published specification (recommended):
1282 Person & email address to contact for further information:
1284 Intended usage: (One of COMMON, LIMITED USE or OBSOLETE)
1286 Owner/Change controller:
1290 Melnikov & Zeilenga SASL [Page 23]
1292 INTERNET-DRAFT draft-ietf-sasl-rfc2222bis-15.txt 23 January 2006
1295 Note: (Any other information that the author deems relevant may be
1298 and sending it via electronic mail to the IETF SASL mailing list at
1299 <ietf-sasl@imc.org> with copy to IANA at <iana@iana.org>. After
1300 allowing two weeks for community input on the IETF SASL mailing list,
1301 the expert will determine the appropriateness of the registration
1302 request and either approve or disappove the request with notice to
1303 requestor, the mailing list, and IANA.
1305 The review should focus on the appropriateness of the requested family
1306 name for the proposed use and the appropriateness of the proposed
1307 naming and registration plan for existing and future mechanism names
1308 in the family. The scope of this request review may entail
1309 consideration of relevant aspects of any provided technical
1310 specification, such as their IANA Considerations section. However
1311 this review is narrowly focused on the appropriateness of the
1312 requested registration and not on the overall soundness of any
1313 provided technical specification.
1315 Authors are encouraged to community review by posting the technical
1316 specification as an Internet-Draft and soliciting comment by posting
1317 to appropriate IETF mailing lists.
1320 7.1.3. Comments on SASL Mechanism Registrations
1322 Comments on a registered SASL mechanism/family should first be sent to
1323 the "owner" of the mechanism/family and/or to the <ietf-sasl@imc.org>
1326 Submitters of comments may, after a reasonable attempt to contact the
1327 owner, request IANA to attach their comment to the SASL mechanism
1328 registration itself by sending mail to <iana@iana.org>. At IANA's
1329 sole discretion, IANA may attach the comment to the SASL mechanism's
1333 7.1.4. Change Control
1335 Once a SASL mechanism registration has been published by IANA, the
1336 author may request a change to its definition. The change request
1337 follows the same procedure as the registration request.
1339 The owner of a SASL mechanism may pass responsibility for the SASL
1340 mechanism to another person or agency by informing IANA; this can be
1341 done without discussion or review.
1346 Melnikov & Zeilenga SASL [Page 24]
1348 INTERNET-DRAFT draft-ietf-sasl-rfc2222bis-15.txt 23 January 2006
1351 The IESG may reassign responsibility for a SASL mechanism. The most
1352 common case of this will be to enable changes to be made to mechanisms
1353 where the author of the registration has died, moved out of contact or
1354 is otherwise unable to make changes that are important to the
1357 SASL mechanism registrations may not be deleted; mechanisms which are
1358 no longer believed appropriate for use can be declared OBSOLETE by a
1359 change to their "intended usage" field; such SASL mechanisms will be
1360 clearly marked in the lists published by IANA.
1362 The IESG is considered to be the owner of all SASL mechanisms which
1363 are on the IETF standards track.
1366 7.2. Registration Changes
1368 It is requested that IANA update the SASL mechanisms registry as
1371 1) Change the "Intended usage" of the KERBEROS_V4 and SKEY mechanism
1372 registrations to OBSOLETE.
1374 2) Change the "Published specification" of the EXTERNAL mechanism to
1375 this document as indicated below:
1377 Subject: Updated Registration of SASL mechanism EXTERNAL
1378 Family of SASL mechanisms: NO
1379 SASL mechanism name: EXTERNAL
1380 Security considerations: See A.3 of RFC XXXX
1381 Published specification (optional, recommended): RFC XXXX
1382 Person & email address to contact for further information:
1383 Alexey Melnikov <Alexey.Melnikov@isode.com>
1384 Intended usage: COMMON
1385 Owner/Change controller: IESG <iesg@ietf.org>
1386 Note: Updates existing entry for EXTERNAL
1391 [[Note to the RFC Editor: please replace the citation tags used in
1392 referencing Internet-Drafts with tags of the form RFCnnnn where
1395 8.1. Normative References
1397 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
1398 Requirement Levels", BCP 14 (also RFC 2119), March 1997.
1402 Melnikov & Zeilenga SASL [Page 25]
1404 INTERNET-DRAFT draft-ietf-sasl-rfc2222bis-15.txt 23 January 2006
1407 [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an
1408 IANA Considerations Section in RFCs", BCP 26 (also RFC
1409 2434), October 1998.
1411 [RFC2743] Linn, J., "Generic Security Service
1412 Application Program Interface, Version 2, Update 1", RFC
1415 [RFC3454] Hoffman, P. and M. Blanchet, "Preparation of
1416 Internationalized Strings ('stringprep')", RFC 3454,
1419 [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO
1420 10646", RFC 3629 (also STD 63), November 2003.
1422 [RFC4013] Zeilenga, K., "SASLprep: Stringprep Profile for User
1423 Names and Passwords", RFC 4013, February 2005.
1425 [RFC4234] Crocker, D. and P. Overell, "Augmented BNF for Syntax
1426 Specifications: ABNF", RFC 4234, October 2005.
1428 [ASCII] Coded Character Set--7-bit American Standard Code for
1429 Information Interchange, ANSI X3.4-1986.
1431 [Unicode] The Unicode Consortium, "The Unicode Standard, Version
1432 3.2.0" is defined by "The Unicode Standard, Version 3.0"
1433 (Reading, MA, Addison-Wesley, 2000. ISBN 0-201-61633-5),
1434 as amended by the "Unicode Standard Annex #27: Unicode
1435 3.1" (http://www.unicode.org/reports/tr27/) and by the
1436 "Unicode Standard Annex #28: Unicode 3.2"
1437 (http://www.unicode.org/reports/tr28/).
1439 [CharModel] Whistler, K. and M. Davis, "Unicode Technical Report
1440 #17, Character Encoding Model", UTR17,
1441 <http://www.unicode.org/unicode/reports/tr17/>, August
1444 [Glossary] The Unicode Consortium, "Unicode Glossary",
1445 <http://www.unicode.org/glossary/>.
1448 8.2. Informative References
1450 [RFC2246] Dierks, T. and, C. Allen, "The TLS Protocol Version
1451 1.0", RFC 2246, January 1999.
1453 [RFC2401] Kent, S., and R. Atkinson, "Security Architecture for
1454 the Internet Protocol", RFC 2401, November 1998.
1458 Melnikov & Zeilenga SASL [Page 26]
1460 INTERNET-DRAFT draft-ietf-sasl-rfc2222bis-15.txt 23 January 2006
1463 [RFC3548] Josefsson, S., "The Base16, Base32, and Base64 Data
1464 Encodings", RFC 3548, July 2003.
1466 [TLS] Dierks, T. and, E. Rescorla, "The TLS Protocol Version
1467 1.1", draft-ietf-tls-rfc2246-bis-xx.txt, a work in
1470 [SASL-GSSAPI] Melnikov, A. (Editor), "SASL GSSAPI mechanisms",
1471 draft-ietf-sasl-gssapi-XX.txt, a work in progress.
1473 [UTR36] Davis, M., "(Draft) Unicode Technical
1474 Report #36, Character Encoding Model", UTR17,
1475 <http://www.unicode.org/unicode/reports/tr36/>, February
1478 [CRAM-MD5] Nerenberg, L., "The CRAM-MD5 SASL Mechanism",
1479 draft-ietf-sasl-crammd5-xx.txt, a work in progress.
1481 [DIGEST-MD5] Leach, P., C. Newman, and A. Melnikov, "Using Digest
1482 Authentication as a SASL Mechanism",
1483 draft-ietf-sasl-rfc2831bis-xx.txt, a work in progress.
1491 5 Castle Business Village
1494 TW12 2BX, United Kingdom
1496 Email: Alexey.Melnikov@isode.com
1497 URI: http://www.melnikov.ca/
1503 Email: Kurt@OpenLDAP.org
1508 This document is a revision of RFC 2222 written by John Myers.
1510 This revision is a product of the IETF Simple Authentication and
1514 Melnikov & Zeilenga SASL [Page 27]
1516 INTERNET-DRAFT draft-ietf-sasl-rfc2222bis-15.txt 23 January 2006
1519 Security Layer (SASL) Working Group.
1521 The following individuals contributed significantly to this revision:
1522 Abhijit Menon-Sen, Hallvard B Furuseth, Jeffrey Hutzelman, John Myers,
1523 Luke Howard, Magnus Nystrom, Nicolas Williams, Peter Saint-Andre, RL
1524 'Bob' Morgan, Rob Siemborski, Sam Hartman, Simon Josefsson, Tim Alsop,
1528 Appendix A. The SASL EXTERNAL Mechanism
1530 This appendix is normative.
1532 The EXTERNAL mechanism allows a client to request the server to use
1533 credentials established by means external to the mechanism to
1534 authenticate the client. The external means may be, for instance, IP
1535 Security [RFC2401] or TLS [RFC2246] services. In absence of some
1536 apriori agreement between the client and the server, the client cannot
1537 make any assumption as to what external means the server has used to
1538 obtain the client's credentials, nor make an assumption as to the form
1539 of credentials. For example, the client cannot assume the server will
1540 use the credentials the client has established via TLS.
1542 A.1. EXTERNAL Technical Specification
1544 The name of this mechanism is "EXTERNAL".
1546 The mechanism does not provide a security layer.
1548 The mechanism is capable of transferring an authorization identity
1549 string. If empty, the client is requesting to act as the identity the
1550 server has associated with the client's credentials. If non-empty,
1551 the client is requesting to act as the identity represented by the
1554 The client is expected to send data first in the authentication
1555 exchange. Where the client does not provide an initial response data
1556 in its request to initiate the authentication exchange, the server is
1557 to respond to the request with an empty initial challenge and then the
1558 client is to provide its initial response.
1560 The client sends the initial response containing the UTF-8 [RFC3629]
1561 encoding of the requested authorization identity string. This
1562 response is non-empty when the client is requesting to act as the
1563 identity represented by the (non-empty) string. This response is
1564 empty when the client is requesting to act as the identity the server
1565 associated with its authentication credentials.
1570 Melnikov & Zeilenga SASL [Page 28]
1572 INTERNET-DRAFT draft-ietf-sasl-rfc2222bis-15.txt 23 January 2006
1575 The syntax of the initial response is specified as a value of the
1576 <extern-initial-resp> production detailed below using the Augmented
1577 Backus-Naur Form (ABNF) [RFC4234] notation.
1579 external-initial-resp = authz-id-string
1580 authz-id-string = *( UTF8-char-no-nul )
1581 UTF8-char-no-nul = UTF8-1-no-nul / UTF8-2 / UTF8-3 / UTF8-4
1582 UTF8-1-no-nul = %x01-7F
1584 where the <UTF8-2>, <UTF8-3>, and <UTF8-4> productions are as defined
1587 There are no additional challenges and responses.
1589 Hence, the server is to return the outcome of the authentication
1592 The exchange fails if
1593 - the client has not established its credentials via external means,
1594 - the client's credentials are inadequate,
1595 - The client provided an empty authorization identity string and the
1596 server is unwilling or unable to associate an authorization identity
1597 with the client's credentials,
1598 - The client provided a non-empty authorization identity string which
1599 is invalid per the syntax requirements of the applicable application
1600 protocol specification,
1601 - The client provided a non-empty authorization identity string
1602 representing an identity which the client is not allowed to act as,
1604 - the server is unwilling or unable to provide service to the client
1605 for any other reason.
1607 Otherwise the exchange is successful. When indicating a successful
1608 outcome, additional data is not provided.
1611 A.2. SASL EXTERNAL Examples
1613 This section provides examples of EXTERNAL authentication exchanges.
1614 The examples are intended to help the readers under the above text.
1615 The examples are not definitive. The Application Configuration
1616 Access Protocol (ACAP) [RFC2244] is used in the examples.
1618 The first example shows use of EXTERNAL with an empty authorization
1619 identity. In this example, the initial response is not sent in the
1620 client's request to initiate authentication exchange.
1622 S: * ACAP (SASL "DIGEST-MD5")
1626 Melnikov & Zeilenga SASL [Page 29]
1628 INTERNET-DRAFT draft-ietf-sasl-rfc2222bis-15.txt 23 January 2006
1632 S: a001 OK "Begin TLS negotiation now"
1633 <TLS negotiation, further commands are under TLS layer>
1634 S: * ACAP (SASL "DIGEST-MD5" "EXTERNAL")
1635 C: a002 AUTHENTICATE "EXTERNAL"
1638 S: a002 OK "Authenticated"
1640 In second example shows use of EXTERNAL with an authorization identity
1641 of "fred@example.com". In this example, the initial response is sent
1642 with the client's request to initiate the authentication exchange.
1643 This saves a round-trip.
1645 S: * ACAP (SASL "DIGEST-MD5")
1647 S: a001 OK "Begin TLS negotiation now"
1648 <TLS negotiation, further commands are under TLS layer>
1649 S: * ACAP (SASL "DIGEST-MD5" "EXTERNAL")
1650 C: a002 AUTHENTICATE "EXTERNAL" {16+}
1652 S: a002 NO "Cannot assume requested authorization identity"
1655 A.3. Security Considerations
1657 The EXTERNAL mechanism provides no security protection; it is
1658 vulnerable to spoofing by either client or server, active attack, and
1659 eavesdropping. It should only be used when adequate security services
1660 have been established.
1664 Appendix B. Changes since RFC 2222
1666 This appendix is non-normative.
1668 The material in RFC 2222 was significantly rewritten in the production
1671 RFC 2222, by not stating the authorization identity string was a
1672 string of Unicode characters, let alone character data, implied the
1673 authorization identity string was a string of octets.
1675 - The authorization identity string is now defined as a string of
1676 Unicode characters. The NUL (U+0000) character is prohibited.
1677 While protocol specifications are responsible for defining the
1678 authorization identity form, as well as the Unicode string syntax
1682 Melnikov & Zeilenga SASL [Page 30]
1684 INTERNET-DRAFT draft-ietf-sasl-rfc2222bis-15.txt 23 January 2006
1687 and related semantics, mechanism specifications are responsible for
1688 defining how the Unicode string is carried in the authentication
1690 - Deleted "If so, when the client does not send data first, the
1691 initial challenge MUST be specified as being an empty challenge."
1693 The following technical change was made to the EXTERNAL mechanism:
1695 - The authorization identity string is to be UTF-8 encoded.
1697 It is noted that protocol and mechanism specification requirements
1698 have been significant tightened. Existing protocol and mechanism
1699 specifications will need to be updated to meet these requirements.
1704 Intellectual Property Rights
1706 The IETF takes no position regarding the validity or scope of any
1707 Intellectual Property Rights or other rights that might be claimed to
1708 pertain to the implementation or use of the technology described in
1709 this document or the extent to which any license under such rights
1710 might or might not be available; nor does it represent that it has
1711 made any independent effort to identify any such rights. Information
1712 on the procedures with respect to rights in RFC documents can be found
1713 in BCP 78 and BCP 79.
1715 Copies of IPR disclosures made to the IETF Secretariat and any
1716 assurances of licenses to be made available, or the result of an
1717 attempt made to obtain a general license or permission for the use of
1718 such proprietary rights by implementers or users of this specification
1719 can be obtained from the IETF on-line IPR repository at
1720 http://www.ietf.org/ipr.
1722 The IETF invites any interested party to bring to its attention any
1723 copyrights, patents or patent applications, or other proprietary
1724 rights that may cover technology that may be required to implement
1725 this standard. Please address the information to the IETF at
1732 Copyright (C) The Internet Society (2006).
1734 This document is subject to the rights, licenses and restrictions
1738 Melnikov & Zeilenga SASL [Page 31]
1740 INTERNET-DRAFT draft-ietf-sasl-rfc2222bis-15.txt 23 January 2006
1743 contained in BCP 78, and except as set forth therein, the authors
1744 retain all their rights.
1746 This document and the information contained herein are provided on an
1747 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
1748 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
1749 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
1750 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
1751 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
1752 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
1794 Melnikov & Zeilenga SASL [Page 32]