idnits 2.17.1 draft-ietf-sasl-4422bis-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.i or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. See https://trustee.ietf.org/license-info/.) 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 and authors 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 contain a disclaimer for pre-RFC5378 work, and may have content which was first submitted before 10 November 2008. The disclaimer is necessary when there are original authors that you have been unable to contact, or if some do not wish to grant the BCP78 rights to the IETF Trust. If you are able to get all authors (current and original) to grant those rights, you can and should remove the disclaimer; otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (14 April 2009) is 5491 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 755, but not defined == Missing Reference: 'CRAM-MD5' is mentioned on line 758, 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 (==), 7 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 14 April 2009 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 This Internet-Draft is submitted to IETF in full conformance with the 21 provisions of BCP 78 and BCP 79. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF), its areas, and its working groups. Note that other 25 groups may also distribute working documents as Internet-Drafts. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 The list of current Internet-Drafts can be accessed at 33 http://www.ietf.org/1id-abstracts.html. 35 The list of Internet-Draft Shadow Directories can be accessed at 36 http://www.ietf.org/shadow.html. 38 Copyright (c) 2009 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 Abstract 43 The Simple Authentication and Security Layer (SASL) is a framework 44 for providing authentication and data security services in 45 connection-oriented protocols via replaceable mechanisms. It 46 provides a structured interface between protocols and mechanisms. 47 The resulting framework allows new protocols to reuse existing 48 mechanisms and allows old protocols to make use of new mechanisms. 49 The framework also provides a protocol for securing subsequent 50 protocol exchanges within a data security layer. 52 This document describes how a SASL mechanism is structured, describes 53 how protocols include support for SASL, and defines the protocol for 54 carrying a data security layer over a connection. In addition, this 55 document defines one SASL mechanism, the EXTERNAL mechanism. 57 This document obsoletes RFC 4422 [[when approved]]. 59 Table of Contents 61 [[Page numbers to be added by RFC-Editor]] 63 1. Introduction ................................................... 64 1.1. Document Audiences ........................................ 65 1.2. Relationship to Other Documents ........................... 66 1.3. Conventions ............................................... 67 2. Identity Concepts .............................................. 68 3. The Authentication Exchange .................................... 69 3.1. Mechanism Naming .......................................... 70 3.2. Mechanism Negotiation ..................................... 71 3.3. Request Authentication Exchange ........................... 72 3.4. Challenges and Responses .................................. 73 3.4.1. Authorization Identity String ...................... 74 3.5. Aborting Authentication Exchanges ......................... 75 3.6. Authentication Outcome .................................... 76 3.7. Security Layers ........................................... 77 3.8. Multiple Authentications .................................. 78 4. Protocol Requirements .......................................... 79 5. Mechanism Requirements ......................................... 80 6. Security Considerations ........................................ 81 6.1. Active Attacks ............................................ 82 6.1.1. Hijack Attacks ..................................... 83 6.1.2. Downgrade Attacks .................................. 84 6.1.3. Replay Attacks ..................................... 85 6.1.4. Truncation Attacks ................................. 86 6.1.5. Other Active Attacks ............................... 87 6.2. Passive Attacks ........................................... 88 6.3. Re-keying ................................................. 89 6.4. Other Considerations ...................................... 90 7. IANA Considerations ............................................ 91 7.1. SASL Mechanism Registry ................................... 92 7.2. Registration Changes ...................................... 93 8. References ..................................................... 94 8.1. Normative References ...................................... 95 8.2. Informative References .................................... 96 9. Acknowledgements ............................................... 97 Appendix A. The SASL EXTERNAL Mechanism .......................... 98 A.1. EXTERNAL Technical Specification .......................... 99 A.2. SASL EXTERNAL Examples .................................... 100 A.3. Security Considerations ................................... 101 Appendix B. Changes since RFC 4422 ............................... 103 1. Introduction 105 The Simple Authentication and Security Layer (SASL) is a framework 106 for providing authentication and data security services in 107 connection-oriented protocols via replaceable mechanisms. SASL 108 provides a structured interface between protocols and mechanisms. 109 SASL also provides a protocol for securing subsequent protocol 110 exchanges within a data security layer. The data security layer can 111 provide data integrity, data confidentiality, and other services. 113 SASL's design is intended to allow new protocols to reuse existing 114 mechanisms without requiring redesign of the mechanisms and allows 115 existing protocols to make use of new mechanisms without redesign of 116 protocols. 118 SASL is conceptually a framework that provides an abstraction layer 119 between protocols and mechanisms as illustrated in the following 120 diagram. 122 SMTP LDAP XMPP Other protocols ... 123 \ | | / 124 \ | | / 125 SASL abstraction layer 126 / | | \ 127 / | | \ 128 EXTERNAL GSSAPI PLAIN Other mechanisms ... 130 It is through the interfaces of this abstraction layer that the 131 framework allows any protocol to utilize any mechanism. While this 132 layer does generally hide the particulars of protocols from 133 mechanisms and the particulars of mechanisms from protocols, this 134 layer does not generally hide the particulars of mechanisms from 135 protocol implementations. For example, different mechanisms require 136 different information to operate, some of them use password-based 137 authentication, some of then require realm information, others make 138 use of Kerberos tickets, certificates, etc. Also, in order to 139 perform authorization, server implementations generally have to 140 implement identity mapping between authentication identities, whose 141 form is mechanism specific, and authorization identities, whose form 142 is application protocol specific. Section 2 discusses identity 143 concepts. 145 It is possible to design and implement this framework in ways that do 146 abstract away particulars of similar mechanisms. Such a framework 147 implementation, as well as mechanisms implementations, could be 148 designed not only to be shared by multiple implementations of a 149 particular protocol but to be shared by implementations of multiple 150 protocols. 152 The framework incorporates interfaces with both protocols and 153 mechanisms in which authentication exchanges are carried out. 154 Section 3 discusses SASL authentication exchanges. 156 To use SASL, each protocol (amongst other items) provides a method 157 for identifying which mechanism is to be used, a method for exchange 158 of mechanism-specific server-challenges and client-responses, and a 159 method for communicating the outcome of the authentication exchange. 160 Section 4 discusses SASL protocol requirements. 162 Each SASL mechanism defines (amongst other items) a series of 163 server-challenges and client-responses that provide authentication 164 services and negotiate data security services. Section 5 discusses 165 SASL mechanism requirements. 167 Section 6 discusses security considerations. Section 7 discusses 168 IANA considerations. Appendix A defines the SASL EXTERNAL mechanism. 170 1.1. Document Audiences 172 This document is written to serve several different audiences: 174 - protocol designers using this specification to support 175 authentication in their protocol, 177 - mechanism designers that define new SASL mechanisms, and 179 - implementors of clients or servers for those protocols that 180 support SASL. 182 While the document organization is intended to allow readers to focus 183 on details relevant to their engineering, readers are encouraged to 184 read and understand all aspects of this document. 186 1.2. Relationship to Other Documents 188 This document obsoletes RFC 4422. It replaces RFC 4422 in its 189 entirety. Appendix B provides a summary of changes since RFC 4422. 191 1.3. Conventions 193 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 194 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 195 document are to be interpreted as described in BCP 14 [RFC2119]. 197 Character names in this document use the notation for code points and 198 names from the Unicode Standard [Unicode]. For example, the letter 199 "a" may be represented as either or . 201 Note: a glossary of terms used in Unicode can be found in [Glossary]. 202 Information on the Unicode character encoding model can be found in 203 [CharModel]. 205 In examples, "C:" and "S:" indicate lines of data to be sent by the 206 client and server, respectively. Lines have been wrapped for 207 improved readability. 209 2. Identity Concepts 211 In practice, authentication and authorization may involve multiple 212 identities, possibly in different forms (simple username, Kerberos 213 principal, X.500 Distinguished Name, etc.), possibly with different 214 representations (e.g., ABNF-described UTF-8 encoded Unicode character 215 string, BER-encoded Distinguished Name). While technical 216 specifications often prescribe both the identity form and 217 representation used on the network, different identity forms and/or 218 representations may be (and often are) used within implementations. 219 How identities of different forms relate to each other is, generally, 220 a local matter. In addition, the forms and representations used 221 within an implementation are a local matter. 223 However, conceptually, the SASL framework involves two identities: 225 1) an identity associated with the authentication credentials 226 (termed the authentication identity), and 228 2) an identity to act as (termed the authorization identity). 230 SASL mechanism specifications describe the credential form(s) (e.g., 231 X.509 certificates, Kerberos tickets, simple username/password) used 232 to authenticate the client, including (where appropriate) the syntax 233 and semantics of authentication identities carried in the 234 credentials. SASL protocol specifications describe the identity 235 form(s) used in authorization and, in particular, prescribe the 236 syntax and semantics of the authorization identity character string 237 to be transferred by mechanisms. 239 The client provides its credentials (which include or imply an 240 authentication identity) and, optionally, a character string 241 representing the requested authorization identity as part of the SASL 242 exchange. When this character string is omitted or empty, the client 243 is requesting to act as the identity associated with the credentials 244 (e.g., the user is requesting to act as the authentication identity). 246 The server is responsible for verifying the client's credentials and 247 verifying that the identity it associates with the client's 248 credentials (e.g., the authentication identity) is allowed to act as 249 the authorization identity. A SASL exchange fails if either (or 250 both) of these verifications fails. (The SASL exchange may fail for 251 other reasons, such as service authorization failure.) 253 However, the precise form(s) of the authentication identities (used 254 within the server in its verifications, or otherwise) and the precise 255 form(s) of the authorization identities (used in making authorization 256 decisions, or otherwise) are beyond the scope of SASL and this 257 specification. In some circumstances, the precise identity forms 258 used in some context outside of the SASL exchange may be dictated by 259 other specifications. For instance, an identity assumption 260 authorization (proxy authorization) policy specification may dictate 261 how authentication and authorization identities are represented in 262 policy statements. 264 3. The Authentication Exchange 266 Each authentication exchange consists of a message from the client to 267 the server requesting authentication via a particular mechanism, 268 followed by one or more pairs of challenges from the server and 269 responses from the client, followed by a message from the server 270 indicating the outcome of the authentication exchange. (Note: 271 exchanges may also be aborted as discussed in Section 3.5.) 273 The following illustration provides a high-level overview of an 274 authentication exchange. 276 C: Request authentication exchange 277 S: Initial challenge 278 C: Initial response 279 280 S: Outcome of authentication exchange 282 If the outcome is successful and a security layer was negotiated, 283 this layer is then installed (see Section 3.7). This also applies to 284 the following illustrations. 286 Some mechanisms specify that the first data sent in the 287 authentication exchange is from the client to the server. Protocols 288 may provide an optional initial response field in the request message 289 to carry this data. Where the mechanism specifies that the first 290 data sent in the exchange is from the client to the server, the 291 protocol provides an optional initial response field, and the client 292 uses this field, the exchange is shortened by one round-trip: 294 C: Request authentication exchange + Initial response 295 296 S: Outcome of authentication exchange 298 Where the mechanism specifies that the first data sent in the 299 exchange is from the client to the server and this field is 300 unavailable or unused, the client request is followed by an empty 301 challenge. 303 C: Request authentication exchange 304 S: Empty Challenge 305 C: Initial Response 306 307 S: Outcome of authentication exchange 309 Should a client include an initial response in its request where the 310 mechanism does not allow the client to send data first, the 311 authentication exchange fails. 313 Some mechanisms specify that the server is to send additional data to 314 the client when indicating a successful outcome. Protocols may 315 provide an optional additional data field in the outcome message to 316 carry this data. Where the mechanism specifies that the server is to 317 return additional data with the successful outcome, the protocol 318 provides an optional additional data field in the outcome message, 319 and the server uses this field, the exchange is shortened by one 320 round-trip: 322 C: Request authentication exchange 323 S: Initial challenge 324 C: Initial response 325 326 S: Outcome of authentication exchange with 327 additional data with success 329 Where the mechanism specifies that the server is to return additional 330 data to the client with a successful outcome and this field is 331 unavailable or unused, the additional data is sent as a challenge 332 whose response is empty. After receiving this response, the server 333 then indicates the successful outcome. 335 C: Request authentication exchange 336 S: Initial challenge 337 C: Initial response 338 339 S: Additional data challenge 340 C: Empty Response 341 S: Outcome of authentication exchange 343 Where mechanisms specify that the first data sent in the exchange is 344 from the client to the server and additional data is sent to the 345 client along with indicating a successful outcome, and the protocol 346 provides fields supporting both, then the exchange takes two fewer 347 round-trips: 349 C: Request authentication exchange + Initial response 350 351 S: Outcome of authentication exchange 352 with additional data with success 354 instead of: 356 C: Request authentication exchange 357 S: Empty Challenge 358 C: Initial Response 359 360 S: Additional data challenge 361 C: Empty Response 362 S: Outcome of authentication exchange 364 3.1. Mechanism Naming 366 SASL mechanisms are named by character strings, from 1 to 20 367 characters in length, consisting of ASCII [ASCII] uppercase letters, 368 digits, hyphens, and/or underscores. In the following Augmented 369 Backus-Naur Form (ABNF) [RFC5234] grammar, the production 370 defines the syntax of a SASL mechanism name. 372 sasl-mech = 1*20mech-char 373 mech-char = UPPER-ALPHA / DIGIT / HYPHEN / UNDERSCORE 374 ; mech-char is restricted to A-Z (uppercase only), 0-9, -, and _ 375 ; from ASCII character set. 377 UPPER-ALPHA = %x41-5A ; A-Z (uppercase only) 378 DIGIT = %x30-39 ; 0-9 379 HYPHEN = %x2D ; hyphen (-) 380 UNDERSCORE = %x5F ; underscore (_) 382 SASL mechanism names are registered as discussed in Section 7.1. 384 3.2. Mechanism Negotiation 385 Mechanism negotiation is protocol specific. 387 Commonly, a protocol will specify that the server advertises 388 supported and available mechanisms to the client via some facility 389 provided by the protocol, and the client will then select the "best" 390 mechanism from this list that it supports and finds suitable. 392 Note that the mechanism negotiation is not protected by the 393 subsequent authentication exchange and hence is subject to downgrade 394 attacks if not protected by other means. 396 To detect downgrade attacks, a protocol can allow the client to 397 discover available mechanisms subsequent to the authentication 398 exchange and installation of data security layers with at least data 399 integrity protection. This allows the client to detect changes to 400 the list of mechanisms supported by the server. 402 3.3. Request Authentication Exchange 404 The authentication exchange is initiated by the client by requesting 405 authentication via a mechanism it specifies. The client sends a 406 message that contains the name of the mechanism to the server. The 407 particulars of the message are protocol specific. 409 Note that the name of the mechanism is not protected by the 410 mechanism, and hence is subject to alteration by an attacker if not 411 integrity protected by other means. 413 Where the mechanism is defined to allow the client to send data 414 first, and the protocol's request message includes an optional 415 initial response field, the client may include the response to the 416 initial challenge in the authentication request message. 418 3.4. Challenges and Responses 420 The authentication exchange involves one or more pairs of 421 server-challenges and client-responses, the particulars of which are 422 mechanism specific. These challenges and responses are enclosed in 423 protocol messages, the particulars of which are protocol specific. 425 Through these challenges and responses, the mechanism may: 427 - authenticate the client to the server, 429 - authenticate the server to the client, 430 - transfer an authorization identity string, 432 - negotiate a security layer, and 434 - provide other services. 436 The negotiation of the security layer may involve negotiation of the 437 security services to be provided in the layer, how these services 438 will be provided, and negotiation of a maximum cipher-text buffer 439 size each side is able to receive in the layer (see Section 3.6). 441 After receiving an authentication request or any client response, the 442 server may issue a challenge, abort the exchange, or indicate the 443 outcome of an exchange. After receiving a challenge, a client 444 mechanism may issue a response or abort the exchange. 446 3.4.1. Authorization Identity String 448 The authorization identity string is a sequence of zero or more 449 Unicode [Unicode] characters, excluding the NUL (U+0000) character, 450 representing the identity to act as. 452 If the authorization identity string is absent, the client is 453 requesting to act as the identity the server associates with the 454 client's credentials. An empty string is equivalent to an absent 455 authorization identity. 457 A non-empty authorization identity string indicates that the client 458 wishes to act as the identity represented by the string. In this 459 case, the form of identity represented by the string, as well as the 460 precise syntax and semantics of the string, is protocol specific. 462 While the character encoding schema used to transfer the 463 authorization identity string in the authentication exchange is 464 mechanism specific, mechanisms are expected to be capable of carrying 465 the entire Unicode repertoire (with the exception of the NUL 466 character). 468 3.5. Aborting Authentication Exchanges 470 A client or server may desire to abort an authentication exchange if 471 it is unwilling or unable to continue (or enter into). 473 A client may abort the authentication exchange by sending a message, 474 the particulars of which are protocol specific, to the server, 475 indicating that the exchange is aborted. The server may be required 476 by the protocol to return a message in response to the client's abort 477 message. 479 Likewise, a server may abort the authentication exchange by sending a 480 message, the particulars of which are protocol specific, to the 481 client, indicating that the exchange is aborted. 483 3.6. Authentication Outcome 485 At the conclusion of the authentication exchange, the server sends a 486 message, the particulars of which are protocol specific, to the 487 client indicating the outcome of the exchange. 489 The outcome is not successful if 491 - the authentication exchange failed for any reason, 493 - the client's credentials could not be verified, 495 - the server cannot associate an identity with the client's 496 credentials, 498 - the client-provided authorization identity string is malformed, 500 - the identity associated with the client's credentials is not 501 authorized to act as the requested authorization identity, 503 - the negotiated security layer (or lack thereof) is not suitable, 504 or 506 - the server is not willing to provide service to the client for 507 any reason. 509 The protocol may include an optional additional data field in this 510 outcome message. This field can only include additional data when 511 the outcome is successful. 513 If the outcome is successful and a security layer was negotiated, 514 this layer is then installed. If the outcome is unsuccessful, or a 515 security layer was not negotiated, any existing security is left in 516 place. 518 The outcome message provided by the server can provide a way for the 519 client to distinguish between errors that are best dealt with by 520 re-prompting the user for her credentials, errors that are best dealt 521 with by telling the user to try again later, and errors where the 522 user must contact a system administrator for resolution (see the SYS 523 and AUTH POP Response Codes [RFC3206] specification for an example). 524 This distinction is particularly useful during scheduled server 525 maintenance periods as it reduces support costs. It is also 526 important that the server can be configured such that the outcome 527 message will not distinguish between a valid user with invalid 528 credentials and an invalid user. 530 3.7. Security Layers 532 SASL mechanisms may offer a wide range of services in security 533 layers. Typical services include data integrity and data 534 confidentiality. SASL mechanisms that do not provide a security 535 layer are treated as negotiating no security layer. 537 If use of a security layer is negotiated in the authentication 538 protocol exchange, the layer is installed by the server after 539 indicating the outcome of the authentication exchange and installed 540 by the client upon receipt of the outcome indication. In both cases, 541 the layer is installed before transfer of further protocol data. The 542 precise position upon which the layer takes effect in the protocol 543 data stream is protocol specific. 545 Once the security layer is in effect in the protocol data stream, it 546 remains in effect until either a subsequently negotiated security 547 layer is installed or the underlying transport connection is closed. 549 When in effect, the security layer processes protocol data into 550 buffers of protected data. If at any time the security layer is 551 unable or unwilling to continue producing buffers protecting protocol 552 data, the underlying transport connection MUST be closed. If the 553 security layer is not able to decode a received buffer, the 554 underlying connection MUST be closed. In both cases, the underlying 555 transport connection SHOULD be closed gracefully. 557 Each buffer of protected data is transferred over the underlying 558 transport connection as a sequence of octets prepended with a 559 four-octet field in network byte order that represents the length of 560 the buffer. The length of the protected data buffer MUST be no 561 larger than the maximum size that the other side expects. Upon the 562 receipt of a length field whose value is greater than the maximum 563 size, the receiver SHOULD close the connection, as this might be a 564 sign of an attack. 566 The maximum size that each side expects is fixed by the mechanism, 567 either through negotiation or by its specification. 569 3.8. Multiple Authentications 570 Unless explicitly permitted in the protocol (as stated in the 571 protocol's technical specification), only one successful SASL 572 authentication exchange may occur in a protocol session. In this 573 case, once an authentication exchange has successfully completed, 574 further attempts to initiate an authentication exchange fail. 576 Where multiple successful SASL authentication exchanges are permitted 577 in the protocol, then in no case may multiple SASL security layers be 578 simultaneously in effect. If a security layer is in effect and a 579 subsequent SASL negotiation selects a second security layer, then the 580 second security layer replaces the first. If a security layer is in 581 effect and a subsequent SASL negotiation selects no security layer, 582 the original security layer remains in effect. 584 Where multiple successful SASL negotiations are permitted in the 585 protocol, the effect of a failed SASL authentication exchange upon 586 the previously established authentication and authorization state is 587 protocol specific. The protocol's technical specification should be 588 consulted to determine whether the previous authentication and 589 authorization state remains in force, or changed to an anonymous 590 state, or otherwise was affected. Regardless of the 591 protocol-specific effect upon previously established authentication 592 and authorization state, the previously negotiated security layer 593 remains in effect. 595 4. Protocol Requirements 597 In order for a protocol to offer SASL services, its specification 598 MUST supply the following information: 600 1) A service name, to be selected from registry of "service" elements 601 for the Generic Security Service Application Program Interface 602 (GSSAPI) host-based service name form, as described in Section 4.1 603 of [RFC2743]. Note that this registry is shared by all GSSAPI and 604 SASL mechanisms. 606 2) Detail any mechanism negotiation facility that the protocol 607 provides (see Section 3.2). 609 A protocol SHOULD specify a facility through which the client may 610 discover, both before initiation of the SASL exchange and after 611 installing security layers negotiated by the exchange, the names 612 of the SASL mechanisms that the server makes available to the 613 client. The latter is important to allow the client to detect 614 downgrade attacks. This facility is typically provided through 615 the protocol's extensions or capabilities discovery facility. 617 3) Definition of the messages necessary for authentication exchange, 618 including the following: 620 a) A message to initiate the authentication exchange (see Section 621 3.3). 623 This message MUST contain a field for carrying the name of the 624 mechanism selected by the client. 626 This message SHOULD contain an optional field for carrying an 627 initial response. If the message is defined with this field, 628 the specification MUST describe how messages with an empty 629 initial response are distinguished from messages with no 630 initial response. This field MUST be capable of carrying 631 arbitrary sequences of octets (including zero-length sequences 632 and sequences containing zero-valued octets). 634 b) Messages to transfer server challenges and client responses 635 (see Section 3.4). 637 Each of these messages MUST be capable of carrying arbitrary 638 sequences of octets (including zero-length sequences and 639 sequences containing zero-valued octets). 641 c) A message to indicate the outcome of the authentication 642 exchange (see Section 3.6). 644 This message SHOULD contain an optional field for carrying 645 additional data with a successful outcome. If the message is 646 defined with this field, the specification MUST describe how 647 messages with an empty additional data are distinguished from 648 messages with no additional data. This field MUST be capable 649 of carrying arbitrary sequences of octets (including 650 zero-length sequences and sequences containing zero-valued 651 octets). 653 4) Prescribe the syntax and semantics of non-empty authorization 654 identity strings (see Section 3.4.1). 656 In order to avoid interoperability problems due to differing 657 normalizations, the protocol specification MUST detail precisely 658 how and where (client or server) non-empty authorization identity 659 strings are prepared, including all normalizations, for comparison 660 and other applicable functions to ensure proper function. 662 Specifications are encouraged to prescribe use of existing 663 authorization identity forms as well as existing string 664 representations, such as simple user names [RFC4013]. 666 Where the specification does not precisely prescribe how 667 identities in SASL relate to identities used elsewhere in the 668 protocol, for instance, in access control policy statements, it 669 may be appropriate for the protocol to provide a facility by which 670 the client can discover information (such as the representation of 671 the identity used in making access control decisions) about 672 established identities for these uses. 674 5) Detail any facility the protocol provides that allows the client 675 and/or server to abort authentication exchange (see Section 3.5). 677 Protocols that support multiple authentications typically allow a 678 client to abort an ongoing authentication exchange by initiating a 679 new authentication exchange. Protocols that do not support 680 multiple authentications may require the client to close the 681 connection and start over to abort an ongoing authentication 682 exchange. 684 Protocols typically allow the server to abort ongoing 685 authentication exchanges by returning a non-successful outcome 686 message. 688 6) Identify precisely where newly negotiated security layers start to 689 take effect, in both directions (see Section 3.7). 691 Typically, specifications require security layers to start taking 692 effect on the first octet following the outcome message in data 693 being sent by the server and on the first octet sent after receipt 694 of the outcome message in data being sent by the client. 696 7) If the protocol supports other layered security services, such as 697 Transport Layer Security (TLS) [RFC5246], the specification MUST 698 prescribe the order in which security layers are applied to 699 protocol data. 701 For instance, where a protocol supports both TLS and SASL security 702 layers, the specification could prescribe any of the following: 704 a) SASL security layer is always applied first to data being sent 705 and, hence, applied last to received data, 707 b) SASL security layer is always applied last to data being sent 708 and, hence, applied first to received data, 710 c) Layers are applied in the order in which they were installed, 712 d) Layers are applied in the reverse order in which they were 713 installed, or 715 e) Both TLS and SASL security layers cannot be installed. 717 8) Indicate whether the protocol supports multiple authentications 718 (see Section 3.8). If so, the protocol MUST detail the effect a 719 failed SASL authentication exchange will have upon a previously 720 established authentication and authorization state. 722 Protocol specifications SHOULD avoid stating implementation 723 requirements that would hinder replacement of applicable mechanisms. 724 In general, protocol specifications SHOULD be mechanism neutral. 725 There are a number of reasonable exceptions to this recommendation, 726 including 728 - detailing how credentials (which are mechanism specific) are 729 managed in the protocol, 731 - detailing how authentication identities (which are mechanism 732 specific) and authorization identities (which are protocol 733 specific) relate to each other, and 735 - detailing which mechanisms are applicable to the protocol. 737 5. Mechanism Requirements 739 SASL mechanism specifications MUST supply the following information: 741 1) The name of the mechanism (see Section 3.1). This name MUST be 742 registered as discussed in Section 7.1. 744 2) A definition of the server-challenges and client-responses of the 745 authentication exchange, as well as the following: 747 a) An indication of whether the mechanism is client-first, 748 variable, or server-first. If a SASL mechanism is defined as 749 client-first and the client does not send an initial response 750 in the authentication request, then the first server challenge 751 MUST be empty (the EXTERNAL mechanism is an example of this 752 case). If a SASL mechanism is defined as variable, then the 753 specification needs to state how the server behaves when the 754 initial client response in the authentication request is 755 omitted (the DIGEST-MD5 mechanism [DIGEST-MD5] is an example of 756 this case). If a SASL mechanism is defined as server-first, 757 then the client MUST NOT send an initial client response in the 758 authentication request (the CRAM-MD5 mechanism [CRAM-MD5] is an 759 example of this case). 761 b) An indication of whether the server is expected to provide 762 additional data when indicating a successful outcome. If so, 763 if the server sends the additional data as a challenge, the 764 specification MUST indicate that the response to this challenge 765 is an empty response. 767 SASL mechanisms SHOULD be designed to minimize the number of 768 challenges and responses necessary to complete the exchange. 770 3) An indication of whether the mechanism is capable of transferring 771 authorization identity strings (see Section 3.4.1). While some 772 legacy mechanisms are incapable of transmitting an authorization 773 identity (which means that for these mechanisms, the authorization 774 identity is always the empty string), newly defined mechanisms 775 SHOULD be capable of transferring authorization identity strings. 776 The mechanism SHOULD NOT be capable of transferring both no 777 authorization identity string and an empty authorization identity. 779 Mechanisms that are capable of transferring an authorization 780 identity string MUST be capable of transferring arbitrary 781 non-empty sequences of Unicode characters, excluding those that 782 contain the NUL (U+0000) character. Mechanisms SHOULD use the 783 UTF-8 [RFC3629] transformation format. The specification MUST 784 detail how any Unicode code points special to the mechanism that 785 might appear in the authorization identity string are escaped to 786 avoid ambiguity during decoding of the authorization identity 787 string. Typically, mechanisms that have special characters 788 require these special characters to be escaped or encoded in the 789 character string (after encoding it in a particular Unicode 790 transformation format) using a data encoding scheme such as Base64 791 [RFC4648]. 793 4) The specification MUST detail whether the mechanism offers a 794 security layer. If the mechanism does, the specification MUST 795 detail the security and other services offered in the layer as 796 well as how these services are to be implemented. 798 5) If the underlying cryptographic technology used by a mechanism 799 supports data integrity, then the mechanism specification MUST 800 integrity protect the transmission of an authorization identity 801 and the negotiation of the security layer. 803 SASL mechanisms SHOULD be protocol neutral. 805 SASL mechanisms SHOULD reuse existing credential and identity forms, 806 as well as associated syntaxes and semantics. 808 SASL mechanisms SHOULD use the UTF-8 transformation format [RFC3629] 809 for encoding Unicode [Unicode] code points for transfer. 811 In order to avoid interoperability problems due to differing 812 normalizations, when a mechanism calls for character data (other than 813 the authorization identity string) to be used as input to a 814 cryptographic and/or comparison function, the specification MUST 815 detail precisely how and where (client or server) the character data 816 is to be prepared, including all normalizations, for input into the 817 function to ensure proper operation. 819 For simple user names and/or passwords in authentication credentials, 820 SASLprep [RFC4013] (a profile of the StringPrep [RFC3454] preparation 821 algorithm), SHOULD be specified as the preparation algorithm. 823 The mechanism SHOULD NOT use the authorization identity string in 824 generation of any long-term cryptographic keys or hashes as there is 825 no requirement that the authorization identity string be canonical. 826 Long-term, here, means a term longer than the duration of the 827 authentication exchange in which they were generated. That is, as 828 different clients (of the same or different protocol) may provide 829 different authorization identity strings that are semantically 830 equivalent, use of authorization identity strings in generation of 831 cryptographic keys and hashes will likely lead to interoperability 832 and other problems. 834 6. Security Considerations 836 Security issues are discussed throughout this memo. 838 Many existing SASL mechanisms do not provide adequate protection 839 against passive attacks, let alone active attacks, in the 840 authentication exchange. Many existing SASL mechanisms do not offer 841 security layers. It is hoped that future SASL mechanisms will 842 provide strong protection against passive and active attacks in the 843 authentication exchange, as well as security layers with strong basic 844 data security features (e.g., data integrity and data 845 confidentiality) services. It is also hoped that future mechanisms 846 will provide more advanced data security services like re-keying (see 847 Section 6.3). 849 Regardless, the SASL framework is susceptible to downgrade attacks. 850 Section 6.1.2 offers a variety of approaches for preventing or 851 detecting these attacks. In some cases, it is appropriate to use 852 data integrity protective services external to SASL (e.g., TLS) to 853 protect against downgrade attacks in SASL. Use of external 854 protective security services is also important when the mechanisms 855 available do not themselves offer adequate integrity and/or 856 confidentiality protection of the authentication exchange and/or 857 protocol data. 859 6.1. Active Attacks 861 6.1.1. Hijack Attacks 863 When the client selects a SASL security layer with at least integrity 864 protection, this protection serves as a counter-measure against an 865 active attacker hijacking the connection and modifying protocol data 866 sent after establishment of the security layer. Implementations 867 SHOULD close the connection when the security services in a SASL 868 security layer report protocol data report lack of data integrity. 870 6.1.2. Downgrade Attacks 872 It is important that any security-sensitive protocol negotiations be 873 performed after installation of a security layer with data integrity 874 protection. Protocols should be designed such that negotiations 875 performed prior to this installation should be revalidated after 876 installation is complete. Negotiation of the SASL mechanism is 877 security sensitive. 879 When a client negotiates the authentication mechanism with the server 880 and/or other security features, it is possible for an active attacker 881 to cause a party to use the least secure security services available. 882 For instance, an attacker can modify the server-advertised mechanism 883 list or can modify the client-advertised security feature list within 884 a mechanism response. To protect against this sort of attack, 885 implementations SHOULD NOT advertise mechanisms and/or features that 886 cannot meet their minimum security requirements, SHOULD NOT enter 887 into or continue authentication exchanges that cannot meet their 888 minimum security requirements, and SHOULD verify that completed 889 authentication exchanges result in security services that meet their 890 minimum security requirements. Note that each endpoint needs to 891 independently verify that its security requirements are met. 893 In order to detect downgrade attacks to the least (or less) secure 894 mechanism supported, the client can discover the SASL mechanisms that 895 the server makes available both before the SASL authentication 896 exchange and after the negotiated SASL security layer (with at least 897 data integrity protection) has been installed through the protocol's 898 mechanism discovery facility. If the client finds that the 899 integrity-protected list (the list obtained after the security layer 900 was installed) contains a stronger mechanism than those in the 901 previously obtained list, the client should assume that the 902 previously obtained list was modified by an attacker and SHOULD close 903 the underlying transport connection. 905 The client's initiation of the SASL exchange, including the selection 906 of a SASL mechanism, is done in the clear and may be modified by an 907 active attacker. It is important for any new SASL mechanisms to be 908 designed such that an active attacker cannot obtain an authentication 909 with weaker security properties by modifying the SASL mechanism name 910 and/or the challenges and responses. 912 Multi-level negotiation of security features is prone to downgrade 913 attack. Protocol designers should avoid offering higher-level 914 negotiation of security features in protocols (e.g., above SASL 915 mechanism negotiation) and mechanism designers should avoid 916 lower-level negotiation of security features in mechanisms (e.g., 917 below SASL mechanism negotiation). 919 6.1.3. Replay Attacks 921 Some mechanisms may be subject to replay attacks unless protected by 922 external data security services (e.g., TLS). 924 6.1.4. Truncation Attacks 926 Most existing SASL security layers do not themselves offer protection 927 against truncation attack. In a truncation attack, the active 928 attacker causes the protocol session to be closed, causing a 929 truncation of the possibly integrity-protected data stream that leads 930 to behavior of one or both the protocol peers that inappropriately 931 benefits the attacker. Truncation attacks are fairly easy to defend 932 against in connection-oriented application-level protocols. A 933 protocol can defend against these attacks by ensuring that each 934 information exchange has a clear final result and that each protocol 935 session has a graceful closure mechanism, and that these are 936 integrity protected. 938 6.1.5. Other Active Attacks 940 When use of a security layer is negotiated by the authentication 941 protocol exchange, the receiver SHOULD handle gracefully any 942 protected data buffer larger than the defined/negotiated maximal 943 size. In particular, it MUST NOT blindly allocate the amount of 944 memory specified in the buffer size field, as this might cause the 945 "out of memory" condition. If the receiver detects a large block, it 946 SHOULD close the connection. 948 6.2. Passive Attacks 949 Many mechanisms are subject to various passive attacks, including 950 simple eavesdropping of unprotected credential information as well as 951 online and offline dictionary attacks of protected credential 952 information. 954 6.3. Re-keying 956 The secure or administratively permitted lifetimes of SASL 957 mechanisms' security layers are finite. Cryptographic keys weaken as 958 they are used and as time passes; the more time and/or cipher-text 959 that a cryptanalyst has after the first use of the a key, the easier 960 it is for the cryptanalyst to mount attacks on the key. 962 Administrative limits on a security layer's lifetime may take the 963 form of time limits expressed in X.509 certificates, in Kerberos V 964 tickets, or in directories, and are often desired. In practice, one 965 likely effect of administrative lifetime limits is that applications 966 may find that security layers stop working in the middle of 967 application protocol operation, such as, perhaps, during large data 968 transfers. As the result of this, the connection will be closed (see 969 Section 3.7), which will result in an unpleasant user experience. 971 Re-keying (key renegotiation process) is a way of addressing the 972 weakening of cryptographic keys. The SASL framework does not itself 973 provide for re-keying; SASL mechanisms may. Designers of future SASL 974 mechanisms should consider providing re-keying services. 976 Implementations that wish to re-key SASL security layers where the 977 mechanism does not provide for re-keying SHOULD reauthenticate the 978 same IDs and replace the expired or soon-to-expire security layers. 979 This approach requires support for reauthentication in the 980 application protocols (see Section 3.8). 982 6.4. Other Considerations 984 Protocol designers and implementors should understand the security 985 considerations of mechanisms so they may select mechanisms that are 986 applicable to their needs. 988 Distributed server implementations need to be careful in how they 989 trust other parties. In particular, authentication secrets should 990 only be disclosed to other parties that are trusted to manage and use 991 those secrets in a manner acceptable to the disclosing party. 992 Applications using SASL assume that SASL security layers providing 993 data confidentiality are secure even when an attacker chooses the 994 text to be protected by the security layer. Similarly, applications 995 assume that the SASL security layer is secure even if the attacker 996 can manipulate the cipher-text output of the security layer. New 997 SASL mechanisms are expected to meet these assumptions. 999 Unicode security considerations [UTR36] apply to authorization 1000 identity strings, as well as UTF-8 [RFC3629] security considerations 1001 where UTF-8 is used. SASLprep [RFC4013] and StringPrep [RFC3454] 1002 security considerations also apply where used. 1004 7. IANA Considerations 1006 7.1. SASL Mechanism Registry 1008 The SASL mechanism registry is maintained by IANA. The registry is 1009 currently available at . 1012 The purpose of this registry is not only to ensure uniqueness of 1013 values used to name SASL mechanisms, but also to provide a definitive 1014 reference to technical specifications detailing each SASL mechanism 1015 available for use on the Internet. 1017 There is no naming convention for SASL mechanisms; any name that 1018 conforms to the syntax of a SASL mechanism name can be registered. 1020 The procedure detailed in Section 7.1.1 is to be used for 1021 registration of a value naming a specific individual mechanism. 1023 The procedure detailed in Section 7.1.2 is to be used for 1024 registration of a value naming a family of related mechanisms. 1026 Comments may be included in the registry as discussed in Section 1027 7.1.3 and may be changed as discussed in Section 7.1.4. 1029 The SASL mechanism registry has been updated to reflect that this 1030 document provides the definitive technical specification for SASL and 1031 that this section provides the registration procedures for this 1032 registry. 1034 7.1.1. Mechanism Name Registration Procedure 1036 IANA will register new SASL mechanism names on a First Come First 1037 Served basis, as defined in BCP 26 [RFC5226]. IANA has the right to 1038 reject obviously bogus registration requests, but will perform no 1039 review of claims made in the registration form. 1041 Registration of a SASL mechanism is requested by filling in the 1042 following template: 1044 Subject: Registration of SASL mechanism X 1046 SASL mechanism name (or prefix for the family): 1048 Security considerations: 1050 Published specification (recommended): 1052 Person & email address to contact for further information: 1054 Intended usage: (One of COMMON, LIMITED USE, or OBSOLETE) 1056 Owner/Change controller: 1058 Note: (Any other information that the author deems relevant may be 1059 added here.) 1061 and sending it via electronic mail to IANA at . 1063 While this registration procedure does not require expert review, 1064 authors of SASL mechanisms are encouraged to seek community review 1065 and comment whenever that is feasible. Authors may seek community 1066 review by posting a specification of their proposed mechanism as an 1067 Internet-Draft. SASL mechanisms intended for widespread use should 1068 be standardized through the normal IETF process, when appropriate. 1070 7.1.2. Family Name Registration Procedure 1072 As noted above, there is no general naming convention for SASL 1073 mechanisms. However, specifications may reserve a portion of the 1074 SASL mechanism namespace for a set of related SASL mechanisms, a 1075 "family" of SASL mechanisms. Each family of SASL mechanisms is 1076 identified by a unique prefix, such as X-. Registration of new SASL 1077 mechanism family names requires expert review as defined in BCP 26 1078 [RFC5226]. 1080 Registration of a SASL family name is requested by filling in the 1081 following template: 1083 Subject: Registration of SASL mechanism family X 1085 SASL family name (or prefix for the family): 1087 Security considerations: 1089 Published specification (recommended): 1091 Person & email address to contact for further information: 1093 Intended usage: (One of COMMON, LIMITED USE, or OBSOLETE) 1095 Owner/Change controller: 1097 Note: (Any other information that the author deems relevant may be 1098 added here.) 1100 and sending it via electronic mail to the IETF SASL mailing list at 1101 and carbon copying IANA at . 1102 After allowing two weeks for community input on the IETF SASL mailing 1103 list, the expert will determine the appropriateness of the 1104 registration request and either approve or disapprove the request 1105 with notice to the requestor, the mailing list, and IANA. 1107 The review should focus on the appropriateness of the requested 1108 family name for the proposed use and the appropriateness of the 1109 proposed naming and registration plan for existing and future 1110 mechanism names in the family. The scope of this request review may 1111 entail consideration of relevant aspects of any provided technical 1112 specification, such as their IANA Considerations section. However, 1113 this review is narrowly focused on the appropriateness of the 1114 requested registration and not on the overall soundness of any 1115 provided technical specification. 1117 Authors are encouraged to pursue community review by posting the 1118 technical specification as an Internet-Draft and soliciting comment 1119 by posting to appropriate IETF mailing lists. 1121 7.1.3. Comments on SASL Mechanism Registrations 1123 Comments on a registered SASL mechanism/family should first be sent 1124 to the "owner" of the mechanism/family and/or to the 1125 mailing list. 1127 Submitters of comments may, after a reasonable attempt to contact the 1128 owner, request IANA to attach their comment to the SASL mechanism 1129 registration itself by sending mail to . At IANA's 1130 sole discretion, IANA may attach the comment to the SASL mechanism's 1131 registration. 1133 7.1.4. Change Control 1134 Once a SASL mechanism registration has been published by IANA, the 1135 author may request a change to its definition. The change request 1136 follows the same procedure as the registration request. 1138 The owner of a SASL mechanism may pass responsibility for the SASL 1139 mechanism to another person or agency by informing IANA; this can be 1140 done without discussion or review. 1142 The IESG may reassign responsibility for a SASL mechanism. The most 1143 common case of this will be to enable changes to be made to 1144 mechanisms where the author of the registration has died, has moved 1145 out of contact, or is otherwise unable to make changes that are 1146 important to the community. 1148 SASL mechanism registrations may not be deleted; mechanisms that are 1149 no longer believed appropriate for use can be declared OBSOLETE by a 1150 change to their "intended usage" field; such SASL mechanisms will be 1151 clearly marked in the lists published by IANA. 1153 The IESG is considered to be the owner of all SASL mechanisms that 1154 are on the IETF standards track. 1156 7.2. Registration Changes 1158 The IANA has updated the SASL mechanisms registry as follows: 1160 1) Changed the "Intended usage" of the KERBEROS_V4 and SKEY mechanism 1161 registrations to OBSOLETE. 1163 2) Changed the "Published specification" of the EXTERNAL mechanism to 1164 this document as indicated below: 1166 Subject: Updated Registration of SASL mechanism EXTERNAL 1167 Family of SASL mechanisms: NO 1168 SASL mechanism name: EXTERNAL 1169 Security considerations: See A.3 of RFC 4422 1170 Published specification (optional, recommended): RFC 4422 1171 Person & email address to contact for further information: 1172 Alexey Melnikov 1173 Intended usage: COMMON 1174 Owner/Change controller: IESG 1175 Note: Updates existing entry for EXTERNAL 1177 8. References 1179 8.1. Normative References 1181 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1182 Requirement Levels", BCP 14, RFC 2119, March 1997. 1184 [RFC2743] Linn, J., "Generic Security Service Application Program 1185 Interface Version 2, Update 1", RFC 2743, January 2000. 1187 [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 1188 10646", STD 63, RFC 3629, November 2003. 1190 [RFC4013] Zeilenga, K., "SASLprep: Stringprep Profile for User 1191 Names and Passwords", RFC 4013, February 2005. 1193 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing 1194 an IANA Considerations Section in RFCs", BCP 26, RFC 1195 5226, May 1998. 1197 [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for 1198 Syntax Specifications: ABNF", STD 68, RFC 5234, January 1199 2008. 1201 [ASCII] Coded Character Set--7-bit American Standard Code for 1202 Information Interchange, ANSI X3.4-1986. 1204 [Unicode] The Unicode Consortium, "The Unicode Standard, Version 1205 3.2.0" is defined by "The Unicode Standard, Version 1206 3.0" (Reading, MA, Addison-Wesley, 2000. ISBN 1207 0-201-61633-5), as amended by the "Unicode Standard 1208 Annex #27: Unicode 3.1" 1209 (http://www.unicode.org/reports/tr27/) and by the 1210 "Unicode Standard Annex #28: Unicode 3.2" 1211 (http://www.unicode.org/reports/tr28/). 1213 [CharModel] Whistler, K. and M. Davis, "Unicode Technical Report 1214 #17, Character Encoding Model", UTR17, 1215 , August 1216 2000. 1218 8.2. Informative References 1220 [RFC2244] Newman, C. and J. G. Myers, "ACAP -- Application 1221 Configuration Access Protocol", RFC 2244, November 1222 1997. 1224 [RFC3206] Gellens, R., "The SYS and AUTH POP Response Codes", RFC 1225 3206, February 2002. 1227 [RFC3454] Hoffman, P. and M. Blanchet, "Preparation of 1228 Internationalized Strings ("stringprep")", RFC 3454, 1229 December 2002. 1231 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the 1232 Internet Protocol", RFC 4301, December 2005. 1234 [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data 1235 Encodings", RFC 4648, October 2006. 1237 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer 1238 Security (TLS) Protocol Version 1.2", RFC 5246, August 1239 2008. 1241 [UTR36] Davis, M. and Michel Suignard, "Unicode Technical 1242 Report #36, Unicode Security Considerations", UTR36, 1243 , July 1244 2008. 1246 [Glossary] The Unicode Consortium, "Unicode Glossary", 1247 . 1249 9. Acknowledgements 1251 This document is a revision of RFC 4422, a product of the IETF Simple 1252 Authentication and Security Layer (SASL) Working Group. RFC 4422 was 1253 a revision of RFC 2222 by John Myers. 1255 This revision is also a product of the IETF SASL Working Group. 1257 The following individuals contributed significantly to this revision: 1258 TBD 1260 Appendix A. The SASL EXTERNAL Mechanism 1262 This appendix is normative. 1264 The EXTERNAL mechanism allows a client to request the server to use 1265 credentials established by means external to the mechanism to 1266 authenticate the client. The external means may be, for instance, IP 1267 Security [RFC4301] or TLS [RFC5246] services. In absence of some a 1268 priori agreement between the client and the server, the client cannot 1269 make any assumption as to what external means the server has used to 1270 obtain the client's credentials, nor make an assumption as to the 1271 form of credentials. For example, the client cannot assume that the 1272 server will use the credentials the client has established via TLS. 1274 A.1. EXTERNAL Technical Specification 1276 The name of this mechanism is "EXTERNAL". 1278 The mechanism does not provide a security layer. 1280 The mechanism is capable of transferring an authorization identity 1281 string. If empty, the client is requesting to act as the identity 1282 the server has associated with the client's credentials. If non- 1283 empty, the client is requesting to act as the identity represented by 1284 the string. 1286 The client is expected to send data first in the authentication 1287 exchange. Where the client does not provide an initial response data 1288 in its request to initiate the authentication exchange, the server is 1289 to respond to the request with an empty initial challenge and then 1290 the client is to provide its initial response. 1292 The client sends the initial response containing the UTF-8 [RFC3629] 1293 encoding of the requested authorization identity string. This 1294 response is non-empty when the client is requesting to act as the 1295 identity represented by the (non-empty) string. This response is 1296 empty when the client is requesting to act as the identity the server 1297 associated with its authentication credentials. 1299 The syntax of the initial response is specified as a value of the 1300 production detailed below using the Augmented 1301 Backus-Naur Form (ABNF) [RFC5234] notation. 1303 external-initial-resp = authz-id-string 1304 authz-id-string = *( UTF8-char-no-nul ) 1305 UTF8-char-no-nul = UTF8-1-no-nul / UTF8-2 / UTF8-3 / UTF8-4 1306 UTF8-1-no-nul = %x01-7F 1308 where the , , and productions are as defined 1309 in [RFC3629]. 1311 There are no additional challenges and responses. 1313 Hence, the server is to return the outcome of the authentication 1314 exchange. 1316 The exchange fails if 1318 - the client has not established its credentials via external means, 1320 - the client's credentials are inadequate, 1322 - the client provided an empty authorization identity string and the 1323 server is unwilling or unable to associate an authorization 1324 identity with the client's credentials, 1326 - the client provided a non-empty authorization identity string that 1327 is invalid per the syntax requirements of the applicable 1328 application protocol specification, 1330 - the client provided a non-empty authorization identity string 1331 representing an identity that the client is not allowed to act as, 1332 or 1334 - the server is unwilling or unable to provide service to the client 1335 for any other reason. 1337 Otherwise the exchange is successful. When indicating a successful 1338 outcome, additional data is not provided. 1340 A.2. SASL EXTERNAL Examples 1342 This section provides examples of EXTERNAL authentication exchanges. 1343 The examples are intended to help the readers understand the above 1344 text. The examples are not definitive. The Application 1345 Configuration Access Protocol (ACAP) [RFC2244] is used in the 1346 examples. 1348 The first example shows use of EXTERNAL with an empty authorization 1349 identity. In this example, the initial response is not sent in the 1350 client's request to initiate the authentication exchange. 1352 S: * ACAP (SASL "GSSAPI") 1353 C: a001 STARTTLS 1354 S: a001 OK "Begin TLS negotiation now" 1355 1356 S: * ACAP (SASL "GSSAPI" "EXTERNAL") 1357 C: a002 AUTHENTICATE "EXTERNAL" 1358 S: + "" 1359 C: + "" 1360 S: a002 OK "Authenticated" 1362 The second example shows use of EXTERNAL with an authorization 1363 identity of "fred@example.com". In this example, the initial 1364 response is sent with the client's request to initiate the 1365 authentication exchange. This saves a round-trip. 1367 S: * ACAP (SASL "GSSAPI") 1368 C: a001 STARTTLS 1369 S: a001 OK "Begin TLS negotiation now" 1370 1371 S: * ACAP (SASL "GSSAPI" "EXTERNAL") 1372 C: a002 AUTHENTICATE "EXTERNAL" {16+} 1373 C: fred@example.com 1374 S: a002 NO "Cannot assume requested authorization identity" 1376 A.3. Security Considerations 1378 The EXTERNAL mechanism provides no security protection; it is 1379 vulnerable to spoofing by either client or server, active attack, and 1380 eavesdropping. It should only be used when adequate security 1381 services have been established. 1383 Appendix B. Changes since RFC 4422 1385 This appendix is non-normative. 1387 The following is a summary of the changes were made: 1389 - References updated and corrected. 1391 Editors' Addresses 1393 Alexey Melnikov 1394 Isode Limited 1395 5 Castle Business Village 1396 36 Station Road 1397 Hampton, Middlesex TW12 2BX 1398 UK 1400 EMail: Alexey.Melnikov@isode.com 1401 Kurt D. Zeilenga 1402 Isode Limited 1404 EMail: Kurt.Zeilenga@isode.com 1406 Full Copyright 1408 Copyright (c) 2009 IETF Trust and the persons identified as the 1409 document authors. All rights reserved. 1411 This document is subject to BCP 78 and the IETF Trust's Legal 1412 Provisions Relating to IETF Documents in effect on the date of 1413 publication of this document (http://trustee.ietf.org/license-info). 1414 Please review these documents carefully, as they describe your rights 1415 and restrictions with respect to this document. 1417 This document may contain material from IETF Documents or IETF 1418 Contributions published or made publicly available before November 10, 1419 2008. The person(s) controlling the copyright in some of this material 1420 may not have granted the IETF Trust the right to allow modifications 1421 of such material outside the IETF Standards Process. Without 1422 obtaining an adequate license from the person(s) controlling the 1423 copyright in such materials, this document may not be modified outside 1424 the IETF Standards Process, and derivative works of it may not be 1425 created outside the IETF Standards Process, except to format it for 1426 publication as an RFC or to translate it into languages other than 1427 English.