doc/rfc2444.txt

   1
   2
   3
   4
   5
   6
   7 Network Working Group                                          C. Newman
   8 Request for Comments: 2444                                      Innosoft
   9 Updates: 2222                                               October 1998
  10 Category: Standards Track
  11
  12
  13                   The One-Time-Password SASL Mechanism
  14
  15 Status of this Memo
  16
  17    This document specifies an Internet standards track protocol for the
  18    Internet community, and requests discussion and suggestions for
  19    improvements.  Please refer to the current edition of the "Internet
  20    Official Protocol Standards" (STD 1) for the standardization state
  21    and status of this protocol.  Distribution of this memo is unlimited.
  22
  23 Copyright Notice
  24
  25    Copyright (C) The Internet Society (1998).  All Rights Reserved.
  26
  27 Abstract
  28
  29    OTP [OTP] provides a useful authentication mechanism for situations
  30    where there is limited client or server trust.  Currently, OTP is
  31    added to protocols in an ad-hoc fashion with heuristic parsing.  This
  32    specification defines an OTP SASL [SASL] mechanism so it can be
  33    easily and formally integrated into many application protocols.
  34
  35 1. How to Read This Document
  36
  37    The key words "MUST", "MUST NOT", "REQUIRED", "SHOULD", "SHOULD NOT",
  38    "RECOMMENDED" and "MAY" in this document are to be interpreted as
  39    defined in "Key words for use in RFCs to Indicate Requirement Levels"
  40    [KEYWORDS].
  41
  42    This memo assumes the reader is familiar with OTP [OTP], OTP extended
  43    responses [OTP-EXT] and SASL [SASL].
  44
  45 2. Intended Use
  46
  47    The OTP SASL mechanism replaces the SKEY SASL mechanism [SASL].  OTP
  48    is a good choice for usage scenarios where the client is untrusted
  49    (e.g., a kiosk client), as a one-time password will only give the
  50    client a single opportunity to act on behalf of the user.  OTP is
  51    also a good choice for situations where interactive logins are
  52    permitted to the server, as a compromised OTP authentication database
  53    is only subject to dictionary attacks, unlike authentication
  54    databases for other simple mechanisms such as CRAM-MD5 [CRAM-MD5].
  55
  56
  57
  58 Newman                      Standards Track                     [Page 1]
  59 \f
  60 RFC 2444                   OTP SASL Mechanism               October 1998
  61
  62
  63    It is important to note that each use of the OTP mechanism causes the
  64    authentication database entry for a user to be updated.
  65
  66    This SASL mechanism provides a formal way to integrate OTP into
  67    SASL-enabled protocols including IMAP [IMAP4], ACAP [ACAP], POP3
  68    [POP-AUTH] and LDAPv3 [LDAPv3].
  69
  70 3. Profiling OTP for SASL
  71
  72    OTP [OTP] and OTP extended responses [OTP-EXT] offer a number of
  73    options.  However, for authentication to succeed, the client and
  74    server need compatible option sets.  This specification defines a
  75    single SASL mechanism: OTP.  The following rules apply to this
  76    mechanism:
  77
  78    o   The extended response syntax MUST be used.
  79
  80    o   Servers MUST support the following four OTP extended responses:
  81        "hex", "word", "init-hex" and "init-word".  Servers MUST support
  82        the "word" and "init-word" responses for the standard dictionary
  83        and SHOULD support alternate dictionaries.  Servers MUST NOT
  84        require use of any additional OTP extensions or options.
  85
  86    o   Clients SHOULD support display of the OTP challenge to the user
  87        and entry of an OTP in multi-word format.  Clients MAY also
  88        support direct entry of the pass phrase and compute the "hex" or
  89        "word" response.
  90
  91    o   Clients MUST indicate when authentication fails due to the
  92        sequence number getting too low and SHOULD offer the user the
  93        option to reset the sequence using the "init-hex" or "init-word"
  94        response.
  95
  96    Support for the MD5 algorithm is REQUIRED, and support for the SHA1
  97    algorithm is RECOMMENDED.
  98
  99 4. OTP Authentication Mechanism
 100
 101    The mechanism does not provide any security layer.
 102
 103    The client begins by sending a message to the server containing the
 104    following two pieces of information.
 105
 106    (1) An authorization identity.  When the empty string is used, this
 107    defaults to the authentication identity.  This is used by system
 108    administrators or proxy servers to login with a different user
 109    identity.  This field may be up to 255 octets and is terminated by a
 110    NUL (0) octet.  US-ASCII printable characters are preferred, although
 111
 112
 113
 114 Newman                      Standards Track                     [Page 2]
 115 \f
 116 RFC 2444                   OTP SASL Mechanism               October 1998
 117
 118
 119    UTF-8 [UTF-8] printable characters are permitted to support
 120    international names.  Use of character sets other than US-ASCII and
 121    UTF-8 is forbidden.
 122
 123    (2) An authentication identity.  The identity whose pass phrase will
 124    be used.  This field may be up to 255 octets.  US-ASCII printable
 125    characters are preferred, although UTF-8 [UTF-8] printable characters
 126    are permitted to support international names.  Use of character sets
 127    other than US-ASCII and UTF-8 is forbidden.
 128
 129    The server responds by sending a message containing the OTP challenge
 130    as described in OTP [OTP] and OTP extended responses [OTP-EXT].
 131
 132    If a client sees an unknown hash algorithm name it will not be able
 133    to process a pass phrase input by the user.  In this situation the
 134    client MAY prompt for the six-word format, issue the cancel sequence
 135    as specified by the SASL profile for the protocol in use and try a
 136    different SASL mechanism, or close the connection and refuse to
 137    authenticate.  As a result of this behavior, a server is restricted
 138    to one OTP hash algorithm per user.
 139
 140    On success, the client generates an extended response in the "hex",
 141    "word", "init-hex" or "init-word" format.  The client is not required
 142    to terminate the response with a space or a newline and SHOULD NOT
 143    include unnecessary whitespace.
 144
 145    Servers MUST tolerate input of arbitrary length, but MAY fail the
 146    authentication if the length of client input exceeds reasonable size.
 147
 148 5. Examples
 149
 150    In these example, "C:" represents lines sent from the client to the
 151    server and "S:" represents lines sent from the server to the client.
 152    The user name is "tim" and no authorization identity is provided.
 153    The "<NUL>" below represents an ASCII NUL octet.
 154
 155    The following is an example of the OTP mechanism using the ACAP
 156    [ACAP] profile of SASL.  The pass phrase used in this example is:
 157              This is a test.
 158
 159           C: a001 AUTHENTICATE "OTP" {4}
 160           C: <NUL>tim
 161           S: + "otp-md5 499 ke1234 ext"
 162           C: "hex:5bf075d9959d036f"
 163           S: a001 OK "AUTHENTICATE completed"
 164
 165
 166
 167
 168
 169
 170 Newman                      Standards Track                     [Page 3]
 171 \f
 172 RFC 2444                   OTP SASL Mechanism               October 1998
 173
 174
 175         Here is the same example using the six-words response:
 176
 177           C: a001 AUTHENTICATE "OTP" {4}
 178           C: <NUL>tim
 179           S: + "otp-md5 499 ke1234 ext"
 180           C: "word:BOND FOGY DRAB NE RISE MART"
 181           S: a001 OK "AUTHENTICATE completed"
 182
 183         Here is the same example using the OTP-SHA1 mechanism:
 184
 185           C: a001 AUTHENTICATE "OTP" {4}
 186           C: <NUL>tim
 187           S: + "otp-sha1 499 ke1234 ext"
 188           C: "hex:c90fc02cc488df5e"
 189           S: a001 OK "AUTHENTICATE completed"
 190
 191         Here is the same example with the init-hex extended response
 192
 193           C: a001 AUTHENTICATE "OTP" {4}
 194           C: <NUL>tim
 195           S: + "otp-md5 499 ke1234 ext"
 196           C: "init-hex:5bf075d9959d036f:md5 499 ke1235:3712dcb4aa5316c1"
 197           S: a001 OK "OTP sequence reset, authentication complete"
 198
 199      The following is an example of the OTP mechanism using the IMAP
 200      [IMAP4] profile of SASL.  The pass phrase used in this example is:
 201           this is a test
 202
 203        C: a001 AUTHENTICATE OTP
 204        S: +
 205        C: AHRpbQ==
 206        S: + b3RwLW1kNSAxMjMga2UxMjM0IGV4dA==
 207        C: aGV4OjExZDRjMTQ3ZTIyN2MxZjE=
 208        S: a001 OK AUTHENTICATE completed
 209
 210    Note that the lack of an initial client response and the base64
 211    encoding are characteristics of the IMAP profile of SASL.  The server
 212    challenge is "otp-md5 123 ke1234 ext" and the client response is
 213    "hex:11d4c147e227c1f1".
 214
 215 6. Security Considerations
 216
 217    This specification introduces no security considerations beyond those
 218    those described in SASL [SASL], OTP [OTP] and OTP extended responses
 219    [OTP-EXT].  A brief summary of these considerations follows:
 220
 221    This mechanism does not provide session privacy, server
 222    authentication or protection from active attacks.
 223
 224
 225
 226 Newman                      Standards Track                     [Page 4]
 227 \f
 228 RFC 2444                   OTP SASL Mechanism               October 1998
 229
 230
 231    This mechanism is subject to passive dictionary attacks.  The
 232    severity of this attack can be reduced by choosing pass phrases well.
 233
 234    The server authentication database necessary for use with OTP need
 235    not be plaintext-equivalent.
 236
 237    Server implementations MUST protect against the race attack [OTP].
 238
 239 7. Multinational Considerations
 240
 241    As remote access is a crucial service, users are encouraged to
 242    restrict user names and pass phrases to the US-ASCII character set.
 243    However, if characters outside the US-ASCII chracter set are used in
 244    user names and pass phrases, then they are interpreted according to
 245    UTF-8 [UTF-8].
 246
 247    Server support for alternate dictionaries is strongly RECOMMENDED to
 248    permit use of the six-word format with non-English words.
 249
 250 8. IANA Considerations
 251
 252    Here is the registration template for the OTP SASL mechanism:
 253
 254    SASL mechanism name: OTP
 255    Security Considerations: See section 6 of this memo
 256    Published specification: this memo
 257    Person & email address to contact for futher information:
 258      see author's address section below
 259    Intended usage: COMMON
 260    Author/Change controller: see author's address section below
 261
 262    This memo also amends the SKEY SASL mechanism registration [SASL] by
 263    changing its intended usage to OBSOLETE.
 264
 265 9. References
 266
 267    [ACAP]     Newman, C. and J. Myers, "ACAP -- Application
 268               Configuration Access Protocol", RFC 2244, November 1997.
 269
 270    [CRAM-MD5] Klensin, J., Catoe, R. and P. Krumviede, "IMAP/POP
 271               AUTHorize Extension for Simple Challenge/Response", RFC
 272               2195, September 1997.
 273
 274    [IMAP4]    Crispin, M., "Internet Message Access Protocol - Version
 275               4rev1", RFC 2060, December 1996.
 276
 277    [KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate
 278               Requirement Levels", BCP 14, RFC 2119, March 1997.
 279
 280
 281
 282 Newman                      Standards Track                     [Page 5]
 283 \f
 284 RFC 2444                   OTP SASL Mechanism               October 1998
 285
 286
 287    [LDAPv3]   Wahl, M., Howes, T. and S. Kille, "Lightweight Directory
 288               Access Protocol (v3)", RFC 2251, December 1997.
 289
 290    [MD5]      Rivest, R., "The MD5 Message Digest Algorithm", RFC 1321,
 291               April 1992.
 292
 293    [OTP]      Haller, N., Metz, C., Nesser, P. and M. Straw, "A One-Time
 294               Password System", RFC 2289, February 1998.
 295
 296    [OTP-EXT]  Metz, C., "OTP Extended Responses", RFC 2243, November
 297               1997.
 298
 299    [POP-AUTH] Myers, J., "POP3 AUTHentication command", RFC 1734,
 300               December 1994.
 301
 302    [SASL]     Myers, J., "Simple Authentication and Security Layer
 303               (SASL)", RFC 2222, October 1997.
 304
 305    [UTF-8]    Yergeau, F., "UTF-8, a transformation format of ISO
 306               10646", RFC 2279, January 1998.
 307
 308 10. Author's Address
 309
 310    Chris Newman
 311    Innosoft International, Inc.
 312    1050 Lakes Drive
 313    West Covina, CA 91790 USA
 314
 315    EMail: chris.newman@innosoft.com
 316
 317
 318
 319
 320
 321
 322
 323
 324
 325
 326
 327
 328
 329
 330
 331
 332
 333
 334
 335
 336
 337
 338 Newman                      Standards Track                     [Page 6]
 339 \f
 340 RFC 2444                   OTP SASL Mechanism               October 1998
 341
 342
 343 11.  Full Copyright Statement
 344
 345    Copyright (C) The Internet Society (1998).  All Rights Reserved.
 346
 347    This document and translations of it may be copied and furnished to
 348    others, and derivative works that comment on or otherwise explain it
 349    or assist in its implementation may be prepared, copied, published
 350    and distributed, in whole or in part, without restriction of any
 351    kind, provided that the above copyright notice and this paragraph are
 352    included on all such copies and derivative works.  However, this
 353    document itself may not be modified in any way, such as by removing
 354    the copyright notice or references to the Internet Society or other
 355    Internet organizations, except as needed for the purpose of
 356    developing Internet standards in which case the procedures for
 357    copyrights defined in the Internet Standards process must be
 358    followed, or as required to translate it into languages other than
 359    English.
 360
 361    The limited permissions granted above are perpetual and will not be
 362    revoked by the Internet Society or its successors or assigns.
 363
 364    This document and the information contained herein is provided on an
 365    "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
 366    TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
 367    BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
 368    HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
 369    MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
 370
 371
 372
 373
 374
 375
 376
 377
 378
 379
 380
 381
 382
 383
 384
 385
 386
 387
 388
 389
 390
 391
 392
 393
 394 Newman                      Standards Track                     [Page 7]
 395 \f