3 Network Working Group A. Melnikov
5 Document: draft-ietf-sasl-rfc2222bis-07.txt March 2004
6 Obsoletes: RFC 2222 Expires in six months
9 Simple Authentication and Security Layer (SASL)
13 This document is an Internet Draft and is in full conformance with
14 all provisions of Section 10 of RFC 2026.
16 Internet Drafts are working documents of the Internet Engineering
17 Task Force (IETF), its Areas, and its Working Groups. Note that
18 other groups may also distribute working documents as Internet
19 Drafts. Internet Drafts are draft documents valid for a maximum of
20 six months. Internet Drafts may be updated, replaced, or obsoleted
21 by other documents at any time. It is not appropriate to use
22 Internet Drafts as reference material or to cite them other than as
25 The list of current Internet-Drafts can be accessed at
26 http://www.ietf.org/ietf/1id-abstracts.txt
28 The list of Internet-Draft Shadow Directories can be accessed at
29 http://www.ietf.org/shadow.html.
31 A revised version of this draft document will be submitted to the RFC
32 editor as a Standards Track RFC for the Internet Community.
33 Discussion and suggestions for improvement are requested.
34 Distribution of this draft is unlimited.
36 When published as an RFC this document will obsolete RFC 2222.
54 A. Melnikov FORMFEED[Page i]
60 Internet DRAFT SASL 31 March 2004
65 The Simple Authentication and Security Layer (SASL) is a framework
66 for providing authentication and data security services in
67 connection-based protocols. It also describes a structure for
68 authentication mechanisms. The result is an abstraction layer
69 between protocols and authentication mechanisms such that any SASL-
70 compatible authentication mechanism can be used with any SASL-
73 This document describes how a SASL authentication mechanism is
74 structured, describes how a protocol adds support for SASL, defines
75 the protocol for carrying a security layer over a connection, and
76 defines the SASL EXTERNAL authentication mechanism.
78 1. Organization of this document
80 1.1. How to read this document
82 This document is written to serve several different audiences
84 o) protocol designers using this specification to support
85 authentication in their protocol
87 o) mechanism designers that define new SASL mechanisms
89 o) implementors of clients or servers for those protocols using this
92 The sections "Overview", "Authentication Mechanisms", "Protocol
93 Profile Requirements", "Specific Issues", and "Security
94 Considerations" cover issues that protocol designers need to
95 understand and address in profiling this specification for use in a
98 The sections "Overview", "Authentication Mechanisms", "Mechanism
99 Profile Requirements", "Security Considerations" and "Registration
100 procedure" cover issues that mechanism designers need to understand
101 and address in designing new SASL mechanisms.
103 The sections "Overview", "Authentication Mechanisms", "Protocol
104 profile requirements", "Specific issues" and "Security
105 Considerations" cover issues that implementors of a protocol that
106 uses SASL framework need to understand. The implementors will also
107 need to understand a specification of a profile specific to the
108 protocol, as well as aspects of mechanism specifications they intend
109 to use (regardless of whether they are implementing the mechanisms
110 themselves or using an existing implementation) to understand, for
114 A. Melnikov FORMFEED[Page 2]
120 Internet DRAFT SASL 31 March 2004
123 instance, the mechanism specific authentication identity forms, the
124 offered services, and security and other considerations.
126 1.2. Conventions used in this document
128 In examples, "C:" and "S:" indicate lines sent by the client and
131 The key words "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", and "MAY"
132 in this document are to be interpreted as defined in "Key words for
133 use in RFCs to Indicate Requirement Levels" [KEYWORDS].
135 Character names in this document use the notation for code points and
136 names from the Unicode Standard [Unicode]. For example, the letter
137 "a" may be represented as either <U+0061> or <LATIN SMALL LETTER A>.
139 This document uses terms "integrity protection" and "confidentiality
140 protection". The former refers to a security layer designed to detect
141 unauthorized data modification. However, integrity protection
142 doesn't make the data unreadable to an attacker. Confidentiality
143 protection is a security layer that is able to make the data
144 unreadable to an attacker by using encryption. Confidentiality
145 protection usually implies integrity protection. Security layers may
146 offer other kinds of security services.
151 The Simple Authentication and Security Layer (SASL) is a method for
152 adding authentication support to connection-based protocols.
154 The SASL specification has three layers, as indicated in the diagram
155 below. At the top, a protocol definition using SASL specifies a
156 profile, including a command for identifying and authenticating a
157 user to a server and for optionally negotiating a security layer for
158 subsequent protocol interactions. At the bottom, a SASL mechanism
159 definition specifies an authentication mechanism. The SASL
160 framework, specified by this document, constrains the behavior of
161 protocol profiles and mechanisms, separating protocol from mechanism
162 and defining how they interact.
164 SMTP Protocol LDAP Protocol Etc
165 Profile Profile . . .
174 A. Melnikov FORMFEED[Page 3]
180 Internet DRAFT SASL 31 March 2004
183 EXTERNAL DIGEST-MD5 Etc
184 SASL mechanism SASL mechanism . . .
186 This separation between the definition of protocols and the
187 definition of authentication mechanisms is crucial. It permits an
188 authentication mechanism to be defined once, making it usable by any
189 SASL protocol profile. In many implementations, the same SASL
190 mechanism code is used for multiple protocols.
192 3. Authentication mechanisms
194 SASL mechanisms are named by strings, from 1 to 20 characters in
195 length, consisting of ASCII [ASCII] upper-case letters, digits,
196 hyphens, and/or underscores. Names of SASL mechanisms or families of
197 mechanisms must be registered with the Internet Assigned Numbers
198 Authority (IANA) as described in section 8.2.
200 The "sasl-mech" ABNF production below defines the syntax of a SASL
201 mechanism name. This uses the Augmented Backus-Naur Form (ABNF)
202 notation as specified in [ABNF].
204 sasl-mech = 1*20mech-char
205 mech-char = UPPER-ALPHA / DIGIT / HYPHEN / UNDERSCORE
206 ; mech-char is restricted to "A"-"Z", "0"-"9", "-",
207 ; and "_" from ASCII character set.
209 UPPER-ALPHA = %x41-5A
222 3.1. Authentication protocol exchange
224 A SASL mechanism is responsible for conducting an authentication
225 protocol exchange. This consists of a series of server challenges
226 and client responses, the contents of which are specific to and
227 defined by the mechanism. To the protocol, the challenges and
228 responses are opaque binary tokens of arbitrary length. The
229 protocol's profile then specifies how these binary tokens are then
230 encoded for transfer over the connection.
234 A. Melnikov FORMFEED[Page 4]
240 Internet DRAFT SASL 31 March 2004
243 After receiving an authentication command or any client response, a
244 server mechanism may issue a challenge, indicate failure, or indicate
245 completion. The server mechanism may return additional data with a
246 completion indication. The protocol's profile specifies how each of
247 these is then represented over the connection.
249 After receiving a challenge, a client mechanism may issue a response
250 or abort the exchange. The protocol's profile specifies how each of
251 these are then represented over the connection.
253 During the authentication protocol exchange, the mechanism performs
254 authentication, transmits an authorization identity (frequently known
255 as a userid) from the client to server, and negotiates the use of a
256 mechanism-specific security layer. If the use of a security layer is
257 agreed upon, then the mechanism must also define or negotiate the
258 maximum security layer buffer size that each side is able to receive.
260 3.2. Authorization and authentication identities
262 SASL authentication deals with two identities: the authentication
263 identity, derived from the client's authentication credentials; and
264 the authorization identity, which is the result of SASL processing
265 and is used by the server as the primary identity for making access
268 The processing model is as follows. A server, upon completion of the
269 authentication mechanism, uses the results produced by the
270 authentication mechanism, the client-provided authorization identity
271 value (which may be the empty string), and local policy information
272 to derive an authorization identity. The authorization identity is
273 made available to further server processing for use in making access
274 policy decisions. The provision of additional client attributes that
275 may affect access policy is not covered by this specification.
277 The authorization identity may be an empty (zero length) string. In
278 this case, the server derives an authorization identity from the
279 client's authentication identity.
281 A mechanism which is incapable of transmitting an authorization
282 identity must be treated as if it always transmits an authorization
283 identity of an empty string.
285 Any normalization of the authentication identity is defined by a
286 particular SASL mechanism, the protocol profile doesn't influence it.
288 The mechanism MUST preserve Unicode codepoint when transferring
289 authorization identity (e.g. the mechanism cann't apply any form of
294 A. Melnikov FORMFEED[Page 5]
300 Internet DRAFT SASL 31 March 2004
303 3.2.1. Authorization identities and proxy authentication
305 If the authorization identity transmitted during the authentication
306 protocol exchange is not the empty string, this is typically referred
307 to as "proxy authentication". This feature permits agents such as
308 proxy servers to authenticate using their own credentials, yet
309 request the access privileges of the identity for which they are
312 The server makes an implementation defined policy decision as to
313 whether the authentication identity is permitted to have the access
314 privileges of the authorization identity and whether the
315 authorization identity is permitted to receive service. If it is
316 not, the server indicates failure of the authentication protocol
319 As a client might not have the same information as the server,
320 clients SHOULD NOT derive authorization identities from
321 authentication identities. Instead, clients SHOULD provide no (or
322 empty) authorization identity when the user has not provided an
323 authorization identity.
325 The server SHOULD verify that a received authorization identity is in
326 the correct form. Protocol profiles whose authorization identities
327 are simple user names (e.g. IMAP [RFC 3501]) SHOULD use "SASLprep"
328 profile [SASLprep] of the "stringprep" algorithm [StringPrep] to
329 prepare these names for matching. The profiles MAY use a stringprep
330 profile that is more strict than "SASLprep". If the preparation of
331 the authorization identity fails or results in an empty string, the
332 server MUST fail the authentication exchange. The only exception to
333 this rule is when the received authorization identity is already the
336 3.2.2. Authorization Identity Format
338 An authorization identity is a string of zero or more Unicode
339 [Unicode] coded characters. The NUL <U+0000> character is not
340 permitted in authorization identities.
342 The character encoding scheme used for transmitting an authorization
343 identity over the protocol is specified in each authentication
344 mechanism. All IETF-defined mechanisms MUST, and all other
345 mechanisms SHOULD, use UTF-8 [UTF-8]. (See [CHARSET-POLICY] for IETF
346 policy regarding character sets and encoding schemes.)
348 Mechanisms are expected to be capable of carrying the entire Unicode
349 repertoire (with the exception of the NUL character). An
350 authorization identity of the empty string and an absent
354 A. Melnikov FORMFEED[Page 6]
360 Internet DRAFT SASL 31 March 2004
363 authorization identity MUST be treated as equivalent. A mechanism
364 which provides an optional field for an authorization identity,
365 SHOULD NOT allow that field, when present, to be empty. The meaning
366 of the empty string as an authorization identity is described in the
371 If use of a security layer is negotiated by the authentication
372 protocol exchange, the security layer is applied to all subsequent
373 data sent over the connection (until another security layer is
374 negotiated; see also section 6.3). The security layer takes effect
375 immediately following the last response of the authentication
376 exchange for data sent by the client and the completion indication
377 for data sent by the server. The exact position MUST be defined by
378 the protocol profile (see section 4 part 5).
380 Note that all SASL mechanisms that are unable to negotiate a security
381 layer automatically select no security layer.
383 Once the security layer is in effect the protocol stream is processed
384 by the security layer into buffers of security encoded data. Each
385 buffer of security encoded data is transferred over the connection as
386 a stream of octets prepended with a four octet field in network byte
387 order that represents the length of the following buffer. The length
388 of the security encoded data buffer MUST be no larger than the
389 maximum size that was either defined in the mechanism specification
390 or negotiated by the other side during the authentication protocol
391 exchange. Upon the receipt of a data buffer which is larger than the
392 defined/negotiated maximal buffer size the receiver SHOULD close the
393 connection. This might be a sign of an attack or a buggy
396 4. Protocol profile requirements
398 In order to use this specification, a protocol definition MUST supply
399 the following information:
401 1) A service name, to be selected from the IANA registry of "service"
402 elements for the GSSAPI host-based service name form [GSSAPI]. This
403 service name is made available to the authentication mechanism.
405 The registry is available at the URL
406 <http://www.iana.org/assignments/gssapi-service-names>.
408 2) A definition of the command to initiate the authentication
409 protocol exchange. This command must have as a parameter the name of
410 the mechanism being selected by the client.
414 A. Melnikov FORMFEED[Page 7]
420 Internet DRAFT SASL 31 March 2004
423 The command SHOULD have an optional parameter giving an initial
424 response. If the protocol allows for the initial response, the
425 protocol profile SHOULD also describe how an empty initial response
426 is encoded. This optional parameter allows the client to avoid a
427 round trip when using a mechanism which is defined to have the client
428 send data first. When this initial response is sent by the client
429 and the selected mechanism is defined to have the server start with
430 an initial challenge, the command fails. See section 6.1 of this
431 document for further information.
433 3) A definition of the method by which the authentication protocol
434 exchange is carried out, including how the challenges and responses
435 are encoded, how the server indicates completion or failure of the
436 exchange, how the client aborts an exchange, and how the exchange
437 method interacts with any line length limits in the protocol.
439 The exchange method SHOULD allow the server to include an optional
440 data ("optional challenge") with a success notification. This allows
441 the server to avoid a round trip when using a mechanism which is
442 defined to have the server send additional data along with the
443 indication of successful completion. See section 6.2 of this
444 document for further information.
446 4) A protocol profile SHOULD specify a mechanism through which a
447 client may obtain the names of the SASL mechanisms available to it.
448 This is typically done through the protocol's extensions or
449 capabilities mechanism.
451 5) Identification of the octet where any negotiated security layer
452 starts to take effect, in both directions.
454 6) Specify if the protocol profile supports "multiple
455 authentications" (see section 6.3).
457 7) If both a Transport Layer Security [TLS] and a SASL security layer
458 are allowed to be negotiated by the protocol, the protocol profile
459 MUST define in which order they are applied to a cleartext data sent
462 8) A protocol profile MAY further refine the definition of an
463 authorization identity by adding additional syntactic restrictions
464 and protocol-specific semantics. A protocol profile MUST specify the
465 form of the authorization identity (since it is protocol specific, as
466 opposed to the authentication identity, which is mechanism specific)
467 and how authorization identities are to be compared. Profiles whose
468 authorization identities are simple user names (e.g. IMAP [RFC 3501])
469 SHOULD use "SASLprep" profile [SASLprep] of the "stringprep"
470 algorithm [StringPrep] to prepare these names for matching. The
474 A. Melnikov FORMFEED[Page 8]
480 Internet DRAFT SASL 31 March 2004
483 profiles MAY use a stringprep profile that is more strict than
486 A protocol profile SHOULD NOT attempt to amend the definition of
487 mechanisms or make mechanism-specific encodings. This breaks the
488 separation between protocol and mechanism that is fundamental to the
489 design of SASL. Likewise, SASL mechanisms SHOULD be profile neutral.
491 5. Mechanism profile guidelines
494 Designers of new SASL mechanism should be aware of the following
497 1) Authorization identity
499 While some legacy mechanisms are incapable of transmitting an
500 authorization identity (which means that for these mechanisms the
501 authorization identity is always the empty string), newly defined
502 mechanisms SHOULD be capable of transmitting a non-empty
503 authorization identity. See also section 3.2.
505 2) Character string issues
507 Authentication mechanisms SHOULD encode character strings in UTF-8
508 [UTF-8] (see [CHARSET-POLICY] for IETF policy regarding character
509 sets in IETF protocols). In order to avoid interoperability problems
510 due to differing normalizations, when a mechanisms specifies that
511 character data is to be used as input to a cryptographic and/or
512 comparison function, the mechanism specification MUST detail how the
513 data is to be represented, including any normalizations or other
514 preparations, to ensure proper function. Designers of mechanisms
515 SHOULD use the "SASLprep" profile [SASLprep] of the "stringprep"
516 algorithm [StringPrep] where applicable. However it should be noted
517 that this rule doesn't apply to authorization identities, as they are
520 The preparation can be potentially performed on the client end (upon
521 getting user input or retrieving a value from configuration) or on
522 the server end (upon receiving the value from the client, retrieving
523 a value from its authentication database or generating a new value in
524 order to store in in the authentication database). SASL mechanisms
525 must define which entity (or entities) must perform the preparation.
526 If preparation fails or results in an empty string, the entity doing
527 the preparation MUST fail the authentication exchange.
529 Implementation note: A server end can be represented by multiple
530 processes. For example, it may consist of the server process itself
534 A. Melnikov FORMFEED[Page 9]
540 Internet DRAFT SASL 31 March 2004
543 that communicated with a client, and a command line utility (a server
544 agent) that is able to store passwords/hashes in a database that can
545 be later used by the server. For the server agent the requirement to
546 "fail the authentication exchange" should be interpreted as a
547 requirement to refuse to store the data in the database.
549 3) If the underlying cryptographic technology used by a mechanism
550 supports data integrity than the mechanism specification MUST
551 integrity protect the transmission of an authorization identity and
552 the negotiation of the security layer.
554 4) <<The mechanism should not use the authorization identity in any
555 long-term cryptographic keys/hashes. For example, it would be wrong
556 to change the digest-md5 spec to include the authz id in the a1 hash.
558 The reason is that there may be multiple forms of the authz id that
559 compare the same and some clients may use one form while other
560 clients use a different form.>>
565 6.1. Client sends data first
567 Some mechanisms specify that the first data sent in the
568 authentication protocol exchange is from the client to the server.
570 If a protocol's profile permits the command which initiates an
571 authentication protocol exchange to contain an initial client
572 response, this parameter SHOULD be used with such mechanisms.
574 If the initial client response parameter is not given, or if a
575 protocol's profile does not permit the command which initiates an
576 authentication protocol exchange to contain an initial client
577 response, then the server issues a challenge with no data. The
578 client's response to this challenge is then used as the initial
579 client response. (The server then proceeds to send the next
580 challenge, indicates completion, or indicates failure.)
582 6.1.1. Client sends data first examples
585 The following are two examples of an SECURID authentication [SASL-
586 SECURID] in the SMTP protocol [SMTP]. In the first example below,
587 the client is trying fast reauthentication by sending the initial
590 S: 220-smtp.example.com ESMTP Server
594 A. Melnikov FORMFEED[Page 10]
600 Internet DRAFT SASL 31 March 2004
603 C: EHLO client.example.com
604 S: 250-smtp.example.com Welcome client.example.com
605 S: 250-AUTH GSSAPI SECURID
607 C: AUTH SECURID AG1hZ251cwAxMjM0NTY3OAA=
608 S: 235 Authentication successful
610 The example below is almost identical to the previous, but here the
611 client chooses not to use the initial response parameter.
613 S: 220-smtp.example.com ESMTP Server
614 C: EHLO client.example.com
615 S: 250-smtp.example.com Welcome client.example.com
616 S: 250-AUTH GSSAPI SECURID
620 C: AG1hZ251cwAxMjM0NTY3OAA=
621 S: 235 Authentication successful
623 Additonal examples that show usage of initial response can be found
627 6.2. Server returns success with additional data
629 Some mechanisms may specify that additional data be sent to the
630 client along with an indication of successful completion of the
631 exchange. This data would, for example, authenticate the server to
634 If a protocol's profile does not permit this additional data to be
635 returned with a success indication, then the server issues the data
636 as a server challenge, without an indication of successful
637 completion. The client then responds with no data. After receiving
638 this empty response, the server then indicates successful completion
639 (with no additional data).
641 Client implementors should be aware of an additional failure case
642 that might occur when the profile supports sending the additional
643 data with success. Imagine that an active attacker is trying to
644 impersonate the server and sends faked data, which should be used to
645 authenticate the server to the client, with success. (A similar
646 situation can happen when either the server and/or the client has a
647 bug and they calculate different responses.) After checking the data,
648 the client will think that the authentication exchange has failed,
649 however the server will think that the authentication exchange has
650 completed successfully. At this point the client can not abort the
654 A. Melnikov FORMFEED[Page 11]
660 Internet DRAFT SASL 31 March 2004
663 authentication exchange; it SHOULD close the connection instead.
664 However, if the profile did not support sending of additional data
665 with success, the client could have aborted the exchange at the very
666 last step of the authentication exchange.
668 6.2.1. Server returns success with additional data examples
671 The following are two examples of a DIGEST-MD5 authentication [SASL-
672 DIGEST] in the Extensible Messaging and Presence Protocol [XMPP]. In
673 the first example below, the server is sending mutual authentication
677 xmlns='jabber:client'
678 xmlns:stream='http://etherx.jabber.org/streams'
682 xmlns='jabber:client'
683 xmlns:stream='http://etherx.jabber.org/streams'
688 <mechanisms xmlns='urn:ietf:params:xml:ns:xmpp-sasl'>
689 <mechanism>DIGEST-MD5</mechanism>
690 <mechanism>CRAM-MD5</mechanism>
693 C: <auth xmlns='urn:ietf:params:xml:ns:xmpp-sasl'
694 mechanism='DIGEST-MD5'/>
695 S: <challenge xmlns='urn:ietf:params:xml:ns:xmpp-sasl'>
696 cmVhbG09InNvbWVyZWFsbSIsbm9uY2U9Ik9BNk1HOXRFUUdtMmhoIixxb3A9
697 ImF1dGgiLGNoYXJzZXQ9dXRmLTgsYWxnb3JpdGhtPW1kNS1zZXNzCg==
699 C: <response xmlns='urn:ietf:params:xml:ns:xmpp-sasl'>
700 dXNlcm5hbWU9InNvbWVub2RlIixyZWFsbT0ic29tZXJlYWxtIixub25jZT0i
701 T0E2TUc5dEVRR20yaGgiLGNub25jZT0iT0E2TUhYaDZWcVRyUmsiLG5jPTAw
702 MDAwMDAxLHFvcD1hdXRoLGRpZ2VzdC11cmk9InhtcHAvZXhhbXBsZS5jb20i
703 LHJlc3BvbnNlPWQzODhkYWQ5MGQ0YmJkNzYwYTE1MjMyMWYyMTQzYWY3LGNo
706 S: <success xmlns='urn:ietf:params:xml:ns:xmpp-sasl'>
707 cnNwYXV0aD1lYTQwZjYwMzM1YzQyN2I1NTI3Yjg0ZGJhYmNkZmZmZAo=
710 The example below is almost identical to the previous, but here
714 A. Melnikov FORMFEED[Page 12]
720 Internet DRAFT SASL 31 March 2004
723 the server chooses not to use the additional data with success.
726 xmlns='jabber:client'
727 xmlns:stream='http://etherx.jabber.org/streams'
731 xmlns='jabber:client'
732 xmlns:stream='http://etherx.jabber.org/streams'
737 <mechanisms xmlns='urn:ietf:params:xml:ns:xmpp-sasl'>
738 <mechanism>DIGEST-MD5</mechanism>
739 <mechanism>CRAM-MD5</mechanism>
742 C: <auth xmlns='urn:ietf:params:xml:ns:xmpp-sasl'
743 mechanism='DIGEST-MD5'/>
744 S: <challenge xmlns='urn:ietf:params:xml:ns:xmpp-sasl'>
745 cmVhbG09InNvbWVyZWFsbSIsbm9uY2U9Ik9BNk1HOXRFUUdtMmhoIixxb3A9
746 ImF1dGgiLGNoYXJzZXQ9dXRmLTgsYWxnb3JpdGhtPW1kNS1zZXNzCg==
748 C: <response xmlns='urn:ietf:params:xml:ns:xmpp-sasl'>
749 dXNlcm5hbWU9InNvbWVub2RlIixyZWFsbT0ic29tZXJlYWxtIixub25jZT0i
750 T0E2TUc5dEVRR20yaGgiLGNub25jZT0iT0E2TUhYaDZWcVRyUmsiLG5jPTAw
751 MDAwMDAxLHFvcD1hdXRoLGRpZ2VzdC11cmk9InhtcHAvZXhhbXBsZS5jb20i
752 LHJlc3BvbnNlPWQzODhkYWQ5MGQ0YmJkNzYwYTE1MjMyMWYyMTQzYWY3LGNo
755 S: <challenge xmlns='urn:ietf:params:xml:ns:xmpp-sasl'>
756 cnNwYXV0aD1lYTQwZjYwMzM1YzQyN2I1NTI3Yjg0ZGJhYmNkZmZmZAo=
758 C: <response xmlns='urn:ietf:params:xml:ns:xmpp-sasl'/>
759 S: <success xmlns='urn:ietf:params:xml:ns:xmpp-sasl'/>
761 6.3. Multiple authentications
763 Unless otherwise stated by the protocol's profile, only one
764 successful SASL negotiation may occur in a protocol session. In this
765 case, once an authentication protocol exchange has successfully
766 completed, further attempts to initiate an authentication protocol
769 If a profile explicitly permits multiple successful SASL negotiations
770 to occur, then in no case may multiple security layers be
774 A. Melnikov FORMFEED[Page 13]
780 Internet DRAFT SASL 31 March 2004
783 simultaneously in effect. If a security layer is in effect and a
784 subsequent SASL negotiation selects a second security layer, then the
785 second security layer replaces the first. If a security layer is in
786 effect and a subsequent SASL negotiation selects no security layer,
787 the original security layer remains in effect.
789 Where a protocol profile permits multiple successful SASL
790 negotiations, the profile MUST detail the effect of a failed SASL
791 negotiation upon the previously established authentication state.
792 In particular, it MUST state whether the previously established
793 authenticated state remain in force or whether the connection is to
794 revert to an non-authenticated state. Regardless of the specified
795 effect upon authentication state, the previously negotiated security
796 layer remains in effect.
798 7. The EXTERNAL mechanism
800 The mechanism name associated with external authentication is
803 The client sends an initial response with the UTF-8 encoding of the
804 authorization identity. The form of the authorization identity is
805 further restricted by the application-level protocol's SASL profile.
807 The server uses information, external to SASL, to determine whether
808 the client is permitted to authenticate as the authorization
809 identity. If the client is so authorized, the server indicates
810 successful completion of the authentication exchange; otherwise the
811 server indicates failure.
813 The system providing this external information may be, for example,
814 IPSec [IPSec] or TLS [TLS]. However, the client can make no
815 assumptions as to what information the server can use in determining
816 client authorization. For example, just because TLS was established,
817 doesn't mean that the server will use the information provided by
820 If the client sends the empty string as the authorization identity,
821 the authorization identity is to be derived from authentication
822 credentials which exist in the system that is providing the external
827 The following syntax specification uses the augmented Backus-Naur
828 Form (BNF) notation as specified in [ABNF]. Non-terminals referenced
829 but not defined below are as defined by [UTF-8].
834 A. Melnikov FORMFEED[Page 14]
840 Internet DRAFT SASL 31 March 2004
843 The "extern-init-resp" rule below defines the initial response sent
844 from client to server.
846 extern-init-resp = *( UTF8-char-no-nul )
848 UTF8-char-no-nul = UTF8-1-no-nul / UTF8-2 / UTF8-3 / UTF8-4
850 UTF8-1-no-nul = %x01-7F
853 7.2. Examples of SASL EXTERNAL
855 The following is an example of an EXTERNAL authentication in the SMTP
856 protocol [SMTP]. In this example, the client is proxy authenticating,
857 sending the authorization identity "fred" using in the (optional)
858 initial response. The server has obtained the client's
859 (authentication) identity from an external service, such as IPsec,
860 and has a security policy that permits that identity to assume the
861 identity of the asserted authorization identity.
863 To the protocol profile, the four octet sequence "fred" is an opaque
864 binary data. The SASL protocol profile for SMTP [SMTP-AUTH] specifies
865 that server challenges and client responses are encoded in BASE64
866 [BASE64, section 3]; the BASE64 encoding of "fred" is "ZnJlZA==".
868 S: 220 smtp.example.com ESMTP server ready
869 C: EHLO jgm.example.com
870 S: 250-smtp.example.com
871 S: 250 AUTH DIGEST-MD5 EXTERNAL
872 C: AUTH EXTERNAL ZnJlZA==
873 S: 235 Authentication successful.
875 The following example is almost identical to the one above, but the
876 client doesn't request proxy authentication.
878 S: 220 smtp.example.com ESMTP server ready
879 C: EHLO jgm.example.com
880 S: 250-smtp.example.com
881 S: 250 AUTH DIGEST-MD5 EXTERNAL
883 S: 235 Authentication successful.
886 8. IANA Considerations
894 A. Melnikov FORMFEED[Page 15]
900 Internet DRAFT SASL 31 March 2004
903 8.1. Guidelines for IANA
906 It is requested that IANA updates the SASL mechanisms registry as
910 Change the "Intended usage" of the KERBEROS_V4 and SKEY mechanism
911 registrations to OBSOLETE. Change the "Published specification"
912 of the EXTERNAL mechanism to this document. Updated registration
913 information is provided in Section 8.6.
915 8.2. Registration procedure
918 Registration of a SASL mechanism is done by filling in the template
919 in section 8.5 and sending it via electronic mail to <iana@iana.org>.
920 IANA has the right to reject obviously bogus registrations, but will
921 perform no review of claims made in the registration form. SASL
922 mechanism registrations are currently available at the URL
923 <http://www.iana.org/assignments/sasl-mechanisms>.
925 There is no naming convention for SASL mechanisms; any name that
926 conforms to the syntax of a SASL mechanism name can be registered.
927 However an IETF Standards Track document may reserve a portion of the
928 SASL mechanism namespace ("family of SASL mechanisms") for its own
929 use, amending the registration rules for that portion of the
930 namespace. Each family of SASL mechanisms MUST be identified by a
933 While the registration procedures do not require it, authors of SASL
934 mechanisms are encouraged to seek community review and comment
935 whenever that is feasible. Authors may seek community review by
936 posting a specification of their proposed mechanism as an Internet-
937 Draft. SASL mechanisms intended for widespread use should be
938 standardized through the normal IETF process, when appropriate.
940 8.3. Comments on SASL mechanism registrations
942 Comments on registered SASL mechanisms should first be sent to the
943 "owner" of the mechanism and/or to the SASL WG mailing list.
944 Submitters of comments may, after a reasonable attempt to contact the
945 owner, request IANA to attach their comment to the SASL mechanism
946 registration itself. If IANA approves of this, the comment will be
947 made accessible in conjunction with the SASL mechanism registration
954 A. Melnikov FORMFEED[Page 16]
960 Internet DRAFT SASL 31 March 2004
965 Once a SASL mechanism registration has been published by IANA, the
966 author may request a change to its definition. The change request
967 follows the same procedure as the registration request.
969 The owner of a SASL mechanism may pass responsibility for the SASL
970 mechanism to another person or agency by informing IANA; this can be
971 done without discussion or review.
973 The IESG may reassign responsibility for a SASL mechanism. The most
974 common case of this will be to enable changes to be made to
975 mechanisms where the author of the registration has died, moved out
976 of contact or is otherwise unable to make changes that are important
979 SASL mechanism registrations may not be deleted; mechanisms which are
980 no longer believed appropriate for use can be declared OBSOLETE by a
981 change to their "intended use" field; such SASL mechanisms will be
982 clearly marked in the lists published by IANA.
984 The IESG is considered to be the owner of all SASL mechanisms which
985 are on the IETF standards track.
987 8.5. Registration template
990 Subject: Registration of SASL mechanism X
992 Family of SASL mechanisms: (YES or NO)
994 SASL mechanism name (or prefix for the family):
996 Security considerations:
998 Published specification (optional, recommended):
1000 Person & email address to contact for further information:
1004 (One of COMMON, LIMITED USE or OBSOLETE)
1006 Owner/Change controller:
1008 (Any other information that the author deems interesting may be
1009 added below this line.)
1014 A. Melnikov FORMFEED[Page 17]
1020 Internet DRAFT SASL 31 March 2004
1023 8.6. The EXTERNAL mechanism registration
1025 It is requested that the SASL Mechanism registry [IANA-SASL] entry
1026 for the EXTERNAL mechanism be updated to reflect that this document
1027 now provides its technical specification.
1030 Subject: Updated Registration of SASL mechanism EXTERNAL
1032 Family of SASL mechanisms: NO
1034 SASL mechanism name: EXTERNAL
1036 Security considerations: See RFC XXXX, section 9.
1038 Published specification (optional, recommended): RFC XXXX
1040 Person & email address to contact for further information:
1041 Alexey Melnikov <Alexey.Melnikov@isode.com>
1043 Intended usage: COMMON
1045 Owner/Change controller: IESG <iesg@ietf.org>
1047 Note: Updates existing entry for EXTERNAL
1049 9. Security considerations
1051 Security issues are discussed throughout this memo.
1053 When the client selects a security layer with at least integrity
1054 protection, this protects against an active attacker hijacking the
1055 connection and modifying the authentication exchange to negotiate a
1056 plaintext connection.
1058 When a server or client supports multiple authentication mechanisms,
1059 each of which has a different security strength, it is possible for
1060 an active attacker to cause a party to use the least secure mechanism
1061 supported. To protect against this sort of attack, a client or
1062 server which supports mechanisms of different strengths should have a
1063 configurable minimum strength that it will use. It is not sufficient
1064 for this minimum strength check to only be on the server, since an
1065 active attacker can change which mechanisms the client sees as being
1066 supported, causing the client to send authentication credentials for
1067 its weakest supported mechanism.
1069 The client's selection of a SASL mechanism is done in the clear and
1070 may be modified by an active attacker. It is important for any new
1074 A. Melnikov FORMFEED[Page 18]
1080 Internet DRAFT SASL 31 March 2004
1083 SASL mechanisms to be designed such that an active attacker cannot
1084 obtain an authentication with weaker security properties by modifying
1085 the SASL mechanism name and/or the challenges and responses.
1087 In order to detect Man-in-the-middle (MITM) attacks the client MAY
1088 list available SASL mechanisms both before and after the SASL
1089 security layer is negotiated. This allows the client to detect
1090 active attacks that remove mechanisms from the server's list of
1091 supported mechanisms, and allows the client to ensure that it is
1092 using the best mechanism supported by both client and server. New
1093 protocol profiles SHOULD require servers to make the list of SASL
1094 mechanisms available for the initial authentication available to the
1095 client after security layers are established. Some older protocols
1096 do not require this (or don't support listing of SASL mechanisms once
1097 authentication is complete); for these protocols clients MUST NOT
1098 treat an empty list of SASL mechanisms after authentication as a MITM
1101 Any protocol interactions prior to authentication are performed in
1102 the clear and may be modified by an active attacker. In the case
1103 where a client selects integrity protection, it is important that any
1104 security-sensitive protocol negotiations be performed after
1105 authentication is complete. Protocols should be designed such that
1106 negotiations performed prior to authentication should be either
1107 ignored or revalidated once authentication is complete.
1109 When use of a security layer is negotiated by the authentication
1110 protocol exchange, the receiver should handle gracefully any security
1111 encoded data buffer larger than the defined/negotiated maximal size.
1112 In particular, it must not blindly allocate the amount of memory
1113 specified in the buffer size field, as this might cause the "out of
1114 memory" condition. If the receiver detects a large block, it SHOULD
1115 close the connection.
1117 Distributed server implementations need to be careful in how they
1118 trust other parties and, in particular, authentication secrets should
1119 only be disclosed to other parties that are trusted to manage and use
1120 those secrets in manner acceptable to disclosing party. It should be
1121 noted that, where those secrets are used to provide data
1122 confidentiality protections, if a third party (other than the
1123 discloser/disclosee) has knowledge of some portion of the protected
1124 information, it can use this knowledge in an attack upon other
1125 portions of the protected information.
1127 <<Section 6.3.1 contains a description of a potential class of attack
1128 on a distributed server implementation. The section also gives some
1129 recommendations about mitigating such attacks.>>
1134 A. Melnikov FORMFEED[Page 19]
1140 Internet DRAFT SASL 31 March 2004
1143 "stringprep" and Unicode security considerations apply to
1144 authentication identities, authorization identities and passwords.
1146 The EXTERNAL mechanism provides no security protection; it is
1147 vulnerable to spoofing by either client or server, active attack, and
1148 eavesdropping. It should only be used when external security
1149 mechanisms are present and have sufficient strength.
1153 10.1. Normative References
1155 [ABNF] Crocker, D. (Ed.), Overell, P., "Augmented BNF for Syntax
1156 Specifications: ABNF", RFC 2234, November 1997
1158 [ASCII] American National Standards Institute, "Code Extension
1159 Techniques for Use with the 7-bit Coded Character Set of American
1160 National Standard Code (ASCII) for Information Interchange", FIPS PUB
1163 [CHARSET-POLICY] Alvestrand, H., "IETF Policy on Character Sets and
1164 Languages", RFC 2277, BCP 18, January 1998
1166 [GSSAPI] Linn, J., "Generic Security Service Application Program
1167 Interface, Version 2, Update 1", RFC 2743, January 2000
1169 [KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate
1170 Requirement Levels", RFC 2119, BCP 19, March 1997
1172 [Unicode] The Unicode Consortium, "The Unicode Standard, Version
1173 3.2.0" is defined by "The Unicode Standard, Version 3.0" (Reading,
1174 MA, Addison-Wesley, 2000. ISBN 0-201-61633-5), as amended by the
1175 "Unicode Standard Annex #27: Unicode 3.1"
1176 (http://www.unicode.org/reports/tr27/) and by the "Unicode Standard
1177 Annex #28: Unicode 3.2" (http://www.unicode.org/reports/tr28/).
1179 [Stringprep] Hoffman, P., Blanchet, M., "Preparation of
1180 Internationalized Strings ("stringprep")", RFC 3454, December 2002.
1182 [SASLprep] Zeilenga, K., "SASLprep: Stringprep profile for user names
1183 and passwords", Work in progress, draft-ietf-sasl-saslprep-XX.txt.
1185 [UTF-8] Yergeau, F., "UTF-8, a transformation format of ISO 10646",
1186 RFC 3629, STD 63, November 2003.
1194 A. Melnikov FORMFEED[Page 20]
1200 Internet DRAFT SASL 31 March 2004
1203 10.2. Informative References
1206 [SASL-GSSAPI] Melnikov, A., "SASL GSSAPI mechanisms", work in
1207 progress, draft-ietf-sasl-gssapi-XX.txt, November 2003
1209 [SASL-DIGEST] Leach, P., Newman, C., Melnikov, A., "Using Digest
1210 Authentication as a SASL Mechanism", work in progress, draft-ietf-
1211 sasl-rfc2831bis-XX.txt, replaces RFC 2831
1213 [SASL-OTP] Newman, C., "The One-Time-Password SASL Mechanism", RFC
1216 [SASL-SECURID] Nystrom, M., "The SecurID(r) SASL Mechanism", RFC
1219 [SMTP] Klensin, J., "Simple Mail Transfer Protocol", RFC 2821, April
1222 [SMTP-AUTH] Myers, J., "SMTP Service Extension for Authentication",
1223 RFC 2554, March 1999.
1225 Being revised by Siemborski, R., "SMTP Service Extension for
1226 Authentication", work in progress, draft-siemborski-rfc2554bis-
1229 [XMPP] Saint-Andre, P., "Extensible Messaging and Presence Protocol
1230 (XMPP): Core", work in progress, draft-ietf-xmpp-core-XX.txt.
1232 [BASE64] Josefsson, S., "The Base16, Base32, and Base64 Data
1233 Encodings", RFC 3548, July 2003.
1235 [RFC-INSTRUCTIONS] Postel, J., Reynolds, J., "Instructions to RFC
1236 Authors", RFC 2223, October 1997.
1238 [IANA-SASL] IANA, "SIMPLE AUTHENTICATION AND SECURITY LAYER (SASL)
1239 MECHANISMS", http://www.iana.org/assignments/sasl-mechanisms.
1241 [TLS] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", RFC
1244 [IPSec] Kent, S., and R. Atkinson, "Security Architecture for the
1245 Internet Protocol", RFC 2401, November 1998.
1254 A. Melnikov FORMFEED[Page 21]
1260 Internet DRAFT SASL 31 March 2004
1263 11. Editor's Address
1267 5 Castle Business Village
1270 TW12 2BX, United Kingdom
1272 Email: Alexey.Melnikov@isode.com
1273 URI: http://www.melnikov.ca/
1277 This document is a revision of RFC 2222 written by John G. Myers. He
1278 also contributed significantly to this revision.
1280 <<The multiple authentication attack described in Section 6.3 was
1281 originally described by Magnus Nystrom.>>
1283 Contributions of many members of the SASL mailing list are gratefully
1284 acknowledged, in particular Kurt Zeilenga, Peter Saint-Andre, Rob
1285 Siemborski, Jeffrey Hutzelman, Hallvard B Furuseth, Tony Hansen,
1286 Simon Josefsson, Abhijit Menon-Sen, RL 'Bob' Morgan and Tim Alsop for
1287 proofreading the document and various editorial suggestions.
1290 13. Full Copyright Statement
1292 Copyright (C) The Internet Society (2004). All Rights Reserved.
1294 This document and translations of it may be copied and furnished to
1295 others, and derivative works that comment on or otherwise explain it
1296 or assist in its implementation may be prepared, copied, published
1297 and distributed, in whole or in part, without restriction of any
1298 kind, provided that the above copyright notice and this paragraph are
1299 included on all such copies and derivative works. However, this
1300 document itself may not be modified in any way, such as by removing
1301 the copyright notice or references to the Internet Society or other
1302 Internet organizations, except as needed for the purpose of
1303 developing Internet standards in which case the procedures for
1304 copyrights defined in the Internet Standards process must be
1305 followed, or as required to translate it into languages other than
1308 The limited permissions granted above are perpetual and will not be
1309 revoked by the Internet Society or its successors or assigns.
1314 A. Melnikov FORMFEED[Page 22]
1320 Internet DRAFT SASL 31 March 2004
1323 This document and the information contained herein is provided on an
1324 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
1325 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
1326 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
1327 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
1328 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
1332 Funding for the RFC Editor function is currently provided by the
1335 14. Intellectual Property
1337 The IETF takes no position regarding the validity or scope of any
1338 Intellectual Property Rights or other rights that might be claimed to
1339 pertain to the implementation or use of the technology described in
1340 this document or the extent to which any license under such rights
1341 might or might not be available; nor does it represent that it has
1342 made any independent effort to identify any such rights. Information
1343 on the procedures with respect to rights in RFC documents can be
1344 found in BCP 78 and BCP 79.
1346 Copies of IPR disclosures made to the IETF Secretariat and any
1347 assurances of licenses to be made available, or the result of an
1348 attempt made to obtain a general license or permission for the use of
1349 such proprietary rights by implementers or users of this
1350 specification can be obtained from the IETF on-line IPR repository at
1351 http://www.ietf.org/ipr.
1353 The IETF invites any interested party to bring to its attention any
1354 copyrights, patents or patent applications, or other proprietary
1355 rights that may cover technology that may be required to implement
1356 this standard. Please address the information to the IETF at ietf-
1359 Appendix A. Relation of SASL to transport security
1361 Questions have been raised about the relationship between SASL and
1362 various services (such as IPsec and TLS) which provide a secured
1365 Two of the key features of SASL are:
1367 The separation of the authorization identity from the identity in
1368 the client's credentials. This permits agents such as proxy
1369 servers to authenticate using their own credentials, yet request
1370 the access privileges of the identity for which they are proxying.
1374 A. Melnikov FORMFEED[Page 23]
1380 Internet DRAFT SASL 31 March 2004
1383 Upon successful completion of an authentication exchange, the
1384 server knows the authorization identity the client wishes to use.
1385 This allows servers to move to a "user is authenticated" state in
1388 These features are extremely important to some application protocols,
1389 yet Transport Security services do not always provide them. To
1390 define SASL mechanisms based on these services would be a very messy
1391 task, as the framing of these services would be redundant with the
1392 framing of SASL and some method of providing these important SASL
1393 features would have to be devised.
1395 Sometimes it is desired to enable within an existing connection the
1396 use of a security service which does not fit the SASL model. (TLS is
1397 an example of such a service.) This can be done by adding a command,
1398 for example "STARTTLS", to the protocol. Such a command is outside
1399 the scope of SASL, and should be different from the command which
1400 starts a SASL authentication protocol exchange.
1402 In certain situations, it is reasonable to use SASL underneath one of
1403 these Transport Security services. The transport service would
1404 secure the connection, either service would authenticate the client,
1405 and SASL would negotiate the authorization identity. The SASL
1406 negotiation would be what moves the protocol from "unauthenticated"
1407 to "authenticated" state. The "EXTERNAL" SASL mechanism is
1408 explicitly intended to handle the case where the transport service
1409 secures the connection and authenticates the client and SASL
1410 negotiates the authorization identity.
1412 Appendix B. Relationship to other documents
1414 This document obsoletes RFC 2222. It replaces all portions of RFC
1415 2222 excepting sections 7.1 (Kerberos version 4 mechanism), 7.2
1416 (GSSAPI mechanism), 7.3 (S/Key mechanism). The Kerberos version 4
1417 (KERBEROS_IV) and S/Key (SKEY) mechanisms are now viewed as obsolete.
1418 The GSSAPI mechanism is now separately specified [SASL-GSSAPI].
1420 Appendix C. Changes since RFC 2222
1422 The GSSAPI mechanism was removed. It is now specified in a separate
1423 document [SASL-GSSAPI].
1425 The "KERBEROS_V4" mechanism defined in RFC 2222 is obsolete and has
1428 The "SKEY" mechanism described in RFC 2222 is obsolete and has been
1429 removed. It has been replaced by the OTP mechanism [SASL-OTP].
1434 A. Melnikov FORMFEED[Page 24]
1440 Internet DRAFT SASL 31 March 2004
1443 The overview has been substantially reorganized and clarified.
1445 Clarified the definition and semantics of the authorization identity.
1447 Prohibited the NUL character in authorization identities.
1449 Added a section on character string issues.
1451 The word "must" in the first paragraph of the "Protocol profile
1452 requirements" section was changed to "MUST".
1454 Specified that protocol profiles SHOULD provide a way for clients to
1455 discover available SASL mechanisms.
1457 Made the requirement that protocol profiles specify the semantics of
1458 the authorization identity optional to the protocol profile.
1459 Clarified that such a specification is a refinement of the definition
1460 in the base SASL spec.
1462 Added a requirement discouraging protocol profiles from breaking the
1463 separation between protocol and mechanism.
1465 Mentioned that standards track documents may carve out their own
1466 portions of the SASL mechanism namespace and may amend registration
1467 rules for the portion. However registration of individual SASL
1468 mechanisms is still required.
1470 Specified that the authorization identity in the EXTERNAL mechanism
1471 is encoded in UTF-8.
1473 Added a statement that a protocol profile SHOULD allow challenge data
1474 to be sent with a success indication.
1476 Added a security consideration for the EXTERNAL mechanism.
1478 Clarified sections concerning success with additional data.
1480 Cleaned up IANA considerations/registrations and assembled them in
1483 Updated references and split them into Informative and Normative.
1485 Added text to the Security Considerations section regarding handling
1486 of extremely large SASL blocks.
1488 Replaced UTF-8 ABNF with the reference to the UTF-8 document.
1490 Added text about SASLprep for authentication identities and
1494 A. Melnikov FORMFEED[Page 25]
1500 Internet DRAFT SASL 31 March 2004
1503 passwords. Described where SASLprep preparation should take place.
1505 Added paragraph about verifying authorization identities.
1507 Added a protocol profile requirement to specify interaction between
1508 SASL and TLS security layers.
1510 Added a protocol profile requirement to specify if it supports
1513 Removed the text that seemed to suggest that SASL security layer must
1514 not be used when TLS is available.
1516 Created two subsections in 3.2 to talk separately about proxy
1517 authorization and format of the authorization identities.
1519 Made requirement to verify that an authorization identity is correct
1520 by performing SASLprep a SHOULD, instead of a MUST.
1522 Clarified that each SASL mechanism must decide where SASLprep is
1525 Added 4 new examples for initial response and additional data with
1528 Added text on checking the list of available SASL mechanisms after
1529 negotiating a security layer.
1531 Added definition of "integrity protection" and "confidentiality
1534 Added warning about negotiating no layer once a security layer is
1537 Added new section with guidelines to a SASL mechanism designer.
1539 Added a requirement to specify how an empty initial challenge is
1540 encoded if initial response is supported by a protocol.
1544 This section will be deleted before publication.
1546 1) Clean up definition of different terms like integrity protection
1547 and check if RFC 2828 (Security Glossary) can be used.
1549 2) Kurt is going to do a new description of what SASL is.
1554 A. Melnikov FORMFEED[Page 26]
1560 Internet DRAFT SASL 31 March 2004
1563 3) Sam is going to propose new text that replaces "multiple
1564 authentication" attack.
1566 4) Reorganize sections 1 & 2 as per recent Kurt suggestion (as
1567 modified by Alexey).
1569 5) Clarify empty versa missing "additional data with success".
1614 A. Melnikov FORMFEED[Page 27]
1620 Internet DRAFT SASL 31 March 2004
1623 Status of this Memo .......................................... i
1624 Abstract ..................................................... 2
1625 1. Organization of this document .......................... 2
1626 1.1. How to read this document .............................. 2
1627 1.2. Conventions used in this document ...................... 3
1628 2. Overview ............................................... 3
1629 3. Authentication mechanisms .............................. 4
1630 3.1. Authentication protocol exchange ....................... 4
1631 3.2. Authorization and authentication identities ............ 5
1632 3.2.1. Authorization identities and proxy authentication .... 6
1633 3.2.2. Authorization Identity Format ........................ 6
1634 3.3. Security layers ........................................ 7
1635 4. Protocol profile requirements .......................... 7
1636 5. Mechanism profile guidelines ........................... 9
1637 6. Specific issues ....................................... 10
1638 6.1. Client sends data first ............................... 10
1639 6.1.1. Client sends data first examples .................... 10
1640 6.2. Server returns success with additional data ........... 11
1641 6.2.1. Server returns success with additional data examples 12
1642 6.3. Multiple authentications .............................. 13
1643 7. The EXTERNAL mechanism ................................ 14
1644 7.1. Formal syntax ......................................... 14
1645 7.2. Examples of SASL EXTERNAL ............................. 15
1646 8. IANA Considerations ................................... 15
1647 8.1. Guidelines for IANA ................................... 16
1648 8.2. Registration procedure ................................ 16
1649 8.3. Comments on SASL mechanism registrations .............. 16
1650 8.4. Change control ........................................ 17
1651 8.5. Registration template ................................. 17
1652 8.6. The EXTERNAL mechanism registration ................... 18
1653 9. Security considerations ................................ 18
1654 10. References ........................................... 20
1655 10.1. Normative References ................................. 20
1656 10.2. Informative References ............................... 21
1657 11. Editor's Address ...................................... 22
1658 12. Acknowledgments ....................................... 22
1659 13. Full Copyright Statement .............................. 22
1660 14. Intellectual Property ................................. 23
1661 Appendix A. Relation of SASL to transport security .......... 23
1662 Appendix B. Relationship to other documents ................. 24
1663 Appendix C. Changes since RFC 2222 .......................... 24
1664 Appendix D. ToDo ............................................ 26
1674 A. Melnikov FORMFEED[Page ii]