doc/rfc2243.txt

   1
   2
   3
   4
   5
   6
   7 Network Working Group                                           C. Metz
   8 Request for Comments: 2243                                The Inner Net
   9 Category: Standards Track                                 November 1997
  10
  11
  12
  13
  14                          OTP Extended Responses
  15
  16
  17 Status of this Memo
  18
  19    This document specifies an Internet standards track protocol for the
  20    Internet community, and requests discussion and suggestions for
  21    improvements.  Please refer to the current edition of the "Internet
  22    Official Protocol Standards" (STD 1) for the standardization state
  23    and status of this protocol.  Distribution of this memo is unlimited.
  24
  25 Copyright Notice
  26
  27    Copyright (C) The Internet Society (1997).  All Rights Reserved.
  28
  29 Abstract
  30
  31    This document provides a specification for a type of response to an
  32    OTP [RFC 1938] challenge that carries explicit indication of the
  33    response's encoding. Codings for the two mandatory OTP data formats
  34    using this new type of response are presented.
  35
  36    This document also provides a specification for a response that
  37    allows an OTP generator to request that a server re-initialize a
  38    sequence and change parameters such as the secret pass phrase.
  39
  40 1. Conventions, Terms, and Notation
  41
  42    This document specifies the data formats and software behaviors
  43    needed to use OTP extended responses. The data formats are described
  44    three ways: using an ad-hoc UNIX manual page style syntax, using
  45    augmented BNF described in sections two and three of RFC 822, and by
  46    examples. Should there be any conflict between these descriptions,
  47    the augmented BNF takes precedence. The software behaviors are
  48    described in words, and specific behavior compliance requirements are
  49    itemized using the requirements terminology (specifically, the words
  50    MUST, SHOULD, and MAY) defined in RFC 2119.
  51
  52
  53
  54
  55
  56
  57
  58 Metz                        Standards Track                     [Page 1]
  59 \f
  60 RFC 2243                 OTP Extended Responses            November 1997
  61
  62
  63 2. Extended Challenges and Extended Responses
  64
  65    This document builds on the protocol and terminology specified in RFC
  66    1938 and assumes that you have already read this document and
  67    understand its contents.
  68
  69    An extended challenge is a single line of printable text terminated
  70    by either a new line sequence appropriate for the context of its use
  71    (e.g., ASCII CR followed by ASCII LF) or a whitespace character. It
  72    contains a standard OTP challenge, a whitespace character, and a list
  73    that generators use to determine which extended responses are
  74    supported by a server.
  75
  76    An extended response is a single line of printable text terminated by
  77    a new line sequence appropriate for the context of its use. It
  78    contains two or more tokens that are separated with a single colon
  79    (':') character. The first token contains a type specifier that
  80    indicates the format of the rest of the response. The tokens that
  81    follow are argument data for the OTP extended response. At least one
  82    token of data MUST be present.
  83
  84 2.1. Syntax
  85
  86    In UNIX manual page like syntax, the general form of an extended
  87    challenge could be described as:
  88
  89       <standard OTP challenge> ext[,<extension set id>[, ...]]
  90
  91    And the general form of an extended response could be described as:
  92
  93       <type-specifier>:<arg1>[:<arg2>[:...]]
  94
  95    In augmented BNF syntax, the syntax of the general form of an
  96    extended challenge and an extended response is:
  97
  98    extended-challenge = otp-challenge 1*LWSP-char capability-list
  99                         (NL / *LWSP-char)
 100    otp-challenge     = <a standard OTP challenge>
 101    capability-list   = "ext" *("," extension-set-id)
 102    extension-set-id  = *<any CHAR except LWSP, CTLs, or ",">
 103    extended-response = type 1*(":" argument) NL
 104    type              = token
 105    argument          = token
 106    token             = 1*<any CHAR except ":" and CTLs>
 107    NL                = <new line sequence appropriate for the context
 108                         in which OTP is being used>
 109
 110
 111
 112
 113
 114 Metz                        Standards Track                     [Page 2]
 115 \f
 116 RFC 2243                 OTP Extended Responses            November 1997
 117
 118
 119    An example of an extended challenge indicating support for OTP
 120    extended responses and for a mythical response set "foo" is:
 121
 122       otp-md5 123 mi1234 ext,foo
 123
 124    An example of an extended response using a mythical type named "foo"
 125    is:
 126
 127       foo:some data:some more data:12345
 128
 129 2.2. Requirements
 130
 131    A server compliant with this specification:
 132
 133       1. MUST be able to receive and parse the general form of an
 134          extended response
 135       2. MUST be able to receive, parse, and correctly process all
 136          extended responses specified in this document
 137       3. MUST process the type field in a case-insensitive manner
 138       4. MUST reject any authentication attempt using an extended
 139          response if it does not support that type of response
 140       5. SHOULD provide an appropriate indication to the generator
 141          if the response was rejected because of (4)
 142       6. MUST limit the length of the input reasonably
 143       7. MUST accept otherwise arbitrary amounts of whitespace
 144          wherever a response allows it
 145       8. MUST be able to receive and correctly process standard OTP
 146          responses
 147
 148    A generator compliant with this specification:
 149
 150       1. MUST be able to generate standard OTP responses
 151       2. MUST use standard responses unless an extended challenge
 152          has been received for the particular server AND seed
 153       3. MUST generate the type field in lower case
 154       4. MUST NOT send a response type for which the server has not
 155          indicated support through an extended challenge
 156
 157    Extension set identifiers and extension type identifiers named with
 158    the prefix "x-" are reserved for private use among mutually
 159    consenting implementations. Implementations that do not recognise a
 160    particular "x-" extension MUST ignore that extension. This means that
 161    all "x-" extensions are likely to be non-interoperable with other
 162    extensions. Careful consideration should be given to the possibility
 163    of a server interacting with with a generator implementation which,
 164    although it recognizes a given "x-" extension, uses it for a
 165    different purpose. All of the remaining extension namespace is
 166    reserved to IANA, which will only officially assign the extension
 167
 168
 169
 170 Metz                        Standards Track                     [Page 3]
 171 \f
 172 RFC 2243                 OTP Extended Responses            November 1997
 173
 174
 175    into this namespace after the IESG approves of such an assignment.
 176    During the lifetime of the OTP WG, it is recommended that the IESG
 177    consult with the OTP WG prior to approving such an assignment.
 178
 179 3. The "hex" and "word" Responses
 180
 181    There exists a very rare case in which a standard OTP response could
 182    be a valid coding in both the hexadecimal and six-word formats. An
 183    example of this is the response "ABE ACE ADA ADD BAD A."  The
 184    solution to this problem mandated by the OTP specification is that
 185    compliant servers MUST attempt to parse and verify a standard
 186    response in both hexadecimal and six-word formats and must consider
 187    the authentication successful if either succeeds.
 188
 189    This problem can be solved easily using extended responses. The "hex"
 190    response and the "word" response are two response types that encode
 191    an OTP in an extended response that explicitly describes the
 192    encoding. These responses start with a type label of "hex" for a
 193    hexadecimal OTP and "word" for a six-word coded OTP. These responses
 194    contain one argument field that contains a standard OTP response
 195    coded in the indicated format.
 196
 197 3.1. Syntax
 198
 199    In UNIX manual page like syntax, the format of these responses could
 200    be described as:
 201
 202       hex:<hexadecimal number>
 203       word:<six dictionary words>
 204
 205    In augmented BNF syntax and with the definitions already provided,
 206    the syntax of these responses is:
 207
 208       hex-response  = "hex:" hex-64bit NL
 209       hex-64bit     = 16(hex-char *LWSP-char)
 210       hex-char      = ("A" / "B" / "C" / "D" / "E" / "F" /
 211                        "a" / "b" / "c" / "d" / "e" / "f" /
 212                        "0" / "1" / "2" / "3" / "4" / "5" /
 213                        "6" / "7" / "8" / "9")
 214
 215       word-response = "word:" word-64bit NL
 216       word-64bit    = 6(otp-word 1*LWSP-char)
 217       otp-word      = <any valid word in the standard OTP coding
 218                       dictionary>
 219
 220
 221
 222
 223
 224
 225
 226 Metz                        Standards Track                     [Page 4]
 227 \f
 228 RFC 2243                 OTP Extended Responses            November 1997
 229
 230
 231    Examples of these responses are:
 232
 233       hex:8720 33d4 6202 9172
 234       word:VAST SAUL TAKE SODA SUCH BOLT
 235
 236 3.2. Requirements
 237
 238    A server compliant with this specification:
 239
 240       1. MUST process all arguments in a case-insensitive manner
 241
 242    A generator compliant with this specification:
 243
 244       1. SHOULD generate otp-word tokens in upper case with single
 245          spaces separating them
 246       2. SHOULD generate hexadecimal numbers using only lower case
 247          for letters
 248
 249 4. The "init-hex" and "init-word" Responses
 250
 251    The OTP specification requires that implementations provide a means
 252    for a client to re-initialize or change its OTP information with a
 253    server but does not require any specific protocol for doing it.
 254    Implementations that support the OTP extended responses described in
 255    this document MUST support the response with the "init-hex" and
 256    "init-word" type specifiers, which provide a standard way for a
 257    client to re-initialize its OTP information with a server. This
 258    response is intended to be used only by automated clients. Because of
 259    this, the recommended form of this response uses the hexadecimal
 260    encoding for binary data. It is possible for a user to type an "init-
 261    hex" or "init-word" response.
 262
 263 4.1. Syntax
 264
 265    In UNIX manual page like syntax, the format of these responses could
 266    be described as:
 267
 268       init-hex:<current-OTP>:<new-params>:<new-OTP>
 269       init-word:<current-OTP>:<new-params>:<new-OTP>
 270
 271    In augmented BNF syntax and with the definitions already provided,
 272    the syntax of the "init-hex" response is:
 273
 274    init-hex-response = "init-hex:" current-OTP ":" new-params ":"
 275                         new-OTP NL
 276
 277    current-OTP     = hex-64bit
 278    new-OTP         = hex-64bit
 279
 280
 281
 282 Metz                        Standards Track                     [Page 5]
 283 \f
 284 RFC 2243                 OTP Extended Responses            November 1997
 285
 286
 287    new-params      = algorithm SPACE sequence-number SPACE seed
 288    algorithm       = "md4" / "md5" / "sha1"
 289    sequence-number = 4*3DIGIT
 290    seed            = 16*1(ALPHA / DIGIT)
 291
 292    In augmented BNF syntax and with the definitions already provided,
 293    the syntax of the "init-word" response is:
 294
 295    init-word-response = "init-word:" current-OTP ":" new-params ":"
 296                         new-OTP NL
 297
 298    current-OTP     = word-64bit
 299    new-OTP         = word-64bit
 300
 301    new-params      = algorithm SPACE sequence-number SPACE seed
 302    algorithm       = "md4" / "md5" / "sha1"
 303    sequence-number = 4*3DIGIT
 304    seed            = 16*1(ALPHA / DIGIT)
 305
 306    Note that all appropriate fields for the "init-hex" response MUST be
 307    hexadecimally coded and that all appropriate fields for the "init-
 308    word" response MUST be six-word coded.
 309
 310    Examples of these responses are:
 311
 312    init-hex:f6bd 6b33 89b8 7203:md5 499 ke6118:23d1 b253 5ae0 2b7e
 313    init-hex:c9b2 12bb 6425 5a0f:md5 499 ke0986:fd17 cef1 b4df 093e
 314
 315    init-word:MOOD SOFT POP COMB BOLO LIFE:md5 499 ke1235:
 316    ARTY WEAR TAD RUG HALO GIVE
 317    init-word:END KERN BALM NICK EROS WAVY:md5 499 ke1235:
 318    BABY FAIN OILY NIL TIDY DADE
 319
 320    (Note that all of these responses are one line. Due to their length,
 321    they had to be split into multiple lines in order to be included
 322    here. These responses MUST NOT span more than one line in actual use)
 323
 324 4.2. Description of Fields
 325
 326    The current-OTP field contains the (RFC 1938) response to the OTP
 327    challenge.  The new-params field contains the parameters for the
 328    client's new requested challenge and the new-OTP field contains a
 329    response to that challenge. If the re-initialization is successful, a
 330    server MUST store the new OTP in its database as the last successful
 331    OTP received and the sequence number in the next challenge presented
 332    by the server MUST be one less than the sequence number specified in
 333    the new-params field.
 334
 335
 336
 337
 338 Metz                        Standards Track                     [Page 6]
 339 \f
 340 RFC 2243                 OTP Extended Responses            November 1997
 341
 342
 343    The new-params field is hashed as a string the same way that a seed
 344    or secret pass phrase would be. All other field values are hashed in
 345    their uncoded binary forms, in network byte order and without any
 346    padding.
 347
 348 4.3. Requirements
 349
 350    A server compliant with this specification:
 351
 352       1. SHOULD NOT allow a user to use the same value for their
 353          seed and secret pass phrase.
 354       2. MUST disable all OTP access to any principal whose
 355          sequence number would be less than one
 356       3. MUST decrement the sequence number if a reinitialization
 357          response includes a valid current-OTP, but the server is
 358          unable to successfully process the new-params or new-OTP for
 359          any reason.
 360
 361    A generator compliant with this specification:
 362
 363       1. SHOULD NOT allow a user to use the same value for their
 364          seed and secret pass phrase
 365       2. MUST take specific steps to prevent infinite loops of
 366          re-initialization attempts in case of failure
 367       3. SHOULD provide the user with some indication that the
 368          re-initialization is taking place
 369       4. SHOULD NOT do a re-initialization without the user's
 370          permission, either for that specific instance or as a
 371          configuration option
 372       5. SHOULD NOT retry a failed re-initialization without a user's
 373          permission
 374       6. SHOULD warn the user if the sequence number falls below ten
 375       7. MUST refuse to generate OTPs with a sequence number below one
 376
 377 5. Security Considerations
 378
 379    All of the security considerations for the OTP system also apply to
 380    the OTP system with extended responses.
 381
 382    These extended responses, like OTP itself, do not protect the user
 383    against active attacks. The IPsec Authentication Header (RFC-1826)
 384    (or another technique with at least as much strength as IPsec AH)
 385    SHOULD be used to protect against such attacks.
 386
 387    The consequences of a successful active attack on the re-
 388    initialization response may be more severe than simply hijacking a
 389    single session. An attacker could substitute his own response for
 390
 391
 392
 393
 394 Metz                        Standards Track                     [Page 7]
 395 \f
 396 RFC 2243                 OTP Extended Responses            November 1997
 397
 398
 399    that of a legitimate user. The attacker may then be able to use the
 400    OTP system to authenticate himself as the user at will (at least
 401    until detected).
 402
 403    Failure to implement server requirement 3 in section 4.3 opens an
 404    implementation to an attack based on replay of the current-OTP part
 405    of the response.
 406
 407 6. Acknowledgments
 408
 409    Like RFC 1938, the protocol described in this document was created by
 410    contributors in the IETF OTP working group. Specific contributions
 411    were made by Neil Haller, who provided input on the overall design
 412    requirements of a re-initialization protocol, Denis Pinkas, who
 413    suggested several modifications to the originally proposed re-
 414    initialization protocol, and Phil Servita, who opened the debate with
 415    the first real protocol proposal and provided lots of specific input
 416    on the design of this and earlier protocols. The extensions to the
 417    OTP challenge were suggested by Chris Newman and John Valdes.
 418
 419    Randall Atkinson and Ted T'so also contributed their views to
 420    discussions about details of the protocol extensions in this
 421    document.
 422
 423 References
 424
 425    [RFC 822]   Crocker, D., "Standard for the Format of ARPA Internet
 426                Text Messages," RFC 822, August 1982.
 427
 428    [RFC 1825]  Atkinson, R., "Security Architecture for the Internet
 429                Protocol," RFC 1825, August 1995.
 430
 431    [RFC 1938]  Haller, N. and C. Metz, "A One-Time Password System,"
 432                RFC 1938, May 1996.
 433
 434    [RFC 2119]  Bradner, S., "Key words for use in RFCs to
 435                Indicate Requirement Level," RFC 2119,
 436                March 1997.
 437
 438 Author's Address
 439
 440    Craig Metz
 441    The Inner Net
 442    Box 10314-1936
 443    Blacksburg, VA 24062-0314
 444    (DSN) 354-8590
 445    cmetz@inner.net
 446
 447
 448
 449
 450 Metz                        Standards Track                     [Page 8]
 451 \f
 452 RFC 2243                 OTP Extended Responses            November 1997
 453
 454
 455 Appendix: Reference Responses
 456
 457    The following responses were generated by a development version of
 458    the One-Time Passwords in Everything (OPIE) implementation of this
 459    specification.
 460
 461    All of these are responses to the challenge:
 462
 463         otp-md5 499 ke1234 ext
 464
 465    Note that the re-initialization responses use the same secret pass
 466    phrase for new and current and a new seed of "ke1235". Also, these
 467    responses have been split for formatting purposes into multiple
 468    lines; they MUST NOT be multiple lines in actual use.
 469
 470    The secret pass phrase for these responses is:
 471
 472         This is a test.
 473
 474    The OTP standard hexadecimal response is:
 475
 476         5bf0 75d9 959d 036f
 477
 478    The OTP standard six-word response is:
 479
 480         BOND FOGY DRAB NE RISE MART
 481
 482    The OTP extended "hex" response is:
 483
 484         hex:5Bf0 75d9 959d 036f
 485
 486    The OTP extended "word" response is:
 487
 488         word:BOND FOGY DRAB NE RISE MART
 489
 490    The OTP extended "init-hex" response is:
 491
 492         init-hex:5bf0 75d9 959d 036f:md5 499 ke1235:3712 dcb4 aa53 16c1
 493
 494    The OTP extended "init-word" response is:
 495
 496         init-word:BOND FOGY DRAB NE RISE MART:md5 499 ke1235:  RED HERD
 497         NOW BEAN PA BURG
 498
 499
 500
 501
 502
 503
 504
 505
 506 Metz                        Standards Track                     [Page 9]
 507 \f
 508 RFC 2243                 OTP Extended Responses            November 1997
 509
 510
 511 Full Copyright Statement
 512
 513    Copyright (C) The Internet Society (1997).  All Rights Reserved.
 514
 515    This document and translations of it may be copied and furnished to
 516    others, and derivative works that comment on or otherwise explain it
 517    or assist in its implementation may be prepared, copied, published
 518    and distributed, in whole or in part, without restriction of any
 519    kind, provided that the above copyright notice and this paragraph are
 520    included on all such copies and derivative works.  However, this
 521    document itself may not be modified in any way, such as by removing
 522    the copyright notice or references to the Internet Society or other
 523    Internet organizations, except as needed for the purpose of
 524    developing Internet standards in which case the procedures for
 525    copyrights defined in the Internet Standards process must be
 526    followed, or as required to translate it into languages other than
 527    English.
 528
 529    The limited permissions granted above are perpetual and will not be
 530    revoked by the Internet Society or its successors or assigns.
 531
 532    This document and the information contained herein is provided on an
 533    "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
 534    TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
 535    BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
 536    HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
 537    MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
 538
 539
 540
 541
 542
 543
 544
 545
 546
 547
 548
 549
 550
 551
 552
 553
 554
 555
 556
 557
 558
 559
 560
 561
 562 Metz                        Standards Track                    [Page 10]
 563 \f