imapext-2007
view docs/rfc/rfc4422.txt @ 0:ada5e610ab86
imap-2007e
| author | yuuji@gentei.org |
|---|---|
| date | Mon, 14 Sep 2009 15:17:45 +0900 |
| parents | |
| children |
line source
7 Network Working Group A. Melnikov, Ed.
8 Request for Comments: 4422 Isode Limited
9 Obsoletes: 2222 K. Zeilenga, Ed.
10 Category: Standards Track OpenLDAP Foundation
11 June 2006
14 Simple Authentication and Security Layer (SASL)
16 Status of This Memo
18 This document specifies an Internet standards track protocol for the
19 Internet community, and requests discussion and suggestions for
20 improvements. Please refer to the current edition of the "Internet
21 Official Protocol Standards" (STD 1) for the standardization state
22 and status of this protocol. Distribution of this memo is unlimited.
24 Copyright Notice
26 Copyright (C) The Internet Society (2006).
28 Abstract
30 The Simple Authentication and Security Layer (SASL) is a framework
31 for providing authentication and data security services in
32 connection-oriented protocols via replaceable mechanisms. It
33 provides a structured interface between protocols and mechanisms.
34 The resulting framework allows new protocols to reuse existing
35 mechanisms and allows old protocols to make use of new mechanisms.
36 The framework also provides a protocol for securing subsequent
37 protocol exchanges within a data security layer.
39 This document describes how a SASL mechanism is structured, describes
40 how protocols include support for SASL, and defines the protocol for
41 carrying a data security layer over a connection. In addition, this
42 document defines one SASL mechanism, the EXTERNAL mechanism.
44 This document obsoletes RFC 2222.
58 Melnikov & Zeilenga Standards Track [Page 1]
60 RFC 4422 SASL June 2006
63 Table of Contents
65 1. Introduction ....................................................3
66 1.1. Document Audiences .........................................4
67 1.2. Relationship to Other Documents ............................4
68 1.3. Conventions ................................................5
69 2. Identity Concepts ...............................................5
70 3. The Authentication Exchange .....................................6
71 3.1. Mechanism Naming ...........................................8
72 3.2. Mechanism Negotiation ......................................9
73 3.3. Request Authentication Exchange ............................9
74 3.4. Challenges and Responses ...................................9
75 3.4.1. Authorization Identity String ......................10
76 3.5. Aborting Authentication Exchanges .........................10
77 3.6. Authentication Outcome ....................................11
78 3.7. Security Layers ...........................................12
79 3.8. Multiple Authentications ..................................12
80 4. Protocol Requirements ..........................................13
81 5. Mechanism Requirements .........................................16
82 6. Security Considerations ........................................18
83 6.1. Active Attacks ............................................19
84 6.1.1. Hijack Attacks .....................................19
85 6.1.2. Downgrade Attacks ..................................19
86 6.1.3. Replay Attacks .....................................20
87 6.1.4. Truncation Attacks .................................20
88 6.1.5. Other Active Attacks ...............................20
89 6.2. Passive Attacks ...........................................20
90 6.3. Re-keying .................................................21
91 6.4. Other Considerations ......................................21
92 7. IANA Considerations ............................................22
93 7.1. SASL Mechanism Registry ...................................22
94 7.2. Registration Changes ......................................26
95 8. References .....................................................26
96 8.1. Normative References ......................................26
97 8.2. Informative References ....................................27
98 9. Acknowledgements ...............................................28
99 Appendix A. The SASL EXTERNAL Mechanism ..........................29
100 A.1. EXTERNAL Technical Specification ..........................29
101 A.2. SASL EXTERNAL Examples ....................................30
102 A.3. Security Considerations ...................................31
103 Appendix B. Changes since RFC 2222 ...............................31
114 Melnikov & Zeilenga Standards Track [Page 2]
116 RFC 4422 SASL June 2006
119 1. Introduction
121 The Simple Authentication and Security Layer (SASL) is a framework
122 for providing authentication and data security services in
123 connection-oriented protocols via replaceable mechanisms. SASL
124 provides a structured interface between protocols and mechanisms.
125 SASL also provides a protocol for securing subsequent protocol
126 exchanges within a data security layer. The data security layer can
127 provide data integrity, data confidentiality, and other services.
129 SASL's design is intended to allow new protocols to reuse existing
130 mechanisms without requiring redesign of the mechanisms and allows
131 existing protocols to make use of new mechanisms without redesign of
132 protocols.
134 SASL is conceptually a framework that provides an abstraction layer
135 between protocols and mechanisms as illustrated in the following
136 diagram.
138 SMTP LDAP XMPP Other protocols ...
139 \ | | /
140 \ | | /
141 SASL abstraction layer
142 / | | \
143 / | | \
144 EXTERNAL GSSAPI PLAIN Other mechanisms ...
146 It is through the interfaces of this abstraction layer that the
147 framework allows any protocol to utilize any mechanism. While this
148 layer does generally hide the particulars of protocols from
149 mechanisms and the particulars of mechanisms from protocols, this
150 layer does not generally hide the particulars of mechanisms from
151 protocol implementations. For example, different mechanisms require
152 different information to operate, some of them use password-based
153 authentication, some of then require realm information, others make
154 use of Kerberos tickets, certificates, etc. Also, in order to
155 perform authorization, server implementations generally have to
156 implement identity mapping between authentication identities, whose
157 form is mechanism specific, and authorization identities, whose form
158 is application protocol specific. Section 2 discusses identity
159 concepts.
161 It is possible to design and implement this framework in ways that do
162 abstract away particulars of similar mechanisms. Such a framework
163 implementation, as well as mechanisms implementations, could be
164 designed not only to be shared by multiple implementations of a
165 particular protocol but to be shared by implementations of multiple
166 protocols.
170 Melnikov & Zeilenga Standards Track [Page 3]
172 RFC 4422 SASL June 2006
175 The framework incorporates interfaces with both protocols and
176 mechanisms in which authentication exchanges are carried out.
177 Section 3 discusses SASL authentication exchanges.
179 To use SASL, each protocol (amongst other items) provides a method
180 for identifying which mechanism is to be used, a method for exchange
181 of mechanism-specific server-challenges and client-responses, and a
182 method for communicating the outcome of the authentication exchange.
183 Section 4 discusses SASL protocol requirements.
185 Each SASL mechanism defines (amongst other items) a series of
186 server-challenges and client-responses that provide authentication
187 services and negotiate data security services. Section 5 discusses
188 SASL mechanism requirements.
190 Section 6 discusses security considerations. Section 7 discusses
191 IANA considerations. Appendix A defines the SASL EXTERNAL mechanism.
193 1.1. Document Audiences
195 This document is written to serve several different audiences:
197 - protocol designers using this specification to support
198 authentication in their protocol,
200 - mechanism designers that define new SASL mechanisms, and
202 - implementors of clients or servers for those protocols that
203 support SASL.
205 While the document organization is intended to allow readers to focus
206 on details relevant to their engineering, readers are encouraged to
207 read and understand all aspects of this document.
209 1.2. Relationship to Other Documents
211 This document obsoletes RFC 2222. It replaces all portions of RFC
212 2222 excepting sections 7.1 (the KERBEROS_IV mechanism), 7.2 (the
213 GSSAPI mechanism), 7.3 (the SKEY mechanism). The KERBEROS_IV and
214 SKEY mechanisms are now viewed as obsolete and their specifications
215 provided in RFC 2222 are Historic. The GSSAPI mechanism is now
216 separately specified [SASL-GSSAPI].
218 Appendix B provides a summary of changes since RFC 2222.
226 Melnikov & Zeilenga Standards Track [Page 4]
228 RFC 4422 SASL June 2006
231 1.3. Conventions
233 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
234 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
235 document are to be interpreted as described in BCP 14 [RFC2119].
237 Character names in this document use the notation for code points and
238 names from the Unicode Standard [Unicode]. For example, the letter
239 "a" may be represented as either <U+0061> or <LATIN SMALL LETTER A>.
241 Note: a glossary of terms used in Unicode can be found in [Glossary].
242 Information on the Unicode character encoding model can be found in
243 [CharModel].
245 In examples, "C:" and "S:" indicate lines of data to be sent by the
246 client and server, respectively. Lines have been wrapped for
247 improved readability.
249 2. Identity Concepts
251 In practice, authentication and authorization may involve multiple
252 identities, possibly in different forms (simple username, Kerberos
253 principal, X.500 Distinguished Name, etc.), possibly with different
254 representations (e.g., ABNF-described UTF-8 encoded Unicode character
255 string, BER-encoded Distinguished Name). While technical
256 specifications often prescribe both the identity form and
257 representation used on the network, different identity forms and/or
258 representations may be (and often are) used within implementations.
259 How identities of different forms relate to each other is, generally,
260 a local matter. In addition, the forms and representations used
261 within an implementation are a local matter.
263 However, conceptually, the SASL framework involves two identities:
265 1) an identity associated with the authentication credentials
266 (termed the authentication identity), and
268 2) an identity to act as (termed the authorization identity).
270 SASL mechanism specifications describe the credential form(s) (e.g.,
271 X.509 certificates, Kerberos tickets, simple username/password) used
272 to authenticate the client, including (where appropriate) the syntax
273 and semantics of authentication identities carried in the
274 credentials. SASL protocol specifications describe the identity
275 form(s) used in authorization and, in particular, prescribe the
276 syntax and semantics of the authorization identity character string
277 to be transferred by mechanisms.
282 Melnikov & Zeilenga Standards Track [Page 5]
284 RFC 4422 SASL June 2006
287 The client provides its credentials (which include or imply an
288 authentication identity) and, optionally, a character string
289 representing the requested authorization identity as part of the SASL
290 exchange. When this character string is omitted or empty, the client
291 is requesting to act as the identity associated with the credentials
292 (e.g., the user is requesting to act as the authentication identity).
294 The server is responsible for verifying the client's credentials and
295 verifying that the identity it associates with the client's
296 credentials (e.g., the authentication identity) is allowed to act as
297 the authorization identity. A SASL exchange fails if either (or
298 both) of these verifications fails. (The SASL exchange may fail for
299 other reasons, such as service authorization failure.)
301 However, the precise form(s) of the authentication identities (used
302 within the server in its verifications, or otherwise) and the precise
303 form(s) of the authorization identities (used in making authorization
304 decisions, or otherwise) are beyond the scope of SASL and this
305 specification. In some circumstances, the precise identity forms
306 used in some context outside of the SASL exchange may be dictated by
307 other specifications. For instance, an identity assumption
308 authorization (proxy authorization) policy specification may dictate
309 how authentication and authorization identities are represented in
310 policy statements.
312 3. The Authentication Exchange
314 Each authentication exchange consists of a message from the client to
315 the server requesting authentication via a particular mechanism,
316 followed by one or more pairs of challenges from the server and
317 responses from the client, followed by a message from the server
318 indicating the outcome of the authentication exchange. (Note:
319 exchanges may also be aborted as discussed in Section 3.5.)
321 The following illustration provides a high-level overview of an
322 authentication exchange.
324 C: Request authentication exchange
325 S: Initial challenge
326 C: Initial response
327 <additional challenge/response messages>
328 S: Outcome of authentication exchange
330 If the outcome is successful and a security layer was negotiated,
331 this layer is then installed (see Section 3.7). This also applies to
332 the following illustrations.
338 Melnikov & Zeilenga Standards Track [Page 6]
340 RFC 4422 SASL June 2006
343 Some mechanisms specify that the first data sent in the
344 authentication exchange is from the client to the server. Protocols
345 may provide an optional initial response field in the request message
346 to carry this data. Where the mechanism specifies that the first
347 data sent in the exchange is from the client to the server, the
348 protocol provides an optional initial response field, and the client
349 uses this field, the exchange is shortened by one round-trip:
351 C: Request authentication exchange + Initial response
352 <additional challenge/response messages>
353 S: Outcome of authentication exchange
355 Where the mechanism specifies that the first data sent in the
356 exchange is from the client to the server and this field is
357 unavailable or unused, the client request is followed by an empty
358 challenge.
360 C: Request authentication exchange
361 S: Empty Challenge
362 C: Initial Response
363 <additional challenge/response messages>
364 S: Outcome of authentication exchange
366 Should a client include an initial response in its request where the
367 mechanism does not allow the client to send data first, the
368 authentication exchange fails.
370 Some mechanisms specify that the server is to send additional data to
371 the client when indicating a successful outcome. Protocols may
372 provide an optional additional data field in the outcome message to
373 carry this data. Where the mechanism specifies that the server is to
374 return additional data with the successful outcome, the protocol
375 provides an optional additional data field in the outcome message,
376 and the server uses this field, the exchange is shortened by one
377 round-trip:
379 C: Request authentication exchange
380 S: Initial challenge
381 C: Initial response
382 <additional challenge/response messages>
383 S: Outcome of authentication exchange with
384 additional data with success
386 Where the mechanism specifies that the server is to return additional
387 data to the client with a successful outcome and this field is
388 unavailable or unused, the additional data is sent as a challenge
389 whose response is empty. After receiving this response, the server
390 then indicates the successful outcome.
394 Melnikov & Zeilenga Standards Track [Page 7]
396 RFC 4422 SASL June 2006
399 C: Request authentication exchange
400 S: Initial challenge
401 C: Initial response
402 <additional challenge/response messages>
403 S: Additional data challenge
404 C: Empty Response
405 S: Outcome of authentication exchange
407 Where mechanisms specify that the first data sent in the exchange is
408 from the client to the server and additional data is sent to the
409 client along with indicating a successful outcome, and the protocol
410 provides fields supporting both, then the exchange takes two fewer
411 round-trips:
413 C: Request authentication exchange + Initial response
414 <additional challenge/response messages>
415 S: Outcome of authentication exchange
416 with additional data with success
418 instead of:
420 C: Request authentication exchange
421 S: Empty Challenge
422 C: Initial Response
423 <additional challenge/response messages>
424 S: Additional data challenge
425 C: Empty Response
426 S: Outcome of authentication exchange
428 3.1. Mechanism Naming
430 SASL mechanisms are named by character strings, from 1 to 20
431 characters in length, consisting of ASCII [ASCII] uppercase letters,
432 digits, hyphens, and/or underscores. In the following Augmented
433 Backus-Naur Form (ABNF) [RFC4234] grammar, the <sasl-mech> production
434 defines the syntax of a SASL mechanism name.
436 sasl-mech = 1*20mech-char
437 mech-char = UPPER-ALPHA / DIGIT / HYPHEN / UNDERSCORE
438 ; mech-char is restricted to A-Z (uppercase only), 0-9, -, and _
439 ; from ASCII character set.
441 UPPER-ALPHA = %x41-5A ; A-Z (uppercase only)
442 DIGIT = %x30-39 ; 0-9
443 HYPHEN = %x2D ; hyphen (-)
444 UNDERSCORE = %x5F ; underscore (_)
446 SASL mechanism names are registered as discussed in Section 7.1.
450 Melnikov & Zeilenga Standards Track [Page 8]
452 RFC 4422 SASL June 2006
455 3.2. Mechanism Negotiation
457 Mechanism negotiation is protocol specific.
459 Commonly, a protocol will specify that the server advertises
460 supported and available mechanisms to the client via some facility
461 provided by the protocol, and the client will then select the "best"
462 mechanism from this list that it supports and finds suitable.
464 Note that the mechanism negotiation is not protected by the
465 subsequent authentication exchange and hence is subject to downgrade
466 attacks if not protected by other means.
468 To detect downgrade attacks, a protocol can allow the client to
469 discover available mechanisms subsequent to the authentication
470 exchange and installation of data security layers with at least data
471 integrity protection. This allows the client to detect changes to
472 the list of mechanisms supported by the server.
474 3.3. Request Authentication Exchange
476 The authentication exchange is initiated by the client by requesting
477 authentication via a mechanism it specifies. The client sends a
478 message that contains the name of the mechanism to the server. The
479 particulars of the message are protocol specific.
481 Note that the name of the mechanism is not protected by the
482 mechanism, and hence is subject to alteration by an attacker if not
483 integrity protected by other means.
485 Where the mechanism is defined to allow the client to send data
486 first, and the protocol's request message includes an optional
487 initial response field, the client may include the response to the
488 initial challenge in the authentication request message.
490 3.4. Challenges and Responses
492 The authentication exchange involves one or more pairs of server-
493 challenges and client-responses, the particulars of which are
494 mechanism specific. These challenges and responses are enclosed in
495 protocol messages, the particulars of which are protocol specific.
497 Through these challenges and responses, the mechanism may:
499 - authenticate the client to the server,
501 - authenticate the server to the client,
506 Melnikov & Zeilenga Standards Track [Page 9]
508 RFC 4422 SASL June 2006
511 - transfer an authorization identity string,
513 - negotiate a security layer, and
515 - provide other services.
517 The negotiation of the security layer may involve negotiation of the
518 security services to be provided in the layer, how these services
519 will be provided, and negotiation of a maximum cipher-text buffer
520 size each side is able to receive in the layer (see Section 3.6).
522 After receiving an authentication request or any client response, the
523 server may issue a challenge, abort the exchange, or indicate the
524 outcome of an exchange. After receiving a challenge, a client
525 mechanism may issue a response or abort the exchange.
527 3.4.1. Authorization Identity String
529 The authorization identity string is a sequence of zero or more
530 Unicode [Unicode] characters, excluding the NUL (U+0000) character,
531 representing the identity to act as.
533 If the authorization identity string is absent, the client is
534 requesting to act as the identity the server associates with the
535 client's credentials. An empty string is equivalent to an absent
536 authorization identity.
538 A non-empty authorization identity string indicates that the client
539 wishes to act as the identity represented by the string. In this
540 case, the form of identity represented by the string, as well as the
541 precise syntax and semantics of the string, is protocol specific.
543 While the character encoding schema used to transfer the
544 authorization identity string in the authentication exchange is
545 mechanism specific, mechanisms are expected to be capable of carrying
546 the entire Unicode repertoire (with the exception of the NUL
547 character).
549 3.5. Aborting Authentication Exchanges
551 A client or server may desire to abort an authentication exchange if
552 it is unwilling or unable to continue (or enter into).
554 A client may abort the authentication exchange by sending a message,
555 the particulars of which are protocol specific, to the server,
556 indicating that the exchange is aborted. The server may be required
557 by the protocol to return a message in response to the client's abort
558 message.
562 Melnikov & Zeilenga Standards Track [Page 10]
564 RFC 4422 SASL June 2006
567 Likewise, a server may abort the authentication exchange by sending a
568 message, the particulars of which are protocol specific, to the
569 client, indicating that the exchange is aborted.
571 3.6. Authentication Outcome
573 At the conclusion of the authentication exchange, the server sends a
574 message, the particulars of which are protocol specific, to the
575 client indicating the outcome of the exchange.
577 The outcome is not successful if
579 - the authentication exchange failed for any reason,
581 - the client's credentials could not be verified,
583 - the server cannot associate an identity with the client's
584 credentials,
586 - the client-provided authorization identity string is malformed,
588 - the identity associated with the client's credentials is not
589 authorized to act as the requested authorization identity,
591 - the negotiated security layer (or lack thereof) is not
592 suitable, or
594 - the server is not willing to provide service to the client for
595 any reason.
597 The protocol may include an optional additional data field in this
598 outcome message. This field can only include additional data when
599 the outcome is successful.
601 If the outcome is successful and a security layer was negotiated,
602 this layer is then installed. If the outcome is unsuccessful, or a
603 security layer was not negotiated, any existing security is left in
604 place.
606 The outcome message provided by the server can provide a way for the
607 client to distinguish between errors that are best dealt with by re-
608 prompting the user for her credentials, errors that are best dealt
609 with by telling the user to try again later, and errors where the
610 user must contact a system administrator for resolution (see the SYS
611 and AUTH POP Response Codes [RFC3206] specification for an example).
612 This distinction is particularly useful during scheduled server
613 maintenance periods as it reduces support costs. It is also
614 important that the server can be configured such that the outcome
618 Melnikov & Zeilenga Standards Track [Page 11]
620 RFC 4422 SASL June 2006
623 message will not distinguish between a valid user with invalid
624 credentials and an invalid user.
626 3.7. Security Layers
628 SASL mechanisms may offer a wide range of services in security
629 layers. Typical services include data integrity and data
630 confidentiality. SASL mechanisms that do not provide a security
631 layer are treated as negotiating no security layer.
633 If use of a security layer is negotiated in the authentication
634 protocol exchange, the layer is installed by the server after
635 indicating the outcome of the authentication exchange and installed
636 by the client upon receipt of the outcome indication. In both cases,
637 the layer is installed before transfer of further protocol data. The
638 precise position upon which the layer takes effect in the protocol
639 data stream is protocol specific.
641 Once the security layer is in effect in the protocol data stream, it
642 remains in effect until either a subsequently negotiated security
643 layer is installed or the underlying transport connection is closed.
645 When in effect, the security layer processes protocol data into
646 buffers of protected data. If at any time the security layer is
647 unable or unwilling to continue producing buffers protecting protocol
648 data, the underlying transport connection MUST be closed. If the
649 security layer is not able to decode a received buffer, the
650 underlying connection MUST be closed. In both cases, the underlying
651 transport connection SHOULD be closed gracefully.
653 Each buffer of protected data is transferred over the underlying
654 transport connection as a sequence of octets prepended with a four-
655 octet field in network byte order that represents the length of the
656 buffer. The length of the protected data buffer MUST be no larger
657 than the maximum size that the other side expects. Upon the receipt
658 of a length field whose value is greater than the maximum size, the
659 receiver SHOULD close the connection, as this might be a sign of an
660 attack.
662 The maximum size that each side expects is fixed by the mechanism,
663 either through negotiation or by its specification.
665 3.8. Multiple Authentications
667 Unless explicitly permitted in the protocol (as stated in the
668 protocol's technical specification), only one successful SASL
669 authentication exchange may occur in a protocol session. In this
674 Melnikov & Zeilenga Standards Track [Page 12]
676 RFC 4422 SASL June 2006
679 case, once an authentication exchange has successfully completed,
680 further attempts to initiate an authentication exchange fail.
682 Where multiple successful SASL authentication exchanges are permitted
683 in the protocol, then in no case may multiple SASL security layers be
684 simultaneously in effect. If a security layer is in effect and a
685 subsequent SASL negotiation selects a second security layer, then the
686 second security layer replaces the first. If a security layer is in
687 effect and a subsequent SASL negotiation selects no security layer,
688 the original security layer remains in effect.
690 Where multiple successful SASL negotiations are permitted in the
691 protocol, the effect of a failed SASL authentication exchange upon
692 the previously established authentication and authorization state is
693 protocol specific. The protocol's technical specification should be
694 consulted to determine whether the previous authentication and
695 authorization state remains in force, or changed to an anonymous
696 state, or otherwise was affected. Regardless of the protocol-
697 specific effect upon previously established authentication and
698 authorization state, the previously negotiated security layer remains
699 in effect.
701 4. Protocol Requirements
703 In order for a protocol to offer SASL services, its specification
704 MUST supply the following information:
706 1) A service name, to be selected from registry of "service" elements
707 for the Generic Security Service Application Program Interface
708 (GSSAPI) host-based service name form, as described in Section 4.1
709 of [RFC2743]. Note that this registry is shared by all GSSAPI and
710 SASL mechanisms.
712 2) Detail any mechanism negotiation facility that the protocol
713 provides (see Section 3.2).
715 A protocol SHOULD specify a facility through which the client may
716 discover, both before initiation of the SASL exchange and after
717 installing security layers negotiated by the exchange, the names
718 of the SASL mechanisms that the server makes available to the
719 client. The latter is important to allow the client to detect
720 downgrade attacks. This facility is typically provided through
721 the protocol's extensions or capabilities discovery facility.
723 3) Definition of the messages necessary for authentication exchange,
724 including the following:
730 Melnikov & Zeilenga Standards Track [Page 13]
732 RFC 4422 SASL June 2006
735 a) A message to initiate the authentication exchange (see Section
736 3.3).
738 This message MUST contain a field for carrying the name of the
739 mechanism selected by the client.
741 This message SHOULD contain an optional field for carrying an
742 initial response. If the message is defined with this field,
743 the specification MUST describe how messages with an empty
744 initial response are distinguished from messages with no
745 initial response. This field MUST be capable of carrying
746 arbitrary sequences of octets (including zero-length sequences
747 and sequences containing zero-valued octets).
749 b) Messages to transfer server challenges and client responses
750 (see Section 3.4).
752 Each of these messages MUST be capable of carrying arbitrary
753 sequences of octets (including zero-length sequences and
754 sequences containing zero-valued octets).
756 c) A message to indicate the outcome of the authentication
757 exchange (see Section 3.6).
759 This message SHOULD contain an optional field for carrying
760 additional data with a successful outcome. If the message is
761 defined with this field, the specification MUST describe how
762 messages with an empty additional data are distinguished from
763 messages with no additional data. This field MUST be capable
764 of carrying arbitrary sequences of octets (including zero-
765 length sequences and sequences containing zero-valued octets).
767 4) Prescribe the syntax and semantics of non-empty authorization
768 identity strings (see Section 3.4.1).
770 In order to avoid interoperability problems due to differing
771 normalizations, the protocol specification MUST detail precisely
772 how and where (client or server) non-empty authorization identity
773 strings are prepared, including all normalizations, for comparison
774 and other applicable functions to ensure proper function.
776 Specifications are encouraged to prescribe use of existing
777 authorization identity forms as well as existing string
778 representations, such as simple user names [RFC4013].
780 Where the specification does not precisely prescribe how
781 identities in SASL relate to identities used elsewhere in the
782 protocol, for instance, in access control policy statements, it
786 Melnikov & Zeilenga Standards Track [Page 14]
788 RFC 4422 SASL June 2006
791 may be appropriate for the protocol to provide a facility by which
792 the client can discover information (such as the representation of
793 the identity used in making access control decisions) about
794 established identities for these uses.
796 5) Detail any facility the protocol provides that allows the client
797 and/or server to abort authentication exchange (see Section 3.5).
799 Protocols that support multiple authentications typically allow a
800 client to abort an ongoing authentication exchange by initiating a
801 new authentication exchange. Protocols that do not support
802 multiple authentications may require the client to close the
803 connection and start over to abort an ongoing authentication
804 exchange.
806 Protocols typically allow the server to abort ongoing
807 authentication exchanges by returning a non-successful outcome
808 message.
810 6) Identify precisely where newly negotiated security layers start to
811 take effect, in both directions (see Section 3.7).
813 Typically, specifications require security layers to start taking
814 effect on the first octet following the outcome message in data
815 being sent by the server and on the first octet sent after receipt
816 of the outcome message in data being sent by the client.
818 7) If the protocol supports other layered security services, such as
819 Transport Layer Security (TLS) [RFC4346], the specification MUST
820 prescribe the order in which security layers are applied to
821 protocol data.
823 For instance, where a protocol supports both TLS and SASL security
824 layers, the specification could prescribe any of the following:
826 a) SASL security layer is always applied first to data being sent
827 and, hence, applied last to received data,
829 b) SASL security layer is always applied last to data being sent
830 and, hence, applied first to received data,
832 c) Layers are applied in the order in which they were installed,
834 d) Layers are applied in the reverse order in which they were
835 installed, or
837 e) Both TLS and SASL security layers cannot be installed.
842 Melnikov & Zeilenga Standards Track [Page 15]
844 RFC 4422 SASL June 2006
847 8) Indicate whether the protocol supports multiple authentications
848 (see Section 3.8). If so, the protocol MUST detail the effect a
849 failed SASL authentication exchange will have upon a previously
850 established authentication and authorization state.
852 Protocol specifications SHOULD avoid stating implementation
853 requirements that would hinder replacement of applicable mechanisms.
854 In general, protocol specifications SHOULD be mechanism neutral.
855 There are a number of reasonable exceptions to this recommendation,
856 including
858 - detailing how credentials (which are mechanism specific) are
859 managed in the protocol,
861 - detailing how authentication identities (which are mechanism
862 specific) and authorization identities (which are protocol
863 specific) relate to each other, and
865 - detailing which mechanisms are applicable to the protocol.
867 5. Mechanism Requirements
869 SASL mechanism specifications MUST supply the following information:
871 1) The name of the mechanism (see Section 3.1). This name MUST be
872 registered as discussed in Section 7.1.
874 2) A definition of the server-challenges and client-responses of the
875 authentication exchange, as well as the following:
877 a) An indication of whether the mechanism is client-first,
878 variable, or server-first. If a SASL mechanism is defined as
879 client-first and the client does not send an initial response
880 in the authentication request, then the first server challenge
881 MUST be empty (the EXTERNAL mechanism is an example of this
882 case). If a SASL mechanism is defined as variable, then the
883 specification needs to state how the server behaves when the
884 initial client response in the authentication request is
885 omitted (the DIGEST-MD5 mechanism [DIGEST-MD5] is an example of
886 this case). If a SASL mechanism is defined as server-first,
887 then the client MUST NOT send an initial client response in the
888 authentication request (the CRAM-MD5 mechanism [CRAM-MD5] is an
889 example of this case).
891 b) An indication of whether the server is expected to provide
892 additional data when indicating a successful outcome. If so,
893 if the server sends the additional data as a challenge, the
898 Melnikov & Zeilenga Standards Track [Page 16]
900 RFC 4422 SASL June 2006
903 specification MUST indicate that the response to this challenge
904 is an empty response.
906 SASL mechanisms SHOULD be designed to minimize the number of
907 challenges and responses necessary to complete the exchange.
909 3) An indication of whether the mechanism is capable of transferring
910 authorization identity strings (see Section 3.4.1). While some
911 legacy mechanisms are incapable of transmitting an authorization
912 identity (which means that for these mechanisms, the authorization
913 identity is always the empty string), newly defined mechanisms
914 SHOULD be capable of transferring authorization identity strings.
915 The mechanism SHOULD NOT be capable of transferring both no
916 authorization identity string and an empty authorization identity.
918 Mechanisms that are capable of transferring an authorization
919 identity string MUST be capable of transferring arbitrary non-
920 empty sequences of Unicode characters, excluding those that
921 contain the NUL (U+0000) character. Mechanisms SHOULD use the
922 UTF-8 [RFC3629] transformation format. The specification MUST
923 detail how any Unicode code points special to the mechanism that
924 might appear in the authorization identity string are escaped to
925 avoid ambiguity during decoding of the authorization identity
926 string. Typically, mechanisms that have special characters
927 require these special characters to be escaped or encoded in the
928 character string (after encoding it in a particular Unicode
929 transformation format) using a data encoding scheme such as Base64
930 [RFC3548].
932 4) The specification MUST detail whether the mechanism offers a
933 security layer. If the mechanism does, the specification MUST
934 detail the security and other services offered in the layer as
935 well as how these services are to be implemented.
937 5) If the underlying cryptographic technology used by a mechanism
938 supports data integrity, then the mechanism specification MUST
939 integrity protect the transmission of an authorization identity
940 and the negotiation of the security layer.
942 SASL mechanisms SHOULD be protocol neutral.
944 SASL mechanisms SHOULD reuse existing credential and identity forms,
945 as well as associated syntaxes and semantics.
947 SASL mechanisms SHOULD use the UTF-8 transformation format [RFC3629]
948 for encoding Unicode [Unicode] code points for transfer.
954 Melnikov & Zeilenga Standards Track [Page 17]
956 RFC 4422 SASL June 2006
959 In order to avoid interoperability problems due to differing
960 normalizations, when a mechanism calls for character data (other than
961 the authorization identity string) to be used as input to a
962 cryptographic and/or comparison function, the specification MUST
963 detail precisely how and where (client or server) the character data
964 is to be prepared, including all normalizations, for input into the
965 function to ensure proper operation.
967 For simple user names and/or passwords in authentication credentials,
968 SASLprep [RFC4013] (a profile of the StringPrep [RFC3454] preparation
969 algorithm), SHOULD be specified as the preparation algorithm.
971 The mechanism SHOULD NOT use the authorization identity string in
972 generation of any long-term cryptographic keys or hashes as there is
973 no requirement that the authorization identity string be canonical.
974 Long-term, here, means a term longer than the duration of the
975 authentication exchange in which they were generated. That is, as
976 different clients (of the same or different protocol) may provide
977 different authorization identity strings that are semantically
978 equivalent, use of authorization identity strings in generation of
979 cryptographic keys and hashes will likely lead to interoperability
980 and other problems.
982 6. Security Considerations
984 Security issues are discussed throughout this memo.
986 Many existing SASL mechanisms do not provide adequate protection
987 against passive attacks, let alone active attacks, in the
988 authentication exchange. Many existing SASL mechanisms do not offer
989 security layers. It is hoped that future SASL mechanisms will
990 provide strong protection against passive and active attacks in the
991 authentication exchange, as well as security layers with strong basic
992 data security features (e.g., data integrity and data
993 confidentiality) services. It is also hoped that future mechanisms
994 will provide more advanced data security services like re-keying (see
995 Section 6.3).
997 Regardless, the SASL framework is susceptible to downgrade attacks.
998 Section 6.1.2 offers a variety of approaches for preventing or
999 detecting these attacks. In some cases, it is appropriate to use
1000 data integrity protective services external to SASL (e.g., TLS) to
1001 protect against downgrade attacks in SASL. Use of external
1002 protective security services is also important when the mechanisms
1003 available do not themselves offer adequate integrity and/or
1004 confidentiality protection of the authentication exchange and/or
1005 protocol data.
1010 Melnikov & Zeilenga Standards Track [Page 18]
1012 RFC 4422 SASL June 2006
1015 6.1. Active Attacks
1017 6.1.1. Hijack Attacks
1019 When the client selects a SASL security layer with at least integrity
1020 protection, this protection serves as a counter-measure against an
1021 active attacker hijacking the connection and modifying protocol data
1022 sent after establishment of the security layer. Implementations
1023 SHOULD close the connection when the security services in a SASL
1024 security layer report protocol data report lack of data integrity.
1026 6.1.2. Downgrade Attacks
1028 It is important that any security-sensitive protocol negotiations be
1029 performed after installation of a security layer with data integrity
1030 protection. Protocols should be designed such that negotiations
1031 performed prior to this installation should be revalidated after
1032 installation is complete. Negotiation of the SASL mechanism is
1033 security sensitive.
1035 When a client negotiates the authentication mechanism with the server
1036 and/or other security features, it is possible for an active attacker
1037 to cause a party to use the least secure security services available.
1038 For instance, an attacker can modify the server-advertised mechanism
1039 list or can modify the client-advertised security feature list within
1040 a mechanism response. To protect against this sort of attack,
1041 implementations SHOULD NOT advertise mechanisms and/or features that
1042 cannot meet their minimum security requirements, SHOULD NOT enter
1043 into or continue authentication exchanges that cannot meet their
1044 minimum security requirements, and SHOULD verify that completed
1045 authentication exchanges result in security services that meet their
1046 minimum security requirements. Note that each endpoint needs to
1047 independently verify that its security requirements are met.
1049 In order to detect downgrade attacks to the least (or less) secure
1050 mechanism supported, the client can discover the SASL mechanisms that
1051 the server makes available both before the SASL authentication
1052 exchange and after the negotiated SASL security layer (with at least
1053 data integrity protection) has been installed through the protocol's
1054 mechanism discovery facility. If the client finds that the
1055 integrity-protected list (the list obtained after the security layer
1056 was installed) contains a stronger mechanism than those in the
1057 previously obtained list, the client should assume that the
1058 previously obtained list was modified by an attacker and SHOULD close
1059 the underlying transport connection.
1061 The client's initiation of the SASL exchange, including the selection
1062 of a SASL mechanism, is done in the clear and may be modified by an
1066 Melnikov & Zeilenga Standards Track [Page 19]
1068 RFC 4422 SASL June 2006
1071 active attacker. It is important for any new SASL mechanisms to be
1072 designed such that an active attacker cannot obtain an authentication
1073 with weaker security properties by modifying the SASL mechanism name
1074 and/or the challenges and responses.
1076 Multi-level negotiation of security features is prone to downgrade
1077 attack. Protocol designers should avoid offering higher-level
1078 negotiation of security features in protocols (e.g., above SASL
1079 mechanism negotiation) and mechanism designers should avoid lower-
1080 level negotiation of security features in mechanisms (e.g., below
1081 SASL mechanism negotiation).
1083 6.1.3. Replay Attacks
1085 Some mechanisms may be subject to replay attacks unless protected by
1086 external data security services (e.g., TLS).
1088 6.1.4. Truncation Attacks
1090 Most existing SASL security layers do not themselves offer protection
1091 against truncation attack. In a truncation attack, the active
1092 attacker causes the protocol session to be closed, causing a
1093 truncation of the possibly integrity-protected data stream that leads
1094 to behavior of one or both the protocol peers that inappropriately
1095 benefits the attacker. Truncation attacks are fairly easy to defend
1096 against in connection-oriented application-level protocols. A
1097 protocol can defend against these attacks by ensuring that each
1098 information exchange has a clear final result and that each protocol
1099 session has a graceful closure mechanism, and that these are
1100 integrity protected.
1102 6.1.5. Other Active Attacks
1104 When use of a security layer is negotiated by the authentication
1105 protocol exchange, the receiver SHOULD handle gracefully any
1106 protected data buffer larger than the defined/negotiated maximal
1107 size. In particular, it MUST NOT blindly allocate the amount of
1108 memory specified in the buffer size field, as this might cause the
1109 "out of memory" condition. If the receiver detects a large block, it
1110 SHOULD close the connection.
1112 6.2. Passive Attacks
1114 Many mechanisms are subject to various passive attacks, including
1115 simple eavesdropping of unprotected credential information as well as
1116 online and offline dictionary attacks of protected credential
1117 information.
1122 Melnikov & Zeilenga Standards Track [Page 20]
1124 RFC 4422 SASL June 2006
1127 6.3. Re-keying
1129 The secure or administratively permitted lifetimes of SASL
1130 mechanisms' security layers are finite. Cryptographic keys weaken as
1131 they are used and as time passes; the more time and/or cipher-text
1132 that a cryptanalyst has after the first use of the a key, the easier
1133 it is for the cryptanalyst to mount attacks on the key.
1135 Administrative limits on a security layer's lifetime may take the
1136 form of time limits expressed in X.509 certificates, in Kerberos V
1137 tickets, or in directories, and are often desired. In practice, one
1138 likely effect of administrative lifetime limits is that applications
1139 may find that security layers stop working in the middle of
1140 application protocol operation, such as, perhaps, during large data
1141 transfers. As the result of this, the connection will be closed (see
1142 Section 3.7), which will result in an unpleasant user experience.
1144 Re-keying (key renegotiation process) is a way of addressing the
1145 weakening of cryptographic keys. The SASL framework does not itself
1146 provide for re-keying; SASL mechanisms may. Designers of future SASL
1147 mechanisms should consider providing re-keying services.
1149 Implementations that wish to re-key SASL security layers where the
1150 mechanism does not provide for re-keying SHOULD reauthenticate the
1151 same IDs and replace the expired or soon-to-expire security layers.
1152 This approach requires support for reauthentication in the
1153 application protocols (see Section 3.8).
1155 6.4. Other Considerations
1157 Protocol designers and implementors should understand the security
1158 considerations of mechanisms so they may select mechanisms that are
1159 applicable to their needs.
1161 Distributed server implementations need to be careful in how they
1162 trust other parties. In particular, authentication secrets should
1163 only be disclosed to other parties that are trusted to manage and use
1164 those secrets in a manner acceptable to the disclosing party.
1165 Applications using SASL assume that SASL security layers providing
1166 data confidentiality are secure even when an attacker chooses the
1167 text to be protected by the security layer. Similarly, applications
1168 assume that the SASL security layer is secure even if the attacker
1169 can manipulate the cipher-text output of the security layer. New
1170 SASL mechanisms are expected to meet these assumptions.
1178 Melnikov & Zeilenga Standards Track [Page 21]
1180 RFC 4422 SASL June 2006
1183 Unicode security considerations [UTR36] apply to authorization
1184 identity strings, as well as UTF-8 [RFC3629] security considerations
1185 where UTF-8 is used. SASLprep [RFC4013] and StringPrep [RFC3454]
1186 security considerations also apply where used.
1188 7. IANA Considerations
1190 7.1. SASL Mechanism Registry
1192 The SASL mechanism registry is maintained by IANA. The registry is
1193 currently available at <http://www.iana.org/assignments/sasl-
1194 mechanisms>.
1196 The purpose of this registry is not only to ensure uniqueness of
1197 values used to name SASL mechanisms, but also to provide a definitive
1198 reference to technical specifications detailing each SASL mechanism
1199 available for use on the Internet.
1201 There is no naming convention for SASL mechanisms; any name that
1202 conforms to the syntax of a SASL mechanism name can be registered.
1204 The procedure detailed in Section 7.1.1 is to be used for
1205 registration of a value naming a specific individual mechanism.
1207 The procedure detailed in Section 7.1.2 is to be used for
1208 registration of a value naming a family of related mechanisms.
1210 Comments may be included in the registry as discussed in Section
1211 7.1.3 and may be changed as discussed in Section 7.1.4.
1213 The SASL mechanism registry has been updated to reflect that this
1214 document provides the definitive technical specification for SASL and
1215 that this section provides the registration procedures for this
1216 registry.
1234 Melnikov & Zeilenga Standards Track [Page 22]
1236 RFC 4422 SASL June 2006
1239 7.1.1. Mechanism Name Registration Procedure
1241 IANA will register new SASL mechanism names on a First Come First
1242 Served basis, as defined in BCP 26 [RFC2434]. IANA has the right to
1243 reject obviously bogus registration requests, but will perform no
1244 review of claims made in the registration form.
1246 Registration of a SASL mechanism is requested by filling in the
1247 following template:
1249 Subject: Registration of SASL mechanism X
1251 SASL mechanism name (or prefix for the family):
1253 Security considerations:
1255 Published specification (recommended):
1257 Person & email address to contact for further information:
1259 Intended usage: (One of COMMON, LIMITED USE, or OBSOLETE)
1261 Owner/Change controller:
1263 Note: (Any other information that the author deems relevant may be
1264 added here.)
1266 and sending it via electronic mail to IANA at <iana@iana.org>.
1268 While this registration procedure does not require expert review,
1269 authors of SASL mechanisms are encouraged to seek community review
1270 and comment whenever that is feasible. Authors may seek community
1271 review by posting a specification of their proposed mechanism as an
1272 Internet-Draft. SASL mechanisms intended for widespread use should
1273 be standardized through the normal IETF process, when appropriate.
1290 Melnikov & Zeilenga Standards Track [Page 23]
1292 RFC 4422 SASL June 2006
1295 7.1.2. Family Name Registration Procedure
1297 As noted above, there is no general naming convention for SASL
1298 mechanisms. However, specifications may reserve a portion of the
1299 SASL mechanism namespace for a set of related SASL mechanisms, a
1300 "family" of SASL mechanisms. Each family of SASL mechanisms is
1301 identified by a unique prefix, such as X-. Registration of new SASL
1302 mechanism family names requires expert review as defined in BCP 26
1303 [RFC2434].
1305 Registration of a SASL family name is requested by filling in the
1306 following template:
1308 Subject: Registration of SASL mechanism family X
1310 SASL family name (or prefix for the family):
1312 Security considerations:
1314 Published specification (recommended):
1316 Person & email address to contact for further information:
1318 Intended usage: (One of COMMON, LIMITED USE, or OBSOLETE)
1320 Owner/Change controller:
1322 Note: (Any other information that the author deems relevant may be
1323 added here.)
1325 and sending it via electronic mail to the IETF SASL mailing list at
1326 <ietf-sasl@imc.org> and carbon copying IANA at <iana@iana.org>.
1327 After allowing two weeks for community input on the IETF SASL mailing
1328 list, the expert will determine the appropriateness of the
1329 registration request and either approve or disapprove the request
1330 with notice to the requestor, the mailing list, and IANA.
1332 The review should focus on the appropriateness of the requested
1333 family name for the proposed use and the appropriateness of the
1334 proposed naming and registration plan for existing and future
1335 mechanism names in the family. The scope of this request review may
1336 entail consideration of relevant aspects of any provided technical
1337 specification, such as their IANA Considerations section. However,
1338 this review is narrowly focused on the appropriateness of the
1339 requested registration and not on the overall soundness of any
1340 provided technical specification.
1346 Melnikov & Zeilenga Standards Track [Page 24]
1348 RFC 4422 SASL June 2006
1351 Authors are encouraged to pursue community review by posting the
1352 technical specification as an Internet-Draft and soliciting comment
1353 by posting to appropriate IETF mailing lists.
1355 7.1.3. Comments on SASL Mechanism Registrations
1357 Comments on a registered SASL mechanism/family should first be sent
1358 to the "owner" of the mechanism/family and/or to the <ietf-
1359 sasl@imc.org> mailing list.
1361 Submitters of comments may, after a reasonable attempt to contact the
1362 owner, request IANA to attach their comment to the SASL mechanism
1363 registration itself by sending mail to <iana@iana.org>. At IANA's
1364 sole discretion, IANA may attach the comment to the SASL mechanism's
1365 registration.
1367 7.1.4. Change Control
1369 Once a SASL mechanism registration has been published by IANA, the
1370 author may request a change to its definition. The change request
1371 follows the same procedure as the registration request.
1373 The owner of a SASL mechanism may pass responsibility for the SASL
1374 mechanism to another person or agency by informing IANA; this can be
1375 done without discussion or review.
1377 The IESG may reassign responsibility for a SASL mechanism. The most
1378 common case of this will be to enable changes to be made to
1379 mechanisms where the author of the registration has died, has moved
1380 out of contact, or is otherwise unable to make changes that are
1381 important to the community.
1383 SASL mechanism registrations may not be deleted; mechanisms that are
1384 no longer believed appropriate for use can be declared OBSOLETE by a
1385 change to their "intended usage" field; such SASL mechanisms will be
1386 clearly marked in the lists published by IANA.
1388 The IESG is considered to be the owner of all SASL mechanisms that
1389 are on the IETF standards track.
1402 Melnikov & Zeilenga Standards Track [Page 25]
1404 RFC 4422 SASL June 2006
1407 7.2. Registration Changes
1409 The IANA has updated the SASL mechanisms registry as follows:
1411 1) Changed the "Intended usage" of the KERBEROS_V4 and SKEY mechanism
1412 registrations to OBSOLETE.
1414 2) Changed the "Published specification" of the EXTERNAL mechanism to
1415 this document as indicated below:
1417 Subject: Updated Registration of SASL mechanism EXTERNAL
1418 Family of SASL mechanisms: NO
1419 SASL mechanism name: EXTERNAL
1420 Security considerations: See A.3 of RFC 4422
1421 Published specification (optional, recommended): RFC 4422
1422 Person & email address to contact for further information:
1423 Alexey Melnikov <Alexey.Melnikov@isode.com>
1424 Intended usage: COMMON
1425 Owner/Change controller: IESG <iesg@ietf.org>
1426 Note: Updates existing entry for EXTERNAL
1428 8. References
1430 8.1. Normative References
1432 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
1433 Requirement Levels", BCP 14, RFC 2119, March 1997.
1435 [RFC2244] Newman, C. and J. G. Myers, "ACAP -- Application
1436 Configuration Access Protocol", RFC 2244, November
1437 1997.
1439 [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing
1440 an IANA Considerations Section in RFCs", BCP 26, RFC
1441 2434, October 1998.
1443 [RFC2743] Linn, J., "Generic Security Service Application Program
1444 Interface Version 2, Update 1", RFC 2743, January 2000.
1446 [RFC3454] Hoffman, P. and M. Blanchet, "Preparation of
1447 Internationalized Strings ("stringprep")", RFC 3454,
1448 December 2002.
1450 [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO
1451 10646", STD 63, RFC 3629, November 2003.
1453 [RFC4013] Zeilenga, K., "SASLprep: Stringprep Profile for User
1454 Names and Passwords", RFC 4013, February 2005.
1458 Melnikov & Zeilenga Standards Track [Page 26]
1460 RFC 4422 SASL June 2006
1463 [RFC4234] Crocker, D. and P. Overell, "Augmented BNF for Syntax
1464 Specifications: ABNF", RFC 4234, October 2005.
1466 [ASCII] Coded Character Set--7-bit American Standard Code for
1467 Information Interchange, ANSI X3.4-1986.
1469 [Unicode] The Unicode Consortium, "The Unicode Standard, Version
1470 3.2.0" is defined by "The Unicode Standard, Version
1471 3.0" (Reading, MA, Addison-Wesley, 2000. ISBN 0-201-
1472 61633-5), as amended by the "Unicode Standard Annex
1473 #27: Unicode 3.1"
1474 (http://www.unicode.org/reports/tr27/) and by the
1475 "Unicode Standard Annex #28: Unicode 3.2"
1476 (http://www.unicode.org/reports/tr28/).
1478 [CharModel] Whistler, K. and M. Davis, "Unicode Technical Report
1479 #17, Character Encoding Model", UTR17,
1480 <http://www.unicode.org/unicode/reports/tr17/>, August
1481 2000.
1483 [Glossary] The Unicode Consortium, "Unicode Glossary",
1484 <http://www.unicode.org/glossary/>.
1486 8.2. Informative References
1488 [RFC3206] Gellens, R., "The SYS and AUTH POP Response Codes", RFC
1489 3206, February 2002.
1491 [RFC3548] Josefsson, S., "The Base16, Base32, and Base64 Data
1492 Encodings", RFC 3548, July 2003.
1494 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the
1495 Internet Protocol", RFC 4301, December 2005.
1497 [RFC4346] Dierks, T. and E. Rescorla, "The Transport Layer
1498 Security (TLS) Protocol Version 1.1", RFC 4346, April
1499 2006.
1501 [SASL-GSSAPI] Melnikov, A. (Editor), "The Kerberos V5 ("GSSAPI") SASL
1502 Mechanism", Work in Progress, May 2006.
1504 [UTR36] Davis, M., "(Draft) Unicode Technical Report #36,
1505 Character Encoding Model", UTR17,
1506 <http://www.unicode.org/unicode/reports/tr36/>,
1507 February 2005.
1509 [CRAM-MD5] Nerenberg, L., "The CRAM-MD5 SASL Mechanism", Work in
1510 Progress.
1514 Melnikov & Zeilenga Standards Track [Page 27]
1516 RFC 4422 SASL June 2006
1519 [DIGEST-MD5] Leach, P., C. Newman, and A. Melnikov, "Using Digest
1520 Authentication as a SASL Mechanism", Work in Progress,
1521 March 2006.
1523 9. Acknowledgements
1525 This document is a revision of RFC 2222 written by John Myers.
1527 This revision is a product of the IETF Simple Authentication and
1528 Security Layer (SASL) Working Group.
1530 The following individuals contributed significantly to this revision:
1531 Abhijit Menon-Sen, Hallvard Furuseth, Jeffrey Hutzelman, John Myers,
1532 Luke Howard, Magnus Nystrom, Nicolas Williams, Peter Saint-Andre, RL
1533 'Bob' Morgan, Rob Siemborski, Sam Hartman, Simon Josefsson, Tim
1534 Alsop, and Tony Hansen.
1570 Melnikov & Zeilenga Standards Track [Page 28]
1572 RFC 4422 SASL June 2006
1575 Appendix A. The SASL EXTERNAL Mechanism
1577 This appendix is normative.
1579 The EXTERNAL mechanism allows a client to request the server to use
1580 credentials established by means external to the mechanism to
1581 authenticate the client. The external means may be, for instance, IP
1582 Security [RFC4301] or TLS [RFC4346] services. In absence of some a
1583 priori agreement between the client and the server, the client cannot
1584 make any assumption as to what external means the server has used to
1585 obtain the client's credentials, nor make an assumption as to the
1586 form of credentials. For example, the client cannot assume that the
1587 server will use the credentials the client has established via TLS.
1589 A.1. EXTERNAL Technical Specification
1591 The name of this mechanism is "EXTERNAL".
1593 The mechanism does not provide a security layer.
1595 The mechanism is capable of transferring an authorization identity
1596 string. If empty, the client is requesting to act as the identity
1597 the server has associated with the client's credentials. If non-
1598 empty, the client is requesting to act as the identity represented by
1599 the string.
1601 The client is expected to send data first in the authentication
1602 exchange. Where the client does not provide an initial response data
1603 in its request to initiate the authentication exchange, the server is
1604 to respond to the request with an empty initial challenge and then
1605 the client is to provide its initial response.
1607 The client sends the initial response containing the UTF-8 [RFC3629]
1608 encoding of the requested authorization identity string. This
1609 response is non-empty when the client is requesting to act as the
1610 identity represented by the (non-empty) string. This response is
1611 empty when the client is requesting to act as the identity the server
1612 associated with its authentication credentials.
1614 The syntax of the initial response is specified as a value of the
1615 <extern-initial-resp> production detailed below using the Augmented
1616 Backus-Naur Form (ABNF) [RFC4234] notation.
1618 external-initial-resp = authz-id-string
1619 authz-id-string = *( UTF8-char-no-nul )
1620 UTF8-char-no-nul = UTF8-1-no-nul / UTF8-2 / UTF8-3 / UTF8-4
1621 UTF8-1-no-nul = %x01-7F
1626 Melnikov & Zeilenga Standards Track [Page 29]
1628 RFC 4422 SASL June 2006
1631 where the <UTF8-2>, <UTF8-3>, and <UTF8-4> productions are as defined
1632 in [RFC3629].
1634 There are no additional challenges and responses.
1636 Hence, the server is to return the outcome of the authentication
1637 exchange.
1639 The exchange fails if
1641 - the client has not established its credentials via external means,
1643 - the client's credentials are inadequate,
1645 - the client provided an empty authorization identity string and the
1646 server is unwilling or unable to associate an authorization
1647 identity with the client's credentials,
1649 - the client provided a non-empty authorization identity string that
1650 is invalid per the syntax requirements of the applicable
1651 application protocol specification,
1653 - the client provided a non-empty authorization identity string
1654 representing an identity that the client is not allowed to act as,
1655 or
1657 - the server is unwilling or unable to provide service to the client
1658 for any other reason.
1660 Otherwise the exchange is successful. When indicating a successful
1661 outcome, additional data is not provided.
1663 A.2. SASL EXTERNAL Examples
1665 This section provides examples of EXTERNAL authentication exchanges.
1666 The examples are intended to help the readers understand the above
1667 text. The examples are not definitive. The Application
1668 Configuration Access Protocol (ACAP) [RFC2244] is used in the
1669 examples.
1671 The first example shows use of EXTERNAL with an empty authorization
1672 identity. In this example, the initial response is not sent in the
1673 client's request to initiate the authentication exchange.
1675 S: * ACAP (SASL "DIGEST-MD5")
1676 C: a001 STARTTLS
1677 S: a001 OK "Begin TLS negotiation now"
1678 <TLS negotiation, further commands are under TLS layer>
1682 Melnikov & Zeilenga Standards Track [Page 30]
1684 RFC 4422 SASL June 2006
1687 S: * ACAP (SASL "DIGEST-MD5" "EXTERNAL")
1688 C: a002 AUTHENTICATE "EXTERNAL"
1689 S: + ""
1690 C: + ""
1691 S: a002 OK "Authenticated"
1693 The second example shows use of EXTERNAL with an authorization
1694 identity of "fred@example.com". In this example, the initial
1695 response is sent with the client's request to initiate the
1696 authentication exchange. This saves a round-trip.
1698 S: * ACAP (SASL "DIGEST-MD5")
1699 C: a001 STARTTLS
1700 S: a001 OK "Begin TLS negotiation now"
1701 <TLS negotiation, further commands are under TLS layer>
1702 S: * ACAP (SASL "DIGEST-MD5" "EXTERNAL")
1703 C: a002 AUTHENTICATE "EXTERNAL" {16+}
1704 C: fred@example.com
1705 S: a002 NO "Cannot assume requested authorization identity"
1707 A.3. Security Considerations
1709 The EXTERNAL mechanism provides no security protection; it is
1710 vulnerable to spoofing by either client or server, active attack, and
1711 eavesdropping. It should only be used when adequate security
1712 services have been established.
1714 Appendix B. Changes since RFC 2222
1716 This appendix is non-normative.
1718 The material in RFC 2222 was significantly rewritten in the
1719 production of this document.
1721 RFC 2222, by not stating that the authorization identity string was a
1722 string of Unicode characters, let alone character data, implied that
1723 the authorization identity string was a string of octets.
1725 - The authorization identity string is now defined as a string of
1726 Unicode characters. The NUL (U+0000) character is prohibited.
1727 While protocol specifications are responsible for defining the
1728 authorization identity form, as well as the Unicode string syntax
1729 and related semantics, mechanism specifications are responsible
1730 for defining how the Unicode string is carried in the
1731 authentication exchange.
1733 - Deleted "If so, when the client does not send data first, the
1734 initial challenge MUST be specified as being an empty challenge."
1738 Melnikov & Zeilenga Standards Track [Page 31]
1740 RFC 4422 SASL June 2006
1743 The following technical change was made to the EXTERNAL mechanism:
1745 - The authorization identity string is to be UTF-8 encoded.
1747 Note that protocol and mechanism specification requirements have
1748 been significantly tightened. Existing protocol and mechanism
1749 specifications will need to be updated to meet these requirements.
1751 Editors' Addresses
1753 Alexey Melnikov
1754 Isode Limited
1755 5 Castle Business Village
1756 36 Station Road
1757 Hampton, Middlesex,
1758 TW12 2BX, United Kingdom
1760 EMail: Alexey.Melnikov@isode.com
1761 URI: http://www.melnikov.ca/
1764 Kurt D. Zeilenga
1765 OpenLDAP Foundation
1767 EMail: Kurt@OpenLDAP.org
1794 Melnikov & Zeilenga Standards Track [Page 32]
1796 RFC 4422 SASL June 2006
1799 Full Copyright Statement
1801 Copyright (C) The Internet Society (2006).
1803 This document is subject to the rights, licenses and restrictions
1804 contained in BCP 78, and except as set forth therein, the authors
1805 retain all their rights.
1807 This document and the information contained herein are provided on an
1808 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
1809 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
1810 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
1811 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
1812 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
1813 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
1815 Intellectual Property
1817 The IETF takes no position regarding the validity or scope of any
1818 Intellectual Property Rights or other rights that might be claimed to
1819 pertain to the implementation or use of the technology described in
1820 this document or the extent to which any license under such rights
1821 might or might not be available; nor does it represent that it has
1822 made any independent effort to identify any such rights. Information
1823 on the procedures with respect to rights in RFC documents can be
1824 found in BCP 78 and BCP 79.
1826 Copies of IPR disclosures made to the IETF Secretariat and any
1827 assurances of licenses to be made available, or the result of an
1828 attempt made to obtain a general license or permission for the use of
1829 such proprietary rights by implementers or users of this
1830 specification can be obtained from the IETF on-line IPR repository at
1831 http://www.ietf.org/ipr.
1833 The IETF invites any interested party to bring to its attention any
1834 copyrights, patents or patent applications, or other proprietary
1835 rights that may cover technology that may be required to implement
1836 this standard. Please address the information to the IETF at
1837 ietf-ipr@ietf.org.
1839 Acknowledgement
1841 Funding for the RFC Editor function is provided by the IETF
1842 Administrative Support Activity (IASA).
1850 Melnikov & Zeilenga Standards Track [Page 33]