7 Network Working Group A. Melnikov
8 Internet Draft May 2003
9 Document: draft-ietf-sasl-rfc2222bis-00.txt
13 Simple Authentication and Security Layer (SASL)
17 This document is an Internet Draft and is in full conformance with
18 all provisions of Section 10 of RFC 2026.
20 Internet Drafts are working documents of the Internet Engineering
21 Task Force (IETF), its Areas, and its Working Groups. Note that
22 other groups may also distribute working documents as Internet
23 Drafts. Internet Drafts are draft documents valid for a maximum of
24 six months. Internet Drafts may be updated, replaced, or obsoleted
25 by other documents at any time. It is not appropriate to use
26 Internet Drafts as reference material or to cite them other than as
29 The list of current Internet-Drafts can be accessed at
30 http://www.ietf.org/ietf/1id-abstracts.txt
32 The list of Internet-Draft Shadow Directories can be accessed at
33 http://www.ietf.org/shadow.html.
35 A revised version of this draft document will be submitted to the RFC
36 editor as a Draft Standard for the Internet Community. Discussion
37 and suggestions for improvement are requested. Distribution of this
58 A. Melnikov FORMFEED[Page i]
64 Internet DRAFT SASL 18 May 2003
69 SASL provides a method for adding authentication support with an
70 optional security layer to connection-based protocols. It also
71 describes a structure for authentication mechanisms. The result is
72 an abstraction layer between protocols and authentication mechanisms
73 such that any SASL-compatible authentication mechanism can be used
74 with any SASL-compatible protocol.
76 This document describes how a SASL authentication mechanism is
77 structured, how a protocol adds support for SASL, defines the
78 protocol for carrying a security layer over a connection, and defines
79 the EXTERNAL SASL authentication mechanism.
81 2. Organization of this document
83 2.1. How to read this document
85 This document is written to serve two different audiences, protocol
86 designers using this specification to support authentication in their
87 protocol, and implementors of clients or servers for those protocols
88 using this specification.
90 The sections "Overview", "Authentication Mechanisms", "Protocol
91 Profile Requirements", "Specific Issues", and "Security
92 Considerations" cover issues that protocol designers need to
93 understand and address in profiling this specification for use in a
96 Implementors of a protocol using this specification need the
97 protocol-specific profiling information in addition to the
98 information in this document.
100 2.2. Conventions used in this document
102 In examples, "C:" and "S:" indicate lines sent by the client and
105 The key words "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", and "MAY"
106 in this document are to be interpreted as defined in "Key words for
107 use in RFCs to Indicate Requirement Levels" [KEYWORDS].
111 The Simple Authentication and Security Layer (SASL) is a method for
112 adding authentication support to connection-based protocols.
114 The SASL specification has three layers, as indicated in the diagram
118 A. Melnikov FORMFEED[Page 2]
124 Internet DRAFT SASL 18 May 2003
127 below. At the top, a protocol definition using SASL specifies a
128 profile, including a command for identifying and authenticating a
129 user to a server and for optionally negotiating a security layer for
130 subsequent protocol interactions. At the bottom, a SASL mechanism
131 definition specifies an authentication mechanism. The SASL
132 framework, specified by this document, constrains the behavior of
133 protocol profiles and mechanisms, separating protocol from mechanism
134 and defining how they interact.
136 SMTP Protocol LDAP Protocol Etc
137 Profile Profile . . .
143 EXTERNAL DIGEST-MD5 Etc
144 SASL mechanism SASL mechanism . . .
146 This separation between the definition of protocols and the
147 definition of authentication mechanisms is crucial. It permits an
148 authentication mechanism to be defined once, making it usable by any
149 SASL protocol profiles. In many implementations, the same SASL
150 mechanism code is used for multiple protocols.
152 4. Authentication mechanisms
154 SASL mechanisms are named by strings, from 1 to 20 characters in
155 length, consisting of upper-case letters, digits, hyphens, and/or
156 underscores. SASL mechanism names must be registered with the IANA.
157 IETF Standards Track documents may override this registration
158 requirement by reserving a portion of the SASL mechanism namespace
159 for their own use; the GSSAPI mechanism specification [SASL-GSSAPI]
160 does this. Procedures for registering new SASL mechanisms are given
161 in the section "Registration procedures".
163 The "sasl-mech" rule below defines the syntax of a SASL mechanism
164 name. This uses the augmented Backus-Naur Form (BNF) notation as
165 specified in [ABNF] and the ABNF core rules as specified in Appendix
166 A of the ABNF specification [ABNF].
168 sasl-mech = 1*20mech-char
169 mech-char = %x41-5A / DIGIT / "-" / "_"
170 ; mech names restricted to uppercase letters,
171 ; digits, "-" and "_"
178 A. Melnikov FORMFEED[Page 3]
184 Internet DRAFT SASL 18 May 2003
187 4.1. Authentication protocol exchange
189 A SASL mechanism is responsible for conducting an authentication
190 protocol exchange. This consists of a series of server challenges
191 and client responses, the contents of which are specific to and
192 defined by the mechanism. To the protocol, the challenges and
193 responses are opaque binary tokens of arbitrary length. The
194 protocol's profile then specifies how these binary tokens are then
195 encoded for transfer over the connection.
197 After receiving an authentication command or any client response, a
198 server mechanism may issue a challenge, indicate failure, or indicate
199 completion. The server mechanism MAY return additional data with a
200 completion indication. The protocol's profile specifies how each of
201 these is then represented over the connection.
203 After receiving a challenge, a client mechanism may issue a response
204 or abort the exchange. The protocol's profile specifies how each of
205 these is then represented over the connection.
207 During the authentication protocol exchange, the mechanism performs
208 authentication, transmits an authorization identity (frequently known
209 as a userid) from the client to server, and negotiates the use of a
210 mechanism-specific security layer. If the use of a security layer is
211 agreed upon, then the mechanism must also define or negotiate the
212 maximum security layer buffer size that each side is able to receive.
214 4.2. Authorization identities and proxy authentication
216 An authorization identity is a string of zero or more ISO 10646
217 [ISO-10646] coded characters. The NUL (U+0000) character is not
218 permitted in authorization identities. The meaning of an
219 authorization identity of the empty string (zero lenght) is defined
220 below in this section. The authorization identity is used by the
221 server as the primary identity for making access policy decisions.
223 The character encoding scheme used for transmitting an authorization
224 identity over protocol is specified in each authentication mechanism
225 (with the authentication mechanism's blob being further
226 restricted/encoded by the protocol profile). Per IETF character set
227 policy [CHARSET-POLICY], authentication mechanisms SHOULD encode
228 these and other strings in UTF-8 [UTF-8]. While some legacy
229 mechanisms are incapable of transmitting an authoriation identity
230 other than the empty string, newly defined mechanisms are expected to
231 be capable of carrying the entire repertoire of Unicode Normalization
232 form KC [UNICODE-NORMALIZATION] (with the exception of the NUL
238 A. Melnikov FORMFEED[Page 4]
244 Internet DRAFT SASL 18 May 2003
247 The identity derived from the client's authentication credentials is
248 known as the "authentication identity". With any mechanism,
249 transmitting an authorization identity of the empty string directs
250 the server to derive an authorization identity from the client's
251 authentication identity.
253 If the authorization identity transmitted during the authentication
254 protocol exchange is not the empty string, this is typically referred
255 to as "proxy authentication". This feature permits agents such as
256 proxy servers to authenticate using their own credentials, yet
257 request the access privileges of the identity for which they are
260 The server makes an implementation defined policy decision as to
261 whether the authentication identity is permitted to have the access
262 privileges of the authorization identity and whether the
263 authorization identity is permitted to receive service. If it is
264 not, the server indicates failure of the authentication protocol
267 As a client might not have the same information as the server,
268 clients SHOULD NOT themselves try to derive authorization identities
269 from authentication identities when clients could instead transmit an
270 authorization identity of the empty string.
272 <<Is transmitting an empty authorization id is the same as not
273 transmitting it at all? Why would we encourage two ways to do the
276 The server SHOULD verify the correctness of a received authorization
277 identity. For example, an IMAP [RFC 3501] server will prepare the
278 received authorization identity using the "SASLPrep" profile
279 [SASLPrep] of the "stringprep" algorithm [StringPrep]. If the
280 preparation of the authorization identity fails or results in an
281 empty string, the server MUST fail the authentication exchange. The
282 only exception to this rule is when the received authorization
283 identity is the empty string.
287 If use of a security layer is negotiated by the authentication
288 protocol exchange, the security layer is applied to all subsequent
289 data sent over the connection. The security layer takes effect
290 immediately following the last response of the authentication
291 exchange for data sent by the client and the completion indication
292 for data sent by the server.
294 Once the security layer is in effect, the protocol stream is
298 A. Melnikov FORMFEED[Page 5]
304 Internet DRAFT SASL 18 May 2003
307 processed by the security layer into buffers of security encoded
308 data. Each buffer of security encoded data is transferred over the
309 connection as a stream of octets prepended with a four octet field in
310 network byte order that represents the length of the following
311 buffer. The length of the security encoded data buffer MUST be no
312 larger than the maximum size that was either defined in the mechanism
313 specification or negotiated by the other side during the
314 authentication protocol exchange. Upon the receipt of a data buffer
315 which is larger than the defined/negotiated maximal buffer size, the
316 receiver SHOULD close the connection. This might be a sign of an
317 attack or a buggy implementation.
319 4.4. Character string issues
321 Per IETF character set policy [CHARSET-POLICY], authentication
322 mechanisms SHOULD encode character strings in UTF-8 [UTF-8]. In
323 order to avoid noninteroperability due to differing normalizations,
324 when a mechanism specifies that a string authentication identity or
325 password used as input to a cryptographic function (or used for
326 comparison) it SHOULD specify that the string first be prepared using
327 the "SASLPrep" profile [SASLPrep], of the "stringprep" algorithm
328 [StringPrep]. This should be done by both the client (upon getting
329 user input or retrieving a value from configuration) and by the
330 server (upon receiving the value from the client). If preparation
331 fails or results in an empty string, the client/server SHALL fail the
332 authentication exchange.
335 5. Protocol profile requirements
337 In order to use this specification, a protocol definition MUST supply
338 the following information:
340 A service name, to be selected from the IANA registry of "service"
341 elements for the GSSAPI host-based service name form. [GSSAPI] This
342 service name is made available to the authentication mechanism.
344 The registry is available at the URL
345 "http://www.iana.org/assignments/gssapi-service-names" A definition
346 of the command to initiate the authentication protocol exchange.
347 This command must have as a parameter the name of the mechanism being
348 selected by the client.
350 The command SHOULD have an optional parameter giving an initial
351 response. This optional parameter allows the client to avoid a round
352 trip when using a mechanism which is defined to have the client send
353 data first. When this initial response is sent by the client and the
354 selected mechanism is defined to have the server start with an
358 A. Melnikov FORMFEED[Page 6]
364 Internet DRAFT SASL 18 May 2003
367 initial challenge, the command fails. See section 6.1 of this
368 document for further information. A definition of the method by
369 which the authentication protocol exchange is carried out, including
370 how the challenges and responses are encoded, how the server
371 indicates completion or failure of the exchange, how the client
372 aborts an exchange, and how the exchange method interacts with any
373 line length limits in the protocol.
375 The command SHOULD have a method for the server to include an
376 optional challenge with a success notification. This allows the
377 server to avoid a round trip when using a mechanism which is defined
378 to have the server send additional data along with the indication of
379 successful completion. See section 6.2 of this document for further
382 Identification of the octet where any negotiated security layer
383 starts to take effect, in both directions.
385 In addition, a protocol profile SHOULD specify a mechanism through
386 which a client may obtain the names of the SASL mechanisms available
387 to it. This is typically done through the protocol's extensions or
388 capabilities mechanism.
390 A protocol profile MAY further refine the definition of an
391 authorization identity by adding additional syntactic restrictions
392 and protocol-specific semantics.
394 A protocol profile SHOULD NOT attempt to amend the definition of
395 mechanisms or make mechanism-specific encodings. This breaks the
396 separation between protocol and mechanism that is fundamental to the
401 6.1. Client sends data first
403 Some mechanisms specify that the first data sent in the
404 authentication protocol exchange is from the client to the server.
406 If a protocol's profile permits the command which initiates an
407 authentication protocol exchange to contain an initial client
408 response, this parameter SHOULD be used with such mechanisms.
410 If the initial client response parameter is not given, or if a
411 protocol's profile does not permit the command which initiates an
412 authentication protocol exchange to contain an initial client
413 response, then the server issues a challenge with no data. The
414 client's response to this challenge is then used as the initial
418 A. Melnikov FORMFEED[Page 7]
424 Internet DRAFT SASL 18 May 2003
427 client response. (The server then proceeds to send the next
428 challenge, indicates completion, or indicates failure.)
430 6.2. Server returns success with additional data
432 Some mechanisms may specify that additional data be sent to the
433 client along with an indication of successful completion of the
434 exchange. This data would, for example, authenticate the server to
437 If a protocol's profile does not permit this additional data to be
438 returned with a success indication, then the server issues the data
439 as a server challenge, without an indication of successful
440 completion. The client then responds with no data. After receiving
441 this empty response, the server then indicates successful completion
442 (with no additional data).
444 Client implementors should be aware of an additional failure case
445 that might occur when the profile supports sending the additional
446 data with success. Imagine that an active attacker is trying to
447 impersonate the server and sends a faked data, that should be used to
448 authenticate the server to the client, with success. (A similar
449 situation can happen when the server has a bug and produces the wrong
450 response). After checking the data the client will think that the
451 authentication exchange has failed, however the server will think
452 that the authentication exchange has completed successfully. At this
453 point the client can't abort the authentication exchange, it SHOULD
454 close the connection instead. However if the profile didn't support
455 sending of additional data with success, the client could have
456 aborted the exchange.
458 <<Should I add a flow diagram here or is it clear from the
461 6.3. Multiple authentications
463 Unless otherwise stated by the protocol's profile, only one
464 successful SASL negotiation may occur in a protocol session. In this
465 case, once an authentication protocol exchange has successfully
466 completed, further attempts to initiate an authentication protocol
469 In the case that a profile explicitly permits multiple successful
470 SASL negotiations to occur, then in no case may multiple security
471 layers be simultaneously in effect. If a security layer is in effect
472 and a subsequent SASL negotiation selects no security layer, the
473 original security layer remains in effect. If a security layer is in
474 effect and a subsequent SASL negotiation selects a second security
478 A. Melnikov FORMFEED[Page 8]
484 Internet DRAFT SASL 18 May 2003
487 layer, then the second security layer replaces the first.
489 7. The EXTERNAL mechanism
491 The mechanism name associated with external authentication is
494 The client sends an initial response with the UTF-8 encoding of the
495 authorization identity. The form of the authorization identity is
496 further restricted by the application-level protocol's SASL profile.
498 The server uses information, external to SASL, to determine whether
499 the client is authorized to authenticate as the authorization
500 identity. If the client is so authorized, the server indicates
501 successful completion of the authentication exchange; otherwise the
502 server indicates failure.
504 The system providing this external information may be, for example,
507 If the client sends the empty string as the authorization identity
508 (thus requesting the authorization identity be derived from the
509 client's authentication credentials), the authorization identity is
510 to be derived from authentication credentials which exist in the
511 system which is providing the external authentication.
515 The following syntax specification uses the augmented Backus-Naur
516 Form (BNF) notation as specified in [ABNF]. This uses the ABNF core
517 rules as specified in Appendix A of the ABNF specification [ABNF].
518 Non-terminals referenced but not defined below are as defined by
521 The "initial-response" rule below defines the initial response sent
522 from client to server.
524 initial-response = *( UTF8-char-no-null )
526 UTF8-char-no-null = UTF8-1-no-null / UTF8-2 / UTF8-3 / UTF8-4
528 UTF8-1-no-null = %x01-7F
533 The following is an example of an EXTERNAL authentication in the SMTP
534 protocol [SMTP-AUTH]. In this example, the client is proxy
538 A. Melnikov FORMFEED[Page 9]
544 Internet DRAFT SASL 18 May 2003
547 authenticating, sending the authorization id "fred". The server has
548 determined the client's identity through IPsec and has a security
549 policy that permits that identity to proxy authenticate as any other
552 To the protocol profile, the four octet sequence "fred" is an opaque
553 binary blob. The SASL protocol profile for SMTP specifies that
554 server challenges and client responses are encoded in BASE64; the
555 BASE64 encoding of "fred" is "ZnJlZA==".
557 S: 220 smtp.example.com ESMTP server ready
558 C: EHLO jgm.example.com
559 S: 250-smtp.example.com
560 S: 250 AUTH DIGEST-MD5 EXTERNAL
561 C: AUTH EXTERNAL ZnJlZA==
562 S: 235 Authentication successful.
564 8. IANA Considerations
566 Registration of a SASL mechanism is done by filling in the template
567 in section 8.4 and sending it in to iana@iana.org. IANA has the
568 right to reject obviously bogus registrations, but will perform no
569 review of claims made in the registration form.
571 There is no naming convention for SASL mechanisms; any name that
572 conforms to the syntax of a SASL mechanism name can be registered.
573 An IETF Standards Track document may reserve a portion of the SASL
574 mechanism namespace for its own use, amending the registration rules
575 for that portion of the namespace.
577 While the registration procedures do not require it, authors of SASL
578 mechanisms are encouraged to seek community review and comment
579 whenever that is feasible. Authors may seek community review by
580 posting a specification of their proposed mechanism as an internet-
581 draft. SASL mechanisms intended for widespread use should be
582 standardized through the normal IETF process, when appropriate.
584 8.1. Comments on SASL mechanism registrations
586 Comments on registered SASL mechanisms should first be sent to the
587 "owner" of the mechanism. Submitters of comments may, after a
588 reasonable attempt to contact the owner, request IANA to attach their
589 comment to the SASL mechanism registration itself. If IANA approves
590 of this the comment will be made accessible in conjunction with the
591 SASL mechanism registration itself.
598 A. Melnikov FORMFEED[Page 10]
604 Internet DRAFT SASL 18 May 2003
607 8.2. Location of registered SASL mechanism list
609 SASL mechanism registrations are available at the URL
610 "http://www.iana.org/assignments/sasl-mechanisms" The SASL mechanism
611 description and other supporting material may also be published as an
612 Informational RFC by sending it to "rfc-editor@rfc-editor.org"
613 (please follow the instructions to RFC authors [RFC-INSTRUCTIONS]).
617 Once a SASL mechanism registration has been published by IANA, the
618 author may request a change to its definition. The change request
619 follows the same procedure as the registration request.
621 The owner of a SASL mechanism may pass responsibility for the SASL
622 mechanism to another person or agency by informing IANA; this can be
623 done without discussion or review.
625 The IESG may reassign responsibility for a SASL mechanism. The most
626 common case of this will be to enable changes to be made to
627 mechanisms where the author of the registration has died, moved out
628 of contact or is otherwise unable to make changes that are important
631 SASL mechanism registrations may not be deleted; mechanisms which are
632 no longer believed appropriate for use can be declared OBSOLETE by a
633 change to their "intended use" field; such SASL mechanisms will be
634 clearly marked in the lists published by IANA.
636 The IESG is considered to be the owner of all SASL mechanisms which
637 are on the IETF standards track.
639 8.4. Registration template
642 Subject: Registration of SASL mechanism X
646 Security considerations:
648 Published specification (optional, recommended):
650 Person & email address to contact for further information:
654 (One of COMMON, LIMITED USE or OBSOLETE)
658 A. Melnikov FORMFEED[Page 11]
664 Internet DRAFT SASL 18 May 2003
667 Owner/Change controller:
669 (Any other information that the author deems interesting may be
670 added below this line.)
673 8.5. The EXTERNAL mechanism registration
675 It is requested that the SASL Mechanism registry [IANA-SASL] entry
676 for the EXTERNAL mechanism be updated to reflect that this document
677 now provides its technical specification.
679 To: iana@iana.org Subject: Updated Registration of SASL mechanism
682 SASL mechanism name: EXTERNAL
684 Security considerations: See RFC XXXX, section 10.
686 Published specification (optional, recommended): RFC XXXX
688 Person & email address to contact for further information:
689 Alexey Melnikov <mel@messagingdirect.com>
691 Intended usage: COMMON
693 Owner/Change controller: IESG <iesg@ietf.org>
695 Note: Updates existing entry for EXTERNAL
699 9.1. Normative References
701 [ABNF] Crocker, Overell, "Augmented BNF for Syntax Specifications:
702 ABNF", RFC 2234, November 1997
704 [CHARSET-POLICY] Alvestrand, "IETF Policy on Character Sets and
705 Languages", RFC 2277, January 1998
707 [GSSAPI] Linn, "Generic Security Service Application Program
708 Interface, Version 2, Update 1", RFC 2743, January 2000
710 [ISO-10646] "Universal Multiple-Octet Coded Character Set (UCS) -
711 Architecture and Basic Multilingual Plane", ISO/IEC 10646-1 : 1993.
713 [KEYWORDS] Bradner, "Key words for use in RFCs to Indicate
714 Requirement Levels", RFC 2119, March 1997
718 A. Melnikov FORMFEED[Page 12]
724 Internet DRAFT SASL 18 May 2003
727 [Stringprep] P. Hoffman, M. Blanchet, "Preparation of
728 Internationalized Strings ("stringprep")", RFC 3454, December 2002.
730 [SASLPrep] Zeilenga, K., "SASLprep: Stringprep profile for user names
731 and passwords", Work in progress, draft-ietf-sasl-saslprep-XX.txt.
733 [UNICODE-NORMALIZATION] Davis, Durst, "Unicode Standard Annex #15:
734 Unicode Normalization Forms", March 2001,
735 http://www.unicode.org/unicode/reports/tr15/
737 [UTF-8] Yergeau, "UTF-8, a transformation format of ISO 10646", work
738 in progress (draft-yergeau-rfc2279bis-XX) that replaces RFC 2279,
741 9.2. Informative References
743 <<Update the reference below>> [SASL-GSSAPI] Myers, "SASL GSSAPI
744 mechanisms", draft-ietf-cat-sasl-gssapi-XX.txt, September 2000
746 [SASL-OTP] Newman, "The One-Time-Password SASL Mechanism", RFC 2444,
749 [SMTP-AUTH] Myers, "SMTP Service Extension for Authentication", RFC
752 [RFC-INSTRUCTIONS] Postel, Reynolds, "Instructions to RFC Authors",
753 RFC 2223, October 1997
755 [IANA-SASL] IANA, "SIMPLE AUTHENTICATION AND SECURITY LAYER (SASL)
756 MECHANISMS", http://www.iana.org/assignments/sasl-mechanisms.
758 10. Security considerations
760 Security issues are discussed throughout this memo.
762 The mechanisms that support integrity protection are designed such
763 that the negotiation of the security layer and authorization identity
764 is integrity protected. When the client selects a security layer
765 with at least integrity protection, this protects against an active
766 attacker hijacking the connection and modifying the authentication
767 exchange to negotiate a plaintext connection.
769 When a server or client supports multiple authentication mechanisms,
770 each of which has a different security strength, it is possible for
771 an active attacker to cause a party to use the least secure mechanism
772 supported. To protect against this sort of attack, a client or
773 server which supports mechanisms of different strengths should have a
774 configurable minimum strength that it will use. It is not sufficient
778 A. Melnikov FORMFEED[Page 13]
784 Internet DRAFT SASL 18 May 2003
787 for this minimum strength check to only be on the server, since an
788 active attacker can change which mechanisms the client sees as being
789 supported, causing the client to send authentication credentials for
790 its weakest supported mechanism.
792 The client's selection of a SASL mechanism is done in the clear and
793 may be modified by an active attacker. It is important for any new
794 SASL mechanisms to be designed such that an active attacker cannot
795 obtain an authentication with weaker security properties by modifying
796 the SASL mechanism name and/or the challenges and responses.
798 Any protocol interactions prior to authentication are performed in
799 the clear and may be modified by an active attacker. In the case
800 where a client selects integrity protection, it is important that any
801 security-sensitive protocol negotiations be performed after
802 authentication is complete. Protocols should be designed such that
803 negotiations performed prior to authentication should be either
804 ignored or revalidated once authentication is complete.
806 When use of a security layer is negotiated by the authentication
807 protocol exchange, the receiver should handle gracefully any security
808 encoded data buffer larger than the defined/negotiated maximal size.
809 In particular, it must not blindly allocate the ammount of memory
810 specified in the buffer size field, as this might cause the "out of
811 memory" condition. If the receiver detects a large block, it SHOULD
812 close the connection.
814 "stringprep" and Unicode security considerations apply to
815 authentication identities, authorization identities and passwords.
817 The EXTERNAL mechanism provides no security protection; it is
818 vulnerable to spoofing by either client or server, active attack, and
819 eavesdropping. It should only be used when external security
820 mechanisms are present and have sufficient strength.
825 ACI Worldwide/MessagingDirect
827 Email: mel@messagingdirect.com
831 This document is a revision of RFC 2222 written by John G. Myers
832 <jgmyers@netscape.com>. He also wrote the major part of this
838 A. Melnikov FORMFEED[Page 14]
844 Internet DRAFT SASL 18 May 2003
847 13. Full Copyright Statement
849 Copyright (C) The Internet Society (2003). All Rights Reserved.
851 This document and translations of it may be copied and furnished to
852 others, and derivative works that comment on or otherwise explain it
853 or assist in its implementation may be prepared, copied, published
854 and distributed, in whole or in part, without restriction of any
855 kind, provided that the above copyright notice and this paragraph are
856 included on all such copies and derivative works. However, this
857 document itself may not be modified in any way, such as by removing
858 the copyright notice or references to the Internet Society or other
859 Internet organizations, except as needed for the purpose of
860 developing Internet standards in which case the procedures for
861 copyrights defined in the Internet Standards process must be
862 followed, or as required to translate it into languages other than
865 The limited permissions granted above are perpetual and will not be
866 revoked by the Internet Society or its successors or assigns.
868 This document and the information contained herein is provided on an
869 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
870 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
871 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
872 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
873 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
877 Funding for the RFC Editor function is currently provided by the
880 Appendix A. Relation of SASL to transport security
882 Questions have been raised about the relationship between SASL and
883 various services (such as IPsec and TLS) which provide a secured
886 Two of the key features of SASL are:
888 The separation of the authorization identity from the identity in
889 the client's credentials. This permits agents such as proxy
890 servers to authenticate using their own credentials, yet request
891 the access privileges of the identity for which they are proxying.
893 Upon successful completion of an authentication exchange, the
894 server knows the authorization identity the client wishes to use.
898 A. Melnikov FORMFEED[Page 15]
904 Internet DRAFT SASL 18 May 2003
907 This allows servers to move to a "user is authenticated" state in
910 These features are extremely important to some application protocols,
911 yet Transport Security services do not always provide them. To
912 define SASL mechanisms based on these services would be a very messy
913 task, as the framing of these services would be redundant with the
914 framing of SASL and some method of providing these important SASL
915 features would have to be devised.
917 Sometimes it is desired to enable within an existing connection the
918 use of a security service which does not fit the SASL model. (TLS is
919 an example of such a service.) This can be done by adding a command,
920 for example "STARTTLS", to the protocol. Such a command is outside
921 the scope of SASL, and should be different from the command which
922 starts a SASL authentication protocol exchange.
924 In certain situations, it is reasonable to use SASL underneath one of
925 these Transport Security services. The transport service would
926 secure the connection, either service would authenticate the client,
927 and SASL would negotiate the authorization identity. The SASL
928 negotiation would be what moves the protocol from "unauthenticated"
929 to "authenticated" state. The "EXTERNAL" SASL mechanism is
930 explicitly intended to handle the case where the transport service
931 secures the connection and authenticates the client and SASL
932 negotiates the authorization identity.
934 When using SASL underneath a sufficiently strong Transport Security
935 service, a SASL security layer would most likely be redundant. The
936 client and server would thus probably want to negotiate off the use
937 of a SASL security layer.
939 Appendix B. IANA considerations
941 The IANA is directed to modify the SASL mechanisms registry as
944 Change the "Intended usage" of the KERBEROS_V4 and SKEY mechanism
945 registrations to OBSOLETE. Change the "Published specification"
946 of the EXTERNAL mechanism to this document.
948 Appendix C. Changes since RFC 2222
950 The GSSAPI mechanism was removed. It is now specified in a separate
951 document [SASL-GSSAPI].
953 The "KERBEROS_V4" mechanism defined in RFC 2222 is obsolete and has
958 A. Melnikov FORMFEED[Page 16]
964 Internet DRAFT SASL 18 May 2003
967 The "SKEY" mechanism described in RFC 2222 is obsolete and has been
968 removed. It has been replaced by the OTP mechanism [SASL-OTP].
970 The overview has been substantially reorganized and clarified.
972 Clarified the definition and semantics of the authorization identity.
974 Prohibited the NULL character in authorization identities.
976 Added a section on character string issues.
978 The word "must" in the first paragraph of the "Protocol profile
979 requirements" section was changed to "MUST".
981 Specified that protocol profiles SHOULD provide a way for clients to
982 discover available SASL mechanisms.
984 Made the requirement that protocol profiles specify the semantics of
985 the authorization identity optional to the protocol profile.
986 Clarified that such a specification is a refinement of the definition
987 in the base SASL spec.
989 Added a requirement discouraging protocol profiles from breaking the
990 separation between protocol and mechanism.
992 Mentioned that standards track documents may carve out their own
993 portions of the SASL mechanism namespace.
995 Specified that the authorization identity in the EXTERNAL mechanism
998 Added a statement that a protocol profile SHOULD allow challenge data
999 to be sent with a success indication.
1001 Added a security consideration for the EXTERNAL mechansim.
1003 Clarified sections concerning success with additional data.
1005 Updated IANA related URLs.
1007 Updated references and split them into Informative and Normative.
1009 Added text to the Security Considerations section regarding handling
1010 of extremely large SASL blocks.
1012 Replaced UTF-8 ABNF with the reference to the UTF-8 document.
1014 Added text about SASLPrep for authentication identities and
1018 A. Melnikov FORMFEED[Page 17]
1024 Internet DRAFT SASL 18 May 2003
1029 Added paragraph about verifying authorization identities.
1078 A. Melnikov FORMFEED[Page 18]
1084 Internet DRAFT SASL 18 May 2003
1089 Status of this Memo .......................................... i
1090 1. Abstract ............................................... 2
1091 2. Organization of this document .......................... 2
1092 2.1. How to read this document .............................. 2
1093 2.2. Conventions used in this document ...................... 2
1094 3. Overview ............................................... 2
1095 4. Authentication mechanisms .............................. 3
1096 4.1. Authentication protocol exchange ....................... 4
1097 4.2. Authorization identities and proxy authentication ...... 4
1098 4.3. Security layers ........................................ 5
1099 4.4. Character string issues ................................ 6
1100 5. Protocol profile requirements .......................... 6
1101 6. Specific issues ........................................ 7
1102 6.1. Client sends data first ................................ 7
1103 6.2. Server returns success with additional data ............ 8
1104 6.3. Multiple authentications ............................... 8
1105 7. The EXTERNAL mechanism ................................. 9
1106 7.1. Formal syntax .......................................... 9
1107 7.2. Example ................................................ 9
1108 8. IANA Considerations ................................... 10
1109 8.1. Comments on SASL mechanism registrations .............. 10
1110 8.2. Location of registered SASL mechanism list ............ 11
1111 8.3. Change control ........................................ 11
1112 8.4. Registration template ................................. 11
1113 8.5. The EXTERNAL mechanism registration ................... 12
1114 9. References ............................................ 12
1115 9.1. Normative References .................................. 12
1116 9.2. Informative References ................................ 13
1117 10. Security considerations ............................... 13
1118 11. Editor's Address ...................................... 14
1119 12. Acknowledgments ....................................... 14
1120 13. Full Copyright Statement .............................. 15
1121 Appendix A. Relation of SASL to transport security .......... 15
1122 Appendix B. IANA considerations ............................. 16
1123 Appendix C. Changes since RFC 2222 .......................... 16
1138 A. Melnikov FORMFEED[Page ii]