idnits 2.17.1 draft-ietf-ldapext-x509-sasl-03.txt: ** The Abstract section seems to be numbered Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 1) being 60 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** There is 1 instance of too long lines in the document, the longest one being 4 characters in excess of 72. ** The abstract seems to contain references ([3], [1]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 211: '... certification-path [0] CertificationPath OPTIONAL,...' RFC 2119 keyword, line 220: '... response [4] BITSTRING OPTIONAL,...' RFC 2119 keyword, line 221: '... target-name [20] GeneralName OPTIONAL,...' RFC 2119 keyword, line 222: '... signer-name [21] GeneralName OPTIONAL,...' RFC 2119 keyword, line 227: '... protocol [1] Protocol OPTIONAL }...' (2 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 29 has weird spacing: '...listing conta...' -- 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 2000) is 8837 days in the past. Is this intentional? Checking references for intended status: Full Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Missing reference section? '1' on line 442 looks like a reference -- Missing reference section? '3' on line 448 looks like a reference -- Missing reference section? '6' on line 238 looks like a reference -- Missing reference section? '0' on line 232 looks like a reference -- Missing reference section? '2' on line 445 looks like a reference -- Missing reference section? '4' on line 452 looks like a reference -- Missing reference section? '20' on line 221 looks like a reference -- Missing reference section? '21' on line 222 looks like a reference -- Missing reference section? '22' on line 223 looks like a reference -- Missing reference section? '5' on line 458 looks like a reference -- Missing reference section? '7' on line 239 looks like a reference -- Missing reference section? '8' on line 240 looks like a reference Summary: 8 errors (**), 0 flaws (~~), 2 warnings (==), 14 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group S.E. Kille 2 INTERNET-DRAFT MessagingDirect Inc. 3 Expires in six months February 2000 4 Intended Category: Standard 6 X.509 Authentication SASL Mechanism 7 9 1. Status of this Memo 11 This document is an Internet-Draft and is in full conformance with all 12 provisions of Section 10 of RFC2026. Internet-Drafts are working docu- 13 ments of the Internet Engineering Task Force (IETF), its areas, and its 14 working groups. Note that other groups may also distribute working 15 documents as Internet-Drafts. 17 Internet-Drafts are draft documents valid for a maximum of six months 18 and may be updated, replaced, or obsoleted by other documents at any 19 time. It is inappropriate to use Internet-Drafts as reference material 20 or to cite them other than as "work in progress." 22 The list of current Internet-Drafts can be accessed at 23 http://www.ietf.org/ietf/1id-abstracts.txt 25 The list of Internet-Draft Shadow Directories can be accessed at 26 http://www.ietf.org/shadow.html. 28 To learn the current status of any Internet-Draft, please check the 29 "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow 30 Directories on ds.internic.net (US East Coast), nic.nordu.net (Europe), 31 ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific Rim). 33 2. Abstract 35 This document defines a SASL [1] authentication mechanism based on X.509 36 strong authentication [3], providing two way authentication. This 37 mechanism is only for authentication, and has no effect on the protocol 38 encodings and is not designed to provide integrity or confidentiality 39 services. 41 3. Model 43 The mechanism provides two way strong authentication as defined in 44 X.509. The encoding is based on that used by X.500 in the DAP, DSP, and 45 DISP protocols. 47 The mechanism is based on use of an asymmetric (public key) signing 48 mechanism. This SASL mechanism contains two authentication mechanisms: 50 - Client authentication is where the client provides information to 51 the server, so that the server can authenticate the client. 53 - Server authentication is where the server provides information to 54 Expires August 2000 IP X.509 SASL Authentication INTERNET DRAFT 56 the client, so that the client can authenticate the server. 58 This mechanism is given three SASL keys for different variants: 60 - "X509-C-" for client authentication only. 62 - "X509-S-" for server authentication only. 64 - "X509-B-" for client and server authentication. In this 65 case client authentication is done prior to server authentication. 67 Each SASL key may be used with a list of algorithms. A list of sup- 68 ported algorithms is given in Section 7. 70 For Client Authentication ("X509-C-"): 72 1. The client generates the credentials (SASLStrongCredentials) from 73 information on both parties and a random number, and signs the 74 enclosed token with its own private key. 76 2. The client sends credentials to the server. 78 3. The server verifies these credentials using the client's public 79 key, and the authentication is complete. 81 For Server Authentication ("X509-S-"): 83 1. The server generates the credentials (SASLStrongCredentials) from 84 information on both parties and a random number, and signs the 85 enclosed token with its own private key. 87 2. The server sends credentials to the client. 89 3. The client verifies these credentials using the server's public 90 key, and the authentication is complete. 92 For most SASL based protocols, server only authentication will not be 93 useful. However, this is included here, as the definition is required 94 for "client and server", and it may be useful for future protocols. 96 For Client and Server Authentication ("X509-B-"), the procedure for 97 "X509-C-" is performed and then followed by the procedure for "X509-S-". 98 The Client needs to go first, as for some protocols the server will need 99 to get information about the client from the client authentication in 100 order to be able to perform the server authentication. 102 Expires August 2000 IP X.509 SASL Authentication INTERNET DRAFT 104 3.1. Encoding 106 The SASLStrongCredentials, which is the definition of the data format 107 exchanged, is encoded using ASN.1 Distinguished Encoding Rules (DER). 109 4. Why this SASL Mechanism is Needed 111 This section discusses the requirements for this SASL mechanism. 113 4.1. Benefits of a Public Key Mechanism 115 The key benefit of asymmetric (public key) security, is that the secret 116 (private key) only needs to be placed with the entity that is being 117 authenticated. Thus a private key can be issued to a client, which can 118 then be authenticated by ANY server based on a token generated by the 119 client and the generally available public key. Symmetric authentication 120 mechanisms (password mechanisms such as CRAM-MD5) require a shared 121 secret, and the need to maintain it at both endpoints. This means that 122 a secret key for the client needs to be maintained at every server which 123 may need to authenticate the client. 125 This is particularly an issue for protocols such as LDAP, where a client 126 may connect to and be authenticated by a large number of servers. In 127 this situation, the requirement to maintain secret keys on all possible 128 servers is not practical, which makes authentication mechanisms such as 129 CRAM-MD5 unsuitable for LDAP in many situations. 131 4.2. Why Authentication Only? 133 This service provides authentication only. The primary reason for this 134 is that it makes the mechanism very simple. It would be possible to 135 define a more complex mechanism which exchanged session keys and also 136 provided confidentiality and/or integrity. 138 There are a number of places where an authentication only service is 139 useful: 141 - Where confidentiality and integrity are provided by lower layers 142 (e.g., TLS or IPSec). 144 - Where confidentiality or integrity services are provided by the 145 application (e.g., X.500 signed operations). 147 - Where physical and other security aspects of the environment do no 148 require confidentiality and integrity services. 150 - For legacy applications where changes to the data exchange would be 151 difficult to integrate. 153 Expires August 2000 IP X.509 SASL Authentication INTERNET DRAFT 155 4.3. Relationship to TLS 157 The functionality defined here can be provided by TLS, and it is impor- 158 tant to consider why it is useful to have it in both places. There are 159 a number of reasons for this: 161 - SASL. SASL also duplicates TLS functionality, and the rationale 162 for this is clearly given in RFC 2222 [1]. These arguments apply 163 here. 165 - Simplicity. This mechanism is simpler than TLS. If there is only 166 a requirement for this functionality (as distinct from all of TLS), 167 this simplicity will facilitate deployment. 169 - Layering. The SASL mechanism to establish authentication works 170 cleanly with most protocols. This mechanism can fit more cleanly 171 than TLS for some protocols. 173 - Proxy support. Proxys can be cleanly supported with this mechan- 174 ism. This works because the proxy can authenticate the client, and 175 then simply pass the credentials on the server, using the previous 176 token member. 178 - This mechanism provides a simpler solution where no Data Confiden- 179 tiality and integrity required. 181 5. Token Definition 183 The SASLStrongCredentials defined here are based on the StrongCreden- 184 tials defined in X.511, making use of the SIGNED Macro and Certification 185 Path definitions of X.509. Two optional fields have been added, the 186 second of which makes use of GeneralName defined in X.509 [6]. The 187 credentials definition is given here for clarity. The formal defini- 188 tions of CertificationPath, AlgorithmIdentifier, and DistinguishedName 189 are by reference to X.511. The formal definition of GeneralName is 190 given in X.509. 192 There are a number of names referenced in these definitions. There are 193 two entities involved in the interaction: 195 1. Signer. This is the entity that is creating the SASLStrongCreden- 196 tials, and singing it with its private key. The signer is also 197 referred to as the "subject", in line with PKIX terminology, as the 198 signer is essentially proving its own identity. 200 2. Target. This is the entity which is expected to verify the signa- 201 ture. The target's name is included in order to prevent replay 202 attacks, and so it is only the target that can securely verify the 204 Expires August 2000 IP X.509 SASL Authentication INTERNET DRAFT 206 SASLStrongCredentials (other entities can verify the signature, but 207 they would not be able to detect replay attack). This enables the 208 token to be used to build trust chains. 210 SASLStrongCredentials ::= SET { 211 certification-path [0] CertificationPath OPTIONAL, 212 bind-token [1] SASLToken, 213 name [2] DistinguishedName OPTIONAL} -- signer 215 SASLToken ::= SIGNED { SEQUENCE { 216 algorithm [0] AlgorithmIdentifier, 217 name [1] DistinguishedName, -- target 218 time [2] UTCTime, 219 random [3] BITSTRING, 220 response [4] BITSTRING OPTIONAL, 221 target-name [20] GeneralName OPTIONAL, 222 signer-name [21] GeneralName OPTIONAL, 223 previous-token [22] SASLStrongCredentials OPTIONAL}} 225 PreviousToken ::= SEQUENCE { 226 token [0] SASLToken, 227 protocol [1] Protocol OPTIONAL } 229 Protocol ::= INTEGER 231 GeneralName ::= CHOICE { 232 otherName [0] OtherName, 233 rfc822Name [1] IA5String, 234 dNSName [2] IA5String, 235 x400Address [3] ORAddress, 236 directoryName [4] Name, 237 edipartyname [5] EDIPartyName, 238 uniformresouceidentifier [6] IA5String, 239 iPAddress [7] OCTET STRING, 240 registeredID [8] OBJECT IDENTIFIER } 242 The elements of SASLStrongCredentials are as follows: 244 certification-path: 245 This provides a mechanism for exchange of certificates, which may 246 help the recipient to verify the credentials. If this is included, 247 it must be consistent with the name in SASLStrongCredentials.name. 248 This information is provided by the entity generating the token to 249 facilitate verification. The entity verifying the token is not 250 required to use this information. 252 bind-token: 253 This is the signed token, which is the core of the credentials. 255 Expires August 2000 IP X.509 SASL Authentication INTERNET DRAFT 257 name:This is the distinguished name of the signer of the token. For 258 client authentication, this will need to be included unless the 259 information is carried in another protocol element of the exchange 260 (which will typically not be the case). For server authentication, 261 this will not normally be needed, as the client will have a priori 262 knowledge of the server it is connecting to. 264 The entity verifying the token shall ensure that this name is con- 265 sistent with the certificate, as a part of the verification pro- 266 cess. 268 The signed token contains the following elements. 270 algorithm: 271 This is the signature algorithm used to sign the token. This is 272 included for compatibility with X.509, and generally implies both 273 an asymmetric algorithm and a hash algorithm. The value SHALL be 274 consistent with the algorithm defined by the SASL mechanism (e.g., 275 DSA-SHA1). 277 name:This is the distinguished name of the target (which will verify the 278 token). For client authentication, this will be the name of the 279 server. 281 This element is mandatory for compatibility with X.511. If a name 282 form other than Distinguished Name is used, this element should 283 contain a null distinguished name, and a name included in the 284 signer-name parameter. 286 time:This is the time that the token expires. 288 random: 289 This is a random number, which must be unique for the target over 290 the valid life of the token. This is included to prevent replay 291 attack. It is recommended that this number is at least as long as 292 the block size of the hash algorithm used. 294 response: 295 This is used to carry a number derived from random if challenge 296 response of authentication is required. This shall be used in the 297 client phase of X509-B- and in no other circumstances. In this 298 case, the value used in this field in the client authentication 299 shall be used in the SASLToken.random field of the server authenti- 300 cation. 302 items 5-19: 303 There is a gap in the sequence numbering. Items 6-9 are used in 304 X.500 DAP, but are not appropriate here. 306 Expires August 2000 IP X.509 SASL Authentication INTERNET DRAFT 308 target-name: 309 This is a very general definition of a name, taken from X.509(v3). 310 This definition is being used by ongoing work on PKI. This enables 311 authentication identifiers other than distinguished names to be 312 used. This will be important when the target does not have a dis- 313 tinguished name. 315 This field is needed when access control is to be applied on the 316 basis of a name different to the one doing the signing. The name 317 of the entity doing the signing is in SASLStrongCredentials.name, 318 and this is verified by the signing process. This field, verified 319 by the signature, is an alternate name to be used for access con- 320 trol purposes in the authentication and for ongoing purposes with 321 the association established. In SASL terminology, this is the 322 "authorization entity". 324 Note that this description is for tutorial purposes only, and the 325 formal definition is taken from X.511. 327 signer-name 328 This has the same function as name, but allows for encodings other 329 than Distinguished Name. 331 previous-token 332 This gives a mechanism to include a previous token, which includes 333 a SASLToken, and optionally a protocol if this is different from 334 the current protocol. The mechanism might be used in a firewall, 335 which does protocol relay. The initial token is generated by the 336 client, which is then encapsulated in another token generated by 337 the firewall. This enables a signed trust chain to be built. 338 The "change of protocol" enables a server to use a different proto- 339 col on behalf of its client (e.g., an ACAP server performing a 340 directory lookup on behalf of the ACAP client). 342 Protocols are represented as Integers, identified by the TCP Port 343 Number. 345 6. Distinguished Names 347 The X.509 strong authentication mechanism makes use of distinguished 348 names to identify the target. For some protocols, such as LDAP [2], 349 this is natural. For protocols which make use of internet domain names 350 to identify objects, the representation defined in RFC 2247 [5] MAY be 351 used as an alternative to subject-name in the token. For an Internet 352 Mailbox the local part must be encoded as a domain component. For exam- 353 ple "J.Bloggs@widget.com" is represented as the distinguished name 354 "DC=J.Bloggs,DC=widget,DC=com". 356 Expires August 2000 IP X.509 SASL Authentication INTERNET DRAFT 358 7. Supported Algorithms 360 The following signature algorithms are recognized for use with this 361 mechanism, and identified by a key. Each key would be combined to make 362 three possible SASL mechanisms. For example for the DSA-SHA1 algorithm 363 would give X509-C-DSA-SHA1, X509-S-DSA-SHA1, and X509-B-DSA-SHA1. All 364 algorithm names are constrained to 13 characters, to keep within the 365 total SASL limit of 20 characters. 367 The following table gives a list of algorithm keys, noting the 368 object identifier and the body which assigned the identifier. 370 Key Object Id Body 371 RSA-MD4 1.3.14.2.2.2 OIW 372 RSA-MD5 1.3.14.2.2.3 OIW 373 RSA-MD4-ENCR 1.3.14.2.2.4 OIW 374 DSA-SHA 1.3.14.2.2.13 OIW 375 DSA-SHA-COMM 1.3.14.2.2.20 OIW 376 RSA-MD2 1.3.14.7.3.1 OIW 377 ELGAMAL-MD2 1.3.14.7.3.2 OIW 378 RSA-MD2-ENCR 1.2.840.113549.1.1.2 RSA 379 RSA-MD5-ENCR 1.2.840.113549.1.1.4 RSA 380 RSA-SHA1-ENC 1.2.840.113549.1.1.5 RSA 381 MSP-SDNS 2.16.840.1.101.2.1.1.1 DMS 382 MSP-MOSAIC 2.16.840.1.101.2.1.1.2 DMS 383 DSA-SHA1 1.2.840.10040.4.3 ANSI 385 Two special algorithm keys are defined: 387 - IMPLICIT. This is used when the signer has a priori knowledge of 388 the algorithm to use. The algorithms is then identified solely by 389 the AlgrithmIdentifier Object Identifier in the token. 391 - X-*. Any algorithm starting with "X-" is reserved for private 392 extension. 394 Support of the DSS-SHA1 algorithm is recommended for use with this 395 mechanism. 397 8. Example 399 The following example shows use with IMAP4. The example is designed to 400 illustrate the protocol interaction and does not provide valid encoding 401 examples. 403 S: * OK IMAP4 server ready 404 C: AOO1 CAPABILITY 405 Expires August 2000 IP X.509 SASL Authentication INTERNET DRAFT 407 S: * CAPABILITY IMAP4 AUTH=CRAM-MD5 AUTH=X509-C-DSA-SHA1 AUTH=X509-C-RSA-MD5 408 S: A001 OK done 409 C: AOO2 AUTHENTICATE X509-C-DSS-SHA1 410 S: + 411 C: AE31FF05.......== 412 S: + 13c3FF44.......== 413 S: AOO3 OK Welcome, authenticated user: CN=Joe Bloggs,O=Widget,C=GB 415 Editor's Note: 416 The ASN.1 values here are fake. A real example should be used 418 (perhaps include ASN.1 value notation), when one can be generated 419 from a prototype implementation. 421 9. Security Considerations 423 These algorithms are designed to be used for authentication where the 424 underlying transport service cannot guarantee confidentiality. These 425 mechanisms do not prevent an authenticated association from being 426 hijacked. 428 10. Acknowledgments 430 Design ideas included in this document are based on those from ITU and 431 ISO, and the IETF ASID Working Groups. Useful ideas were taken from a 432 note "X.500 Strong Authentication Mechanisms for LDAPv3" by Mark Wahl. 433 The contributions of individuals in these working groups, including 434 Harald Alvestrand (Maxware), Alexis Bor (Directory Works), David Boyce 435 (Isode), William Curtin (DISA), Bruce Greenblatt (RSA), Steve Hole 436 (Esys), Tim Howes (Netscape), John Myers (Netscape), Chris Newman (Inno- 437 soft), Frank Siebeblist (DASCOM), Erik Skovgaard (Geotrain), and Sean 438 Turner (IECA) are gratefully acknowledged. 440 11. Bibliography 442 [1] J. Meyers, "Simple Authentication and Security Layer", RFC 2222, 443 October 1997. 445 [2] M. Wahl, T. Howes, S. Kille, "Lightweight Directory Access Protocol 446 (v3)", RFC 2252, December 1997. 448 [3] ITU-T Recommendation X.509 (1997) | ISO/IEC 9594-8:1997, Information 449 Technology - Open Systems Interconnection - The Directory: Authentica- 450 tion Framework. 452 [4] ITU-T Recommendation X.511 (1997) | ISO/IEC 9594-8:1997, Information 453 Technology - Open Systems Interconnection - The Directory: Abstract 454 Service Definition. 456 Expires August 2000 IP X.509 SASL Authentication INTERNET DRAFT 458 [5] S. Kille, M.Wahl, A. Grimstad, R. Huber, S. Sataluri, "Using Domains 459 in LDAP/X.500 Distinguished Names", RFC 2247, January 1998. 461 12. Author's Address 463 Steve Kille 464 MessagingDirect Inc 465 The Dome, The Square 466 Richmond, Surrey, 467 TW9 1DT, UK 469 Phone: +44-20-8332-9091 470 Email: Steve.Kille@messagingdirect.com