idnits 2.17.1 draft-ietf-sasl-4422bis-00.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 23. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 1448. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1419. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1426. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1432. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust 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 (31 August 2008) is 5710 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: 'DIGEST-MD5' is mentioned on line 759, but not defined == Missing Reference: 'CRAM-MD5' is mentioned on line 762, but not defined ** Obsolete normative reference: RFC 4013 (Obsoleted by RFC 7613) ** Obsolete normative reference: RFC 5226 (Obsoleted by RFC 8126) -- Possible downref: Non-RFC (?) normative reference: ref. 'ASCII' -- Possible downref: Non-RFC (?) normative reference: ref. 'Unicode' -- Possible downref: Non-RFC (?) normative reference: ref. 'CharModel' -- Obsolete informational reference (is this intentional?): RFC 3454 (Obsoleted by RFC 7564) -- Obsolete informational reference (is this intentional?): RFC 5246 (Obsoleted by RFC 8446) Summary: 3 errors (**), 0 flaws (~~), 4 warnings (==), 12 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 Obsoletes: 4422 (if approved) K. Zeilenga, Ed. 5 Category: Standards Track Isode Limited 6 Expires in six months 31 August 2008 8 Simple Authentication and Security Layer (SASL) 9 11 Status of This Memo 13 This document is intended to be, after appropriate review and 14 revision, submitted to the RFC Editor as a Standards Track document. 15 Distribution of this memo is unlimited. Technical discussion of this 16 document will take place on the IETF SASL WG mailing list 17 . Please send editorial comments directly to the 18 editor. 20 By submitting this Internet-Draft, each author represents that any 21 applicable patent or other IPR claims of which he or she is aware 22 have been or will be disclosed, and any of which he or she becomes 23 aware will be disclosed, in accordance with Section 6 of BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF), its areas, and its working groups. Note that other 27 groups may also distribute working documents as Internet-Drafts. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 The list of current Internet-Drafts can be accessed at 35 http://www.ietf.org/1id-abstracts.html. 37 The list of Internet-Draft Shadow Directories can be accessed at 38 http://www.ietf.org/shadow.html. 40 Copyright (C) The IETF Trust (2008). 42 Please see the Full Copyright section near the end of this document 43 for more information. 45 Abstract 47 The Simple Authentication and Security Layer (SASL) is a framework 48 for providing authentication and data security services in 49 connection-oriented protocols via replaceable mechanisms. It 50 provides a structured interface between protocols and mechanisms. 51 The resulting framework allows new protocols to reuse existing 52 mechanisms and allows old protocols to make use of new mechanisms. 53 The framework also provides a protocol for securing subsequent 54 protocol exchanges within a data security layer. 56 This document describes how a SASL mechanism is structured, describes 57 how protocols include support for SASL, and defines the protocol for 58 carrying a data security layer over a connection. In addition, this 59 document defines one SASL mechanism, the EXTERNAL mechanism. 61 This document obsoletes RFC 4422 [[when approved]]. 63 Table of Contents 65 [[Page numbers to be added by RFC-Editor]] 67 1. Introduction ................................................... 68 1.1. Document Audiences ........................................ 69 1.2. Relationship to Other Documents ........................... 70 1.3. Conventions ............................................... 71 2. Identity Concepts .............................................. 72 3. The Authentication Exchange .................................... 73 3.1. Mechanism Naming .......................................... 74 3.2. Mechanism Negotiation ..................................... 75 3.3. Request Authentication Exchange ........................... 76 3.4. Challenges and Responses .................................. 77 3.4.1. Authorization Identity String ...................... 78 3.5. Aborting Authentication Exchanges ......................... 79 3.6. Authentication Outcome .................................... 80 3.7. Security Layers ........................................... 81 3.8. Multiple Authentications .................................. 82 4. Protocol Requirements .......................................... 83 5. Mechanism Requirements ......................................... 84 6. Security Considerations ........................................ 85 6.1. Active Attacks ............................................ 86 6.1.1. Hijack Attacks ..................................... 87 6.1.2. Downgrade Attacks .................................. 88 6.1.3. Replay Attacks ..................................... 89 6.1.4. Truncation Attacks ................................. 90 6.1.5. Other Active Attacks ............................... 91 6.2. Passive Attacks ........................................... 92 6.3. Re-keying ................................................. 93 6.4. Other Considerations ...................................... 94 7. IANA Considerations ............................................ 95 7.1. SASL Mechanism Registry ................................... 96 7.2. Registration Changes ...................................... 97 8. References ..................................................... 98 8.1. Normative References ...................................... 99 8.2. Informative References .................................... 100 9. Acknowledgements ............................................... 101 Appendix A. The SASL EXTERNAL Mechanism .......................... 102 A.1. EXTERNAL Technical Specification .......................... 103 A.2. SASL EXTERNAL Examples .................................... 104 A.3. Security Considerations ................................... 105 Appendix B. Changes since RFC 4422 ............................... 107 1. Introduction 109 The Simple Authentication and Security Layer (SASL) is a framework 110 for providing authentication and data security services in 111 connection-oriented protocols via replaceable mechanisms. SASL 112 provides a structured interface between protocols and mechanisms. 113 SASL also provides a protocol for securing subsequent protocol 114 exchanges within a data security layer. The data security layer can 115 provide data integrity, data confidentiality, and other services. 117 SASL's design is intended to allow new protocols to reuse existing 118 mechanisms without requiring redesign of the mechanisms and allows 119 existing protocols to make use of new mechanisms without redesign of 120 protocols. 122 SASL is conceptually a framework that provides an abstraction layer 123 between protocols and mechanisms as illustrated in the following 124 diagram. 126 SMTP LDAP XMPP Other protocols ... 127 \ | | / 128 \ | | / 129 SASL abstraction layer 130 / | | \ 131 / | | \ 132 EXTERNAL GSSAPI PLAIN Other mechanisms ... 134 It is through the interfaces of this abstraction layer that the 135 framework allows any protocol to utilize any mechanism. While this 136 layer does generally hide the particulars of protocols from 137 mechanisms and the particulars of mechanisms from protocols, this 138 layer does not generally hide the particulars of mechanisms from 139 protocol implementations. For example, different mechanisms require 140 different information to operate, some of them use password-based 141 authentication, some of then require realm information, others make 142 use of Kerberos tickets, certificates, etc. Also, in order to 143 perform authorization, server implementations generally have to 144 implement identity mapping between authentication identities, whose 145 form is mechanism specific, and authorization identities, whose form 146 is application protocol specific. Section 2 discusses identity 147 concepts. 149 It is possible to design and implement this framework in ways that do 150 abstract away particulars of similar mechanisms. Such a framework 151 implementation, as well as mechanisms implementations, could be 152 designed not only to be shared by multiple implementations of a 153 particular protocol but to be shared by implementations of multiple 154 protocols. 156 The framework incorporates interfaces with both protocols and 157 mechanisms in which authentication exchanges are carried out. 158 Section 3 discusses SASL authentication exchanges. 160 To use SASL, each protocol (amongst other items) provides a method 161 for identifying which mechanism is to be used, a method for exchange 162 of mechanism-specific server-challenges and client-responses, and a 163 method for communicating the outcome of the authentication exchange. 164 Section 4 discusses SASL protocol requirements. 166 Each SASL mechanism defines (amongst other items) a series of 167 server-challenges and client-responses that provide authentication 168 services and negotiate data security services. Section 5 discusses 169 SASL mechanism requirements. 171 Section 6 discusses security considerations. Section 7 discusses 172 IANA considerations. Appendix A defines the SASL EXTERNAL mechanism. 174 1.1. Document Audiences 176 This document is written to serve several different audiences: 178 - protocol designers using this specification to support 179 authentication in their protocol, 181 - mechanism designers that define new SASL mechanisms, and 183 - implementors of clients or servers for those protocols that 184 support SASL. 186 While the document organization is intended to allow readers to focus 187 on details relevant to their engineering, readers are encouraged to 188 read and understand all aspects of this document. 190 1.2. Relationship to Other Documents 192 This document obsoletes RFC 4422. It replaces RFC 4422 in its 193 entirety. Appendix B provides a summary of changes since RFC 4422. 195 1.3. Conventions 197 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 198 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 199 document are to be interpreted as described in BCP 14 [RFC2119]. 201 Character names in this document use the notation for code points and 202 names from the Unicode Standard [Unicode]. For example, the letter 203 "a" may be represented as either or . 205 Note: a glossary of terms used in Unicode can be found in [Glossary]. 206 Information on the Unicode character encoding model can be found in 207 [CharModel]. 209 In examples, "C:" and "S:" indicate lines of data to be sent by the 210 client and server, respectively. Lines have been wrapped for 211 improved readability. 213 2. Identity Concepts 215 In practice, authentication and authorization may involve multiple 216 identities, possibly in different forms (simple username, Kerberos 217 principal, X.500 Distinguished Name, etc.), possibly with different 218 representations (e.g., ABNF-described UTF-8 encoded Unicode character 219 string, BER-encoded Distinguished Name). While technical 220 specifications often prescribe both the identity form and 221 representation used on the network, different identity forms and/or 222 representations may be (and often are) used within implementations. 223 How identities of different forms relate to each other is, generally, 224 a local matter. In addition, the forms and representations used 225 within an implementation are a local matter. 227 However, conceptually, the SASL framework involves two identities: 229 1) an identity associated with the authentication credentials 230 (termed the authentication identity), and 232 2) an identity to act as (termed the authorization identity). 234 SASL mechanism specifications describe the credential form(s) (e.g., 235 X.509 certificates, Kerberos tickets, simple username/password) used 236 to authenticate the client, including (where appropriate) the syntax 237 and semantics of authentication identities carried in the 238 credentials. SASL protocol specifications describe the identity 239 form(s) used in authorization and, in particular, prescribe the 240 syntax and semantics of the authorization identity character string 241 to be transferred by mechanisms. 243 The client provides its credentials (which include or imply an 244 authentication identity) and, optionally, a character string 245 representing the requested authorization identity as part of the SASL 246 exchange. When this character string is omitted or empty, the client 247 is requesting to act as the identity associated with the credentials 248 (e.g., the user is requesting to act as the authentication identity). 250 The server is responsible for verifying the client's credentials and 251 verifying that the identity it associates with the client's 252 credentials (e.g., the authentication identity) is allowed to act as 253 the authorization identity. A SASL exchange fails if either (or 254 both) of these verifications fails. (The SASL exchange may fail for 255 other reasons, such as service authorization failure.) 257 However, the precise form(s) of the authentication identities (used 258 within the server in its verifications, or otherwise) and the precise 259 form(s) of the authorization identities (used in making authorization 260 decisions, or otherwise) are beyond the scope of SASL and this 261 specification. In some circumstances, the precise identity forms 262 used in some context outside of the SASL exchange may be dictated by 263 other specifications. For instance, an identity assumption 264 authorization (proxy authorization) policy specification may dictate 265 how authentication and authorization identities are represented in 266 policy statements. 268 3. The Authentication Exchange 270 Each authentication exchange consists of a message from the client to 271 the server requesting authentication via a particular mechanism, 272 followed by one or more pairs of challenges from the server and 273 responses from the client, followed by a message from the server 274 indicating the outcome of the authentication exchange. (Note: 275 exchanges may also be aborted as discussed in Section 3.5.) 277 The following illustration provides a high-level overview of an 278 authentication exchange. 280 C: Request authentication exchange 281 S: Initial challenge 282 C: Initial response 283 284 S: Outcome of authentication exchange 286 If the outcome is successful and a security layer was negotiated, 287 this layer is then installed (see Section 3.7). This also applies to 288 the following illustrations. 290 Some mechanisms specify that the first data sent in the 291 authentication exchange is from the client to the server. Protocols 292 may provide an optional initial response field in the request message 293 to carry this data. Where the mechanism specifies that the first 294 data sent in the exchange is from the client to the server, the 295 protocol provides an optional initial response field, and the client 296 uses this field, the exchange is shortened by one round-trip: 298 C: Request authentication exchange + Initial response 299 300 S: Outcome of authentication exchange 302 Where the mechanism specifies that the first data sent in the 303 exchange is from the client to the server and this field is 304 unavailable or unused, the client request is followed by an empty 305 challenge. 307 C: Request authentication exchange 308 S: Empty Challenge 309 C: Initial Response 310 311 S: Outcome of authentication exchange 313 Should a client include an initial response in its request where the 314 mechanism does not allow the client to send data first, the 315 authentication exchange fails. 317 Some mechanisms specify that the server is to send additional data to 318 the client when indicating a successful outcome. Protocols may 319 provide an optional additional data field in the outcome message to 320 carry this data. Where the mechanism specifies that the server is to 321 return additional data with the successful outcome, the protocol 322 provides an optional additional data field in the outcome message, 323 and the server uses this field, the exchange is shortened by one 324 round-trip: 326 C: Request authentication exchange 327 S: Initial challenge 328 C: Initial response 329 330 S: Outcome of authentication exchange with 331 additional data with success 333 Where the mechanism specifies that the server is to return additional 334 data to the client with a successful outcome and this field is 335 unavailable or unused, the additional data is sent as a challenge 336 whose response is empty. After receiving this response, the server 337 then indicates the successful outcome. 339 C: Request authentication exchange 340 S: Initial challenge 341 C: Initial response 342 343 S: Additional data challenge 344 C: Empty Response 345 S: Outcome of authentication exchange 347 Where mechanisms specify that the first data sent in the exchange is 348 from the client to the server and additional data is sent to the 349 client along with indicating a successful outcome, and the protocol 350 provides fields supporting both, then the exchange takes two fewer 351 round-trips: 353 C: Request authentication exchange + Initial response 354 355 S: Outcome of authentication exchange 356 with additional data with success 358 instead of: 360 C: Request authentication exchange 361 S: Empty Challenge 362 C: Initial Response 363 364 S: Additional data challenge 365 C: Empty Response 366 S: Outcome of authentication exchange 368 3.1. Mechanism Naming 370 SASL mechanisms are named by character strings, from 1 to 20 371 characters in length, consisting of ASCII [ASCII] uppercase letters, 372 digits, hyphens, and/or underscores. In the following Augmented 373 Backus-Naur Form (ABNF) [RFC5234] grammar, the production 374 defines the syntax of a SASL mechanism name. 376 sasl-mech = 1*20mech-char 377 mech-char = UPPER-ALPHA / DIGIT / HYPHEN / UNDERSCORE 378 ; mech-char is restricted to A-Z (uppercase only), 0-9, -, and _ 379 ; from ASCII character set. 381 UPPER-ALPHA = %x41-5A ; A-Z (uppercase only) 382 DIGIT = %x30-39 ; 0-9 383 HYPHEN = %x2D ; hyphen (-) 384 UNDERSCORE = %x5F ; underscore (_) 386 SASL mechanism names are registered as discussed in Section 7.1. 388 3.2. Mechanism Negotiation 389 Mechanism negotiation is protocol specific. 391 Commonly, a protocol will specify that the server advertises 392 supported and available mechanisms to the client via some facility 393 provided by the protocol, and the client will then select the "best" 394 mechanism from this list that it supports and finds suitable. 396 Note that the mechanism negotiation is not protected by the 397 subsequent authentication exchange and hence is subject to downgrade 398 attacks if not protected by other means. 400 To detect downgrade attacks, a protocol can allow the client to 401 discover available mechanisms subsequent to the authentication 402 exchange and installation of data security layers with at least data 403 integrity protection. This allows the client to detect changes to 404 the list of mechanisms supported by the server. 406 3.3. Request Authentication Exchange 408 The authentication exchange is initiated by the client by requesting 409 authentication via a mechanism it specifies. The client sends a 410 message that contains the name of the mechanism to the server. The 411 particulars of the message are protocol specific. 413 Note that the name of the mechanism is not protected by the 414 mechanism, and hence is subject to alteration by an attacker if not 415 integrity protected by other means. 417 Where the mechanism is defined to allow the client to send data 418 first, and the protocol's request message includes an optional 419 initial response field, the client may include the response to the 420 initial challenge in the authentication request message. 422 3.4. Challenges and Responses 424 The authentication exchange involves one or more pairs of 425 server-challenges and client-responses, the particulars of which are 426 mechanism specific. These challenges and responses are enclosed in 427 protocol messages, the particulars of which are protocol specific. 429 Through these challenges and responses, the mechanism may: 431 - authenticate the client to the server, 433 - authenticate the server to the client, 434 - transfer an authorization identity string, 436 - negotiate a security layer, and 438 - provide other services. 440 The negotiation of the security layer may involve negotiation of the 441 security services to be provided in the layer, how these services 442 will be provided, and negotiation of a maximum cipher-text buffer 443 size each side is able to receive in the layer (see Section 3.6). 445 After receiving an authentication request or any client response, the 446 server may issue a challenge, abort the exchange, or indicate the 447 outcome of an exchange. After receiving a challenge, a client 448 mechanism may issue a response or abort the exchange. 450 3.4.1. Authorization Identity String 452 The authorization identity string is a sequence of zero or more 453 Unicode [Unicode] characters, excluding the NUL (U+0000) character, 454 representing the identity to act as. 456 If the authorization identity string is absent, the client is 457 requesting to act as the identity the server associates with the 458 client's credentials. An empty string is equivalent to an absent 459 authorization identity. 461 A non-empty authorization identity string indicates that the client 462 wishes to act as the identity represented by the string. In this 463 case, the form of identity represented by the string, as well as the 464 precise syntax and semantics of the string, is protocol specific. 466 While the character encoding schema used to transfer the 467 authorization identity string in the authentication exchange is 468 mechanism specific, mechanisms are expected to be capable of carrying 469 the entire Unicode repertoire (with the exception of the NUL 470 character). 472 3.5. Aborting Authentication Exchanges 474 A client or server may desire to abort an authentication exchange if 475 it is unwilling or unable to continue (or enter into). 477 A client may abort the authentication exchange by sending a message, 478 the particulars of which are protocol specific, to the server, 479 indicating that the exchange is aborted. The server may be required 480 by the protocol to return a message in response to the client's abort 481 message. 483 Likewise, a server may abort the authentication exchange by sending a 484 message, the particulars of which are protocol specific, to the 485 client, indicating that the exchange is aborted. 487 3.6. Authentication Outcome 489 At the conclusion of the authentication exchange, the server sends a 490 message, the particulars of which are protocol specific, to the 491 client indicating the outcome of the exchange. 493 The outcome is not successful if 495 - the authentication exchange failed for any reason, 497 - the client's credentials could not be verified, 499 - the server cannot associate an identity with the client's 500 credentials, 502 - the client-provided authorization identity string is malformed, 504 - the identity associated with the client's credentials is not 505 authorized to act as the requested authorization identity, 507 - the negotiated security layer (or lack thereof) is not suitable, 508 or 510 - the server is not willing to provide service to the client for 511 any reason. 513 The protocol may include an optional additional data field in this 514 outcome message. This field can only include additional data when 515 the outcome is successful. 517 If the outcome is successful and a security layer was negotiated, 518 this layer is then installed. If the outcome is unsuccessful, or a 519 security layer was not negotiated, any existing security is left in 520 place. 522 The outcome message provided by the server can provide a way for the 523 client to distinguish between errors that are best dealt with by 524 re-prompting the user for her credentials, errors that are best dealt 525 with by telling the user to try again later, and errors where the 526 user must contact a system administrator for resolution (see the SYS 527 and AUTH POP Response Codes [RFC3206] specification for an example). 528 This distinction is particularly useful during scheduled server 529 maintenance periods as it reduces support costs. It is also 530 important that the server can be configured such that the outcome 531 message will not distinguish between a valid user with invalid 532 credentials and an invalid user. 534 3.7. Security Layers 536 SASL mechanisms may offer a wide range of services in security 537 layers. Typical services include data integrity and data 538 confidentiality. SASL mechanisms that do not provide a security 539 layer are treated as negotiating no security layer. 541 If use of a security layer is negotiated in the authentication 542 protocol exchange, the layer is installed by the server after 543 indicating the outcome of the authentication exchange and installed 544 by the client upon receipt of the outcome indication. In both cases, 545 the layer is installed before transfer of further protocol data. The 546 precise position upon which the layer takes effect in the protocol 547 data stream is protocol specific. 549 Once the security layer is in effect in the protocol data stream, it 550 remains in effect until either a subsequently negotiated security 551 layer is installed or the underlying transport connection is closed. 553 When in effect, the security layer processes protocol data into 554 buffers of protected data. If at any time the security layer is 555 unable or unwilling to continue producing buffers protecting protocol 556 data, the underlying transport connection MUST be closed. If the 557 security layer is not able to decode a received buffer, the 558 underlying connection MUST be closed. In both cases, the underlying 559 transport connection SHOULD be closed gracefully. 561 Each buffer of protected data is transferred over the underlying 562 transport connection as a sequence of octets prepended with a 563 four-octet field in network byte order that represents the length of 564 the buffer. The length of the protected data buffer MUST be no 565 larger than the maximum size that the other side expects. Upon the 566 receipt of a length field whose value is greater than the maximum 567 size, the receiver SHOULD close the connection, as this might be a 568 sign of an attack. 570 The maximum size that each side expects is fixed by the mechanism, 571 either through negotiation or by its specification. 573 3.8. Multiple Authentications 574 Unless explicitly permitted in the protocol (as stated in the 575 protocol's technical specification), only one successful SASL 576 authentication exchange may occur in a protocol session. In this 577 case, once an authentication exchange has successfully completed, 578 further attempts to initiate an authentication exchange fail. 580 Where multiple successful SASL authentication exchanges are permitted 581 in the protocol, then in no case may multiple SASL security layers be 582 simultaneously in effect. If a security layer is in effect and a 583 subsequent SASL negotiation selects a second security layer, then the 584 second security layer replaces the first. If a security layer is in 585 effect and a subsequent SASL negotiation selects no security layer, 586 the original security layer remains in effect. 588 Where multiple successful SASL negotiations are permitted in the 589 protocol, the effect of a failed SASL authentication exchange upon 590 the previously established authentication and authorization state is 591 protocol specific. The protocol's technical specification should be 592 consulted to determine whether the previous authentication and 593 authorization state remains in force, or changed to an anonymous 594 state, or otherwise was affected. Regardless of the 595 protocol-specific effect upon previously established authentication 596 and authorization state, the previously negotiated security layer 597 remains in effect. 599 4. Protocol Requirements 601 In order for a protocol to offer SASL services, its specification 602 MUST supply the following information: 604 1) A service name, to be selected from registry of "service" elements 605 for the Generic Security Service Application Program Interface 606 (GSSAPI) host-based service name form, as described in Section 4.1 607 of [RFC2743]. Note that this registry is shared by all GSSAPI and 608 SASL mechanisms. 610 2) Detail any mechanism negotiation facility that the protocol 611 provides (see Section 3.2). 613 A protocol SHOULD specify a facility through which the client may 614 discover, both before initiation of the SASL exchange and after 615 installing security layers negotiated by the exchange, the names 616 of the SASL mechanisms that the server makes available to the 617 client. The latter is important to allow the client to detect 618 downgrade attacks. This facility is typically provided through 619 the protocol's extensions or capabilities discovery facility. 621 3) Definition of the messages necessary for authentication exchange, 622 including the following: 624 a) A message to initiate the authentication exchange (see Section 625 3.3). 627 This message MUST contain a field for carrying the name of the 628 mechanism selected by the client. 630 This message SHOULD contain an optional field for carrying an 631 initial response. If the message is defined with this field, 632 the specification MUST describe how messages with an empty 633 initial response are distinguished from messages with no 634 initial response. This field MUST be capable of carrying 635 arbitrary sequences of octets (including zero-length sequences 636 and sequences containing zero-valued octets). 638 b) Messages to transfer server challenges and client responses 639 (see Section 3.4). 641 Each of these messages MUST be capable of carrying arbitrary 642 sequences of octets (including zero-length sequences and 643 sequences containing zero-valued octets). 645 c) A message to indicate the outcome of the authentication 646 exchange (see Section 3.6). 648 This message SHOULD contain an optional field for carrying 649 additional data with a successful outcome. If the message is 650 defined with this field, the specification MUST describe how 651 messages with an empty additional data are distinguished from 652 messages with no additional data. This field MUST be capable 653 of carrying arbitrary sequences of octets (including 654 zero-length sequences and sequences containing zero-valued 655 octets). 657 4) Prescribe the syntax and semantics of non-empty authorization 658 identity strings (see Section 3.4.1). 660 In order to avoid interoperability problems due to differing 661 normalizations, the protocol specification MUST detail precisely 662 how and where (client or server) non-empty authorization identity 663 strings are prepared, including all normalizations, for comparison 664 and other applicable functions to ensure proper function. 666 Specifications are encouraged to prescribe use of existing 667 authorization identity forms as well as existing string 668 representations, such as simple user names [RFC4013]. 670 Where the specification does not precisely prescribe how 671 identities in SASL relate to identities used elsewhere in the 672 protocol, for instance, in access control policy statements, it 673 may be appropriate for the protocol to provide a facility by which 674 the client can discover information (such as the representation of 675 the identity used in making access control decisions) about 676 established identities for these uses. 678 5) Detail any facility the protocol provides that allows the client 679 and/or server to abort authentication exchange (see Section 3.5). 681 Protocols that support multiple authentications typically allow a 682 client to abort an ongoing authentication exchange by initiating a 683 new authentication exchange. Protocols that do not support 684 multiple authentications may require the client to close the 685 connection and start over to abort an ongoing authentication 686 exchange. 688 Protocols typically allow the server to abort ongoing 689 authentication exchanges by returning a non-successful outcome 690 message. 692 6) Identify precisely where newly negotiated security layers start to 693 take effect, in both directions (see Section 3.7). 695 Typically, specifications require security layers to start taking 696 effect on the first octet following the outcome message in data 697 being sent by the server and on the first octet sent after receipt 698 of the outcome message in data being sent by the client. 700 7) If the protocol supports other layered security services, such as 701 Transport Layer Security (TLS) [RFC5246], the specification MUST 702 prescribe the order in which security layers are applied to 703 protocol data. 705 For instance, where a protocol supports both TLS and SASL security 706 layers, the specification could prescribe any of the following: 708 a) SASL security layer is always applied first to data being sent 709 and, hence, applied last to received data, 711 b) SASL security layer is always applied last to data being sent 712 and, hence, applied first to received data, 714 c) Layers are applied in the order in which they were installed, 716 d) Layers are applied in the reverse order in which they were 717 installed, or 719 e) Both TLS and SASL security layers cannot be installed. 721 8) Indicate whether the protocol supports multiple authentications 722 (see Section 3.8). If so, the protocol MUST detail the effect a 723 failed SASL authentication exchange will have upon a previously 724 established authentication and authorization state. 726 Protocol specifications SHOULD avoid stating implementation 727 requirements that would hinder replacement of applicable mechanisms. 728 In general, protocol specifications SHOULD be mechanism neutral. 729 There are a number of reasonable exceptions to this recommendation, 730 including 732 - detailing how credentials (which are mechanism specific) are 733 managed in the protocol, 735 - detailing how authentication identities (which are mechanism 736 specific) and authorization identities (which are protocol 737 specific) relate to each other, and 739 - detailing which mechanisms are applicable to the protocol. 741 5. Mechanism Requirements 743 SASL mechanism specifications MUST supply the following information: 745 1) The name of the mechanism (see Section 3.1). This name MUST be 746 registered as discussed in Section 7.1. 748 2) A definition of the server-challenges and client-responses of the 749 authentication exchange, as well as the following: 751 a) An indication of whether the mechanism is client-first, 752 variable, or server-first. If a SASL mechanism is defined as 753 client-first and the client does not send an initial response 754 in the authentication request, then the first server challenge 755 MUST be empty (the EXTERNAL mechanism is an example of this 756 case). If a SASL mechanism is defined as variable, then the 757 specification needs to state how the server behaves when the 758 initial client response in the authentication request is 759 omitted (the DIGEST-MD5 mechanism [DIGEST-MD5] is an example of 760 this case). If a SASL mechanism is defined as server-first, 761 then the client MUST NOT send an initial client response in the 762 authentication request (the CRAM-MD5 mechanism [CRAM-MD5] is an 763 example of this case). 765 b) An indication of whether the server is expected to provide 766 additional data when indicating a successful outcome. If so, 767 if the server sends the additional data as a challenge, the 768 specification MUST indicate that the response to this challenge 769 is an empty response. 771 SASL mechanisms SHOULD be designed to minimize the number of 772 challenges and responses necessary to complete the exchange. 774 3) An indication of whether the mechanism is capable of transferring 775 authorization identity strings (see Section 3.4.1). While some 776 legacy mechanisms are incapable of transmitting an authorization 777 identity (which means that for these mechanisms, the authorization 778 identity is always the empty string), newly defined mechanisms 779 SHOULD be capable of transferring authorization identity strings. 780 The mechanism SHOULD NOT be capable of transferring both no 781 authorization identity string and an empty authorization identity. 783 Mechanisms that are capable of transferring an authorization 784 identity string MUST be capable of transferring arbitrary 785 non-empty sequences of Unicode characters, excluding those that 786 contain the NUL (U+0000) character. Mechanisms SHOULD use the 787 UTF-8 [RFC3629] transformation format. The specification MUST 788 detail how any Unicode code points special to the mechanism that 789 might appear in the authorization identity string are escaped to 790 avoid ambiguity during decoding of the authorization identity 791 string. Typically, mechanisms that have special characters 792 require these special characters to be escaped or encoded in the 793 character string (after encoding it in a particular Unicode 794 transformation format) using a data encoding scheme such as Base64 795 [RFC4648]. 797 4) The specification MUST detail whether the mechanism offers a 798 security layer. If the mechanism does, the specification MUST 799 detail the security and other services offered in the layer as 800 well as how these services are to be implemented. 802 5) If the underlying cryptographic technology used by a mechanism 803 supports data integrity, then the mechanism specification MUST 804 integrity protect the transmission of an authorization identity 805 and the negotiation of the security layer. 807 SASL mechanisms SHOULD be protocol neutral. 809 SASL mechanisms SHOULD reuse existing credential and identity forms, 810 as well as associated syntaxes and semantics. 812 SASL mechanisms SHOULD use the UTF-8 transformation format [RFC3629] 813 for encoding Unicode [Unicode] code points for transfer. 815 In order to avoid interoperability problems due to differing 816 normalizations, when a mechanism calls for character data (other than 817 the authorization identity string) to be used as input to a 818 cryptographic and/or comparison function, the specification MUST 819 detail precisely how and where (client or server) the character data 820 is to be prepared, including all normalizations, for input into the 821 function to ensure proper operation. 823 For simple user names and/or passwords in authentication credentials, 824 SASLprep [RFC4013] (a profile of the StringPrep [RFC3454] preparation 825 algorithm), SHOULD be specified as the preparation algorithm. 827 The mechanism SHOULD NOT use the authorization identity string in 828 generation of any long-term cryptographic keys or hashes as there is 829 no requirement that the authorization identity string be canonical. 830 Long-term, here, means a term longer than the duration of the 831 authentication exchange in which they were generated. That is, as 832 different clients (of the same or different protocol) may provide 833 different authorization identity strings that are semantically 834 equivalent, use of authorization identity strings in generation of 835 cryptographic keys and hashes will likely lead to interoperability 836 and other problems. 838 6. Security Considerations 840 Security issues are discussed throughout this memo. 842 Many existing SASL mechanisms do not provide adequate protection 843 against passive attacks, let alone active attacks, in the 844 authentication exchange. Many existing SASL mechanisms do not offer 845 security layers. It is hoped that future SASL mechanisms will 846 provide strong protection against passive and active attacks in the 847 authentication exchange, as well as security layers with strong basic 848 data security features (e.g., data integrity and data 849 confidentiality) services. It is also hoped that future mechanisms 850 will provide more advanced data security services like re-keying (see 851 Section 6.3). 853 Regardless, the SASL framework is susceptible to downgrade attacks. 854 Section 6.1.2 offers a variety of approaches for preventing or 855 detecting these attacks. In some cases, it is appropriate to use 856 data integrity protective services external to SASL (e.g., TLS) to 857 protect against downgrade attacks in SASL. Use of external 858 protective security services is also important when the mechanisms 859 available do not themselves offer adequate integrity and/or 860 confidentiality protection of the authentication exchange and/or 861 protocol data. 863 6.1. Active Attacks 865 6.1.1. Hijack Attacks 867 When the client selects a SASL security layer with at least integrity 868 protection, this protection serves as a counter-measure against an 869 active attacker hijacking the connection and modifying protocol data 870 sent after establishment of the security layer. Implementations 871 SHOULD close the connection when the security services in a SASL 872 security layer report protocol data report lack of data integrity. 874 6.1.2. Downgrade Attacks 876 It is important that any security-sensitive protocol negotiations be 877 performed after installation of a security layer with data integrity 878 protection. Protocols should be designed such that negotiations 879 performed prior to this installation should be revalidated after 880 installation is complete. Negotiation of the SASL mechanism is 881 security sensitive. 883 When a client negotiates the authentication mechanism with the server 884 and/or other security features, it is possible for an active attacker 885 to cause a party to use the least secure security services available. 886 For instance, an attacker can modify the server-advertised mechanism 887 list or can modify the client-advertised security feature list within 888 a mechanism response. To protect against this sort of attack, 889 implementations SHOULD NOT advertise mechanisms and/or features that 890 cannot meet their minimum security requirements, SHOULD NOT enter 891 into or continue authentication exchanges that cannot meet their 892 minimum security requirements, and SHOULD verify that completed 893 authentication exchanges result in security services that meet their 894 minimum security requirements. Note that each endpoint needs to 895 independently verify that its security requirements are met. 897 In order to detect downgrade attacks to the least (or less) secure 898 mechanism supported, the client can discover the SASL mechanisms that 899 the server makes available both before the SASL authentication 900 exchange and after the negotiated SASL security layer (with at least 901 data integrity protection) has been installed through the protocol's 902 mechanism discovery facility. If the client finds that the 903 integrity-protected list (the list obtained after the security layer 904 was installed) contains a stronger mechanism than those in the 905 previously obtained list, the client should assume that the 906 previously obtained list was modified by an attacker and SHOULD close 907 the underlying transport connection. 909 The client's initiation of the SASL exchange, including the selection 910 of a SASL mechanism, is done in the clear and may be modified by an 911 active attacker. It is important for any new SASL mechanisms to be 912 designed such that an active attacker cannot obtain an authentication 913 with weaker security properties by modifying the SASL mechanism name 914 and/or the challenges and responses. 916 Multi-level negotiation of security features is prone to downgrade 917 attack. Protocol designers should avoid offering higher-level 918 negotiation of security features in protocols (e.g., above SASL 919 mechanism negotiation) and mechanism designers should avoid 920 lower-level negotiation of security features in mechanisms (e.g., 921 below SASL mechanism negotiation). 923 6.1.3. Replay Attacks 925 Some mechanisms may be subject to replay attacks unless protected by 926 external data security services (e.g., TLS). 928 6.1.4. Truncation Attacks 930 Most existing SASL security layers do not themselves offer protection 931 against truncation attack. In a truncation attack, the active 932 attacker causes the protocol session to be closed, causing a 933 truncation of the possibly integrity-protected data stream that leads 934 to behavior of one or both the protocol peers that inappropriately 935 benefits the attacker. Truncation attacks are fairly easy to defend 936 against in connection-oriented application-level protocols. A 937 protocol can defend against these attacks by ensuring that each 938 information exchange has a clear final result and that each protocol 939 session has a graceful closure mechanism, and that these are 940 integrity protected. 942 6.1.5. Other Active Attacks 944 When use of a security layer is negotiated by the authentication 945 protocol exchange, the receiver SHOULD handle gracefully any 946 protected data buffer larger than the defined/negotiated maximal 947 size. In particular, it MUST NOT blindly allocate the amount of 948 memory specified in the buffer size field, as this might cause the 949 "out of memory" condition. If the receiver detects a large block, it 950 SHOULD close the connection. 952 6.2. Passive Attacks 953 Many mechanisms are subject to various passive attacks, including 954 simple eavesdropping of unprotected credential information as well as 955 online and offline dictionary attacks of protected credential 956 information. 958 6.3. Re-keying 960 The secure or administratively permitted lifetimes of SASL 961 mechanisms' security layers are finite. Cryptographic keys weaken as 962 they are used and as time passes; the more time and/or cipher-text 963 that a cryptanalyst has after the first use of the a key, the easier 964 it is for the cryptanalyst to mount attacks on the key. 966 Administrative limits on a security layer's lifetime may take the 967 form of time limits expressed in X.509 certificates, in Kerberos V 968 tickets, or in directories, and are often desired. In practice, one 969 likely effect of administrative lifetime limits is that applications 970 may find that security layers stop working in the middle of 971 application protocol operation, such as, perhaps, during large data 972 transfers. As the result of this, the connection will be closed (see 973 Section 3.7), which will result in an unpleasant user experience. 975 Re-keying (key renegotiation process) is a way of addressing the 976 weakening of cryptographic keys. The SASL framework does not itself 977 provide for re-keying; SASL mechanisms may. Designers of future SASL 978 mechanisms should consider providing re-keying services. 980 Implementations that wish to re-key SASL security layers where the 981 mechanism does not provide for re-keying SHOULD reauthenticate the 982 same IDs and replace the expired or soon-to-expire security layers. 983 This approach requires support for reauthentication in the 984 application protocols (see Section 3.8). 986 6.4. Other Considerations 988 Protocol designers and implementors should understand the security 989 considerations of mechanisms so they may select mechanisms that are 990 applicable to their needs. 992 Distributed server implementations need to be careful in how they 993 trust other parties. In particular, authentication secrets should 994 only be disclosed to other parties that are trusted to manage and use 995 those secrets in a manner acceptable to the disclosing party. 996 Applications using SASL assume that SASL security layers providing 997 data confidentiality are secure even when an attacker chooses the 998 text to be protected by the security layer. Similarly, applications 999 assume that the SASL security layer is secure even if the attacker 1000 can manipulate the cipher-text output of the security layer. New 1001 SASL mechanisms are expected to meet these assumptions. 1003 Unicode security considerations [UTR36] apply to authorization 1004 identity strings, as well as UTF-8 [RFC3629] security considerations 1005 where UTF-8 is used. SASLprep [RFC4013] and StringPrep [RFC3454] 1006 security considerations also apply where used. 1008 7. IANA Considerations 1010 7.1. SASL Mechanism Registry 1012 The SASL mechanism registry is maintained by IANA. The registry is 1013 currently available at . 1016 The purpose of this registry is not only to ensure uniqueness of 1017 values used to name SASL mechanisms, but also to provide a definitive 1018 reference to technical specifications detailing each SASL mechanism 1019 available for use on the Internet. 1021 There is no naming convention for SASL mechanisms; any name that 1022 conforms to the syntax of a SASL mechanism name can be registered. 1024 The procedure detailed in Section 7.1.1 is to be used for 1025 registration of a value naming a specific individual mechanism. 1027 The procedure detailed in Section 7.1.2 is to be used for 1028 registration of a value naming a family of related mechanisms. 1030 Comments may be included in the registry as discussed in Section 1031 7.1.3 and may be changed as discussed in Section 7.1.4. 1033 The SASL mechanism registry has been updated to reflect that this 1034 document provides the definitive technical specification for SASL and 1035 that this section provides the registration procedures for this 1036 registry. 1038 7.1.1. Mechanism Name Registration Procedure 1040 IANA will register new SASL mechanism names on a First Come First 1041 Served basis, as defined in BCP 26 [RFC5226]. IANA has the right to 1042 reject obviously bogus registration requests, but will perform no 1043 review of claims made in the registration form. 1045 Registration of a SASL mechanism is requested by filling in the 1046 following template: 1048 Subject: Registration of SASL mechanism X 1050 SASL mechanism name (or prefix for the family): 1052 Security considerations: 1054 Published specification (recommended): 1056 Person & email address to contact for further information: 1058 Intended usage: (One of COMMON, LIMITED USE, or OBSOLETE) 1060 Owner/Change controller: 1062 Note: (Any other information that the author deems relevant may be 1063 added here.) 1065 and sending it via electronic mail to IANA at . 1067 While this registration procedure does not require expert review, 1068 authors of SASL mechanisms are encouraged to seek community review 1069 and comment whenever that is feasible. Authors may seek community 1070 review by posting a specification of their proposed mechanism as an 1071 Internet-Draft. SASL mechanisms intended for widespread use should 1072 be standardized through the normal IETF process, when appropriate. 1074 7.1.2. Family Name Registration Procedure 1076 As noted above, there is no general naming convention for SASL 1077 mechanisms. However, specifications may reserve a portion of the 1078 SASL mechanism namespace for a set of related SASL mechanisms, a 1079 "family" of SASL mechanisms. Each family of SASL mechanisms is 1080 identified by a unique prefix, such as X-. Registration of new SASL 1081 mechanism family names requires expert review as defined in BCP 26 1082 [RFC5226]. 1084 Registration of a SASL family name is requested by filling in the 1085 following template: 1087 Subject: Registration of SASL mechanism family X 1089 SASL family name (or prefix for the family): 1091 Security considerations: 1093 Published specification (recommended): 1095 Person & email address to contact for further information: 1097 Intended usage: (One of COMMON, LIMITED USE, or OBSOLETE) 1099 Owner/Change controller: 1101 Note: (Any other information that the author deems relevant may be 1102 added here.) 1104 and sending it via electronic mail to the IETF SASL mailing list at 1105 and carbon copying IANA at . 1106 After allowing two weeks for community input on the IETF SASL mailing 1107 list, the expert will determine the appropriateness of the 1108 registration request and either approve or disapprove the request 1109 with notice to the requestor, the mailing list, and IANA. 1111 The review should focus on the appropriateness of the requested 1112 family name for the proposed use and the appropriateness of the 1113 proposed naming and registration plan for existing and future 1114 mechanism names in the family. The scope of this request review may 1115 entail consideration of relevant aspects of any provided technical 1116 specification, such as their IANA Considerations section. However, 1117 this review is narrowly focused on the appropriateness of the 1118 requested registration and not on the overall soundness of any 1119 provided technical specification. 1121 Authors are encouraged to pursue community review by posting the 1122 technical specification as an Internet-Draft and soliciting comment 1123 by posting to appropriate IETF mailing lists. 1125 7.1.3. Comments on SASL Mechanism Registrations 1127 Comments on a registered SASL mechanism/family should first be sent 1128 to the "owner" of the mechanism/family and/or to the 1129 mailing list. 1131 Submitters of comments may, after a reasonable attempt to contact the 1132 owner, request IANA to attach their comment to the SASL mechanism 1133 registration itself by sending mail to . At IANA's 1134 sole discretion, IANA may attach the comment to the SASL mechanism's 1135 registration. 1137 7.1.4. Change Control 1138 Once a SASL mechanism registration has been published by IANA, the 1139 author may request a change to its definition. The change request 1140 follows the same procedure as the registration request. 1142 The owner of a SASL mechanism may pass responsibility for the SASL 1143 mechanism to another person or agency by informing IANA; this can be 1144 done without discussion or review. 1146 The IESG may reassign responsibility for a SASL mechanism. The most 1147 common case of this will be to enable changes to be made to 1148 mechanisms where the author of the registration has died, has moved 1149 out of contact, or is otherwise unable to make changes that are 1150 important to the community. 1152 SASL mechanism registrations may not be deleted; mechanisms that are 1153 no longer believed appropriate for use can be declared OBSOLETE by a 1154 change to their "intended usage" field; such SASL mechanisms will be 1155 clearly marked in the lists published by IANA. 1157 The IESG is considered to be the owner of all SASL mechanisms that 1158 are on the IETF standards track. 1160 7.2. Registration Changes 1162 The IANA has updated the SASL mechanisms registry as follows: 1164 1) Changed the "Intended usage" of the KERBEROS_V4 and SKEY mechanism 1165 registrations to OBSOLETE. 1167 2) Changed the "Published specification" of the EXTERNAL mechanism to 1168 this document as indicated below: 1170 Subject: Updated Registration of SASL mechanism EXTERNAL 1171 Family of SASL mechanisms: NO 1172 SASL mechanism name: EXTERNAL 1173 Security considerations: See A.3 of RFC 4422 1174 Published specification (optional, recommended): RFC 4422 1175 Person & email address to contact for further information: 1176 Alexey Melnikov 1177 Intended usage: COMMON 1178 Owner/Change controller: IESG 1179 Note: Updates existing entry for EXTERNAL 1181 8. References 1183 8.1. Normative References 1185 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1186 Requirement Levels", BCP 14, RFC 2119, March 1997. 1188 [RFC2743] Linn, J., "Generic Security Service Application Program 1189 Interface Version 2, Update 1", RFC 2743, January 2000. 1191 [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 1192 10646", STD 63, RFC 3629, November 2003. 1194 [RFC4013] Zeilenga, K., "SASLprep: Stringprep Profile for User 1195 Names and Passwords", RFC 4013, February 2005. 1197 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing 1198 an IANA Considerations Section in RFCs", BCP 26, RFC 1199 5226, May 1998. 1201 [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for 1202 Syntax Specifications: ABNF", STD 68, RFC 5234, January 1203 2008. 1205 [ASCII] Coded Character Set--7-bit American Standard Code for 1206 Information Interchange, ANSI X3.4-1986. 1208 [Unicode] The Unicode Consortium, "The Unicode Standard, Version 1209 3.2.0" is defined by "The Unicode Standard, Version 1210 3.0" (Reading, MA, Addison-Wesley, 2000. ISBN 1211 0-201-61633-5), as amended by the "Unicode Standard 1212 Annex #27: Unicode 3.1" 1213 (http://www.unicode.org/reports/tr27/) and by the 1214 "Unicode Standard Annex #28: Unicode 3.2" 1215 (http://www.unicode.org/reports/tr28/). 1217 [CharModel] Whistler, K. and M. Davis, "Unicode Technical Report 1218 #17, Character Encoding Model", UTR17, 1219 , August 1220 2000. 1222 8.2. Informative References 1224 [RFC2244] Newman, C. and J. G. Myers, "ACAP -- Application 1225 Configuration Access Protocol", RFC 2244, November 1226 1997. 1228 [RFC3206] Gellens, R., "The SYS and AUTH POP Response Codes", RFC 1229 3206, February 2002. 1231 [RFC3454] Hoffman, P. and M. Blanchet, "Preparation of 1232 Internationalized Strings ("stringprep")", RFC 3454, 1233 December 2002. 1235 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the 1236 Internet Protocol", RFC 4301, December 2005. 1238 [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data 1239 Encodings", RFC 4648, October 2006. 1241 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer 1242 Security (TLS) Protocol Version 1.2", RFC 5246, August 1243 2008. 1245 [UTR36] Davis, M. and Michel Suignard, "Unicode Technical 1246 Report #36, Unicode Security Considerations", UTR36, 1247 , July 1248 2008. 1250 [Glossary] The Unicode Consortium, "Unicode Glossary", 1251 . 1253 9. Acknowledgements 1255 This document is a revision of RFC 4422, a product of the IETF Simple 1256 Authentication and Security Layer (SASL) Working Group. RFC 4422 was 1257 a revision of RFC 2222 by John Myers. 1259 This revision is also a product of the IETF SASL Working Group. 1261 The following individuals contributed significantly to this revision: 1262 TBD 1264 Appendix A. The SASL EXTERNAL Mechanism 1266 This appendix is normative. 1268 The EXTERNAL mechanism allows a client to request the server to use 1269 credentials established by means external to the mechanism to 1270 authenticate the client. The external means may be, for instance, IP 1271 Security [RFC4301] or TLS [RFC5246] services. In absence of some a 1272 priori agreement between the client and the server, the client cannot 1273 make any assumption as to what external means the server has used to 1274 obtain the client's credentials, nor make an assumption as to the 1275 form of credentials. For example, the client cannot assume that the 1276 server will use the credentials the client has established via TLS. 1278 A.1. EXTERNAL Technical Specification 1280 The name of this mechanism is "EXTERNAL". 1282 The mechanism does not provide a security layer. 1284 The mechanism is capable of transferring an authorization identity 1285 string. If empty, the client is requesting to act as the identity 1286 the server has associated with the client's credentials. If non- 1287 empty, the client is requesting to act as the identity represented by 1288 the string. 1290 The client is expected to send data first in the authentication 1291 exchange. Where the client does not provide an initial response data 1292 in its request to initiate the authentication exchange, the server is 1293 to respond to the request with an empty initial challenge and then 1294 the client is to provide its initial response. 1296 The client sends the initial response containing the UTF-8 [RFC3629] 1297 encoding of the requested authorization identity string. This 1298 response is non-empty when the client is requesting to act as the 1299 identity represented by the (non-empty) string. This response is 1300 empty when the client is requesting to act as the identity the server 1301 associated with its authentication credentials. 1303 The syntax of the initial response is specified as a value of the 1304 production detailed below using the Augmented 1305 Backus-Naur Form (ABNF) [RFC5234] notation. 1307 external-initial-resp = authz-id-string 1308 authz-id-string = *( UTF8-char-no-nul ) 1309 UTF8-char-no-nul = UTF8-1-no-nul / UTF8-2 / UTF8-3 / UTF8-4 1310 UTF8-1-no-nul = %x01-7F 1312 where the , , and productions are as defined 1313 in [RFC3629]. 1315 There are no additional challenges and responses. 1317 Hence, the server is to return the outcome of the authentication 1318 exchange. 1320 The exchange fails if 1322 - the client has not established its credentials via external means, 1324 - the client's credentials are inadequate, 1326 - the client provided an empty authorization identity string and the 1327 server is unwilling or unable to associate an authorization 1328 identity with the client's credentials, 1330 - the client provided a non-empty authorization identity string that 1331 is invalid per the syntax requirements of the applicable 1332 application protocol specification, 1334 - the client provided a non-empty authorization identity string 1335 representing an identity that the client is not allowed to act as, 1336 or 1338 - the server is unwilling or unable to provide service to the client 1339 for any other reason. 1341 Otherwise the exchange is successful. When indicating a successful 1342 outcome, additional data is not provided. 1344 A.2. SASL EXTERNAL Examples 1346 This section provides examples of EXTERNAL authentication exchanges. 1347 The examples are intended to help the readers understand the above 1348 text. The examples are not definitive. The Application 1349 Configuration Access Protocol (ACAP) [RFC2244] is used in the 1350 examples. 1352 The first example shows use of EXTERNAL with an empty authorization 1353 identity. In this example, the initial response is not sent in the 1354 client's request to initiate the authentication exchange. 1356 S: * ACAP (SASL "GSSAPI") 1357 C: a001 STARTTLS 1358 S: a001 OK "Begin TLS negotiation now" 1359 1360 S: * ACAP (SASL "GSSAPI" "EXTERNAL") 1361 C: a002 AUTHENTICATE "EXTERNAL" 1362 S: + "" 1363 C: + "" 1364 S: a002 OK "Authenticated" 1366 The second example shows use of EXTERNAL with an authorization 1367 identity of "fred@example.com". In this example, the initial 1368 response is sent with the client's request to initiate the 1369 authentication exchange. This saves a round-trip. 1371 S: * ACAP (SASL "GSSAPI") 1372 C: a001 STARTTLS 1373 S: a001 OK "Begin TLS negotiation now" 1374 1375 S: * ACAP (SASL "GSSAPI" "EXTERNAL") 1376 C: a002 AUTHENTICATE "EXTERNAL" {16+} 1377 C: fred@example.com 1378 S: a002 NO "Cannot assume requested authorization identity" 1380 A.3. Security Considerations 1382 The EXTERNAL mechanism provides no security protection; it is 1383 vulnerable to spoofing by either client or server, active attack, and 1384 eavesdropping. It should only be used when adequate security 1385 services have been established. 1387 Appendix B. Changes since RFC 4422 1389 This appendix is non-normative. 1391 The following is a summary of the changes were made: 1393 - References updated and corrected. 1395 Editors' Addresses 1397 Alexey Melnikov 1398 Isode Limited 1399 5 Castle Business Village 1400 36 Station Road 1401 Hampton, Middlesex TW12 2BX 1402 UK 1404 EMail: Alexey.Melnikov@isode.com 1405 Kurt D. Zeilenga 1406 Isode Limited 1408 EMail: Kurt.Zeilenga@isode.com 1410 Intellectual Property 1412 The IETF takes no position regarding the validity or scope of any 1413 Intellectual Property Rights or other rights that might be claimed to 1414 pertain to the implementation or use of the technology described in 1415 this document or the extent to which any license under such rights 1416 might or might not be available; nor does it represent that it has 1417 made any independent effort to identify any such rights. Information 1418 on the procedures with respect to rights in RFC documents can be found 1419 in BCP 78 and BCP 79. 1421 Copies of IPR disclosures made to the IETF Secretariat and any 1422 assurances of licenses to be made available, or the result of an 1423 attempt made to obtain a general license or permission for the use of 1424 such proprietary rights by implementers or users of this specification 1425 can be obtained from the IETF on-line IPR repository at 1426 http://www.ietf.org/ipr. 1428 The IETF invites any interested party to bring to its attention any 1429 copyrights, patents or patent applications, or other proprietary 1430 rights that may cover technology that may be required to implement 1431 this standard. Please address the information to the IETF at 1432 ietf-ipr@ietf.org. 1434 Full Copyright 1436 Copyright (C) The IETF Trust (2008). 1438 This document is subject to the rights, licenses and restrictions 1439 contained in BCP 78, and except as set forth therein, the authors 1440 retain all their rights. 1442 This document and the information contained herein are provided on an 1443 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1444 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 1445 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 1446 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 1447 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1448 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.