idnits 2.17.1 draft-ietf-sasl-rfc2222bis-09.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3667, Section 5.1 on line 13. -- Found old boilerplate from RFC 3978, Section 5.5 on line 1387. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1403. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1410. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1416. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement -- however, there's a paragraph with a matching beginning. Boilerplate error? ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. ** The document uses RFC 3667 boilerplate or RFC 3978-like boilerplate instead of verbatim RFC 3978 boilerplate. After 6 May 2005, submission of drafts without verbatim RFC 3978 boilerplate is not accepted. The following non-3978 patterns matched text found in the document. That text should be removed or replaced: By submitting this Internet-Draft, I certify that any applicable patent or other IPR claims of which I am aware have been disclosed, or will be disclosed, and any of which I become aware will be disclosed, in accordance with RFC 3668. 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 30 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 31 pages -- Found 31 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 92 instances of too long lines in the document, the longest one being 33 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 (October 2004) is 7126 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 455, but not defined ** Obsolete undefined reference: RFC 3501 (Obsoleted by RFC 9051) == Missing Reference: 'StringPrep' is mentioned on line 494, but not defined == Missing Reference: 'IMAP' is mentioned on line 829, but not defined == Unused Reference: 'Stringprep' is defined on line 1113, but no explicit reference was found in the text == Unused Reference: 'BASE64' is defined on line 1153, but no explicit reference was found in the text == Unused Reference: 'RFC-INSTRUCTIONS' is defined on line 1156, 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. '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? -- 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) -- Obsolete informational reference (is this intentional?): RFC 2246 (ref. 'TLS') (Obsoleted by RFC 4346) -- Obsolete informational reference (is this intentional?): RFC 2401 (ref. 'IPSec') (Obsoleted by RFC 4301) -- Obsolete informational reference (is this intentional?): RFC 2828 (ref. 'Sec-Glossary') (Obsoleted by RFC 4949) Summary: 13 errors (**), 0 flaws (~~), 12 warnings (==), 22 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group A. Melnikov 2 Internet Draft Editor 3 Document: draft-ietf-sasl-rfc2222bis-09.txt October 2004 4 Obsoletes: RFC 2222 Expires in six months 6 Simple Authentication and Security Layer (SASL) 8 Status of this Memo 10 By submitting this Internet-Draft, I certify that any applicable 11 patent or other IPR claims of which I am aware have been disclosed, 12 and any of which I become aware will be disclosed, in accordance with 13 RFC 3668. 15 Internet Drafts are working documents of the Internet Engineering 16 Task Force (IETF), its Areas, and its Working Groups. Note that 17 other groups may also distribute working documents as Internet 18 Drafts. Internet Drafts are draft documents valid for a maximum of 19 six months. Internet Drafts may be updated, replaced, or obsoleted 20 by other documents at any time. It is not appropriate to use 21 Internet Drafts as reference material or to cite them other than as 22 ``work in progress''. 24 The list of current Internet-Drafts can be accessed at 25 http://www.ietf.org/ietf/1id-abstracts.txt 27 The list of Internet-Draft Shadow Directories can be accessed at 28 http://www.ietf.org/shadow.html. 30 A revised version of this draft document will be submitted to the RFC 31 editor as a Standards Track RFC for the Internet Community. 32 Discussion and suggestions for improvement are requested. 33 Distribution of this draft is unlimited. 35 When published as an RFC this document will obsolete RFC 2222. 37 Internet DRAFT SASL 25 October 2004 39 Abstract 41 The Simple Authentication and Security Layer (SASL) is a framework 42 for providing authentication and data security services in 43 connection-oriented protocols via replaceable mechanisms. It provides 44 a structured interface between protocols and mechanisms. The 45 resulting framework allows new protocols to reuse existing mechanisms 46 and allows old protocols to make use of new mechanisms. The 47 framework also provides a protocol for securing subsequent protocol 48 exchanges within a data security layer. 50 This document describes how a SASL mechanism is structured, describes 51 how protocols add support for SASL, and defines the protocol for 52 carrying a data security layer over a connection. Additionally, this 53 document defines one SASL mechanism, the EXTERNAL mechanism. 55 1. Conventions used in this document 57 In examples, "C:" and "S:" indicate lines sent by the client and 58 server respectively. 60 The key words "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", and "MAY" 61 in this document are to be interpreted as defined in "Key words for 62 use in RFCs to Indicate Requirement Levels" [KEYWORDS]. 64 Character names in this document use the notation for code points and 65 names from the Unicode Standard [Unicode]. For example, the letter 66 "a" may be represented as either or . 68 This document uses terms "integrity protection" and "confidentiality 69 protection". The former refers to a security layer (see Section 70 "Introduction" below for the definition) designed to provide "data 71 integrity service" as defined in [Sec-Glossary]. Confidentiality 72 protection is a security layer that provides "data confidentiality 73 service" as defined in [Sec-Glossary]. The term "confidentiality 74 protection" implies "integrity protection". Security layers may offer 75 other kinds of security services. 77 2. Introduction 79 The Simple Authentication and Security Layer (SASL) is a framework 80 for providing authentication and data security services in 81 connection-oriented protocols via replaceable mechanisms. SASL 82 provides a structured interface between protocols and mechanisms. 83 SASL also provides a protocol for securing subsequent protocol 84 exchanges within a data security layer. 86 Internet DRAFT SASL 25 October 2004 88 SASL's design is intended to allow new protocols to reuse existing 89 mechanisms without requiring redesign of the mechanisms and allows 90 existing protocols to make use of new mechanisms without redesign of 91 protocols. 93 The SASL is conceptually a framework which provides a layer between 94 protocols and mechanisms, as illustrated in the following diagram. 96 SMTP Protocol LDAP Protocol Other Protocols 97 Profile Profile . . . 98 \----- | -----/ 99 \ | / 100 SASL framework 101 / | \ 102 /----- | -----\ 103 DIGEST-MD5 EXTERNAL Other Mechanisms 104 SASL mechanism SASL mechanism . . . 106 It is through the interfaces of this layer that the framework allows 107 any protocol to be utilized with any mechanism. While the layer does 108 generally hide the particulars of protocols from mechanisms and the 109 particulars of mechanisms from protocols, the layer does not 110 generally hide the particulars of mechanisms from protocol 111 implementations. For example, different mechanisms require different 112 information to operate, some of them use password based 113 authentication, some of then require realm information, others make 114 use of Kerberos tickets, certificates, etc. Also, in order to 115 perform authorization, server implementations have to implement a 116 mapping from a mechanism-specific authentication identity format to a 117 protocol-specific format. 119 It is possible to design and implement this framework in ways which 120 do abstract away particulars of similar mechanisms. Such 121 implementation could also be designed to be shared by multiple 122 implementations of various protocols. 124 As illustrated above, the SASL framework interfaces with both 125 protocols and mechanisms. 127 To use SASL, a protocol includes a command for identifying and 128 authenticating a user to a server and for optionally negotiating a 129 security layer for subsequent protocol interactions. If the use of a 130 security layer is negotiated, that security layer is inserted between 131 the protocol and the connection. Section 4 ("Protocol profile 132 requirements") profiles the requirements that a protocol 133 specification must fulfill to make use of SASL. A SASL protocol 134 profile is a part of the protocol specification that satisfies the 136 Internet DRAFT SASL 25 October 2004 138 requirements of Section 4. 140 A SASL mechanism is a series of server challenges and client 141 responses specific to the mechanism. Each SASL mechanism is 142 identified by a registered name. Section 5 ("Mechanism profile 143 guidelines") profiles the requirements that a mechanism specification 144 must fulfill to define a SASL mechanism. 146 This document is written to serve several different audiences: 148 - protocol designers using this specification to support 149 authentication in their protocol, 151 - mechanism designers that define new SASL mechanisms, and 153 - implementors of clients or servers for those protocols using this 154 specification. 156 The sections "Authentication mechanisms", "Protocol profile 157 requirements", "Specific issues", and "Security considerations" cover 158 issues that protocol designers need to understand and address in 159 profiling this specification for use in a specific protocol. 161 The sections "Authentication mechanisms", "Mechanism profile 162 guidelines", "Security considerations" and "Registration procedure" 163 cover issues that mechanism designers need to understand and address 164 in designing new SASL mechanisms. 166 The sections "Authentication mechanisms", "Protocol profile 167 requirements", "Specific issues" and "Security considerations" cover 168 issues that implementors of a protocol that uses SASL framework need 169 to understand. The implementors will also need to understand a 170 specification of a SASL profile specific to the protocol, as well as 171 aspects of mechanism specifications they intend to use (regardless of 172 whether they are implementing the mechanisms themselves or using an 173 existing implementation) to understand, for instance, the mechanism- 174 specific authentication identity forms, the offered services, and 175 security and other considerations. 177 2.1. Relationship to other documents 179 This document obsoletes RFC 2222. It replaces all portions of RFC 180 2222 excepting sections 7.1 (Kerberos version 4 mechanism), 7.2 181 (GSSAPI mechanism), 7.3 (S/Key mechanism). The Kerberos version 4 182 (KERBEROS_IV) and S/Key (SKEY) mechanisms are now viewed as obsolete. 183 The GSSAPI mechanism is now separately specified [SASL-GSSAPI]. 185 Internet DRAFT SASL 25 October 2004 187 3. Authentication mechanisms 189 SASL mechanisms are named by strings, from 1 to 20 characters in 190 length, consisting of ASCII [ASCII] upper-case letters, digits, 191 hyphens, and/or underscores. Names of SASL mechanisms or families of 192 mechanisms must be registered with the Internet Assigned Numbers 193 Authority (IANA) as described in section 8.2. 195 The "sasl-mech" ABNF production below defines the syntax of a SASL 196 mechanism name. This uses the Augmented Backus-Naur Form (ABNF) 197 notation as specified in [ABNF]. 199 sasl-mech = 1*20mech-char 200 mech-char = UPPER-ALPHA / DIGIT / HYPHEN / UNDERSCORE 201 ; mech-char is restricted to "A"-"Z", "0"-"9", "-", 202 ; and "_" from ASCII character set. 204 UPPER-ALPHA = %x41-5A 205 ; "A"-"Z" 207 DIGIT = %x30-39 208 ; "0"-"9" 210 HYPHEN = %x2D 211 ; "-" 213 UNDERSCORE = %x5F 214 ; "_" 216 3.1. Authentication Exchange 218 A SASL mechanism is responsible for conducting an authentication 219 exchange. This consists of a series of server challenges and client 220 responses, the contents of which are specific to and defined by the 221 mechanism. To the application protocol, the challenges and responses 222 are opaque binary tokens of arbitrary length (including 0-length). 223 The protocol's profile then specifies how these binary tokens are 224 encoded for transfer over the connection. 226 After receiving an authentication command or any client response, a 227 server mechanism may issue a challenge, indicate failure, or indicate 228 completion. The server mechanism may return additional data with a 229 completion indication. The protocol's profile specifies how each of 230 these is then represented over the connection. 232 After receiving a challenge, a client mechanism may issue a response 233 or abort the exchange. The protocol's profile specifies how each of 235 Internet DRAFT SASL 25 October 2004 237 these are then represented over the connection. 239 During the authentication exchange, the mechanism performs 240 authentication, transmits an authorization identity (sometimes known 241 as a username<<>>) from the client to server, and may negotiate the 242 use of a mechanism-specific security layer. If the use of a security 243 layer is agreed upon, then the mechanism must also define or 244 negotiate the maximum security layer buffer size that each side is 245 able to receive. 247 3.2. Identity Concepts 249 Conceptually, SASL framework involves two identities: 250 1) an identity associated with the authentication 251 credentials (termed the authentication identity), and 252 2) an identity to act as (termed the authorization 253 identity). 255 The client provides its credentials and, optionally, a 256 string representing the requested authorization identity 257 as part of the SASL exchange. When this string is omitted or empty, 258 the client is requesting to act as the identity 259 associated with the credentials (e.g., the user is 260 requesting to act as the authentication identity). 262 The server is responsible for verifying the client's 263 credentials and verifying that the client is allowed to 264 act as the authorization identity. A SASL exchange 265 fails if either (or both) of these verifications fails. 267 SASL mechanism specifications describe the form of credentials 268 used to authenticate clients, and SASL application 269 profiles describe the form of authorization identities 270 transferred as part of authentication exchange. 271 However, the 272 precise form(s) of the authentication identities (used 273 within the server in its verifications, or otherwise) 274 and the precise form(s) of the authorization identities 275 (used in making authorization decisions, or otherwise) is 276 beyond the scope of the SASL and this specification. In 277 some circumstances, the precise identity forms used 278 outside of the SASL exchange may be dictated by other 279 specifications. For instance, the authorization policy 280 specification for an application protocol may dictate the 281 precise form that an authorization identity is to be 282 represented in the authorization policy. 284 Internet DRAFT SASL 25 October 2004 286 <> 287 Any normalization of the authentication identity (for the purposes 288 of conducting authentication exchange) is defined by a particular 289 SASL mechanism, the protocol profile doesn't influence it. 290 Note, that the mechanism specification doesn't control how 291 authentication identity information is represented elsewhere 292 <>. 294 The mechanism MUST preserve Unicode codepoints when transferring 295 authorization identity (e.g. the mechanism can't apply any form 296 of normalization). 298 3.2.1. Authorization identities and proxy authentication 300 A mechanism which is incapable of transmitting an authorization identity 301 must be treated as if it always transmits an authorization identity of an 302 empty string. <> 304 If the authorization identity transmitted during the authentication 305 exchange is not the empty string, this is typically referred 306 to as "proxy authentication". This feature permits agents such as 307 proxy servers to authenticate using their own credentials, yet request 308 the access privileges of the identity for which they are proxying. 310 The server makes an implementation-defined policy decision as to 311 whether the authentication identity is permitted to have the access 312 privileges of the authorization identity and whether the authorization 313 identity is permitted to receive service. If it is not, the server 314 indicates failure of the authentication exchange. 316 As a client might not have the same information as the server, 317 clients SHOULD NOT derive authorization identities from authentication 318 identities. Instead, clients SHOULD provide no (or empty) authorization 319 identity when the user<> has not provided an authorization identity. 321 The server SHOULD verify that a received authorization identity is in the 322 correct form. Protocol profiles whose authorization identities are simple user 323 names (e.g. IMAP [RFC 3501]) SHOULD use "SASLprep" 324 profile [SASLprep] of the "stringprep" algorithm [StringPrep] to prepare 325 these names for matching. The profiles MAY use a stringprep profile 326 that is more strict than "SASLprep". If the preparation of 327 the authorization identity fails or results in an empty string, 328 the server MUST fail the authentication exchange. The only exception to 329 this rule is when the received authorization identity is already the empty 330 string. 332 Internet DRAFT SASL 25 October 2004 334 3.2.2. Authorization Identity Format 336 An authorization identity is a string of zero or more Unicode [Unicode] 337 coded characters. The NUL character is prohibited 338 in authorization identities. 340 The character encoding scheme used for transmitting an authorization 341 identity over the protocol is specified in each authentication mechanism. 342 All IETF-defined mechanisms MUST, and all other mechanisms SHOULD, 343 use UTF-8 [UTF-8]. (See [CHARSET-POLICY] for IETF policy regarding character 344 sets and encoding schemes.) 346 Mechanisms are expected to be capable of carrying the entire Unicode 347 repertoire (with the exception of the NUL character). An authorization 348 identity of the empty string and an absent authorization identity 349 MUST be treated as equivalent. A mechanism 350 which provides an optional field for an authorization identity, 351 SHOULD NOT allow that field, when present, to be empty. 352 The meaning of the empty string as an authorization identity is described 353 in Section 3.2. 355 3.3. Security layers 357 If use of a security layer is negotiated by the authentication 358 protocol exchange, the security layer is applied to all subsequent 359 data sent over the connection (until another security layer is negotiated ( 360 see also section 6.3) or underlying connection is closed). The security 361 layer takes effect 362 immediately following the last response of the authentication exchange 363 for data sent by the client and the completion indication for data 364 sent by the server. The exact position MUST be defined by the protocol profile 365 (see section 4 part 5). 367 Once the security layer is in effect the 368 protocol stream is processed by the security layer into buffers of 369 protected data. If the security layer is not able to produce a buffer, 370 the connection MUST be closed. If the security layer is not able to 371 decode a received buffer, the connection MUST be closed. In both cases the 372 underlying connection SHOULD be closed gracefully. 374 Each buffer of protected data is 375 transferred over the connection as a stream of octets prepended with a 376 four octet field in network byte order that represents the length of 377 the buffer. The length of the protected data buffer 378 MUST be no larger than the maximum size that was either defined in the 379 mechanism specification or negotiated by 380 the other side during the authentication exchange. 381 Upon the receipt of a data buffer which is larger than the defined/negotiated 383 Internet DRAFT SASL 25 October 2004 385 maximal buffer size the receiver SHOULD close the connection, 386 as this might be a sign of an attack. 388 SASL mechanisms which are unable to negotiate a security layer 389 are treated as selecting no security layer. 391 4. Protocol profile requirements 393 In order to use this specification, a protocol definition MUST supply 394 the following information: 396 1) A service name, to be selected from the IANA registry of "service" 397 elements for the GSSAPI host-based service name form [GSSAPI]. This 398 service name is made available to the authentication mechanism. 400 The registry is available at the URL 401 . 403 2) A definition of the command to initiate the authentication protocol 404 exchange. This command must have as a parameter the 405 name of the mechanism being selected by the client. 407 The command SHOULD have an optional parameter giving an initial 408 response. If the protocol allows for the initial response, 409 the protocol profile MUST also describe how an empty initial response is 410 encoded. This optional parameter allows the client to avoid a round 411 trip when using a mechanism which is defined to have the client send 412 data first. When this initial response is sent by the client and the 413 selected mechanism is defined to have the server start with an initial 414 challenge, the command fails. See section 6.1 of this document for 415 further information. 417 3) A definition of the method by which the authentication protocol 418 exchange is carried out, including how the challenges and responses 419 are encoded, how the server indicates completion or failure of the 420 exchange, how the client aborts an exchange, and how the exchange method 421 interacts with any line length limits in the protocol. 423 The exchange method SHOULD allow the server to include an 424 optional data ("optional challenge") with a success notification. This allows the 425 server to avoid a round trip when using a mechanism which is defined 426 to have the server send additional data along with the indication of 427 successful completion. Note that if additional data is sent with success, 428 it can not be empty. See section 6.2 of this document for further information. 430 4) A protocol profile SHOULD specify a mechanism through 431 which a client may obtain the names of the SASL mechanisms available 432 to it. This is typically done through the protocol's extensions or 434 Internet DRAFT SASL 25 October 2004 436 capabilities mechanism. 438 5) Identification of the octet where any negotiated security layer starts 439 to take effect, in both directions. 441 6) Specify if the protocol profile supports "multiple authentications" 442 (see section 6.3). 444 7) If both a Transport Layer Security [TLS] and a SASL security layer are 445 allowed to be negotiated by 446 the protocol, the protocol profile MUST define in which order they are 447 applied to a cleartext data sent over the connection. 449 8) A protocol profile MAY further refine the definition of an 450 authorization identity by adding additional syntactic restrictions and 451 protocol-specific semantics. A protocol profile MUST specify the form 452 of the authorization identity (since it is protocol-specific, as opposed 453 to the authentication identity, which is mechanism-specific) and how 454 authorization identities are to be compared. Profiles whose authorization 455 identities are simple user names (e.g. IMAP [RFC 3501]) SHOULD use 456 "SASLprep" profile [SASLprep] of the "stringprep" algorithm [StringPrep] 457 to prepare these names for matching. The profiles MAY use a stringprep profile 458 that is more strict than SASLprep. 460 9) Where the application-layer protocol does not precisely state 461 how identities established through SASL relate to identities 462 used elsewhere (e.g., access controls) in the application-layer 463 protocol, it may be useful for the application-layer protocol 464 to provide a facility which the client may use to discover the 465 identity used. 467 A protocol profile SHOULD NOT attempt to amend the definition of 468 mechanisms or create mechanism-specific encodings. This breaks the 469 separation between protocol and mechanism that is fundamental to the 470 design of SASL. (Likewise, SASL mechanisms are intended to be profile neutral.) 472 5. Mechanism profile guidelines 474 Designers of new SASL mechanism should be aware of the following issues: 476 1) Authorization identity 478 While some legacy mechanisms are incapable of transmitting an authorization 479 identity (which means that for these mechanisms the authorization identity 480 is always the empty string), newly defined mechanisms SHOULD be 481 capable of transmitting a non-empty authorization identity. See also section 3.2. 483 Internet DRAFT SASL 25 October 2004 485 2) Character string issues 487 Authentication mechanisms SHOULD encode character strings in UTF-8 [UTF-8] 488 (see [CHARSET-POLICY] for IETF policy regarding character sets in IETF protocols). 489 In order to avoid interoperability problems due to differing normalizations, 490 when a mechanism specifies that character data is to be used as input to a 491 cryptographic and/or comparison function, the mechanism specification MUST 492 detail how the data is to be represented, including any normalizations or 493 other preparations, to ensure proper function. Designers of mechanisms SHOULD use 494 the "SASLprep" profile [SASLprep] of the "stringprep" algorithm [StringPrep] where applicable. 495 This recommendation does not apply to authorization identities as their handling is protocol-specific. 497 The preparation can be potentially performed on the client side (upon getting user input 498 or retrieving a value from configuration) or on the server side (upon receiving the value 499 from the client, retrieving a value from its authentication database or generating a 500 new value in order to store in in the authentication database). 501 SASL mechanisms MUST define which entity (or entities) must perform the 502 preparation. If preparation fails or turns a non-empty string into the empty string, the entity 503 doing the preparation MUST fail the authentication exchange. 505 Implementation note: 506 A server side can be represented by multiple processes. For example, the server side may 507 consist of the server process itself that communicated with a client and a 508 utility (a server agent) that is able to store passwords/hashes (or derivitives) in a 509 database that can be later used by the server. For the server agent the 510 requirement to "fail the authentication exchange" should be interpreted 511 as a requirement to refuse to store the data in the database. 513 3) If the underlying cryptographic technology used by a mechanism supports 514 data integrity, then the mechanism specification MUST integrity protect 515 the transmission of an authorization identity and the negotiation of 516 the security layer. 518 4) The mechanism SHOULD NOT use the authorization identity in generation of any 519 long-term cryptographic keys/hashes. The reason is that different protocols 520 (and sometimes even different implementations of the same protocol) may use 521 multiple forms of an authorization identity that are semantically equivalent 522 and some clients may use one form while other clients use a different form. 524 5) SASL mechanisms should be designed to minimize the number of round 525 trips required, because SASL can be used with protocols where connections 526 are short-lived. 528 6) SASL does not provide for re-keying (see Section 9.1), but SASL mechanisms may. 530 <> 531 SASL mechanisms that support re-keying SHOULD: 532 - indicate that re-keying is or will be needed immediately; <> 534 Internet DRAFT SASL 25 October 2004 536 - provide re-keying messages or transparently include re-keying 537 messages in the security layers; the latter can happen without 538 application involvement, but only as long as the application is 539 engaged in timely bidirectional exchanges with its peer. 541 <> 542 A SASL mechanism supports re-keying if it is able to generate/process 543 messages that request immediate re-keying and it is able to carry out 544 re-keying exchange. (Note that the mechanism MAY use a single message 545 type to do both). SASL mechanisms that support re-keying MAY also be 546 able to indicate that re-keying will be needed in the future. 547 A re-keying exchange can be conducted transparently by the mechanism, 548 or the mechanism should be able to provide/accept re-keying messages 549 to/from the application. The former can happen without application 550 involvement, but only as long as the application is engaged in timely 551 bidirectional exchanges with its peer. 553 7) SASL mechanisms SHOULD be profile neutral. 555 6. Specific issues 557 6.1. Client sends data first 559 Some mechanisms specify that the first data sent in the 560 authentication exchange is from the client to the server. 562 If a protocol's profile permits the command which initiates an 563 authentication exchange to contain an initial client 564 response, this parameter SHOULD be used with such mechanisms. 566 If the initial client response parameter is not given, or if a 567 protocol's profile does not permit the command which initiates an 568 authentication exchange to contain an initial client 569 response, then the server issues a challenge with no data. The 570 client's response to this challenge is then used as the initial client 571 response. (The server then proceeds to send the next challenge, 572 indicates completion, or indicates failure.) 574 6.1.1. Client sends data first examples 576 The following are two examples of the SECURID authentication [SASL-SECURID] in the SMTP 577 protocol [SMTP]. In the first example below, the client is trying fast reauthentication 578 by sending the initial response: 580 S: 220-smtp.example.com ESMTP Server 581 C: EHLO client.example.com 582 S: 250-smtp.example.com Welcome client.example.com 584 Internet DRAFT SASL 25 October 2004 586 S: 250-AUTH GSSAPI SECURID 587 S: 250 DSN 588 C: AUTH SECURID AG1hZ251cwAxMjM0NTY3OAA= 589 S: 235 Authentication successful 591 The example below is almost identical to the previous, but here the 592 client chooses not to use the initial response parameter. 594 S: 220-smtp.example.com ESMTP Server 595 C: EHLO client.example.com 596 S: 250-smtp.example.com Welcome client.example.com 597 S: 250-AUTH GSSAPI SECURID 598 S: 250 DSN 599 C: AUTH SECURID 600 S: 334 601 C: AG1hZ251cwAxMjM0NTY3OAA= 602 S: 235 Authentication successful 604 Additonal examples that show usage of initial response can be found 605 in section 7.2. 607 6.2. Server returns success with additional data 609 Some mechanisms may specify that additional data be sent to the 610 client along with an indication of successful completion of the 611 exchange. This data would, for example, authenticate the server to 612 the client. 614 If a protocol's profile does not permit this additional data to be 615 returned with a success indication, then the server issues the data 616 as a server challenge, without an indication of successful 617 completion. The client then responds with no data. After receiving 618 this empty response, the server then indicates successful completion 619 (with no additional data). 621 Client implementors should be aware of an additional failure case 622 that might occur when the profile supports sending the additional 623 data with success. Imagine that an active attacker is trying to 624 impersonate the server and sends faked data, which should be used to 625 authenticate the server to the client, with success. (A similar 626 situation can happen when either the server and/or the client has a 627 bug and they calculate different responses.) After checking the data, 628 the client will think that the authentication exchange has failed, 629 however the server will think that the authentication exchange has 630 completed successfully. At this point the client can not abort the 631 authentication exchange; it SHOULD close the connection instead. 632 However, if the profile did not support sending of additional data 634 Internet DRAFT SASL 25 October 2004 636 with success, the client could have aborted the exchange at the very 637 last step of the authentication exchange. 639 6.2.1. Server returns success with additional data examples 641 The following are two examples of a DIGEST-MD5 authentication [SASL- 642 DIGEST] in the Extensible Messaging and Presence Protocol [XMPP]. In 643 the first example below, the server is sending mutual authentication 644 data with success. 646 C: 651 S: 657 S: 658 659 DIGEST-MD5 660 CRAM-MD5 661 662 663 C: 665 S: 666 cmVhbG09InNvbWVyZWFsbSIsbm9uY2U9Ik9BNk1HOXRFUUdtMmhoIixxb3A9 667 ImF1dGgiLGNoYXJzZXQ9dXRmLTgsYWxnb3JpdGhtPW1kNS1zZXNzCg== 668 669 C: 670 dXNlcm5hbWU9InNvbWVub2RlIixyZWFsbT0ic29tZXJlYWxtIixub25jZT0i 671 T0E2TUc5dEVRR20yaGgiLGNub25jZT0iT0E2TUhYaDZWcVRyUmsiLG5jPTAw 672 MDAwMDAxLHFvcD1hdXRoLGRpZ2VzdC11cmk9InhtcHAvZXhhbXBsZS5jb20i 673 LHJlc3BvbnNlPWQzODhkYWQ5MGQ0YmJkNzYwYTE1MjMyMWYyMTQzYWY3LGNo 674 YXJzZXQ9dXRmLTgK 675 676 S: 677 cnNwYXV0aD1lYTQwZjYwMzM1YzQyN2I1NTI3Yjg0ZGJhYmNkZmZmZAo= 678 680 The example below is almost identical to the previous, but here 681 the server chooses not to use the additional data with success. 683 Internet DRAFT SASL 25 October 2004 685 C: 690 S: 696 S: 697 698 DIGEST-MD5 699 CRAM-MD5 700 701 702 C: 704 S: 705 cmVhbG09InNvbWVyZWFsbSIsbm9uY2U9Ik9BNk1HOXRFUUdtMmhoIixxb3A9 706 ImF1dGgiLGNoYXJzZXQ9dXRmLTgsYWxnb3JpdGhtPW1kNS1zZXNzCg== 707 708 C: 709 dXNlcm5hbWU9InNvbWVub2RlIixyZWFsbT0ic29tZXJlYWxtIixub25jZT0i 710 T0E2TUc5dEVRR20yaGgiLGNub25jZT0iT0E2TUhYaDZWcVRyUmsiLG5jPTAw 711 MDAwMDAxLHFvcD1hdXRoLGRpZ2VzdC11cmk9InhtcHAvZXhhbXBsZS5jb20i 712 LHJlc3BvbnNlPWQzODhkYWQ5MGQ0YmJkNzYwYTE1MjMyMWYyMTQzYWY3LGNo 713 YXJzZXQ9dXRmLTgK 714 715 S: 716 cnNwYXV0aD1lYTQwZjYwMzM1YzQyN2I1NTI3Yjg0ZGJhYmNkZmZmZAo= 717 718 C: 719 S: 721 6.3. Multiple authentications 723 Unless otherwise stated by the protocol's profile, only one 724 successful SASL negotiation may occur in a protocol session. In this 725 case, once an authentication exchange has successfully completed, 726 further attempts to initiate an authentication exchange fail. 728 If a profile explicitly permits multiple successful SASL negotiations 729 to occur, then in no case may multiple security layers be 730 simultaneously in effect. If a security layer is in effect and a 731 subsequent SASL negotiation selects a second security layer, then the 732 second security layer replaces the first; this can be used as a form 734 Internet DRAFT SASL 25 October 2004 736 of re-keying, where SASL mechanisms that provide security layers fail 737 to provide for re-keying, provided that the authenticated identity 738 remains the same. If a security layer is in effect and a subsequent 739 SASL negotiation selects no security layer, the original security 740 layer remains in effect. 742 Where a protocol profile permits multiple successful SASL 743 negotiations, the profile MUST detail the effect of a failed SASL 744 negotiation upon the previously established authentication state. 745 In particular, it MUST state whether the previously established 746 authenticated state remains in force or whether the connection is to 747 revert to an non-authenticated state. Regardless of the specified 748 effect upon authentication state, the previously negotiated security 749 layer remains in effect. 751 7. The EXTERNAL mechanism 753 The mechanism name associated with external authentication is 754 "EXTERNAL". 756 The client sends a single message containing the UTF-8 encoding of 757 the requested authorization identity. The message may be empty. The 758 form of the authorization identity may be restricted by the 759 application protocol's SASL profile. 761 Some system external to SASL must authenticate the client. If that 762 succeeds, the server determines the authentication identity from 763 information from this system. If the requested authorization 764 identity is empty, the authorization identity is derived from the 765 authentication identity. The server determines if the authentication 766 identity is allowed to act as the authorization identity. If all 767 that succeeds, the server indicates successful completion of the 768 authentication exchange; otherwise it indicates failure. 770 The system providing this external information may be, for example, 771 IPSec [IPSec] or TLS [TLS]. However, the client can make no 772 assumptions as to what information the server can use in determining 773 client authorization. For example, just because TLS was established, 774 doesn't mean that the server will use the information provided by 775 TLS. 777 7.1. Formal syntax 779 The following syntax specification uses the augmented Backus-Naur 780 Form (BNF) notation as specified in [ABNF]. Non-terminals referenced 781 but not defined below are as defined by [UTF-8]. 783 The "extern-resp" rule below defines the message sent from client to 785 Internet DRAFT SASL 25 October 2004 787 server. 789 extern-resp = *( UTF8-char-no-nul ) 791 UTF8-char-no-nul = UTF8-1-no-nul / UTF8-2 / UTF8-3 / UTF8-4 793 UTF8-1-no-nul = %x01-7F 795 7.2. Examples of SASL EXTERNAL 797 The following is an example of an EXTERNAL authentication in the SMTP 798 protocol [SMTP]. In this example, the client is proxy authenticating, 799 sending the authorization identity "fred@example.com" in the 800 (optional) initial response. The server has obtained the client's 801 (authentication) identity from an external service, such as IPsec, 802 and has a security policy that permits that identity to assume the 803 identity of the asserted authorization identity. 805 To the protocol profile, the sequence "fred@example.com" is an opaque 806 binary data. The SASL protocol profile for SMTP [SMTP-AUTH] specifies 807 that server challenges and client responses are encoded in BASE64 808 [BASE64, section 3]; the BASE64 encoding of "fred@example.com" is 809 "ZnJlZEBleGFtcGxlLmNvbQ==". 811 S: 220 smtp.example.com ESMTP server ready 812 C: EHLO jgm.example.com 813 S: 250-smtp.example.com 814 S: 250 AUTH DIGEST-MD5 EXTERNAL 815 C: AUTH EXTERNAL ZnJlZEBleGFtcGxlLmNvbQ== 816 S: 235 Authentication successful. 818 The following example is almost identical to the one above, but the 819 client doesn't request proxy authentication. 821 S: 220 smtp.example.com ESMTP server ready 822 C: EHLO jgm.example.com 823 S: 250-smtp.example.com 824 S: 250 AUTH DIGEST-MD5 EXTERNAL 825 C: AUTH EXTERNAL 826 S: 235 Authentication successful. 828 The following is an example of an EXTERNAL authentication in the 829 IMAP4 protocol [IMAP]. IMAP4 doesn't support the initial response 830 feature of SASL. As in the previous example, the client doesn't 831 request proxy authentication. 833 S: * OK IMAP4rev1 Server 835 Internet DRAFT SASL 25 October 2004 837 C: C01 CAPABILITY 838 S: * CAPABILITY IMAP4 IMAP4rev1 AUTH=DIGEST-MD5 AUTH=EXTERNAL 839 [...] 840 C: A01 AUTHENTICATE EXTERNAL 841 (note that there is a space following the "+" in the following line) 842 S: + 843 C: 844 S: A01 OK Success 846 8. IANA Considerations 848 8.1. Guidelines for IANA 850 It is requested that IANA updates the SASL mechanisms registry as 851 follows: 853 Change the "Intended usage" of the KERBEROS_V4 and SKEY mechanism 854 registrations to OBSOLETE. Change the "Published specification" 855 of the EXTERNAL mechanism to this document. Updated registration 856 information is provided in Section 8.6. 858 8.2. Registration procedure 860 Registration of a SASL mechanism is done by filling in the template 861 in section 8.5 and sending it via electronic mail to . 862 IANA has the right to reject obviously bogus registrations, but will 863 perform no review of claims made in the registration form. SASL 864 mechanism registrations are currently available at the URL 865 . 867 There is no naming convention for SASL mechanisms; any name that 868 conforms to the syntax of a SASL mechanism name can be registered. 869 However an IETF Standards Track document may reserve a portion of the 870 SASL mechanism namespace ("family of SASL mechanisms") for its own 871 use, amending the registration rules for that portion of the 872 namespace. Each family of SASL mechanisms MUST be identified by a 873 prefix. 875 While the registration procedures do not require expert review, 876 authors of SASL mechanisms are encouraged to seek community review 877 and comment whenever that is feasible. Authors may seek community 878 review by posting a specification of their proposed mechanism as an 879 Internet-Draft. SASL mechanisms intended for widespread use should 881 Internet DRAFT SASL 25 October 2004 883 be standardized through the normal IETF process, when appropriate. 885 8.3. Comments on SASL mechanism registrations 887 Comments on registered SASL mechanisms should first be sent to the 888 "owner" of the mechanism and/or to the SASL WG mailing list. 889 Submitters of comments may, after a reasonable attempt to contact the 890 owner, request IANA to attach their comment to the SASL mechanism 891 registration itself. If IANA approves of this, the comment will be 892 made accessible in conjunction with the SASL mechanism registration 893 itself. 895 8.4. Change control 897 Once a SASL mechanism registration has been published by IANA, the 898 author may request a change to its definition. The change request 899 follows the same procedure as the registration request. 901 The owner of a SASL mechanism may pass responsibility for the SASL 902 mechanism to another person or agency by informing IANA; this can be 903 done without discussion or review. 905 The IESG may reassign responsibility for a SASL mechanism. The most 906 common case of this will be to enable changes to be made to 907 mechanisms where the author of the registration has died, moved out 908 of contact or is otherwise unable to make changes that are important 909 to the community. 911 SASL mechanism registrations may not be deleted; mechanisms which are 912 no longer believed appropriate for use can be declared OBSOLETE by a 913 change to their "intended usage" field; such SASL mechanisms will be 914 clearly marked in the lists published by IANA. 916 The IESG is considered to be the owner of all SASL mechanisms which 917 are on the IETF standards track. 919 8.5. Registration template 921 Subject: Registration of SASL mechanism X 923 Family of SASL mechanisms: (YES or NO) 925 SASL mechanism name (or prefix for the family): 927 Security considerations: 929 Published specification (optional, recommended): 931 Internet DRAFT SASL 25 October 2004 933 Person & email address to contact for further information: 935 Intended usage: 937 (One of COMMON, LIMITED USE or OBSOLETE) 939 Owner/Change controller: 941 (Any other information that the author deems interesting may be 942 added below this line.) 944 8.6. The EXTERNAL mechanism registration 946 It is requested that the SASL Mechanism registry [IANA-SASL] entry 947 for the EXTERNAL mechanism be updated to reflect that this document 948 now provides its technical specification. 950 Subject: Updated Registration of SASL mechanism EXTERNAL 952 Family of SASL mechanisms: NO 954 SASL mechanism name: EXTERNAL 956 Security considerations: See RFC XXXX, section 9. 958 Published specification (optional, recommended): RFC XXXX 960 Person & email address to contact for further information: 961 Alexey Melnikov 963 Intended usage: COMMON 965 Owner/Change controller: IESG 967 Note: Updates existing entry for EXTERNAL 969 9. Security considerations 971 Security issues are discussed throughout this memo. 973 When the client selects a security layer with at least integrity 974 protection, this protects against an active attacker hijacking the 975 connection and modifying the authentication exchange to negotiate a 976 plaintext connection. 978 When a server or client supports multiple authentication mechanisms, 980 Internet DRAFT SASL 25 October 2004 982 each of which has a different security strength, it is possible for 983 an active attacker to cause a party to use the least secure mechanism 984 supported. To protect against this sort of attack, a client or 985 server which supports mechanisms of different strengths should have a 986 configurable minimum strength that it will use. It is not sufficient 987 for this minimum strength check to only be on the server, since an 988 active attacker can change which mechanisms the client sees as being 989 supported, causing the client to send authentication credentials for 990 its weakest supported mechanism. 992 The client's selection of a SASL mechanism is done in the clear and 993 may be modified by an active attacker. It is important for any new 994 SASL mechanisms to be designed such that an active attacker cannot 995 obtain an authentication with weaker security properties by modifying 996 the SASL mechanism name and/or the challenges and responses. 998 In order to detect Man-in-the-middle (MITM) attacks the client MAY 999 list available SASL mechanisms both before and after the SASL 1000 security layer is negotiated. This allows the client to detect 1001 active attacks that remove mechanisms from the server's list of 1002 supported mechanisms, and allows the client to ensure that it is 1003 using the best mechanism supported by both client and server. New 1004 protocol profiles SHOULD require servers to make the list of SASL 1005 mechanisms available for the initial authentication available to the 1006 client after security layers are established. Some older protocols 1007 do not require this (or don't support listing of SASL mechanisms once 1008 authentication is complete); for these protocols clients MUST NOT 1009 treat an empty list of SASL mechanisms after authentication as a MITM 1010 attack. 1012 Any protocol interactions prior to authentication are performed in 1013 the clear and may be modified by an active attacker. In the case 1014 where a client selects integrity protection, it is important that any 1015 security-sensitive protocol negotiations be performed after 1016 authentication is complete. Protocols should be designed such that 1017 negotiations performed prior to authentication should be either 1018 ignored or revalidated once authentication is complete. 1020 Clients should be admonished to validate TLS server IDs to prevent 1021 MITM attacks when using SASL-over-TLS. The same recommendation 1022 applies to other protocols providing security services. 1024 When use of a security layer is negotiated by the authentication 1025 protocol exchange, the receiver should handle gracefully any 1026 protected data buffer larger than the defined/negotiated maximal 1027 size. In particular, it must not blindly allocate the amount of 1028 memory specified in the buffer size field, as this might cause the 1029 "out of memory" condition. If the receiver detects a large block, it 1031 Internet DRAFT SASL 25 October 2004 1033 SHOULD close the connection. 1035 Distributed server implementations need to be careful in how they 1036 trust other parties. In particular, authentication secrets should 1037 only be disclosed to other parties that are trusted to manage and use 1038 those secrets in manner acceptable to disclosing party. Applications 1039 using SASL assume that SASL security layers providing data 1040 confidentiality are secure even when an attacker chooses the text to 1041 be protected by the security layer. Similarly applications assume 1042 that the SASL security layer is secure even if the attacker can 1043 manipulate the ciphertext output of the security layer. New SASL 1044 mechanisms MUST meet these assumptions. 1046 "stringprep" and Unicode security considerations apply to 1047 authentication identities, authorization identities and passwords. 1049 The EXTERNAL mechanism provides no security protection; it is 1050 vulnerable to spoofing by either client or server, active attack, and 1051 eavesdropping. It should only be used when external security 1052 mechanisms are present and have sufficient strength. 1054 9.1. Re-keying 1056 The secure or administratively permitted lifetimes of SASL 1057 mechanisms' security layers are finite. Cryptographic keys weaken as 1058 they are used and as time passes; the more time and/or ciphertext 1059 that a cryptanalyst has after the first use of the a key, the easier 1060 it is for the cryptanalyst to mount attacks on the key. 1062 Administrative limits on security layers lifetime may take the form 1063 of time limits expressed in x.509 certificates, Kerberos V tickets, 1064 or in directories, and are often desired. <> 1071 Re-keying (key renegotiation process) is a<<>> way of addressing the 1072 weakening of cryptographic keys. SASL framework does not provide for 1073 re-keying. SASL mechanisms may; all future SASL mechanisms that 1074 provide security layers should provide for re-keying. 1076 Applications that wish to re-key SASL security layers where the 1077 mechanism does not provide for re-keying should reauthenticate the 1078 same IDs and replace the expired or soon-to-expire security layers. 1080 Internet DRAFT SASL 25 October 2004 1082 This approach requires support for re-keying in the application 1083 protocols. See section 6.3. 1085 10. References 1087 10.1. Normative References 1089 [ABNF] Crocker, D. (Ed.), Overell, P., "Augmented BNF for Syntax 1090 Specifications: ABNF", RFC 2234, November 1997 1092 [ASCII] American National Standards Institute, "Code Extension 1093 Techniques for Use with the 7-bit Coded Character Set of American 1094 National Standard Code (ASCII) for Information Interchange", FIPS PUB 1095 35, 1974 1097 [CHARSET-POLICY] Alvestrand, H., "IETF Policy on Character Sets and 1098 Languages", RFC 2277, BCP 18, January 1998 1100 [GSSAPI] Linn, J., "Generic Security Service Application Program 1101 Interface, Version 2, Update 1", RFC 2743, January 2000 1103 [KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate 1104 Requirement Levels", RFC 2119, BCP 19, March 1997 1106 [Unicode] The Unicode Consortium, "The Unicode Standard, Version 1107 3.2.0" is defined by "The Unicode Standard, Version 3.0" (Reading, 1108 MA, Addison-Wesley, 2000. ISBN 0-201-61633-5), as amended by the 1109 "Unicode Standard Annex #27: Unicode 3.1" 1110 (http://www.unicode.org/reports/tr27/) and by the "Unicode Standard 1111 Annex #28: Unicode 3.2" (http://www.unicode.org/reports/tr28/). 1113 [Stringprep] Hoffman, P., Blanchet, M., "Preparation of 1114 Internationalized Strings ("stringprep")", RFC 3454, December 2002. 1116 [SASLprep] Zeilenga, K., "SASLprep: Stringprep profile for user names 1117 and passwords", Work in progress, draft-ietf-sasl-saslprep-XX.txt. 1119 [UTF-8] Yergeau, F., "UTF-8, a transformation format of ISO 10646", 1120 RFC 3629, STD 63, November 2003. 1122 10.2. Informative References 1124 [SASL-GSSAPI] Melnikov, A., "SASL GSSAPI mechanisms", work in 1125 progress, draft-ietf-sasl-gssapi-XX.txt, November 2003 1127 [SASL-DIGEST] Leach, P., Newman, C., Melnikov, A., "Using Digest 1129 Internet DRAFT SASL 25 October 2004 1131 Authentication as a SASL Mechanism", work in progress, draft-ietf- 1132 sasl-rfc2831bis-XX.txt, replaces RFC 2831 1134 [SASL-OTP] Newman, C., "The One-Time-Password SASL Mechanism", RFC 1135 2444, October 1998. 1137 [SASL-SECURID] Nystrom, M., "The SecurID(r) SASL Mechanism", RFC 1138 2808, April 2000. 1140 [SMTP] Klensin, J., "Simple Mail Transfer Protocol", RFC 2821, April 1141 2001. 1143 [SMTP-AUTH] Myers, J., "SMTP Service Extension for Authentication", 1144 RFC 2554, March 1999. 1146 Being revised by Siemborski, R., "SMTP Service Extension for 1147 Authentication", work in progress, draft-siemborski-rfc2554bis- 1148 XX.txt. 1150 [XMPP] Saint-Andre, P., "Extensible Messaging and Presence Protocol 1151 (XMPP): Core", work in progress, draft-ietf-xmpp-core-XX.txt. 1153 [BASE64] Josefsson, S., "The Base16, Base32, and Base64 Data 1154 Encodings", RFC 3548, July 2003. 1156 [RFC-INSTRUCTIONS] Postel, J., Reynolds, J., "Instructions to RFC 1157 Authors", RFC 2223, October 1997. 1159 [IANA-SASL] IANA, "SIMPLE AUTHENTICATION AND SECURITY LAYER (SASL) 1160 MECHANISMS", http://www.iana.org/assignments/sasl-mechanisms. 1162 [TLS] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", RFC 1163 2246, January 1999. 1165 [IPSec] Kent, S., and R. Atkinson, "Security Architecture for the 1166 Internet Protocol", RFC 2401, November 1998. 1168 [Sec-Glossary] Shirey, R., "Internet Security Glossary", RFC 2828, 1169 May 2000. 1171 11. Editor's Address 1173 Alexey Melnikov 1174 Isode Limited 1175 5 Castle Business Village 1176 36 Station Road 1177 Hampton, Middlesex, 1179 Internet DRAFT SASL 25 October 2004 1181 TW12 2BX, United Kingdom 1183 Email: Alexey.Melnikov@isode.com 1184 URI: http://www.melnikov.ca/ 1186 12. Acknowledgments 1188 This document is a revision of RFC 2222 written by John G. Myers. He 1189 also contributed significantly to this revision. 1191 Contributions of many members of the SASL mailing list are gratefully 1192 acknowledged, in particular that of Kurt Zeilenga, Peter Saint-Andre, 1193 Rob Siemborski, Magnus Nystrom, Jeffrey Hutzelman, Hallvard B 1194 Furuseth, Tony Hansen, Simon Josefsson, Abhijit Menon-Sen, RL 'Bob' 1195 Morgan, Sam Hartman, Nicolas Williams, Tim Alsop and Luke Howard. 1197 Appendix A. Relation of SASL to transport security 1199 Questions have been raised about the relationship between SASL and 1200 various services (such as IPsec and TLS) which provide a secured 1201 connection. 1203 Two of the key features of SASL are: 1205 The separation of the authorization identity from the identity in 1206 the client's credentials. This permits agents such as proxy 1207 servers to authenticate using their own credentials, yet request 1208 the access privileges of the identity for which they are proxying. 1210 Upon successful completion of an authentication exchange, the 1211 server knows the authorization identity the client wishes to use. 1212 This allows servers to move to a "user is authenticated" state in 1213 the protocol. 1215 These features are extremely important to some application protocols, 1216 yet Transport Security services do not always provide them. To 1217 define SASL mechanisms based on these services would be a very messy 1218 task, as the framing of these services would be redundant with the 1219 framing of SASL and some method of providing these important SASL 1220 features would have to be devised. 1222 Sometimes it is desired to enable within an existing connection the 1223 use of a security service which does not fit the SASL model. (TLS is 1224 an example of such a service.) This can be done by adding a command, 1225 for example "STARTTLS", to the protocol. Such a command is outside 1226 the scope of SASL, and should be different from the command which 1227 starts a SASL authentication protocol exchange. 1229 Internet DRAFT SASL 25 October 2004 1231 In certain situations, it is reasonable to use SASL underneath one of 1232 these Transport Security services. The transport service would 1233 secure the connection, either service would authenticate the client, 1234 and SASL would negotiate the authorization identity. The SASL 1235 negotiation would be what moves the protocol from "unauthenticated" 1236 to "authenticated" state. The "EXTERNAL" SASL mechanism is 1237 explicitly intended to handle the case where the transport service 1238 secures the connection and authenticates the client and SASL 1239 negotiates the authorization identity. 1241 Appendix B. Changes since RFC 2222 1243 The GSSAPI mechanism was removed. It is now specified in a separate 1244 document [SASL-GSSAPI]. 1246 The "KERBEROS_V4" mechanism defined in RFC 2222 is obsolete and has 1247 been removed. 1249 The "SKEY" mechanism described in RFC 2222 is obsolete and has been 1250 removed. It has been replaced by the OTP mechanism [SASL-OTP]. 1252 The introduction has been substantially reorganized and clarified. 1254 Clarified the definition and semantics of the authorization identity. 1256 Prohibited the NUL character in authorization identities. 1258 Added a section on character string issues. 1260 The word "must" in the first paragraph of the "Protocol profile 1261 requirements" section was changed to "MUST". 1263 Specified that protocol profiles SHOULD provide a way for clients to 1264 discover available SASL mechanisms. 1266 Made the requirement that protocol profiles specify the semantics of 1267 the authorization identity optional to the protocol profile. 1268 Clarified that such a specification is a refinement of the definition 1269 in the base SASL spec. 1271 Added a requirement discouraging protocol profiles from breaking the 1272 separation between protocol and mechanism. 1274 Mentioned that standards track documents may carve out their own 1275 portions of the SASL mechanism namespace and may amend registration 1276 rules for the portion. However registration of individual SASL 1277 mechanisms is still required. 1279 Internet DRAFT SASL 25 October 2004 1281 Clarified that authorization identity should be encoded in UTF-8. 1283 Specified that the authorization identity in the EXTERNAL mechanism 1284 is encoded in UTF-8. 1286 Added a statement that a protocol profile SHOULD allow challenge data 1287 to be sent with a success indication. 1289 Added a security consideration for the EXTERNAL mechanism. 1291 Clarified sections concerning success with additional data. 1293 Cleaned up IANA considerations/registrations and assembled them in 1294 one place. 1296 Updated references and split them into Informative and Normative. 1298 Added text to the Security considerations section regarding handling 1299 of extremely large SASL blocks. 1301 Added text about SASLprep for authentication identities and 1302 passwords. Described where SASLprep preparation should take place. 1304 Added paragraph about verifying authorization identities. 1306 Added a protocol profile requirement to specify interaction between 1307 SASL and TLS security layers. 1309 Added a protocol profile requirement to specify if it supports 1310 reauthentication. 1312 Removed the text that seemed to suggest that SASL security layer must 1313 not be used when TLS is available. 1315 Created two subsections in 3.2 to talk separately about proxy 1316 authorization and format of the authorization identities. 1318 Made requirement to verify that an authorization identity is correct 1319 by performing SASLprep. 1321 Clarified that each SASL mechanism must decide where SASLprep is 1322 taking place. 1324 Added 4 new examples for initial response and additional data with 1325 success. 1327 Added text on checking the list of available SASL mechanisms after 1328 negotiating a security layer. 1330 Internet DRAFT SASL 25 October 2004 1332 Added definition of "integrity protection" and "confidentiality 1333 protection". 1335 Added warning about negotiating no layer once a security layer is 1336 negotiated. 1338 Added new section with guidelines to a SASL mechanism designer. 1340 Added a requirement to specify how an empty initial challenge is 1341 encoded if initial response is supported by a protocol. 1343 Clarified that empty "additional data with success" is not allowed. 1345 Replaced "buffers of cipher-text" with "buffers of protected data" 1346 for clarity. 1348 Clarified that SASL EXTERNAL can be used even with SASL profiles that 1349 don't support initial client response. 1351 Changed "authentication protocol exchange" to "authentication 1352 exchange" everywhere. 1354 Appendix C. Full Copyright Statement and Intellectual Property Statement 1356 Full Copyright Statement 1358 Copyright (C) The Internet Society (2004). This document is subject 1359 to the rights, licenses and restrictions contained in BCP 78, and 1360 except as set forth therein, the authors retain all their rights. 1362 This document and translations of it may be copied and furnished to 1363 others, and derivative works that comment on or otherwise explain it 1364 or assist in its implementation may be prepared, copied, published 1365 and distributed, in whole or in part, without restriction of any 1366 kind, provided that the above copyright notice and this paragraph are 1367 included on all such copies and derivative works. However, this 1368 document itself may not be modified in any way, such as by removing 1369 the copyright notice or references to the Internet Society or other 1370 Internet organizations, except as needed for the purpose of 1371 developing Internet standards in which case the procedures for 1372 copyrights defined in the Internet Standards process must be 1373 followed, or as required to translate it into languages other than 1374 English. 1376 The limited permissions granted above are perpetual and will not be 1377 revoked by the Internet Society or its successors or assigns. 1379 Internet DRAFT SASL 25 October 2004 1381 This document and the information contained herein are provided on an 1382 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1383 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 1384 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 1385 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 1386 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1387 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1389 Acknowledgement 1391 Funding for the RFC Editor function is currently provided by the 1392 Internet Society. 1394 Intellectual Property 1396 The IETF takes no position regarding the validity or scope of any 1397 Intellectual Property Rights or other rights that might be claimed to 1398 pertain to the implementation or use of the technology described in 1399 this document or the extent to which any license under such rights 1400 might or might not be available; nor does it represent that it has 1401 made any independent effort to identify any such rights. Information 1402 on the procedures with respect to rights in RFC documents can be 1403 found in BCP 78 and BCP 79. 1405 Copies of IPR disclosures made to the IETF Secretariat and any 1406 assurances of licenses to be made available, or the result of an 1407 attempt made to obtain a general license or permission for the use of 1408 such proprietary rights by implementers or users of this 1409 specification can be obtained from the IETF on-line IPR repository at 1410 http://www.ietf.org/ipr. 1412 The IETF invites any interested party to bring to its attention any 1413 copyrights, patents or patent applications, or other proprietary 1414 rights that may cover technology that may be required to implement 1415 this standard. Please address the information to the IETF at ietf- 1416 ipr@ietf.org. 1418 Internet DRAFT SASL 25 October 2004 1420 Status of this Memo ..... i 1421 Abstract . 2 1422 1. Conventions used in this document .. 2 1423 2. Introduction . 2 1424 2.1. Relationship to other documents .. 4 1425 3. Authentication mechanisms ... 5 1426 3.1. Authentication Exchange ..... 5 1427 3.2. Identity Concepts . 6 1428 3.2.1. Authorization identities and proxy authentication 1429 ..... 7 1430 3.2.2. Authorization Identity Format 1431 ..... 8 1432 3.3. Security layers 1433 ..... 8 1434 4. Protocol profile requirements 1435 ..... 9 1436 5. Mechanism profile guidelines 1437 ..... 10 1438 6. Specific issues 1439 ..... 12 1440 6.1. Client sends data first 1441 ..... 12 1442 6.1.1. Client sends data first examples 1443 ..... 12 1444 6.2. Server returns success with additional data ..... 13 1445 6.2.1. Server returns success with additional data examples .... 14 1446 6.3. Multiple authentications .... 15 1447 7. The EXTERNAL mechanism . 16 1448 7.1. Formal syntax ..... 16 1449 7.2. Examples of SASL EXTERNAL ... 17 1450 8. IANA Considerations .... 18 1451 8.1. Guidelines for IANA .... 18 1452 8.2. Registration procedure . 18 1453 8.3. Comments on SASL mechanism registrations ... 19 1454 8.4. Change control .... 19 1455 8.5. Registration template .. 19 1456 8.6. The EXTERNAL mechanism registration ... 20 1457 9. Security considerations . 20 1458 9.1. Re-keying .... 22 1459 10. References .. 23 1460 10.1. Normative References .. 23 1461 10.2. Informative References ..... 23 1462 11. Editor's Address .. 24 1463 12. Acknowledgments ... 25 1464 Appendix A. Relation of SASL to transport security .... 25 1465 Appendix B. Changes since RFC 2222 ..... 26 1466 Appendix C. Full Copyright Statement and Intellectual Property Statement 1467 ..... 28 1469 Internet DRAFT SASL 25 October 2004 1471 Full Copyright Statement ..... 28 1472 Intellectual Property ... 29