1
2
3
4
5
6
7Network Working Group A. Melnikov, Ed.
8Request for Comments: 4422 Isode Limited
9Obsoletes: 2222 K. Zeilenga, Ed.
10Category: Standards Track OpenLDAP Foundation
11 June 2006
12
13
14 Simple Authentication and Security Layer (SASL)
15
16Status of This Memo
17
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.
23
24Copyright Notice
25
26 Copyright (C) The Internet Society (2006).
27
28Abstract
29
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.
38
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.
43
44 This document obsoletes RFC 2222.
45
46
47
48
49
50
51
52
53
54
55
56
57
58Melnikov & Zeilenga Standards Track [Page 1]
59
60RFC 4422 SASL June 2006
61
62
63Table of Contents
64
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
104
105
106
107
108
109
110
111
112
113
114Melnikov & Zeilenga Standards Track [Page 2]
115
116RFC 4422 SASL June 2006
117
118
1191. Introduction
120
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.
128
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.
133
134 SASL is conceptually a framework that provides an abstraction layer
135 between protocols and mechanisms as illustrated in the following
136 diagram.
137
138 SMTP LDAP XMPP Other protocols ...
139 \ | | /
140 \ | | /
141 SASL abstraction layer
142 / | | \
143 / | | \
144 EXTERNAL GSSAPI PLAIN Other mechanisms ...
145
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.
160
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.
167
168
169
170Melnikov & Zeilenga Standards Track [Page 3]
171
172RFC 4422 SASL June 2006
173
174
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.
178
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.
184
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.
189
190 Section 6 discusses security considerations. Section 7 discusses
191 IANA considerations. Appendix A defines the SASL EXTERNAL mechanism.
192
1931.1. Document Audiences
194
195 This document is written to serve several different audiences:
196
197 - protocol designers using this specification to support
198 authentication in their protocol,
199
200 - mechanism designers that define new SASL mechanisms, and
201
202 - implementors of clients or servers for those protocols that
203 support SASL.
204
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.
208
2091.2. Relationship to Other Documents
210
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].
217
218 Appendix B provides a summary of changes since RFC 2222.
219
220
221
222
223
224
225
226Melnikov & Zeilenga Standards Track [Page 4]
227
228RFC 4422 SASL June 2006
229
230
2311.3. Conventions
232
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].
236
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>.
240
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].
244
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.
248
2492. Identity Concepts
250
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.
262
263 However, conceptually, the SASL framework involves two identities:
264
265 1) an identity associated with the authentication credentials
266 (termed the authentication identity), and
267
268 2) an identity to act as (termed the authorization identity).
269
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.
278
279
280
281
282Melnikov & Zeilenga Standards Track [Page 5]
283
284RFC 4422 SASL June 2006
285
286
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).
293
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.)
300
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.
311
3123. The Authentication Exchange
313
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.)
320
321 The following illustration provides a high-level overview of an
322 authentication exchange.
323
324 C: Request authentication exchange
325 S: Initial challenge
326 C: Initial response
327 <additional challenge/response messages>
328 S: Outcome of authentication exchange
329
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.
333
334
335
336
337
338Melnikov & Zeilenga Standards Track [Page 6]
339
340RFC 4422 SASL June 2006
341
342
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:
350
351 C: Request authentication exchange + Initial response
352 <additional challenge/response messages>
353 S: Outcome of authentication exchange
354
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.
359
360 C: Request authentication exchange
361 S: Empty Challenge
362 C: Initial Response
363 <additional challenge/response messages>
364 S: Outcome of authentication exchange
365
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.
369
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:
378
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
385
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.
391
392
393
394Melnikov & Zeilenga Standards Track [Page 7]
395
396RFC 4422 SASL June 2006
397
398
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
406
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:
412
413 C: Request authentication exchange + Initial response
414 <additional challenge/response messages>
415 S: Outcome of authentication exchange
416 with additional data with success
417
418 instead of:
419
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
427
4283.1. Mechanism Naming
429
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.
435
436 sasl-mech = 1*20mech-char ../smtpserver/parse.go:506
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.
440
441 UPPER-ALPHA = %x41-5A ; A-Z (uppercase only)
442 DIGIT = %x30-39 ; 0-9
443 HYPHEN = %x2D ; hyphen (-)
444 UNDERSCORE = %x5F ; underscore (_)
445
446 SASL mechanism names are registered as discussed in Section 7.1.
447
448
449
450Melnikov & Zeilenga Standards Track [Page 8]
451
452RFC 4422 SASL June 2006
453
454
4553.2. Mechanism Negotiation
456
457 Mechanism negotiation is protocol specific.
458
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.
463
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.
467
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.
473
4743.3. Request Authentication Exchange
475
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.
480
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.
484
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.
489
4903.4. Challenges and Responses
491
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.
496
497 Through these challenges and responses, the mechanism may:
498
499 - authenticate the client to the server,
500
501 - authenticate the server to the client,
502
503
504
505
506Melnikov & Zeilenga Standards Track [Page 9]
507
508RFC 4422 SASL June 2006
509
510
511 - transfer an authorization identity string,
512
513 - negotiate a security layer, and
514
515 - provide other services.
516
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).
521
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.
526
5273.4.1. Authorization Identity String
528
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.
532
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.
537
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.
542
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).
548
5493.5. Aborting Authentication Exchanges
550
551 A client or server may desire to abort an authentication exchange if
552 it is unwilling or unable to continue (or enter into).
553
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.
559
560
561
562Melnikov & Zeilenga Standards Track [Page 10]
563
564RFC 4422 SASL June 2006
565
566
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.
570
5713.6. Authentication Outcome
572
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.
576
577 The outcome is not successful if
578
579 - the authentication exchange failed for any reason,
580
581 - the client's credentials could not be verified,
582
583 - the server cannot associate an identity with the client's
584 credentials,
585
586 - the client-provided authorization identity string is malformed,
587
588 - the identity associated with the client's credentials is not
589 authorized to act as the requested authorization identity,
590
591 - the negotiated security layer (or lack thereof) is not
592 suitable, or
593
594 - the server is not willing to provide service to the client for
595 any reason.
596
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.
600
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.
605
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
615
616
617
618Melnikov & Zeilenga Standards Track [Page 11]
619
620RFC 4422 SASL June 2006
621
622
623 message will not distinguish between a valid user with invalid
624 credentials and an invalid user.
625
6263.7. Security Layers
627
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.
632
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.
640
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.
644
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.
652
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.
661
662 The maximum size that each side expects is fixed by the mechanism,
663 either through negotiation or by its specification.
664
6653.8. Multiple Authentications
666
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
670
671
672
673
674Melnikov & Zeilenga Standards Track [Page 12]
675
676RFC 4422 SASL June 2006
677
678
679 case, once an authentication exchange has successfully completed,
680 further attempts to initiate an authentication exchange fail.
681
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.
689
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.
700
7014. Protocol Requirements
702
703 In order for a protocol to offer SASL services, its specification
704 MUST supply the following information:
705
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.
711
712 2) Detail any mechanism negotiation facility that the protocol
713 provides (see Section 3.2).
714
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.
722
723 3) Definition of the messages necessary for authentication exchange,
724 including the following:
725
726
727
728
729
730Melnikov & Zeilenga Standards Track [Page 13]
731
732RFC 4422 SASL June 2006
733
734
735 a) A message to initiate the authentication exchange (see Section
736 3.3).
737
738 This message MUST contain a field for carrying the name of the
739 mechanism selected by the client.
740
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).
748
749 b) Messages to transfer server challenges and client responses
750 (see Section 3.4).
751
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).
755
756 c) A message to indicate the outcome of the authentication
757 exchange (see Section 3.6).
758
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).
766
767 4) Prescribe the syntax and semantics of non-empty authorization
768 identity strings (see Section 3.4.1).
769
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.
775
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].
779
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
783
784
785
786Melnikov & Zeilenga Standards Track [Page 14]
787
788RFC 4422 SASL June 2006
789
790
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.
795
796 5) Detail any facility the protocol provides that allows the client
797 and/or server to abort authentication exchange (see Section 3.5).
798
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.
805
806 Protocols typically allow the server to abort ongoing
807 authentication exchanges by returning a non-successful outcome
808 message.
809
810 6) Identify precisely where newly negotiated security layers start to
811 take effect, in both directions (see Section 3.7).
812
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.
817
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.
822
823 For instance, where a protocol supports both TLS and SASL security
824 layers, the specification could prescribe any of the following:
825
826 a) SASL security layer is always applied first to data being sent
827 and, hence, applied last to received data,
828
829 b) SASL security layer is always applied last to data being sent
830 and, hence, applied first to received data,
831
832 c) Layers are applied in the order in which they were installed,
833
834 d) Layers are applied in the reverse order in which they were
835 installed, or
836
837 e) Both TLS and SASL security layers cannot be installed.
838
839
840
841
842Melnikov & Zeilenga Standards Track [Page 15]
843
844RFC 4422 SASL June 2006
845
846
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.
851
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
857
858 - detailing how credentials (which are mechanism specific) are
859 managed in the protocol,
860
861 - detailing how authentication identities (which are mechanism
862 specific) and authorization identities (which are protocol
863 specific) relate to each other, and
864
865 - detailing which mechanisms are applicable to the protocol.
866
8675. Mechanism Requirements
868
869 SASL mechanism specifications MUST supply the following information:
870
871 1) The name of the mechanism (see Section 3.1). This name MUST be
872 registered as discussed in Section 7.1.
873
874 2) A definition of the server-challenges and client-responses of the
875 authentication exchange, as well as the following:
876
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).
890
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
894
895
896
897
898Melnikov & Zeilenga Standards Track [Page 16]
899
900RFC 4422 SASL June 2006
901
902
903 specification MUST indicate that the response to this challenge
904 is an empty response.
905
906 SASL mechanisms SHOULD be designed to minimize the number of
907 challenges and responses necessary to complete the exchange.
908
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.
917
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].
931
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.
936
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.
941
942 SASL mechanisms SHOULD be protocol neutral.
943
944 SASL mechanisms SHOULD reuse existing credential and identity forms,
945 as well as associated syntaxes and semantics.
946
947 SASL mechanisms SHOULD use the UTF-8 transformation format [RFC3629]
948 for encoding Unicode [Unicode] code points for transfer.
949
950
951
952
953
954Melnikov & Zeilenga Standards Track [Page 17]
955
956RFC 4422 SASL June 2006
957
958
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.
966
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.
970
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.
981
9826. Security Considerations
983
984 Security issues are discussed throughout this memo.
985
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).
996
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.
1006
1007
1008
1009
1010Melnikov & Zeilenga Standards Track [Page 18]
1011
1012RFC 4422 SASL June 2006
1013
1014
10156.1. Active Attacks
1016
10176.1.1. Hijack Attacks
1018
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.
1025
10266.1.2. Downgrade Attacks
1027
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.
1034
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.
1048
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.
1060
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
1063
1064
1065
1066Melnikov & Zeilenga Standards Track [Page 19]
1067
1068RFC 4422 SASL June 2006
1069
1070
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.
1075
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).
1082
10836.1.3. Replay Attacks
1084
1085 Some mechanisms may be subject to replay attacks unless protected by
1086 external data security services (e.g., TLS).
1087
10886.1.4. Truncation Attacks
1089
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.
1101
11026.1.5. Other Active Attacks
1103
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.
1111
11126.2. Passive Attacks
1113
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.
1118
1119
1120
1121
1122Melnikov & Zeilenga Standards Track [Page 20]
1123
1124RFC 4422 SASL June 2006
1125
1126
11276.3. Re-keying
1128
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.
1134
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.
1143
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.
1148
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).
1154
11556.4. Other Considerations
1156
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.
1160
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.
1171
1172
1173
1174
1175
1176
1177
1178Melnikov & Zeilenga Standards Track [Page 21]
1179
1180RFC 4422 SASL June 2006
1181
1182
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.
1187
11887. IANA Considerations
1189
11907.1. SASL Mechanism Registry
1191
1192 The SASL mechanism registry is maintained by IANA. The registry is
1193 currently available at <http://www.iana.org/assignments/sasl-
1194 mechanisms>.
1195
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.
1200
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.
1203
1204 The procedure detailed in Section 7.1.1 is to be used for
1205 registration of a value naming a specific individual mechanism.
1206
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.
1209
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.
1212
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.
1217
1218
1219
1220
1221
1222
1223
1224
1225
1226
1227
1228
1229
1230
1231
1232
1233
1234Melnikov & Zeilenga Standards Track [Page 22]
1235
1236RFC 4422 SASL June 2006
1237
1238
12397.1.1. Mechanism Name Registration Procedure
1240
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.
1245
1246 Registration of a SASL mechanism is requested by filling in the
1247 following template:
1248
1249 Subject: Registration of SASL mechanism X
1250
1251 SASL mechanism name (or prefix for the family):
1252
1253 Security considerations:
1254
1255 Published specification (recommended):
1256
1257 Person & email address to contact for further information:
1258
1259 Intended usage: (One of COMMON, LIMITED USE, or OBSOLETE)
1260
1261 Owner/Change controller:
1262
1263 Note: (Any other information that the author deems relevant may be
1264 added here.)
1265
1266 and sending it via electronic mail to IANA at <iana@iana.org>.
1267
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.
1274
1275
1276
1277
1278
1279
1280
1281
1282
1283
1284
1285
1286
1287
1288
1289
1290Melnikov & Zeilenga Standards Track [Page 23]
1291
1292RFC 4422 SASL June 2006
1293
1294
12957.1.2. Family Name Registration Procedure
1296
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].
1304
1305 Registration of a SASL family name is requested by filling in the
1306 following template:
1307
1308 Subject: Registration of SASL mechanism family X
1309
1310 SASL family name (or prefix for the family):
1311
1312 Security considerations:
1313
1314 Published specification (recommended):
1315
1316 Person & email address to contact for further information:
1317
1318 Intended usage: (One of COMMON, LIMITED USE, or OBSOLETE)
1319
1320 Owner/Change controller:
1321
1322 Note: (Any other information that the author deems relevant may be
1323 added here.)
1324
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.
1331
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.
1341
1342
1343
1344
1345
1346Melnikov & Zeilenga Standards Track [Page 24]
1347
1348RFC 4422 SASL June 2006
1349
1350
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.
1354
13557.1.3. Comments on SASL Mechanism Registrations
1356
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.
1360
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.
1366
13677.1.4. Change Control
1368
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.
1372
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.
1376
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.
1382
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.
1387
1388 The IESG is considered to be the owner of all SASL mechanisms that
1389 are on the IETF standards track.
1390
1391
1392
1393
1394
1395
1396
1397
1398
1399
1400
1401
1402Melnikov & Zeilenga Standards Track [Page 25]
1403
1404RFC 4422 SASL June 2006
1405
1406
14077.2. Registration Changes
1408
1409 The IANA has updated the SASL mechanisms registry as follows:
1410
1411 1) Changed the "Intended usage" of the KERBEROS_V4 and SKEY mechanism
1412 registrations to OBSOLETE.
1413
1414 2) Changed the "Published specification" of the EXTERNAL mechanism to
1415 this document as indicated below:
1416
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
1427
14288. References
1429
14308.1. Normative References
1431
1432 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
1433 Requirement Levels", BCP 14, RFC 2119, March 1997.
1434
1435 [RFC2244] Newman, C. and J. G. Myers, "ACAP -- Application
1436 Configuration Access Protocol", RFC 2244, November
1437 1997.
1438
1439 [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing
1440 an IANA Considerations Section in RFCs", BCP 26, RFC
1441 2434, October 1998.
1442
1443 [RFC2743] Linn, J., "Generic Security Service Application Program
1444 Interface Version 2, Update 1", RFC 2743, January 2000.
1445
1446 [RFC3454] Hoffman, P. and M. Blanchet, "Preparation of
1447 Internationalized Strings ("stringprep")", RFC 3454,
1448 December 2002.
1449
1450 [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO
1451 10646", STD 63, RFC 3629, November 2003.
1452
1453 [RFC4013] Zeilenga, K., "SASLprep: Stringprep Profile for User
1454 Names and Passwords", RFC 4013, February 2005.
1455
1456
1457
1458Melnikov & Zeilenga Standards Track [Page 26]
1459
1460RFC 4422 SASL June 2006
1461
1462
1463 [RFC4234] Crocker, D. and P. Overell, "Augmented BNF for Syntax
1464 Specifications: ABNF", RFC 4234, October 2005.
1465
1466 [ASCII] Coded Character Set--7-bit American Standard Code for
1467 Information Interchange, ANSI X3.4-1986.
1468
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/).
1477
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.
1482
1483 [Glossary] The Unicode Consortium, "Unicode Glossary",
1484 <http://www.unicode.org/glossary/>.
1485
14868.2. Informative References
1487
1488 [RFC3206] Gellens, R., "The SYS and AUTH POP Response Codes", RFC
1489 3206, February 2002.
1490
1491 [RFC3548] Josefsson, S., "The Base16, Base32, and Base64 Data
1492 Encodings", RFC 3548, July 2003.
1493
1494 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the
1495 Internet Protocol", RFC 4301, December 2005.
1496
1497 [RFC4346] Dierks, T. and E. Rescorla, "The Transport Layer
1498 Security (TLS) Protocol Version 1.1", RFC 4346, April
1499 2006.
1500
1501 [SASL-GSSAPI] Melnikov, A. (Editor), "The Kerberos V5 ("GSSAPI") SASL
1502 Mechanism", Work in Progress, May 2006.
1503
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.
1508
1509 [CRAM-MD5] Nerenberg, L., "The CRAM-MD5 SASL Mechanism", Work in
1510 Progress.
1511
1512
1513
1514Melnikov & Zeilenga Standards Track [Page 27]
1515
1516RFC 4422 SASL June 2006
1517
1518
1519 [DIGEST-MD5] Leach, P., C. Newman, and A. Melnikov, "Using Digest
1520 Authentication as a SASL Mechanism", Work in Progress,
1521 March 2006.
1522
15239. Acknowledgements
1524
1525 This document is a revision of RFC 2222 written by John Myers.
1526
1527 This revision is a product of the IETF Simple Authentication and
1528 Security Layer (SASL) Working Group.
1529
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.
1535
1536
1537
1538
1539
1540
1541
1542
1543
1544
1545
1546
1547
1548
1549
1550
1551
1552
1553
1554
1555
1556
1557
1558
1559
1560
1561
1562
1563
1564
1565
1566
1567
1568
1569
1570Melnikov & Zeilenga Standards Track [Page 28]
1571
1572RFC 4422 SASL June 2006
1573
1574
1575Appendix A. The SASL EXTERNAL Mechanism
1576
1577 This appendix is normative.
1578
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.
1588
1589A.1. EXTERNAL Technical Specification
1590
1591 The name of this mechanism is "EXTERNAL".
1592
1593 The mechanism does not provide a security layer.
1594
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.
1600
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.
1606
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.
1613
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.
1617
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
1622
1623
1624
1625
1626Melnikov & Zeilenga Standards Track [Page 29]
1627
1628RFC 4422 SASL June 2006
1629
1630
1631 where the <UTF8-2>, <UTF8-3>, and <UTF8-4> productions are as defined
1632 in [RFC3629].
1633
1634 There are no additional challenges and responses.
1635
1636 Hence, the server is to return the outcome of the authentication
1637 exchange.
1638
1639 The exchange fails if
1640
1641 - the client has not established its credentials via external means,
1642
1643 - the client's credentials are inadequate,
1644
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,
1648
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,
1652
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
1656
1657 - the server is unwilling or unable to provide service to the client
1658 for any other reason.
1659
1660 Otherwise the exchange is successful. When indicating a successful
1661 outcome, additional data is not provided.
1662
1663A.2. SASL EXTERNAL Examples
1664
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.
1670
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.
1674
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>
1679
1680
1681
1682Melnikov & Zeilenga Standards Track [Page 30]
1683
1684RFC 4422 SASL June 2006
1685
1686
1687 S: * ACAP (SASL "DIGEST-MD5" "EXTERNAL")
1688 C: a002 AUTHENTICATE "EXTERNAL"
1689 S: + ""
1690 C: + ""
1691 S: a002 OK "Authenticated"
1692
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.
1697
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"
1706
1707A.3. Security Considerations
1708
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.
1713
1714Appendix B. Changes since RFC 2222
1715
1716 This appendix is non-normative.
1717
1718 The material in RFC 2222 was significantly rewritten in the
1719 production of this document.
1720
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.
1724
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.
1732
1733 - Deleted "If so, when the client does not send data first, the
1734 initial challenge MUST be specified as being an empty challenge."
1735
1736
1737
1738Melnikov & Zeilenga Standards Track [Page 31]
1739
1740RFC 4422 SASL June 2006
1741
1742
1743 The following technical change was made to the EXTERNAL mechanism:
1744
1745 - The authorization identity string is to be UTF-8 encoded.
1746
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.
1750
1751Editors' Addresses
1752
1753 Alexey Melnikov
1754 Isode Limited
1755 5 Castle Business Village
1756 36 Station Road
1757 Hampton, Middlesex,
1758 TW12 2BX, United Kingdom
1759
1760 EMail: Alexey.Melnikov@isode.com
1761 URI: http://www.melnikov.ca/
1762
1763
1764 Kurt D. Zeilenga
1765 OpenLDAP Foundation
1766
1767 EMail: Kurt@OpenLDAP.org
1768
1769
1770
1771
1772
1773
1774
1775
1776
1777
1778
1779
1780
1781
1782
1783
1784
1785
1786
1787
1788
1789
1790
1791
1792
1793
1794Melnikov & Zeilenga Standards Track [Page 32]
1795
1796RFC 4422 SASL June 2006
1797
1798
1799Full Copyright Statement
1800
1801 Copyright (C) The Internet Society (2006).
1802
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.
1806
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.
1814
1815Intellectual Property
1816
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.
1825
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.
1832
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.
1838
1839Acknowledgement
1840
1841 Funding for the RFC Editor function is provided by the IETF
1842 Administrative Support Activity (IASA).
1843
1844
1845
1846
1847
1848
1849
1850Melnikov & Zeilenga Standards Track [Page 33]
1851
1852