idnits 2.17.1 draft-ietf-sasl-rfc2222bis-04.txt: ** The Abstract section seems to be numbered Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by 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. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity. ** The document is more than 15 pages and seems to lack a Table of Contents. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 25 longer pages, the longest (page 2) being 60 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 26 pages -- Found 26 instances of the string 'FORMFEED[Page...' -- is this a case of missing nroff postprocessing? Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 5 instances of too long lines in the document, the longest one being 5 characters in excess of 72. == 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. -- The draft header indicates that this document obsoletes RFC2222, but the abstract doesn't seem to mention this, which it should. 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 (December 2003) is 7438 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: 'RFC 3501' is mentioned on line 374, but not defined ** Obsolete undefined reference: RFC 3501 (Obsoleted by RFC 9051) == Missing Reference: 'StringPrep' is mentioned on line 376, but not defined == Unused Reference: 'Stringprep' is defined on line 944, but no explicit reference was found in the text == Unused Reference: 'RFC-INSTRUCTIONS' is defined on line 986, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2234 (ref. 'ABNF') (Obsoleted by RFC 4234) -- Possible downref: Non-RFC (?) normative reference: ref. 'ASCII' -- Possible downref: Non-RFC (?) normative reference: ref. 'ISO-10646' -- Possible downref: Non-RFC (?) normative reference: ref. 'Unicode' ** Obsolete normative reference: RFC 3454 (ref. 'Stringprep') (Obsoleted by RFC 7564) -- No information found for draft-ietf-sasl-saslprep-XX - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'SASLPrep' -- No information found for draft-yergeau-rfc2279bis-XX - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'UTF-8' -- No information found for draft-ietf-sasl-gssapi-XX - is the name correct? -- No information found for draft-ietf-sasl-rfc2831bis-XX - is the name correct? -- Obsolete informational reference (is this intentional?): RFC 2821 (ref. 'SMTP') (Obsoleted by RFC 5321) -- Obsolete informational reference (is this intentional?): RFC 2554 (ref. 'SMTP-AUTH') (Obsoleted by RFC 4954) -- No information found for draft-ietf-xmpp-core-XX - is the name correct? -- Obsolete informational reference (is this intentional?): RFC 3548 (ref. 'BASE64') (Obsoleted by RFC 4648) -- Obsolete informational reference (is this intentional?): RFC 2223 (ref. 'RFC-INSTRUCTIONS') (Obsoleted by RFC 7322) Summary: 10 errors (**), 0 flaws (~~), 10 warnings (==), 18 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group A. Melnikov 3 Internet Draft Editor 4 Document: draft-ietf-sasl-rfc2222bis-04.txt December 2003 5 Obsoletes: RFC 2222 Expires in six months 7 Simple Authentication and Security Layer (SASL) 9 Status of this Memo 11 This document is an Internet Draft and is in full conformance with 12 all provisions of Section 10 of RFC 2026. 14 Internet Drafts are working documents of the Internet Engineering 15 Task Force (IETF), its Areas, and its Working Groups. Note that 16 other groups may also distribute working documents as Internet 17 Drafts. Internet Drafts are draft documents valid for a maximum of 18 six months. Internet Drafts may be updated, replaced, or obsoleted 19 by other documents at any time. It is not appropriate to use 20 Internet Drafts as reference material or to cite them other than as 21 ``work in progress''. 23 The list of current Internet-Drafts can be accessed at 24 http://www.ietf.org/ietf/1id-abstracts.txt 26 The list of Internet-Draft Shadow Directories can be accessed at 27 http://www.ietf.org/shadow.html. 29 A revised version of this draft document will be submitted to the RFC 30 editor as a Draft Standard for the Internet Community. Discussion 31 and suggestions for improvement are requested. Distribution of this 32 draft is unlimited. 34 When published as an RFC this document will obsolete RFC 2222. 36 Internet DRAFT SASL 21 December 2003 38 1. Abstract 40 The Simple Authentication and Security Layer (SASL) provides a method 41 for adding authentication support with an optional security layer to 42 connection-based protocols. It also describes a structure for 43 authentication mechanisms. The result is an abstraction layer 44 between protocols and authentication mechanisms such that any SASL- 45 compatible authentication mechanism can be used with any SASL- 46 compatible protocol. 48 This document describes how a SASL authentication mechanism is 49 structured, describes how a protocol adds support for SASL, defines 50 the protocol for carrying a security layer over a connection, and 51 defines the EXTERNAL SASL authentication mechanism. 53 2. Organization of this document 55 2.1. How to read this document 57 This document is written to serve two different audiences, protocol 58 designers using this specification to support authentication in their 59 protocol, and implementors of clients or servers for those protocols 60 using this specification. 62 The sections "Overview", "Authentication Mechanisms", "Protocol 63 Profile Requirements", "Specific Issues", and "Security 64 Considerations" cover issues that protocol designers need to 65 understand and address in profiling this specification for use in a 66 specific protocol. 68 Implementors of a protocol using this specification need the 69 protocol-specific profiling information in addition to the 70 information in this document. 72 2.2. Conventions used in this document 74 In examples, "C:" and "S:" indicate lines sent by the client and 75 server respectively. 77 The key words "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", and "MAY" 78 in this document are to be interpreted as defined in "Key words for 79 use in RFCs to Indicate Requirement Levels" [KEYWORDS]. 81 Character names in this document use the notation for code points and 82 names from the Unicode Standard [Unicode]. For example, the letter 83 "a" may be represented as either or . 85 This document uses terms "integrity protection" and "confidentiality 87 Internet DRAFT SASL 21 December 2003 89 protection". The former references to a security layer, that is able 90 to detect data modification by using some kind of hash. However, 91 integrity protection doesn't make the data unreadable to an attacker. 92 Confidentiality protection is a security layer, that is able to make 93 the data unreadable to an attacker by using encryption. 94 Confidentiality protection usually implies integrity protection. 96 3. Overview 98 The Simple Authentication and Security Layer (SASL) is a method for 99 adding authentication support to connection-based protocols. 101 The SASL specification has three layers, as indicated in the diagram 102 below. At the top, a protocol definition using SASL specifies a 103 profile, including a command for identifying and authenticating a 104 user to a server and for optionally negotiating a security layer for 105 subsequent protocol interactions. At the bottom, a SASL mechanism 106 definition specifies an authentication mechanism. The SASL 107 framework, specified by this document, constrains the behavior of 108 protocol profiles and mechanisms, separating protocol from mechanism 109 and defining how they interact. 111 SMTP Protocol LDAP Protocol Etc 112 Profile Profile . . . 113 ----- | -----// 114 | // 115 SASL framework 116 / | \ 117 /----- | -----\ 118 EXTERNAL DIGEST-MD5 Etc 119 SASL mechanism SASL mechanism . . . 121 This separation between the definition of protocols and the 122 definition of authentication mechanisms is crucial. It permits an 123 authentication mechanism to be defined once, making it usable by any 124 SASL protocol profile. In many implementations, the same SASL 125 mechanism code is used for multiple protocols. 127 4. Authentication mechanisms 129 SASL mechanisms are named by strings, from 1 to 20 characters in 130 length, consisting of upper-case ASCII [ASCII] letters, digits, 131 hyphens, and/or underscores. SASL mechanism names must be registered 132 with the Internet Assigned Numbers Authority (IANA). IETF standards 133 track documents may direct the IANA to reserve a portion of the SASL 134 mechanism namespace and may specify different registration criteria 135 for the reserved portion; the GSSAPI mechanism specification [SASL- 137 Internet DRAFT SASL 21 December 2003 139 GSSAPI] does this. Procedures for registering new SASL mechanisms are 140 given in the section 8. 142 The "sasl-mech" rule below defines the syntax of a SASL mechanism 143 name. This uses the Augmented Backus-Naur Form (ABNF) notation as 144 specified in [ABNF] and the ABNF core rules as specified in Appendix 145 A of the ABNF specification [ABNF]. 147 sasl-mech = 1*20mech-char 148 mech-char = %x41-5A / DIGIT / "-" / "_" 149 ; mech names restricted to uppercase ASCII letters, 150 ; digits, "-" and "_" 152 4.1. Authentication protocol exchange 154 A SASL mechanism is responsible for conducting an authentication 155 protocol exchange. This consists of a series of server challenges 156 and client responses, the contents of which are specific to and 157 defined by the mechanism. To the protocol, the challenges and 158 responses are opaque binary tokens of arbitrary length. The 159 protocol's profile then specifies how these binary tokens are then 160 encoded for transfer over the connection. 162 After receiving an authentication command or any client response, a 163 server mechanism may issue a challenge, indicate failure, or indicate 164 completion. The server mechanism may return additional data with a 165 completion indication. The protocol's profile specifies how each of 166 these is then represented over the connection. 168 After receiving a challenge, a client mechanism may issue a response 169 or abort the exchange. The protocol's profile specifies how each of 170 these is then represented over the connection. 172 During the authentication protocol exchange, the mechanism performs 173 authentication, transmits an authorization identity (frequently known 174 as a userid) from the client to server, and negotiates the use of a 175 mechanism-specific security layer. If the use of a security layer is 176 agreed upon, then the mechanism must also define or negotiate the 177 maximum security layer buffer size that each side is able to receive. 179 4.2. Authorization and authentication identities 181 SASL authentication deals with two identities: the authorization 182 identity and the authentication identity. The transmitted 183 authorization identity may be an empty string (zero length), but the 184 transmitted authentication identity may not be an empty string. 186 Internet DRAFT SASL 21 December 2003 188 While some legacy mechanisms are incapable of transmitting an 189 authorization identity (which means that for these mechanisms the 190 authorization identity is always the empty string), newly defined 191 mechanisms SHOULD be capable of transmiting a non-empty authorization 192 identity. 194 Authentication identity is the identity derived from the client's 195 authentication credentials. 197 The authorization identity is used by the server as the primary 198 identity for making access policy decisions. 200 4.2.1. Authorization identities and proxy authentication 202 With any mechanism, transmitting an authorization identity of the 203 empty string directs the server to derive the authorization identity 204 from the client's authentication identity. 206 If the authorization identity transmitted during the authentication 207 protocol exchange is not the empty string, this is typically referred 208 to as "proxy authentication". This feature permits agents such as 209 proxy servers to authenticate using their own credentials, yet 210 request the access privileges of the identity for which they are 211 proxying. 213 The server makes an implementation defined policy decision as to 214 whether the authentication identity is permitted to have the access 215 privileges of the authorization identity and whether the 216 authorization identity is permitted to receive service. If it is 217 not, the server indicates failure of the authentication protocol 218 exchange. 220 As a client might not have the same information as the server, 221 clients SHOULD NOT derive authorization identities from 222 authentication identities. Instead, clients SHOULD provide no (or 223 empty) authorization identity when the user has not provided an 224 authorization identity. 226 The server SHOULD verify that a received authorization identity is in 227 the correct form. Profiles whose authorization identities are simple 228 user names (e.g. IMAP [RFC 3501]) SHOULD use "SASLPrep" profile 229 [SASLPrep] of the "stringprep" algorithm [StringPrep] to prepare 230 these names for matching. The profiles MAY use a stringprep profile 231 that is more strict than "SASLPrep". If the preparation of the 232 authorization identity fails or results in an empty string, the 233 server MUST fail the authentication exchange. The only exception to 234 this rule is when the received authorization identity is already the 236 Internet DRAFT SASL 21 December 2003 238 empty string. 240 4.2.2. Authorization Identity Format 242 An authorization identity is a string of zero or more ISO 10646 243 [ISO-10646] coded characters. The NUL character is not 244 permitted in authorization identities. 246 The character encoding scheme used (see [CHARSET-POLICY] for IETF 247 policy regarding character sets in IETF protocols) for transmitting 248 an authorization identity over protocol is specified in each 249 authentication mechanism (with the authentication mechanism's data 250 being further restricted/encoded by the protocol profile). 251 Authentication mechanisms SHOULD encode these and other strings in 252 UTF-8 [UTF-8]. 254 Mechanisms are expected to be capable of carrying the entire Unicode 255 repertoire (with the exception of the NUL character). An 256 authorization identity of the empty string and and an absent 257 authorization identity MUST be treated as equivalent. That is, a 258 mechanism which provides an optional field for an authorization 259 identity, SHOULD NOT allow that field, when present, to be empty. 260 The meaning of an authorization identity of the empty string is 261 described in the previous section. 263 4.3. Security layers 265 If use of a security layer is negotiated by the authentication 266 protocol exchange, the security layer is applied to all subsequent 267 data sent over the connection (until another security layer is 268 negotiated; see also section 6.3). The security layer takes effect 269 immediately following the last response of the authentication 270 exchange for data sent by the client and the completion indication 271 for data sent by the server. 273 Note, that all SASL mechanisms that are unable to negotiate a 274 security layer automatically select no security layer. 276 Once the security layer is in effect, the protocol stream is 277 processed by the security layer into buffers of security encoded 278 data. Each buffer of security encoded data is transferred over the 279 connection as a stream of octets prepended with a four octet field in 280 network byte order that represents the length of the following 281 buffer. The length of the security encoded data buffer MUST be no 282 larger than the maximum size that was either defined in the mechanism 283 specification or negotiated by the other side during the 284 authentication protocol exchange. Upon the receipt of a data buffer 286 Internet DRAFT SASL 21 December 2003 288 which is larger than the defined/negotiated maximal buffer size, the 289 receiver SHOULD close the connection. This might be a sign of an 290 attack or a buggy implementation. 292 4.4. Character string issues 294 Authentication mechanisms SHOULD encode character strings in UTF-8 295 [UTF-8] (see [CHARSET-POLICY] for IETF policy regarding character 296 sets in IETF protocols). In order to avoid noninteroperability due 297 to differing normalizations, when a mechanism specifies that a string 298 authentication identity or password used as input to a cryptographic 299 function (or used for comparison) it SHOULD specify that the string 300 first be prepared using the "SASLPrep" profile [SASLPrep] of the 301 "stringprep" algorithm [StringPrep]. There are three entities that 302 has to deal with this issue: a client (upon getting user input or 303 retrieving a value from configuration), a server (upon receiving the 304 value from the client) and a utility that is able to store 305 passwords/hashes in a database that can be later used by the server. 306 SASL mechanisms must define which entity (or entities) must perform 307 the preparation. If preparation fails or results in an empty string, 308 the entity doing the preparation SHALL fail the authentication 309 exchange (or, in case of the utility, refuse to store the data). 311 5. Protocol profile requirements 313 In order to use this specification, a protocol definition MUST supply 314 the following information: 316 A service name, to be selected from the IANA registry of "service" 317 elements for the GSSAPI host-based service name form [GSSAPI]. This 318 service name is made available to the authentication mechanism. 320 The registry is available at the URL 321 . 323 A definition of the command to initiate the authentication protocol 324 exchange. This command must have as a parameter the name of the 325 mechanism being selected by the client. 327 The command SHOULD have an optional parameter giving an initial 328 response. This optional parameter allows the client to avoid a round 329 trip when using a mechanism which is defined to have the client send 330 data first. When this initial response is sent by the client and the 331 selected mechanism is defined to have the server start with an 332 initial challenge, the command fails. See section 6.1 of this 333 document for further information. 335 Internet DRAFT SASL 21 December 2003 337 A definition of the method by which the authentication protocol 338 exchange is carried out, including how the challenges and responses 339 are encoded, how the server indicates completion or failure of the 340 exchange, how the client aborts an exchange, and how the exchange 341 method interacts with any line length limits in the protocol. 343 The exchange method SHOULD allow the server to include an optional 344 data ("optional challenge") with a success notification. This allows 345 the server to avoid a round trip when using a mechanism which is 346 defined to have the server send additional data along with the 347 indication of successful completion. See section 6.2 of this 348 document for further information. 350 In addition, a protocol profile SHOULD specify a mechanism through 351 which a client may obtain the names of the SASL mechanisms available 352 to it. This is typically done through the protocol's extensions or 353 capabilities mechanism. 355 Identification of the octet where any negotiated security layer 356 starts to take effect, in both directions. 358 Specify if the protocol profile supports "multiple authentications" 359 (see section 6.3). 361 <> 364 If both TLS and SASL security layer are allowed to be negotiated by 365 the protocol, the protocol profile MUST define in which order they 366 are applied to a cleartext data sent over the connection. 368 A protocol profile MAY further refine the definition of an 369 authorization identity by adding additional syntactic restrictions 370 and protocol-specific semantics. A protocol profile MUST specify the 371 form of the authorization identity (since it is protocol specific, as 372 opposed to the authentication identity, which is mechanism specific) 373 and how authorization identities are to be compared. Profiles whose 374 authorization identities are simple user names (e.g. IMAP [RFC 3501]) 375 SHOULD use "SASLPrep" profile [SASLPrep] of the "stringprep" 376 algorithm [StringPrep] to prepare these names for matching. The 377 profiles MAY use a stringprep profile that is more strict than 378 SASLPrep. 380 A protocol profile SHOULD NOT attempt to amend the definition of 381 mechanisms or make mechanism-specific encodings. This breaks the 382 separation between protocol and mechanism that is fundamental to the 383 design of SASL. Likewise, SASL mechanisms SHOULD be profile neutral. 385 Internet DRAFT SASL 21 December 2003 387 6. Specific issues 389 6.1. Client sends data first 391 Some mechanisms specify that the first data sent in the 392 authentication protocol exchange is from the client to the server. 394 If a protocol's profile permits the command which initiates an 395 authentication protocol exchange to contain an initial client 396 response, this parameter SHOULD be used with such mechanisms. 398 If the initial client response parameter is not given, or if a 399 protocol's profile does not permit the command which initiates an 400 authentication protocol exchange to contain an initial client 401 response, then the server issues a challenge with no data. The 402 client's response to this challenge is then used as the initial 403 client response. (The server then proceeds to send the next 404 challenge, indicates completion, or indicates failure.) 406 6.1.1. Examples 408 The following are two examples of an SECURID authentication [SASL- 409 SECURID] in the SMTP protocol [SMTP]. In the first example below, 410 the client is trying fast reauthentication by sending the initial 411 response: 413 S: 220-smtp.example.com ESMTP Server 414 C: EHLO client.example.com 415 S: 250-smtp.example.com Hello client.example.com, pleased to meet you 416 S: 250-AUTH GSSAPI SECURID 417 S: 250 DSN 418 C: AUTH SECURID AG1hZ251cwAxMjM0NTY3OAA= 419 S: 235 Authentication successful 421 The example below is almost identical to the previous, but here 422 the client chooses not to use the initial response parameter. 424 S: 220-smtp.example.com ESMTP Server 425 C: EHLO client.example.com 426 S: 250-smtp.example.com Hello client.example.com, pleased to meet you 427 S: 250-AUTH GSSAPI SECURID 428 S: 250 DSN 429 C: AUTH SECURID 430 S: 334 431 C: AG1hZ251cwAxMjM0NTY3OAA= 432 S: 235 Authentication successful 434 Internet DRAFT SASL 21 December 2003 436 Section 7.2 contains an additional example. 438 6.2. Server returns success with additional data 440 Some mechanisms may specify that additional data be sent to the 441 client along with an indication of successful completion of the 442 exchange. This data would, for example, authenticate the server to 443 the client. 445 If a protocol's profile does not permit this additional data to be 446 returned with a success indication, then the server issues the data 447 as a server challenge, without an indication of successful 448 completion. The client then responds with no data. After receiving 449 this empty response, the server then indicates successful completion 450 (with no additional data). 452 Client implementors should be aware of an additional failure case 453 that might occur when the profile supports sending the additional 454 data with success. Imagine that an active attacker is trying to 455 impersonate the server and sends faked data, which should be used to 456 authenticate the server to the client, with success. (A similar 457 situation can happen when either the server and/or the client has a 458 bug and they calculate different responses.) After checking the data, 459 the client will think that the authentication exchange has failed, 460 however the server will think that the authentication exchange has 461 completed successfully. At this point the client can not abort the 462 authentication exchange, it SHOULD close the connection instead. 463 However, if the profile did not support sending of additional data 464 with success, the client could have aborted the exchange at the very 465 last step of the authentication exchange. 467 6.2.1. Examples 469 The following are two examples of a DIGEST-MD5 authentication [SASL- 470 DIGEST] in the XMPP protocol [XMPP]. In the first example below, the 471 server is sending mutual authentication data with success. 473 C: 478 S: 487 S: 488 489 DIGEST-MD5 490 CRAM-MD5 491 492 493 C: 495 S: 496 cmVhbG09InNvbWVyZWFsbSIsbm9uY2U9Ik9BNk1HOXRFUUdtMmhoIixxb3A9ImF1dGgi 497 LGNoYXJzZXQ9dXRmLTgsYWxnb3JpdGhtPW1kNS1zZXNzCg== 498 499 C: 500 dXNlcm5hbWU9InNvbWVub2RlIixyZWFsbT0ic29tZXJlYWxtIixub25jZT0i 501 T0E2TUc5dEVRR20yaGgiLGNub25jZT0iT0E2TUhYaDZWcVRyUmsiLG5jPTAw 502 MDAwMDAxLHFvcD1hdXRoLGRpZ2VzdC11cmk9InhtcHAvZXhhbXBsZS5jb20i 503 LHJlc3BvbnNlPWQzODhkYWQ5MGQ0YmJkNzYwYTE1MjMyMWYyMTQzYWY3LGNo 504 YXJzZXQ9dXRmLTgK 505 506 S: 507 cnNwYXV0aD1lYTQwZjYwMzM1YzQyN2I1NTI3Yjg0ZGJhYmNkZmZmZAo= 508 510 The example below is almost identical to the previous, but here 511 the server chooses not to use the additional data with success. 513 C: 518 S: 524 S: 525 526 DIGEST-MD5 527 CRAM-MD5 528 529 530 C: 532 S: 533 cmVhbG09InNvbWVyZWFsbSIsbm9uY2U9Ik9BNk1HOXRFUUdtMmhoIixxb3A9ImF1dGgi 535 Internet DRAFT SASL 21 December 2003 537 LGNoYXJzZXQ9dXRmLTgsYWxnb3JpdGhtPW1kNS1zZXNzCg== 538 539 C: 540 dXNlcm5hbWU9InNvbWVub2RlIixyZWFsbT0ic29tZXJlYWxtIixub25jZT0i 541 T0E2TUc5dEVRR20yaGgiLGNub25jZT0iT0E2TUhYaDZWcVRyUmsiLG5jPTAw 542 MDAwMDAxLHFvcD1hdXRoLGRpZ2VzdC11cmk9InhtcHAvZXhhbXBsZS5jb20i 543 LHJlc3BvbnNlPWQzODhkYWQ5MGQ0YmJkNzYwYTE1MjMyMWYyMTQzYWY3LGNo 544 YXJzZXQ9dXRmLTgK 545 546 S: 547 cnNwYXV0aD1lYTQwZjYwMzM1YzQyN2I1NTI3Yjg0ZGJhYmNkZmZmZAo= 548 549 C: 550 S: 552 6.3. Multiple authentications 554 Unless otherwise stated by the protocol's profile, only one 555 successful SASL negotiation may occur in a protocol session. In this 556 case, once an authentication protocol exchange has successfully 557 completed, further attempts to initiate an authentication protocol 558 exchange fail. 560 If a profile explicitly permits multiple successful SASL negotiations 561 to occur, then in no case may multiple security layers be 562 simultaneously in effect. If a security layer is in effect and a 563 subsequent SASL negotiation selects a second security layer, then the 564 second security layer replaces the first. If a security layer is in 565 effect and a subsequent SASL negotiation selects no security layer, 566 the original security layer remains in effect. 568 Note, that keeping the original security layer is a subject to a 569 class of security attack described later in this section. However, at 570 the time of the writing of this document the Working Group consensus 571 is not to change SASL handling of security layers, as the risk of 572 such attacks is considered to be low. The protocol profiles that 573 allow for reauthentication SHOULD recommend to always negotiate 574 another security layer, once a security layer was installed. 576 Also note, that if a subsequent authentication fails, the protocol 577 profile MAY allow the connection state to return to non- 578 authenticated, however the previously negotiated security layer MUST 579 NOT be removed. Only a successful reauthentication is able 580 replace/remove the previously negotiated security layer. 582 Let's assume that the protected resources on a server are partitioned 583 into a set of protection spaces, each with its own authentication 584 mechanisms and/or authorization database. Let's use the term "realm" 586 Internet DRAFT SASL 21 December 2003 588 to reference any such protected space. Conceptually, realm is a named 589 collection of user's accounts. For example, a proxy/frontend can use 590 different realms for different servers/backends it represents. 592 Now consider the following scenario. A client has already 593 authenticated and established a security layer with "Realm A" which 594 is managed by the server AA. Now the same client authenticates to 595 "Realm B" (managed by the server BB) without negotiating a new 596 security layer, while the security layer negotiated with "Realm A" 597 remains in effect. The server BB is now able observe how known 598 cleartext is encrypted. This scenario enables the server BB to make 599 guesses about previously observed ciphertext between the client and 600 the server AA using the server's SASL engine as an oracle. This 601 scenario is illustrated below: 603 Internet DRAFT SASL 21 December 2003 605 +---------+ +---------+ 606 | | | | 607 | Realm B | | Realm A | 608 | | | | 609 +---------+ +---------+ 610 | ^ | 611 | : +-----------+ | 612 Traffic from | : | Encryption| | Traffic from A 613 B to client +-------->| end point |<-------+ to client 614 : | (SSL/SASL)| 615 : +-----------+ 616 : | 617 : | 618 : +---+ 619 : | | 620 : | | 621 : | | Encryption tunnel, e.g. SASL or SSL, 622 : | | between the server 623 (1) Recording +---------:| | and a single client only. 624 encrypted | | Separate tunnels to different 625 traffic between | | clients. 626 Realm A and client +---+ 627 | 628 | 629 +-----------> Traffic to clients 631 7. The EXTERNAL mechanism 633 The mechanism name associated with external authentication is 634 "EXTERNAL". 636 The client sends an initial response with the UTF-8 encoding of the 637 authorization identity. The form of the authorization identity is 638 further restricted by the application-level protocol's SASL profile. 640 The server uses information, external to SASL, to determine whether 641 the client is authorized to authenticate as the authorization 642 identity. If the client is so authorized, the server indicates 643 successful completion of the authentication exchange; otherwise the 644 server indicates failure. 646 The system providing this external information may be, for example, 647 IPSec or TLS. However, the client can make no assumptions as to what 648 information the server can use in determining client authorization. 649 E.g., just because TLS was established, doesn't mean that the server 650 will use the information provided by TLS. 652 If the client sends the empty string as the authorization identity 654 Internet DRAFT SASL 21 December 2003 656 (thus requesting that the authorization identity be derived from the 657 client's authentication credentials), the authorization identity is 658 to be derived from authentication credentials which exist in the 659 system that is providing the external authentication. 661 7.1. Formal syntax 663 The following syntax specification uses the augmented Backus-Naur 664 Form (BNF) notation as specified in [ABNF]. This uses the ABNF core 665 rules as specified in Appendix A of the ABNF specification [ABNF]. 666 Non-terminals referenced but not defined below are as defined by 667 [UTF-8]. 669 The "extern-init-resp" rule below defines the initial response sent 670 from client to server. 672 extern-init-resp = *( UTF8-char-no-nul ) 674 UTF8-char-no-nul = UTF8-1-no-nul / UTF8-2 / UTF8-3 / UTF8-4 676 UTF8-1-no-nul = %x01-7F 678 7.2. Example 680 The following is an example of an EXTERNAL authentication in the SMTP 681 protocol [SMTP]. In this example, the client is proxy 682 authenticating, sending the authorization id "fred". The server has 683 determined the client's identity through IPsec and has a security 684 policy that permits that identity to proxy authenticate as any other 685 identity. 687 To the protocol profile, the four octet sequence "fred" is an opaque 688 binary data. The SASL protocol profile for SMTP [SMTP-AUTH] specifies 689 that server challenges and client responses are encoded in BASE64 690 [BASE64]; the BASE64 encoding of "fred" is "ZnJlZA==". 692 S: 220 smtp.example.com ESMTP server ready 693 C: EHLO jgm.example.com 694 S: 250-smtp.example.com 695 S: 250 AUTH DIGEST-MD5 EXTERNAL 696 C: AUTH EXTERNAL ZnJlZA== 697 S: 235 Authentication successful. 699 8. IANA Considerations 701 Internet DRAFT SASL 21 December 2003 703 8.1. Guidelines for IANA 705 It is requested that IANA updates the SASL mechanisms registry as 706 follows: 708 Change the "Intended usage" of the KERBEROS_V4 and SKEY mechanism 709 registrations to OBSOLETE. Change the "Published specification" 710 of the EXTERNAL mechanism to this document. Updated registration 711 is provided in Section 8.6. 713 8.2. Registration procedure 715 Registration of a SASL mechanism is done by filling in the template 716 in section 8.5 and sending it via electronic mail to . 717 IANA has the right to reject obviously bogus registrations, but will 718 perform no review of claims made in the registration form. SASL 719 mechanism registrations are currently available at the URL 720 . 722 There is no naming convention for SASL mechanisms; any name that 723 conforms to the syntax of a SASL mechanism name can be registered. 724 An IETF Standards Track document may reserve a portion of the SASL 725 mechanism namespace ("family of SASL mechanisms") for its own use, 726 amending the registration rules for that portion of the namespace. 727 Each family of SASL mechanisms MUST be identified by a prefix. 729 While the registration procedures do not require it, authors of SASL 730 mechanisms are encouraged to seek community review and comment 731 whenever that is feasible. Authors may seek community review by 732 posting a specification of their proposed mechanism as an Internet- 733 Draft. SASL mechanisms intended for widespread use should be 734 standardized through the normal IETF process, when appropriate. 736 8.3. Comments on SASL mechanism registrations 738 Comments on registered SASL mechanisms should first be sent to the 739 "owner" of the mechanism and/or to the SASL WG mailing list. 740 Submitters of comments may, after a reasonable attempt to contact the 741 owner, request IANA to attach their comment to the SASL mechanism 742 registration itself. If IANA approves of this, the comment will be 743 made accessible in conjunction with the SASL mechanism registration 744 itself. 746 Internet DRAFT SASL 21 December 2003 748 8.4. Change control 750 Once a SASL mechanism registration has been published by IANA, the 751 author may request a change to its definition. The change request 752 follows the same procedure as the registration request. 754 The owner of a SASL mechanism may pass responsibility for the SASL 755 mechanism to another person or agency by informing IANA; this can be 756 done without discussion or review. 758 The IESG may reassign responsibility for a SASL mechanism. The most 759 common case of this will be to enable changes to be made to 760 mechanisms where the author of the registration has died, moved out 761 of contact or is otherwise unable to make changes that are important 762 to the community. 764 SASL mechanism registrations may not be deleted; mechanisms which are 765 no longer believed appropriate for use can be declared OBSOLETE by a 766 change to their "intended use" field; such SASL mechanisms will be 767 clearly marked in the lists published by IANA. 769 The IESG is considered to be the owner of all SASL mechanisms which 770 are on the IETF standards track. 772 8.5. Registration template 774 Subject: Registration of SASL mechanism X 776 Family of SASL mechanisms: (YES or NO) 778 SASL mechanism name (or prefix for the family): 780 Security considerations: 782 Published specification (optional, recommended): 784 Person & email address to contact for further information: 786 Intended usage: 788 (One of COMMON, LIMITED USE or OBSOLETE) 790 Owner/Change controller: 792 (Any other information that the author deems interesting may be 793 added below this line.) 795 Internet DRAFT SASL 21 December 2003 797 8.6. The EXTERNAL mechanism registration 799 It is requested that the SASL Mechanism registry [IANA-SASL] entry 800 for the EXTERNAL mechanism be updated to reflect that this document 801 now provides its technical specification. 803 Subject: Updated Registration of SASL mechanism EXTERNAL 805 Family of SASL mechanisms: NO 807 SASL mechanism name: EXTERNAL 809 Security considerations: See RFC XXXX, section 9. 811 Published specification (optional, recommended): RFC XXXX 813 Person & email address to contact for further information: 814 Alexey Melnikov 816 Intended usage: COMMON 818 Owner/Change controller: IESG 820 Note: Updates existing entry for EXTERNAL 822 9. Security considerations 824 Security issues are discussed throughout this memo. 826 In order to make password cracking and/or username harvesting attacks 827 more difficult servers MAY implement a policy whereby the connection 828 is dropped after a number of failed authentication attempts. If they 829 do so, they SHOULD NOT drop the connection until at least 3 attempts 830 to authenticate have failed. Alternatively, the server MAY implement 831 a policy when after a number of failed authentication attempts it 832 returns error to all subsequent authentication attempts on the same 833 connection. 835 The mechanisms that support integrity protection are designed such 836 that the negotiation of the security layer and authorization identity 837 is integrity protected. When the client selects a security layer 838 with at least integrity protection, this protects against an active 839 attacker hijacking the connection and modifying the authentication 840 exchange to negotiate a plaintext connection. 842 When a server or client supports multiple authentication mechanisms, 843 each of which has a different security strength, it is possible for 845 Internet DRAFT SASL 21 December 2003 847 an active attacker to cause a party to use the least secure mechanism 848 supported. To protect against this sort of attack, a client or 849 server which supports mechanisms of different strengths should have a 850 configurable minimum strength that it will use. It is not sufficient 851 for this minimum strength check to only be on the server, since an 852 active attacker can change which mechanisms the client sees as being 853 supported, causing the client to send authentication credentials for 854 its weakest supported mechanism. 856 The client's selection of a SASL mechanism is done in the clear and 857 may be modified by an active attacker. It is important for any new 858 SASL mechanisms to be designed such that an active attacker cannot 859 obtain an authentication with weaker security properties by modifying 860 the SASL mechanism name and/or the challenges and responses. 862 In order to detect Man-in-the-middle (MITM) attacks the client MAY 863 list available SASL mechanisms both before and after the SASL 864 security layer is negotiated. This allows the client to detect 865 active attacks that remove mechanisms from the server's list of 866 supported mechanisms, and allows the client to ensure that it is 867 using the best mechanism supported by both client and server. New 868 protocol profiles SHOULd require servers to make the list of SASL 869 mechanisms available for the initial authentication available to the 870 client after security layers are established. Some older protocols 871 do not require this (or don't support listing of SASL mechanisms once 872 authentication is complete); for these protocols clients MUST NOT 873 treat an empty list of SASL mechanisms after authentication as a MITM 874 attack. 876 Any protocol interactions prior to authentication are performed in 877 the clear and may be modified by an active attacker. In the case 878 where a client selects integrity protection, it is important that any 879 security-sensitive protocol negotiations be performed after 880 authentication is complete. Protocols should be designed such that 881 negotiations performed prior to authentication should be either 882 ignored or revalidated once authentication is complete. 884 When use of a security layer is negotiated by the authentication 885 protocol exchange, the receiver should handle gracefully any security 886 encoded data buffer larger than the defined/negotiated maximal size. 887 In particular, it must not blindly allocate the amount of memory 888 specified in the buffer size field, as this might cause the "out of 889 memory" condition. If the receiver detects a large block, it SHOULD 890 close the connection. 892 Distributed server implementations need to be careful in how they 893 trust other parties and, in particular, authentication secrets should 894 only be disclosed to other parties that are trusted to manage and use 896 Internet DRAFT SASL 21 December 2003 898 those secrets in manner acceptable to disclosing party. It should be 899 noted that where those secrets are used to providing data 900 confidentiality protections, if a third party (other then the 901 discloser/declosee) has knowledge of some portion of the protected 902 information, it can use this knowledge in an attack upon other 903 portions of the protected information. 905 "stringprep" and Unicode security considerations apply to 906 authentication identities, authorization identities and passwords. 908 The EXTERNAL mechanism provides no security protection; it is 909 vulnerable to spoofing by either client or server, active attack, and 910 eavesdropping. It should only be used when external security 911 mechanisms are present and have sufficient strength. 913 10. References 915 10.1. Normative References 917 [ABNF] Crocker, Overell, "Augmented BNF for Syntax Specifications: 918 ABNF", RFC 2234, November 1997 920 [ASCII] American National Standards Institute, "Code Extension 921 Techniques for Use with the 7-bit Coded Character Set of American 922 National Standard Code (ASCII) for Information Interchange", FIPS PUB 923 35, 1974 925 [CHARSET-POLICY] Alvestrand, "IETF Policy on Character Sets and 926 Languages", RFC 2277, January 1998 928 [GSSAPI] Linn, "Generic Security Service Application Program 929 Interface, Version 2, Update 1", RFC 2743, January 2000 931 [ISO-10646] "Universal Multiple-Octet Coded Character Set (UCS) - 932 Architecture and Basic Multilingual Plane", ISO/IEC 10646-1 : 1993. 934 [KEYWORDS] Bradner, "Key words for use in RFCs to Indicate 935 Requirement Levels", RFC 2119, March 1997 937 [Unicode] The Unicode Consortium, "The Unicode Standard, Version 938 3.2.0" is defined by "The Unicode Standard, Version 3.0" (Reading, 939 MA, Addison-Wesley, 2000. ISBN 0-201-61633-5), as amended by the 940 "Unicode Standard Annex #27: Unicode 3.1" 941 (http://www.unicode.org/reports/tr27/) and by the "Unicode Standard 942 Annex #28: Unicode 3.2" (http://www.unicode.org/reports/tr28/). 944 [Stringprep] P. Hoffman, M. Blanchet, "Preparation of 945 Internationalized Strings ("stringprep")", RFC 3454, December 2002. 947 Internet DRAFT SASL 21 December 2003 949 [SASLPrep] Zeilenga, K., "SASLprep: Stringprep profile for user names 950 and passwords", Work in progress, draft-ietf-sasl-saslprep-XX.txt. 952 [UTF-8] Yergeau, "UTF-8, a transformation format of ISO 10646", work 953 in progress (draft-yergeau-rfc2279bis-XX) that replaces RFC 2279, 954 Janyary 1998 956 10.2. Informative References 958 [SASL-GSSAPI] Melnikov, A., "SASL GSSAPI mechanisms", work in 959 progress, draft-ietf-sasl-gssapi-XX.txt, November 2003 961 [SASL-DIGEST] Leach, P., Newman, C., Melnikov, A., "Using Digest 962 Authentication as a SASL Mechanism", work in progress, draft-ietf- 963 sasl-rfc2831bis-XX.txt, replaces RFC 2831 965 [SASL-OTP] Newman, C., "The One-Time-Password SASL Mechanism", RFC 966 2444, October 1998 968 [SASL-SECURID] Nystrom, M., "The SecurID(r) SASL Mechanism", RFC 969 2808, April 2000 971 [SMTP] Klensin, J., "Simple Mail Transfer Protocol", RFC 2821, April 972 2001 974 [SMTP-AUTH] Myers, J., "SMTP Service Extension for Authentication", 975 RFC 2554, March 1999 977 Being revised by Siemborski, R., "SMTP Service Extension for 978 Authentication", work in progress, draft-siemborski-rfc2554bis-XX.txt 980 [XMPP] Saint-Andre, P., "Extensible Messaging and Presence Protocol 981 (XMPP): Core", work in progress, draft-ietf-xmpp-core-XX.txt 983 [BASE64] Josefsson, S., "The Base16, Base32, and Base64 Data 984 Encodings", RFC 3548, July 2003 986 [RFC-INSTRUCTIONS] Postel, Reynolds, "Instructions to RFC Authors", 987 RFC 2223, October 1997 989 [IANA-SASL] IANA, "SIMPLE AUTHENTICATION AND SECURITY LAYER (SASL) 990 MECHANISMS", http://www.iana.org/assignments/sasl-mechanisms. 992 11. Editor's Address 994 Alexey Melnikov 995 Isode 997 Internet DRAFT SASL 21 December 2003 999 Email: Alexey.Melnikov@isode.com 1001 12. Acknowledgments 1003 This document is a revision of RFC 2222 written by John G. Myers. He 1004 also contributed significantly to this revision. 1006 Magnus Nystrom provided the ASCII art used in Section 6.3. 1008 Definition of realm was extracted from RFC 2617 ("HTTP 1009 Authentication: Basic and Digest Access Authentication"). 1011 Contributions of many members of the SASL mailing list are gratefully 1012 acknowledged, in particular Kurt D. Zeilenga, Peter Saint-Andre, Rob 1013 Siemborski, Jeffrey Hutzelman, Hallvard B Furuseth and Tony Hansen 1014 for proofreading the document and various editorial suggestions. 1016 13. Full Copyright Statement 1018 Copyright (C) The Internet Society (2003). All Rights Reserved. 1020 This document and translations of it may be copied and furnished to 1021 others, and derivative works that comment on or otherwise explain it 1022 or assist in its implementation may be prepared, copied, published 1023 and distributed, in whole or in part, without restriction of any 1024 kind, provided that the above copyright notice and this paragraph are 1025 included on all such copies and derivative works. However, this 1026 document itself may not be modified in any way, such as by removing 1027 the copyright notice or references to the Internet Society or other 1028 Internet organizations, except as needed for the purpose of 1029 developing Internet standards in which case the procedures for 1030 copyrights defined in the Internet Standards process must be 1031 followed, or as required to translate it into languages other than 1032 English. 1034 The limited permissions granted above are perpetual and will not be 1035 revoked by the Internet Society or its successors or assigns. 1037 This document and the information contained herein is provided on an 1038 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 1039 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 1040 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 1041 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 1042 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1044 Acknowledgement 1046 Internet DRAFT SASL 21 December 2003 1048 Funding for the RFC Editor function is currently provided by the 1049 Internet Society. 1051 Appendix A. Relation of SASL to transport security 1053 Questions have been raised about the relationship between SASL and 1054 various services (such as IPsec and TLS) which provide a secured 1055 connection. 1057 Two of the key features of SASL are: 1059 The separation of the authorization identity from the identity in 1060 the client's credentials. This permits agents such as proxy 1061 servers to authenticate using their own credentials, yet request 1062 the access privileges of the identity for which they are proxying. 1064 Upon successful completion of an authentication exchange, the 1065 server knows the authorization identity the client wishes to use. 1066 This allows servers to move to a "user is authenticated" state in 1067 the protocol. 1069 These features are extremely important to some application protocols, 1070 yet Transport Security services do not always provide them. To 1071 define SASL mechanisms based on these services would be a very messy 1072 task, as the framing of these services would be redundant with the 1073 framing of SASL and some method of providing these important SASL 1074 features would have to be devised. 1076 Sometimes it is desired to enable within an existing connection the 1077 use of a security service which does not fit the SASL model. (TLS is 1078 an example of such a service.) This can be done by adding a command, 1079 for example "STARTTLS", to the protocol. Such a command is outside 1080 the scope of SASL, and should be different from the command which 1081 starts a SASL authentication protocol exchange. 1083 In certain situations, it is reasonable to use SASL underneath one of 1084 these Transport Security services. The transport service would 1085 secure the connection, either service would authenticate the client, 1086 and SASL would negotiate the authorization identity. The SASL 1087 negotiation would be what moves the protocol from "unauthenticated" 1088 to "authenticated" state. The "EXTERNAL" SASL mechanism is 1089 explicitly intended to handle the case where the transport service 1090 secures the connection and authenticates the client and SASL 1091 negotiates the authorization identity. 1093 Internet DRAFT SASL 21 December 2003 1095 Appendix B. Changes since RFC 2222 1097 The GSSAPI mechanism was removed. It is now specified in a separate 1098 document [SASL-GSSAPI]. 1100 The "KERBEROS_V4" mechanism defined in RFC 2222 is obsolete and has 1101 been removed. 1103 The "SKEY" mechanism described in RFC 2222 is obsolete and has been 1104 removed. It has been replaced by the OTP mechanism [SASL-OTP]. 1106 The overview has been substantially reorganized and clarified. 1108 Clarified the definition and semantics of the authorization identity. 1110 Prohibited the NUL character in authorization identities. 1112 Added a section on character string issues. 1114 The word "must" in the first paragraph of the "Protocol profile 1115 requirements" section was changed to "MUST". 1117 Specified that protocol profiles SHOULD provide a way for clients to 1118 discover available SASL mechanisms. 1120 Made the requirement that protocol profiles specify the semantics of 1121 the authorization identity optional to the protocol profile. 1122 Clarified that such a specification is a refinement of the definition 1123 in the base SASL spec. 1125 Added a requirement discouraging protocol profiles from breaking the 1126 separation between protocol and mechanism. 1128 Mentioned that standards track documents may carve out their own 1129 portions of the SASL mechanism namespace and may amend registration 1130 rules for the portion. However registration of individual SASL 1131 mechanisms is still required. 1133 Specified that the authorization identity in the EXTERNAL mechanism 1134 is encoded in UTF-8. 1136 Added a statement that a protocol profile SHOULD allow challenge data 1137 to be sent with a success indication. 1139 Added a security consideration for the EXTERNAL mechansim. 1141 Clarified sections concerning success with additional data. 1143 Internet DRAFT SASL 21 December 2003 1145 Cleaned up IANA considerations/registrations and assembled them in 1146 one place. 1148 Updated references and split them into Informative and Normative. 1150 Added text to the Security Considerations section regarding handling 1151 of extremely large SASL blocks. 1153 Replaced UTF-8 ABNF with the reference to the UTF-8 document. 1155 Added text about SASLPrep for authentication identities and 1156 passwords. Described where SASLPrep preparation should take place. 1158 Added paragraph about verifying authorization identities. 1160 Added a protocol profile requirement to specify interaction between 1161 SASL and TLS security layers. 1163 Added a protocol profile requirement to specify if it supports 1164 reauthentication. 1166 Removed the text that seemed to suggest that SASL security layer must 1167 not be used when TLS is available. 1169 Created two subsections in 4.2 to talk separately about proxy 1170 authorization and format of the authorization identities. 1172 Made requirement to verify that an authorization identity is correct 1173 by performing SASLPrep a SHOULD, instead of a MUST. 1175 Clarified that each SASL mechanism must decide where SASLPrep is 1176 taking place. 1178 Added 4 new examples for initial response and additional data with 1179 success. 1181 Added text on checking the list of available SASL mechanisms after 1182 negotiating a security layer. 1184 Added definition of "integrity protection" and "confidentiality 1185 protection". 1187 Added text about preventing password cracking/username harvesting 1188 attacks. 1190 Added warning about negotiating no layer once a security layer is 1191 negotiated. 1193 Internet DRAFT SASL 21 December 2003 1195 Status of this Memo .......................................... i 1196 1. Abstract ............................................... 2 1197 2. Organization of this document .......................... 2 1198 2.1. How to read this document .............................. 2 1199 2.2. Conventions used in this document ...................... 2 1200 3. Overview ............................................... 3 1201 4. Authentication mechanisms .............................. 3 1202 4.1. Authentication protocol exchange ....................... 4 1203 4.2. Authorization and authentication identities ............ 4 1204 4.2.1. Authorization identities and proxy authentication .... 5 1205 4.2.2. Authorization Identity Format ........................ 6 1206 4.3. Security layers ........................................ 6 1207 4.4. Character string issues ................................ 7 1208 5. Protocol profile requirements .......................... 7 1209 6. Specific issues ........................................ 9 1210 6.1. Client sends data first ................................ 9 1211 6.1.1. Examples ............................................. 9 1212 6.2. Server returns success with additional data ........... 10 1213 6.2.1. Examples ............................................ 10 1214 6.3. Multiple authentications .............................. 12 1215 7. The EXTERNAL mechanism ................................ 14 1216 7.1. Formal syntax ......................................... 15 1217 7.2. Example ............................................... 15 1218 8. IANA Considerations ................................... 15 1219 8.1. Guidelines for IANA ................................... 16 1220 8.2. Registration procedure ................................ 16 1221 8.3. Comments on SASL mechanism registrations .............. 16 1222 8.4. Change control ........................................ 17 1223 8.5. Registration template ................................. 17 1224 8.6. The EXTERNAL mechanism registration ................... 18 1225 9. Security considerations ................................ 18 1226 10. References ........................................... 20 1227 10.1. Normative References ................................. 20 1228 10.2. Informative References ............................... 21 1229 11. Editor's Address ...................................... 21 1230 12. Acknowledgments ....................................... 22 1231 13. Full Copyright Statement .............................. 22 1232 Appendix A. Relation of SASL to transport security .......... 23 1233 Appendix B. Changes since RFC 2222 .......................... 24