7 Network Working Group A. Melnikov
9 Document: draft-ietf-sasl-rfc2222bis-03.txt October 2003
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
40 When published as an RFC this document will obsolete RFC 2222.
58 A. Melnikov FORMFEED[Page i]
64 Internet DRAFT SASL 18 October 2003
69 The Simple Authentication and Security Layer (SASL) provides a method
70 for adding authentication support with an optional security layer to
71 connection-based protocols. It also describes a structure for
72 authentication mechanisms. The result is an abstraction layer
73 between protocols and authentication mechanisms such that any SASL-
74 compatible authentication mechanism can be used with any SASL-
77 This document describes how a SASL authentication mechanism is
78 structured, describes how a protocol adds support for SASL, defines
79 the protocol for carrying a security layer over a connection, and
80 defines the EXTERNAL SASL authentication mechanism.
82 2. Organization of this document
84 2.1. How to read this document
86 This document is written to serve two different audiences, protocol
87 designers using this specification to support authentication in their
88 protocol, and implementors of clients or servers for those protocols
89 using this specification.
91 The sections "Overview", "Authentication Mechanisms", "Protocol
92 Profile Requirements", "Specific Issues", and "Security
93 Considerations" cover issues that protocol designers need to
94 understand and address in profiling this specification for use in a
97 Implementors of a protocol using this specification need the
98 protocol-specific profiling information in addition to the
99 information in this document.
101 2.2. Conventions used in this document
103 In examples, "C:" and "S:" indicate lines sent by the client and
106 The key words "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", and "MAY"
107 in this document are to be interpreted as defined in "Key words for
108 use in RFCs to Indicate Requirement Levels" [KEYWORDS].
110 Character names in this document use the notation for code points and
111 names from the Unicode Standard [Unicode]. For example, the letter
112 "a" may be represented as either <U+0061> or <LATIN SMALL LETTER A>.
118 A. Melnikov FORMFEED[Page 2]
124 Internet DRAFT SASL 18 October 2003
129 The Simple Authentication and Security Layer (SASL) is a method for
130 adding authentication support to connection-based protocols.
132 The SASL specification has three layers, as indicated in the diagram
133 below. At the top, a protocol definition using SASL specifies a
134 profile, including a command for identifying and authenticating a
135 user to a server and for optionally negotiating a security layer for
136 subsequent protocol interactions. At the bottom, a SASL mechanism
137 definition specifies an authentication mechanism. The SASL
138 framework, specified by this document, constrains the behavior of
139 protocol profiles and mechanisms, separating protocol from mechanism
140 and defining how they interact.
142 SMTP Protocol LDAP Protocol Etc
143 Profile Profile . . .
149 EXTERNAL DIGEST-MD5 Etc
150 SASL mechanism SASL mechanism . . .
152 This separation between the definition of protocols and the
153 definition of authentication mechanisms is crucial. It permits an
154 authentication mechanism to be defined once, making it usable by any
155 SASL protocol profile. In many implementations, the same SASL
156 mechanism code is used for multiple protocols.
158 4. Authentication mechanisms
160 SASL mechanisms are named by strings, from 1 to 20 characters in
161 length, consisting of upper-case ASCII [ASCII] letters, digits,
162 hyphens, and/or underscores. SASL mechanism names must be registered
163 with the Internet Assigned Numbers Authority (IANA). IETF standards
164 track documents may direct the IANA to reserve a portion of the SASL
165 mechanism namespace and may specify different registration criteria
166 for the reserved portion; the GSSAPI mechanism specification [SASL-
167 GSSAPI] does this. Procedures for registering new SASL mechanisms are
168 given in the section 8.
170 The "sasl-mech" rule below defines the syntax of a SASL mechanism
171 name. This uses the Augmented Backus-Naur Form (ABNF) notation as
172 specified in [ABNF] and the ABNF core rules as specified in Appendix
173 A of the ABNF specification [ABNF].
178 A. Melnikov FORMFEED[Page 3]
184 Internet DRAFT SASL 18 October 2003
187 sasl-mech = 1*20mech-char
188 mech-char = %x41-5A / DIGIT / "-" / "_"
189 ; mech names restricted to uppercase ASCII letters,
190 ; digits, "-" and "_"
193 4.1. Authentication protocol exchange
195 A SASL mechanism is responsible for conducting an authentication
196 protocol exchange. This consists of a series of server challenges
197 and client responses, the contents of which are specific to and
198 defined by the mechanism. To the protocol, the challenges and
199 responses are opaque binary tokens of arbitrary length. The
200 protocol's profile then specifies how these binary tokens are then
201 encoded for transfer over the connection.
203 After receiving an authentication command or any client response, a
204 server mechanism may issue a challenge, indicate failure, or indicate
205 completion. The server mechanism may return additional data with a
206 completion indication. The protocol's profile specifies how each of
207 these is then represented over the connection.
209 After receiving a challenge, a client mechanism may issue a response
210 or abort the exchange. The protocol's profile specifies how each of
211 these is then represented over the connection.
213 During the authentication protocol exchange, the mechanism performs
214 authentication, transmits an authorization identity (frequently known
215 as a userid) from the client to server, and negotiates the use of a
216 mechanism-specific security layer. If the use of a security layer is
217 agreed upon, then the mechanism must also define or negotiate the
218 maximum security layer buffer size that each side is able to receive.
220 4.2. Authorization identities and proxy authentication
222 An authorization identity is a string of zero or more ISO 10646
223 [ISO-10646] coded characters. The NUL <U+0000> character is not
224 permitted in authorization identities. The meaning of an
225 authorization identity of the empty string (zero length) is defined
226 below in this section. The authorization identity is used by the
227 server as the primary identity for making access policy decisions.
229 The character encoding scheme used (see [CHARSET-POLICY] for IETF
230 policy regarding character sets in IETF protocols) for transmitting
231 an authorization identity over protocol is specified in each
232 authentication mechanism (with the authentication mechanism's data
233 being further restricted/encoded by the protocol profile).
234 Authentication mechanisms SHOULD encode these and other strings in
238 A. Melnikov FORMFEED[Page 4]
244 Internet DRAFT SASL 18 October 2003
247 UTF-8 [UTF-8]. While some legacy mechanisms are incapable of
248 transmitting an authorization identity other than the empty string,
249 newly defined mechanisms are expected to be capable of carrying the
250 entire Unicode repertoire (with the exception of the NUL character).
251 An authorization identity of the empty string and an absent
252 authorization identity MUST be treated as equivalent. However,
253 mechanisms SHOULD NOT allow both. That is, a mechanism which provides
254 an optional field for an authorization identity, SHOULD NOT allow
255 that field, when present, to be empty.
257 The identity derived from the client's authentication credentials is
258 known as the "authentication identity". With any mechanism,
259 transmitting an authorization identity of the empty string directs
260 the server to derive an authorization identity from the client's
261 authentication identity.
263 If the authorization identity transmitted during the authentication
264 protocol exchange is not the empty string, this is typically referred
265 to as "proxy authentication". This feature permits agents such as
266 proxy servers to authenticate using their own credentials, yet
267 request the access privileges of the identity for which they are
270 The server makes an implementation defined policy decision as to
271 whether the authentication identity is permitted to have the access
272 privileges of the authorization identity and whether the
273 authorization identity is permitted to receive service. If it is
274 not, the server indicates failure of the authentication protocol
277 As a client might not have the same information as the server,
278 clients SHOULD NOT derive authorization identities from
279 authentication identities. Instead, clients SHOULD provide no (or
280 empty) authorization identity when the user has not provided an
281 authorization identity.
283 The server MUST verify that a received authorization identity is in
284 the correct form. Profiles whose authorization identities are simple
285 user names (e.g. IMAP [RFC 3501]) SHOULD use "SASLPrep" profile
286 [SASLPrep] of the "stringprep" algorithm [StringPrep] to prepare
287 these names for matching. The profiles MAY use a stringprep profile
288 that is more strict than "SASLPrep". If the preparation of the
289 authorization identity fails or results in an empty string, the
290 server MUST fail the authentication exchange. The only exception to
291 this rule is when the received authorization identity is already the
298 A. Melnikov FORMFEED[Page 5]
304 Internet DRAFT SASL 18 October 2003
309 If use of a security layer is negotiated by the authentication
310 protocol exchange, the security layer is applied to all subsequent
311 data sent over the connection (until another security layer or no
312 security layer is negotiated; see also section 6.3). The security
313 layer takes effect immediately following the last response of the
314 authentication exchange for data sent by the client and the
315 completion indication for data sent by the server.
317 Once the security layer is in effect, the protocol stream is
318 processed by the security layer into buffers of security encoded
319 data. Each buffer of security encoded data is transferred over the
320 connection as a stream of octets prepended with a four octet field in
321 network byte order that represents the length of the following
322 buffer. The length of the security encoded data buffer MUST be no
323 larger than the maximum size that was either defined in the mechanism
324 specification or negotiated by the other side during the
325 authentication protocol exchange. Upon the receipt of a data buffer
326 which is larger than the defined/negotiated maximal buffer size, the
327 receiver SHOULD close the connection. This might be a sign of an
328 attack or a buggy implementation.
330 4.4. Character string issues
332 Authentication mechanisms SHOULD encode character strings in UTF-8
333 [UTF-8] (see [CHARSET-POLICY] for IETF policy regarding character
334 sets in IETF protocols). In order to avoid noninteroperability due
335 to differing normalizations, when a mechanism specifies that a string
336 authentication identity or password used as input to a cryptographic
337 function (or used for comparison) it SHOULD specify that the string
338 first be prepared using the "SASLPrep" profile [SASLPrep] of the
339 "stringprep" algorithm [StringPrep]. There are three entities that
340 has to deal with this issue: a client (upon getting user input or
341 retrieving a value from configuration), a server (upon receiving the
342 value from the client) and a utility that is able to store
343 passwords/hashes in a database that can be later used by the server.
344 The preparation must be done by the client and the utility and may be
345 done by the server. If preparation fails or results in an empty
346 string, the entity doing the preparation SHALL fail the
347 authentication exchange.
350 5. Protocol profile requirements
352 In order to use this specification, a protocol definition MUST supply
353 the following information:
358 A. Melnikov FORMFEED[Page 6]
364 Internet DRAFT SASL 18 October 2003
367 A service name, to be selected from the IANA registry of "service"
368 elements for the GSSAPI host-based service name form [GSSAPI]. This
369 service name is made available to the authentication mechanism.
371 The registry is available at the URL
372 <http://www.iana.org/assignments/gssapi-service-names>.
374 A definition of the command to initiate the authentication protocol
375 exchange. This command must have as a parameter the name of the
376 mechanism being selected by the client.
378 The command SHOULD have an optional parameter giving an initial
379 response. This optional parameter allows the client to avoid a round
380 trip when using a mechanism which is defined to have the client send
381 data first. When this initial response is sent by the client and the
382 selected mechanism is defined to have the server start with an
383 initial challenge, the command fails. See section 6.1 of this
384 document for further information.
386 A definition of the method by which the authentication protocol
387 exchange is carried out, including how the challenges and responses
388 are encoded, how the server indicates completion or failure of the
389 exchange, how the client aborts an exchange, and how the exchange
390 method interacts with any line length limits in the protocol.
392 The exchange method SHOULD allow the server to include an optional
393 data ("optional challenge") with a success notification. This allows
394 the server to avoid a round trip when using a mechanism which is
395 defined to have the server send additional data along with the
396 indication of successful completion. See section 6.2 of this
397 document for further information.
399 In addition, a protocol profile SHOULD specify a mechanism through
400 which a client may obtain the names of the SASL mechanisms available
401 to it. This is typically done through the protocol's extensions or
402 capabilities mechanism.
404 Identification of the octet where any negotiated security layer
405 starts to take effect, in both directions.
407 Specify if the protocol supports "multiple authentications" (see
410 If both TLS and SASL security layer are allowed to be negotiated by
411 the protocol, the protocol profile MUST define in which order they
412 are applied to a cleartext data sent over the connection.
414 A protocol profile MAY further refine the definition of an
418 A. Melnikov FORMFEED[Page 7]
424 Internet DRAFT SASL 18 October 2003
427 authorization identity by adding additional syntactic restrictions
428 and protocol-specific semantics. A protocol profile MUST specify the
429 form of the authorization identity (since it is protocol specific, as
430 opposed to the authentication identity, which is mechanism specific)
431 and how authorization identities are to be compared. Profiles whose
432 authorization identities are simple user names (e.g. IMAP [RFC 3501])
433 SHOULD use "SASLPrep" profile [SASLPrep] of the "stringprep"
434 algorithm [StringPrep] to prepare these names for matching. The
435 profiles MAY use a stringprep profile that is more strict than
438 A protocol profile SHOULD NOT attempt to amend the definition of
439 mechanisms or make mechanism-specific encodings. This breaks the
440 separation between protocol and mechanism that is fundamental to the
441 design of SASL. Likewise, SASL mechanisms SHOULD be profile neutral.
445 6.1. Client sends data first
447 Some mechanisms specify that the first data sent in the
448 authentication protocol exchange is from the client to the server.
450 If a protocol's profile permits the command which initiates an
451 authentication protocol exchange to contain an initial client
452 response, this parameter SHOULD be used with such mechanisms.
454 If the initial client response parameter is not given, or if a
455 protocol's profile does not permit the command which initiates an
456 authentication protocol exchange to contain an initial client
457 response, then the server issues a challenge with no data. The
458 client's response to this challenge is then used as the initial
459 client response. (The server then proceeds to send the next
460 challenge, indicates completion, or indicates failure.)
462 6.2. Server returns success with additional data
464 Some mechanisms may specify that additional data be sent to the
465 client along with an indication of successful completion of the
466 exchange. This data would, for example, authenticate the server to
469 If a protocol's profile does not permit this additional data to be
470 returned with a success indication, then the server issues the data
471 as a server challenge, without an indication of successful
472 completion. The client then responds with no data. After receiving
473 this empty response, the server then indicates successful completion
474 (with no additional data).
478 A. Melnikov FORMFEED[Page 8]
484 Internet DRAFT SASL 18 October 2003
487 Client implementors should be aware of an additional failure case
488 that might occur when the profile supports sending the additional
489 data with success. Imagine that an active attacker is trying to
490 impersonate the server and sends faked data, which should be used to
491 authenticate the server to the client, with success. (A similar
492 situation can happen when either the server and/or the client has a
493 bug and they calculate different responses.) After checking the data,
494 the client will think that the authentication exchange has failed,
495 however the server will think that the authentication exchange has
496 completed successfully. At this point the client can not abort the
497 authentication exchange, it SHOULD close the connection instead.
498 However, if the profile did not support sending of additional data
499 with success, the client could have aborted the exchange at the very
500 last step of the authentication exchange.
502 6.3. Multiple authentications
504 Unless otherwise stated by the protocol's profile, only one
505 successful SASL negotiation may occur in a protocol session. In this
506 case, once an authentication protocol exchange has successfully
507 completed, further attempts to initiate an authentication protocol
510 If a profile explicitly permits multiple successful SASL negotiations
511 to occur, then in no case may multiple security layers be
512 simultaneously in effect. If a security layer is in effect and a
513 subsequent SASL negotiation selects a second security layer, then the
514 second security layer replaces the first. If a security layer is in
515 effect and a subsequent SASL negotiation selects no security layer,
516 the original security layer MUST be removed. The next paragraphs
517 explain why this is important.
519 Let's assume that the protected resources on a server are partitioned
520 into a set of protection spaces, each with its own authentication
521 mechanisms and/or authorization database. Let's use the term "realm"
522 to reference any such protected space. Conceptually, realm is a named
523 collection of user's accounts. For example, a proxy/frontend can use
524 different realms for different servers/backends it represents.
526 Now consider the following scenario. A client has already
527 authenticated and established a security layer with "Realm A" which
528 is managed by the server AA. Now the same client authenticates to
529 "Realm B" (managed by the server BB) without negotiating a new
530 security layer, while the security layer negotiated with "Realm A"
531 remains in effect. The server BB is now able observe how known
532 cleartext is encrypted. This scenario enables the server BB to make
533 guesses about previously observed ciphertext between the client and
534 the server AA using the server's SASL engine as an oracle. This
538 A. Melnikov FORMFEED[Page 9]
544 Internet DRAFT SASL 18 October 2003
547 scenario is illustrated below:
598 A. Melnikov FORMFEED[Page 10]
604 Internet DRAFT SASL 18 October 2003
607 +---------+ +---------+
609 | Realm B | | Realm A |
611 +---------+ +---------+
614 Traffic from | : | Encryption| | Traffic from A
615 B to client +-------->| end point |<-------+ to client
623 : | | Encryption tunnel, e.g. SASL or SSL,
624 : | | between the server
625 (1) Recording +---------:| | and a single client only.
626 encrypted | | Separate tunnels to different
627 traffic between | | clients.
628 Realm A and client +---+
631 +-----------> Traffic to clients
633 7. The EXTERNAL mechanism
635 The mechanism name associated with external authentication is
638 The client sends an initial response with the UTF-8 encoding of the
639 authorization identity. The form of the authorization identity is
640 further restricted by the application-level protocol's SASL profile.
642 The server uses information, external to SASL, to determine whether
643 the client is authorized to authenticate as the authorization
644 identity. If the client is so authorized, the server indicates
645 successful completion of the authentication exchange; otherwise the
646 server indicates failure.
648 The system providing this external information may be, for example,
649 IPSec or TLS. However, the client can make no assumptions as to what
650 information the server can use in determining client authorization.
651 E.g., just because TLS was established, doesn't mean that the server
652 will use the information provided by TLS.
654 If the client sends the empty string as the authorization identity
658 A. Melnikov FORMFEED[Page 11]
664 Internet DRAFT SASL 18 October 2003
667 (thus requesting that the authorization identity be derived from the
668 client's authentication credentials), the authorization identity is
669 to be derived from authentication credentials which exist in the
670 system that is providing the external authentication.
674 The following syntax specification uses the augmented Backus-Naur
675 Form (BNF) notation as specified in [ABNF]. This uses the ABNF core
676 rules as specified in Appendix A of the ABNF specification [ABNF].
677 Non-terminals referenced but not defined below are as defined by
680 The "extern-init-resp" rule below defines the initial response sent
681 from client to server.
683 extern-init-resp = *( UTF8-char-no-nul )
685 UTF8-char-no-nul = UTF8-1-no-nul / UTF8-2 / UTF8-3 / UTF8-4
687 UTF8-1-no-nul = %x01-7F
692 The following is an example of an EXTERNAL authentication in the SMTP
693 protocol [SMTP]. In this example, the client is proxy
694 authenticating, sending the authorization id "fred". The server has
695 determined the client's identity through IPsec and has a security
696 policy that permits that identity to proxy authenticate as any other
699 To the protocol profile, the four octet sequence "fred" is an opaque
700 binary data. The SASL protocol profile for SMTP [SMTP-AUTH] specifies
701 that server challenges and client responses are encoded in BASE64
702 [BASE64]; the BASE64 encoding of "fred" is "ZnJlZA==".
704 S: 220 smtp.example.com ESMTP server ready
705 C: EHLO jgm.example.com
706 S: 250-smtp.example.com
707 S: 250 AUTH DIGEST-MD5 EXTERNAL
708 C: AUTH EXTERNAL ZnJlZA==
709 S: 235 Authentication successful.
711 8. IANA Considerations
718 A. Melnikov FORMFEED[Page 12]
724 Internet DRAFT SASL 18 October 2003
727 8.1. Guidelines for IANA
730 It is requested that IANA updates the SASL mechanisms registry as
734 Change the "Intended usage" of the KERBEROS_V4 and SKEY mechanism
735 registrations to OBSOLETE. Change the "Published specification"
736 of the EXTERNAL mechanism to this document. Updated registration
737 is provided in Section 8.6.
739 8.2. Registration procedure
742 Registration of a SASL mechanism is done by filling in the template
743 in section 8.5 and sending it via electronic mail to <iana@iana.org>.
744 IANA has the right to reject obviously bogus registrations, but will
745 perform no review of claims made in the registration form. SASL
746 mechanism registrations are currently available at the URL
747 <http://www.iana.org/assignments/sasl-mechanisms>.
749 There is no naming convention for SASL mechanisms; any name that
750 conforms to the syntax of a SASL mechanism name can be registered.
751 An IETF Standards Track document may reserve a portion of the SASL
752 mechanism namespace ("family of SASL mechanisms") for its own use,
753 amending the registration rules for that portion of the namespace.
754 Each family of SASL mechanisms MUST be identified by a prefix.
756 While the registration procedures do not require it, authors of SASL
757 mechanisms are encouraged to seek community review and comment
758 whenever that is feasible. Authors may seek community review by
759 posting a specification of their proposed mechanism as an Internet-
760 Draft. SASL mechanisms intended for widespread use should be
761 standardized through the normal IETF process, when appropriate.
763 8.3. Comments on SASL mechanism registrations
765 Comments on registered SASL mechanisms should first be sent to the
766 "owner" of the mechanism and/or to the SASL WG mailing list.
767 Submitters of comments may, after a reasonable attempt to contact the
768 owner, request IANA to attach their comment to the SASL mechanism
769 registration itself. If IANA approves of this, the comment will be
770 made accessible in conjunction with the SASL mechanism registration
778 A. Melnikov FORMFEED[Page 13]
784 Internet DRAFT SASL 18 October 2003
789 Once a SASL mechanism registration has been published by IANA, the
790 author may request a change to its definition. The change request
791 follows the same procedure as the registration request.
793 The owner of a SASL mechanism may pass responsibility for the SASL
794 mechanism to another person or agency by informing IANA; this can be
795 done without discussion or review.
797 The IESG may reassign responsibility for a SASL mechanism. The most
798 common case of this will be to enable changes to be made to
799 mechanisms where the author of the registration has died, moved out
800 of contact or is otherwise unable to make changes that are important
803 SASL mechanism registrations may not be deleted; mechanisms which are
804 no longer believed appropriate for use can be declared OBSOLETE by a
805 change to their "intended use" field; such SASL mechanisms will be
806 clearly marked in the lists published by IANA.
808 The IESG is considered to be the owner of all SASL mechanisms which
809 are on the IETF standards track.
811 8.5. Registration template
814 Subject: Registration of SASL mechanism X
816 Family of SASL mechanisms: (YES or NO)
818 SASL mechanism name (or prefix for the family):
820 Security considerations:
822 Published specification (optional, recommended):
824 Person & email address to contact for further information:
828 (One of COMMON, LIMITED USE or OBSOLETE)
830 Owner/Change controller:
832 (Any other information that the author deems interesting may be
833 added below this line.)
838 A. Melnikov FORMFEED[Page 14]
844 Internet DRAFT SASL 18 October 2003
847 8.6. The EXTERNAL mechanism registration
849 It is requested that the SASL Mechanism registry [IANA-SASL] entry
850 for the EXTERNAL mechanism be updated to reflect that this document
851 now provides its technical specification.
854 Subject: Updated Registration of SASL mechanism EXTERNAL
856 Family of SASL mechanisms: NO
858 SASL mechanism name: EXTERNAL
860 Security considerations: See RFC XXXX, section 9.
862 Published specification (optional, recommended): RFC XXXX
864 Person & email address to contact for further information:
865 Alexey Melnikov <Alexey.Melnikov@isode.com>
867 Intended usage: COMMON
869 Owner/Change controller: IESG <iesg@ietf.org>
871 Note: Updates existing entry for EXTERNAL
873 9. Security considerations
875 Security issues are discussed throughout this memo.
877 The mechanisms that support integrity protection are designed such
878 that the negotiation of the security layer and authorization identity
879 is integrity protected. When the client selects a security layer
880 with at least integrity protection, this protects against an active
881 attacker hijacking the connection and modifying the authentication
882 exchange to negotiate a plaintext connection.
884 When a server or client supports multiple authentication mechanisms,
885 each of which has a different security strength, it is possible for
886 an active attacker to cause a party to use the least secure mechanism
887 supported. To protect against this sort of attack, a client or
888 server which supports mechanisms of different strengths should have a
889 configurable minimum strength that it will use. It is not sufficient
890 for this minimum strength check to only be on the server, since an
891 active attacker can change which mechanisms the client sees as being
892 supported, causing the client to send authentication credentials for
893 its weakest supported mechanism.
898 A. Melnikov FORMFEED[Page 15]
904 Internet DRAFT SASL 18 October 2003
907 The client's selection of a SASL mechanism is done in the clear and
908 may be modified by an active attacker. It is important for any new
909 SASL mechanisms to be designed such that an active attacker cannot
910 obtain an authentication with weaker security properties by modifying
911 the SASL mechanism name and/or the challenges and responses.
913 Any protocol interactions prior to authentication are performed in
914 the clear and may be modified by an active attacker. In the case
915 where a client selects integrity protection, it is important that any
916 security-sensitive protocol negotiations be performed after
917 authentication is complete. Protocols should be designed such that
918 negotiations performed prior to authentication should be either
919 ignored or revalidated once authentication is complete.
921 When use of a security layer is negotiated by the authentication
922 protocol exchange, the receiver should handle gracefully any security
923 encoded data buffer larger than the defined/negotiated maximal size.
924 In particular, it must not blindly allocate the amount of memory
925 specified in the buffer size field, as this might cause the "out of
926 memory" condition. If the receiver detects a large block, it SHOULD
927 close the connection.
929 "stringprep" and Unicode security considerations apply to
930 authentication identities, authorization identities and passwords.
932 The EXTERNAL mechanism provides no security protection; it is
933 vulnerable to spoofing by either client or server, active attack, and
934 eavesdropping. It should only be used when external security
935 mechanisms are present and have sufficient strength.
939 10.1. Normative References
941 [ABNF] Crocker, Overell, "Augmented BNF for Syntax Specifications:
942 ABNF", RFC 2234, November 1997
944 [ASCII] American National Standards Institute, "Code Extension
945 Techniques for Use with the 7-bit Coded Character Set of American
946 National Standard Code (ASCII) for Information Interchange", FIPS PUB
949 [CHARSET-POLICY] Alvestrand, "IETF Policy on Character Sets and
950 Languages", RFC 2277, January 1998
952 [GSSAPI] Linn, "Generic Security Service Application Program
953 Interface, Version 2, Update 1", RFC 2743, January 2000
958 A. Melnikov FORMFEED[Page 16]
964 Internet DRAFT SASL 18 October 2003
967 [ISO-10646] "Universal Multiple-Octet Coded Character Set (UCS) -
968 Architecture and Basic Multilingual Plane", ISO/IEC 10646-1 : 1993.
970 [KEYWORDS] Bradner, "Key words for use in RFCs to Indicate
971 Requirement Levels", RFC 2119, March 1997
973 [Unicode] The Unicode Consortium, "The Unicode Standard, Version
974 3.2.0" is defined by "The Unicode Standard, Version 3.0" (Reading,
975 MA, Addison-Wesley, 2000. ISBN 0-201-61633-5), as amended by the
976 "Unicode Standard Annex #27: Unicode 3.1"
977 (http://www.unicode.org/reports/tr27/) and by the "Unicode Standard
978 Annex #28: Unicode 3.2" (http://www.unicode.org/reports/tr28/).
980 [Stringprep] P. Hoffman, M. Blanchet, "Preparation of
981 Internationalized Strings ("stringprep")", RFC 3454, December 2002.
983 [SASLPrep] Zeilenga, K., "SASLprep: Stringprep profile for user names
984 and passwords", Work in progress, draft-ietf-sasl-saslprep-XX.txt.
986 [UTF-8] Yergeau, "UTF-8, a transformation format of ISO 10646", work
987 in progress (draft-yergeau-rfc2279bis-XX) that replaces RFC 2279,
990 10.2. Informative References
992 <<Update the reference below>> [SASL-GSSAPI] Myers, J., "SASL GSSAPI
993 mechanisms", work in progress, draft-ietf-cat-sasl-gssapi-XX.txt,
996 [SASL-DIGEST] Leach, P., Newman, C., Melnikov, A., "Using Digest
997 Authentication as a SASL Mechanism", work in progress, draft-ietf-
998 sasl-rfc2831bis-XX.txt, replaces RFC 2831
1000 [SASL-OTP] Newman, C., "The One-Time-Password SASL Mechanism", RFC
1003 [SMTP] Klensin, J., "Simple Mail Transfer Protocol", RFC 2821, April
1006 [SMTP-AUTH] Myers, J., "SMTP Service Extension for Authentication",
1007 RFC 2554, March 1999
1009 [BASE64] Josefsson, S., "The Base16, Base32, and Base64 Data
1010 Encodings", RFC 3548, July 2003
1012 [RFC-INSTRUCTIONS] Postel, Reynolds, "Instructions to RFC Authors",
1013 RFC 2223, October 1997
1018 A. Melnikov FORMFEED[Page 17]
1024 Internet DRAFT SASL 18 October 2003
1027 [IANA-SASL] IANA, "SIMPLE AUTHENTICATION AND SECURITY LAYER (SASL)
1028 MECHANISMS", http://www.iana.org/assignments/sasl-mechanisms.
1030 11. Editor's Address
1035 Email: Alexey.Melnikov@isode.com
1039 This document is a revision of RFC 2222 written by John G. Myers. He
1040 also contributed significantly to this revision.
1042 Magnus Nystrom provided the ASCII art used in Section 6.3.
1044 Definition of realm was extracted from RFC 2617 ("HTTP
1045 Authentication: Basic and Digest Access Authentication").
1047 Contributions of many members of the SASL mailing list are gratefully
1048 acknowledged, in particular Kurt D. Zeilenga, Peter Saint-Andre, Rob
1049 Siemborski, Jeffrey Hutzelman and Hallvard B Furuseth for
1050 proofreading the document and various editorial suggestions.
1053 13. Full Copyright Statement
1055 Copyright (C) The Internet Society (2003). All Rights Reserved.
1057 This document and translations of it may be copied and furnished to
1058 others, and derivative works that comment on or otherwise explain it
1059 or assist in its implementation may be prepared, copied, published
1060 and distributed, in whole or in part, without restriction of any
1061 kind, provided that the above copyright notice and this paragraph are
1062 included on all such copies and derivative works. However, this
1063 document itself may not be modified in any way, such as by removing
1064 the copyright notice or references to the Internet Society or other
1065 Internet organizations, except as needed for the purpose of
1066 developing Internet standards in which case the procedures for
1067 copyrights defined in the Internet Standards process must be
1068 followed, or as required to translate it into languages other than
1071 The limited permissions granted above are perpetual and will not be
1072 revoked by the Internet Society or its successors or assigns.
1074 This document and the information contained herein is provided on an
1078 A. Melnikov FORMFEED[Page 18]
1084 Internet DRAFT SASL 18 October 2003
1087 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
1088 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
1089 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
1090 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
1091 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
1095 Funding for the RFC Editor function is currently provided by the
1098 Appendix A. Relation of SASL to transport security
1100 Questions have been raised about the relationship between SASL and
1101 various services (such as IPsec and TLS) which provide a secured
1104 Two of the key features of SASL are:
1106 The separation of the authorization identity from the identity in
1107 the client's credentials. This permits agents such as proxy
1108 servers to authenticate using their own credentials, yet request
1109 the access privileges of the identity for which they are proxying.
1111 Upon successful completion of an authentication exchange, the
1112 server knows the authorization identity the client wishes to use.
1113 This allows servers to move to a "user is authenticated" state in
1116 These features are extremely important to some application protocols,
1117 yet Transport Security services do not always provide them. To
1118 define SASL mechanisms based on these services would be a very messy
1119 task, as the framing of these services would be redundant with the
1120 framing of SASL and some method of providing these important SASL
1121 features would have to be devised.
1123 Sometimes it is desired to enable within an existing connection the
1124 use of a security service which does not fit the SASL model. (TLS is
1125 an example of such a service.) This can be done by adding a command,
1126 for example "STARTTLS", to the protocol. Such a command is outside
1127 the scope of SASL, and should be different from the command which
1128 starts a SASL authentication protocol exchange.
1130 In certain situations, it is reasonable to use SASL underneath one of
1131 these Transport Security services. The transport service would
1132 secure the connection, either service would authenticate the client,
1133 and SASL would negotiate the authorization identity. The SASL
1134 negotiation would be what moves the protocol from "unauthenticated"
1138 A. Melnikov FORMFEED[Page 19]
1144 Internet DRAFT SASL 18 October 2003
1147 to "authenticated" state. The "EXTERNAL" SASL mechanism is
1148 explicitly intended to handle the case where the transport service
1149 secures the connection and authenticates the client and SASL
1150 negotiates the authorization identity.
1152 Appendix B. Changes since RFC 2222
1154 The GSSAPI mechanism was removed. It is now specified in a separate
1155 document [SASL-GSSAPI].
1157 The "KERBEROS_V4" mechanism defined in RFC 2222 is obsolete and has
1160 The "SKEY" mechanism described in RFC 2222 is obsolete and has been
1161 removed. It has been replaced by the OTP mechanism [SASL-OTP].
1163 The overview has been substantially reorganized and clarified.
1165 Clarified the definition and semantics of the authorization identity.
1167 Prohibited the NUL character in authorization identities.
1169 Added a section on character string issues.
1171 The word "must" in the first paragraph of the "Protocol profile
1172 requirements" section was changed to "MUST".
1174 Specified that protocol profiles SHOULD provide a way for clients to
1175 discover available SASL mechanisms.
1177 Made the requirement that protocol profiles specify the semantics of
1178 the authorization identity optional to the protocol profile.
1179 Clarified that such a specification is a refinement of the definition
1180 in the base SASL spec.
1182 Added a requirement discouraging protocol profiles from breaking the
1183 separation between protocol and mechanism.
1185 Mentioned that standards track documents may carve out their own
1186 portions of the SASL mechanism namespace and may amend registration
1187 rules for the portion. However registration of individual SASL
1188 mechanisms is still required.
1190 Specified that the authorization identity in the EXTERNAL mechanism
1191 is encoded in UTF-8.
1193 Added a statement that a protocol profile SHOULD allow challenge data
1194 to be sent with a success indication.
1198 A. Melnikov FORMFEED[Page 20]
1204 Internet DRAFT SASL 18 October 2003
1207 Added a security consideration for the EXTERNAL mechansim.
1209 Clarified sections concerning success with additional data.
1211 Cleaned up IANA considerations/registrations and assembled them in
1214 Updated references and split them into Informative and Normative.
1216 Added text to the Security Considerations section regarding handling
1217 of extremely large SASL blocks.
1219 Replaced UTF-8 ABNF with the reference to the UTF-8 document.
1221 Added text about SASLPrep for authentication identities and
1222 passwords. Described where SASLPrep preparation should take place.
1224 Added paragraph about verifying authorization identities.
1226 This document requires to drop a security layer on reauthentication
1227 when no security layer is negotiated. This differs from RFC 2222,
1228 which required to keep the last security layer in this case.
1230 Added a protocol profile requirement to specify interaction between
1231 SASL and TLS security layers.
1233 Added a protocol profile requirement to specify if it supports
1236 Removed the text that seemed to suggest that SASL security layer must
1237 not be used when TLS is available.
1258 A. Melnikov FORMFEED[Page 21]
1264 Internet DRAFT SASL 18 October 2003
1267 Status of this Memo .......................................... i
1268 1. Abstract ............................................... 2
1269 2. Organization of this document .......................... 2
1270 2.1. How to read this document .............................. 2
1271 2.2. Conventions used in this document ...................... 2
1272 3. Overview ............................................... 3
1273 4. Authentication mechanisms .............................. 3
1274 4.1. Authentication protocol exchange ....................... 4
1275 4.2. Authorization identities and proxy authentication ...... 4
1276 4.3. Security layers ........................................ 6
1277 4.4. Character string issues ................................ 6
1278 5. Protocol profile requirements .......................... 6
1279 6. Specific issues ........................................ 8
1280 6.1. Client sends data first ................................ 8
1281 6.2. Server returns success with additional data ............ 8
1282 6.3. Multiple authentications ............................... 9
1283 7. The EXTERNAL mechanism ................................ 11
1284 7.1. Formal syntax ......................................... 12
1285 7.2. Example ............................................... 12
1286 8. IANA Considerations ................................... 12
1287 8.1. Guidelines for IANA ................................... 13
1288 8.2. Registration procedure ................................ 13
1289 8.3. Comments on SASL mechanism registrations .............. 13
1290 8.4. Change control ........................................ 14
1291 8.5. Registration template ................................. 14
1292 8.6. The EXTERNAL mechanism registration ................... 15
1293 9. Security considerations ................................ 15
1294 10. References ........................................... 16
1295 10.1. Normative References ................................. 16
1296 10.2. Informative References ............................... 17
1297 11. Editor's Address ...................................... 18
1298 12. Acknowledgments ....................................... 18
1299 13. Full Copyright Statement .............................. 18
1300 Appendix A. Relation of SASL to transport security .......... 19
1301 Appendix B. Changes since RFC 2222 .......................... 20
1318 A. Melnikov FORMFEED[Page ii]