idnits 2.17.1 draft-zeilenga-sasl-rfc2222bis-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 21. -- Found old boilerplate from RFC 3978, Section 5.5 on line 1323. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1296. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1303. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1309. ** Found boilerplate matching RFC 3978, Section 5.4, paragraph 1 (on line 1315), which is fine, but *also* found old RFC 2026, Section 10.4C, paragraph 1 text on line 38. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == The 'Obsoletes: ' line in the draft header should list only the _numbers_ of the RFCs which will be obsoleted by this document (if approved); it should not include the word 'RFC' in the list. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords -- however, there's a paragraph with a matching beginning. Boilerplate error? (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (15 May 2005) is 6919 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: 'RFC2234' is mentioned on line 1186, but not defined ** Obsolete undefined reference: RFC 2234 (Obsoleted by RFC 4234) ** Obsolete normative reference: RFC 2434 (Obsoleted by RFC 5226) ** Obsolete normative reference: RFC 3454 (Obsoleted by RFC 7564) ** Obsolete normative reference: RFC 4013 (Obsoleted by RFC 7613) -- Possible downref: Non-RFC (?) normative reference: ref. 'ASCII' -- Possible downref: Non-RFC (?) normative reference: ref. 'Unicode' -- Possible downref: Non-RFC (?) normative reference: ref. 'CharModel' -- Possible downref: Non-RFC (?) normative reference: ref. 'Glossary' -- Obsolete informational reference (is this intentional?): RFC 2246 (Obsoleted by RFC 4346) -- Obsolete informational reference (is this intentional?): RFC 3548 (Obsoleted by RFC 4648) -- Obsolete informational reference (is this intentional?): RFC 2401 (Obsoleted by RFC 4301) -- No information found for draft-ietf-sasl-gssapi-XX - is the name correct? Summary: 9 errors (**), 0 flaws (~~), 4 warnings (==), 15 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 INTERNET-DRAFT A. Melnikov, Ed. 3 Intended Category: Standards Track ISODE Limited 4 Expires in six months K. Zeilenga, Ed. 5 Obsoletes: RFC 2222 OpenLDAP Project 6 15 May 2005 8 Simple Authentication and Security Layer (SASL) 9 11 Status of this Memo 13 This document is based upon . This 14 document offers alternative text. 16 By submitting this Internet-Draft, I accept the provisions of Section 17 3 of BCP 78. By submitting this Internet-Draft, each author 18 represents that any applicable patent or other IPR claims of which he 19 or she is aware have been or will be disclosed, and any of which he or 20 she becomes aware will be disclosed, in accordance with Section 6 of 21 BCP 79. 23 Internet-Drafts are working documents of the Internet Engineering Task 24 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 material 30 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) The Internet Society (2005). All Rights Reserved. 40 Please see the Full Copyright section near the end of this document 41 for more information. 43 Abstract 44 The Simple Authentication and Security Layer (SASL) is a framework for 45 providing authentication and data security services in 46 connection-oriented protocols via replaceable mechanisms. It provides 47 a structured interface between protocols and mechanisms. The 48 resulting framework allows new protocols to reuse existing mechanisms 49 and allows old protocols to make use of new mechanisms. The framework 50 also provides a protocol for securing subsequent protocol exchanges 51 within a data security layer. 53 This document describes how a SASL mechanism is structured, describes 54 how protocols include support for SASL, and defines the protocol for 55 carrying a data security layer over a connection. Additionally, this 56 document defines one SASL mechanism, the EXTERNAL mechanism. 58 This document obsoletes RFC 2222. 60 Table of Contents 62 [[Page numbers to be filled in by RFC-Editor]] 64 Status of this Memo 65 Abstract 66 1. Introduction 67 1.1. Document Audiences 68 1.2. Relationship to Other Documents 69 1.3. Conventions 70 2. Identity Concepts 71 3. The Authentication Exchange 72 3.1. Mechanism Naming 73 3.2. Mechanism Negotiation 74 3.3. Request Authentication Exchange 75 3.4. Challenges and Responses 76 3.4.1. Authorization Identity String 77 3.5. Aborting Authentication Exchanges 78 3.6. Authentication Outcome 79 3.7. Security Layers 80 3.8. Multiple Authentications 81 4. Protocol Requirements 82 5. Mechanism Requirements 83 6. Security Considerations 84 6.1. Active Attacks 85 6.1.1. Man-in-the-middle Attacks 86 6.1.2. Replay Attacks 87 6.1.3. Truncation Attacks 88 6.2. Passive Attacks 89 6.3. Re-keying 90 6.4. Other considerations 91 7. IANA Considerations 92 8. References 93 9. Editors' Address 94 10. Acknowledgments 95 A. The SASL EXTERNAL Mechanism 96 B. Changes since RFC 2222 98 1. Introduction 100 The Simple Authentication and Security Layer (SASL) is a framework for 101 providing authentication and data security services in 102 connection-oriented protocols via replaceable mechanisms. SASL 103 provides a structured interface between protocols and mechanisms. 104 SASL also provides a protocol for securing subsequent protocol 105 exchanges within a data security layer. The data security layer can 106 provide data integrity, data confidential, and other services. 108 SASL's design is intended to allow new protocols to reuse existing 109 mechanisms without requiring redesign of the mechanisms and allows 110 existing protocols to make use of new mechanisms without redesign of 111 protocols. 113 SASL is conceptually a framework which provides an abstraction layer 114 between protocols and mechanisms as illustrated in the following 115 diagram. 117 SMTP LDAP XMPP Other protocols ... 118 \ | | / 119 \ | | / 120 SASL abstraction layer 121 / | | \ 122 / | | \ 123 EXTERNAL GSSAPI PLAIN Other mechanisms ... 125 It is through the interfaces of this abstraction layer that the 126 framework allows any protocol to utilize any mechanism. While this 127 layer does generally hide the particulars of protocols from mechanisms 128 and the particulars of mechanisms from protocols, this layer does not 129 generally hide the particulars of mechanisms from protocol 130 implementations. For example, different mechanisms require different 131 information to operate, some of them use password-based 132 authentication, some of then require realm information, others make 133 use of Kerberos tickets, certificates, etc.. Also, in order to 134 perform authorization, server implementations generally have to 135 implement identity mapping between authentication identities, whose 136 form is mechanism-specific, and authorization identities, whose form 137 is application protocol specific. Section 2 discusses identity 138 concepts. 140 It is possible to design and implement this framework in ways which do 141 abstract away particulars of similar mechanisms. Such a framework 142 implementation, as well as mechanisms implementations, could be 143 designed not only to be shared by multiple implementations of a 144 particular protocol, but be shared by implementations of multiple 145 protocols. 147 The framework incorporates interfaces with both protocols and 148 mechanisms in which authentication exchanges are carried out. Section 149 3 discusses SASL authentication exchanges. 151 To use SASL, each protocol (amongst other items) provides a method for 152 identifying which mechanism is to be used, provides a method for 153 exchange of mechanism-specific server-challenges and client-responses, 154 and a method the communicating the outcome of the authentication 155 exchange. Section 4 discusses SASL protocol requirements. 157 Each SASL mechanism defines (amongst other items) a series of server 158 challenges and client responses which provide authentication services 159 and negotiate data security services. Section 5 discusses SASL 160 mechanism requirements. 162 Section 6 discusses security considerations. Section 7 discusses IANA 163 considerations. Appendix A defines the SASL EXTERNAL mechanism. 165 1.1. Document Audiences 167 This document is written to serve several different audiences: 169 - protocol designers using this specification to support 170 authentication in their protocol, 172 - mechanism designers that define new SASL mechanisms, and 174 - implementors of clients or servers for those protocols which 175 support SASL. 177 While the document organization is intended to allow readers to focus 178 on details relevant to their engineering, readers are encouraged to 179 read and understand all aspects of this document. 181 1.2. Relationship to other documents 183 This document obsoletes RFC 2222. It replaces all portions of RFC 184 2222 excepting sections 7.1 (the KERBEROS_IV mechanism), 7.2 (the 185 GSSAPI mechanism), 7.3 (the SKEY mechanism). The KERBEROS_IV and SKEY 186 mechanisms are now viewed as obsolete and their specifications 187 provided in RFC 2222 are Historic. The GSSAPI mechanism is now 188 separately specified [SASL-GSSAPI]. 190 Appendix B provides a summary of changes since RFC 2222. 192 1.3. Conventions 194 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 195 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 196 document are to be interpreted as described in BCP 14 [RFC2119]. 198 Character names in this document use the notation for code points and 199 names from the Unicode Standard [Unicode]. For example, the letter 200 "a" may be represented as either or . 202 Note: a glossary of terms used in Unicode can be found in [Glossary]. 203 Information on the Unicode character encoding model can be found in 204 [CharModel]. 206 In examples, "C:" and "S:" indicate lines of data to be sent by the 207 client and server respectively. Lines have been wrapped for improved 208 readability. 210 2. Identity Concepts 212 In practice, authentication and authorization may involve multiple 213 identities, possible in different forms (simple username, Kerberos 214 principal, X.500 Distinguished Name, etc.), possibly with different 215 representations (e.g.: ABNF-described UTF-8 encoded Unicode character 216 string, BER-encoded Distinguished Name). While technical 217 specifications often prescribe both the identity form and 218 representation used on the network, different identity forms and/or 219 representations may (and often are) used within implementations. How 220 identities of different forms relate to each other is, generally, a 221 local matter. Additionally, the forms and representations used within 222 an implementation is a local matter. 224 However, conceptually, SASL framework involves two identities: 225 1) an identity associated with the authentication credentials 226 (termed the authentication identity), and 227 2) an identity to act as (termed the authorization identity). 229 The client provides its credentials and, optionally, a character 230 string representing the requested authorization identity as part of 231 the SASL exchange. When this string is omitted or empty, the client 232 is requesting to act as the identity associated with the credentials 233 (e.g., the user is requesting to act as the authentication identity). 235 The server is responsible for verifying the client's credentials and 236 verifying that the client is allowed to act as the authorization 237 identity. A SASL exchange fails if either (or both) of these 238 verifications fails. (The SASL exchange may fail for other reasons, 239 such as service authorization failure.) 241 SASL mechanism specifications describe the credential form(s) (e.g., 242 X.509 certificates, Kerberos tickets, simple username/password) used 243 to authenticate the client, including (where appropriate) the syntax 244 and semantics of associated identities. SASL protocol specifications 245 describe the identity form(s) used in authorization and, in 246 particular, prescribe the syntax and semantics of the authorization 247 identity character string to be transferred by mechanisms. 249 However, the precise form(s) of the authentication identities (used 250 within the server in its verifications, or otherwise) and the precise 251 form(s) of the authorization identities (used in making authorization 252 decisions, or otherwise) is beyond the scope of the SASL and this 253 specification. In some circumstances, the precise identity forms used 254 in some context outside of the SASL exchange may be dictated by other 255 specifications. For instance, an identity assumption authorization 256 (proxy authorization) policy specification may dictate how 257 authentication and authorization identities are represented in the 258 policy statement. 260 3. The Authentication Exchange 262 Each authentication exchange consists of a message from the client to 263 the server requesting authentication via a particular mechanism, 264 followed by pairs of challenges from servers and responses from 265 clients, followed by message from the server indicating the outcome of 266 the authentication exchange. (Note: exchanges may also be aborted as 267 discussed in Section 3.5.) 269 The following illustration provides a high-level overview of an 270 authentication exchange. 272 C: Request authentication exchange 273 S: Initial challenge 274 C: Initial response 275 276 S: Outcome of authentication exchange 278 If the outcome is successful and a data layer was negotiated, this 279 layer is then installed. Protocols may allow this data to be carried 280 in the request message. This applies as well to the following 281 illustrations. 283 Some mechanisms specify that the first data sent in the authentication 284 exchange is from the client to the server. Protocols may provide an 285 optional initial response field in the request message to carry this 286 data. Where the mechanism specifies the first data data sent in the 287 exchange is from the client to the server, the protocol provides an 288 optional initial response field, and the client uses this field, the 289 exchange is shorten by one round-trip: 291 C: Request authentication exchange + Initial response 292 293 S: Outcome of authentication exchange 295 Where the mechanism specifies the first data sent in the exchange is 296 from the client to the server and this field is unavailable or unused, 297 the client request is followed by an empty challenge. 299 C: Request authentication exchange 300 S: Empty Challenge 301 C: Initial Response 302 303 S: Outcome of authentication exchange 305 Should a client include an initial response in its request where the 306 mechanism does not allow the client to send data first, the 307 authentication exchange fails. 309 Some mechanisms specify that the server is to send additional data to 310 the client along when indicating a successful outcome. Protocols may 311 provide an optional additional data field in the outcome message to 312 carry this data. Where the mechanism specifies the server is to 313 return additional data with the successful outcome, the protocol 314 provides an optional additional data field in the outcome message, and 315 the server uses this field, the exchange is shorten by one round-trip: 317 C: Request authentication exchange 318 S: Initial challenge 319 C: Initial response 320 321 S: Outcome of authentication exchange with 322 additional data with success 324 Where the mechanism specifies the server is to return additional data 325 to the client with a successful outcome and and this field is 326 unavailable or unused, the additional data is sent as a challenge 327 whose response is empty. After receiving this response, the server 328 then indicates the successful outcome. 330 C: Request authentication exchange 331 S: Initial challenge 332 C: Initial response 333 334 S: Additional data challenge 335 C: Empty Response 336 S: Outcome of authentication exchange 338 Where mechanisms specify the first data sent in the exchange is from 339 the client to the server and additional data is to sent to the client 340 along with indicating a successful outcome, and the protocol provides 341 fields support both, the exchange can be shorted by two round-trips: 343 C: Request authentication exchange + Initial response 344 345 S: Outcome of authentication exchange 346 with additional data with success 348 instead of: 350 C: Request authentication exchange 351 S: Empty Challenge 352 C: Initial Response 353 354 S: Additional data challenge 355 C: Empty Response 356 S: Outcome of authentication exchange 358 3.1. Mechanism Naming 360 SASL mechanisms are named by character strings, from 1 to 20 361 characters in length, consisting of ASCII [ASCII] uppercase letters, 362 digits, hyphens, and/or underscores. In the following Augmented 363 Backus-Naur Form (ABNF) [ABNF] grammar, the production 364 defines the syntax of a SASL mechanism name. 366 sasl-mech = 1*20mech-char 367 mech-char = UPPER-ALPHA / DIGIT / HYPHEN / UNDERSCORE 368 ; mech-char is restricted to A-Z (uppercase only), 0-9, -, and _ 369 ; from ASCII character set. 371 UPPER-ALPHA = %x41-5A ; A-Z (uppercase only) 372 DIGIT = %x30-39 ; 0-9 373 HYPHEN = %x2D ; hyphen (-) 374 UNDERSCORE = %x5F ; underscore (_) 376 SASL mechanisms names are registered as discussed in Section 7.1. 378 3.2. Mechanism Negotiation 380 Mechanism negotiation is protocol-specific. 382 Commonly, a protocol will specify that the server advertises supported 383 and available mechanisms to the client via some facility provided by 384 the protocol and the client will then use select the "best" mechanism 385 from this which its supports and finds suitable. 387 It is noted that the mechanism negotiation is not protected by the 388 subsequent authentication exchange and hence is subject to downgrade 389 attacks if not protected by other means. 391 To detect downgrade attacks, a protocol may allow the client to 392 discover available mechanism subsequent to the authentication exchange 393 (and, hence, protected by any data security layer provided by 394 mechanism) so that downgrade attacks can be detected. 396 3.3. Request Authentication Exchange 398 The authentication exchange is initiated by the client by requesting 399 authentication via a mechanism it specifies. The client sends a 400 message that contains the name of the mechanism to the server. The 401 particulars of the message are protocol specific. 403 It is noted that the name of the mechanism is not protected by the 404 mechanism, and hence subject to alteration by an attacker if not 405 integrity protected by other means. 407 Where the mechanism is defined to allow the client to send data first, 408 and the protocol's request message includes an optional initial 409 response field, the client may include the response to the initial 410 challenge in the authentication request message. 412 3.4. Challenges and Responses 414 The authentication exchange involves pairs of server-challenges and 415 client-responses, the particulars of which are mechanism specific. 416 These challenges and responses are enclosed in protocol messages, the 417 particulars of which are protocol specific. 419 Through these challenges and responses, the mechanism may: 420 - authenticate the client to the server, 421 - authenticate the server to the client, 422 - transfer an authorization identity string, 423 - negotiate a security layer, and 424 - provide other services. 426 The negotiation of the security layer may involve negotiation of the 427 security services to be provided in the layer, how these services will 428 be provided, and negotiation of a maximum cipher-text buffer size each 429 size is able to receive in the layer (see Section 3.6). 431 After receiving an authentication request or any client response, the 432 server may issue a challenge, abort the exchange, or indicate the 433 outcome of an exchange. After receiving a challenge, a client 434 mechanism may issue a response or abort the exchange. 436 3.4.1. Authorization Identity String 438 The authorization identity string is a sequence of zero or more 439 Unicode [Unicode] characters, excluding the NUL (U+0000) character, 440 representing the identity to act as. 442 If the authorization identity string is absent, the client is 443 requesting to act as the identity the server associates with the 444 client's credentials. An empty string is equivalent to an absent 445 authorization identity. 447 Non-empty authorization identity string indicates the client wishes to 448 act as the identity represented by the string. In this case, the form 449 of identity represented by the string, as well as the precise syntax 450 and semantics of the string, is protocol specific. 452 While character encoding schema used to transfer the authorization 453 identity string in the authentication exchange is mechanism specific, 454 mechanisms are expected to be capable of carrying the entire Unicode 455 repertoire (with the exception of the NUL character). 457 3.5. Aborting Authentication Exchanges 459 A client or server may desire to abort an authentication exchange it 460 is unwilling or unable to continue (or enter into). 462 A client may abort the authentication exchange by sending a message, 463 the particulars of which are mechanism specific, to the server, 464 indicating the exchange is aborted. The server may be required by the 465 protocol to return a message in response to the client's abort 466 message. 468 Likewise, a server may abort the authentication exchange by sending a 469 message, the particulars of which are mechanism specific, to the 470 client, indicating the exchange is aborted. 472 3.6. Authentication Outcome 474 At the conclusion of the authentication exchange, the server sends a 475 message, the particulars of which are protocol specific, to the client 476 indicating the outcome of the exchange. 478 The outcome is not successful if 479 - the authentication exchange failed for any reason, 480 - the clients credentials could not be verified, 481 - the server cannot associate an identity with the client's 482 credentials, 483 - the client-provided authorization identity string is malformed, 484 - the identity associated with the client's credentials are not 485 authorized to act as the requested authorization identity, 486 - the negotiated security layer (or lack thereof) is not suitable, 487 or 488 - the server is not willing to provide service to the client for any 489 reason. 491 The protocol may include a field in this optional additional data. 493 If the outcome is successful and a security layer was negotiated, this 494 layer is then installed. If the outcome is unsuccessful, or a 495 security layer was not negotiated, any existing security is left in 496 place. 498 3.7. Security Layers 500 SASL mechanisms may offer a wide range of services in security layers. 501 Typical services include data integrity and data confidentiality. 502 SASL mechanisms which do not provide a security layer are treated as 503 negotiating no security layer. 505 If use of a security layer is negotiated in the authentication 506 protocol exchange, the layer is installed by the server after 507 indicating the outcome of the authentication exchange and installed by 508 the client upon receipt the outcome indication. In both cases, the 509 layer is installed before transfer of further protocol data. The 510 precise position that the layer takes effect in the protocol data 511 stream is protocol specific. 513 Once the security layer is in effect in the protocol data stream, it 514 remains in effect until either a subsequently negotiated security 515 layer is installed, or the underlying transport connection is closed. 517 When in effect, the security layer processes protocol data into 518 buffers of protected data. If at any time the security layer is 519 unable to continue producing buffers protecting protocol data, the 520 underlying transport connection MUST be closed. If the security layer 521 is not able to decode a received buffer, the underlying connection 522 MUST be closed. In both cases the underlying transport connection 523 SHOULD be closed gracefully. 525 Each buffer of protected data is transferred over the underlying 526 transport connection as a sequence of octets prepended with a four 527 octet field in network byte order that represents the length of the 528 buffer. The length of the protected data buffer MUST be no larger 529 than the maximum size the other side expects. Upon the receipt of a 530 length field whose value is greater than maximum size, the receiver 531 SHOULD close the connection, as this might be a sign of an attack. 533 The maximum size for each side expects is fixed by the mechanism, 534 either through negotiation or by its specification. 536 3.8. Multiple Authentications 538 Unless explicitly permitted in the protocol (as stated in the 539 protocol's technical specification), only one successful SASL 540 authentication exchange may occur in a protocol session. In this 541 case, once an authentication exchange has successfully completed, 542 further attempts to initiate an authentication exchange fail. 544 Where multiple successful SASL authentication exchanges are permitted 545 in the protocol, then in no case may multiple SASL security layers be 546 simultaneously in effect. If a security layer is in effect and a 547 subsequent SASL negotiation selects a second security layer, then the 548 second security layer replaces the first. If a security layer is in 549 effect and a subsequent SASL negotiation selects no security layer, 550 the original security layer remains in effect. 552 Where multiple successful SASL negotiations are permitted in the 553 protocol, the effect of a failed SASL authentication exchange upon the 554 previously established authentication and authorization state is 555 protocol specific. The protocol's technical specification should be 556 consulted to determine whether the previous authentication and 557 authorization state remains in force, or changed to an anonymous 558 state, or otherwise effected. Regardless of the protocol-specific 559 effect upon previously established authentication and authorization 560 state, the previously negotiated security layer remains in effect. 562 4. Protocol Requirements 564 In order for a protocol to offer SASL services, its specification MUST 565 supply the following information: 567 1) A service name, to be selected from the IANA registry of "service" 568 elements for the GSSAPI host-based service name form [RFC2743]. 570 2) Detail any mechanism negotiation facility the protocol provides 571 (see Section 3.2). 573 A protocol SHOULD specify a facility through which the client may 574 discover, both before initiation of the SASL exchange and after 575 installing security layers negotiated by the exchange, the names of 576 the SASL mechanisms the server makes available to the client. The 577 latter is important to allow the client to detect downgrade 578 attacks. This facility is typically provided through the 579 protocol's extensions or capabilities discovery facility. 581 3) Definition of the messages necessary for authentication exchange, 582 including: 584 a) A message to initiate the authentication exchange (see Section 585 3.3). 587 This message MUST contain a field for carrying the name of the 588 mechanism selected by the client. 590 This message SHOULD contain an optional field for carrying an 591 initial response. If the message is defined with this field, 592 the specification MUST describe how messages with an empty 593 initial response are distinguished from messages with no initial 594 response. This field MUST be capable of carrying arbitrary 595 sequences of octets (including zero length sequences and 596 sequences containing zero-valued octets). 598 b) Messages to transfer a server challenges and client responses. 599 (see Section 3.4). 601 Each of these messages MUST be capable of carrying arbitrary 602 sequences of octets (including zero length sequences and 603 sequences containing zero-valued octets). 605 c) A message to indicate the outcome of the authentication exchange 606 (see Section 3.6). 608 This message SHOULD contain an optional field for carrying 609 additional data with a successful outcome. If the message is 610 defined with this field, the specification MUST describe how 611 messages with an empty additional data are distinguished from 612 messages with no additional data. This field MUST be capable of 613 carrying arbitrary sequences of octets (including zero length 614 sequences and sequences containing zero-valued octets). 616 4) Prescribe the syntax and semantics of non-empty authorization 617 identity strings (see Section 3.4.1). 619 Specifications are encouraged to prescribe use existing 620 authorization identity forms as well as existing string 621 representations, such as simple user names [RFC4013]. 623 Where the specification does not precisely prescribe how identities 624 in SASL relate to identities used elsewhere in the protocol, for 625 instance in access control policy statements, it may be appropriate 626 for the protocol to provide a facility by which the client may 627 discover information (such as the representation of the 628 authentication identity used in making access control decisions) 629 about established identities for these uses. 631 5) Detail any facility the protocol provide allow the client and/or 632 server to abort authentication exchange (see Section 3.5). 634 Protocols which support multiple authentications typically allow a 635 client to abort an on-going authentication exchange by initiating a 636 new authentication exchange. Protocols which do not support 637 multiple authentications may require the client to close the 638 connection and start over to abort an on-going authentication 639 exchange. 641 Protocols typically allow the server to abort on-going 642 authentication exchanges by returning a non-successful outcome 643 message. 645 6) Identify precisely where newly negotiated security layers starts to 646 take effect, in both directions (see Section 3.7). 648 Typically, specifications require security layer to start taking 649 effect, in data being sent by the server, on the first octet 650 following the outcome message and, in data being sent by the 651 client, on the first octet sent after receipt of the outcome 652 message. 654 7) If the protocol supports other layered security services, such as 655 Transport Layer Security (TLS) [RFC2246], the specification MUST 656 prescribe the order in which security layers are applied to 657 protocol data. 659 For instance, where a protocol supports both TLS and SASL security 660 layers, the specification could prescribe any of the following: 661 a) SASL security layer is always applied first to data being sent 662 and, hence, applied last to received data, 663 b) SASL security layer is always applied last to data being sent 664 and, hence, applied first to received data, 665 c) Layers are applied in the order in which they were installed, 666 d) Layers are applied in the reverse order in which they were 667 installed, or 668 e) Both TLS and SASL security layers cannot be installed. 670 8) Indicate whether the protocol supports multiple authentications 671 (see Section 3.8). If so, the protocol MUST detail the effect a 672 failed SASL authentication exchange will have upon previously 673 established authentication and authorization state. 675 Protocol specifications SHOULD avoid stating implementation 676 requirements which would hinder replacement of applicable mechanisms. 677 In general, protocol specification SHOULD be mechanism neutral. There 678 are a number reasonable exceptions to this recommendation, including: 679 - detailing how credentials (which are mechanism-specific) are 680 managed in the protocol, 681 - detailing how authentication identities (which are 682 mechanism-specific) and authorization identities (which are 683 protocol-specific) relate to each other, and 684 - detailing which mechanisms are applicable to the protocol. 686 5. Mechanism Requirements 688 SASL mechanism specifications MUST supply the following information: 690 1) The name of the mechanism (see Section 3.1). This name MUST be 691 registered as discussed in Section 8.1. 693 2) A definition of the server-challenges and client-responses of the 694 authentication exchange, as well as: 696 a) An indication whether the client is expected to send data first. 697 If so, when the client does not send data first, the initial 698 challenge MUST be specified as being an empty challenge. 700 b) An indication whether the server is expected to provide 701 additional data when indicating a successful outcome. If so, if 702 the server sends the additional data as a challenge, the 703 specification MUST indicate the response to this challenge is an 704 empty response. 706 SASL mechanisms SHOULD be designed to minimize the number of round 707 challenges and responses necessary to complete the exchange. 709 3) An indication of whether the mechanism is capable of transferring 710 authorization identity strings (see Section 3.4.1). While some 711 legacy mechanisms are incapable of transmitting an authorization 712 identity (which means that for these mechanisms the authorization 713 identity is always the empty string), newly defined mechanisms 714 SHOULD be capable of transferring authorization identity strings. 715 The mechanism SHOULD NOT be capable of transferring both no 716 authorization identity string and an empty authorization identity. 718 Mechanisms which are capable of transferring an authorization 719 identity string MUST be capable of transferring arbitrary non-empty 720 sequences of Unicode characters, excluding those which contain the 721 NUL (U+0000) character. Mechanisms SHOULD use the UTF-8 [RFC3629] 722 transformation format. The specification MUST detail how any 723 Unicode code points special to the mechanism which might appear in 724 the authorization identity string are escaped to avoid ambiguity 725 during decoding of the authorization identity string. Typically, 726 mechanisms which have special characters require these special 727 characters to be escaped or encoded in the character string (after 728 encoding it a particular Unicode transformation format) using a 729 data encoding scheme such as Base64 [RFC3548]. 731 4) The specification MUST detail whether or not the mechanism offers a 732 security layer. If the mechanism does, the specification MUST 733 detail the security and other services offered in the layer as well 734 as how these services are to be implemented. 736 5) If the underlying cryptographic technology used by a mechanism 737 supports data integrity, then the mechanism specification MUST 738 integrity protect the transmission of an authorization identity and 739 the negotiation of the security layer. 741 SASL mechanisms SHOULD be protocol neutral. 743 SASL mechanisms SHOULD reuse existing credential and identity forms, 744 as well as associated syntaxes and semantics. 746 SASL mechanisms SHOULD use UTF-8 transformation format [RFC3629] for 747 encoding Unicode [Unicode] code points for transfer. 749 In order to avoid interoperability problems due to differing 750 normalizations, when a mechanism calls for character data is to be 751 used as input to a cryptographic and/or comparison function, the 752 specification MUST detail precisely how and where (client or server) 753 the character data is to be prepared, including all normalizations, 754 for input into the function to ensure proper operation. 756 For simple user names and/or passwords in authentication credentials, 757 SASLprep [RFC4013] (a profile of the StringPrep [RFC3454] preparation 758 algorithm), SHOULD be specified as the preparation algorithm. 760 The mechanism SHOULD NOT use the authorization identity string in 761 generation of any long-term cryptographic keys or hashes as there is 762 no requirement that the authorization identity string be be 763 non-canonical. Long-term, here, means a term longer than the duration 764 of the authentication exchange in which they were generated in. That 765 is, as different clients (of the same or different protocol) may 766 provide different authorization identity strings which are 767 semantically equivalent, use of authorization identity strings in 768 generation of cryptographic keys and hashes will likely lead to 769 interoperability and other problems. 771 6. Security Considerations 773 Security issues are discussed throughout this memo. 775 Many existing SASL mechanisms do not provide adequate protection 776 against passive attacks, let alone active attacks, against the 777 authentication exchange. Many existing SASL mechanisms do not offer 778 any security layers. It is hoped that future SASL mechanisms will 779 provide strong protection against passive and active attacks in the 780 authentication exchange, as well as security layers with strong basis 781 data security features (e.g., data integrity and data confidentiality) 782 services. It is also hoped that future mechanisms will provide more 783 advance data security services like re-keying (see Section 6.1). 785 Regardless, the SASL framework is suspectable to downgrade attacks. 786 Section 6.1 offers a variety of approaches for preventing or detecting 787 these attacks. In some cases, it is appropriate to use data integrity 788 protective services (e.g., TLS) external to SASL to protect against 789 downgrade attacks in SASL. This is especially true when the 790 mechanisms available to the client do not themselves offer adequate 791 integrity or confidentiality protection of the authentication exchange 792 and/or protocol data. 794 6.1. Active Attacks 796 6.1.1. Man-in-the-middle Attacks 798 When the client selects a security layer with at least integrity 799 protection, this protects against an active attacker hijacking the 800 connection and modifying the authentication exchange to negotiate a 801 plain-text connection. In this case, it is important that any 802 security-sensitive protocol negotiations be performed after 803 authentication is complete. Protocols should be designed such that 804 negotiations performed prior to authentication should be either 805 ignored or revalidated once authentication is complete. 807 Negotiation of the SASL mechanism, initiation of the SASL exchange, 808 and portions of the SASL authentication exchange itself are 809 security-sensitive negotiations. 811 When a server or client supports multiple authentication mechanisms, 812 each of which has a different security strength, it is possible for an 813 active attacker to cause a party to use the least secure mechanism 814 supported. To protect against this sort of attack, a client or server 815 which supports mechanisms of different strengths should have a 816 configurable minimum strength that it will use. It is not sufficient 817 for this minimum strength check to only be on the server, since an 818 active attacker can change which mechanisms the client sees as being 819 supported, causing the client to send authentication credentials for 820 its weakest supported mechanism. 822 In order to detect downgrade attacks to the least (or less) secure 823 mechanism supported, the client may discover the SASL mechanisms the 824 server makes available both before the SASL authentication exchange 825 and after the negotiated SASL security layer (with at least integrity 826 protection) has been installed through the protocol's mechanism 827 discovery facility. If the client finds that the integrity protected 828 list (the list obtained after the security layer was installed) 829 contains a stronger mechanism than those in the previously obtained 830 list, the client should assume the previously obtained list was 831 modified by an attacker. 833 The client's initiation of the SASL exchange, including the the 834 selection of a SASL mechanism, is done in the clear and may be 835 modified by an active attacker. It is important for any new SASL 836 mechanisms to be designed such that an active attacker cannot obtain 837 an authentication with weaker security properties by modifying the 838 SASL mechanism name and/or the challenges and responses. 840 When use of a security layer is negotiated by the authentication 841 protocol exchange, the receiver should handle gracefully any protected 842 data buffer larger than the defined/negotiated maximal size. In 843 particular, it must not blindly allocate the amount of memory 844 specified in the buffer size field, as this might cause the "out of 845 memory" condition. If the receiver detects a large block, it SHOULD 846 close the connection. 848 Distributed server implementations need to be careful in how they 849 trust other parties. In particular, authentication secrets should 850 only be disclosed to other parties that are trusted to manage and use 851 those secrets in manner acceptable to disclosing party. Applications 852 using SASL assume that SASL security layers providing data 853 confidentiality are secure even when an attacker chooses the text to 854 be protected by the security layer. Similarly applications assume 855 that the SASL security layer is secure even if the attacker can 856 manipulate the cipher-text output of the security layer. New SASL of 857 new SASL mechanisms SHOULD meet these assumptions. 859 6.1.2. Replay Attacks 861 Some mechanisms may be subject to replay attacks unless protected by 862 external data security services (e.g., TLS). 864 6.1.3. Truncation Attacks 866 Most existing SASL security layers to not, themselves, offer 867 protection against truncation attack. In a truncation attacks, the 868 active attacker causes the protocol session to be closed, causing a 869 truncation of the possibly integrity protected data stream that leads 870 to behavior of one or both the protocol peers that inappropriate 871 benefits the attacker. Truncation attacks are fairly easy to defend 872 against in connection-oriented application-level protocols. A 873 protocol can defend against these attacks simply by ensuring that each 874 information exchange has a clear final result and that each protocol 875 session has a graceful closure mechanism, and that these are integrity 876 protected. 878 6.2. Passive Attacks 880 Many mechanisms are subject to various passive attacks, including 881 simple eavesdropping of unprotected credential information in 882 mechanisms, such as PLAIN, to online and offline dictionary attacks. 884 6.3. Re-keying 886 The secure or administratively permitted lifetimes of SASL mechanisms' 887 security layers are finite. Cryptographic keys weaken as they are 888 used and as time passes; the more time and/or cipher-text that a 889 cryptanalyst has after the first use of the a key, the easier it is 890 for the cryptanalyst to mount attacks on the key. 892 Administrative limits on security layers lifetime may take the form of 893 time limits expressed in X.509 certificates, Kerberos V tickets, or in 894 directories, and are often desired. In practice one likely effect of 895 administrative security layers lifetime limits is that applications 896 may find that security layers stop working in the middle of 897 application protocol operation, such as, perhaps, during large data 898 transfers. As the result of this the connection will be closed (see 899 Section 3.7), which will result in unpleasant user experience. 901 Re-keying (key renegotiation process) is a way of addressing the 902 weakening of cryptographic keys. SASL framework does not itself 903 provide for re-keying. SASL mechanisms may. Designers of future SASL 904 mechanisms should consider providing re-keying services. 906 Applications that wish to re-key SASL security layers where the 907 mechanism does not provide for re-keying should reauthenticate the 908 same IDs and replace the expired or soon-to-expire security layers. 909 This approach requires support for reauthentication in the application 910 protocols (see Section 3.8). 912 6.5. Other Considerations 914 Unicode security considerations [UTR36] apply to authorization 915 identity strings, and well as UTF-8 [RFC3629] security considerations 916 where UTF-8 is used. SASLprep [RFC4013] and StringPrep [RFC3454] 917 security considerations also apply where used. 919 Protocol designers and implementors should understand the security 920 considerations of mechanisms so they may select mechanisms which are 921 applicable to their needs. 923 Multi-level negotiation of security features is prone to downgrade 924 attack. Protocol designers should avoid offering higher level 925 negotiation of security features in protocols (e.g., above SASL 926 mechanism negotiation) and mechanism designers should avoid lower 927 level negotiation of security features in mechanisms (e.g., below SASL 928 mechanism negotiation). 930 7. IANA Considerations 932 7.1. SASL Mechanism Registry 934 SASL mechanism registry is maintained by IANA. The registry is 935 currently available at 936 . 938 7.1.1. Registration Procedure 940 Registration of a SASL mechanism is requested by filling in the 941 following template: 943 Subject: Registration of SASL mechanism X 945 Family of SASL mechanisms: (YES or NO) 947 SASL mechanism name (or prefix for the family): 949 Security considerations: 951 Published specification (recommended): 953 Person & email address to contact for further information: 955 Intended usage: (One of COMMON, LIMITED USE or OBSOLETE) 957 Owner/Change controller: 959 Note: (Any other information that the author deems interesting may 960 be added here .) 962 and sending it via electronic mail to . 964 IANA has the right to reject obviously bogus registrations, but will 965 perform no review of claims made in the registration form. IANA will 966 register new values on a First Come First Served basis, as defined in 967 BCP 64 [RFC2434]. 969 There is no naming convention for SASL mechanisms; any name that 970 conforms to the syntax of a SASL mechanism name can be registered. 972 However an IETF Standards Track document may reserve a portion of the 973 SASL mechanism namespace ("family of SASL mechanisms") for its own 974 use, amending the registration rules for that portion of the 975 namespace. Each family of SASL mechanisms MUST be identified by a 976 prefix. 978 While the registration procedures do not require expert review, 979 authors of SASL mechanisms are encouraged to seek community review and 980 comment whenever that is feasible. Authors may seek community review 981 by posting a specification of their proposed mechanism as an 982 Internet-Draft. SASL mechanisms intended for widespread use should be 983 standardized through the normal IETF process, when appropriate. 985 7.1.2. Comments on SASL Mechanism Registrations 987 Comments on registered SASL mechanisms should first be sent to the 988 "owner" of the mechanism and/or to the SASL WG mailing list. 990 Submitters of comments may, after a reasonable attempt to contact the 991 owner, request IANA to attach their comment to the SASL mechanism 992 registration itself by sending mail to . At IANA sole 993 discretion, IANA may attach the comment to the registration SASL 994 mechanism. 996 7.1.3. Change Control 998 Once a SASL mechanism registration has been published by IANA, the 999 author may request a change to its definition. The change request 1000 follows the same procedure as the registration request. 1002 The owner of a SASL mechanism may pass responsibility for the SASL 1003 mechanism to another person or agency by informing IANA; this can be 1004 done without discussion or review. 1006 The IESG may reassign responsibility for a SASL mechanism. The most 1007 common case of this will be to enable changes to be made to mechanisms 1008 where the author of the registration has died, moved out of contact or 1009 is otherwise unable to make changes that are important to the 1010 community. 1012 SASL mechanism registrations may not be deleted; mechanisms which are 1013 no longer believed appropriate for use can be declared OBSOLETE by a 1014 change to their "intended usage" field; such SASL mechanisms will be 1015 clearly marked in the lists published by IANA. 1017 The IESG is considered to be the owner of all SASL mechanisms which 1018 are on the IETF standards track. 1020 7.2. Registration Changes 1022 It is requested that IANA updates the SASL mechanisms registry as 1023 follows: 1025 1) Change the "Intended usage" of the KERBEROS_V4 and SKEY mechanism 1026 registrations to OBSOLETE. 1028 2) Change the "Published specification" of the EXTERNAL mechanism to 1029 this document as indicated below: 1031 Subject: Updated Registration of SASL mechanism EXTERNAL 1032 Family of SASL mechanisms: NO 1033 SASL mechanism name: EXTERNAL 1034 Security considerations: See RFC XXXX, section 9. 1035 Published specification (optional, recommended): RFC XXXX 1036 Person & email address to contact for further information: 1037 Alexey Melnikov 1038 Intended usage: COMMON 1039 Owner/Change controller: IESG 1040 Note: Updates existing entry for EXTERNAL 1042 8. References 1044 [[Note to the RFC Editor: please replace the citation tags used in 1045 referencing Internet-Drafts with tags of the form RFCnnnn where 1046 possible.]] 1048 8.1. Normative References 1050 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1051 Requirement Levels", BCP 14 (also RFC 2119), March 1997. 1053 [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an 1054 IANA Considerations Section in RFCs", BCP 26 (also RFC 1055 2434), October 1998. 1057 [RFC2743] Linn, J., "Generic Security Service 1058 Application Program Interface, Version 2, Update 1", RFC 1059 2743, January 2000. 1061 [RFC3454] Hoffman, P. and M. Blanchet, "Preparation of 1062 Internationalized Strings ('stringprep')", RFC 3454, 1063 December 2002. 1065 [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 1066 10646", RFC 3629 (also STD 63), November 2003. 1068 [RFC4013] Zeilenga, K., "SASLprep: Stringprep Profile for User 1069 Names and Passwords", RFC 4013, February 2005. 1071 [ABNF] Crocker, D. and P. Overell, "Augmented BNF for Syntax 1072 Specifications: ABNF", draft-crocker-abnf-rfc2234bis, a 1073 work in progress. 1075 [ASCII] Coded Character Set--7-bit American Standard Code for 1076 Information Interchange, ANSI X3.4-1986. 1078 [Unicode] The Unicode Consortium, "The Unicode Standard, Version 1079 3.2.0" is defined by "The Unicode Standard, Version 3.0" 1080 (Reading, MA, Addison-Wesley, 2000. ISBN 0-201-61633-5), 1081 as amended by the "Unicode Standard Annex #27: Unicode 1082 3.1" (http://www.unicode.org/reports/tr27/) and by the 1083 "Unicode Standard Annex #28: Unicode 3.2" 1084 (http://www.unicode.org/reports/tr28/). 1086 [CharModel] Whistler, K. and M. Davis, "Unicode Technical Report 1087 #17, Character Encoding Model", UTR17, 1088 , August 1089 2000. 1091 [Glossary] The Unicode Consortium, "Unicode Glossary", 1092 . 1094 8.2. Informative References 1096 [RFC2244] Newman, C. and J. Myers, "ACAP -- Application 1097 Configuration Access Protocol", RFC 2244, November 1997. 1098 [RFC2246] Dierks, T. and, C. Allen, "The TLS Protocol Version 1099 1.0", RFC 2246, January 1999. 1101 [RFC3548] Josefsson, S., "The Base16, Base32, and Base64 Data 1102 Encodings", RFC 3548, July 2003. 1104 [RFC2401] Kent, S., and R. Atkinson, "Security Architecture for 1105 the Internet Protocol", RFC 2401, November 1998. 1107 [SASL-GSSAPI] Melnikov, A. (Editor), "SASL GSSAPI mechanisms", 1108 draft-ietf-sasl-gssapi-XX.txt, a work in progress. 1110 [UTR36] Davis, M., "(Draft) Unicode Technical 1111 Report #36, Character Encoding Model", UTR17, 1112 , February 1113 2005. 1115 9. Editors' Address 1117 Alexey Melnikov 1118 Isode Limited 1119 5 Castle Business Village 1120 36 Station Road 1121 Hampton, Middlesex, 1122 TW12 2BX, United Kingdom 1124 Email: Alexey.Melnikov@isode.com 1125 URI: http://www.melnikov.ca/ 1127 Kurt D. Zeilenga 1128 OpenLDAP Foundation 1130 Email: Kurt@OpenLDAP.org 1132 10. Acknowledgments 1134 This document is a revision of RFC 2222 written by John Myers. 1136 This revision is a product of the IETF Simple Authentication and 1137 Security Layer (SASL) Working Group. 1139 The following individuals contributed significantly to this revision: 1140 Abhijit Menon-Sen, Hallvard B Furuseth, Jeffrey Hutzelman, John Myers, 1141 Luke Howard, Magnus Nystrom, Nicolas Williams, Peter Saint-Andre, RL 1142 'Bob' Morgan, Rob Siemborski, Sam Hartman, Simon Josefsson, Tim Alsop, 1143 and Tony Hansen. 1145 Appendix A. The SASL EXTERNAL Mechanism 1147 This appendix is normative. 1149 The EXTERNAL mechanism allows a client to request the server use 1150 credentials established by means external to the mechanism to 1151 authenticate the client. The external means may be, for instance, IP 1152 Security [RFC2401] or TLS [RFC2246] services. In absence of some 1153 apriori agreement between the client and the server, the client cannot 1154 make any assumption as to what external means the server has used to 1155 obtain the client's credentials, nor make an assumption as to the form 1156 of credentials. For example, the client cannot assume the server will 1157 use the credentials the client has established via TLS. 1159 A.1. EXTERNAL Technical Specification 1161 The name of this mechanism is "EXTERNAL". 1163 The mechanism does not provide a security layer. 1165 The mechanism is capable of transferring an authorization identity 1166 string. If empty, the client is requesting to act as the identity the 1167 server has associated with the client's credentials. If non-empty, 1168 the client is requesting to act as the identity represented by the 1169 string. 1171 The client is expected to send data first in the authentication 1172 exchange. Where the client does not provide an initial response data 1173 in its request to initiate the authentication exchange, the server is 1174 to respond to the request with an empty initial challenge and then the 1175 client is to provide its initial response. 1177 The client sends the initial response containing the UTF-8 [RFC3629] 1178 encoding of the requested authorization identity string. This 1179 response is non-empty when the client is requesting to act as identity 1180 represented by the (non-empty) string. This response is empty when 1181 the client is requesting to act as the identity the server associated 1182 with its authentication credentials. 1184 The syntax of the initial response is specified as a value of the 1185 production detailed below using the Augmented 1186 Backus-Naur Form (ABNF) [RFC2234] notation. 1188 external-initial-resp = authz-id-string 1189 authz-id-string = *( UTF8-char-no-nul ) 1190 UTF8-char-no-nul = UTF8-1-no-nul / UTF8-2 / UTF8-3 / UTF8-4 1191 UTF8-1-no-nul = %x01-7F 1193 where the , , and productions are as defined 1194 in [RFC3629]. 1196 There are no additional challenges and responses. 1198 Hence, the server is to return the outcome of the authentication 1199 exchange. 1201 The exchange fails if 1202 - the client has not established its credentials via external means, 1203 - the client's credentials are inadequate, 1204 - The client provided an empty authorization identity string and the 1205 server unwilling or unable to associate an authorization identity 1206 with the clients credentials, 1207 - The client provided a non-empty authorization identity string which 1208 is invalid per the syntax requirements of the applicable application 1209 protocol specification, 1210 - The client provided a non-empty authorization identity string 1211 representing an identity which the client is not allowed to act as, 1212 or 1213 - the server is unwilling or unable to provide service to the client 1214 for any other reason. 1216 Otherwise the exchange is successful. When indicating a successful 1217 outcome, additional data is not provided. 1219 A.2. SASL EXTERNAL Examples 1221 This section provides examples of EXTERNAL authentication exchanges. 1222 The examples are intended to help the readers under the above text. 1223 The examples are not definitive. The Application Configuration 1224 Access Protocol (ACAP) [RFC2244] is used in the examples. 1226 The first example shows use of EXTERNAL with an empty authorization 1227 identity. In this example, the initial response is not sent the 1228 client's request to initiate authentication exchange. 1230 S: * ACAP (SASL "DIGEST-MD5") 1231 C: a001 STARTTLS 1232 S: a001 OK "Begin TLS negotiation now" 1233 1234 S: * ACAP (SASL "DIGEST-MD5" "EXTERNAL") 1235 C: a002 AUTHENTICATE "EXTERNAL" 1236 S: + "" 1237 C: + "" 1238 S: a002 OK "Authenticated" 1240 In second example shows use of EXTERNAL with an authorization identity 1241 of "fred@example.com". In this example, the initial response is sent 1242 with the clients request to initiate the authentication exchange. 1243 This saves a round-trip. 1245 S: * ACAP (SASL "DIGEST-MD5") 1246 C: a001 STARTTLS 1247 S: a001 OK "Begin TLS negotiation now" 1248 1249 S: * ACAP (SASL "DIGEST-MD5" "EXTERNAL") 1250 C: a002 AUTHENTICATE "EXTERNAL" {16+} 1251 C: fred@example.com 1252 S: a002 NO "Cannot assume requested authorization identity" 1254 A.3. Security Considerations 1256 The EXTERNAL mechanism provides no security protection; it is 1257 vulnerable to spoofing by either client or server, active attack, and 1258 eavesdropping. It should only be used when adequate security services 1259 have been established. 1261 Appendix B. Changes since RFC 2222 1263 This appendix is non-normative. 1265 The material in RFC 2222 was significantly rewritten in the production 1266 of this document. 1268 RFC 2222, by not stating the authorization identity string was a 1269 string of Unicode characters, let alone character data, implied the 1270 authorization identity string was a string of octets. 1272 - The authorization identity string is now defined as a string of 1273 Unicode characters. The NUL (U+0000) is prohibited. While protocol 1274 specifications are responsible for defining the authorization 1275 identity form, as well as the Unicode string syntax and related 1276 semantics, mechanism specifications are responsible for defining how 1277 the Unicode string is carried in the authentication exchange. 1279 The following technical change was made to the EXTERNAL mechanism: 1281 - The authorization identity string is to be UTF-8 encoded. 1283 It is noted that protocol and mechanism specification requirements 1284 have been significant tightened. Existing protocol and mechanism 1285 specifications will need to be updated to meet these requirements. 1287 Intellectual Property Rights 1289 The IETF takes no position regarding the validity or scope of any 1290 Intellectual Property Rights or other rights that might be claimed to 1291 pertain to the implementation or use of the technology described in 1292 this document or the extent to which any license under such rights 1293 might or might not be available; nor does it represent that it has 1294 made any independent effort to identify any such rights. Information 1295 on the procedures with respect to rights in RFC documents can be found 1296 in BCP 78 and BCP 79. 1298 Copies of IPR disclosures made to the IETF Secretariat and any 1299 assurances of licenses to be made available, or the result of an 1300 attempt made to obtain a general license or permission for the use of 1301 such proprietary rights by implementers or users of this specification 1302 can be obtained from the IETF on-line IPR repository at 1303 http://www.ietf.org/ipr. 1305 The IETF invites any interested party to bring to its attention any 1306 copyrights, patents or patent applications, or other proprietary 1307 rights that may cover technology that may be required to implement 1308 this standard. Please address the information to the IETF at 1309 ietf-ipr@ietf.org. 1311 Full Copyright 1313 Copyright (C) The Internet Society (2005). This document is subject 1314 to the rights, licenses and restrictions contained in BCP 78, and 1315 except as set forth therein, the authors retain all their rights. 1317 This document and the information contained herein are provided on an 1318 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1319 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 1320 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 1321 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 1322 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1323 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.