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