1 Network Working Group J. Myers
2 Internet Draft April 2001
3 Document: draft-myers-saslrev-01.txt
6 Simple Authentication and Security Layer (SASL)
10 This document is an Internet Draft and is in full conformance with
11 all provisions of Section 10 of RFC 2026.
13 Internet Drafts are working documents of the Internet Engineering
14 Task Force (IETF), its Areas, and its Working Groups. Note that
15 other groups may also distribute working documents as Internet
16 Drafts. Internet Drafts are draft documents valid for a maximum of
17 six months. Internet Drafts may be updated, replaced, or obsoleted
18 by other documents at any time. It is not appropriate to use
19 Internet Drafts as reference material or to cite them other than as
22 The list of current Internet-Drafts can be accessed at
23 http://www.ietf.org/1id-abstracts.html
25 The list of Internet-Draft Shadow Directories can be accessed at
26 http://www.ietf.org/shadow.html.
30 To learn the current status of any Internet-Draft, please check the
31 1id-abstracts.txt listing contained in the Internet-Drafts Shadow
32 Directories on ds.internic.net, nic.nordu.net, ftp.isi.edu, or
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
62 Internet DRAFT SASL April 25, 2001
72 Status of this Memo ............................................... i
73 1. Abstract .................................................... 2
74 2. Organization of this document ............................... 2
75 2.1. How to read this document ................................... 2
76 2.2. Conventions used in this document ........................... 2
77 3. Overview .................................................... 2
78 4. Authentication mechanisms ................................... 3
79 4.1. Authentication protocol exchange ............................ 4
80 4.2. Proxy authentication ........................................ 4
81 4.3. Security layers ............................................. 5
82 5. Protocol profile requirements ............................... 5
83 6. Specific issues ............................................. 6
84 6.1. Client sends data first ..................................... 6
85 6.2. Server returns success with additional data ................. 6
86 6.3. Multiple authentications .................................... 7
87 7. Registration procedures ..................................... 7
88 7.1. Comments on SASL mechanism registrations .................... 7
89 7.2. Location of registered SASL mechanism list .................. 8
90 7.3. Change control .............................................. 8
91 7.4. Registration template ....................................... 8
92 8. The external mechanism ...................................... 9
93 8.1 Formal syntax ............................................... 9
94 8.2 Example ..................................................... 10
95 9. References .................................................. 10
96 10. Security considerations ..................................... 11
97 11. Author's address ............................................ 12
98 Appendix A. Relation of SASL to transport security ................ 12
99 Appendix B. IANA considerations ................................... 13
100 Appendix C. Changes since RFC 2222 ................................ 13
118 Internet DRAFT SASL April 25, 2001
123 SASL provides a method for adding authentication support with an
124 optional security layer to connection-based protocols. It also
125 describes a structure for authentication mechanisms. The result is
126 an abstraction layer between protocols and authentication mechanisms
127 such that any SASL-compatible authentication mechanism can be used
128 with any SASL-compatible protocol.
130 This document describes how a SASL authentication mechanism is
131 structured, how a protocol adds support for SASL, defines the
132 protocol for carrying a security layer over a connection, and defines
133 the EXTERNAL SASL authentication mechanism.
135 2. Organization of this document
137 2.1. How to read this document
139 This document is written to serve two different audiences, protocol
140 designers using this specification to support authentication in their
141 protocol, and implementors of clients or servers for those protocols
142 using this specification.
144 The sections "Overview", "Authentication Mechanisms", "Protocol
145 Profile Requirements", "Specific Issues", and "Security
146 Considerations" cover issues that protocol designers need to
147 understand and address in profiling this specification for use in a
150 Implementors of a protocol using this specification need the
151 protocol-specific profiling information in addition to the
152 information in this document.
154 2.2. Conventions used in this document
156 In examples, "C:" and "S:" indicate lines sent by the client and
159 The key words "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", and "MAY"
160 in this document are to be interpreted as defined in "Key words for
161 use in RFCs to Indicate Requirement Levels" [KEYWORDS].
165 The Simple Authentication and Security Layer (SASL) is a method for
166 adding authentication support to connection-based protocols.
168 The SASL specification has three layers, as indicated in the diagram
174 Internet DRAFT SASL April 25, 2001
177 below. At the top, a protocol definition using SASL specifies a
178 profile, including a command for identifying and authenticating a
179 user to a server and for optionally negotiating a security layer for
180 subsequent protocol interactions. At the bottom, a SASL mechanism
181 definition specifies an authentication mechanism. The SASL
182 framework, specified by this document, constrains the behavior of
183 protocol profiles and mechanisms, separating protocol from mechanism
184 and defining how they interact.
186 SMTP Protocol LDAP Protocol Etc
187 Profile Profile . . .
193 EXTERNAL DIGEST-MD5 Etc
194 SASL mechanism SASL mechanism . . .
196 This separation between the definition of protocols and the
197 definition of authentication mechanisms is crucial. It permits an
198 authentication mechanism to be defined once, making it usable by any
199 SASL protocol profiles. In many implementations, the same SASL
200 mechanism code is used for multiple protocols.
202 4. Authentication mechanisms
204 SASL mechanisms are named by strings, from 1 to 20 characters in
205 length, consisting of upper-case letters, digits, hyphens, and/or
206 underscores. SASL mechanism names must be registered with the IANA.
207 IETF Standards Track documents may override this registration
208 requirement by reserving a portion of the SASL mechanism namespace
209 for their own use; the GSSAPI mechanism specification [SASL-GSSAPI]
210 does this. Procedures for registering new SASL mechanisms are given
211 in the section "Registration procedures".
213 The "sasl-mech" rule below defines the syntax of a SASL mechanism
214 name. This uses the augmented Backus-Naur Form (BNF) notation as
215 specified in [ABNF] and the ABNF core rules as specified in Appendix
216 A of the ABNF specification [ABNF].
218 sasl-mech = 1*20mech-char
219 mech-char = %x41-5A / DIGIT / "-" / "_"
220 ; mech names restricted to uppercase letters,
221 ; digits, "-" and "_"
230 Internet DRAFT SASL April 25, 2001
233 4.1. Authentication protocol exchange
235 A SASL mechanism is responsible for conducting an authentication
236 protocol exchange. This consists of a series of server challenges
237 and client responses, the contents of which are specific to and
238 defined by the mechanism. To the protocol, the challenges and
239 responses are opaque binary tokens of arbitrary length. The
240 protocol's profile then specifies how these binary tokens are then
241 encoded for transfer over the connection.
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 is 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 4.2. Proxy authentication
262 The identity derived from the client's authentication credentials is
263 known as the "authentication identity". With any mechanism,
264 transmitting an authorization identity of the empty string directs
265 the server to derive an authorization identity from the client's
266 authentication identity.
268 If the authorization identity transmitted during the authentication
269 protocol exchange is not the empty string, this is typically referred
270 to as "proxy authentication". This feature permits agents such as
271 proxy servers to authenticate using their own credentials, yet
272 request the access privileges of the identity for which they are
275 As a client might not have the same information as the server,
276 clients SHOULD NOT themselves try to derive authorization identities
277 from auhentication identities when clients could instead transmit an
278 authorization identity of the empty string.
286 Internet DRAFT SASL April 25, 2001
291 If use of a security layer is negotiated by the authentication
292 protocol exchange, the security layer is applied to all subsequent
293 data sent over the connection. The security layer takes effect
294 immediately following the last response of the authentication
295 exchange for data sent by the client and the completion indication
296 for data sent by the server.
298 Once the security layer is in effect, the protocol stream is
299 processed by the security layer into buffers of security encoded
300 data. Each buffer of security encoded data is transferred over the
301 connection as a stream of octets prepended with a four octet field in
302 network byte order that represents the length of the following
303 buffer. The length of the security encoded data buffer must be no
304 larger than the maximum size that was either defined in the mechanism
305 specification or negotiated by the other side during the
306 authentication protocol exchange.
308 5. Protocol profile requirements
310 In order to use this specification, a protocol definition MUST supply
311 the following information:
314 1. A service name, to be selected from the IANA registry of "service"
315 elements for the GSSAPI host-based service name form. [GSSAPI]
316 This service name is made available to the authentication
319 The registry is available at the URL
320 "http://www.isi.edu/in-notes/iana/assignments/gssapi-service-names"
322 2. A definition of the command to initiate the authentication
323 protocol exchange. This command must have as a parameter the name
324 of the mechanism being selected by the client.
326 The command SHOULD have an optional parameter giving an initial
327 response. This optional parameter allows the client to avoid a
328 round trip when using a mechanism which is defined to have the
329 client send data first. When this initial response is sent by the
330 client and the selected mechanism is defined to have the server
331 start with an initial challenge, the command fails. See section
332 6.1 of this document for further information.
334 3. A definition of the method by which the authentication protocol
335 exchange is carried out, including how the challenges and
336 responses are encoded, how the server indicates completion or
342 Internet DRAFT SASL April 25, 2001
345 failure of the exchange, how the client aborts an exchange, and
346 how the exchange method interacts with any line length limits in
349 The command SHOULD have a method for the server to include an
350 optional challenge with a success notification. This allows the
351 server to avoid a round trip when using a mechanism which is
352 defined to have the server send additional data along with the
353 indication of successful completion. See section 6.2 of this
354 document for further information.
356 4. Identification of the octet where any negotiated security layer
357 starts to take effect, in both directions.
359 5. A specification of how the authorization identity passed from the
360 client to the server is to be interpreted.
362 In addition, a protocol definition SHOULD specify a mechanism
363 through which a client may obtain the names of the SASL mechanisms
364 available to it. This is typically done through the protocol's
365 extensions or capabilities mechanism.
369 6.1. Client sends data first
371 Some mechanisms specify that the first data sent in the
372 authentication protocol exchange is from the client to the server.
374 If a protocol's profile permits the command which initiates an
375 authentication protocol exchange to contain an initial client
376 response, this parameter SHOULD be used with such mechanisms.
378 If the initial client response parameter is not given, or if a
379 protocol's profile does not permit the command which initiates an
380 authentication protocol exchange to contain an initial client
381 response, then the server issues a challenge with no data. The
382 client's response to this challenge is then used as the initial
383 client response. (The server then proceeds to send the next
384 challenge, indicates completion, or indicates failure.)
386 6.2. Server returns success with additional data
388 Some mechanisms may specify that additional data be sent to the
389 client along with an indication of successful completion of the
390 exchange. This data would, for example, authenticate the server to
398 Internet DRAFT SASL April 25, 2001
401 If a protocol's profile does not permit this additional data to be
402 returned with a success indication, then the server issues the data
403 as a server challenge, without an indication of successful
404 completion. The client then responds with no data. After receiving
405 this empty response, the server then indicates successful completion
406 (with no additional data).
408 6.3. Multiple authentications
410 Unless otherwise stated by the protocol's profile, only one
411 successful SASL negotiation may occur in a protocol session. In this
412 case, once an authentication protocol exchange has successfully
413 completed, further attempts to initiate an authentication protocol
416 In the case that a profile explicitly permits multiple successful
417 SASL negotiations to occur, then in no case may multiple security
418 layers be simultaneously in effect. If a security layer is in effect
419 and a subsequent SASL negotiation selects no security layer, the
420 original security layer remains in effect. If a security layer is in
421 effect and a subsequent SASL negotiation selects a second security
422 layer, then the second security layer replaces the first.
424 7. Registration procedures
426 Registration of a SASL mechanism is done by filling in the template
427 in section 7.4 and sending it in to iana@iana.org. IANA has the
428 right to reject obviously bogus registrations, but will perform no
429 review of claims made in the registration form.
431 There is no naming convention for SASL mechanisms; any name that
432 conforms to the syntax of a SASL mechanism name can be registered.
434 While the registration procedures do not require it, authors of SASL
435 mechanisms are encouraged to seek community review and comment
436 whenever that is feasible. Authors may seek community review by
437 posting a specification of their proposed mechanism as an internet-
438 draft. SASL mechanisms intended for widespread use should be
439 standardized through the normal IETF process, when appropriate.
441 7.1. Comments on SASL mechanism registrations
443 Comments on registered SASL mechanisms should first be sent to the
444 "owner" of the mechanism. Submitters of comments may, after a
445 reasonable attempt to contact the owner, request IANA to attach their
446 comment to the SASL mechanism registration itself. If IANA approves
447 of this the comment will be made accessible in conjunction with the
448 SASL mechanism registration itself.
454 Internet DRAFT SASL April 25, 2001
457 7.2. Location of registered SASL mechanism list
459 SASL mechanism registrations are available at the URL
460 "http://www.isi.edu/in-notes/iana/assignments/sasl-mechanisms" The
461 SASL mechanism description and other supporting material may also be
462 published as an Informational RFC by sending it to
463 "rfc-editor@rfc-editor.org" (please follow the instructions to RFC
464 authors [RFC-INSTRUCTIONS]).
468 Once a SASL mechanism registration has been published by IANA, the
469 author may request a change to its definition. The change request
470 follows the same procedure as the registration request.
472 The owner of a SASL mechanism may pass responsibility for the SASL
473 mechanism to another person or agency by informing IANA; this can be
474 done without discussion or review.
476 The IESG may reassign responsibility for a SASL mechanism. The most
477 common case of this will be to enable changes to be made to
478 mechanisms where the author of the registration has died, moved out
479 of contact or is otherwise unable to make changes that are important
482 SASL mechanism registrations may not be deleted; mechanisms which are
483 no longer believed appropriate for use can be declared OBSOLETE by a
484 change to their "intended use" field; such SASL mechanisms will be
485 clearly marked in the lists published by IANA.
487 The IESG is considered to be the owner of all SASL mechanisms which
488 are on the IETF standards track.
490 7.4. Registration template
494 Subject: Registration of SASL mechanism X
498 Security considerations:
500 Published specification (optional, recommended):
502 Person & email address to contact for further information:
510 Internet DRAFT SASL April 25, 2001
513 (One of COMMON, LIMITED USE or OBSOLETE)
515 Owner/Change controller:
517 (Any other information that the author deems interesting may be
518 added below this line.)
520 8. The external mechanism
522 The mechanism name associated with external authentication is
525 The client sends an initial response with the UTF-8 encoding of the
526 authorization identity.
528 The server uses information, external to SASL, to determine whether
529 the client is authorized to authenticate as the authorization
530 identity. If the client is so authorized, the server indicates
531 successful completion of the authentication exchange; otherwise the
532 server indicates failure.
534 The system providing this external information may be, for example,
537 If the client sends the empty string as the authorization identity
538 (thus requesting the authorization identity be derived from the
539 client's authentication credentials), the authorization identity is
540 to be derived from authentication credentials which exist in the
541 system which is providing the external authentication.
545 The following syntax specification uses the augmented Backus-Naur
546 Form (BNF) notation as specified in [ABNF]. This uses the ABNF core
547 rules as specified in Appendix A of the ABNF specification [ABNF].
549 The "initial-response" rule below defines the initial response sent
550 from client to server.
552 initial-response = *UTF8
553 UTF8 = %x01-7F / UTF8-2 / UTF8-3 / UTF8-4
554 UTF8-loworder = %x80-BF
555 UTF8-2 = %xC1-DF UTF8-loworder
556 ; Disallow overlong sequences beginning with 0xC0.
557 UTF8-3 = (%xE0 %xA0-BF UTF8-loworder) /
558 (%xE1-EC 2UTF8-loworder) /
559 (%xED %x80-9F UTF8-loworder) /
560 (%xEE 2UTF8-loworder) /
566 Internet DRAFT SASL April 25, 2001
569 (%xEF %x80-BE UTF8-loworder) /
571 ; Disallow overlong sequences beginning with 0xE0,
572 ; disallow encoded surrogate characters, and
573 ; disallow U+FFFE, U+FFFF.
574 UTF8-4 = (%xF0 %x90-BF 2UTF8-loworder) /
575 (%xF1-F7 3UTF8-loworder)
576 ; Disallow overlong sequences beginning with 0xF0.
580 The following is an example of an EXTERNAL authentication in the SMTP
581 protocol [SMTP-AUTH]. In this example, the client is proxy
582 authenticating, sending the authorization id "fred". The server has
583 determined the client's identity through IPsec and has a security
584 policy that permits that identity to proxy authenticate as any other
587 To the protocol profile, the four octet sequence "fred" is an opaque
588 binary blob. The SASL protocol profile for SMTP specifies that
589 server challenges and client responses are encoded in BASE64; the
590 BASE64 encoding of "fred" is "ZnJlZA==".
592 S: 220 smtp.example.com ESMTP server ready
593 C: EHLO jgm.example.com
594 S: 250-smtp.example.com
595 S: 250 AUTH DIGEST-MD5 EXTERNAL
596 C: AUTH EXTERNAL ZnJlZA==
597 S: 235 Authentication successful.
601 [ABNF] Crocker, Overell, "Augmented BNF for Syntax Specifications:
602 ABNF", RFC 2234, November 1997
604 [GSSAPI] Linn, "Generic Security Service Application Program
605 Interface, Version 2, Update 1", RFC 2743, January 2000
607 [KEYWORDS] Bradner, "Key words for use in RFCs to Indicate
608 Requirement Levels", RFC 2119, March 1997
610 [RFC-INSTRUCTIONS] Postel, Reynolds, "Instructions to RFC Authors",
611 RFC 2223, October 1997
613 [SASL-GSSAPI] Myers, "SASL GSSAPI mechanisms", draft-ietf-cat-sasl-
614 gssapi-XX.txt, September 2000
616 [SASL-OTP] Newman, "The One-Time-Password SASL Mechanism", RFC 2444,
622 Internet DRAFT SASL April 25, 2001
627 [SMTP-AUTH] Myers, "SMTP Service Extension for Authentication", RFC
630 [UTF-8] Yergeau, "UTF-8, a transformation format of ISO 10646", RFC
633 10. Security considerations
635 Security issues are discussed throughout this memo.
637 The mechanisms that support integrity protection are designed such
638 that the negotiation of the security layer and authorization identity
639 is integrity protected. When the client selects a security layer
640 with at least integrity protection, this protects against an active
641 attacker hijacking the connection and modifying the authentication
642 exchange to negotiate a plaintext connection.
644 When a server or client supports multiple authentication mechanisms,
645 each of which has a different security strength, it is possible for
646 an active attacker to cause a party to use the least secure mechanism
647 supported. To protect against this sort of attack, a client or
648 server which supports mechanisms of different strengths should have a
649 configurable minimum strength that it will use. It is not sufficient
650 for this minimum strength check to only be on the server, since an
651 active attacker can change which mechanisms the client sees as being
652 supported, causing the client to send authentication credentials for
653 its weakest supported mechanism.
655 The client's selection of a SASL mechanism is done in the clear and
656 may be modified by an active attacker. It is important for any new
657 SASL mechanisms to be designed such that an active attacker cannot
658 obtain an authentication with weaker security properties by modifying
659 the SASL mechanism name and/or the challenges and responses.
661 Any protocol interactions prior to authentication are performed in
662 the clear and may be modified by an active attacker. In the case
663 where a client selects integrity protection, it is important that any
664 security-sensitive protocol negotiations be performed after
665 authentication is complete. Protocols should be designed such that
666 negotiations performed prior to authentication should be either
667 ignored or revalidated once authentication is complete.
669 The EXTERNAL mechanism provides no security protection; it is
670 vulnerable to spoofing by either client or server, active attack, and
671 eavesdropping. It should only be used when external security
672 mechanisms are present and have sufficient strength.
678 Internet DRAFT SASL April 25, 2001
684 Netscape Communications
685 501 E. Middlefield Road
687 Mountain View, CA 94043-4042
689 Email: jgmyers@netscape.com
691 Appendix A. Relation of SASL to transport security
693 Questions have been raised about the relationship between SASL and
694 various services (such as IPsec and TLS) which provide a secured
697 Two of the key features of SASL are:
700 1. The separation of the authorization identity from the identity in
701 the client's credentials. This permits agents such as proxy
702 servers to authenticate using their own credentials, yet request
703 the access privileges of the identity for which they are proxying.
705 2. Upon successful completion of an authentication exchange, the
706 server knows the authorization identity the client wishes to use.
707 This allows servers to move to a "user is authenticated" state in
710 These features are extremely important to some application protocols,
711 yet Transport Security services do not always provide them. To
712 define SASL mechanisms based on these services would be a very messy
713 task, as the framing of these services would be redundant with the
714 framing of SASL and some method of providing these important SASL
715 features would have to be devised.
717 Sometimes it is desired to enable within an existing connection the
718 use of a security service which does not fit the SASL model. (TLS is
719 an example of such a service.) This can be done by adding a command,
720 for example "STARTTLS", to the protocol. Such a command is outside
721 the scope of SASL, and should be different from the command which
722 starts a SASL authentication protocol exchange.
724 In certain situations, it is reasonable to use SASL underneath one of
725 these Transport Security services. The transport service would
726 secure the connection, either service would authenticate the client,
727 and SASL would negotiate the authorization identity. The SASL
728 negotiation would be what moves the protocol from "unauthenticated"
734 Internet DRAFT SASL April 25, 2001
737 to "authenticated" state. The "EXTERNAL" SASL mechanism is
738 explicitly intended to handle the case where the transport service
739 secures the connection and authenticates the client and SASL
740 negotiates the authorization identity.
742 When using SASL underneath a sufficiently strong Transport Security
743 service, a SASL security layer would most likely be redundant. The
744 client and server would thus probably want to negotiate off the use
745 of a SASL security layer.
747 Appendix B. IANA considerations
749 The IANA is directed to modify the SASL mechanisms registry as
753 1. Change the "Intended usage" of the KERBEROS_V4 and SKEY mechanism
754 registrations to OBSOLETE.
756 2. Change the "Published specification" of the EXTERNAL mechanism to
759 Appendix C. Changes since RFC 2222
761 The GSSAPI mechanism was removed. It is now specified in a separate
762 document [SASL-GSSAPI].
764 The "KERBEROS_V4" mechanism defined in RFC 2222 is obsolete and has
767 The "SKEY" mechanism described in RFC 2222 is obsolete and has been
768 removed. It has been replaced by the OTP mechanism [SASL-OTP].
770 The overview has been substantially reorganized and clarified.
772 The word "must" in the first paragraph of the "Protocol profile
773 requirements" section was changed to "MUST".
775 Specified that protocol profiles SHOULD provide a way for clients to
776 discover available SASL mechanisms.
778 Specified that the authorization identity in the EXTERNAL mechanism
781 Added a statement that a protocol profile SHOULD allow challenge data
782 to be sent with a success indication.
784 Added a security consideration for the EXTERNAL mechansim.
790 Internet DRAFT SASL April 25, 2001
793 Clarified sections concerning success with addtional data.