idnits 2.17.1 draft-ietf-sasl-rfc2222bis-11.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 18. -- Found old boilerplate from RFC 3978, Section 5.5 on line 1328. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1301. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1308. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1314. ** Found boilerplate matching RFC 3978, Section 5.4, paragraph 1 (on line 1320), which is fine, but *also* found old RFC 2026, Section 10.4C, paragraph 1 text on line 35. ** 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 (1 June 2005) is 6902 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 1192, 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 1 June 2005 8 Simple Authentication and Security Layer (SASL) 9 11 Status of this Memo 13 By submitting this Internet-Draft, I accept the provisions of Section 14 3 of BCP 78. By submitting this Internet-Draft, each author 15 represents that any applicable patent or other IPR claims of which he 16 or she is aware have been or will be disclosed, and any of which he or 17 she becomes aware will be disclosed, in accordance with Section 6 of 18 BCP 79. 20 Internet-Drafts are working documents of the Internet Engineering Task 21 Force (IETF), its areas, and its working groups. Note that other 22 groups may also distribute working documents as Internet-Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six months 25 and may be updated, replaced, or obsoleted by other documents at any 26 time. It is inappropriate to use Internet-Drafts as reference material 27 or to cite them other than as "work in progress." 29 The list of current Internet-Drafts can be accessed at 30 http://www.ietf.org/1id-abstracts.html 32 The list of Internet-Draft Shadow Directories can be accessed at 33 http://www.ietf.org/shadow.html 35 Copyright (C) The Internet Society (2005). All Rights Reserved. 37 Please see the Full Copyright section near the end of this document 38 for more information. 40 Abstract 42 The Simple Authentication and Security Layer (SASL) is a framework for 43 providing authentication and data security services in 44 connection-oriented protocols via replaceable mechanisms. It provides 45 a structured interface between protocols and mechanisms. The 46 resulting framework allows new protocols to reuse existing mechanisms 47 and allows old protocols to make use of new mechanisms. The framework 48 also provides a protocol for securing subsequent protocol exchanges 49 within a data security layer. 51 This document describes how a SASL mechanism is structured, describes 52 how protocols include support for SASL, and defines the protocol for 53 carrying a data security layer over a connection. Additionally, this 54 document defines one SASL mechanism, the EXTERNAL mechanism. 56 This document obsoletes RFC 2222. 58 Table of Contents 60 [[Page numbers to be filled in by RFC-Editor]] 62 Status of this Memo 63 Abstract 64 1. Introduction 65 1.1. Document Audiences 66 1.2. Relationship to Other Documents 67 1.3. Conventions 68 2. Identity Concepts 69 3. The Authentication Exchange 70 3.1. Mechanism Naming 71 3.2. Mechanism Negotiation 72 3.3. Request Authentication Exchange 73 3.4. Challenges and Responses 74 3.4.1. Authorization Identity String 75 3.5. Aborting Authentication Exchanges 76 3.6. Authentication Outcome 77 3.7. Security Layers 78 3.8. Multiple Authentications 79 4. Protocol Requirements 80 5. Mechanism Requirements 81 6. Security Considerations 82 6.1. Active Attacks 83 6.1.1. Man-in-the-middle Attacks 84 6.1.2. Replay Attacks 85 6.1.3. Truncation Attacks 86 6.2. Passive Attacks 87 6.3. Re-keying 88 6.4. Other considerations 89 7. IANA Considerations 90 8. References 91 9. Editors' Address 92 10. Acknowledgments 93 A. The SASL EXTERNAL Mechanism 94 B. Changes since RFC 2222 96 1. Introduction 98 The Simple Authentication and Security Layer (SASL) is a framework for 99 providing authentication and data security services in 100 connection-oriented protocols via replaceable mechanisms. SASL 101 provides a structured interface between protocols and mechanisms. 102 SASL also provides a protocol for securing subsequent protocol 103 exchanges within a data security layer. The data security layer can 104 provide data integrity, data confidentiality, and other services. 106 SASL's design is intended to allow new protocols to reuse existing 107 mechanisms without requiring redesign of the mechanisms and allows 108 existing protocols to make use of new mechanisms without redesign of 109 protocols. 111 SASL is conceptually a framework which provides an abstraction layer 112 between protocols and mechanisms as illustrated in the following 113 diagram. 115 SMTP LDAP XMPP Other protocols ... 116 \ | | / 117 \ | | / 118 SASL abstraction layer 119 / | | \ 120 / | | \ 121 EXTERNAL GSSAPI PLAIN Other mechanisms ... 123 It is through the interfaces of this abstraction layer that the 124 framework allows any protocol to utilize any mechanism. While this 125 layer does generally hide the particulars of protocols from mechanisms 126 and the particulars of mechanisms from protocols, this layer does not 127 generally hide the particulars of mechanisms from protocol 128 implementations. For example, different mechanisms require different 129 information to operate, some of them use password-based 130 authentication, some of then require realm information, others make 131 use of Kerberos tickets, certificates, etc.. Also, in order to 132 perform authorization, server implementations generally have to 133 implement identity mapping between authentication identities, whose 134 form is mechanism-specific, and authorization identities, whose form 135 is application protocol specific. Section 2 discusses identity 136 concepts. 138 It is possible to design and implement this framework in ways which do 139 abstract away particulars of similar mechanisms. Such a framework 140 implementation, as well as mechanisms implementations, could be 141 designed not only to be shared by multiple implementations of a 142 particular protocol, but be shared by implementations of multiple 143 protocols. 145 The framework incorporates interfaces with both protocols and 146 mechanisms in which authentication exchanges are carried out. Section 147 3 discusses SASL authentication exchanges. 149 To use SASL, each protocol (amongst other items) provides a method for 150 identifying which mechanism is to be used, provides a method for 151 exchange of mechanism-specific server-challenges and client-responses, 152 and a method for communicating the outcome of the authentication 153 exchange. Section 4 discusses SASL protocol requirements. 155 Each SASL mechanism defines (amongst other items) a series of server 156 challenges and client responses which provide authentication services 157 and negotiate data security services. Section 5 discusses SASL 158 mechanism requirements. 160 Section 6 discusses security considerations. Section 7 discusses IANA 161 considerations. Appendix A defines the SASL EXTERNAL mechanism. 163 1.1. Document Audiences 165 This document is written to serve several different audiences: 167 - protocol designers using this specification to support 168 authentication in their protocol, 170 - mechanism designers that define new SASL mechanisms, and 172 - implementors of clients or servers for those protocols which 173 support SASL. 175 While the document organization is intended to allow readers to focus 176 on details relevant to their engineering, readers are encouraged to 177 read and understand all aspects of this document. 179 1.2. Relationship to other documents 181 This document obsoletes RFC 2222. It replaces all portions of RFC 182 2222 excepting sections 7.1 (the KERBEROS_IV mechanism), 7.2 (the 183 GSSAPI mechanism), 7.3 (the SKEY mechanism). The KERBEROS_IV and SKEY 184 mechanisms are now viewed as obsolete and their specifications 185 provided in RFC 2222 are Historic. The GSSAPI mechanism is now 186 separately specified [SASL-GSSAPI]. 188 Appendix B provides a summary of changes since RFC 2222. 190 1.3. Conventions 192 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 193 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 194 document are to be interpreted as described in BCP 14 [RFC2119]. 196 Character names in this document use the notation for code points and 197 names from the Unicode Standard [Unicode]. For example, the letter 198 "a" may be represented as either or . 200 Note: a glossary of terms used in Unicode can be found in [Glossary]. 201 Information on the Unicode character encoding model can be found in 202 [CharModel]. 204 In examples, "C:" and "S:" indicate lines of data to be sent by the 205 client and server respectively. Lines have been wrapped for improved 206 readability. 208 2. Identity Concepts 210 In practice, authentication and authorization may involve multiple 211 identities, possibly in different forms (simple username, Kerberos 212 principal, X.500 Distinguished Name, etc.), possibly with different 213 representations (e.g.: ABNF-described UTF-8 encoded Unicode character 214 string, BER-encoded Distinguished Name). While technical 215 specifications often prescribe both the identity form and 216 representation used on the network, different identity forms and/or 217 representations may (and often are) used within implementations. How 218 identities of different forms relate to each other is, generally, a 219 local matter. Additionally, the forms and representations used within 220 an implementation is a local matter. 222 However, conceptually, SASL framework involves two identities: 223 1) an identity associated with the authentication credentials 224 (termed the authentication identity), and 225 2) an identity to act as (termed the authorization identity). 227 The client provides its credentials and, optionally, a character 228 string representing the requested authorization identity as part of 229 the SASL exchange. When this string is omitted or empty, the client 230 is requesting to act as the identity associated with the credentials 231 (e.g., the user is requesting to act as the authentication identity). 233 The server is responsible for verifying the client's credentials and 234 verifying that the client is allowed to act as the authorization 235 identity. A SASL exchange fails if either (or both) of these 236 verifications fails. (The SASL exchange may fail for other reasons, 237 such as service authorization failure.) 239 SASL mechanism specifications describe the credential form(s) (e.g., 240 X.509 certificates, Kerberos tickets, simple username/password) used 241 to authenticate the client, including (where appropriate) the syntax 242 and semantics of associated identities. SASL protocol specifications 243 describe the identity form(s) used in authorization and, in 244 particular, prescribe the syntax and semantics of the authorization 245 identity character string to be transferred by mechanisms. 247 However, the precise form(s) of the authentication identities (used 248 within the server in its verifications, or otherwise) and the precise 249 form(s) of the authorization identities (used in making authorization 250 decisions, or otherwise) is beyond the scope of SASL and this 251 specification. In some circumstances, the precise identity forms used 252 in some context outside of the SASL exchange may be dictated by other 253 specifications. For instance, an identity assumption authorization 254 (proxy authorization) policy specification may dictate how 255 authentication and authorization identities are represented in the 256 policy statement. 258 3. The Authentication Exchange 260 Each authentication exchange consists of a message from the client to 261 the server requesting authentication via a particular mechanism, 262 followed by pairs of challenges from servers and responses from 263 clients, followed by a message from the server indicating the outcome 264 of the authentication exchange. (Note: exchanges may also be aborted 265 as discussed in Section 3.5.) 267 The following illustration provides a high-level overview of an 268 authentication exchange. 270 C: Request authentication exchange 271 S: Initial challenge 272 C: Initial response 273 274 S: Outcome of authentication exchange 276 If the outcome is successful and a data layer was negotiated, this 277 layer is then installed. Protocols may allow this data to be carried 278 in the request message. This applies as well to the following 279 illustrations. 281 Some mechanisms specify that the first data sent in the authentication 282 exchange is from the client to the server. Protocols may provide an 283 optional initial response field in the request message to carry this 284 data. Where the mechanism specifies the first data data sent in the 285 exchange is from the client to the server, the protocol provides an 286 optional initial response field, and the client uses this field, the 287 exchange is shortened by one round-trip: 289 C: Request authentication exchange + Initial response 290 291 S: Outcome of authentication exchange 293 Where the mechanism specifies the first data sent in the exchange is 294 from the client to the server and this field is unavailable or unused, 295 the client request is followed by an empty challenge. 297 C: Request authentication exchange 298 S: Empty Challenge 299 C: Initial Response 300 301 S: Outcome of authentication exchange 303 Should a client include an initial response in its request where the 304 mechanism does not allow the client to send data first, the 305 authentication exchange fails. 307 Some mechanisms specify that the server is to send additional data to 308 the client when indicating a successful outcome. Protocols may 309 provide an optional additional data field in the outcome message to 310 carry this data. Where the mechanism specifies the server is to 311 return additional data with the successful outcome, the protocol 312 provides an optional additional data field in the outcome message, and 313 the server uses this field, the exchange is shortened by one 314 round-trip: 316 C: Request authentication exchange 317 S: Initial challenge 318 C: Initial response 319 320 S: Outcome of authentication exchange with 321 additional data with success 323 Where the mechanism specifies the server is to return additional data 324 to the client with a successful outcome and and this field is 325 unavailable or unused, the additional data is sent as a challenge 326 whose response is empty. After receiving this response, the server 327 then indicates the successful outcome. 329 C: Request authentication exchange 330 S: Initial challenge 331 C: Initial response 332 333 S: Additional data challenge 334 C: Empty Response 335 S: Outcome of authentication exchange 337 Where mechanisms specify the first data sent in the exchange is from 338 the client to the server and additional data is sent to the client 339 along with indicating a successful outcome, and the protocol provides 340 fields supporting both, the exchange can be shorted by two 341 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 select the "best" mechanism from 385 this list 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 if 460 it is unwilling or unable to continue (or enter into). 462 A client may abort the authentication exchange by sending a message, 463 the particulars of which are protocol-specific, to the server, 464 indicating the exchange is aborted. The server may be required by the 465 protocol to return a message in response to the client's abort 466 message. 468 Likewise, a server may abort the authentication exchange by sending a 469 message, the particulars of which are protocol-specific, to the 470 client, indicating the exchange is aborted. 472 3.6. Authentication Outcome 474 At the conclusion of the authentication exchange, the server sends a 475 message, the particulars of which are protocol specific, to the client 476 indicating the outcome of the exchange. 478 The outcome is not successful if 479 - the authentication exchange failed for any reason, 480 - the clients credentials could not be verified, 481 - the server cannot associate an identity with the client's 482 credentials, 483 - the client-provided authorization identity string is malformed, 484 - the identity associated with the client's credentials 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 an optional additional data field in this 492 outcome message. 494 If the outcome is successful and a security layer was negotiated, this 495 layer is then installed. If the outcome is unsuccessful, or a 496 security layer was not negotiated, any existing security is left in 497 place. 499 3.7. Security Layers 501 SASL mechanisms may offer a wide range of services in security layers. 502 Typical services include data integrity and data confidentiality. 503 SASL mechanisms which do not provide a security layer are treated as 504 negotiating no security layer. 506 If use of a security layer is negotiated in the authentication 507 protocol exchange, the layer is installed by the server after 508 indicating the outcome of the authentication exchange and installed by 509 the client upon receipt the outcome indication. In both cases, the 510 layer is installed before transfer of further protocol data. The 511 precise position that the layer takes effect in the protocol data 512 stream is protocol specific. 514 Once the security layer is in effect in the protocol data stream, it 515 remains in effect until either a subsequently negotiated security 516 layer is installed, or the underlying transport connection is closed. 518 When in effect, the security layer processes protocol data into 519 buffers of protected data. If at any time the security layer is 520 unable to continue producing buffers protecting protocol data, the 521 underlying transport connection MUST be closed. If the security layer 522 is not able to decode a received buffer, the underlying connection 523 MUST be closed. In both cases the underlying transport connection 524 SHOULD be closed gracefully. 526 Each buffer of protected data is transferred over the underlying 527 transport connection as a sequence of octets prepended with a four 528 octet field in network byte order that represents the length of the 529 buffer. The length of the protected data buffer MUST be no larger 530 than the maximum size the other side expects. Upon the receipt of a 531 length field whose value is greater than maximum size, the receiver 532 SHOULD close the connection, as this might be a sign of an attack. 534 The maximum size for each side expects is fixed by the mechanism, 535 either through negotiation or by its specification. 537 3.8. Multiple Authentications 539 Unless explicitly permitted in the protocol (as stated in the 540 protocol's technical specification), only one successful SASL 541 authentication exchange may occur in a protocol session. In this 542 case, once an authentication exchange has successfully completed, 543 further attempts to initiate an authentication exchange fail. 545 Where multiple successful SASL authentication exchanges are permitted 546 in the protocol, then in no case may multiple SASL security layers be 547 simultaneously in effect. If a security layer is in effect and a 548 subsequent SASL negotiation selects a second security layer, then the 549 second security layer replaces the first. If a security layer is in 550 effect and a subsequent SASL negotiation selects no security layer, 551 the original security layer remains in effect. 553 Where multiple successful SASL negotiations are permitted in the 554 protocol, the effect of a failed SASL authentication exchange upon the 555 previously established authentication and authorization state is 556 protocol specific. The protocol's technical specification should be 557 consulted to determine whether the previous authentication and 558 authorization state remains in force, or changed to an anonymous 559 state, or otherwise effected. Regardless of the protocol-specific 560 effect upon previously established authentication and authorization 561 state, the previously negotiated security layer remains in effect. 563 4. Protocol Requirements 565 In order for a protocol to offer SASL services, its specification MUST 566 supply the following information: 568 1) A service name, to be selected from the IANA registry of "service" 569 elements for the GSSAPI host-based service name form [RFC2743]. 571 2) Detail any mechanism negotiation facility the protocol provides 572 (see Section 3.2). 574 A protocol SHOULD specify a facility through which the client may 575 discover, both before initiation of the SASL exchange and after 576 installing security layers negotiated by the exchange, the names of 577 the SASL mechanisms the server makes available to the client. The 578 latter is important to allow the client to detect downgrade 579 attacks. This facility is typically provided through the 580 protocol's extensions or capabilities discovery facility. 582 3) Definition of the messages necessary for authentication exchange, 583 including: 585 a) A message to initiate the authentication exchange (see Section 586 3.3). 588 This message MUST contain a field for carrying the name of the 589 mechanism selected by the client. 591 This message SHOULD contain an optional field for carrying an 592 initial response. If the message is defined with this field, 593 the specification MUST describe how messages with an empty 594 initial response are distinguished from messages with no initial 595 response. This field MUST be capable of carrying arbitrary 596 sequences of octets (including zero length sequences and 597 sequences containing zero-valued octets). 599 b) Messages to transfer server challenges and client responses. 600 (see Section 3.4). 602 Each of these messages MUST be capable of carrying arbitrary 603 sequences of octets (including zero length sequences and 604 sequences containing zero-valued octets). 606 c) A message to indicate the outcome of the authentication exchange 607 (see Section 3.6). 609 This message SHOULD contain an optional field for carrying 610 additional data with a successful outcome. If the message is 611 defined with this field, the specification MUST describe how 612 messages with an empty additional data are distinguished from 613 messages with no additional data. This field MUST be capable of 614 carrying arbitrary sequences of octets (including zero length 615 sequences and sequences containing zero-valued octets). 617 4) Prescribe the syntax and semantics of non-empty authorization 618 identity strings (see Section 3.4.1). 620 Specifications are encouraged to prescribe use of existing 621 authorization identity forms as well as existing string 622 representations, such as simple user names [RFC4013]. Protocols 623 whose authorization identities are simple user names SHOULD use of 624 SASLprep [RFC4013] (a profile of the StringPrep [RFC3454] 625 preparation algorithm) as their preparation algorithm. 627 Where the specification does not precisely prescribe how identities 628 in SASL relate to identities used elsewhere in the protocol, for 629 instance in access control policy statements, it may be appropriate 630 for the protocol to provide a facility by which the client may 631 discover information (such as the representation of the 632 authentication identity used in making access control decisions) 633 about established identities for these uses. 635 5) Detail any facility the protocol provides that allows the client 636 and/or server to abort authentication exchange (see Section 3.5). 638 Protocols which support multiple authentications typically allow a 639 client to abort an on-going authentication exchange by initiating a 640 new authentication exchange. Protocols which do not support 641 multiple authentications may require the client to close the 642 connection and start over to abort an on-going authentication 643 exchange. 645 Protocols typically allow the server to abort on-going 646 authentication exchanges by returning a non-successful outcome 647 message. 649 6) Identify precisely where newly negotiated security layers starts to 650 take effect, in both directions (see Section 3.7). 652 Typically, specifications require security layer to start taking 653 effect, in data being sent by the server, on the first octet 654 following the outcome message and, in data being sent by the 655 client, on the first octet sent after receipt of the outcome 656 message. 658 7) If the protocol supports other layered security services, such as 659 Transport Layer Security (TLS) [RFC2246], the specification MUST 660 prescribe the order in which security layers are applied to 661 protocol data. 663 For instance, where a protocol supports both TLS and SASL security 664 layers, the specification could prescribe any of the following: 665 a) SASL security layer is always applied first to data being sent 666 and, hence, applied last to received data, 667 b) SASL security layer is always applied last to data being sent 668 and, hence, applied first to received data, 669 c) Layers are applied in the order in which they were installed, 670 d) Layers are applied in the reverse order in which they were 671 installed, or 672 e) Both TLS and SASL security layers cannot be installed. 674 8) Indicate whether the protocol supports multiple authentications 675 (see Section 3.8). If so, the protocol MUST detail the effect a 676 failed SASL authentication exchange will have upon previously 677 established authentication and authorization state. 679 Protocol specifications SHOULD avoid stating implementation 680 requirements which would hinder replacement of applicable mechanisms. 681 In general, protocol specification SHOULD be mechanism neutral. There 682 are a number reasonable exceptions to this recommendation, including: 683 - detailing how credentials (which are mechanism-specific) are 684 managed in the protocol, 685 - detailing how authentication identities (which are 686 mechanism-specific) and authorization identities (which are 687 protocol-specific) relate to each other, and 688 - detailing which mechanisms are applicable to the protocol. 690 5. Mechanism Requirements 692 SASL mechanism specifications MUST supply the following information: 694 1) The name of the mechanism (see Section 3.1). This name MUST be 695 registered as discussed in Section 8.1. 697 2) A definition of the server-challenges and client-responses of the 698 authentication exchange, as well as: 700 a) An indication whether the client is expected to send data first. 701 If so, when the client does not send data first, the initial 702 challenge MUST be specified as being an empty challenge. 704 b) An indication whether the server is expected to provide 705 additional data when indicating a successful outcome. If so, if 706 the server sends the additional data as a challenge, the 707 specification MUST indicate the response to this challenge is an 708 empty response. 710 SASL mechanisms SHOULD be designed to minimize the number of 711 challenges and responses necessary to complete the exchange. 713 3) An indication of whether the mechanism is capable of transferring 714 authorization identity strings (see Section 3.4.1). While some 715 legacy mechanisms are incapable of transmitting an authorization 716 identity (which means that for these mechanisms the authorization 717 identity is always the empty string), newly defined mechanisms 718 SHOULD be capable of transferring authorization identity strings. 719 The mechanism SHOULD NOT be capable of transferring both no 720 authorization identity string and an empty authorization identity. 722 Mechanisms which are capable of transferring an authorization 723 identity string MUST be capable of transferring arbitrary non-empty 724 sequences of Unicode characters, excluding those which contain the 725 NUL (U+0000) character. Mechanisms SHOULD use the UTF-8 [RFC3629] 726 transformation format. The specification MUST detail how any 727 Unicode code points special to the mechanism which might appear in 728 the authorization identity string are escaped to avoid ambiguity 729 during decoding of the authorization identity string. Typically, 730 mechanisms which have special characters require these special 731 characters to be escaped or encoded in the character string (after 732 encoding it a particular Unicode transformation format) using a 733 data encoding scheme such as Base64 [RFC3548]. 735 4) The specification MUST detail whether or not the mechanism offers a 736 security layer. If the mechanism does, the specification MUST 737 detail the security and other services offered in the layer as well 738 as how these services are to be implemented. 740 5) If the underlying cryptographic technology used by a mechanism 741 supports data integrity, then the mechanism specification MUST 742 integrity protect the transmission of an authorization identity and 743 the negotiation of the security layer. 745 SASL mechanisms SHOULD be protocol neutral. 747 SASL mechanisms SHOULD reuse existing credential and identity forms, 748 as well as associated syntaxes and semantics. 750 SASL mechanisms SHOULD use UTF-8 transformation format [RFC3629] for 751 encoding Unicode [Unicode] code points for transfer. 753 In order to avoid interoperability problems due to differing 754 normalizations, when a mechanism calls for character data is to be 755 used as input to a cryptographic and/or comparison function, the 756 specification MUST detail precisely how and where (client or server) 757 the character data is to be prepared, including all normalizations, 758 for input into the function to ensure proper operation. 760 For simple user names and/or passwords in authentication credentials, 761 SASLprep [RFC4013] (a profile of the StringPrep [RFC3454] preparation 762 algorithm), SHOULD be specified as the preparation algorithm. 764 The mechanism SHOULD NOT use the authorization identity string in 765 generation of any long-term cryptographic keys or hashes as there is 766 no requirement that the authorization identity string be be 767 non-canonical. Long-term, here, means a term longer than the duration 768 of the authentication exchange in which they were generated in. That 769 is, as different clients (of the same or different protocol) may 770 provide different authorization identity strings which are 771 semantically equivalent, use of authorization identity strings in 772 generation of cryptographic keys and hashes will likely lead to 773 interoperability and other problems. 775 6. Security Considerations 777 Security issues are discussed throughout this memo. 779 Many existing SASL mechanisms do not provide adequate protection 780 against passive attacks, let alone active attacks, against the 781 authentication exchange. Many existing SASL mechanisms do not offer 782 any security layers. It is hoped that future SASL mechanisms will 783 provide strong protection against passive and active attacks in the 784 authentication exchange, as well as security layers with strong basis 785 data security features (e.g., data integrity and data confidentiality) 786 services. It is also hoped that future mechanisms will provide more 787 advance data security services like re-keying (see Section 6.1). 789 Regardless, the SASL framework is suspectable to downgrade attacks. 790 Section 6.1 offers a variety of approaches for preventing or detecting 791 these attacks. In some cases, it is appropriate to use data integrity 792 protective services (e.g., TLS) external to SASL to protect against 793 downgrade attacks in SASL. This is especially true when the 794 mechanisms available to the client do not themselves offer adequate 795 integrity or confidentiality protection of the authentication exchange 796 and/or protocol data. 798 6.1. Active Attacks 800 6.1.1. Man-in-the-middle Attacks 802 When the client selects a security layer with at least integrity 803 protection, this protects against an active attacker hijacking the 804 connection and modifying the authentication exchange to negotiate a 805 plain-text connection. In this case, it is important that any 806 security-sensitive protocol negotiations be performed after 807 authentication is complete. Protocols should be designed such that 808 negotiations performed prior to authentication should be either 809 ignored or revalidated once authentication is complete. 811 Negotiation of the SASL mechanism, initiation of the SASL exchange, 812 and portions of the SASL authentication exchange itself are 813 security-sensitive negotiations. 815 When a server or client allows negotiation of authentication 816 mechanisms and/or other security features, it is possible for an 817 active attacker to cause a party to use the least secure services 818 supported. For instance, an attacker can modify the server-advertised 819 mechanism list or can modify client-advertised security feature list 820 within a mechanism response. To protect against this sort of attack, 821 implementations should not advertise mechanisms and/or features which 822 cannot meet their minimum security requirements, should not enter into 823 or continue authentication exchanges which cannot meet their minimum 824 security requirements, and should verify that completed authentication 825 exchanges meets their minimum security requirements. Note that each 826 endpoint needs to independently verify that its security requirements 827 are met. 829 In order to detect downgrade attacks to the least (or less) secure 830 mechanism supported, the client may discover the SASL mechanisms the 831 server makes available both before the SASL authentication exchange 832 and after the negotiated SASL security layer (with at least integrity 833 protection) has been installed through the protocol's mechanism 834 discovery facility. If the client finds that the integrity protected 835 list (the list obtained after the security layer was installed) 836 contains a stronger mechanism than those in the previously obtained 837 list, the client should assume the previously obtained list was 838 modified by an attacker. 840 The client's initiation of the SASL exchange, including the the 841 selection of a SASL mechanism, is done in the clear and may be 842 modified by an active attacker. It is important for any new SASL 843 mechanisms to be designed such that an active attacker cannot obtain 844 an authentication with weaker security properties by modifying the 845 SASL mechanism name and/or the challenges and responses. 847 When use of a security layer is negotiated by the authentication 848 protocol exchange, the receiver should handle gracefully any protected 849 data buffer larger than the defined/negotiated maximal size. In 850 particular, it must not blindly allocate the amount of memory 851 specified in the buffer size field, as this might cause the "out of 852 memory" condition. If the receiver detects a large block, it SHOULD 853 close the connection. 855 Distributed server implementations need to be careful in how they 856 trust other parties. In particular, authentication secrets should 857 only be disclosed to other parties that are trusted to manage and use 858 those secrets in manner acceptable to disclosing party. Applications 859 using SASL assume that SASL security layers providing data 860 confidentiality are secure even when an attacker chooses the text to 861 be protected by the security layer. Similarly applications assume 862 that the SASL security layer is secure even if the attacker can 863 manipulate the cipher-text output of the security layer. New SASL 864 mechanisms are expected to meet these assumptions. 866 6.1.2. Replay Attacks 868 Some mechanisms may be subject to replay attacks unless protected by 869 external data security services (e.g., TLS). 871 6.1.3. Truncation Attacks 873 Most existing SASL security layers to not, themselves, offer 874 protection against truncation attack. In a truncation attack, the 875 active attacker causes the protocol session to be closed, causing a 876 truncation of the possibly integrity protected data stream that leads 877 to behavior of one or both the protocol peers that inappropriately 878 benefits the attacker. Truncation attacks are fairly easy to defend 879 against in connection-oriented application-level protocols. A 880 protocol can defend against these attacks simply by ensuring that each 881 information exchange has a clear final result and that each protocol 882 session has a graceful closure mechanism, and that these are integrity 883 protected. 885 6.2. Passive Attacks 887 Many mechanisms are subject to various passive attacks, including 888 simple eavesdropping of unprotected credential information in 889 mechanisms, such as PLAIN, to online and offline dictionary attacks. 891 6.3. Re-keying 893 The secure or administratively permitted lifetimes of SASL mechanisms' 894 security layers are finite. Cryptographic keys weaken as they are 895 used and as time passes; the more time and/or cipher-text that a 896 cryptanalyst has after the first use of the a key, the easier it is 897 for the cryptanalyst to mount attacks on the key. 899 Administrative limits on security layers lifetime may take the form of 900 time limits expressed in X.509 certificates, Kerberos V tickets, or in 901 directories, and are often desired. In practice one likely effect of 902 administrative security layers lifetime limits is that applications 903 may find that security layers stop working in the middle of 904 application protocol operation, such as, perhaps, during large data 905 transfers. As the result of this the connection will be closed (see 906 Section 3.7), which will result in unpleasant user experience. 908 Re-keying (key renegotiation process) is a way of addressing the 909 weakening of cryptographic keys. SASL framework does not itself 910 provide for re-keying. SASL mechanisms may. Designers of future SASL 911 mechanisms should consider providing re-keying services. 913 Applications that wish to re-key SASL security layers where the 914 mechanism does not provide for re-keying should reauthenticate the 915 same IDs and replace the expired or soon-to-expire security layers. 916 This approach requires support for reauthentication in the application 917 protocols (see Section 3.8). 919 6.5. Other Considerations 921 Unicode security considerations [UTR36] apply to authorization 922 identity strings, and well as UTF-8 [RFC3629] security considerations 923 where UTF-8 is used. SASLprep [RFC4013] and StringPrep [RFC3454] 924 security considerations also apply where used. 926 Protocol designers and implementors should understand the security 927 considerations of mechanisms so they may select mechanisms which are 928 applicable to their needs. 930 Multi-level negotiation of security features is prone to downgrade 931 attack. Protocol designers should avoid offering higher level 932 negotiation of security features in protocols (e.g., above SASL 933 mechanism negotiation) and mechanism designers should avoid lower 934 level negotiation of security features in mechanisms (e.g., below SASL 935 mechanism negotiation). 937 7. IANA Considerations 939 7.1. SASL Mechanism Registry 941 SASL mechanism registry is maintained by IANA. The registry is 942 currently available at 943 . 945 7.1.1. Registration Procedure 947 Registration of a SASL mechanism is requested by filling in the 948 following template: 950 Subject: Registration of SASL mechanism X 952 Family of SASL mechanisms: (YES or NO) 954 SASL mechanism name (or prefix for the family): 956 Security considerations: 958 Published specification (recommended): 960 Person & email address to contact for further information: 962 Intended usage: (One of COMMON, LIMITED USE or OBSOLETE) 964 Owner/Change controller: 966 Note: (Any other information that the author deems interesting may 967 be added here .) 969 and sending it via electronic mail to . 971 IANA has the right to reject obviously bogus registrations, but will 972 perform no review of claims made in the registration form. IANA will 973 register new values on a First Come First Served basis, as defined in 974 BCP 64 [RFC2434]. 976 There is no naming convention for SASL mechanisms; any name that 977 conforms to the syntax of a SASL mechanism name can be registered. 978 However an IETF Standards Track document may reserve a portion of the 979 SASL mechanism namespace ("family of SASL mechanisms") for its own 980 use, amending the registration rules for that portion of the 981 namespace. Each family of SASL mechanisms MUST be identified by a 982 prefix. 984 While the registration procedures do not require expert review, 985 authors of SASL mechanisms are encouraged to seek community review and 986 comment whenever that is feasible. Authors may seek community review 987 by posting a specification of their proposed mechanism as an 988 Internet-Draft. SASL mechanisms intended for widespread use should be 989 standardized through the normal IETF process, when appropriate. 991 7.1.2. Comments on SASL Mechanism Registrations 993 Comments on registered SASL mechanisms should first be sent to the 994 "owner" of the mechanism and/or to the SASL WG mailing list. 996 Submitters of comments may, after a reasonable attempt to contact the 997 owner, request IANA to attach their comment to the SASL mechanism 998 registration itself by sending mail to . At IANA sole 999 discretion, IANA may attach the comment to the registration SASL 1000 mechanism. 1002 7.1.3. Change Control 1004 Once a SASL mechanism registration has been published by IANA, the 1005 author may request a change to its definition. The change request 1006 follows the same procedure as the registration request. 1008 The owner of a SASL mechanism may pass responsibility for the SASL 1009 mechanism to another person or agency by informing IANA; this can be 1010 done without discussion or review. 1012 The IESG may reassign responsibility for a SASL mechanism. The most 1013 common case of this will be to enable changes to be made to mechanisms 1014 where the author of the registration has died, moved out of contact or 1015 is otherwise unable to make changes that are important to the 1016 community. 1018 SASL mechanism registrations may not be deleted; mechanisms which are 1019 no longer believed appropriate for use can be declared OBSOLETE by a 1020 change to their "intended usage" field; such SASL mechanisms will be 1021 clearly marked in the lists published by IANA. 1023 The IESG is considered to be the owner of all SASL mechanisms which 1024 are on the IETF standards track. 1026 7.2. Registration Changes 1028 It is requested that IANA updates the SASL mechanisms registry as 1029 follows: 1031 1) Change the "Intended usage" of the KERBEROS_V4 and SKEY mechanism 1032 registrations to OBSOLETE. 1034 2) Change the "Published specification" of the EXTERNAL mechanism to 1035 this document as indicated below: 1037 Subject: Updated Registration of SASL mechanism EXTERNAL 1038 Family of SASL mechanisms: NO 1039 SASL mechanism name: EXTERNAL 1040 Security considerations: See RFC XXXX, section 9. 1041 Published specification (optional, recommended): RFC XXXX 1042 Person & email address to contact for further information: 1043 Alexey Melnikov 1044 Intended usage: COMMON 1045 Owner/Change controller: IESG 1046 Note: Updates existing entry for EXTERNAL 1048 8. References 1050 [[Note to the RFC Editor: please replace the citation tags used in 1051 referencing Internet-Drafts with tags of the form RFCnnnn where 1052 possible.]] 1054 8.1. Normative References 1056 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1057 Requirement Levels", BCP 14 (also RFC 2119), March 1997. 1059 [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an 1060 IANA Considerations Section in RFCs", BCP 26 (also RFC 1061 2434), October 1998. 1063 [RFC2743] Linn, J., "Generic Security Service 1064 Application Program Interface, Version 2, Update 1", RFC 1065 2743, January 2000. 1067 [RFC3454] Hoffman, P. and M. Blanchet, "Preparation of 1068 Internationalized Strings ('stringprep')", RFC 3454, 1069 December 2002. 1071 [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 1072 10646", RFC 3629 (also STD 63), November 2003. 1074 [RFC4013] Zeilenga, K., "SASLprep: Stringprep Profile for User 1075 Names and Passwords", RFC 4013, February 2005. 1077 [ABNF] Crocker, D. and P. Overell, "Augmented BNF for Syntax 1078 Specifications: ABNF", draft-crocker-abnf-rfc2234bis, a 1079 work in progress. 1081 [ASCII] Coded Character Set--7-bit American Standard Code for 1082 Information Interchange, ANSI X3.4-1986. 1084 [Unicode] The Unicode Consortium, "The Unicode Standard, Version 1085 3.2.0" is defined by "The Unicode Standard, Version 3.0" 1086 (Reading, MA, Addison-Wesley, 2000. ISBN 0-201-61633-5), 1087 as amended by the "Unicode Standard Annex #27: Unicode 1088 3.1" (http://www.unicode.org/reports/tr27/) and by the 1089 "Unicode Standard Annex #28: Unicode 3.2" 1090 (http://www.unicode.org/reports/tr28/). 1092 [CharModel] Whistler, K. and M. Davis, "Unicode Technical Report 1093 #17, Character Encoding Model", UTR17, 1094 , August 1095 2000. 1097 [Glossary] The Unicode Consortium, "Unicode Glossary", 1098 . 1100 8.2. Informative References 1102 [RFC2244] Newman, C. and J. Myers, "ACAP -- Application 1103 Configuration Access Protocol", RFC 2244, November 1997. 1104 [RFC2246] Dierks, T. and, C. Allen, "The TLS Protocol Version 1105 1.0", RFC 2246, January 1999. 1107 [RFC3548] Josefsson, S., "The Base16, Base32, and Base64 Data 1108 Encodings", RFC 3548, July 2003. 1110 [RFC2401] Kent, S., and R. Atkinson, "Security Architecture for 1111 the Internet Protocol", RFC 2401, November 1998. 1113 [SASL-GSSAPI] Melnikov, A. (Editor), "SASL GSSAPI mechanisms", 1114 draft-ietf-sasl-gssapi-XX.txt, a work in progress. 1116 [UTR36] Davis, M., "(Draft) Unicode Technical 1117 Report #36, Character Encoding Model", UTR17, 1118 , February 1119 2005. 1121 9. Editors' Address 1123 Alexey Melnikov 1124 Isode Limited 1125 5 Castle Business Village 1126 36 Station Road 1127 Hampton, Middlesex, 1128 TW12 2BX, United Kingdom 1130 Email: Alexey.Melnikov@isode.com 1131 URI: http://www.melnikov.ca/ 1133 Kurt D. Zeilenga 1134 OpenLDAP Foundation 1136 Email: Kurt@OpenLDAP.org 1138 10. Acknowledgments 1140 This document is a revision of RFC 2222 written by John Myers. 1142 This revision is a product of the IETF Simple Authentication and 1143 Security Layer (SASL) Working Group. 1145 The following individuals contributed significantly to this revision: 1146 Abhijit Menon-Sen, Hallvard B Furuseth, Jeffrey Hutzelman, John Myers, 1147 Luke Howard, Magnus Nystrom, Nicolas Williams, Peter Saint-Andre, RL 1148 'Bob' Morgan, Rob Siemborski, Sam Hartman, Simon Josefsson, Tim Alsop, 1149 and Tony Hansen. 1151 Appendix A. The SASL EXTERNAL Mechanism 1153 This appendix is normative. 1155 The EXTERNAL mechanism allows a client to request the server use 1156 credentials established by means external to the mechanism to 1157 authenticate the client. The external means may be, for instance, IP 1158 Security [RFC2401] or TLS [RFC2246] services. In absence of some 1159 apriori agreement between the client and the server, the client cannot 1160 make any assumption as to what external means the server has used to 1161 obtain the client's credentials, nor make an assumption as to the form 1162 of credentials. For example, the client cannot assume the server will 1163 use the credentials the client has established via TLS. 1165 A.1. EXTERNAL Technical Specification 1167 The name of this mechanism is "EXTERNAL". 1169 The mechanism does not provide a security layer. 1171 The mechanism is capable of transferring an authorization identity 1172 string. If empty, the client is requesting to act as the identity the 1173 server has associated with the client's credentials. If non-empty, 1174 the client is requesting to act as the identity represented by the 1175 string. 1177 The client is expected to send data first in the authentication 1178 exchange. Where the client does not provide an initial response data 1179 in its request to initiate the authentication exchange, the server is 1180 to respond to the request with an empty initial challenge and then the 1181 client is to provide its initial response. 1183 The client sends the initial response containing the UTF-8 [RFC3629] 1184 encoding of the requested authorization identity string. This 1185 response is non-empty when the client is requesting to act as identity 1186 represented by the (non-empty) string. This response is empty when 1187 the client is requesting to act as the identity the server associated 1188 with its authentication credentials. 1190 The syntax of the initial response is specified as a value of the 1191 production detailed below using the Augmented 1192 Backus-Naur Form (ABNF) [RFC2234] notation. 1194 external-initial-resp = authz-id-string 1195 authz-id-string = *( UTF8-char-no-nul ) 1196 UTF8-char-no-nul = UTF8-1-no-nul / UTF8-2 / UTF8-3 / UTF8-4 1197 UTF8-1-no-nul = %x01-7F 1199 where the , , and productions are as defined 1200 in [RFC3629]. 1202 There are no additional challenges and responses. 1204 Hence, the server is to return the outcome of the authentication 1205 exchange. 1207 The exchange fails if 1208 - the client has not established its credentials via external means, 1209 - the client's credentials are inadequate, 1210 - The client provided an empty authorization identity string and the 1211 server unwilling or unable to associate an authorization identity 1212 with the clients credentials, 1213 - The client provided a non-empty authorization identity string which 1214 is invalid per the syntax requirements of the applicable application 1215 protocol specification, 1216 - The client provided a non-empty authorization identity string 1217 representing an identity which the client is not allowed to act as, 1218 or 1219 - the server is unwilling or unable to provide service to the client 1220 for any other reason. 1222 Otherwise the exchange is successful. When indicating a successful 1223 outcome, additional data is not provided. 1225 A.2. SASL EXTERNAL Examples 1227 This section provides examples of EXTERNAL authentication exchanges. 1228 The examples are intended to help the readers under the above text. 1229 The examples are not definitive. The Application Configuration 1230 Access Protocol (ACAP) [RFC2244] is used in the examples. 1232 The first example shows use of EXTERNAL with an empty authorization 1233 identity. In this example, the initial response is not sent the 1234 client's request to initiate authentication exchange. 1236 S: * ACAP (SASL "DIGEST-MD5") 1237 C: a001 STARTTLS 1238 S: a001 OK "Begin TLS negotiation now" 1239 1240 S: * ACAP (SASL "DIGEST-MD5" "EXTERNAL") 1241 C: a002 AUTHENTICATE "EXTERNAL" 1242 S: + "" 1243 C: + "" 1244 S: a002 OK "Authenticated" 1246 In second example shows use of EXTERNAL with an authorization identity 1247 of "fred@example.com". In this example, the initial response is sent 1248 with the clients request to initiate the authentication exchange. 1249 This saves a round-trip. 1251 S: * ACAP (SASL "DIGEST-MD5") 1252 C: a001 STARTTLS 1253 S: a001 OK "Begin TLS negotiation now" 1254 1255 S: * ACAP (SASL "DIGEST-MD5" "EXTERNAL") 1256 C: a002 AUTHENTICATE "EXTERNAL" {16+} 1257 C: fred@example.com 1258 S: a002 NO "Cannot assume requested authorization identity" 1260 A.3. Security Considerations 1262 The EXTERNAL mechanism provides no security protection; it is 1263 vulnerable to spoofing by either client or server, active attack, and 1264 eavesdropping. It should only be used when adequate security services 1265 have been established. 1267 Appendix B. Changes since RFC 2222 1269 This appendix is non-normative. 1271 The material in RFC 2222 was significantly rewritten in the production 1272 of this document. 1274 RFC 2222, by not stating the authorization identity string was a 1275 string of Unicode characters, let alone character data, implied the 1276 authorization identity string was a string of octets. 1278 - The authorization identity string is now defined as a string of 1279 Unicode characters. The NUL (U+0000) is prohibited. While protocol 1280 specifications are responsible for defining the authorization 1281 identity form, as well as the Unicode string syntax and related 1282 semantics, mechanism specifications are responsible for defining how 1283 the Unicode string is carried in the authentication exchange. 1285 The following technical change was made to the EXTERNAL mechanism: 1287 - The authorization identity string is to be UTF-8 encoded. 1289 It is noted that protocol and mechanism specification requirements 1290 have been significant tightened. Existing protocol and mechanism 1291 specifications will need to be updated to meet these requirements. 1293 Intellectual Property Rights 1294 The IETF takes no position regarding the validity or scope of any 1295 Intellectual Property Rights or other rights that might be claimed to 1296 pertain to the implementation or use of the technology described in 1297 this document or the extent to which any license under such rights 1298 might or might not be available; nor does it represent that it has 1299 made any independent effort to identify any such rights. Information 1300 on the procedures with respect to rights in RFC documents can be found 1301 in BCP 78 and BCP 79. 1303 Copies of IPR disclosures made to the IETF Secretariat and any 1304 assurances of licenses to be made available, or the result of an 1305 attempt made to obtain a general license or permission for the use of 1306 such proprietary rights by implementers or users of this specification 1307 can be obtained from the IETF on-line IPR repository at 1308 http://www.ietf.org/ipr. 1310 The IETF invites any interested party to bring to its attention any 1311 copyrights, patents or patent applications, or other proprietary 1312 rights that may cover technology that may be required to implement 1313 this standard. Please address the information to the IETF at 1314 ietf-ipr@ietf.org. 1316 Full Copyright 1318 Copyright (C) The Internet Society (2005). This document is subject 1319 to the rights, licenses and restrictions contained in BCP 78, and 1320 except as set forth therein, the authors retain all their rights. 1322 This document and the information contained herein are provided on an 1323 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1324 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 1325 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 1326 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 1327 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1328 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.