1 2 3 4 5 6 7Network Working Group A. Melnikov, Ed. 8Request for Comments: 4422 Isode Limited 9Obsoletes: 2222 K. Zeilenga, Ed. 10Category: Standards Track OpenLDAP Foundation 11 June 2006 12 13 14 Simple Authentication and Security Layer (SASL) 15 16Status of This Memo 17 18 This document specifies an Internet standards track protocol for the 19 Internet community, and requests discussion and suggestions for 20 improvements. Please refer to the current edition of the "Internet 21 Official Protocol Standards" (STD 1) for the standardization state 22 and status of this protocol. Distribution of this memo is unlimited. 23 24Copyright Notice 25 26 Copyright (C) The Internet Society (2006). 27 28Abstract 29 30 The Simple Authentication and Security Layer (SASL) is a framework 31 for providing authentication and data security services in 32 connection-oriented protocols via replaceable mechanisms. It 33 provides a structured interface between protocols and mechanisms. 34 The resulting framework allows new protocols to reuse existing 35 mechanisms and allows old protocols to make use of new mechanisms. 36 The framework also provides a protocol for securing subsequent 37 protocol exchanges within a data security layer. 38 39 This document describes how a SASL mechanism is structured, describes 40 how protocols include support for SASL, and defines the protocol for 41 carrying a data security layer over a connection. In addition, this 42 document defines one SASL mechanism, the EXTERNAL mechanism. 43 44 This document obsoletes RFC 2222. 45 46 47 48 49 50 51 52 53 54 55 56 57 58Melnikov & Zeilenga Standards Track [Page 1] 59 60RFC 4422 SASL June 2006 61 62 63Table of Contents 64 65 1. Introduction ....................................................3 66 1.1. Document Audiences .........................................4 67 1.2. Relationship to Other Documents ............................4 68 1.3. Conventions ................................................5 69 2. Identity Concepts ...............................................5 70 3. The Authentication Exchange .....................................6 71 3.1. Mechanism Naming ...........................................8 72 3.2. Mechanism Negotiation ......................................9 73 3.3. Request Authentication Exchange ............................9 74 3.4. Challenges and Responses ...................................9 75 3.4.1. Authorization Identity String ......................10 76 3.5. Aborting Authentication Exchanges .........................10 77 3.6. Authentication Outcome ....................................11 78 3.7. Security Layers ...........................................12 79 3.8. Multiple Authentications ..................................12 80 4. Protocol Requirements ..........................................13 81 5. Mechanism Requirements .........................................16 82 6. Security Considerations ........................................18 83 6.1. Active Attacks ............................................19 84 6.1.1. Hijack Attacks .....................................19 85 6.1.2. Downgrade Attacks ..................................19 86 6.1.3. Replay Attacks .....................................20 87 6.1.4. Truncation Attacks .................................20 88 6.1.5. Other Active Attacks ...............................20 89 6.2. Passive Attacks ...........................................20 90 6.3. Re-keying .................................................21 91 6.4. Other Considerations ......................................21 92 7. IANA Considerations ............................................22 93 7.1. SASL Mechanism Registry ...................................22 94 7.2. Registration Changes ......................................26 95 8. References .....................................................26 96 8.1. Normative References ......................................26 97 8.2. Informative References ....................................27 98 9. Acknowledgements ...............................................28 99 Appendix A. The SASL EXTERNAL Mechanism ..........................29 100 A.1. EXTERNAL Technical Specification ..........................29 101 A.2. SASL EXTERNAL Examples ....................................30 102 A.3. Security Considerations ...................................31 103 Appendix B. Changes since RFC 2222 ...............................31 104 105 106 107 108 109 110 111 112 113 114Melnikov & Zeilenga Standards Track [Page 2] 115 116RFC 4422 SASL June 2006 117 118 1191. Introduction 120 121 The Simple Authentication and Security Layer (SASL) is a framework 122 for providing authentication and data security services in 123 connection-oriented protocols via replaceable mechanisms. SASL 124 provides a structured interface between protocols and mechanisms. 125 SASL also provides a protocol for securing subsequent protocol 126 exchanges within a data security layer. The data security layer can 127 provide data integrity, data confidentiality, and other services. 128 129 SASL's design is intended to allow new protocols to reuse existing 130 mechanisms without requiring redesign of the mechanisms and allows 131 existing protocols to make use of new mechanisms without redesign of 132 protocols. 133 134 SASL is conceptually a framework that provides an abstraction layer 135 between protocols and mechanisms as illustrated in the following 136 diagram. 137 138 SMTP LDAP XMPP Other protocols ... 139 \ | | / 140 \ | | / 141 SASL abstraction layer 142 / | | \ 143 / | | \ 144 EXTERNAL GSSAPI PLAIN Other mechanisms ... 145 146 It is through the interfaces of this abstraction layer that the 147 framework allows any protocol to utilize any mechanism. While this 148 layer does generally hide the particulars of protocols from 149 mechanisms and the particulars of mechanisms from protocols, this 150 layer does not generally hide the particulars of mechanisms from 151 protocol implementations. For example, different mechanisms require 152 different information to operate, some of them use password-based 153 authentication, some of then require realm information, others make 154 use of Kerberos tickets, certificates, etc. Also, in order to 155 perform authorization, server implementations generally have to 156 implement identity mapping between authentication identities, whose 157 form is mechanism specific, and authorization identities, whose form 158 is application protocol specific. Section 2 discusses identity 159 concepts. 160 161 It is possible to design and implement this framework in ways that do 162 abstract away particulars of similar mechanisms. Such a framework 163 implementation, as well as mechanisms implementations, could be 164 designed not only to be shared by multiple implementations of a 165 particular protocol but to be shared by implementations of multiple 166 protocols. 167 168 169 170Melnikov & Zeilenga Standards Track [Page 3] 171 172RFC 4422 SASL June 2006 173 174 175 The framework incorporates interfaces with both protocols and 176 mechanisms in which authentication exchanges are carried out. 177 Section 3 discusses SASL authentication exchanges. 178 179 To use SASL, each protocol (amongst other items) provides a method 180 for identifying which mechanism is to be used, a method for exchange 181 of mechanism-specific server-challenges and client-responses, and a 182 method for communicating the outcome of the authentication exchange. 183 Section 4 discusses SASL protocol requirements. 184 185 Each SASL mechanism defines (amongst other items) a series of 186 server-challenges and client-responses that provide authentication 187 services and negotiate data security services. Section 5 discusses 188 SASL mechanism requirements. 189 190 Section 6 discusses security considerations. Section 7 discusses 191 IANA considerations. Appendix A defines the SASL EXTERNAL mechanism. 192 1931.1. Document Audiences 194 195 This document is written to serve several different audiences: 196 197 - protocol designers using this specification to support 198 authentication in their protocol, 199 200 - mechanism designers that define new SASL mechanisms, and 201 202 - implementors of clients or servers for those protocols that 203 support SASL. 204 205 While the document organization is intended to allow readers to focus 206 on details relevant to their engineering, readers are encouraged to 207 read and understand all aspects of this document. 208 2091.2. Relationship to Other Documents 210 211 This document obsoletes RFC 2222. It replaces all portions of RFC 212 2222 excepting sections 7.1 (the KERBEROS_IV mechanism), 7.2 (the 213 GSSAPI mechanism), 7.3 (the SKEY mechanism). The KERBEROS_IV and 214 SKEY mechanisms are now viewed as obsolete and their specifications 215 provided in RFC 2222 are Historic. The GSSAPI mechanism is now 216 separately specified [SASL-GSSAPI]. 217 218 Appendix B provides a summary of changes since RFC 2222. 219 220 221 222 223 224 225 226Melnikov & Zeilenga Standards Track [Page 4] 227 228RFC 4422 SASL June 2006 229 230 2311.3. Conventions 232 233 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 234 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 235 document are to be interpreted as described in BCP 14 [RFC2119]. 236 237 Character names in this document use the notation for code points and 238 names from the Unicode Standard [Unicode]. For example, the letter 239 "a" may be represented as either <U+0061> or <LATIN SMALL LETTER A>. 240 241 Note: a glossary of terms used in Unicode can be found in [Glossary]. 242 Information on the Unicode character encoding model can be found in 243 [CharModel]. 244 245 In examples, "C:" and "S:" indicate lines of data to be sent by the 246 client and server, respectively. Lines have been wrapped for 247 improved readability. 248 2492. Identity Concepts 250 251 In practice, authentication and authorization may involve multiple 252 identities, possibly in different forms (simple username, Kerberos 253 principal, X.500 Distinguished Name, etc.), possibly with different 254 representations (e.g., ABNF-described UTF-8 encoded Unicode character 255 string, BER-encoded Distinguished Name). While technical 256 specifications often prescribe both the identity form and 257 representation used on the network, different identity forms and/or 258 representations may be (and often are) used within implementations. 259 How identities of different forms relate to each other is, generally, 260 a local matter. In addition, the forms and representations used 261 within an implementation are a local matter. 262 263 However, conceptually, the SASL framework involves two identities: 264 265 1) an identity associated with the authentication credentials 266 (termed the authentication identity), and 267 268 2) an identity to act as (termed the authorization identity). 269 270 SASL mechanism specifications describe the credential form(s) (e.g., 271 X.509 certificates, Kerberos tickets, simple username/password) used 272 to authenticate the client, including (where appropriate) the syntax 273 and semantics of authentication identities carried in the 274 credentials. SASL protocol specifications describe the identity 275 form(s) used in authorization and, in particular, prescribe the 276 syntax and semantics of the authorization identity character string 277 to be transferred by mechanisms. 278 279 280 281 282Melnikov & Zeilenga Standards Track [Page 5] 283 284RFC 4422 SASL June 2006 285 286 287 The client provides its credentials (which include or imply an 288 authentication identity) and, optionally, a character string 289 representing the requested authorization identity as part of the SASL 290 exchange. When this character string is omitted or empty, the client 291 is requesting to act as the identity associated with the credentials 292 (e.g., the user is requesting to act as the authentication identity). 293 294 The server is responsible for verifying the client's credentials and 295 verifying that the identity it associates with the client's 296 credentials (e.g., the authentication identity) is allowed to act as 297 the authorization identity. A SASL exchange fails if either (or 298 both) of these verifications fails. (The SASL exchange may fail for 299 other reasons, such as service authorization failure.) 300 301 However, the precise form(s) of the authentication identities (used 302 within the server in its verifications, or otherwise) and the precise 303 form(s) of the authorization identities (used in making authorization 304 decisions, or otherwise) are beyond the scope of SASL and this 305 specification. In some circumstances, the precise identity forms 306 used in some context outside of the SASL exchange may be dictated by 307 other specifications. For instance, an identity assumption 308 authorization (proxy authorization) policy specification may dictate 309 how authentication and authorization identities are represented in 310 policy statements. 311 3123. The Authentication Exchange 313 314 Each authentication exchange consists of a message from the client to 315 the server requesting authentication via a particular mechanism, 316 followed by one or more pairs of challenges from the server and 317 responses from the client, followed by a message from the server 318 indicating the outcome of the authentication exchange. (Note: 319 exchanges may also be aborted as discussed in Section 3.5.) 320 321 The following illustration provides a high-level overview of an 322 authentication exchange. 323 324 C: Request authentication exchange 325 S: Initial challenge 326 C: Initial response 327 <additional challenge/response messages> 328 S: Outcome of authentication exchange 329 330 If the outcome is successful and a security layer was negotiated, 331 this layer is then installed (see Section 3.7). This also applies to 332 the following illustrations. 333 334 335 336 337 338Melnikov & Zeilenga Standards Track [Page 6] 339 340RFC 4422 SASL June 2006 341 342 343 Some mechanisms specify that the first data sent in the 344 authentication exchange is from the client to the server. Protocols 345 may provide an optional initial response field in the request message 346 to carry this data. Where the mechanism specifies that the first 347 data sent in the exchange is from the client to the server, the 348 protocol provides an optional initial response field, and the client 349 uses this field, the exchange is shortened by one round-trip: 350 351 C: Request authentication exchange + Initial response 352 <additional challenge/response messages> 353 S: Outcome of authentication exchange 354 355 Where the mechanism specifies that the first data sent in the 356 exchange is from the client to the server and this field is 357 unavailable or unused, the client request is followed by an empty 358 challenge. 359 360 C: Request authentication exchange 361 S: Empty Challenge 362 C: Initial Response 363 <additional challenge/response messages> 364 S: Outcome of authentication exchange 365 366 Should a client include an initial response in its request where the 367 mechanism does not allow the client to send data first, the 368 authentication exchange fails. 369 370 Some mechanisms specify that the server is to send additional data to 371 the client when indicating a successful outcome. Protocols may 372 provide an optional additional data field in the outcome message to 373 carry this data. Where the mechanism specifies that the server is to 374 return additional data with the successful outcome, the protocol 375 provides an optional additional data field in the outcome message, 376 and the server uses this field, the exchange is shortened by one 377 round-trip: 378 379 C: Request authentication exchange 380 S: Initial challenge 381 C: Initial response 382 <additional challenge/response messages> 383 S: Outcome of authentication exchange with 384 additional data with success 385 386 Where the mechanism specifies that the server is to return additional 387 data to the client with a successful outcome and this field is 388 unavailable or unused, the additional data is sent as a challenge 389 whose response is empty. After receiving this response, the server 390 then indicates the successful outcome. 391 392 393 394Melnikov & Zeilenga Standards Track [Page 7] 395 396RFC 4422 SASL June 2006 397 398 399 C: Request authentication exchange 400 S: Initial challenge 401 C: Initial response 402 <additional challenge/response messages> 403 S: Additional data challenge 404 C: Empty Response 405 S: Outcome of authentication exchange 406 407 Where mechanisms specify that the first data sent in the exchange is 408 from the client to the server and additional data is sent to the 409 client along with indicating a successful outcome, and the protocol 410 provides fields supporting both, then the exchange takes two fewer 411 round-trips: 412 413 C: Request authentication exchange + Initial response 414 <additional challenge/response messages> 415 S: Outcome of authentication exchange 416 with additional data with success 417 418 instead of: 419 420 C: Request authentication exchange 421 S: Empty Challenge 422 C: Initial Response 423 <additional challenge/response messages> 424 S: Additional data challenge 425 C: Empty Response 426 S: Outcome of authentication exchange 427 4283.1. Mechanism Naming 429 430 SASL mechanisms are named by character strings, from 1 to 20 431 characters in length, consisting of ASCII [ASCII] uppercase letters, 432 digits, hyphens, and/or underscores. In the following Augmented 433 Backus-Naur Form (ABNF) [RFC4234] grammar, the <sasl-mech> production 434 defines the syntax of a SASL mechanism name. 435 436 sasl-mech = 1*20mech-char 437 mech-char = UPPER-ALPHA / DIGIT / HYPHEN / UNDERSCORE 438 ; mech-char is restricted to A-Z (uppercase only), 0-9, -, and _ 439 ; from ASCII character set. 440 441 UPPER-ALPHA = %x41-5A ; A-Z (uppercase only) 442 DIGIT = %x30-39 ; 0-9 443 HYPHEN = %x2D ; hyphen (-) 444 UNDERSCORE = %x5F ; underscore (_) 445 446 SASL mechanism names are registered as discussed in Section 7.1. 447 448 449 450Melnikov & Zeilenga Standards Track [Page 8] 451 452RFC 4422 SASL June 2006 453 454 4553.2. Mechanism Negotiation 456 457 Mechanism negotiation is protocol specific. 458 459 Commonly, a protocol will specify that the server advertises 460 supported and available mechanisms to the client via some facility 461 provided by the protocol, and the client will then select the "best" 462 mechanism from this list that it supports and finds suitable. 463 464 Note that the mechanism negotiation is not protected by the 465 subsequent authentication exchange and hence is subject to downgrade 466 attacks if not protected by other means. 467 468 To detect downgrade attacks, a protocol can allow the client to 469 discover available mechanisms subsequent to the authentication 470 exchange and installation of data security layers with at least data 471 integrity protection. This allows the client to detect changes to 472 the list of mechanisms supported by the server. 473 4743.3. Request Authentication Exchange 475 476 The authentication exchange is initiated by the client by requesting 477 authentication via a mechanism it specifies. The client sends a 478 message that contains the name of the mechanism to the server. The 479 particulars of the message are protocol specific. 480 481 Note that the name of the mechanism is not protected by the 482 mechanism, and hence is subject to alteration by an attacker if not 483 integrity protected by other means. 484 485 Where the mechanism is defined to allow the client to send data 486 first, and the protocol's request message includes an optional 487 initial response field, the client may include the response to the 488 initial challenge in the authentication request message. 489 4903.4. Challenges and Responses 491 492 The authentication exchange involves one or more pairs of server- 493 challenges and client-responses, the particulars of which are 494 mechanism specific. These challenges and responses are enclosed in 495 protocol messages, the particulars of which are protocol specific. 496 497 Through these challenges and responses, the mechanism may: 498 499 - authenticate the client to the server, 500 501 - authenticate the server to the client, 502 503 504 505 506Melnikov & Zeilenga Standards Track [Page 9] 507 508RFC 4422 SASL June 2006 509 510 511 - transfer an authorization identity string, 512 513 - negotiate a security layer, and 514 515 - provide other services. 516 517 The negotiation of the security layer may involve negotiation of the 518 security services to be provided in the layer, how these services 519 will be provided, and negotiation of a maximum cipher-text buffer 520 size each side is able to receive in the layer (see Section 3.6). 521 522 After receiving an authentication request or any client response, the 523 server may issue a challenge, abort the exchange, or indicate the 524 outcome of an exchange. After receiving a challenge, a client 525 mechanism may issue a response or abort the exchange. 526 5273.4.1. Authorization Identity String 528 529 The authorization identity string is a sequence of zero or more 530 Unicode [Unicode] characters, excluding the NUL (U+0000) character, 531 representing the identity to act as. 532 533 If the authorization identity string is absent, the client is 534 requesting to act as the identity the server associates with the 535 client's credentials. An empty string is equivalent to an absent 536 authorization identity. 537 538 A non-empty authorization identity string indicates that the client 539 wishes to act as the identity represented by the string. In this 540 case, the form of identity represented by the string, as well as the 541 precise syntax and semantics of the string, is protocol specific. 542 543 While the character encoding schema used to transfer the 544 authorization identity string in the authentication exchange is 545 mechanism specific, mechanisms are expected to be capable of carrying 546 the entire Unicode repertoire (with the exception of the NUL 547 character). 548 5493.5. Aborting Authentication Exchanges 550 551 A client or server may desire to abort an authentication exchange if 552 it is unwilling or unable to continue (or enter into). 553 554 A client may abort the authentication exchange by sending a message, 555 the particulars of which are protocol specific, to the server, 556 indicating that the exchange is aborted. The server may be required 557 by the protocol to return a message in response to the client's abort 558 message. 559 560 561 562Melnikov & Zeilenga Standards Track [Page 10] 563 564RFC 4422 SASL June 2006 565 566 567 Likewise, a server may abort the authentication exchange by sending a 568 message, the particulars of which are protocol specific, to the 569 client, indicating that the exchange is aborted. 570 5713.6. Authentication Outcome 572 573 At the conclusion of the authentication exchange, the server sends a 574 message, the particulars of which are protocol specific, to the 575 client indicating the outcome of the exchange. 576 577 The outcome is not successful if 578 579 - the authentication exchange failed for any reason, 580 581 - the client's credentials could not be verified, 582 583 - the server cannot associate an identity with the client's 584 credentials, 585 586 - the client-provided authorization identity string is malformed, 587 588 - the identity associated with the client's credentials is not 589 authorized to act as the requested authorization identity, 590 591 - the negotiated security layer (or lack thereof) is not 592 suitable, or 593 594 - the server is not willing to provide service to the client for 595 any reason. 596 597 The protocol may include an optional additional data field in this 598 outcome message. This field can only include additional data when 599 the outcome is successful. 600 601 If the outcome is successful and a security layer was negotiated, 602 this layer is then installed. If the outcome is unsuccessful, or a 603 security layer was not negotiated, any existing security is left in 604 place. 605 606 The outcome message provided by the server can provide a way for the 607 client to distinguish between errors that are best dealt with by re- 608 prompting the user for her credentials, errors that are best dealt 609 with by telling the user to try again later, and errors where the 610 user must contact a system administrator for resolution (see the SYS 611 and AUTH POP Response Codes [RFC3206] specification for an example). 612 This distinction is particularly useful during scheduled server 613 maintenance periods as it reduces support costs. It is also 614 important that the server can be configured such that the outcome 615 616 617 618Melnikov & Zeilenga Standards Track [Page 11] 619 620RFC 4422 SASL June 2006 621 622 623 message will not distinguish between a valid user with invalid 624 credentials and an invalid user. 625 6263.7. Security Layers 627 628 SASL mechanisms may offer a wide range of services in security 629 layers. Typical services include data integrity and data 630 confidentiality. SASL mechanisms that do not provide a security 631 layer are treated as negotiating no security layer. 632 633 If use of a security layer is negotiated in the authentication 634 protocol exchange, the layer is installed by the server after 635 indicating the outcome of the authentication exchange and installed 636 by the client upon receipt of the outcome indication. In both cases, 637 the layer is installed before transfer of further protocol data. The 638 precise position upon which the layer takes effect in the protocol 639 data stream is protocol specific. 640 641 Once the security layer is in effect in the protocol data stream, it 642 remains in effect until either a subsequently negotiated security 643 layer is installed or the underlying transport connection is closed. 644 645 When in effect, the security layer processes protocol data into 646 buffers of protected data. If at any time the security layer is 647 unable or unwilling to continue producing buffers protecting protocol 648 data, the underlying transport connection MUST be closed. If the 649 security layer is not able to decode a received buffer, the 650 underlying connection MUST be closed. In both cases, the underlying 651 transport connection SHOULD be closed gracefully. 652 653 Each buffer of protected data is transferred over the underlying 654 transport connection as a sequence of octets prepended with a four- 655 octet field in network byte order that represents the length of the 656 buffer. The length of the protected data buffer MUST be no larger 657 than the maximum size that the other side expects. Upon the receipt 658 of a length field whose value is greater than the maximum size, the 659 receiver SHOULD close the connection, as this might be a sign of an 660 attack. 661 662 The maximum size that each side expects is fixed by the mechanism, 663 either through negotiation or by its specification. 664 6653.8. Multiple Authentications 666 667 Unless explicitly permitted in the protocol (as stated in the 668 protocol's technical specification), only one successful SASL 669 authentication exchange may occur in a protocol session. In this 670 671 672 673 674Melnikov & Zeilenga Standards Track [Page 12] 675 676RFC 4422 SASL June 2006 677 678 679 case, once an authentication exchange has successfully completed, 680 further attempts to initiate an authentication exchange fail. 681 682 Where multiple successful SASL authentication exchanges are permitted 683 in the protocol, then in no case may multiple SASL security layers be 684 simultaneously in effect. If a security layer is in effect and a 685 subsequent SASL negotiation selects a second security layer, then the 686 second security layer replaces the first. If a security layer is in 687 effect and a subsequent SASL negotiation selects no security layer, 688 the original security layer remains in effect. 689 690 Where multiple successful SASL negotiations are permitted in the 691 protocol, the effect of a failed SASL authentication exchange upon 692 the previously established authentication and authorization state is 693 protocol specific. The protocol's technical specification should be 694 consulted to determine whether the previous authentication and 695 authorization state remains in force, or changed to an anonymous 696 state, or otherwise was affected. Regardless of the protocol- 697 specific effect upon previously established authentication and 698 authorization state, the previously negotiated security layer remains 699 in effect. 700 7014. Protocol Requirements 702 703 In order for a protocol to offer SASL services, its specification 704 MUST supply the following information: 705 706 1) A service name, to be selected from registry of "service" elements 707 for the Generic Security Service Application Program Interface 708 (GSSAPI) host-based service name form, as described in Section 4.1 709 of [RFC2743]. Note that this registry is shared by all GSSAPI and 710 SASL mechanisms. 711 712 2) Detail any mechanism negotiation facility that the protocol 713 provides (see Section 3.2). 714 715 A protocol SHOULD specify a facility through which the client may 716 discover, both before initiation of the SASL exchange and after 717 installing security layers negotiated by the exchange, the names 718 of the SASL mechanisms that the server makes available to the 719 client. The latter is important to allow the client to detect 720 downgrade attacks. This facility is typically provided through 721 the protocol's extensions or capabilities discovery facility. 722 723 3) Definition of the messages necessary for authentication exchange, 724 including the following: 725 726 727 728 729 730Melnikov & Zeilenga Standards Track [Page 13] 731 732RFC 4422 SASL June 2006 733 734 735 a) A message to initiate the authentication exchange (see Section 736 3.3). 737 738 This message MUST contain a field for carrying the name of the 739 mechanism selected by the client. 740 741 This message SHOULD contain an optional field for carrying an 742 initial response. If the message is defined with this field, 743 the specification MUST describe how messages with an empty 744 initial response are distinguished from messages with no 745 initial response. This field MUST be capable of carrying 746 arbitrary sequences of octets (including zero-length sequences 747 and sequences containing zero-valued octets). 748 749 b) Messages to transfer server challenges and client responses 750 (see Section 3.4). 751 752 Each of these messages MUST be capable of carrying arbitrary 753 sequences of octets (including zero-length sequences and 754 sequences containing zero-valued octets). 755 756 c) A message to indicate the outcome of the authentication 757 exchange (see Section 3.6). 758 759 This message SHOULD contain an optional field for carrying 760 additional data with a successful outcome. If the message is 761 defined with this field, the specification MUST describe how 762 messages with an empty additional data are distinguished from 763 messages with no additional data. This field MUST be capable 764 of carrying arbitrary sequences of octets (including zero- 765 length sequences and sequences containing zero-valued octets). 766 767 4) Prescribe the syntax and semantics of non-empty authorization 768 identity strings (see Section 3.4.1). 769 770 In order to avoid interoperability problems due to differing 771 normalizations, the protocol specification MUST detail precisely 772 how and where (client or server) non-empty authorization identity 773 strings are prepared, including all normalizations, for comparison 774 and other applicable functions to ensure proper function. 775 776 Specifications are encouraged to prescribe use of existing 777 authorization identity forms as well as existing string 778 representations, such as simple user names [RFC4013]. 779 780 Where the specification does not precisely prescribe how 781 identities in SASL relate to identities used elsewhere in the 782 protocol, for instance, in access control policy statements, it 783 784 785 786Melnikov & Zeilenga Standards Track [Page 14] 787 788RFC 4422 SASL June 2006 789 790 791 may be appropriate for the protocol to provide a facility by which 792 the client can discover information (such as the representation of 793 the identity used in making access control decisions) about 794 established identities for these uses. 795 796 5) Detail any facility the protocol provides that allows the client 797 and/or server to abort authentication exchange (see Section 3.5). 798 799 Protocols that support multiple authentications typically allow a 800 client to abort an ongoing authentication exchange by initiating a 801 new authentication exchange. Protocols that do not support 802 multiple authentications may require the client to close the 803 connection and start over to abort an ongoing authentication 804 exchange. 805 806 Protocols typically allow the server to abort ongoing 807 authentication exchanges by returning a non-successful outcome 808 message. 809 810 6) Identify precisely where newly negotiated security layers start to 811 take effect, in both directions (see Section 3.7). 812 813 Typically, specifications require security layers to start taking 814 effect on the first octet following the outcome message in data 815 being sent by the server and on the first octet sent after receipt 816 of the outcome message in data being sent by the client. 817 818 7) If the protocol supports other layered security services, such as 819 Transport Layer Security (TLS) [RFC4346], the specification MUST 820 prescribe the order in which security layers are applied to 821 protocol data. 822 823 For instance, where a protocol supports both TLS and SASL security 824 layers, the specification could prescribe any of the following: 825 826 a) SASL security layer is always applied first to data being sent 827 and, hence, applied last to received data, 828 829 b) SASL security layer is always applied last to data being sent 830 and, hence, applied first to received data, 831 832 c) Layers are applied in the order in which they were installed, 833 834 d) Layers are applied in the reverse order in which they were 835 installed, or 836 837 e) Both TLS and SASL security layers cannot be installed. 838 839 840 841 842Melnikov & Zeilenga Standards Track [Page 15] 843 844RFC 4422 SASL June 2006 845 846 847 8) Indicate whether the protocol supports multiple authentications 848 (see Section 3.8). If so, the protocol MUST detail the effect a 849 failed SASL authentication exchange will have upon a previously 850 established authentication and authorization state. 851 852 Protocol specifications SHOULD avoid stating implementation 853 requirements that would hinder replacement of applicable mechanisms. 854 In general, protocol specifications SHOULD be mechanism neutral. 855 There are a number of reasonable exceptions to this recommendation, 856 including 857 858 - detailing how credentials (which are mechanism specific) are 859 managed in the protocol, 860 861 - detailing how authentication identities (which are mechanism 862 specific) and authorization identities (which are protocol 863 specific) relate to each other, and 864 865 - detailing which mechanisms are applicable to the protocol. 866 8675. Mechanism Requirements 868 869 SASL mechanism specifications MUST supply the following information: 870 871 1) The name of the mechanism (see Section 3.1). This name MUST be 872 registered as discussed in Section 7.1. 873 874 2) A definition of the server-challenges and client-responses of the 875 authentication exchange, as well as the following: 876 877 a) An indication of whether the mechanism is client-first, 878 variable, or server-first. If a SASL mechanism is defined as 879 client-first and the client does not send an initial response 880 in the authentication request, then the first server challenge 881 MUST be empty (the EXTERNAL mechanism is an example of this 882 case). If a SASL mechanism is defined as variable, then the 883 specification needs to state how the server behaves when the 884 initial client response in the authentication request is 885 omitted (the DIGEST-MD5 mechanism [DIGEST-MD5] is an example of 886 this case). If a SASL mechanism is defined as server-first, 887 then the client MUST NOT send an initial client response in the 888 authentication request (the CRAM-MD5 mechanism [CRAM-MD5] is an 889 example of this case). 890 891 b) An indication of whether the server is expected to provide 892 additional data when indicating a successful outcome. If so, 893 if the server sends the additional data as a challenge, the 894 895 896 897 898Melnikov & Zeilenga Standards Track [Page 16] 899 900RFC 4422 SASL June 2006 901 902 903 specification MUST indicate that the response to this challenge 904 is an empty response. 905 906 SASL mechanisms SHOULD be designed to minimize the number of 907 challenges and responses necessary to complete the exchange. 908 909 3) An indication of whether the mechanism is capable of transferring 910 authorization identity strings (see Section 3.4.1). While some 911 legacy mechanisms are incapable of transmitting an authorization 912 identity (which means that for these mechanisms, the authorization 913 identity is always the empty string), newly defined mechanisms 914 SHOULD be capable of transferring authorization identity strings. 915 The mechanism SHOULD NOT be capable of transferring both no 916 authorization identity string and an empty authorization identity. 917 918 Mechanisms that are capable of transferring an authorization 919 identity string MUST be capable of transferring arbitrary non- 920 empty sequences of Unicode characters, excluding those that 921 contain the NUL (U+0000) character. Mechanisms SHOULD use the 922 UTF-8 [RFC3629] transformation format. The specification MUST 923 detail how any Unicode code points special to the mechanism that 924 might appear in the authorization identity string are escaped to 925 avoid ambiguity during decoding of the authorization identity 926 string. Typically, mechanisms that have special characters 927 require these special characters to be escaped or encoded in the 928 character string (after encoding it in a particular Unicode 929 transformation format) using a data encoding scheme such as Base64 930 [RFC3548]. 931 932 4) The specification MUST detail whether the mechanism offers a 933 security layer. If the mechanism does, the specification MUST 934 detail the security and other services offered in the layer as 935 well as how these services are to be implemented. 936 937 5) If the underlying cryptographic technology used by a mechanism 938 supports data integrity, then the mechanism specification MUST 939 integrity protect the transmission of an authorization identity 940 and the negotiation of the security layer. 941 942 SASL mechanisms SHOULD be protocol neutral. 943 944 SASL mechanisms SHOULD reuse existing credential and identity forms, 945 as well as associated syntaxes and semantics. 946 947 SASL mechanisms SHOULD use the UTF-8 transformation format [RFC3629] 948 for encoding Unicode [Unicode] code points for transfer. 949 950 951 952 953 954Melnikov & Zeilenga Standards Track [Page 17] 955 956RFC 4422 SASL June 2006 957 958 959 In order to avoid interoperability problems due to differing 960 normalizations, when a mechanism calls for character data (other than 961 the authorization identity string) to be used as input to a 962 cryptographic and/or comparison function, the specification MUST 963 detail precisely how and where (client or server) the character data 964 is to be prepared, including all normalizations, for input into the 965 function to ensure proper operation. 966 967 For simple user names and/or passwords in authentication credentials, 968 SASLprep [RFC4013] (a profile of the StringPrep [RFC3454] preparation 969 algorithm), SHOULD be specified as the preparation algorithm. 970 971 The mechanism SHOULD NOT use the authorization identity string in 972 generation of any long-term cryptographic keys or hashes as there is 973 no requirement that the authorization identity string be canonical. 974 Long-term, here, means a term longer than the duration of the 975 authentication exchange in which they were generated. That is, as 976 different clients (of the same or different protocol) may provide 977 different authorization identity strings that are semantically 978 equivalent, use of authorization identity strings in generation of 979 cryptographic keys and hashes will likely lead to interoperability 980 and other problems. 981 9826. Security Considerations 983 984 Security issues are discussed throughout this memo. 985 986 Many existing SASL mechanisms do not provide adequate protection 987 against passive attacks, let alone active attacks, in the 988 authentication exchange. Many existing SASL mechanisms do not offer 989 security layers. It is hoped that future SASL mechanisms will 990 provide strong protection against passive and active attacks in the 991 authentication exchange, as well as security layers with strong basic 992 data security features (e.g., data integrity and data 993 confidentiality) services. It is also hoped that future mechanisms 994 will provide more advanced data security services like re-keying (see 995 Section 6.3). 996 997 Regardless, the SASL framework is susceptible to downgrade attacks. 998 Section 6.1.2 offers a variety of approaches for preventing or 999 detecting these attacks. In some cases, it is appropriate to use 1000 data integrity protective services external to SASL (e.g., TLS) to 1001 protect against downgrade attacks in SASL. Use of external 1002 protective security services is also important when the mechanisms 1003 available do not themselves offer adequate integrity and/or 1004 confidentiality protection of the authentication exchange and/or 1005 protocol data. 1006 1007 1008 1009 1010Melnikov & Zeilenga Standards Track [Page 18] 1011 1012RFC 4422 SASL June 2006 1013 1014 10156.1. Active Attacks 1016 10176.1.1. Hijack Attacks 1018 1019 When the client selects a SASL security layer with at least integrity 1020 protection, this protection serves as a counter-measure against an 1021 active attacker hijacking the connection and modifying protocol data 1022 sent after establishment of the security layer. Implementations 1023 SHOULD close the connection when the security services in a SASL 1024 security layer report protocol data report lack of data integrity. 1025 10266.1.2. Downgrade Attacks 1027 1028 It is important that any security-sensitive protocol negotiations be 1029 performed after installation of a security layer with data integrity 1030 protection. Protocols should be designed such that negotiations 1031 performed prior to this installation should be revalidated after 1032 installation is complete. Negotiation of the SASL mechanism is 1033 security sensitive. 1034 1035 When a client negotiates the authentication mechanism with the server 1036 and/or other security features, it is possible for an active attacker 1037 to cause a party to use the least secure security services available. 1038 For instance, an attacker can modify the server-advertised mechanism 1039 list or can modify the client-advertised security feature list within 1040 a mechanism response. To protect against this sort of attack, 1041 implementations SHOULD NOT advertise mechanisms and/or features that 1042 cannot meet their minimum security requirements, SHOULD NOT enter 1043 into or continue authentication exchanges that cannot meet their 1044 minimum security requirements, and SHOULD verify that completed 1045 authentication exchanges result in security services that meet their 1046 minimum security requirements. Note that each endpoint needs to 1047 independently verify that its security requirements are met. 1048 1049 In order to detect downgrade attacks to the least (or less) secure 1050 mechanism supported, the client can discover the SASL mechanisms that 1051 the server makes available both before the SASL authentication 1052 exchange and after the negotiated SASL security layer (with at least 1053 data integrity protection) has been installed through the protocol's 1054 mechanism discovery facility. If the client finds that the 1055 integrity-protected list (the list obtained after the security layer 1056 was installed) contains a stronger mechanism than those in the 1057 previously obtained list, the client should assume that the 1058 previously obtained list was modified by an attacker and SHOULD close 1059 the underlying transport connection. 1060 1061 The client's initiation of the SASL exchange, including the selection 1062 of a SASL mechanism, is done in the clear and may be modified by an 1063 1064 1065 1066Melnikov & Zeilenga Standards Track [Page 19] 1067 1068RFC 4422 SASL June 2006 1069 1070 1071 active attacker. It is important for any new SASL mechanisms to be 1072 designed such that an active attacker cannot obtain an authentication 1073 with weaker security properties by modifying the SASL mechanism name 1074 and/or the challenges and responses. 1075 1076 Multi-level negotiation of security features is prone to downgrade 1077 attack. Protocol designers should avoid offering higher-level 1078 negotiation of security features in protocols (e.g., above SASL 1079 mechanism negotiation) and mechanism designers should avoid lower- 1080 level negotiation of security features in mechanisms (e.g., below 1081 SASL mechanism negotiation). 1082 10836.1.3. Replay Attacks 1084 1085 Some mechanisms may be subject to replay attacks unless protected by 1086 external data security services (e.g., TLS). 1087 10886.1.4. Truncation Attacks 1089 1090 Most existing SASL security layers do not themselves offer protection 1091 against truncation attack. In a truncation attack, the active 1092 attacker causes the protocol session to be closed, causing a 1093 truncation of the possibly integrity-protected data stream that leads 1094 to behavior of one or both the protocol peers that inappropriately 1095 benefits the attacker. Truncation attacks are fairly easy to defend 1096 against in connection-oriented application-level protocols. A 1097 protocol can defend against these attacks by ensuring that each 1098 information exchange has a clear final result and that each protocol 1099 session has a graceful closure mechanism, and that these are 1100 integrity protected. 1101 11026.1.5. Other Active Attacks 1103 1104 When use of a security layer is negotiated by the authentication 1105 protocol exchange, the receiver SHOULD handle gracefully any 1106 protected data buffer larger than the defined/negotiated maximal 1107 size. In particular, it MUST NOT blindly allocate the amount of 1108 memory specified in the buffer size field, as this might cause the 1109 "out of memory" condition. If the receiver detects a large block, it 1110 SHOULD close the connection. 1111 11126.2. Passive Attacks 1113 1114 Many mechanisms are subject to various passive attacks, including 1115 simple eavesdropping of unprotected credential information as well as 1116 online and offline dictionary attacks of protected credential 1117 information. 1118 1119 1120 1121 1122Melnikov & Zeilenga Standards Track [Page 20] 1123 1124RFC 4422 SASL June 2006 1125 1126 11276.3. Re-keying 1128 1129 The secure or administratively permitted lifetimes of SASL 1130 mechanisms' security layers are finite. Cryptographic keys weaken as 1131 they are used and as time passes; the more time and/or cipher-text 1132 that a cryptanalyst has after the first use of the a key, the easier 1133 it is for the cryptanalyst to mount attacks on the key. 1134 1135 Administrative limits on a security layer's lifetime may take the 1136 form of time limits expressed in X.509 certificates, in Kerberos V 1137 tickets, or in directories, and are often desired. In practice, one 1138 likely effect of administrative lifetime limits is that applications 1139 may find that security layers stop working in the middle of 1140 application protocol operation, such as, perhaps, during large data 1141 transfers. As the result of this, the connection will be closed (see 1142 Section 3.7), which will result in an unpleasant user experience. 1143 1144 Re-keying (key renegotiation process) is a way of addressing the 1145 weakening of cryptographic keys. The SASL framework does not itself 1146 provide for re-keying; SASL mechanisms may. Designers of future SASL 1147 mechanisms should consider providing re-keying services. 1148 1149 Implementations that wish to re-key SASL security layers where the 1150 mechanism does not provide for re-keying SHOULD reauthenticate the 1151 same IDs and replace the expired or soon-to-expire security layers. 1152 This approach requires support for reauthentication in the 1153 application protocols (see Section 3.8). 1154 11556.4. Other Considerations 1156 1157 Protocol designers and implementors should understand the security 1158 considerations of mechanisms so they may select mechanisms that are 1159 applicable to their needs. 1160 1161 Distributed server implementations need to be careful in how they 1162 trust other parties. In particular, authentication secrets should 1163 only be disclosed to other parties that are trusted to manage and use 1164 those secrets in a manner acceptable to the disclosing party. 1165 Applications using SASL assume that SASL security layers providing 1166 data confidentiality are secure even when an attacker chooses the 1167 text to be protected by the security layer. Similarly, applications 1168 assume that the SASL security layer is secure even if the attacker 1169 can manipulate the cipher-text output of the security layer. New 1170 SASL mechanisms are expected to meet these assumptions. 1171 1172 1173 1174 1175 1176 1177 1178Melnikov & Zeilenga Standards Track [Page 21] 1179 1180RFC 4422 SASL June 2006 1181 1182 1183 Unicode security considerations [UTR36] apply to authorization 1184 identity strings, as well as UTF-8 [RFC3629] security considerations 1185 where UTF-8 is used. SASLprep [RFC4013] and StringPrep [RFC3454] 1186 security considerations also apply where used. 1187 11887. IANA Considerations 1189 11907.1. SASL Mechanism Registry 1191 1192 The SASL mechanism registry is maintained by IANA. The registry is 1193 currently available at <http://www.iana.org/assignments/sasl- 1194 mechanisms>. 1195 1196 The purpose of this registry is not only to ensure uniqueness of 1197 values used to name SASL mechanisms, but also to provide a definitive 1198 reference to technical specifications detailing each SASL mechanism 1199 available for use on the Internet. 1200 1201 There is no naming convention for SASL mechanisms; any name that 1202 conforms to the syntax of a SASL mechanism name can be registered. 1203 1204 The procedure detailed in Section 7.1.1 is to be used for 1205 registration of a value naming a specific individual mechanism. 1206 1207 The procedure detailed in Section 7.1.2 is to be used for 1208 registration of a value naming a family of related mechanisms. 1209 1210 Comments may be included in the registry as discussed in Section 1211 7.1.3 and may be changed as discussed in Section 7.1.4. 1212 1213 The SASL mechanism registry has been updated to reflect that this 1214 document provides the definitive technical specification for SASL and 1215 that this section provides the registration procedures for this 1216 registry. 1217 1218 1219 1220 1221 1222 1223 1224 1225 1226 1227 1228 1229 1230 1231 1232 1233 1234Melnikov & Zeilenga Standards Track [Page 22] 1235 1236RFC 4422 SASL June 2006 1237 1238 12397.1.1. Mechanism Name Registration Procedure 1240 1241 IANA will register new SASL mechanism names on a First Come First 1242 Served basis, as defined in BCP 26 [RFC2434]. IANA has the right to 1243 reject obviously bogus registration requests, but will perform no 1244 review of claims made in the registration form. 1245 1246 Registration of a SASL mechanism is requested by filling in the 1247 following template: 1248 1249 Subject: Registration of SASL mechanism X 1250 1251 SASL mechanism name (or prefix for the family): 1252 1253 Security considerations: 1254 1255 Published specification (recommended): 1256 1257 Person & email address to contact for further information: 1258 1259 Intended usage: (One of COMMON, LIMITED USE, or OBSOLETE) 1260 1261 Owner/Change controller: 1262 1263 Note: (Any other information that the author deems relevant may be 1264 added here.) 1265 1266 and sending it via electronic mail to IANA at <iana@iana.org>. 1267 1268 While this registration procedure does not require expert review, 1269 authors of SASL mechanisms are encouraged to seek community review 1270 and comment whenever that is feasible. Authors may seek community 1271 review by posting a specification of their proposed mechanism as an 1272 Internet-Draft. SASL mechanisms intended for widespread use should 1273 be standardized through the normal IETF process, when appropriate. 1274 1275 1276 1277 1278 1279 1280 1281 1282 1283 1284 1285 1286 1287 1288 1289 1290Melnikov & Zeilenga Standards Track [Page 23] 1291 1292RFC 4422 SASL June 2006 1293 1294 12957.1.2. Family Name Registration Procedure 1296 1297 As noted above, there is no general naming convention for SASL 1298 mechanisms. However, specifications may reserve a portion of the 1299 SASL mechanism namespace for a set of related SASL mechanisms, a 1300 "family" of SASL mechanisms. Each family of SASL mechanisms is 1301 identified by a unique prefix, such as X-. Registration of new SASL 1302 mechanism family names requires expert review as defined in BCP 26 1303 [RFC2434]. 1304 1305 Registration of a SASL family name is requested by filling in the 1306 following template: 1307 1308 Subject: Registration of SASL mechanism family X 1309 1310 SASL family name (or prefix for the family): 1311 1312 Security considerations: 1313 1314 Published specification (recommended): 1315 1316 Person & email address to contact for further information: 1317 1318 Intended usage: (One of COMMON, LIMITED USE, or OBSOLETE) 1319 1320 Owner/Change controller: 1321 1322 Note: (Any other information that the author deems relevant may be 1323 added here.) 1324 1325 and sending it via electronic mail to the IETF SASL mailing list at 1326 <ietf-sasl@imc.org> and carbon copying IANA at <iana@iana.org>. 1327 After allowing two weeks for community input on the IETF SASL mailing 1328 list, the expert will determine the appropriateness of the 1329 registration request and either approve or disapprove the request 1330 with notice to the requestor, the mailing list, and IANA. 1331 1332 The review should focus on the appropriateness of the requested 1333 family name for the proposed use and the appropriateness of the 1334 proposed naming and registration plan for existing and future 1335 mechanism names in the family. The scope of this request review may 1336 entail consideration of relevant aspects of any provided technical 1337 specification, such as their IANA Considerations section. However, 1338 this review is narrowly focused on the appropriateness of the 1339 requested registration and not on the overall soundness of any 1340 provided technical specification. 1341 1342 1343 1344 1345 1346Melnikov & Zeilenga Standards Track [Page 24] 1347 1348RFC 4422 SASL June 2006 1349 1350 1351 Authors are encouraged to pursue community review by posting the 1352 technical specification as an Internet-Draft and soliciting comment 1353 by posting to appropriate IETF mailing lists. 1354 13557.1.3. Comments on SASL Mechanism Registrations 1356 1357 Comments on a registered SASL mechanism/family should first be sent 1358 to the "owner" of the mechanism/family and/or to the <ietf- 1359 sasl@imc.org> mailing list. 1360 1361 Submitters of comments may, after a reasonable attempt to contact the 1362 owner, request IANA to attach their comment to the SASL mechanism 1363 registration itself by sending mail to <iana@iana.org>. At IANA's 1364 sole discretion, IANA may attach the comment to the SASL mechanism's 1365 registration. 1366 13677.1.4. Change Control 1368 1369 Once a SASL mechanism registration has been published by IANA, the 1370 author may request a change to its definition. The change request 1371 follows the same procedure as the registration request. 1372 1373 The owner of a SASL mechanism may pass responsibility for the SASL 1374 mechanism to another person or agency by informing IANA; this can be 1375 done without discussion or review. 1376 1377 The IESG may reassign responsibility for a SASL mechanism. The most 1378 common case of this will be to enable changes to be made to 1379 mechanisms where the author of the registration has died, has moved 1380 out of contact, or is otherwise unable to make changes that are 1381 important to the community. 1382 1383 SASL mechanism registrations may not be deleted; mechanisms that are 1384 no longer believed appropriate for use can be declared OBSOLETE by a 1385 change to their "intended usage" field; such SASL mechanisms will be 1386 clearly marked in the lists published by IANA. 1387 1388 The IESG is considered to be the owner of all SASL mechanisms that 1389 are on the IETF standards track. 1390 1391 1392 1393 1394 1395 1396 1397 1398 1399 1400 1401 1402Melnikov & Zeilenga Standards Track [Page 25] 1403 1404RFC 4422 SASL June 2006 1405 1406 14077.2. Registration Changes 1408 1409 The IANA has updated the SASL mechanisms registry as follows: 1410 1411 1) Changed the "Intended usage" of the KERBEROS_V4 and SKEY mechanism 1412 registrations to OBSOLETE. 1413 1414 2) Changed the "Published specification" of the EXTERNAL mechanism to 1415 this document as indicated below: 1416 1417 Subject: Updated Registration of SASL mechanism EXTERNAL 1418 Family of SASL mechanisms: NO 1419 SASL mechanism name: EXTERNAL 1420 Security considerations: See A.3 of RFC 4422 1421 Published specification (optional, recommended): RFC 4422 1422 Person & email address to contact for further information: 1423 Alexey Melnikov <Alexey.Melnikov@isode.com> 1424 Intended usage: COMMON 1425 Owner/Change controller: IESG <iesg@ietf.org> 1426 Note: Updates existing entry for EXTERNAL 1427 14288. References 1429 14308.1. Normative References 1431 1432 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1433 Requirement Levels", BCP 14, RFC 2119, March 1997. 1434 1435 [RFC2244] Newman, C. and J. G. Myers, "ACAP -- Application 1436 Configuration Access Protocol", RFC 2244, November 1437 1997. 1438 1439 [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing 1440 an IANA Considerations Section in RFCs", BCP 26, RFC 1441 2434, October 1998. 1442 1443 [RFC2743] Linn, J., "Generic Security Service Application Program 1444 Interface Version 2, Update 1", RFC 2743, January 2000. 1445 1446 [RFC3454] Hoffman, P. and M. Blanchet, "Preparation of 1447 Internationalized Strings ("stringprep")", RFC 3454, 1448 December 2002. 1449 1450 [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 1451 10646", STD 63, RFC 3629, November 2003. 1452 1453 [RFC4013] Zeilenga, K., "SASLprep: Stringprep Profile for User 1454 Names and Passwords", RFC 4013, February 2005. 1455 1456 1457 1458Melnikov & Zeilenga Standards Track [Page 26] 1459 1460RFC 4422 SASL June 2006 1461 1462 1463 [RFC4234] Crocker, D. and P. Overell, "Augmented BNF for Syntax 1464 Specifications: ABNF", RFC 4234, October 2005. 1465 1466 [ASCII] Coded Character Set--7-bit American Standard Code for 1467 Information Interchange, ANSI X3.4-1986. 1468 1469 [Unicode] The Unicode Consortium, "The Unicode Standard, Version 1470 3.2.0" is defined by "The Unicode Standard, Version 1471 3.0" (Reading, MA, Addison-Wesley, 2000. ISBN 0-201- 1472 61633-5), as amended by the "Unicode Standard Annex 1473 #27: Unicode 3.1" 1474 (http://www.unicode.org/reports/tr27/) and by the 1475 "Unicode Standard Annex #28: Unicode 3.2" 1476 (http://www.unicode.org/reports/tr28/). 1477 1478 [CharModel] Whistler, K. and M. Davis, "Unicode Technical Report 1479 #17, Character Encoding Model", UTR17, 1480 <http://www.unicode.org/unicode/reports/tr17/>, August 1481 2000. 1482 1483 [Glossary] The Unicode Consortium, "Unicode Glossary", 1484 <http://www.unicode.org/glossary/>. 1485 14868.2. Informative References 1487 1488 [RFC3206] Gellens, R., "The SYS and AUTH POP Response Codes", RFC 1489 3206, February 2002. 1490 1491 [RFC3548] Josefsson, S., "The Base16, Base32, and Base64 Data 1492 Encodings", RFC 3548, July 2003. 1493 1494 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the 1495 Internet Protocol", RFC 4301, December 2005. 1496 1497 [RFC4346] Dierks, T. and E. Rescorla, "The Transport Layer 1498 Security (TLS) Protocol Version 1.1", RFC 4346, April 1499 2006. 1500 1501 [SASL-GSSAPI] Melnikov, A. (Editor), "The Kerberos V5 ("GSSAPI") SASL 1502 Mechanism", Work in Progress, May 2006. 1503 1504 [UTR36] Davis, M., "(Draft) Unicode Technical Report #36, 1505 Character Encoding Model", UTR17, 1506 <http://www.unicode.org/unicode/reports/tr36/>, 1507 February 2005. 1508 1509 [CRAM-MD5] Nerenberg, L., "The CRAM-MD5 SASL Mechanism", Work in 1510 Progress. 1511 1512 1513 1514Melnikov & Zeilenga Standards Track [Page 27] 1515 1516RFC 4422 SASL June 2006 1517 1518 1519 [DIGEST-MD5] Leach, P., C. Newman, and A. Melnikov, "Using Digest 1520 Authentication as a SASL Mechanism", Work in Progress, 1521 March 2006. 1522 15239. Acknowledgements 1524 1525 This document is a revision of RFC 2222 written by John Myers. 1526 1527 This revision is a product of the IETF Simple Authentication and 1528 Security Layer (SASL) Working Group. 1529 1530 The following individuals contributed significantly to this revision: 1531 Abhijit Menon-Sen, Hallvard Furuseth, Jeffrey Hutzelman, John Myers, 1532 Luke Howard, Magnus Nystrom, Nicolas Williams, Peter Saint-Andre, RL 1533 'Bob' Morgan, Rob Siemborski, Sam Hartman, Simon Josefsson, Tim 1534 Alsop, and Tony Hansen. 1535 1536 1537 1538 1539 1540 1541 1542 1543 1544 1545 1546 1547 1548 1549 1550 1551 1552 1553 1554 1555 1556 1557 1558 1559 1560 1561 1562 1563 1564 1565 1566 1567 1568 1569 1570Melnikov & Zeilenga Standards Track [Page 28] 1571 1572RFC 4422 SASL June 2006 1573 1574 1575Appendix A. The SASL EXTERNAL Mechanism 1576 1577 This appendix is normative. 1578 1579 The EXTERNAL mechanism allows a client to request the server to use 1580 credentials established by means external to the mechanism to 1581 authenticate the client. The external means may be, for instance, IP 1582 Security [RFC4301] or TLS [RFC4346] services. In absence of some a 1583 priori agreement between the client and the server, the client cannot 1584 make any assumption as to what external means the server has used to 1585 obtain the client's credentials, nor make an assumption as to the 1586 form of credentials. For example, the client cannot assume that the 1587 server will use the credentials the client has established via TLS. 1588 1589A.1. EXTERNAL Technical Specification 1590 1591 The name of this mechanism is "EXTERNAL". 1592 1593 The mechanism does not provide a security layer. 1594 1595 The mechanism is capable of transferring an authorization identity 1596 string. If empty, the client is requesting to act as the identity 1597 the server has associated with the client's credentials. If non- 1598 empty, the client is requesting to act as the identity represented by 1599 the string. 1600 1601 The client is expected to send data first in the authentication 1602 exchange. Where the client does not provide an initial response data 1603 in its request to initiate the authentication exchange, the server is 1604 to respond to the request with an empty initial challenge and then 1605 the client is to provide its initial response. 1606 1607 The client sends the initial response containing the UTF-8 [RFC3629] 1608 encoding of the requested authorization identity string. This 1609 response is non-empty when the client is requesting to act as the 1610 identity represented by the (non-empty) string. This response is 1611 empty when the client is requesting to act as the identity the server 1612 associated with its authentication credentials. 1613 1614 The syntax of the initial response is specified as a value of the 1615 <extern-initial-resp> production detailed below using the Augmented 1616 Backus-Naur Form (ABNF) [RFC4234] notation. 1617 1618 external-initial-resp = authz-id-string 1619 authz-id-string = *( UTF8-char-no-nul ) 1620 UTF8-char-no-nul = UTF8-1-no-nul / UTF8-2 / UTF8-3 / UTF8-4 1621 UTF8-1-no-nul = %x01-7F 1622 1623 1624 1625 1626Melnikov & Zeilenga Standards Track [Page 29] 1627 1628RFC 4422 SASL June 2006 1629 1630 1631 where the <UTF8-2>, <UTF8-3>, and <UTF8-4> productions are as defined 1632 in [RFC3629]. 1633 1634 There are no additional challenges and responses. 1635 1636 Hence, the server is to return the outcome of the authentication 1637 exchange. 1638 1639 The exchange fails if 1640 1641 - the client has not established its credentials via external means, 1642 1643 - the client's credentials are inadequate, 1644 1645 - the client provided an empty authorization identity string and the 1646 server is unwilling or unable to associate an authorization 1647 identity with the client's credentials, 1648 1649 - the client provided a non-empty authorization identity string that 1650 is invalid per the syntax requirements of the applicable 1651 application protocol specification, 1652 1653 - the client provided a non-empty authorization identity string 1654 representing an identity that the client is not allowed to act as, 1655 or 1656 1657 - the server is unwilling or unable to provide service to the client 1658 for any other reason. 1659 1660 Otherwise the exchange is successful. When indicating a successful 1661 outcome, additional data is not provided. 1662 1663A.2. SASL EXTERNAL Examples 1664 1665 This section provides examples of EXTERNAL authentication exchanges. 1666 The examples are intended to help the readers understand the above 1667 text. The examples are not definitive. The Application 1668 Configuration Access Protocol (ACAP) [RFC2244] is used in the 1669 examples. 1670 1671 The first example shows use of EXTERNAL with an empty authorization 1672 identity. In this example, the initial response is not sent in the 1673 client's request to initiate the authentication exchange. 1674 1675 S: * ACAP (SASL "DIGEST-MD5") 1676 C: a001 STARTTLS 1677 S: a001 OK "Begin TLS negotiation now" 1678 <TLS negotiation, further commands are under TLS layer> 1679 1680 1681 1682Melnikov & Zeilenga Standards Track [Page 30] 1683 1684RFC 4422 SASL June 2006 1685 1686 1687 S: * ACAP (SASL "DIGEST-MD5" "EXTERNAL") 1688 C: a002 AUTHENTICATE "EXTERNAL" 1689 S: + "" 1690 C: + "" 1691 S: a002 OK "Authenticated" 1692 1693 The second example shows use of EXTERNAL with an authorization 1694 identity of "fred@example.com". In this example, the initial 1695 response is sent with the client's request to initiate the 1696 authentication exchange. This saves a round-trip. 1697 1698 S: * ACAP (SASL "DIGEST-MD5") 1699 C: a001 STARTTLS 1700 S: a001 OK "Begin TLS negotiation now" 1701 <TLS negotiation, further commands are under TLS layer> 1702 S: * ACAP (SASL "DIGEST-MD5" "EXTERNAL") 1703 C: a002 AUTHENTICATE "EXTERNAL" {16+} 1704 C: fred@example.com 1705 S: a002 NO "Cannot assume requested authorization identity" 1706 1707A.3. Security Considerations 1708 1709 The EXTERNAL mechanism provides no security protection; it is 1710 vulnerable to spoofing by either client or server, active attack, and 1711 eavesdropping. It should only be used when adequate security 1712 services have been established. 1713 1714Appendix B. Changes since RFC 2222 1715 1716 This appendix is non-normative. 1717 1718 The material in RFC 2222 was significantly rewritten in the 1719 production of this document. 1720 1721 RFC 2222, by not stating that the authorization identity string was a 1722 string of Unicode characters, let alone character data, implied that 1723 the authorization identity string was a string of octets. 1724 1725 - The authorization identity string is now defined as a string of 1726 Unicode characters. The NUL (U+0000) character is prohibited. 1727 While protocol specifications are responsible for defining the 1728 authorization identity form, as well as the Unicode string syntax 1729 and related semantics, mechanism specifications are responsible 1730 for defining how the Unicode string is carried in the 1731 authentication exchange. 1732 1733 - Deleted "If so, when the client does not send data first, the 1734 initial challenge MUST be specified as being an empty challenge." 1735 1736 1737 1738Melnikov & Zeilenga Standards Track [Page 31] 1739 1740RFC 4422 SASL June 2006 1741 1742 1743 The following technical change was made to the EXTERNAL mechanism: 1744 1745 - The authorization identity string is to be UTF-8 encoded. 1746 1747 Note that protocol and mechanism specification requirements have 1748 been significantly tightened. Existing protocol and mechanism 1749 specifications will need to be updated to meet these requirements. 1750 1751Editors' Addresses 1752 1753 Alexey Melnikov 1754 Isode Limited 1755 5 Castle Business Village 1756 36 Station Road 1757 Hampton, Middlesex, 1758 TW12 2BX, United Kingdom 1759 1760 EMail: Alexey.Melnikov@isode.com 1761 URI: http://www.melnikov.ca/ 1762 1763 1764 Kurt D. Zeilenga 1765 OpenLDAP Foundation 1766 1767 EMail: Kurt@OpenLDAP.org 1768 1769 1770 1771 1772 1773 1774 1775 1776 1777 1778 1779 1780 1781 1782 1783 1784 1785 1786 1787 1788 1789 1790 1791 1792 1793 1794Melnikov & Zeilenga Standards Track [Page 32] 1795 1796RFC 4422 SASL June 2006 1797 1798 1799Full Copyright Statement 1800 1801 Copyright (C) The Internet Society (2006). 1802 1803 This document is subject to the rights, licenses and restrictions 1804 contained in BCP 78, and except as set forth therein, the authors 1805 retain all their rights. 1806 1807 This document and the information contained herein are provided on an 1808 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1809 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 1810 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 1811 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 1812 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1813 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1814 1815Intellectual Property 1816 1817 The IETF takes no position regarding the validity or scope of any 1818 Intellectual Property Rights or other rights that might be claimed to 1819 pertain to the implementation or use of the technology described in 1820 this document or the extent to which any license under such rights 1821 might or might not be available; nor does it represent that it has 1822 made any independent effort to identify any such rights. Information 1823 on the procedures with respect to rights in RFC documents can be 1824 found in BCP 78 and BCP 79. 1825 1826 Copies of IPR disclosures made to the IETF Secretariat and any 1827 assurances of licenses to be made available, or the result of an 1828 attempt made to obtain a general license or permission for the use of 1829 such proprietary rights by implementers or users of this 1830 specification can be obtained from the IETF on-line IPR repository at 1831 http://www.ietf.org/ipr. 1832 1833 The IETF invites any interested party to bring to its attention any 1834 copyrights, patents or patent applications, or other proprietary 1835 rights that may cover technology that may be required to implement 1836 this standard. Please address the information to the IETF at 1837 ietf-ipr@ietf.org. 1838 1839Acknowledgement 1840 1841 Funding for the RFC Editor function is provided by the IETF 1842 Administrative Support Activity (IASA). 1843 1844 1845 1846 1847 1848 1849 1850Melnikov & Zeilenga Standards Track [Page 33] 1851 1852