| blob | 0137dd891d679ed74c6a5c7f936f6347a6823cc9 |
1 \r
2 \r
3 \r
4 \r
5 \r
6 \r
7 Network Working Group M. Nystrom\r
8 Request for Comments: 2808 RSA Laboratories\r
9 Category: Informational April 2000\r
10 \r
11 \r
12 The SecurID(r) SASL Mechanism\r
13 \r
14 Status of this Memo\r
15 \r
16 This memo provides information for the Internet community. It does\r
17 not specify an Internet standard of any kind. Distribution of this\r
18 memo is unlimited.\r
19 \r
20 Copyright Notice\r
21 \r
22 Copyright (C) The Internet Society (2000). All Rights Reserved.\r
23 \r
24 Abstract\r
25 \r
26 SecurID is a hardware token card product (or software emulation\r
27 thereof) produced by RSA Security Inc., which is used for end-user\r
28 authentication. This document defines a SASL [RFC2222] authentication\r
29 mechanism using these tokens, thereby providing a means for such\r
30 tokens to be used in SASL environments. This mechanism is only for\r
31 authentication, and has no effect on the protocol encoding and is not\r
32 designed to provide integrity or confidentiality services.\r
33 \r
34 This memo assumes the reader has basic familiarity with the SecurID\r
35 token, its associated authentication protocol and SASL.\r
36 \r
37 How to read this document\r
38 \r
39 The key words "MUST", "MUST NOT", "SHALL", "SHOULD" and "MAY" in this\r
40 document are to be interpreted as defined in [RFC2119].\r
41 \r
42 In examples, "C:" and "S:" indicate messages sent by the client and\r
43 server respectively.\r
44 \r
45 1. Introduction\r
46 \r
47 The SECURID SASL mechanism is a good choice for usage scenarios where\r
48 a client, acting on behalf of a user, is untrusted, as a one-time\r
49 passcode will only give the client a single opportunity to act\r
50 maliciously. This mechanism provides authentication only.\r
51 \r
52 \r
53 \r
54 \r
55 \r
56 \r
57 \r
58 Nystrom Informational [Page 1]\r
60 RFC 2808 The SecurID(r) SASL Mechanism April 2000\r
61 \r
62 \r
63 The SECURID SASL mechanism provides a formal way to integrate the\r
64 existing SecurID authentication method into SASL-enabled protocols\r
65 including IMAP [RFC2060], ACAP [RFC2244], POP3 [RFC1734] and LDAPv3\r
66 [RFC2251].\r
67 \r
68 2. Authentication Model\r
69 \r
70 The SECURID SASL mechanism provides two-factor based user\r
71 authentication as defined below.\r
72 \r
73 There are basically three entities in the authentication mechanism\r
74 described here: A user, possessing a SecurID token, an application\r
75 server, to which the user wants to connect, and an authentication\r
76 server, capable of authenticating the user. Even though the\r
77 application server in practice may function as a client with respect\r
78 to the authentication server, relaying authentication credentials\r
79 etc. as needed, both servers are, unless explicitly mentioned,\r
80 collectively termed "the server" here. The protocol used between the\r
81 application server and the authentication server is outside the scope\r
82 of this memo. The application client, acting on behalf of the user,\r
83 is termed "the client".\r
84 \r
85 The mechanism is based on the use of a shared secret key, or "seed",\r
86 and a personal identification number (PIN), which is known both by\r
87 the user and the authentication server. The secret seed is stored on\r
88 a token that the user possesses, as well as on the authentication\r
89 server. Hence the term "two-factor authentication", a user needs not\r
90 only physical access to the token but also knowledge about the PIN in\r
91 order to perform an authentication. Given the seed, current time of\r
92 day, and the PIN, a "PASSCODE(r)" is generated by the user's token\r
93 and sent to the server.\r
94 \r
95 The SECURID SASL mechanism provides one service:\r
96 \r
97 - User authentication where the user provides information to the\r
98 server, so that the server can authenticate the user.\r
99 \r
100 This mechanism is identified with the SASL key "SECURID".\r
101 \r
102 3. Authentication Procedure\r
103 \r
104 a) The client generates the credentials using local information\r
105 (seed, current time and user PIN/password).\r
106 \r
107 \r
108 \r
109 \r
110 \r
111 \r
112 \r
113 \r
114 Nystrom Informational [Page 2]\r
116 RFC 2808 The SecurID(r) SASL Mechanism April 2000\r
117 \r
118 \r
119 b) If the underlying protocol permits, the client sends credentials\r
120 to the server in an initial response message. Otherwise, the\r
121 client sends a request to the server to initiate the\r
122 authentication mechanism, and sends credentials after the server's\r
123 response (see [RFC2222] section 5.1 for more information regarding\r
124 the initial response option).\r
125 \r
126 Unless the server requests a new PIN (see below), the contents of\r
127 the client's initial response SHALL be as follows:\r
128 \r
129 (1) An authorization identity. When this field is empty, it\r
130 defaults to the authentication identity. This field MAY be used\r
131 by system administrators or proxy servers to login with a\r
132 different user identity. This field MUST NOT be longer than 255\r
133 octets, SHALL be terminated by a NUL (0) octet, and MUST consist\r
134 of UTF-8-encoded [RFC2279] printable characters only (US-ASCII\r
135 [X3.4] is a subset of UTF-8).\r
136 \r
137 (2) An authentication identity. The identity whose passcode will\r
138 be used. If this field is empty, it is assumed to have been\r
139 transferred by other means (e.g. if the underlying protocol has\r
140 support for this, like [RFC2251]). This field MUST NOT be longer\r
141 than 255 octets, SHALL be terminated by a NUL (0) octet, and MUST\r
142 consist of UTF-8-encoded printable characters only.\r
143 \r
144 (3) A passcode. The one-time password that will be used to grant\r
145 access. This field MUST NOT be shorter than 4 octets, MUST NOT be\r
146 longer than 32 octets, SHALL be terminated by a NUL (0) octet, and\r
147 MUST consist of UTF-8-encoded printable characters only.\r
148 Passcodes usually consist of 4-8 digits.\r
149 \r
150 The ABNF [RFC2234] form of this message is as follows:\r
151 \r
152 credential-pdu = authorization-id authentication-id passcode [pin]\r
153 \r
154 authorization-id = 0*255VUTF8 %x00\r
155 \r
156 authentication-id = 0*255VUTF8 %x00\r
157 \r
158 passcode = 4*32VUTF8 %x00\r
159 \r
160 pin ::= 4*32VUTF8 %x00\r
161 \r
162 VUTF8 = <Visible (printable) UTF8-encoded characters>\r
163 \r
164 Regarding the <pin> rule, see d) below.\r
165 \r
166 \r
167 \r
168 \r
169 \r
170 Nystrom Informational [Page 3]\r
172 RFC 2808 The SecurID(r) SASL Mechanism April 2000\r
173 \r
174 \r
175 c) The server verifies these credentials using its own information.\r
176 If the verification succeeds, the server sends back a response\r
177 indicating success to the client. After receiving this response,\r
178 the client is authenticated. Otherwise, the verification either\r
179 failed or the server needs an additional set of credentials from\r
180 the client in order to authenticate the user.\r
181 \r
182 d) If the server needs an additional set of credentials, it requests\r
183 them now. This request has the following format, described in ABNF\r
184 notation:\r
185 \r
186 server-request = passcode | pin\r
187 \r
188 passcode = "passcode" %x00\r
189 \r
190 pin = "pin" %x00 [suggested-pin]\r
191 \r
192 suggested-pin = 4*32VUTF8 %x00 ; Between 4 and 32 UTF-8 characters\r
193 \r
194 The 'passcode' choice will be sent when the server requests\r
195 another passcode. The 'pin' choice will be sent when the server\r
196 requests a new user PIN. The server will either send an empty\r
197 string or suggest a new user PIN in this message.\r
198 \r
199 e) The client generates a new set of credentials using local\r
200 information and depending on the server's request and sends them\r
201 to the server. Authentication now continues as in c) above.\r
202 \r
203 Note 1: Case d) above may occur e.g. when the clocks on which the\r
204 server and the client relies are not synchronized.\r
205 \r
206 Note 2: If the server requests a new user PIN, the client MUST\r
207 respond with a new user PIN (together with a passcode), encoded as a\r
208 UTF-8 string. If the server supplies the client with a suggested PIN,\r
209 the client accepts this by replying with the same PIN, but MAY\r
210 replace it with another one. The length of the PIN is application-\r
211 dependent as are any other requirements for the PIN, e.g. allowed\r
212 characters. If the server for some reason does not accept the\r
213 received PIN, the client MUST be prepared to receive either a message\r
214 indicating the failure of the authentication or a repeated request\r
215 for a new PIN. Mechanisms for transferring knowledge about PIN\r
216 requirements from the server to the client are outside the scope of\r
217 this memo. However, some information MAY be provided in error\r
218 messages transferred from the server to the client when applicable.\r
219 \r
220 \r
221 \r
222 \r
223 \r
224 \r
225 \r
226 Nystrom Informational [Page 4]\r
228 RFC 2808 The SecurID(r) SASL Mechanism April 2000\r
229 \r
230 \r
231 4. Examples\r
232 \r
233 4.1 IMAP4\r
234 \r
235 The following example shows the use of the SECURID SASL mechanism\r
236 with IMAP4. The example is only designed to illustrate the protocol\r
237 interaction but do provide valid encoding examples.\r
238 \r
239 The base64 encoding of the last client response, as well as the "+ "\r
240 preceding the response, is part of the IMAP4 profile, and not a part\r
241 of this specification itself.\r
242 \r
243 S: * OK IMAP4 server ready\r
244 C: A001 CAPABILITY\r
245 S: * CAPABILITY IMAP4 AUTH=CRAM-MD5 AUTH=SECURID\r
246 S: A001 OK done\r
247 C: A002 AUTHENTICATE SECURID\r
248 S: +\r
249 C: AG1hZ251cwAxMjM0NTY3OAA=\r
250 S: A002 OK Welcome, SECURID authenticated user: magnus\r
251 \r
252 4.2 LDAPv3\r
253 \r
254 The following examples show the use of the SECURID SASL mechanism\r
255 with LDAPv3. The examples are only designed to illustrate the\r
256 protocol interaction, but do provide valid encoding examples.\r
257 Usernames, passcodes and PINs are of course fictitious. For\r
258 readability, all messages are shown in the value-notation defined in\r
259 [X680]. <credential-pdu> values are shown hex-encoded in the\r
260 'credentials' field of LDAP's 'BindRequest' and <server-request>\r
261 values are shown hex-encoded in the 'serverSaslCreds' field of LDAP's\r
262 'BindResponse'.\r
263 \r
264 4.2.1 LDAPv3 Example 1\r
265 \r
266 Initial response message, successful authentication.\r
267 \r
268 C: { messageID 1,\r
269 protocolOp bindRequest :\r
270 { version 1,\r
271 name '434E3D4D41474E5553'H, -- "CN=MAGNUS"\r
272 authentication sasl :\r
273 { mechanism '53454355524944'H, -- "SECURID"\r
274 credentials '006d61676e757300313233343536373800'H\r
275 }\r
276 }\r
277 }\r
278 \r
279 \r
280 \r
281 \r
282 Nystrom Informational [Page 5]\r
284 RFC 2808 The SecurID(r) SASL Mechanism April 2000\r
285 \r
286 \r
287 S: { messageID 1,\r
288 protocolOp bindResponse :\r
289 { resultCode success,\r
290 matchedDN ''H,\r
291 errorMessage ''H,\r
292 }\r
293 }\r
294 \r
295 4.2.2 LDAPv3 Example 2\r
296 \r
297 Initial response message, server requires second passcode.\r
298 \r
299 C: {\r
300 messageID 1,\r
301 protocolOp bindRequest : {\r
302 version 1,\r
303 name '434E3D4D41474E5553'H, -- "CN=MAGNUS"\r
304 authentication sasl : {\r
305 mechanism '53454355524944'H, -- "SECURID"\r
306 credentials '006d61676e757300313233343536373800'H\r
307 }\r
308 }\r
309 }\r
310 \r
311 S: {\r
312 messageID 1,\r
313 protocolOp bindResponse : {\r
314 resultCode saslBindInProgress,\r
315 matchedDN ''H,\r
316 errorMessage ''H,\r
317 serverSaslCreds '70617373636f646500'H\r
318 }\r
319 }\r
320 \r
321 C: {\r
322 messageID 1,\r
323 protocolOp bindRequest : {\r
324 version 1,\r
325 name '434E3D4D41474E5553'H, -- "CN=MAGNUS"\r
326 authentication sasl : {\r
327 mechanism '53454355524944'H, -- "SECURID"\r
328 credentials '006d61676e757300383736353433323100'H\r
329 }\r
330 }\r
331 }\r
332 \r
333 S: {\r
334 messageID 1,\r
335 \r
336 \r
337 \r
338 Nystrom Informational [Page 6]\r
340 RFC 2808 The SecurID(r) SASL Mechanism April 2000\r
341 \r
342 \r
343 protocolOp bindResponse : {\r
344 resultCode success,\r
345 matchedDN ''H,\r
346 errorMessage ''H,\r
347 }\r
348 }\r
349 \r
350 4.2.3 LDAPv3 Example 3\r
351 \r
352 Initial response message, server requires new PIN and passcode, and\r
353 supplies client with a suggested new PIN (which the client accepts).\r
354 \r
355 C: {\r
356 messageID 1,\r
357 protocolOp bindRequest : {\r
358 version 1,\r
359 name '434E3D4D41474E5553'H, -- "CN=MAGNUS"\r
360 authentication sasl : {\r
361 mechanism '53454355524944'H, -- "SECURID"\r
362 credentials '006d61676e757300313233343536373800'H\r
363 }\r
364 }\r
365 }\r
366 \r
367 S: {\r
368 messageID 1,\r
369 protocolOp bindResponse : {\r
370 resultCode saslBindInProgress,\r
371 matchedDN ''H,\r
372 errorMessage ''H,\r
373 serverSaslCreds '70696e006b616c6c6500'H\r
374 }\r
375 }\r
376 \r
377 C: {\r
378 messageID 1,\r
379 protocolOp bindRequest : {\r
380 version 1,\r
381 name '434E3D4D41474E5553'H, -- "CN=MAGNUS"\r
382 authentication sasl : {\r
383 mechanism '53454355524944'H, -- "SECURID"\r
384 credentials '006d61676e7573003837343434363734006b616c6c6500'H\r
385 }\r
386 }\r
387 }\r
388 \r
389 S: {\r
390 messageID 1,\r
391 \r
392 \r
393 \r
394 Nystrom Informational [Page 7]\r
396 RFC 2808 The SecurID(r) SASL Mechanism April 2000\r
397 \r
398 \r
399 protocolOp bindResponse : {\r
400 resultCode success,\r
401 matchedDN ''H,\r
402 errorMessage ''H,\r
403 }\r
404 }\r
405 \r
406 5. Security Considerations\r
407 \r
408 This mechanism only provides protection against passive eavesdropping\r
409 attacks. It does not provide session privacy, server authentication\r
410 or protection from active attacks. In particular, man-in-the-middle\r
411 attacks, were an attacker acts as an application server in order to\r
412 acquire a valid passcode are possible.\r
413 \r
414 In order to protect against such attacks, the client SHOULD make sure\r
415 that the server is properly authenticated. When user PINs are\r
416 transmitted, user authentication SHOULD take place on a server-\r
417 authenticated and confidentiality-protected connection.\r
418 \r
419 Server implementations MUST protect against replay attacks, since an\r
420 attacker could otherwise gain access by replaying a previous, valid\r
421 request. Clients MUST also protect against replay of PIN-change\r
422 messages.\r
423 \r
424 5.1 The Race Attack\r
425 \r
426 It is possible for an attacker to listen to most of a passcode, guess\r
427 the remainder, and then race the legitimate user to complete the\r
428 authentication. As for OTP [RFC2289], conforming server\r
429 implementations MUST protect against this race condition. One defense\r
430 against this attack is outlined below and borrowed from [RFC2289];\r
431 implementations MAY use this approach or MAY select an alternative\r
432 defense.\r
433 \r
434 One possible defense is to prevent a user from starting multiple\r
435 simultaneous authentication sessions. This means that once the\r
436 legitimate user has initiated authentication, an attacker would be\r
437 blocked until the first authentication process has completed. In\r
438 this approach, a timeout is necessary to thwart a denial of service\r
439 attack.\r
440 \r
441 6. IANA Considerations\r
442 \r
443 By registering the SecurID protocol as a SASL mechanism, implementers\r
444 will have a well-defined way of adding this authentication mechanism\r
445 to their product. Here is the registration template for the SECURID\r
446 SASL mechanism:\r
447 \r
448 \r
449 \r
450 Nystrom Informational [Page 8]\r
452 RFC 2808 The SecurID(r) SASL Mechanism April 2000\r
453 \r
454 \r
455 SASL mechanism name: SECURID\r
456 Security Considerations: See corresponding section of this memo\r
457 Published specification: This memo\r
458 Person & email address to\r
459 contact for further\r
460 information: See author's address section below\r
461 Intended usage: COMMON\r
462 Author/Change controller: See author's address section below\r
463 \r
464 7. Intellectual Property Considerations\r
465 \r
466 RSA Security Inc. does not make any claims on the general\r
467 constructions described in this memo, although underlying techniques\r
468 may be covered. Among the underlying techniques, the SecurID\r
469 technology is covered by a number of US patents (and foreign\r
470 counterparts), in particular US patent no. 4,885,778, no. 5,097,505,\r
471 no. 5,168,520, and 5,657,388.\r
472 \r
473 SecurID is a registered trademark, and PASSCODE is a trademark, of\r
474 RSA Security Inc.\r
475 \r
476 8. References\r
477 \r
478 [RFC1734] Myers, J., "POP3 AUTHentication command", RFC 1734,\r
479 December 1994.\r
480 \r
481 [RFC2026] Bradner, S., "The Internet Standards Process -- Revision\r
482 3", BCP 9, RFC 2026, October 1996.\r
483 \r
484 [RFC2060] Crispin, M., "Internet Message Access Protocol - Version\r
485 4rev1", RFC 2060, December 1996.\r
486 \r
487 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate\r
488 Requirement Levels", BCP 14, RFC 2119, March 1997.\r
489 \r
490 [RFC2222] Myers, J., "Simple Authentication and Security Layer", RFC\r
491 2222, October 1997.\r
492 \r
493 [RFC2234] Crocker, D. and P. Overell, "Augmented BNF for Syntax\r
494 Specifications: ABNF", RFC 2234, November 1997.\r
495 \r
496 [RFC2244] Newman, C. and J. Myers, "ACAP -- Application Configuration\r
497 Access Protocol", RFC 2244, November 1997.\r
498 \r
499 [RFC2251] Wahl, M., Howes, T. and S. Kille, "Lightweight Directory\r
500 Access Protocol (v3)", RFC 2251, December 1997.\r
501 \r
502 \r
503 \r
504 \r
505 \r
506 Nystrom Informational [Page 9]\r
508 RFC 2808 The SecurID(r) SASL Mechanism April 2000\r
509 \r
510 \r
511 [RFC2279] Yergeau, F., "UTF-8, a transformation format of ISO 10646",\r
512 RFC 2279, January 1998.\r
513 \r
514 [RFC2289] Haller, N., Metz, C., Nesser, P. and M. Straw, "A One-Time\r
515 Password System", RFC 2289, February 1998.\r
516 \r
517 [X3.4] ANSI, "ANSI X3.4: Information Systems - Coded Character\r
518 Sets - 7-Bit American National Standard Code for\r
519 Information Interchange (7-Bit ASCII)," American National\r
520 Standards Institute.\r
521 \r
522 [X680] ITU-T, "Information Technology - Abstract Syntax Notation\r
523 One (ASN.1): Specification of Basic Notation,"\r
524 International Telecommunication Union, 1997.\r
525 \r
526 9. Acknowledgements\r
527 \r
528 The author gratefully acknowledges the contributions of various\r
529 reviewers of this memo, in particular the ones from John Myers. They\r
530 have significantly clarified and improved the utility of this\r
531 specification.\r
532 \r
533 10. Author's Address\r
534 \r
535 Magnus Nystrom\r
536 RSA Laboratories\r
537 Box 10704\r
538 121 29 Stockholm\r
539 Sweden\r
540 \r
541 Phone: +46 8 725 0900\r
542 EMail: magnus@rsasecurity.com\r
543 \r
544 \r
545 \r
546 \r
547 \r
548 \r
549 \r
550 \r
551 \r
552 \r
553 \r
554 \r
555 \r
556 \r
557 \r
558 \r
559 \r
560 \r
561 \r
562 Nystrom Informational [Page 10]\r
564 RFC 2808 The SecurID(r) SASL Mechanism April 2000\r
565 \r
566 \r
567 11. Full Copyright Statement\r
568 \r
569 Copyright (C) The Internet Society (2000). All Rights Reserved.\r
570 \r
571 This document and translations of it may be copied and furnished to\r
572 others, and derivative works that comment on or otherwise explain it\r
573 or assist in its implementation may be prepared, copied, published\r
574 and distributed, in whole or in part, without restriction of any\r
575 kind, provided that the above copyright notice and this paragraph are\r
576 included on all such copies and derivative works. However, this\r
577 document itself may not be modified in any way, such as by removing\r
578 the copyright notice or references to the Internet Society or other\r
579 Internet organizations, except as needed for the purpose of\r
580 developing Internet standards in which case the procedures for\r
581 copyrights defined in the Internet Standards process must be\r
582 followed, or as required to translate it into languages other than\r
583 English.\r
584 \r
585 The limited permissions granted above are perpetual and will not be\r
586 revoked by the Internet Society or its successors or assigns.\r
587 \r
588 This document and the information contained herein is provided on an\r
589 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING\r
590 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING\r
591 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION\r
592 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF\r
593 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.\r
594 \r
595 Acknowledgement\r
596 \r
597 Funding for the RFC Editor function is currently provided by the\r
598 Internet Society.\r
599 \r
600 \r
601 \r
602 \r
603 \r
604 \r
605 \r
606 \r
607 \r
608 \r
609 \r
610 \r
611 \r
612 \r
613 \r
614 \r
615 \r
616 \r
617 \r
618 Nystrom Informational [Page 11]\r