idnits 2.17.1 draft-nystrom-securid-sasl-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents -- however, there's a paragraph with a matching beginning. Boilerplate error? == There is 1 instance of lines with non-ascii characters in the document. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 4 instances of too long lines in the document, the longest one being 2 characters in excess of 72. ** The abstract seems to contain references ([RFC2119], [RFC2222]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (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 (June 1999) is 9081 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Looks like a reference, but probably isn't: '0' on line 131 == Unused Reference: 'RFC2279' is defined on line 422, but no explicit reference was found in the text ** Obsolete normative reference: RFC 1734 (Obsoleted by RFC 5034) ** Obsolete normative reference: RFC 2060 (Obsoleted by RFC 3501) ** Obsolete normative reference: RFC 2222 (Obsoleted by RFC 4422, RFC 4752) ** Obsolete normative reference: RFC 2252 (ref. 'RFC2251') (Obsoleted by RFC 4510, RFC 4512, RFC 4517, RFC 4523) ** Obsolete normative reference: RFC 2279 (Obsoleted by RFC 3629) Summary: 11 errors (**), 0 flaws (~~), 3 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 INTERNET-DRAFT M. Nystrom 2 Expires: December 1999 J. Brainard 3 Intended Category: Informational RSA Laboratories 4 June 1999 6 The SecurID(r) SASL Mechanism 8 Status of this Memo 10 This document is an Internet-Draft and is in full conformance with 11 all provisions of Section 10 of [RFC2026]. 13 Internet-Drafts are working documents of the Internet Engineering 14 Task Force (IETF), its areas, and its working groups. Note that 15 other groups and individuals may also distribute working documents as 16 Internet-Drafts. 18 Internet-Drafts are draft documents valid for a maximum of six months 19 and may be updated, replaced, or obsoleted by other documents at any 20 time. It is inappropriate to use Internet-Drafts as reference 21 material or to cite them other than as "work in progress." 23 The list of current Internet-Drafts can be accessed at 24 http://www.ietf.org/ietf/1id-abstracts.txt. 26 The list of Internet-Draft Shadow Directories can be accessed at 27 http://www.ietf.org/shadow.html. 29 This Internet-Draft expires in December, 1999. Comments and 30 suggestions on this document are encouraged. Comments on this 31 document should be sent directly to the author. 33 Abstract 35 SecurID is a hardware token card product (or software emulation 36 thereof) produced by Security Dynamics, which is used for end-user 37 authentication. This document defines a SASL authentication mechanism 38 using these tokens, thereby providing a means for such tokens to be 39 used in SASL [RFC2222] environments. This mechanism is only for 40 authentication, and has no effect on the protocol encoding and is not 41 designed to provide integrity or confidentiality services. 43 This memo assumes the reader has basic familiarity with the SecurID 44 token, its associated authentication protocol and SASL. 46 How to read this document 48 The key words "MUST", "SHOULD" and "MAY" in this document are to be 49 interpreted as defined in [RFC2119]. 51 In examples, "C:" and "S:" indicate messages sent by the client and 52 server respectively. 54 1. Introduction 56 The SECURID SASL mechanism is a good choice for usage scenarios where 57 a client, acting on behalf of a user, is untrusted, as a one-time 58 passcode will only give the client a single opportunity to act 59 maliciously. This mechanism provides authentication only. 61 The SECURID SASL mechanism provides a formal way to integrate the 62 existing SecurID authentication method into SASL-enabled protocols 63 including IMAP [RFC2060], ACAP [RFC2244], POP3 [RFC1734] and LDAPv3 64 [RFC2251]. 66 2. Authentication Model 68 The SECURID SASL mechanism provides one-way two-factor based 69 authentication as defined below. 71 There are basically three entities in the authentication mechanism 72 described here: A user, possessing a SecurID token, an application 73 server, to which the user wants to connect, and an authentication 74 server, capable of authenticating the user. Even though the 75 application server in practice may function as a client with respect 76 to the authentication server, relaying authentication credentials etc 77 as needed, both servers are, unless explicitly mentioned, 78 collectively termed "the server" here. The protocol used between the 79 application server and the authentication server is outside the scope 80 of this memo. The application client, acting on behalf of the user, 81 is termed "the client". 83 The mechanism is based on the use of a shared secret key, or 'seed', 84 and a personal identification number (PIN), which is known both by 85 the user and the authentication server. Hence the term 'two-factor 86 authentication'. The secret seed is stored on a token that the 87 client (user) possesses, as well as on the authentication server. 88 Given the seed, current time of day, and the PIN, a "PASSCODE(r)" is 89 generated by the user's token and sent to the server. 91 The SECURID SASL mechanism provides one service: 93 - Client authentication where the client provides information to 94 the server, so that the server can authenticate the client. 96 This mechanism is identified with the SASL key "SECURID". 98 3. Authentication Procedure 100 a) The client generates the credentials using local information 101 (seed, current time and user PIN/password). 103 b) If the underlying protocol permits, the client sends credentials 104 to the server in an initial response message. Otherwise, the 105 client sends a request to the server to initiate the 106 authentication mechanism, and sends credentials after the server's 107 response (see [RFC2222] section 5.1 for more information regarding 108 the initial response option). 110 Unless the server requests a new PIN (see below), the contents of 111 the clients initial response SHALL be as follows: 113 (1) An authorization identity. When this field isn't present, 114 this defaults to the authentication identity. This field may be 115 used by system administrators or proxy servers to login with a 116 different user identity. 118 (2) An authentication identity. The identity whose passcode 119 will be used. If this field isn't present, it is assumed to have 120 been transferred by other means (e.g. if the underlying protocol 121 has support for this, like [RFC2251]). 123 (3) A passcode. The one-time password that will be used to grant 124 access. 126 This message is defined in ASN.1 [X680] as follows: 128 SecurIDSASLCredentialsPDU ::= SEQUENCE { 129 version INTEGER {v1(0)} (v1,...) DEFAULT v1, 130 authorizationID UTF8String OPTIONAL, 131 authenticationID [0] IMPLICIT UTF8String OPTIONAL, 132 passcode OCTET STRING (SIZE (4..32)), 133 pin UTF8String (SIZE (4..32)) OPTIONAL, 134 ... -- For future extensions 135 } 137 (The 'pin' field shall only be present when the server has sent a 138 request for a new user PIN.) 140 Values shall be DER-encoded [X690] before transformed in 141 accordance with the underlying protocol. Passcodes usually 142 consist of 4-8 digits. 144 c) The server verifies these credentials using its own information. 145 If the verification succeeds, the server sends back a 146 response indicating success to the client. After receiving this 147 response, the client is authenticated. Otherwise, the verification 148 either failed or the server needs an additional set of credentials 149 from the client in order to authenticate the user. 151 d) If the server needs an additional set of credentials, it requests 152 them now. The request has the following format and shall be 153 DER-encoded before being transformed in accordance with the 154 underlying protocol: 156 SecurIDSASLCredentialsRequest ::= SEQUENCE { 157 version INTEGER {v1(0)} (v1,...) DEFAULT v1, 158 request CHOICE { 159 passcode NULL, 160 pin UTF8String (SIZE (0|4..32)), 161 ... -- For future extensions 162 } 163 } 165 The 'passcode' choice will be sent when the server requests a 166 passcode. The 'pin' choice will be sent when the server requests a 167 new user password. The server will either send an empty string or 168 suggest a new user PIN in this message. 170 e) The client generates a new set of credentials using local 171 information and depending on the servers request and sends them to 172 the server. Authentication now continues as in c) above. 174 Note 1: Case d) above may occur e.g. when the clocks on which the 175 server and the client relies are not synchronized. 177 Note 2: If the server requested a new user PIN, the client MUST 178 respond with a new user PIN (together with a passcode), encoded as a 179 UTF8String. If the server supplied the client with a suggested PIN, 180 the client accepts this by replying with the same PIN, but MAY 181 replace it with another one. The length of the PIN is application- 182 dependent as is any other requirements for the PIN, e.g. allowed 183 characters. If the server for some reason does not accept the 184 received PIN, the client MUST be prepared to receive either a message 185 indicating the failure of the authentication or a repeated request 186 for a new PIN. Mechanisms for transferring knowledge about PIN 187 requirements from the server to the client is outside of the scope 188 for this memo. However, some information MAY be provided in error 189 messages transferred from the server to the client when applicable. 191 4. Examples 193 4.1 IMAP4 194 The following example shows the use of the SECURID SASL mechanism 195 with IMAP4. The example is only designed to illustrate the protocol 196 interaction but does provide valid encoding examples. 198 S: * OK IMAP4 server ready 199 C: AOO1 CAPABILITY 200 S: * CAPABILITY IMAP4 AUTH=CRAM-MD5 AUTH=SECURID 201 S: A001 OK done 202 C: AOO2 AUTHENTICATE SECURID 203 S: + 204 C: MBKABm1hZ251cwQIMTIzNDU2Nzg= 205 S: AOO2 OK Welcome, SECURID authenticated user: magnus 207 4.2 LDAPv3 209 The following examples show the use of the SECURID SASL mechanism 210 with LDAPv3. The examples are only designed to illustrate the 211 protocol interaction, but does provide valid encoding examples. 212 Usernames, passcodes and PINs are of course fictitious. For 213 readability, all messages is shown in the value-notation defined in 214 [X680]. 216 4.2.1 LDAPv3 Example 1 218 Initial response message, successful authentication. 220 C: { messageID 1, 221 protocolOp bindRequest : 222 { version 1, 223 name '434E3D4D41474E5553'H, 224 authentication sasl : 225 { mechanism '53454355524944'H, 226 credentials '300A04083132333435363738'H 227 } 228 } 229 } 231 S: { messageID 1, 232 protocolOp bindResponse : 233 { resultCode success, 234 matchedDN ''H, 235 errorMessage ''H, 236 } 237 } 239 4.2.2 LDAPv3 Example 2 241 Initial response message, server requires second passcode. 243 C: { 244 messageID 1, 245 protocolOp bindRequest : { 246 version 1, 247 name '434E3D4D41474E5553'H, 248 authentication sasl : { 249 mechanism '53454355524944'H, 250 credentials '300A04083132333435363738'H 251 } 252 } } 254 S: { 255 messageID 1, 256 protocolOp bindResponse : { 257 resultCode saslBindInProgress, 258 matchedDN ''H, 259 errorMessage ''H, 260 serverSaslCreds '30020500'H 261 } } 263 C: { 264 messageID 1, 265 protocolOp bindRequest : { 266 version 1, 267 name '434E3D4D41474E5553'H, 268 authentication sasl : { 269 mechanism '53454355524944'H, 270 credentials '300A04083131333335353636'H 271 } 272 } } 274 S: { 275 messageID 1, 276 protocolOp bindResponse : { 277 resultCode success, 278 matchedDN ''H, 279 errorMessage ''H, 280 } } 282 4.2.3 LDAPv3 Example 3 284 Initial response message, server requires new PIN and passcode, and 285 supplies client with a suggested new PIN (which the client accepts). 287 C: { 288 messageID 1, 289 protocolOp bindRequest : { 290 version 1, 291 name '434E3D4D41474E5553'H, 292 authentication sasl : { 293 mechanism '53454355524944'H, 294 credentials '300A04083132333435363738'H 295 } 296 } } 298 S: { 299 messageID 1, 300 protocolOp bindResponse : { 301 resultCode saslBindInProgress, 302 matchedDN ''H, 303 errorMessage ''H, 304 serverSaslCreds '30070C056B616C6C65'H 305 } } 307 C: { 308 messageID 1, 309 protocolOp bindRequest : { 310 version 1, 311 name '434E3D4D41474E5553'H, 312 authentication sasl : { 313 mechanism '53454355524944'H, 314 credentials '3011040831323334353637380C056B616C6C65'H 315 } 316 } } 318 S: { 319 messageID 1, 320 protocolOp bindResponse : { 321 resultCode success, 322 matchedDN ''H, 323 errorMessage ''H, 324 } } 326 5. Security Considerations 328 This mechanism does not provide session privacy, server 329 authentication or protection from active attacks. In particular, 330 man-in-the-middle attacks, were an attacker acts as an application 331 server in order to acquire a valid passcode are possible. 333 In order to protect against such attacks, the client SHOULD make 334 sure that the server is properly authenticated. When user PINs are 335 transmitted, authentication SHOULD take place on an authenticated and 336 confidentiality-protected connection. 338 Server implementations MUST protect against replay attacks. 340 Implementations MUST support passcodes with at least a length of 4 341 characters, in order to protect against passcode-guessing attacks. 343 6. IANA Considerations 345 By registering the SecurID protocol as a SASL mechanism, implementers 346 will have a well-defined way of adding this authentication mechanism 347 to their product. Here is the registration template for the SECURID 348 SASL mechanism: 350 SASL mechanism name: SECURID 351 Security Considerations: See corresponding section of this memo 352 Published specification: This memo 353 Person & email address to 354 contact for further 355 information: See author's address section below 356 Intended usage: COMMON 357 Author/Change controller: See author's address section below 359 7. Intellectual Property Considerations 361 Neither RSA Data Security Inc. or Security Dynamics Technologies Inc. 362 makes any claims on the general constructions described in this memo, 363 although underlying techniques may be covered. Among the underlying 364 techniques, the SecurID technology is covered by a number of US 365 patents, in particular US patent no. 4,885,778, no. 5,097,505, no. 366 5,168,520, and 5,657,388. 368 Security Dynamics and SecurID are registered trademarks, and PASSCODE 369 is a trademark, of Security Dynamics Technologies, Inc. 371 8. Copyright 373 Copyright (C) The Internet Society (date). All Rights Reserved. 375 This document and translations of it may be copied and furnished to 376 others, and derivative works that comment on or otherwise explain it 377 or assist in its implementation may be prepared, copied, published 378 and distributed, in whole or in part, without restriction of any 379 kind, provided that the above copyright notice and this paragraph are 380 included on all such copies and derivative works. However, this 381 document itself may not be modified in any way, such as by removing 382 the copyright notice or references to the Internet Society or other 383 Internet organizations, except as needed for the purpose of 384 developing Internet standards in which case the procedures for 385 copyrights defined in the Internet Standards process must be 386 followed, or as required to translate it into languages other than 387 English. 389 The limited permissions granted above are perpetual and will not be 390 revoked by the Internet Society or its successors or assigns. 392 This document and the information contained herein is provided on an 393 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 394 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 395 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 396 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 397 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 399 9. References 401 [RFC1734] Myers, J., "POP3 AUTHentication command," IETF RFC 1734, 402 December 1994. 404 [RFC2026] Bradner, S., "The Internet Standards Process -- Revision 405 3," IETF RFC 2026, October 1996. 407 [RFC2060] Crispin, M., "Internet Message Access Protocol - Version 408 4rev1," IETF RFC 2060, December 1996. 410 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 411 Requirement Levels," IETF RFC 2119, March 1997. 413 [RFC2222] Myers, J., "Simple Authentication and Security Layer," IETF 414 RFC 2222, October 1997. 416 [RFC2244] Newman, C., "RFC2244 -- Application Configuration Access 417 Protocol," IETF RFC 2244, November 1997. 419 [RFC2251] Wahl, M., et al, "Lightweight Directory Access Protocol 420 (v3)," IETF RFC 2252, December 1997. 422 [RFC2279] Yergeau, F., "UTF-8, a transformation format of ISO 10646," 423 IETF RFC 2279, January 1998. 425 [X3.4] ANSI, "ANSI X3.4: Information Systems - Coded Character Sets - 426 7-Bit American National Standard Code for Information Interchange 427 (7-Bit ASCII)," American National Standards Institute. 429 [X680] ITU-T, "Information technology - Abstract Syntax Notation One 430 (ASN.1): Specification of basic notation," ITU-T Recommendation 431 X.680, 1994. 433 [X690] ITU-T, "Information technology - ASN.1 encoding rules: 434 SPecification of Basic Encoding Rules (BER), Canonical Encoding Rules 435 (CER) and Distinguished Encoding Rules (DER)," ITU-T Recommendation 436 X.690, 1994. 438 10. Acknowledgements 440 The authors gratefully acknowledge the contributions of various 441 reviewers of this memo, in particular the ones from John Myers. They 442 have significantly clarified and improved the utility of this 443 specification. 445 11. Author's Address 447 Magnus Nystr�m 448 RSA Laboratories 449 20 Crosby Drive 450 Bedford, MA 01730 452 Phone: +1-781-687-7000 453 Email: magnus@rsa.com 455 John Brainard 456 RSA Laboratories 457 20 Crosby Drive 458 Bedford, MA 01730 460 Phone: +1-781-687-7000 461 Email: jbrainard@rsa.com