idnits 2.17.1 draft-ietf-ldapext-x509-sasl-00.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): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-25) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. 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 the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. 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 5 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 194: '... certification-path [0] CertificationPath OPTIONAL,...' RFC 2119 keyword, line 205: '... response [4] BITSTRING OPTIONAL,...' RFC 2119 keyword, line 206: '... generation-time [20] UTCTime OPTIONAL,...' RFC 2119 keyword, line 279: '...to identify objects, the representation defined in RFC 2247 [5] MAY be...' Miscellaneous warnings: ---------------------------------------------------------------------------- -- 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 (July 1998) is 9416 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 333 looks like a reference -- Missing reference section? '3' on line 339 looks like a reference -- Missing reference section? '6' on line 216 looks like a reference -- Missing reference section? '0' on line 210 looks like a reference -- Missing reference section? '2' on line 336 looks like a reference -- Missing reference section? '4' on line 343 looks like a reference -- Missing reference section? '20' on line 206 looks like a reference -- Missing reference section? '21' on line 207 looks like a reference -- Missing reference section? '5' on line 347 looks like a reference -- Missing reference section? '7' on line 217 looks like a reference -- Missing reference section? '8' on line 218 looks like a reference Summary: 11 errors (**), 0 flaws (~~), 0 warnings (==), 13 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 Isode Ltd. 3 Expires in six months July 1998 4 Intended Category: Standard 6 X.509 Authentication SASL Mechanism 7 9 1. Status of this Memo 11 This document is an Internet-Draft. Internet-Drafts are working docu- 12 ments of the Internet Engineering Task Force (IETF), its areas, and its 13 working groups. Note that other groups may also distribute working 14 documents as Internet-Drafts. 16 Internet-Drafts are draft documents valid for a maximum of six months 17 and may be updated, replaced, or obsoleted by other documents at any 18 time. It is inappropriate to use Internet-Drafts as reference material 19 or to cite them other than as "work in progress." 21 To view the entire list of current Internet-Drafts, please check 22 the "1id-abstracts.txt" listing contained in the Internet-Drafts 23 Shadow Directories on ftp.is.co.za (Africa), ftp.nordu.net 24 (Northern Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au 25 (Pacific Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu 26 (US West Coast). 28 2. Abstract 30 This document defines a SASL [1] authentication mechanism based on X.509 31 strong authentication [3], providing two way authentication. This 32 mechanism is only for authentication, and has no effect on the protocol 33 encodings and is not designed to provide integrity or confidentiality 34 services. 36 3. Model 38 The mechanism provides two way strong authentication as defined in 39 X.509. The encoding is based on on that used by X.500 in the DAP, DSP, 40 and DISP protocols. 42 The mechanism is based on use of an assymetric (public key) signing 43 mechanism. The SASL mechanism contains two symmetric authentication 44 mechanisms: 46 - Client authentication is where the client provides information to 47 the server, so that the server can authenticate the client. 49 - Server authentication is where the server provides information to 50 Expires January 1999 IP X.509 SASL Authentication INTERNET DRAFT 52 the client, so that the client can authenticate the server. 54 This mechanism is given three SASL keys for different variants: 56 - "X509-CLIENT-" for client authentication only. 58 - "X509-SERVER-" for sever authentication only. 60 - "X509-BOTH-" for client and server authentication. In 61 this case client authentication is done prior to server authentica- 62 tion. 64 Each SASL key may be used with a list of algorithms. Supported algo- 65 rithms in this version are "DSS", "RSA", and "X-". 67 For Client Authentication ("X509-CLIENT"): 69 1. The client generates the credentials (SASLStrongCredentials) using 70 local information, and signs the enclosed token with its own 71 private key. 73 2. The client sends credentials to the server. 75 3. The server verifies these credentials using the client's public 76 key, and the authentication is complete. 78 For Serever Authentication ("X509-SERVER"): 80 1. The server generates the credentials (SASLStrongCredentials) using 81 local information, and signs the enclosed token with its own 82 private key. 84 2. The server sends credentials to the client. 86 3. The client verifies these credentials using the server's public 87 key, and the authentication is complete. 89 For Client and Server Authentication ("X509-BOTH"), the procedure for 90 "X509-CLIENT" is performed and then followed by the procedure for 91 "X509-SERVER". 93 3.1. Encoding 95 The SASLStrongCredentials, which is the definition of the data format 96 exchanged, is encoded using ASN.1 Basic Encoding Rules (BER). 98 Expires January 1999 IP X.509 SASL Authentication INTERNET DRAFT 100 4. Why this SASL Mechanism is Needed 102 This section discusses the requirements for this SASL mechanism. 104 4.1. Benefits of a Public Key Mechanism 106 The key benefit of assymetric (public key) security, is that the secret 107 only needs to be placed with the entity that is being authenticated. 108 Thus a secret key can be given to a client, which can then be authenti- 109 cated by ANY server. Symmetric authentication requires a shared secret, 110 and the need to maintain it at both endpoints. This means that a secret 111 key for the client needs to be maintained at every server which may need 112 to authenticate the client. 114 This is particularly an issue for protocols such as LDAP, where a client 115 may connect to and be authenticated by a large number of servers. In 116 this situation, the requirement to maintain secret keys on all possible 117 servers is not practical, which makes authentication mechanisms such as 118 CRAM-MD5 unsuitable for LDAP in many situations. 120 4.2. Why Authentication Only? 122 This service provides authentication only. The primary reason for this 123 is that it makes the mechanism very simple. It would be possible to 124 define a more complex mechanism which exchanged session keys and also 125 provided confidentiality and/or integrity. 127 There are a number of places where an authentication only service is 128 useful: 130 - Where confidentiality and integrity are provided by lower layers 131 (e.g., TLS or IPSec). 133 - Where confidentialy or integrity services are provided by the 134 application (e.g., X.500 signed operations). 136 - Where physical and other security aspects of the environment do no 137 require confidentiality and integrity services. 139 - For legacy applications where changes to the data exchange would be 140 difficult to integrate. 142 4.3. Relatiohship to TLS 144 The functionality defined here can be provided by TLS, and it is impor- 145 tant to consider why it is useful to have it in both places. There are 146 a number of reasons for this: 148 Expires January 1999 IP X.509 SASL Authentication INTERNET DRAFT 150 - SASL. SASL also duplicates TLS functionality, and the rationale 151 for this is clearly given in RFC 2222 [1]. These arguments apply 152 here. 154 - Simplicity. This mechanism is a great deal simpler than TLS. If 155 there is only a requirement for this functionality (as distinct 156 from all of TLS), this simplicity will facilitate deployment. 158 - Layering. The SASL mechanism to establish authentication works 159 cleanly with most protocols. TLS often layers awkwardly, and does 160 not provide the authentication dialogue at the right stage in the 161 protocol negotiation. 163 - Proxy support. Proxys can be cleanly supported with this mechan- 164 ism, but not with TLS. This works because the proxy can authenti- 165 cate the client, and then simply pass the credentials on the the 166 server. 168 - No Data Confidentiality and integrity required. In many situa- 169 tions, the data confidentiality and integrity provided by TLS is 170 not needed, and in this situation use of TLS provides an unecessary 171 overhead and complexity. 173 - Export. Because of its data confidentiality functionality, TLS 174 will often have export problems. When used with a signing algo- 175 rithm such as DSS that cannot be used for data confidentiality, 176 export problems for this mechanism will be much less. For this 177 reason, it will be much easier to globally deploy this mechanism 178 than TLS. It is also useful that if an "export product" uses 179 "weak" data confidentiality, that a separate authentication mechan- 180 ism will mean that authentication does not need to be weakened. 182 5. Token Definition 184 The SASLStrongCredentials defined here are based on the StrongCreden- 185 tials defined in X.511, making use of the SIGNED Macro and Certification 186 Path definitions of X.509. Two optional fields have been added, the 187 second of which makes use of GeneralName defined in X.509 [6]. The 188 credentials definition is given here for clarity. The formal defini- 189 tions of CertificationPath, AlgorithmIdentifier, and DistinguishedName 190 are by reference to X.511. The formal definition of GeneralName is 191 given in X.509. 193 SASLStrongCredentials ::= SET { 194 certification-path [0] CertificationPath OPTIONAL, 195 bind-token [1] SASLToken, 196 name [2] DistinguishedName OPTIONAL} 198 Expires January 1999 IP X.509 SASL Authentication INTERNET DRAFT 200 SASLToken ::= SIGNED { SEQUENCE { 201 algorithm [0] AlgorithmIdentifier, 202 name [1] DistinguishedName, 203 time [2] UTCTime, 204 random [3] BITSTRING, 205 response [4] BITSTRING OPTIONAL, 206 generation-time [20] UTCTime OPTIONAL, 207 subject-name [21] GeneralName OPTIONAL}} 209 GeneralName ::= CHOICE { 210 otherName [0] OtherName, 211 rfc822Name [1] IA5String, 212 dNSName [2] IA5String, 213 x400Address [3] ORAddress, 214 directoryName [4] Name, 215 edipartyname [5] EDIPartyName, 216 uniformresouceidentifier [6] IA5String, 217 iPAddress [7] OCTET STRING, 218 registeredID [8] OBEJCT IDENTIFIER } 220 The elemements of SASLStrongCredentials are as follows: 222 certification-path: 223 This provides a mechanism for exchange of certificates, which may 224 help the recipient to verify the credentials. 226 bind-token: 227 This is the signed token, which is the core of the credentials. 229 name:This is the name of the signer of the token. For client authenti- 230 cation, this will need to be included unless the information is 231 carried in another protocol element of the exchange. For server 232 authentication, this will not normally be needed. 234 The signed token contains the following elements. 236 algorithm: 237 This is the algorithm used to sign the token. 239 name:This is the name of the object that is verifying the token. For 240 client authentication, this will be the name of the server. 242 time:This is the time that the token expires. 244 random: 245 This is a random number, which should be unique for the target over 246 the valid life of the token. This is included to prevent replay 247 attack. 249 Expires January 1999 IP X.509 SASL Authentication INTERNET DRAFT 251 items 6-19: 252 There is a gap in the sequence numbering. Items 6-9 are used in 253 X.500 DAP, but are not appropriate here. 255 response: 256 This is used to carry a number derived from random if challenge 257 response of authentication is required. This shall be used in the 258 client phase of X509-BOTH and in no other circumstances. 260 generation-time: 261 This is the time that the token was generated. It may be generated 262 by the client. It may be used by the entity verifying the token to 263 not accept the token prior to its exiry time. 265 subject-name: 266 This is a very general definition of a name, taken from X.509(v3). 267 This definition is being used by ongoing work on PKI. This enables 268 authentication identifiers other than distinguished names to be 269 used. 271 Note that this description is for tutorial purposes only, and the formal 272 definition is taken from X.511. 274 6. Distinguished Names 276 The X.509 strong authentication mechanism makes use of distinguished 277 names to identify the target. For some protocols, such as LDAP [2], 278 this is natural. For protocols which make use of internet domain names 279 to identify objects, the representation defined in RFC 2247 [5] MAY be 280 used as an alternative to subject-name in the token. For an Internet 281 Mailbox the local part should be encoded as a domain component. For 282 example "J.Bloggs@widget.com" is represented as the distinguished name 283 "DC=J.Bloggs,DC=widget,DC=com". 285 7. Supported Algorithms 287 The following algorithms are recognised for use with this mechanism: 289 1. DSS. (X509-CLIENT-DSS, X509-SERVER-DSS, X509-BOTH-DSS). 291 2. RSA. (X509-CLIENT-RSA, X509-SERVER-RSA, X509-BOTH-RSA). 293 The set of supported algorithms is handled by the SASL negotiation. Sup- 294 port of the DSS algorithm is recommended for use with this mechanism. 296 8. Example 298 The following example shows use with IMAP4. The example is designed to 299 Expires January 1999 IP X.509 SASL Authentication INTERNET DRAFT 301 illustrate the protocol interaction and does not provide valid encoding 302 examples. 304 S: * OK IMAP4 server ready 305 C: AOO1 CAPABILITY 306 S: * CAPABILITY IMAP4 AUTH=CRAM-MD5 AUTH=X509-CLIENT-RSA AUTH=X509-CLIENT-DSS 307 S: A001 OK done 308 C: AOO2 AUTHENTICATE X509-CLIENT-DSS 309 S: + 310 C: AE31FF05.......== 311 S: + 13c3FF44.......== 312 S: AOO3 OK Welcome, authenticated user: CN=Joe Bloggs,O=Widget,C=GB 314 9. Security Considerations 316 These algorithms are designed to be used for authentication where the 317 underlying transport service cannot guarantee confidentiality. These 318 mechanisms do not prevent an authenticated association from being 319 hijacked. 321 10. Acknowledgements 323 Design ideas included in this document are based on those from ITU and 324 ISO, and the IETF ASID Working Groups. Useful ideas were taken from a 325 note "X.500 Strong Authentication Mechanisms for LDAPv3" by Mark Wahl. 326 The contributions of individuals in these working groups, including 327 Harald Alvestrand (Maxware), Alexis Bor (Directory Works), William Cur- 328 tin (DISA), Steve Hole (Esys), Tim Howes (Netscape), John Myers 329 (Netscape), and Sean Turner (IECA) are gratefully acknowledged. 331 11. Bibliography 333 [1] J. Meyers, "Simple Authentication and Security Layer", RFC 2222, 334 October 1997. 336 [2] M. Wahl, T. Howes, S. Kille, "Lightweight Directory Access Protocol 337 (v3)", RFC 2252, December 1997. 339 [3] ITU-T Recommendation X.509 (1997) | ISO/IEC 9594-8:1997, Information 340 Technology - Open Systems Interconnection - The Directory: Authentica- 341 tion Framework. 343 [4] ITU-T Recommendation X.511 (1997) | ISO/IEC 9594-8:1997, Information 344 Technology - Open Systems Interconnection - The Directory: Abstract 345 Service Definition. 347 [5] S. Kille, M.Wahl, A. Grimstad, R. Huber, S. Sataluri, "Using Domains 348 in LDAP/X.500 Distinguished Names", RFC 2247, January 1998. 350 Expires January 1999 IP X.509 SASL Authentication INTERNET DRAFT 352 12. Author's Address 354 Steve Kille 355 Isode Ltd 356 The Dome, The Square 357 Richmond, Surrey, 358 TW9 1DT, UK 360 Phone: +44-181-332-9091 361 Email: S.Kille@isode.com