idnits 2.17.1 draft-ietf-sasl-rfc2222bis-05.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 26 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 27 pages -- Found 27 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 (January 2004) is 7400 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 371, but not defined ** Obsolete undefined reference: RFC 3501 (Obsoleted by RFC 9051) == Missing Reference: 'StringPrep' is mentioned on line 373, but not defined == Unused Reference: 'ISO-10646' is defined on line 954, but no explicit reference was found in the text == Unused Reference: 'Stringprep' is defined on line 967, but no explicit reference was found in the text == Unused Reference: 'RFC-INSTRUCTIONS' is defined on line 1009, 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-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 (~~), 11 warnings (==), 16 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-05.txt January 2004 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 Proposed 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 25 January 2004 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 25 January 2004 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 ASCII [ASCII] upper-case 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 137 Internet DRAFT SASL 25 January 2004 139 [SASL-GSSAPI] does this. Procedures for registering new SASL 140 mechanisms are given in section 8. 142 The "sasl-mech" production below defines the syntax of a SASL 143 mechanism name. This uses the Augmented Backus-Naur Form (ABNF) 144 notation as specified in [ABNF] and the ABNF core rules as specified 145 in Appendix A of the ABNF specification [ABNF]. 147 sasl-mech = 1*20mech-char 148 mech-char = %x41-5A / DIGIT / "-" / "_" 149 ; mech names restricted to ASCII uppercase 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 25 January 2004 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 235 empty string. 237 Internet DRAFT SASL 25 January 2004 239 4.2.2. Authorization Identity Format 241 An authorization identity is a string of zero or more Unicode 242 [Unicode] coded characters. The NUL character is not 243 permitted in authorization identities. 245 The character encoding scheme used for transmitting an authorization 246 identity over the protocol is specified in each authentication 247 mechanism All IETF-defined mechanisms MUST, and all other mechanisms 248 SHOULD, use UTF-8 [UTF-8]. (See [CHARSET-POLICY] for IETF policy 249 regarding character sets and encoding schemes.) 251 Mechanisms are expected to be capable of carrying the entire Unicode 252 repertoire (with the exception of the NUL character). An 253 authorization identity of the empty string and an absent 254 authorization identity MUST be treated as equivalent. A mechanism 255 which provides an optional field for an authorization identity, 256 SHOULD NOT allow that field, when present, to be empty. The meaning 257 of an authorization identity of the empty string is described in the 258 previous section. 260 4.3. Security layers 262 If use of a security layer is negotiated by the authentication 263 protocol exchange, the security layer is applied to all subsequent 264 data sent over the connection (until another security layer is 265 negotiated; see also section 6.3). The security layer takes effect 266 immediately following the last response of the authentication 267 exchange for data sent by the client and the completion indication 268 for data sent by the server. 270 Note that all SASL mechanisms that are unable to negotiate a security 271 layer automatically select no security layer. 273 Once the security layer is in effect the protocol stream is processed 274 by the security layer into buffers of security encoded data. Each 275 buffer of security encoded data is transferred over the connection as 276 a stream of octets prepended with a four octet field in network byte 277 order that represents the length of the following buffer. The length 278 of the security encoded data buffer MUST be no larger than the 279 maximum size that was either defined in the mechanism specification 280 or negotiated by the other side during the authentication protocol 281 exchange. Upon the receipt of a data buffer which is larger than the 282 defined/negotiated maximal buffer size the receiver SHOULD close the 283 connection. This might be a sign of an attack or a buggy 284 implementation. 286 Internet DRAFT SASL 25 January 2004 288 4.4. Character string issues 290 Authentication mechanisms SHOULD encode character strings in UTF-8 291 [UTF-8] (see [CHARSET-POLICY] for IETF policy regarding character 292 sets in IETF protocols). In order to avoid interoperability problems 293 due to differing normalizations, when a mechanisms specifies that 294 character data is to be used as input to a cryptographic and/or 295 comparison function, the mechanism specification MUST detail how the 296 data is to be represented, including any normalizations or other 297 preparations, to ensure proper function. Designers of mechanisms 298 SHOULD use the "SASLprep" profile [SASLPrep] of the "stringprep" 299 algorithm [StringPrep] where applicable. 301 There are three entities that have to deal with this issue: a client 302 (upon getting user input or retrieving a value from configuration), a 303 server (upon receiving the value from the client) and a utility that 304 is able to store passwords/hashes in a database that can be later 305 used by the server. SASL mechanisms must define which entity (or 306 entities) must perform the preparation. If preparation fails or 307 results in an empty string, the entity doing the preparation SHALL 308 fail the authentication exchange (or, in case of the utility, refuse 309 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 1) 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 2) A definition of the command to initiate the authentication 324 protocol exchange. This command must have as a parameter the name of 325 the 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 25 January 2004 337 3) 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 4) A protocol profile SHOULD specify a mechanism through which a 351 client may obtain the names of the SASL mechanisms available to it. 352 This is typically done through the protocol's extensions or 353 capabilities mechanism. 355 5) Identification of the octet where any negotiated security layer 356 starts to take effect, in both directions. 358 6) Specify if the protocol profile supports "multiple 359 authentications" (see section 6.3). 361 7) If both TLS and SASL security layer are allowed to be negotiated 362 by the protocol, the protocol profile MUST define in which order they 363 are applied to a cleartext data sent over the connection. 365 8) A protocol profile MAY further refine the definition of an 366 authorization identity by adding additional syntactic restrictions 367 and protocol-specific semantics. A protocol profile MUST specify the 368 form of the authorization identity (since it is protocol specific, as 369 opposed to the authentication identity, which is mechanism specific) 370 and how authorization identities are to be compared. Profiles whose 371 authorization identities are simple user names (e.g. IMAP [RFC 3501]) 372 SHOULD use "SASLPrep" profile [SASLPrep] of the "stringprep" 373 algorithm [StringPrep] to prepare these names for matching. The 374 profiles MAY use a stringprep profile that is more strict than 375 SASLPrep. 377 A protocol profile SHOULD NOT attempt to amend the definition of 378 mechanisms or make mechanism-specific encodings. This breaks the 379 separation between protocol and mechanism that is fundamental to the 380 design of SASL. Likewise, SASL mechanisms SHOULD be profile neutral. 382 Internet DRAFT SASL 25 January 2004 384 6. Specific issues 386 6.1. Client sends data first 388 Some mechanisms specify that the first data sent in the 389 authentication protocol exchange is from the client to the server. 391 If a protocol's profile permits the command which initiates an 392 authentication protocol exchange to contain an initial client 393 response, this parameter SHOULD be used with such mechanisms. 395 If the initial client response parameter is not given, or if a 396 protocol's profile does not permit the command which initiates an 397 authentication protocol exchange to contain an initial client 398 response, then the server issues a challenge with no data. The 399 client's response to this challenge is then used as the initial 400 client response. (The server then proceeds to send the next 401 challenge, indicates completion, or indicates failure.) 403 6.1.1. Examples 405 The following are two examples of an SECURID authentication [SASL- 406 SECURID] in the SMTP protocol [SMTP]. In the first example below, 407 the client is trying fast reauthentication by sending the initial 408 response: 410 S: 220-smtp.example.com ESMTP Server 411 C: EHLO client.example.com 412 S: 250-smtp.example.com Hello client.example.com, pleased to meet you 413 S: 250-AUTH GSSAPI SECURID 414 S: 250 DSN 415 C: AUTH SECURID AG1hZ251cwAxMjM0NTY3OAA= 416 S: 235 Authentication successful 418 The example below is almost identical to the previous, but here the 419 client chooses not to use the initial response parameter. 421 S: 220-smtp.example.com ESMTP Server 422 C: EHLO client.example.com 423 S: 250-smtp.example.com Hello client.example.com, pleased to meet you 424 S: 250-AUTH GSSAPI SECURID 425 S: 250 DSN 426 C: AUTH SECURID 427 S: 334 428 C: AG1hZ251cwAxMjM0NTY3OAA= 429 S: 235 Authentication successful 431 Internet DRAFT SASL 25 January 2004 433 Section 7.2 contains an additional example. 435 6.2. Server returns success with additional data 437 Some mechanisms may specify that additional data be sent to the 438 client along with an indication of successful completion of the 439 exchange. This data would, for example, authenticate the server to 440 the client. 442 If a protocol's profile does not permit this additional data to be 443 returned with a success indication, then the server issues the data 444 as a server challenge, without an indication of successful 445 completion. The client then responds with no data. After receiving 446 this empty response, the server then indicates successful completion 447 (with no additional data). 449 Client implementors should be aware of an additional failure case 450 that might occur when the profile supports sending the additional 451 data with success. Imagine that an active attacker is trying to 452 impersonate the server and sends faked data, which should be used to 453 authenticate the server to the client, with success. (A similar 454 situation can happen when either the server and/or the client has a 455 bug and they calculate different responses.) After checking the data, 456 the client will think that the authentication exchange has failed, 457 however the server will think that the authentication exchange has 458 completed successfully. At this point the client can not abort the 459 authentication exchange; it SHOULD close the connection instead. 460 However, if the profile did not support sending of additional data 461 with success, the client could have aborted the exchange at the very 462 last step of the authentication exchange. 464 6.2.1. Examples 466 The following are two examples of a DIGEST-MD5 authentication [SASL- 467 DIGEST] in the XMPP protocol [XMPP]. In the first example below, the 468 server is sending mutual authentication data with success. 470 C: 475 S: 484 S: 485 486 DIGEST-MD5 487 CRAM-MD5 488 489 490 C: 492 S: 493 cmVhbG09InNvbWVyZWFsbSIsbm9uY2U9Ik9BNk1HOXRFUUdtMmhoIixxb3A9ImF1dGgi 494 LGNoYXJzZXQ9dXRmLTgsYWxnb3JpdGhtPW1kNS1zZXNzCg== 495 496 C: 497 dXNlcm5hbWU9InNvbWVub2RlIixyZWFsbT0ic29tZXJlYWxtIixub25jZT0i 498 T0E2TUc5dEVRR20yaGgiLGNub25jZT0iT0E2TUhYaDZWcVRyUmsiLG5jPTAw 499 MDAwMDAxLHFvcD1hdXRoLGRpZ2VzdC11cmk9InhtcHAvZXhhbXBsZS5jb20i 500 LHJlc3BvbnNlPWQzODhkYWQ5MGQ0YmJkNzYwYTE1MjMyMWYyMTQzYWY3LGNo 501 YXJzZXQ9dXRmLTgK 502 503 S: 504 cnNwYXV0aD1lYTQwZjYwMzM1YzQyN2I1NTI3Yjg0ZGJhYmNkZmZmZAo= 505 507 The example below is almost identical to the previous, but here 508 the server chooses not to use the additional data with success. 510 C: 515 S: 521 S: 522 523 DIGEST-MD5 524 CRAM-MD5 525 526 527 C: 529 S: 530 cmVhbG09InNvbWVyZWFsbSIsbm9uY2U9Ik9BNk1HOXRFUUdtMmhoIixxb3A9ImF1dGgi 532 Internet DRAFT SASL 25 January 2004 534 LGNoYXJzZXQ9dXRmLTgsYWxnb3JpdGhtPW1kNS1zZXNzCg== 535 536 C: 537 dXNlcm5hbWU9InNvbWVub2RlIixyZWFsbT0ic29tZXJlYWxtIixub25jZT0i 538 T0E2TUc5dEVRR20yaGgiLGNub25jZT0iT0E2TUhYaDZWcVRyUmsiLG5jPTAw 539 MDAwMDAxLHFvcD1hdXRoLGRpZ2VzdC11cmk9InhtcHAvZXhhbXBsZS5jb20i 540 LHJlc3BvbnNlPWQzODhkYWQ5MGQ0YmJkNzYwYTE1MjMyMWYyMTQzYWY3LGNo 541 YXJzZXQ9dXRmLTgK 542 543 S: 544 cnNwYXV0aD1lYTQwZjYwMzM1YzQyN2I1NTI3Yjg0ZGJhYmNkZmZmZAo= 545 546 C: 547 S: 549 6.3. Multiple authentications 551 Unless otherwise stated by the protocol's profile, only one 552 successful SASL negotiation may occur in a protocol session. In this 553 case, once an authentication protocol exchange has successfully 554 completed, further attempts to initiate an authentication protocol 555 exchange fail. 557 If a profile explicitly permits multiple successful SASL negotiations 558 to occur, then in no case may multiple security layers be 559 simultaneously in effect. If a security layer is in effect and a 560 subsequent SASL negotiation selects a second security layer, then the 561 second security layer replaces the first. If a security layer is in 562 effect and a subsequent SASL negotiation selects no security layer, 563 the original security layer remains in effect. 565 Note that keeping the original security layer is a subject to a class 566 of security attack described in section 6.3.1. However, at the time 567 of the writing of this document the Working Group consensus is not to 568 change SASL handling of security layers, as the risk of such attacks 569 is considered to be low and specific to only certain classes of 570 implementations. The protocol profiles that allow for 571 reauthentication SHOULD recommend that another security layer is 572 negotiated once a security layer was installed. 574 Also note, that if a subsequent authentication fails, the protocol 575 profile MAY allow the connection state to return to non- 576 authenticated, however the previously negotiated security layer MUST 577 NOT be removed. Only a successful reauthentication is able 578 replace/remove the previously negotiated security layer. 580 Internet DRAFT SASL 25 January 2004 582 6.3.1. Description of Multiple Authentication attack 584 Let's assume that the protected resources on a server are partitioned 585 into a set of protection spaces, each with its own authentication 586 mechanisms and/or authorization database. Let's use the term 587 "partition" to reference any such protected space. An example of a 588 partition might be an HTTP "realm". Also a proxy/frontend can use 589 different partitions for different servers/backends it represents. 591 Now consider the following scenario. A client has already 592 authenticated and established a security layer with "Partition A" 593 which is managed by the server AA. Now the same client authenticates 594 to "Partition B" (managed by the server BB) without negotiating a new 595 security layer, while the security layer negotiated with "Partition 596 A" remains in effect. The server BB is now able to observe how known 597 cleartext is encrypted. This scenario enables the server BB to make 598 guesses about previously observed ciphertext between the client and 599 the server AA using the server's SASL engine as an oracle. This 600 scenario is illustrated below: 602 Internet DRAFT SASL 25 January 2004 604 +---------+ +---------+ 605 | | | | 606 |Partition| |Partition| 607 | B | | A | 608 +---------+ +---------+ 609 | ^ | 610 | : +-----------+ | 611 Traffic from | : | Encryption| | Traffic from A 612 B to client +-------->| end point |<-------+ to client 613 : | (SSL/SASL)| 614 : +-----------+ 615 : | 616 : | 617 : +---+ 618 : | | 619 : | | 620 : | | Encryption tunnel, e.g. SASL or SSL, 621 : | | between the server 622 (1) Recording +---------:| | and a single client only. 623 encrypted | | Separate tunnels to different 624 traffic between | | clients. 625 Partition A and client +---+ 626 | 627 | 628 +-----------> Traffic to clients 630 <> 636 7. The EXTERNAL mechanism 638 The mechanism name associated with external authentication is 639 "EXTERNAL". 641 The client sends an initial response with the UTF-8 encoding of the 642 authorization identity. The form of the authorization identity is 643 further restricted by the application-level protocol's SASL profile. 645 The server uses information, external to SASL, to determine whether 646 the client is authorized to authenticate as the authorization 647 identity. If the client is so authorized, the server indicates 648 successful completion of the authentication exchange; otherwise the 650 Internet DRAFT SASL 25 January 2004 652 server indicates failure. 654 The system providing this external information may be, for example, 655 IPSec or TLS. However, the client can make no assumptions as to what 656 information the server can use in determining client authorization. 657 E.g., just because TLS was established, doesn't mean that the server 658 will use the information provided by TLS. 660 If the client sends the empty string as the authorization identity 661 (thus requesting that the authorization identity be derived from the 662 client's authentication credentials), the authorization identity is 663 to be derived from authentication credentials which exist in the 664 system that is providing the external authentication. 666 7.1. Formal syntax 668 The following syntax specification uses the augmented Backus-Naur 669 Form (BNF) notation as specified in [ABNF]. This uses the ABNF core 670 rules as specified in Appendix A of the ABNF specification [ABNF]. 671 Non-terminals referenced but not defined below are as defined by 672 [UTF-8]. 674 The "extern-init-resp" rule below defines the initial response sent 675 from client to server. 677 extern-init-resp = *( UTF8-char-no-nul ) 679 UTF8-char-no-nul = UTF8-1-no-nul / UTF8-2 / UTF8-3 / UTF8-4 681 UTF8-1-no-nul = %x01-7F 683 7.2. Example 685 The following is an example of an EXTERNAL authentication in the SMTP 686 protocol [SMTP]. In this example, the client is proxy 687 authenticating, sending the authorization identity "fred" using in 688 the (optional) initial response. The server has determined the 689 client's identity through IPsec and has a security policy that 690 permits that identity to proxy authenticate as any other identity. 692 To the protocol profile, the four octet sequence "fred" is an opaque 693 binary data. The SASL protocol profile for SMTP [SMTP-AUTH] specifies 694 that server challenges and client responses are encoded in BASE64 695 [BASE64]; the BASE64 encoding of "fred" is "ZnJlZA==". 697 S: 220 smtp.example.com ESMTP server ready 698 C: EHLO jgm.example.com 700 Internet DRAFT SASL 25 January 2004 702 S: 250-smtp.example.com 703 S: 250 AUTH DIGEST-MD5 EXTERNAL 704 C: AUTH EXTERNAL ZnJlZA== 705 S: 235 Authentication successful. 707 The following example is almost identical to the one above, but the 708 client doesn't use proxy authentication. 710 S: 220 smtp.example.com ESMTP server ready 711 C: EHLO jgm.example.com 712 S: 250-smtp.example.com 713 S: 250 AUTH DIGEST-MD5 EXTERNAL 714 C: AUTH EXTERNAL 715 S: 235 Authentication successful. 717 8. IANA Considerations 719 8.1. Guidelines for IANA 721 It is requested that IANA updates the SASL mechanisms registry as 722 follows: 724 Change the "Intended usage" of the KERBEROS_V4 and SKEY mechanism 725 registrations to OBSOLETE. Change the "Published specification" 726 of the EXTERNAL mechanism to this document. Updated registration 727 is provided in Section 8.6. 729 8.2. Registration procedure 731 Registration of a SASL mechanism is done by filling in the template 732 in section 8.5 and sending it via electronic mail to . 733 IANA has the right to reject obviously bogus registrations, but will 734 perform no review of claims made in the registration form. SASL 735 mechanism registrations are currently available at the URL 736 . 738 There is no naming convention for SASL mechanisms; any name that 739 conforms to the syntax of a SASL mechanism name can be registered. 740 An IETF Standards Track document may reserve a portion of the SASL 741 mechanism namespace ("family of SASL mechanisms") for its own use, 742 amending the registration rules for that portion of the namespace. 743 Each family of SASL mechanisms MUST be identified by a prefix. 745 Internet DRAFT SASL 25 January 2004 747 While the registration procedures do not require it, authors of SASL 748 mechanisms are encouraged to seek community review and comment 749 whenever that is feasible. Authors may seek community review by 750 posting a specification of their proposed mechanism as an Internet- 751 Draft. SASL mechanisms intended for widespread use should be 752 standardized through the normal IETF process, when appropriate. 754 8.3. Comments on SASL mechanism registrations 756 Comments on registered SASL mechanisms should first be sent to the 757 "owner" of the mechanism and/or to the SASL WG mailing list. 758 Submitters of comments may, after a reasonable attempt to contact the 759 owner, request IANA to attach their comment to the SASL mechanism 760 registration itself. If IANA approves of this, the comment will be 761 made accessible in conjunction with the SASL mechanism registration 762 itself. 764 8.4. Change control 766 Once a SASL mechanism registration has been published by IANA, the 767 author may request a change to its definition. The change request 768 follows the same procedure as the registration request. 770 The owner of a SASL mechanism may pass responsibility for the SASL 771 mechanism to another person or agency by informing IANA; this can be 772 done without discussion or review. 774 The IESG may reassign responsibility for a SASL mechanism. The most 775 common case of this will be to enable changes to be made to 776 mechanisms where the author of the registration has died, moved out 777 of contact or is otherwise unable to make changes that are important 778 to the community. 780 SASL mechanism registrations may not be deleted; mechanisms which are 781 no longer believed appropriate for use can be declared OBSOLETE by a 782 change to their "intended use" field; such SASL mechanisms will be 783 clearly marked in the lists published by IANA. 785 The IESG is considered to be the owner of all SASL mechanisms which 786 are on the IETF standards track. 788 8.5. Registration template 790 Subject: Registration of SASL mechanism X 792 Family of SASL mechanisms: (YES or NO) 794 Internet DRAFT SASL 25 January 2004 796 SASL mechanism name (or prefix for the family): 798 Security considerations: 800 Published specification (optional, recommended): 802 Person & email address to contact for further information: 804 Intended usage: 806 (One of COMMON, LIMITED USE or OBSOLETE) 808 Owner/Change controller: 810 (Any other information that the author deems interesting may be 811 added below this line.) 813 8.6. The EXTERNAL mechanism registration 815 It is requested that the SASL Mechanism registry [IANA-SASL] entry 816 for the EXTERNAL mechanism be updated to reflect that this document 817 now provides its technical specification. 819 Subject: Updated Registration of SASL mechanism EXTERNAL 821 Family of SASL mechanisms: NO 823 SASL mechanism name: EXTERNAL 825 Security considerations: See RFC XXXX, section 9. 827 Published specification (optional, recommended): RFC XXXX 829 Person & email address to contact for further information: 830 Alexey Melnikov 832 Intended usage: COMMON 834 Owner/Change controller: IESG 836 Note: Updates existing entry for EXTERNAL 838 9. Security considerations 840 Security issues are discussed throughout this memo. 842 Internet DRAFT SASL 25 January 2004 844 SASL implementations might be subject to online dictionary attacks 845 (e.g. username harvesting, password cracking). In order to mitigate 846 the attacks a server implementation is encouraged to implement a 847 policy when after a number of failed authentication attempts it 848 returns errors to all subsequent authentication attempts on the same 849 connection. Alternatively, the server may implement a policy whereby 850 the connection is dropped after a number of failed authentication 851 attempts. If a server implementation chooses to do so, it should not 852 drop the connection until at least 3 authentication attempts have 853 failed. 855 The mechanisms that support integrity protection are designed such 856 that the negotiation of the security layer and authorization identity 857 is integrity protected. When the client selects a security layer 858 with at least integrity protection, this protects against an active 859 attacker hijacking the connection and modifying the authentication 860 exchange to negotiate a plaintext connection. 862 When a server or client supports multiple authentication mechanisms, 863 each of which has a different security strength, it is possible for 864 an active attacker to cause a party to use the least secure mechanism 865 supported. To protect against this sort of attack, a client or 866 server which supports mechanisms of different strengths should have a 867 configurable minimum strength that it will use. It is not sufficient 868 for this minimum strength check to only be on the server, since an 869 active attacker can change which mechanisms the client sees as being 870 supported, causing the client to send authentication credentials for 871 its weakest supported mechanism. 873 The client's selection of a SASL mechanism is done in the clear and 874 may be modified by an active attacker. It is important for any new 875 SASL mechanisms to be designed such that an active attacker cannot 876 obtain an authentication with weaker security properties by modifying 877 the SASL mechanism name and/or the challenges and responses. 879 In order to detect Man-in-the-middle (MITM) attacks the client MAY 880 list available SASL mechanisms both before and after the SASL 881 security layer is negotiated. This allows the client to detect 882 active attacks that remove mechanisms from the server's list of 883 supported mechanisms, and allows the client to ensure that it is 884 using the best mechanism supported by both client and server. New 885 protocol profiles SHOULd require servers to make the list of SASL 886 mechanisms available for the initial authentication available to the 887 client after security layers are established. Some older protocols 888 do not require this (or don't support listing of SASL mechanisms once 889 authentication is complete); for these protocols clients MUST NOT 890 treat an empty list of SASL mechanisms after authentication as a MITM 891 attack. 893 Internet DRAFT SASL 25 January 2004 895 Any protocol interactions prior to authentication are performed in 896 the clear and may be modified by an active attacker. In the case 897 where a client selects integrity protection, it is important that any 898 security-sensitive protocol negotiations be performed after 899 authentication is complete. Protocols should be designed such that 900 negotiations performed prior to authentication should be either 901 ignored or revalidated once authentication is complete. 903 When use of a security layer is negotiated by the authentication 904 protocol exchange, the receiver should handle gracefully any security 905 encoded data buffer larger than the defined/negotiated maximal size. 906 In particular, it must not blindly allocate the amount of memory 907 specified in the buffer size field, as this might cause the "out of 908 memory" condition. If the receiver detects a large block, it SHOULD 909 close the connection. 911 Distributed server implementations need to be careful in how they 912 trust other parties and, in particular, authentication secrets should 913 only be disclosed to other parties that are trusted to manage and use 914 those secrets in manner acceptable to disclosing party. It should be 915 noted that where those secrets are used to providing data 916 confidentiality protections, if a third party (other then the 917 discloser/declosee) has knowledge of some portion of the protected 918 information, it can use this knowledge in an attack upon other 919 portions of the protected information. 921 Section 6.3.1 contains a description of a potential class of attack 922 on a distributed server implementation. The section also gives some 923 recommendations about mitigating such attacks. 925 "stringprep" and Unicode security considerations apply to 926 authentication identities, authorization identities and passwords. 928 The EXTERNAL mechanism provides no security protection; it is 929 vulnerable to spoofing by either client or server, active attack, and 930 eavesdropping. It should only be used when external security 931 mechanisms are present and have sufficient strength. 933 10. References 935 10.1. Normative References 937 [ABNF] Crocker, D. (Ed.), Overell, P., "Augmented BNF for Syntax 938 Specifications: ABNF", RFC 2234, November 1997 940 [ASCII] American National Standards Institute, "Code Extension 941 Techniques for Use with the 7-bit Coded Character Set of American 942 National Standard Code (ASCII) for Information Interchange", FIPS PUB 944 Internet DRAFT SASL 25 January 2004 946 35, 1974 948 [CHARSET-POLICY] Alvestrand, H., "IETF Policy on Character Sets and 949 Languages", RFC 2277, BCP 18, January 1998 951 [GSSAPI] Linn, J., "Generic Security Service Application Program 952 Interface, Version 2, Update 1", RFC 2743, January 2000 954 [ISO-10646] "Universal Multiple-Octet Coded Character Set (UCS) - 955 Architecture and Basic Multilingual Plane", ISO/IEC 10646-1 : 1993. 957 [KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate 958 Requirement Levels", RFC 2119, BCP 19, March 1997 960 [Unicode] The Unicode Consortium, "The Unicode Standard, Version 961 3.2.0" is defined by "The Unicode Standard, Version 3.0" (Reading, 962 MA, Addison-Wesley, 2000. ISBN 0-201-61633-5), as amended by the 963 "Unicode Standard Annex #27: Unicode 3.1" 964 (http://www.unicode.org/reports/tr27/) and by the "Unicode Standard 965 Annex #28: Unicode 3.2" (http://www.unicode.org/reports/tr28/). 967 [Stringprep] Hoffman, P., Blanchet, M., "Preparation of 968 Internationalized Strings ("stringprep")", RFC 3454, December 2002. 970 [SASLPrep] Zeilenga, K., "SASLprep: Stringprep profile for user names 971 and passwords", Work in progress, draft-ietf-sasl-saslprep-XX.txt. 973 [UTF-8] Yergeau, F., "UTF-8, a transformation format of ISO 10646", 974 RFC 3629, STD 63, November 2003. 976 10.2. Informative References 978 [SASL-GSSAPI] Melnikov, A., "SASL GSSAPI mechanisms", work in 979 progress, draft-ietf-sasl-gssapi-XX.txt, November 2003 981 [SASL-DIGEST] Leach, P., Newman, C., Melnikov, A., "Using Digest 982 Authentication as a SASL Mechanism", work in progress, draft-ietf- 983 sasl-rfc2831bis-XX.txt, replaces RFC 2831 985 [SASL-OTP] Newman, C., "The One-Time-Password SASL Mechanism", RFC 986 2444, October 1998. 988 [SASL-SECURID] Nystrom, M., "The SecurID(r) SASL Mechanism", RFC 989 2808, April 2000. 991 [SMTP] Klensin, J., "Simple Mail Transfer Protocol", RFC 2821, April 992 2001. 994 Internet DRAFT SASL 25 January 2004 996 [SMTP-AUTH] Myers, J., "SMTP Service Extension for Authentication", 997 RFC 2554, March 1999. 999 Being revised by Siemborski, R., "SMTP Service Extension for 1000 Authentication", work in progress, draft-siemborski-rfc2554bis- 1001 XX.txt. 1003 [XMPP] Saint-Andre, P., "Extensible Messaging and Presence Protocol 1004 (XMPP): Core", work in progress, draft-ietf-xmpp-core-XX.txt. 1006 [BASE64] Josefsson, S., "The Base16, Base32, and Base64 Data 1007 Encodings", RFC 3548, July 2003. 1009 [RFC-INSTRUCTIONS] Postel, J., Reynolds, J., "Instructions to RFC 1010 Authors", RFC 2223, October 1997. 1012 [IANA-SASL] IANA, "SIMPLE AUTHENTICATION AND SECURITY LAYER (SASL) 1013 MECHANISMS", http://www.iana.org/assignments/sasl-mechanisms. 1015 11. Editor's Address 1017 Alexey Melnikov 1018 Isode Limited 1020 Email: Alexey.Melnikov@isode.com 1022 12. Acknowledgments 1024 This document is a revision of RFC 2222 written by John G. Myers. He 1025 also contributed significantly to this revision. 1027 Magnus Nystrom provided the ASCII art used in Section 6.3. 1029 Definition of partition was extracted from RFC 2617 ("HTTP 1030 Authentication: Basic and Digest Access Authentication"). 1032 Contributions of many members of the SASL mailing list are gratefully 1033 acknowledged, in particular Kurt D. Zeilenga, Peter Saint-Andre, Rob 1034 Siemborski, Jeffrey Hutzelman, Hallvard B Furuseth and Tony Hansen 1035 for proofreading the document and various editorial suggestions. 1037 13. Full Copyright Statement 1039 Copyright (C) The Internet Society (2004). All Rights Reserved. 1041 This document and translations of it may be copied and furnished to 1042 others, and derivative works that comment on or otherwise explain it 1044 Internet DRAFT SASL 25 January 2004 1046 or assist in its implementation may be prepared, copied, published 1047 and distributed, in whole or in part, without restriction of any 1048 kind, provided that the above copyright notice and this paragraph are 1049 included on all such copies and derivative works. However, this 1050 document itself may not be modified in any way, such as by removing 1051 the copyright notice or references to the Internet Society or other 1052 Internet organizations, except as needed for the purpose of 1053 developing Internet standards in which case the procedures for 1054 copyrights defined in the Internet Standards process must be 1055 followed, or as required to translate it into languages other than 1056 English. 1058 The limited permissions granted above are perpetual and will not be 1059 revoked by the Internet Society or its successors or assigns. 1061 This document and the information contained herein is provided on an 1062 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 1063 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 1064 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 1065 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 1066 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1068 Acknowledgement 1070 Funding for the RFC Editor function is currently provided by the 1071 Internet Society. 1073 Appendix A. Relation of SASL to transport security 1075 Questions have been raised about the relationship between SASL and 1076 various services (such as IPsec and TLS) which provide a secured 1077 connection. 1079 Two of the key features of SASL are: 1081 The separation of the authorization identity from the identity in 1082 the client's credentials. This permits agents such as proxy 1083 servers to authenticate using their own credentials, yet request 1084 the access privileges of the identity for which they are proxying. 1086 Upon successful completion of an authentication exchange, the 1087 server knows the authorization identity the client wishes to use. 1088 This allows servers to move to a "user is authenticated" state in 1089 the protocol. 1091 These features are extremely important to some application protocols, 1092 yet Transport Security services do not always provide them. To 1093 define SASL mechanisms based on these services would be a very messy 1095 Internet DRAFT SASL 25 January 2004 1097 task, as the framing of these services would be redundant with the 1098 framing of SASL and some method of providing these important SASL 1099 features would have to be devised. 1101 Sometimes it is desired to enable within an existing connection the 1102 use of a security service which does not fit the SASL model. (TLS is 1103 an example of such a service.) This can be done by adding a command, 1104 for example "STARTTLS", to the protocol. Such a command is outside 1105 the scope of SASL, and should be different from the command which 1106 starts a SASL authentication protocol exchange. 1108 In certain situations, it is reasonable to use SASL underneath one of 1109 these Transport Security services. The transport service would 1110 secure the connection, either service would authenticate the client, 1111 and SASL would negotiate the authorization identity. The SASL 1112 negotiation would be what moves the protocol from "unauthenticated" 1113 to "authenticated" state. The "EXTERNAL" SASL mechanism is 1114 explicitly intended to handle the case where the transport service 1115 secures the connection and authenticates the client and SASL 1116 negotiates the authorization identity. 1118 Appendix B. Changes since RFC 2222 1120 The GSSAPI mechanism was removed. It is now specified in a separate 1121 document [SASL-GSSAPI]. 1123 The "KERBEROS_V4" mechanism defined in RFC 2222 is obsolete and has 1124 been removed. 1126 The "SKEY" mechanism described in RFC 2222 is obsolete and has been 1127 removed. It has been replaced by the OTP mechanism [SASL-OTP]. 1129 The overview has been substantially reorganized and clarified. 1131 Clarified the definition and semantics of the authorization identity. 1133 Prohibited the NUL character in authorization identities. 1135 Added a section on character string issues. 1137 The word "must" in the first paragraph of the "Protocol profile 1138 requirements" section was changed to "MUST". 1140 Specified that protocol profiles SHOULD provide a way for clients to 1141 discover available SASL mechanisms. 1143 Made the requirement that protocol profiles specify the semantics of 1144 the authorization identity optional to the protocol profile. 1146 Internet DRAFT SASL 25 January 2004 1148 Clarified that such a specification is a refinement of the definition 1149 in the base SASL spec. 1151 Added a requirement discouraging protocol profiles from breaking the 1152 separation between protocol and mechanism. 1154 Mentioned that standards track documents may carve out their own 1155 portions of the SASL mechanism namespace and may amend registration 1156 rules for the portion. However registration of individual SASL 1157 mechanisms is still required. 1159 Specified that the authorization identity in the EXTERNAL mechanism 1160 is encoded in UTF-8. 1162 Added a statement that a protocol profile SHOULD allow challenge data 1163 to be sent with a success indication. 1165 Added a security consideration for the EXTERNAL mechansim. 1167 Clarified sections concerning success with additional data. 1169 Cleaned up IANA considerations/registrations and assembled them in 1170 one place. 1172 Updated references and split them into Informative and Normative. 1174 Added text to the Security Considerations section regarding handling 1175 of extremely large SASL blocks. 1177 Replaced UTF-8 ABNF with the reference to the UTF-8 document. 1179 Added text about SASLPrep for authentication identities and 1180 passwords. Described where SASLPrep preparation should take place. 1182 Added paragraph about verifying authorization identities. 1184 Added a protocol profile requirement to specify interaction between 1185 SASL and TLS security layers. 1187 Added a protocol profile requirement to specify if it supports 1188 reauthentication. 1190 Removed the text that seemed to suggest that SASL security layer must 1191 not be used when TLS is available. 1193 Created two subsections in 4.2 to talk separately about proxy 1194 authorization and format of the authorization identities. 1196 Internet DRAFT SASL 25 January 2004 1198 Made requirement to verify that an authorization identity is correct 1199 by performing SASLPrep a SHOULD, instead of a MUST. 1201 Clarified that each SASL mechanism must decide where SASLPrep is 1202 taking place. 1204 Added 4 new examples for initial response and additional data with 1205 success. 1207 Added text on checking the list of available SASL mechanisms after 1208 negotiating a security layer. 1210 Added definition of "integrity protection" and "confidentiality 1211 protection". 1213 Added text about preventing password cracking/username harvesting 1214 attacks. 1216 Added warning about negotiating no layer once a security layer is 1217 negotiated. 1219 Internet DRAFT SASL 25 January 2004 1221 Status of this Memo .......................................... i 1222 1. Abstract ............................................... 2 1223 2. Organization of this document .......................... 2 1224 2.1. How to read this document .............................. 2 1225 2.2. Conventions used in this document ...................... 2 1226 3. Overview ............................................... 3 1227 4. Authentication mechanisms .............................. 3 1228 4.1. Authentication protocol exchange ....................... 4 1229 4.2. Authorization and authentication identities ............ 4 1230 4.2.1. Authorization identities and proxy authentication .... 5 1231 4.2.2. Authorization Identity Format ........................ 6 1232 4.3. Security layers ........................................ 6 1233 4.4. Character string issues ................................ 7 1234 5. Protocol profile requirements .......................... 7 1235 6. Specific issues ........................................ 9 1236 6.1. Client sends data first ................................ 9 1237 6.1.1. Examples ............................................. 9 1238 6.2. Server returns success with additional data ........... 10 1239 6.2.1. Examples ............................................ 10 1240 6.3. Multiple authentications .............................. 12 1241 6.3.1. Description of Multiple Authentication attack ....... 13 1242 7. The EXTERNAL mechanism ................................ 14 1243 7.1. Formal syntax ......................................... 15 1244 7.2. Example ............................................... 15 1245 8. IANA Considerations ................................... 15 1246 8.1. Guidelines for IANA ................................... 16 1247 8.2. Registration procedure ................................ 16 1248 8.3. Comments on SASL mechanism registrations .............. 16 1249 8.4. Change control ........................................ 17 1250 8.5. Registration template ................................. 17 1251 8.6. The EXTERNAL mechanism registration ................... 18 1252 9. Security considerations ................................ 18 1253 10. References ........................................... 20 1254 10.1. Normative References ................................. 20 1255 10.2. Informative References ............................... 21 1256 11. Editor's Address ...................................... 21 1257 12. Acknowledgments ....................................... 22 1258 13. Full Copyright Statement .............................. 22 1259 Appendix A. Relation of SASL to transport security .......... 23 1260 Appendix B. Changes since RFC 2222 .......................... 24