idnits 2.17.1 draft-ietf-sasl-rfc2222bis-14.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 16. -- Found old boilerplate from RFC 3978, Section 5.5 on line 1440. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1411. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1418. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1424. ** Found boilerplate matching RFC 3978, Section 5.4, paragraph 1 (on line 1428), which is fine, but *also* found old RFC 2026, Section 10.4C, paragraph 1 text on line 33. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == The 'Obsoletes: ' line in the draft header should list only the _numbers_ of the RFCs which will be obsoleted by this document (if approved); it should not include the word 'RFC' in the list. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords -- however, there's a paragraph with a matching beginning. Boilerplate error? (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (17 November 2005) is 6725 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'RFC3206' is mentioned on line 505, but not defined == Missing Reference: 'RFC2244' is mentioned on line 1336, but not defined ** Obsolete normative reference: RFC 2434 (Obsoleted by RFC 5226) ** Obsolete normative reference: RFC 3454 (Obsoleted by RFC 7564) ** Obsolete normative reference: RFC 4013 (Obsoleted by RFC 7613) ** Obsolete normative reference: RFC 4234 (Obsoleted by RFC 5234) -- Possible downref: Non-RFC (?) normative reference: ref. 'ASCII' -- Possible downref: Non-RFC (?) normative reference: ref. 'Unicode' -- Possible downref: Non-RFC (?) normative reference: ref. 'CharModel' -- Possible downref: Non-RFC (?) normative reference: ref. 'Glossary' -- Obsolete informational reference (is this intentional?): RFC 2246 (Obsoleted by RFC 4346) -- Obsolete informational reference (is this intentional?): RFC 2401 (Obsoleted by RFC 4301) -- Obsolete informational reference (is this intentional?): RFC 3548 (Obsoleted by RFC 4648) -- No information found for draft-ietf-tls-rfc2246-bis-xx - is the name correct? -- No information found for draft-ietf-sasl-gssapi-XX - is the name correct? -- No information found for draft-ietf-sasl-crammd5-xx - is the name correct? -- No information found for draft-ietf-sasl-rfc2831bis-xx - is the name correct? Summary: 9 errors (**), 0 flaws (~~), 5 warnings (==), 18 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 INTERNET-DRAFT A. Melnikov, Ed. 3 Intended Category: Standards Track ISODE Limited 4 Expires in six months K. Zeilenga, Ed. 5 Obsoletes: RFC 2222 OpenLDAP Project 6 17 November 2005 8 Simple Authentication and Security Layer (SASL) 9 11 Status of this Memo 13 By submitting this Internet-Draft, each author represents that any 14 applicable patent or other IPR claims of which he or she is aware have 15 been or will be disclosed, and any of which he or she becomes aware 16 will be disclosed, in accordance with Section 6 of BCP 79. 18 Internet-Drafts are working documents of the Internet Engineering Task 19 Force (IETF), its areas, and its working groups. Note that other 20 groups may also distribute working documents as Internet-Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference material 25 or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/1id-abstracts.html 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html 33 Copyright (C) The Internet Society (2005). All Rights Reserved. 35 Please see the Full Copyright section near the end of this document 36 for more information. 38 Abstract 40 The Simple Authentication and Security Layer (SASL) is a framework for 41 providing authentication and data security services in 42 connection-oriented protocols via replaceable mechanisms. It provides 43 a structured interface between protocols and mechanisms. The 44 resulting framework allows new protocols to reuse existing mechanisms 45 and allows old protocols to make use of new mechanisms. The framework 46 also provides a protocol for securing subsequent protocol exchanges 47 within a data security layer. 49 This document describes how a SASL mechanism is structured, describes 50 how protocols include support for SASL, and defines the protocol for 51 carrying a data security layer over a connection. Additionally, this 52 document defines one SASL mechanism, the EXTERNAL mechanism. 54 This document obsoletes RFC 2222. 56 Table of Contents 58 [[Page numbers to be filled in by RFC-Editor]] 60 Status of this Memo 61 Abstract 62 1. Introduction 63 1.1. Document Audiences 64 1.2. Relationship to Other Documents 65 1.3. Conventions 66 2. Identity Concepts 67 3. The Authentication Exchange 68 3.1. Mechanism Naming 69 3.2. Mechanism Negotiation 70 3.3. Request Authentication Exchange 71 3.4. Challenges and Responses 72 3.4.1. Authorization Identity String 73 3.5. Aborting Authentication Exchanges 74 3.6. Authentication Outcome 75 3.7. Security Layers 76 3.8. Multiple Authentications 77 4. Protocol Requirements 78 5. Mechanism Requirements 79 6. Security Considerations 80 6.1. Active Attacks 81 6.1.1. Man-in-the-middle Attacks 82 6.1.2. Replay Attacks 83 6.1.3. Truncation Attacks 84 6.2. Passive Attacks 85 6.3. Re-keying 86 6.4. Other considerations 87 7. IANA Considerations 88 8. References 89 9. Editors' Address 90 10. Acknowledgments 91 A. The SASL EXTERNAL Mechanism 92 B. Changes since RFC 2222 94 1. Introduction 96 The Simple Authentication and Security Layer (SASL) is a framework for 97 providing authentication and data security services in 98 connection-oriented protocols via replaceable mechanisms. SASL 99 provides a structured interface between protocols and mechanisms. 100 SASL also provides a protocol for securing subsequent protocol 101 exchanges within a data security layer. The data security layer can 102 provide data integrity, data confidentiality, and other services. 104 SASL's design is intended to allow new protocols to reuse existing 105 mechanisms without requiring redesign of the mechanisms and allows 106 existing protocols to make use of new mechanisms without redesign of 107 protocols. 109 SASL is conceptually a framework which provides an abstraction layer 110 between protocols and mechanisms as illustrated in the following 111 diagram. 113 SMTP LDAP XMPP Other protocols ... 114 \ | | / 115 \ | | / 116 SASL abstraction layer 117 / | | \ 118 / | | \ 119 EXTERNAL GSSAPI PLAIN Other mechanisms ... 121 It is through the interfaces of this abstraction layer that the 122 framework allows any protocol to utilize any mechanism. While this 123 layer does generally hide the particulars of protocols from mechanisms 124 and the particulars of mechanisms from protocols, this layer does not 125 generally hide the particulars of mechanisms from protocol 126 implementations. For example, different mechanisms require different 127 information to operate, some of them use password-based 128 authentication, some of then require realm information, others make 129 use of Kerberos tickets, certificates, etc.. Also, in order to 130 perform authorization, server implementations generally have to 131 implement identity mapping between authentication identities, whose 132 form is mechanism-specific, and authorization identities, whose form 133 is application protocol specific. Section 2 discusses identity 134 concepts. 136 It is possible to design and implement this framework in ways which do 137 abstract away particulars of similar mechanisms. Such a framework 138 implementation, as well as mechanisms implementations, could be 139 designed not only to be shared by multiple implementations of a 140 particular protocol, but be shared by implementations of multiple 141 protocols. 143 The framework incorporates interfaces with both protocols and 144 mechanisms in which authentication exchanges are carried out. Section 145 3 discusses SASL authentication exchanges. 147 To use SASL, each protocol (amongst other items) provides a method for 148 identifying which mechanism is to be used, provides a method for 149 exchange of mechanism-specific server-challenges and client-responses, 150 and a method for communicating the outcome of the authentication 151 exchange. Section 4 discusses SASL protocol requirements. 153 Each SASL mechanism defines (amongst other items) a series of server 154 challenges and client responses which provide authentication services 155 and negotiate data security services. Section 5 discusses SASL 156 mechanism requirements. 158 Section 6 discusses security considerations. Section 7 discusses IANA 159 considerations. Appendix A defines the SASL EXTERNAL mechanism. 161 1.1. Document Audiences 163 This document is written to serve several different audiences: 165 - protocol designers using this specification to support 166 authentication in their protocol, 168 - mechanism designers that define new SASL mechanisms, and 170 - implementors of clients or servers for those protocols which 171 support SASL. 173 While the document organization is intended to allow readers to focus 174 on details relevant to their engineering, readers are encouraged to 175 read and understand all aspects of this document. 177 1.2. Relationship to other documents 179 This document obsoletes RFC 2222. It replaces all portions of RFC 180 2222 excepting sections 7.1 (the KERBEROS_IV mechanism), 7.2 (the 181 GSSAPI mechanism), 7.3 (the SKEY mechanism). The KERBEROS_IV and SKEY 182 mechanisms are now viewed as obsolete and their specifications 183 provided in RFC 2222 are Historic. The GSSAPI mechanism is now 184 separately specified [SASL-GSSAPI]. 186 Appendix B provides a summary of changes since RFC 2222. 188 1.3. Conventions 190 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 191 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 192 document are to be interpreted as described in BCP 14 [RFC2119]. 194 Character names in this document use the notation for code points and 195 names from the Unicode Standard [Unicode]. For example, the letter 196 "a" may be represented as either or . 198 Note: a glossary of terms used in Unicode can be found in [Glossary]. 199 Information on the Unicode character encoding model can be found in 200 [CharModel]. 202 In examples, "C:" and "S:" indicate lines of data to be sent by the 203 client and server respectively. Lines have been wrapped for improved 204 readability. 206 2. Identity Concepts 208 In practice, authentication and authorization may involve multiple 209 identities, possibly in different forms (simple username, Kerberos 210 principal, X.500 Distinguished Name, etc.), possibly with different 211 representations (e.g.: ABNF-described UTF-8 encoded Unicode character 212 string, BER-encoded Distinguished Name). While technical 213 specifications often prescribe both the identity form and 214 representation used on the network, different identity forms and/or 215 representations may (and often are) used within implementations. How 216 identities of different forms relate to each other is, generally, a 217 local matter. Additionally, the forms and representations used within 218 an implementation is a local matter. 220 However, conceptually, SASL framework involves two identities: 221 1) an identity associated with the authentication credentials 222 (termed the authentication identity), and 223 2) an identity to act as (termed the authorization identity). 225 SASL mechanism specifications describe the credential form(s) (e.g., 226 X.509 certificates, Kerberos tickets, simple username/password) used 227 to authenticate the client, including (where appropriate) the syntax 228 and semantics of associated authentication identities. SASL protocol 229 specifications describe the identity form(s) used in authorization 230 and, in particular, prescribe the syntax and semantics of the 231 authorization identity character string to be transferred by 232 mechanisms. 234 The client provides its credentials which (implicitly or explicitly) 235 include an authentication identity and, optionally, a character string 236 representing the requested authorization identity as part of the SASL 237 exchange. When this character string is omitted or empty, the client 238 is requesting to act as the identity associated with the credentials 239 (e.g., the user is requesting to act as the authentication identity). 241 The server is responsible for verifying the client's credentials and 242 verifying that the client is allowed to act as the authorization 243 identity. A SASL exchange fails if either (or both) of these 244 verifications fails. (The SASL exchange may fail for other reasons, 245 such as service authorization failure.) 247 However, the precise form(s) of the authentication identities (used 248 within the server in its verifications, or otherwise) and the precise 249 form(s) of the authorization identities (used in making authorization 250 decisions, or otherwise) is beyond the scope of SASL and this 251 specification. In some circumstances, the precise identity forms used 252 in some context outside of the SASL exchange may be dictated by other 253 specifications. For instance, an identity assumption authorization 254 (proxy authorization) policy specification may dictate how 255 authentication and authorization identities are represented in policy 256 statements. 258 3. The Authentication Exchange 260 Each authentication exchange consists of a message from the client to 261 the server requesting authentication via a particular mechanism, 262 followed by one or more pairs of challenges from the server and 263 responses from the client, followed by a message from the server 264 indicating the outcome of the authentication exchange. (Note: 265 exchanges may also be aborted as discussed in Section 3.5.) 267 The following illustration provides a high-level overview of an 268 authentication exchange. 270 C: Request authentication exchange 271 S: Initial challenge 272 C: Initial response 273 274 S: Outcome of authentication exchange 276 If the outcome is successful and a security layer was negotiated, this 277 layer is then installed (see Section 3.7). This also applies to the 278 following illustrations. 280 Some mechanisms specify that the first data sent in the authentication 281 exchange is from the client to the server. Protocols may provide an 282 optional initial response field in the request message to carry this 283 data. Where the mechanism specifies the first data sent in the 284 exchange is from the client to the server, the protocol provides an 285 optional initial response field, and the client uses this field, the 286 exchange is shortened by one round-trip: 288 C: Request authentication exchange + Initial response 289 290 S: Outcome of authentication exchange 292 Where the mechanism specifies the first data sent in the exchange is 293 from the client to the server and this field is unavailable or unused, 294 the client request is followed by an empty challenge. 296 C: Request authentication exchange 297 S: Empty Challenge 298 C: Initial Response 299 300 S: Outcome of authentication exchange 302 Should a client include an initial response in its request where the 303 mechanism does not allow the client to send data first, the 304 authentication exchange fails. 306 Some mechanisms specify that the server is to send additional data to 307 the client when indicating a successful outcome. Protocols may 308 provide an optional additional data field in the outcome message to 309 carry this data. Where the mechanism specifies the server is to 310 return additional data with the successful outcome, the protocol 311 provides an optional additional data field in the outcome message, and 312 the server uses this field, the exchange is shortened by one 313 round-trip: 315 C: Request authentication exchange 316 S: Initial challenge 317 C: Initial response 318 319 S: Outcome of authentication exchange with 320 additional data with success 322 Where the mechanism specifies the server is to return additional data 323 to the client with a successful outcome and this field is unavailable 324 or unused, the additional data is sent as a challenge whose response 325 is empty. After receiving this response, the server then indicates 326 the successful outcome. 328 C: Request authentication exchange 329 S: Initial challenge 330 C: Initial response 331 332 S: Additional data challenge 333 C: Empty Response 334 S: Outcome of authentication exchange 336 Where mechanisms specify the first data sent in the exchange is from 337 the client to the server and additional data is sent to the client 338 along with indicating a successful outcome, and the protocol provides 339 fields supporting both, the exchange can be shorted by two 340 round-trips: 342 C: Request authentication exchange + Initial response 343 344 S: Outcome of authentication exchange 345 with additional data with success 347 instead of: 349 C: Request authentication exchange 350 S: Empty Challenge 351 C: Initial Response 352 353 S: Additional data challenge 354 C: Empty Response 355 S: Outcome of authentication exchange 357 3.1. Mechanism Naming 359 SASL mechanisms are named by character strings, from 1 to 20 360 characters in length, consisting of ASCII [ASCII] uppercase letters, 361 digits, hyphens, and/or underscores. In the following Augmented 362 Backus-Naur Form (ABNF) [RFC4234] grammar, the production 363 defines the syntax of a SASL mechanism name. 365 sasl-mech = 1*20mech-char 366 mech-char = UPPER-ALPHA / DIGIT / HYPHEN / UNDERSCORE 367 ; mech-char is restricted to A-Z (uppercase only), 0-9, -, and _ 368 ; from ASCII character set. 370 UPPER-ALPHA = %x41-5A ; A-Z (uppercase only) 371 DIGIT = %x30-39 ; 0-9 372 HYPHEN = %x2D ; hyphen (-) 373 UNDERSCORE = %x5F ; underscore (_) 375 SASL mechanisms names are registered as discussed in Section 7.1. 377 3.2. Mechanism Negotiation 379 Mechanism negotiation is protocol-specific. 381 Commonly, a protocol will specify that the server advertises supported 382 and available mechanisms to the client via some facility provided by 383 the protocol and the client will then select the "best" mechanism from 384 this list which its supports and finds suitable. 386 It is noted that the mechanism negotiation is not protected by the 387 subsequent authentication exchange and hence is subject to downgrade 388 attacks if not protected by other means. 390 To detect downgrade attacks, a protocol can allow the client to 391 discover available mechanisms subsequent to the authentication 392 exchange and installation of data security layers with at least data 393 integrity protection. This allows the client to detect changes to the 394 list of mechanisms supported by the server. 396 3.3. Request Authentication Exchange 398 The authentication exchange is initiated by the client by requesting 399 authentication via a mechanism it specifies. The client sends a 400 message that contains the name of the mechanism to the server. The 401 particulars of the message are protocol specific. 403 It is noted that the name of the mechanism is not protected by the 404 mechanism, and hence subject to alteration by an attacker if not 405 integrity protected by other means. 407 Where the mechanism is defined to allow the client to send data first, 408 and the protocol's request message includes an optional initial 409 response field, the client may include the response to the initial 410 challenge in the authentication request message. 412 3.4. Challenges and Responses 414 The authentication exchange involves one or more pairs of 415 server-challenges and client-responses, the particulars of which are 416 mechanism specific. These challenges and responses are enclosed in 417 protocol messages, the particulars of which are protocol specific. 419 Through these challenges and responses, the mechanism may: 420 - authenticate the client to the server, 421 - authenticate the server to the client, 422 - transfer an authorization identity string, 423 - negotiate a security layer, and 424 - provide other services. 426 The negotiation of the security layer may involve negotiation of the 427 security services to be provided in the layer, how these services will 428 be provided, and negotiation of a maximum cipher-text buffer size each 429 side is able to receive in the layer (see Section 3.6). 431 After receiving an authentication request or any client response, the 432 server may issue a challenge, abort the exchange, or indicate the 433 outcome of an exchange. After receiving a challenge, a client 434 mechanism may issue a response or abort the exchange. 436 3.4.1. Authorization Identity String 438 The authorization identity string is a sequence of zero or more 439 Unicode [Unicode] characters, excluding the NUL (U+0000) character, 440 representing the identity to act as. 442 If the authorization identity string is absent, the client is 443 requesting to act as the identity the server associates with the 444 client's credentials. An empty string is equivalent to an absent 445 authorization identity. 447 Non-empty authorization identity string indicates the client wishes to 448 act as the identity represented by the string. In this case, the form 449 of identity represented by the string, as well as the precise syntax 450 and semantics of the string, is protocol specific. 452 While the character encoding schema used to transfer the authorization 453 identity string in the authentication exchange is mechanism specific, 454 mechanisms are expected to be capable of carrying the entire Unicode 455 repertoire (with the exception of the NUL character). 457 3.5. Aborting Authentication Exchanges 459 A client or server may desire to abort an authentication exchange if 460 it is unwilling or unable to continue (or enter into). 462 A client may abort the authentication exchange by sending a message, 463 the particulars of which are protocol-specific, to the server, 464 indicating the exchange is aborted. The server may be required by the 465 protocol to return a message in response to the client's abort 466 message. 468 Likewise, a server may abort the authentication exchange by sending a 469 message, the particulars of which are protocol-specific, to the 470 client, indicating the exchange is aborted. 472 3.6. Authentication Outcome 474 At the conclusion of the authentication exchange, the server sends a 475 message, the particulars of which are protocol specific, to the client 476 indicating the outcome of the exchange. 478 The outcome is not successful if 479 - the authentication exchange failed for any reason, 480 - the clients credentials could not be verified, 481 - the server cannot associate an identity with the client's 482 credentials, 483 - the client-provided authorization identity string is malformed, 484 - the identity associated with the client's credentials is not 485 authorized to act as the requested authorization identity, 486 - the negotiated security layer (or lack thereof) is not suitable, 487 or 488 - the server is not willing to provide service to the client for any 489 reason. 491 The protocol may include an optional additional data field in this 492 outcome message. This field can only include additional data when the 493 outcome is successful. 495 If the outcome is successful and a security layer was negotiated, this 496 layer is then installed. If the outcome is unsuccessful, or a 497 security layer was not negotiated, any existing security is left in 498 place. 500 The outcome message provided by the server can provide a way for the 501 client to distinguish between errors which are best dealt with by re- 502 prompting the user for her credentials, errors which are best dealt 503 with by telling the user to try again later, and errors where the user 504 must contact a system administrator for resolution (see The SYS and 505 AUTH POP Response Codes [RFC3206] specification for an example). This 506 distinction is particularly useful during scheduled server maintenance 507 periods as it reduces support costs. It is also important that the 508 server can be configured such that the outcome message will not 509 distinguish between a valid user with invalid credentials and an 510 invalid user. 512 3.7. Security Layers 514 SASL mechanisms may offer a wide range of services in security layers. 516 Typical services include data integrity and data confidentiality. 517 SASL mechanisms which do not provide a security layer are treated as 518 negotiating no security layer. 520 If use of a security layer is negotiated in the authentication 521 protocol exchange, the layer is installed by the server after 522 indicating the outcome of the authentication exchange and installed by 523 the client upon receipt the outcome indication. In both cases, the 524 layer is installed before transfer of further protocol data. The 525 precise position that the layer takes effect in the protocol data 526 stream is protocol specific. 528 Once the security layer is in effect in the protocol data stream, it 529 remains in effect until either a subsequently negotiated security 530 layer is installed, or the underlying transport connection is closed. 532 When in effect, the security layer processes protocol data into 533 buffers of protected data. If at any time the security layer is 534 unable or unwilling to continue producing buffers protecting protocol 535 data, the underlying transport connection MUST be closed. If the 536 security layer is not able to decode a received buffer, the underlying 537 connection MUST be closed. In both cases the underlying transport 538 connection SHOULD be closed gracefully. 540 Each buffer of protected data is transferred over the underlying 541 transport connection as a sequence of octets prepended with a four 542 octet field in network byte order that represents the length of the 543 buffer. The length of the protected data buffer MUST be no larger 544 than the maximum size the other side expects. Upon the receipt of a 545 length field whose value is greater than maximum size, the receiver 546 SHOULD close the connection, as this might be a sign of an attack. 548 The maximum size each side expects is fixed by the mechanism, either 549 through negotiation or by its specification. 551 3.8. Multiple Authentications 553 Unless explicitly permitted in the protocol (as stated in the 554 protocol's technical specification), only one successful SASL 555 authentication exchange may occur in a protocol session. In this 556 case, once an authentication exchange has successfully completed, 557 further attempts to initiate an authentication exchange fail. 559 Where multiple successful SASL authentication exchanges are permitted 560 in the protocol, then in no case may multiple SASL security layers be 561 simultaneously in effect. If a security layer is in effect and a 562 subsequent SASL negotiation selects a second security layer, then the 563 second security layer replaces the first. If a security layer is in 564 effect and a subsequent SASL negotiation selects no security layer, 565 the original security layer remains in effect. 567 Where multiple successful SASL negotiations are permitted in the 568 protocol, the effect of a failed SASL authentication exchange upon the 569 previously established authentication and authorization state is 570 protocol specific. The protocol's technical specification should be 571 consulted to determine whether the previous authentication and 572 authorization state remains in force, or changed to an anonymous 573 state, or otherwise effected. Regardless of the protocol-specific 574 effect upon previously established authentication and authorization 575 state, the previously negotiated security layer remains in effect. 577 4. Protocol Requirements 579 In order for a protocol to offer SASL services, its specification MUST 580 supply the following information: 582 1) A service name, to be selected from registry of "service" elements 583 for the GSSAPI host-based service name form, as described in 584 Section 4.1 of [RFC2743]. Note that this registry is shared by all 585 GSSAPI and SASL mechanisms. 587 2) Detail any mechanism negotiation facility the protocol provides 588 (see Section 3.2). 590 A protocol SHOULD specify a facility through which the client may 591 discover, both before initiation of the SASL exchange and after 592 installing security layers negotiated by the exchange, the names of 593 the SASL mechanisms the server makes available to the client. The 594 latter is important to allow the client to detect downgrade 595 attacks. This facility is typically provided through the 596 protocol's extensions or capabilities discovery facility. 598 3) Definition of the messages necessary for authentication exchange, 599 including: 601 a) A message to initiate the authentication exchange (see Section 602 3.3). 604 This message MUST contain a field for carrying the name of the 605 mechanism selected by the client. 607 This message SHOULD contain an optional field for carrying an 608 initial response. If the message is defined with this field, 609 the specification MUST describe how messages with an empty 610 initial response are distinguished from messages with no initial 611 response. This field MUST be capable of carrying arbitrary 612 sequences of octets (including zero length sequences and 613 sequences containing zero-valued octets). 615 b) Messages to transfer server challenges and client responses. 616 (see Section 3.4). 618 Each of these messages MUST be capable of carrying arbitrary 619 sequences of octets (including zero length sequences and 620 sequences containing zero-valued octets). 622 c) A message to indicate the outcome of the authentication exchange 623 (see Section 3.6). 625 This message SHOULD contain an optional field for carrying 626 additional data with a successful outcome. If the message is 627 defined with this field, the specification MUST describe how 628 messages with an empty additional data are distinguished from 629 messages with no additional data. This field MUST be capable of 630 carrying arbitrary sequences of octets (including zero length 631 sequences and sequences containing zero-valued octets). 633 4) Prescribe the syntax and semantics of non-empty authorization 634 identity strings (see Section 3.4.1). 636 In order to avoid interoperability problems due to differing 637 normalizations, the protocol specification MUST detail precisely 638 the how and where (client or server) non-empty authorization 639 identity strings are prepared, including all normalizations, for 640 comparison and other applicable functions to ensure proper 641 function. 643 Specifications are encouraged to prescribe use of existing 644 authorization identity forms as well as existing string 645 representations, such as simple user names [RFC4013]. 647 Where the specification does not precisely prescribe how identities 648 in SASL relate to identities used elsewhere in the protocol, for 649 instance in access control policy statements, it may be appropriate 650 for the protocol to provide a facility by which the client can 651 discover information (such as the representation of the 652 authentication identity used in making access control decisions) 653 about established identities for these uses. 655 5) Detail any facility the protocol provides that allows the client 656 and/or server to abort authentication exchange (see Section 3.5). 658 Protocols which support multiple authentications typically allow a 659 client to abort an on-going authentication exchange by initiating a 660 new authentication exchange. Protocols which do not support 661 multiple authentications may require the client to close the 662 connection and start over to abort an on-going authentication 663 exchange. 665 Protocols typically allow the server to abort on-going 666 authentication exchanges by returning a non-successful outcome 667 message. 669 6) Identify precisely where newly negotiated security layers start to 670 take effect, in both directions (see Section 3.7). 672 Typically, specifications require security layer to start taking 673 effect, in data being sent by the server, on the first octet 674 following the outcome message and, in data being sent by the 675 client, on the first octet sent after receipt of the outcome 676 message. 678 7) If the protocol supports other layered security services, such as 679 Transport Layer Security (TLS) [RFC2246], the specification MUST 680 prescribe the order in which security layers are applied to 681 protocol data. 683 For instance, where a protocol supports both TLS and SASL security 684 layers, the specification could prescribe any of the following: 685 a) SASL security layer is always applied first to data being sent 686 and, hence, applied last to received data, 687 b) SASL security layer is always applied last to data being sent 688 and, hence, applied first to received data, 689 c) Layers are applied in the order in which they were installed, 690 d) Layers are applied in the reverse order in which they were 691 installed, or 692 e) Both TLS and SASL security layers cannot be installed. 694 8) Indicate whether the protocol supports multiple authentications 695 (see Section 3.8). If so, the protocol MUST detail the effect a 696 failed SASL authentication exchange will have upon previously 697 established authentication and authorization state. 699 Protocol specifications SHOULD avoid stating implementation 700 requirements which would hinder replacement of applicable mechanisms. 701 In general, protocol specification SHOULD be mechanism neutral. There 702 are a number reasonable exceptions to this recommendation, including: 703 - detailing how credentials (which are mechanism-specific) are 704 managed in the protocol, 705 - detailing how authentication identities (which are 706 mechanism-specific) and authorization identities (which are 707 protocol-specific) relate to each other, and 708 - detailing which mechanisms are applicable to the protocol. 710 5. Mechanism Requirements 712 SASL mechanism specifications MUST supply the following information: 714 1) The name of the mechanism (see Section 3.1). This name MUST be 715 registered as discussed in Section 7.1. 717 2) A definition of the server-challenges and client-responses of the 718 authentication exchange, as well as: 720 a) An indication whether mechanism is client-first, variable, or 721 server-first. If a SASL mechanism is defined as client-first 722 and the client does not send an initial response, then the first 723 server challenge MUST be empty (the EXTERNAL mechanism is an 724 example of this case). If a SASL mechanism is defined as 725 variable, then the specification needs to state how the server 726 behaves when the initial client response is omitted (the 727 DIGEST-MD5 mechanism [DIGEST-MD5] is an example of this case). 728 If a SASL mechanism is defined as server-first then the client 729 MUST NOT send an initial client response (the CRAM-MD5 mechanism 730 [CRAM-MD5] is an example of this case). 732 b) An indication whether the server is expected to provide 733 additional data when indicating a successful outcome. If so, if 734 the server sends the additional data as a challenge, the 735 specification MUST indicate the response to this challenge is an 736 empty response. 738 SASL mechanisms SHOULD be designed to minimize the number of 739 challenges and responses necessary to complete the exchange. 741 3) An indication of whether the mechanism is capable of transferring 742 authorization identity strings (see Section 3.4.1). While some 743 legacy mechanisms are incapable of transmitting an authorization 744 identity (which means that for these mechanisms the authorization 745 identity is always the empty string), newly defined mechanisms 746 SHOULD be capable of transferring authorization identity strings. 747 The mechanism SHOULD NOT be capable of transferring both no 748 authorization identity string and an empty authorization identity. 750 Mechanisms which are capable of transferring an authorization 751 identity string MUST be capable of transferring arbitrary non-empty 752 sequences of Unicode characters, excluding those which contain the 753 NUL (U+0000) character. Mechanisms SHOULD use the UTF-8 [RFC3629] 754 transformation format. The specification MUST detail how any 755 Unicode code points special to the mechanism which might appear in 756 the authorization identity string are escaped to avoid ambiguity 757 during decoding of the authorization identity string. Typically, 758 mechanisms which have special characters require these special 759 characters to be escaped or encoded in the character string (after 760 encoding it a particular Unicode transformation format) using a 761 data encoding scheme such as Base64 [RFC3548]. 763 4) The specification MUST detail whether or not the mechanism offers a 764 security layer. If the mechanism does, the specification MUST 765 detail the security and other services offered in the layer as well 766 as how these services are to be implemented. 768 5) If the underlying cryptographic technology used by a mechanism 769 supports data integrity, then the mechanism specification MUST 770 integrity protect the transmission of an authorization identity and 771 the negotiation of the security layer. 773 SASL mechanisms SHOULD be protocol neutral. 775 SASL mechanisms SHOULD reuse existing credential and identity forms, 776 as well as associated syntaxes and semantics. 778 SASL mechanisms SHOULD use UTF-8 transformation format [RFC3629] for 779 encoding Unicode [Unicode] code points for transfer. 781 In order to avoid interoperability problems due to differing 782 normalizations, when a mechanism calls for character data (other than 783 the authorization identity string) to be used as input to a 784 cryptographic and/or comparison function, the specification MUST 785 detail precisely how and where (client or server) the character data 786 is to be prepared, including all normalizations, for input into the 787 function to ensure proper operation. 789 For simple user names and/or passwords in authentication credentials, 790 SASLprep [RFC4013] (a profile of the StringPrep [RFC3454] preparation 791 algorithm), SHOULD be specified as the preparation algorithm. 793 The mechanism SHOULD NOT use the authorization identity string in 794 generation of any long-term cryptographic keys or hashes as there is 795 no requirement that the authorization identity string be canonical. 796 Long-term, here, means a term longer than the duration of the 797 authentication exchange in which they were generated in. That is, as 798 different clients (of the same or different protocol) may provide 799 different authorization identity strings which are semantically 800 equivalent, use of authorization identity strings in generation of 801 cryptographic keys and hashes will likely lead to interoperability and 802 other problems. 804 6. Security Considerations 806 Security issues are discussed throughout this memo. 808 Many existing SASL mechanisms do not provide adequate protection 809 against passive attacks, let alone active attacks, in the 810 authentication exchange. Many existing SASL mechanisms do not offer 811 security layers. It is hoped that future SASL mechanisms will provide 812 strong protection against passive and active attacks in the 813 authentication exchange, as well as security layers with strong basic 814 data security features (e.g., data integrity and data confidentiality) 815 services. It is also hoped that future mechanisms will provide more 816 advanced data security services like re-keying (see Section 6.3). 818 Regardless, the SASL framework is suspectable to downgrade attacks. 819 Section 6.1.2 offers a variety of approaches for preventing or 820 detecting these attacks. In some cases, it is appropriate to use data 821 integrity protective services external to SASL (e.g., TLS [TLS]) to 822 protect against downgrade attacks in SASL. Use of external protective 823 security services is also important when the mechanisms available do 824 not themselves offer adequate integrity and/or confidentiality 825 protection of the authentication exchange and/or protocol data. 827 6.1. Active Attacks 829 6.1.1. Hijack Attacks 831 When the client selects a SASL security layer with at least integrity 832 protection, this protect serves as a counter-measure against an active 833 attacker hijacking the connection and modifying protocol data sent 834 after establishment of the security layer. Implementations should 835 close the connection when the security services in an SASL security 836 layer report protocol data report lack of data integrity. 838 6.1.2. Downgrade Attacks 840 It is important that any security-sensitive protocol negotiations be 841 performed after installation of security layer with data integrity 842 protection. Protocols should be designed such that negotiations 843 performed prior to this installation should be revalidated after 844 installation is complete. Negotiation of the SASL mechanism is 845 security-sensitive. 847 When a client negotiates the authentication mechanism with the server 848 and/or other security features, it is possible for an active attacker 849 to cause a party to use the least secure security services available. 850 For instance, an attacker can modify the server-advertised mechanism 851 list or can modify client-advertised security feature list within a 852 mechanism response. To protect against this sort of attack, 853 implementations should not advertise mechanisms and/or features which 854 cannot meet their minimum security requirements, should not enter into 855 or continue authentication exchanges which cannot meet their minimum 856 security requirements, and should verify that completed authentication 857 exchanges result in security services that meet their minimum security 858 requirements. Note that each endpoint needs to independently verify 859 that its security requirements are met. 861 In order to detect downgrade attacks to the least (or less) secure 862 mechanism supported, the client may discover the SASL mechanisms the 863 server makes available both before the SASL authentication exchange 864 and after the negotiated SASL security layer (with at least data 865 integrity protection) has been installed through the protocol's 866 mechanism discovery facility. If the client finds that the integrity 867 protected list (the list obtained after the security layer was 868 installed) contains a stronger mechanism than those in the previously 869 obtained list, the client should assume the previously obtained list 870 was modified by an attacker and should close the underlying transport 871 connection. 873 The client's initiation of the SASL exchange, including the selection 874 of a SASL mechanism, is done in the clear and may be modified by an 875 active attacker. It is important for any new SASL mechanisms to be 876 designed such that an active attacker cannot obtain an authentication 877 with weaker security properties by modifying the SASL mechanism name 878 and/or the challenges and responses. 880 Multi-level negotiation of security features is prone to downgrade 881 attack. Protocol designers should avoid offering higher level 882 negotiation of security features in protocols (e.g., above SASL 883 mechanism negotiation) and mechanism designers should avoid lower 884 level negotiation of security features in mechanisms (e.g., below SASL 885 mechanism negotiation). 887 6.1.3. Replay Attacks 889 Some mechanisms may be subject to replay attacks unless protected by 890 external data security services (e.g., TLS). 892 6.1.4. Truncation Attacks 894 Most existing SASL security layers do not themselves offer protection 895 against truncation attack. In a truncation attack, the active 896 attacker causes the protocol session to be closed, causing a 897 truncation of the possibly integrity protected data stream that leads 898 to behavior of one or both the protocol peers that inappropriately 899 benefits the attacker. Truncation attacks are fairly easy to defend 900 against in connection-oriented application-level protocols. A 901 protocol can defend against these attacks by ensuring that each 902 information exchange has a clear final result and that each protocol 903 session has a graceful closure mechanism, and that these are integrity 904 protected. 906 6.1.5. Other Active Attacks 908 When use of a security layer is negotiated by the authentication 909 protocol exchange, the receiver should handle gracefully any protected 910 data buffer larger than the defined/negotiated maximal size. In 911 particular, it must not blindly allocate the amount of memory 912 specified in the buffer size field, as this might cause the "out of 913 memory" condition. If the receiver detects a large block, it should 914 close the connection. 916 6.2. Passive Attacks 918 Many mechanisms are subject to various passive attacks, including 919 simple eavesdropping of unprotected credential information as well as 920 online and offline dictionary attacks of protected credential 921 information. 923 6.3. Re-keying 924 The secure or administratively permitted lifetimes of SASL mechanisms' 925 security layers are finite. Cryptographic keys weaken as they are 926 used and as time passes; the more time and/or cipher-text that a 927 cryptanalyst has after the first use of the a key, the easier it is 928 for the cryptanalyst to mount attacks on the key. 930 Administrative limits on a security layer's lifetime may take the form 931 of time limits expressed in X.509 certificates, Kerberos V tickets, or 932 in directories, and are often desired. In practice one likely effect 933 of administrative lifetime limits is that applications may find that 934 security layers stop working in the middle of application protocol 935 operation, such as, perhaps, during large data transfers. As the 936 result of this the connection will be closed (see Section 3.7), which 937 will result in unpleasant user experience. 939 Re-keying (key renegotiation process) is a way of addressing the 940 weakening of cryptographic keys. SASL framework does not itself 941 provide for re-keying, SASL mechanisms may. Designers of future SASL 942 mechanisms should consider providing re-keying services. 944 Applications that wish to re-key SASL security layers where the 945 mechanism does not provide for re-keying should reauthenticate the 946 same IDs and replace the expired or soon-to-expire security layers. 947 This approach requires support for reauthentication in the application 948 protocols (see Section 3.8). 950 6.4. Other Considerations 952 Protocol designers and implementors should understand the security 953 considerations of mechanisms so they may select mechanisms which are 954 applicable to their needs. 956 Distributed server implementations need to be careful in how they 957 trust other parties. In particular, authentication secrets should 958 only be disclosed to other parties that are trusted to manage and use 959 those secrets in manner acceptable to disclosing party. Applications 960 using SASL assume that SASL security layers providing data 961 confidentiality are secure even when an attacker chooses the text to 962 be protected by the security layer. Similarly applications assume 963 that the SASL security layer is secure even if the attacker can 964 manipulate the cipher-text output of the security layer. New SASL 965 mechanisms are expected to meet these assumptions. 967 Unicode security considerations [UTR36] apply to authorization 968 identity strings, and well as UTF-8 [RFC3629] security considerations 969 where UTF-8 is used. SASLprep [RFC4013] and StringPrep [RFC3454] 970 security considerations also apply where used. 972 7. IANA Considerations 974 7.1. SASL Mechanism Registry 976 SASL mechanism registry is maintained by IANA. The registry is 977 currently available at 978 . 980 The purpose of this registry is not only to ensure uniqueness of 981 values used to name SASL mechanisms, but to provide a definitive 982 references to technical specifications detailing each SASL mechanism 983 available for use on the Internet. 985 There is no naming convention for SASL mechanisms; any name that 986 conforms to the syntax of a SASL mechanism name can be registered. 988 The procedure detailed in Section 7.1.1 is to be used for registration 989 of a value naming a specific individual mechanism. 991 The procedure detailed in Section 7.1.2 is to be used for registration 992 of a value naming a family of related mechanisms. 994 Comments may be included in the registry as discussed in Section 7.1.3 995 and may be changed as discussed in Section 7.1.4. 997 It is requested that the SASL mechanism registry be updated to reflect 998 that this document provides the definitive technical specification for 999 SASL and that this section provides the registration procedures for 1000 this registry. 1002 7.1.1. Mechanism Name Registration Procedure 1004 IANA will register new SASL mechanism names on a First Come First 1005 Served basis, as defined in BCP 26 [RFC2434]. IANA has the right to 1006 reject obviously bogus registration requests, but will perform no 1007 review of claims made in the registration form. 1009 Registration of a SASL mechanism is requested by filling in the 1010 following template: 1012 Subject: Registration of SASL mechanism X 1014 SASL mechanism name (or prefix for the family): 1016 Security considerations: 1018 Published specification (recommended): 1020 Person & email address to contact for further information: 1022 Intended usage: (One of COMMON, LIMITED USE or OBSOLETE) 1024 Owner/Change controller: 1026 Note: (Any other information that the author deems relevant may be 1027 added here .) 1029 and sending it via electronic mail to IANA at . 1031 While this registration procedures do not require expert review, 1032 authors of SASL mechanisms are encouraged to seek community review and 1033 comment whenever that is feasible. Authors may seek community review 1034 by posting a specification of their proposed mechanism as an 1035 Internet-Draft. SASL mechanisms intended for widespread use should be 1036 standardized through the normal IETF process, when appropriate. 1038 7.1.2. Family Name Registration Procedure 1040 As noted above, there is no general naming convention for SASL 1041 mechanisms. However, specifications may reserve a portion of the SASL 1042 mechanism namespace for a set of related SASL mechanisms, a "family" 1043 of SASL mechanisms. Each family of SASL mechanisms is identified by a 1044 unique prefix, such as X-. Registration of new SASL mechanism family 1045 names requires Expert Review as defined in BCP 26 [RFC2434]. 1047 Registration of a SASL family name is requested by filling in the 1048 following template: 1050 Subject: Registration of SASL mechanism family X 1052 SASL family name (or prefix for the family): 1054 Security considerations: 1056 Published specification (recommended): 1058 Person & email address to contact for further information: 1060 Intended usage: (One of COMMON, LIMITED USE or OBSOLETE) 1062 Owner/Change controller: 1064 Note: (Any other information that the author deems relevant may be 1065 added here .) 1067 and sending it via electronic mail to the IETF SASL mailing list at 1068 with copy to IANA at . After 1069 allowing two weeks for community input on the IETF SASL mailing list, 1070 the expert will determine the appropriateness of the registration 1071 request and either approve or disappove the request with notice to 1072 requestor, the mailing list, and IANA. 1074 The review should focus on the appropriateness of the requested family 1075 name for the proposed use and the appropriateness of the proposed 1076 naming and registration plan for existing and future mechanism names 1077 in the family. The scope of this request review may entail 1078 consideration of relevant aspects of any provided technical 1079 specification, such as their IANA Considerations section. However 1080 this review is narrowly focused on the appropriateness of the 1081 requested registration and not on the overall soundness of any 1082 provided technical specification. 1084 Authors are encouraged to community review by posting the technical 1085 specification as an Internet-Draft and soliciting comment by posting 1086 to appropriate IETF mailing lists. 1088 7.1.3. Comments on SASL Mechanism Registrations 1090 Comments on a registered SASL mechanism/family should first be sent to 1091 the "owner" of the mechanism/family and/or to the 1092 mailing list. 1094 Submitters of comments may, after a reasonable attempt to contact the 1095 owner, request IANA to attach their comment to the SASL mechanism 1096 registration itself by sending mail to . At IANA's 1097 sole discretion, IANA may attach the comment to the SASL mechanism's 1098 registration. 1100 7.1.4. Change Control 1102 Once a SASL mechanism registration has been published by IANA, the 1103 author may request a change to its definition. The change request 1104 follows the same procedure as the registration request. 1106 The owner of a SASL mechanism may pass responsibility for the SASL 1107 mechanism to another person or agency by informing IANA; this can be 1108 done without discussion or review. 1110 The IESG may reassign responsibility for a SASL mechanism. The most 1111 common case of this will be to enable changes to be made to mechanisms 1112 where the author of the registration has died, moved out of contact or 1113 is otherwise unable to make changes that are important to the 1114 community. 1116 SASL mechanism registrations may not be deleted; mechanisms which are 1117 no longer believed appropriate for use can be declared OBSOLETE by a 1118 change to their "intended usage" field; such SASL mechanisms will be 1119 clearly marked in the lists published by IANA. 1121 The IESG is considered to be the owner of all SASL mechanisms which 1122 are on the IETF standards track. 1124 7.2. Registration Changes 1126 It is requested that IANA update the SASL mechanisms registry as 1127 follows: 1129 1) Change the "Intended usage" of the KERBEROS_V4 and SKEY mechanism 1130 registrations to OBSOLETE. 1132 2) Change the "Published specification" of the EXTERNAL mechanism to 1133 this document as indicated below: 1135 Subject: Updated Registration of SASL mechanism EXTERNAL 1136 Family of SASL mechanisms: NO 1137 SASL mechanism name: EXTERNAL 1138 Security considerations: See A.3 of RFC XXXX 1139 Published specification (optional, recommended): RFC XXXX 1140 Person & email address to contact for further information: 1141 Alexey Melnikov 1142 Intended usage: COMMON 1143 Owner/Change controller: IESG 1144 Note: Updates existing entry for EXTERNAL 1146 8. References 1148 [[Note to the RFC Editor: please replace the citation tags used in 1149 referencing Internet-Drafts with tags of the form RFCnnnn where 1150 possible.]] 1152 8.1. Normative References 1154 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1155 Requirement Levels", BCP 14 (also RFC 2119), March 1997. 1157 [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an 1158 IANA Considerations Section in RFCs", BCP 26 (also RFC 1159 2434), October 1998. 1161 [RFC2743] Linn, J., "Generic Security Service 1162 Application Program Interface, Version 2, Update 1", RFC 1163 2743, January 2000. 1165 [RFC3454] Hoffman, P. and M. Blanchet, "Preparation of 1166 Internationalized Strings ('stringprep')", RFC 3454, 1167 December 2002. 1169 [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 1170 10646", RFC 3629 (also STD 63), November 2003. 1172 [RFC4013] Zeilenga, K., "SASLprep: Stringprep Profile for User 1173 Names and Passwords", RFC 4013, February 2005. 1175 [RFC4234] Crocker, D. and P. Overell, "Augmented BNF for Syntax 1176 Specifications: ABNF", RFC 4234, October 2005. 1178 [ASCII] Coded Character Set--7-bit American Standard Code for 1179 Information Interchange, ANSI X3.4-1986. 1181 [Unicode] The Unicode Consortium, "The Unicode Standard, Version 1182 3.2.0" is defined by "The Unicode Standard, Version 3.0" 1183 (Reading, MA, Addison-Wesley, 2000. ISBN 0-201-61633-5), 1184 as amended by the "Unicode Standard Annex #27: Unicode 1185 3.1" (http://www.unicode.org/reports/tr27/) and by the 1186 "Unicode Standard Annex #28: Unicode 3.2" 1187 (http://www.unicode.org/reports/tr28/). 1189 [CharModel] Whistler, K. and M. Davis, "Unicode Technical Report 1190 #17, Character Encoding Model", UTR17, 1191 , August 1192 2000. 1194 [Glossary] The Unicode Consortium, "Unicode Glossary", 1195 . 1197 8.2. Informative References 1199 [RFC2246] Dierks, T. and, C. Allen, "The TLS Protocol Version 1200 1.0", RFC 2246, January 1999. 1202 [RFC2401] Kent, S., and R. Atkinson, "Security Architecture for 1203 the Internet Protocol", RFC 2401, November 1998. 1205 [RFC3548] Josefsson, S., "The Base16, Base32, and Base64 Data 1206 Encodings", RFC 3548, July 2003. 1208 [TLS] Dierks, T. and, E. Rescorla, "The TLS Protocol Version 1209 1.1", draft-ietf-tls-rfc2246-bis-xx.txt, a work in 1210 progress. 1212 [SASL-GSSAPI] Melnikov, A. (Editor), "SASL GSSAPI mechanisms", 1213 draft-ietf-sasl-gssapi-XX.txt, a work in progress. 1215 [UTR36] Davis, M., "(Draft) Unicode Technical 1216 Report #36, Character Encoding Model", UTR17, 1217 , February 1218 2005. 1220 [CRAM-MD5] Nerenberg, L., "The CRAM-MD5 SASL Mechanism", 1221 draft-ietf-sasl-crammd5-xx.txt, a work in progress. 1223 [DIGEST-MD5] Leach, P., C. Newman, and A. Melnikov, "Using Digest 1224 Authentication as a SASL Mechanism", 1225 draft-ietf-sasl-rfc2831bis-xx.txt, a work in progress. 1227 9. Editors' Address 1229 Alexey Melnikov 1230 Isode Limited 1231 5 Castle Business Village 1232 36 Station Road 1233 Hampton, Middlesex, 1234 TW12 2BX, United Kingdom 1236 Email: Alexey.Melnikov@isode.com 1237 URI: http://www.melnikov.ca/ 1239 Kurt D. Zeilenga 1240 OpenLDAP Foundation 1242 Email: Kurt@OpenLDAP.org 1244 10. Acknowledgments 1246 This document is a revision of RFC 2222 written by John Myers. 1248 This revision is a product of the IETF Simple Authentication and 1249 Security Layer (SASL) Working Group. 1251 The following individuals contributed significantly to this revision: 1252 Abhijit Menon-Sen, Hallvard B Furuseth, Jeffrey Hutzelman, John Myers, 1253 Luke Howard, Magnus Nystrom, Nicolas Williams, Peter Saint-Andre, RL 1254 'Bob' Morgan, Rob Siemborski, Sam Hartman, Simon Josefsson, Tim Alsop, 1255 and Tony Hansen. 1257 Appendix A. The SASL EXTERNAL Mechanism 1259 This appendix is normative. 1261 The EXTERNAL mechanism allows a client to request the server to use 1262 credentials established by means external to the mechanism to 1263 authenticate the client. The external means may be, for instance, IP 1264 Security [RFC2401] or TLS [RFC2246] services. In absence of some 1265 apriori agreement between the client and the server, the client cannot 1266 make any assumption as to what external means the server has used to 1267 obtain the client's credentials, nor make an assumption as to the form 1268 of credentials. For example, the client cannot assume the server will 1269 use the credentials the client has established via TLS. 1271 A.1. EXTERNAL Technical Specification 1273 The name of this mechanism is "EXTERNAL". 1275 The mechanism does not provide a security layer. 1277 The mechanism is capable of transferring an authorization identity 1278 string. If empty, the client is requesting to act as the identity the 1279 server has associated with the client's credentials. If non-empty, 1280 the client is requesting to act as the identity represented by the 1281 string. 1283 The client is expected to send data first in the authentication 1284 exchange. Where the client does not provide an initial response data 1285 in its request to initiate the authentication exchange, the server is 1286 to respond to the request with an empty initial challenge and then the 1287 client is to provide its initial response. 1289 The client sends the initial response containing the UTF-8 [RFC3629] 1290 encoding of the requested authorization identity string. This 1291 response is non-empty when the client is requesting to act as the 1292 identity represented by the (non-empty) string. This response is 1293 empty when the client is requesting to act as the identity the server 1294 associated with its authentication credentials. 1296 The syntax of the initial response is specified as a value of the 1297 production detailed below using the Augmented 1298 Backus-Naur Form (ABNF) [RFC4234] notation. 1300 external-initial-resp = authz-id-string 1301 authz-id-string = *( UTF8-char-no-nul ) 1302 UTF8-char-no-nul = UTF8-1-no-nul / UTF8-2 / UTF8-3 / UTF8-4 1303 UTF8-1-no-nul = %x01-7F 1305 where the , , and productions are as defined 1306 in [RFC3629]. 1308 There are no additional challenges and responses. 1310 Hence, the server is to return the outcome of the authentication 1311 exchange. 1313 The exchange fails if 1314 - the client has not established its credentials via external means, 1315 - the client's credentials are inadequate, 1316 - The client provided an empty authorization identity string and the 1317 server is unwilling or unable to associate an authorization identity 1318 with the client's credentials, 1319 - The client provided a non-empty authorization identity string which 1320 is invalid per the syntax requirements of the applicable application 1321 protocol specification, 1322 - The client provided a non-empty authorization identity string 1323 representing an identity which the client is not allowed to act as, 1324 or 1325 - the server is unwilling or unable to provide service to the client 1326 for any other reason. 1328 Otherwise the exchange is successful. When indicating a successful 1329 outcome, additional data is not provided. 1331 A.2. SASL EXTERNAL Examples 1333 This section provides examples of EXTERNAL authentication exchanges. 1334 The examples are intended to help the readers under the above text. 1335 The examples are not definitive. The Application Configuration 1336 Access Protocol (ACAP) [RFC2244] is used in the examples. 1338 The first example shows use of EXTERNAL with an empty authorization 1339 identity. In this example, the initial response is not sent in the 1340 client's request to initiate authentication exchange. 1342 S: * ACAP (SASL "DIGEST-MD5") 1343 C: a001 STARTTLS 1344 S: a001 OK "Begin TLS negotiation now" 1345 1346 S: * ACAP (SASL "DIGEST-MD5" "EXTERNAL") 1347 C: a002 AUTHENTICATE "EXTERNAL" 1348 S: + "" 1349 C: + "" 1350 S: a002 OK "Authenticated" 1352 In second example shows use of EXTERNAL with an authorization identity 1353 of "fred@example.com". In this example, the initial response is sent 1354 with the client's request to initiate the authentication exchange. 1355 This saves a round-trip. 1357 S: * ACAP (SASL "DIGEST-MD5") 1358 C: a001 STARTTLS 1359 S: a001 OK "Begin TLS negotiation now" 1360 1361 S: * ACAP (SASL "DIGEST-MD5" "EXTERNAL") 1362 C: a002 AUTHENTICATE "EXTERNAL" {16+} 1363 C: fred@example.com 1364 S: a002 NO "Cannot assume requested authorization identity" 1366 A.3. Security Considerations 1368 The EXTERNAL mechanism provides no security protection; it is 1369 vulnerable to spoofing by either client or server, active attack, and 1370 eavesdropping. It should only be used when adequate security services 1371 have been established. 1373 Appendix B. Changes since RFC 2222 1375 This appendix is non-normative. 1377 The material in RFC 2222 was significantly rewritten in the production 1378 of this document. 1380 RFC 2222, by not stating the authorization identity string was a 1381 string of Unicode characters, let alone character data, implied the 1382 authorization identity string was a string of octets. 1384 - The authorization identity string is now defined as a string of 1385 Unicode characters. The NUL (U+0000) character is prohibited. 1386 While protocol specifications are responsible for defining the 1387 authorization identity form, as well as the Unicode string syntax 1388 and related semantics, mechanism specifications are responsible for 1389 defining how the Unicode string is carried in the authentication 1390 exchange. 1391 - Deleted "If so, when the client does not send data first, the 1392 initial challenge MUST be specified as being an empty challenge." 1394 The following technical change was made to the EXTERNAL mechanism: 1396 - The authorization identity string is to be UTF-8 encoded. 1398 It is noted that protocol and mechanism specification requirements 1399 have been significant tightened. Existing protocol and mechanism 1400 specifications will need to be updated to meet these requirements. 1402 Intellectual Property Rights 1404 The IETF takes no position regarding the validity or scope of any 1405 Intellectual Property Rights or other rights that might be claimed to 1406 pertain to the implementation or use of the technology described in 1407 this document or the extent to which any license under such rights 1408 might or might not be available; nor does it represent that it has 1409 made any independent effort to identify any such rights. Information 1410 on the procedures with respect to rights in RFC documents can be found 1411 in BCP 78 and BCP 79. 1413 Copies of IPR disclosures made to the IETF Secretariat and any 1414 assurances of licenses to be made available, or the result of an 1415 attempt made to obtain a general license or permission for the use of 1416 such proprietary rights by implementers or users of this specification 1417 can be obtained from the IETF on-line IPR repository at 1418 http://www.ietf.org/ipr. 1420 The IETF invites any interested party to bring to its attention any 1421 copyrights, patents or patent applications, or other proprietary 1422 rights that may cover technology that may be required to implement 1423 this standard. Please address the information to the IETF at 1424 ietf-ipr@ietf.org. 1426 Full Copyright 1428 Copyright (C) The Internet Society (2005). 1430 This document is subject to the rights, licenses and restrictions 1431 contained in BCP 78, and except as set forth therein, the authors 1432 retain all their rights. 1434 This document and the information contained herein are provided on an 1435 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1436 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 1437 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 1438 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 1439 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1440 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.