doc/standardisation/draft-richards-otp-kerberos-01.txt

   1
   2
   3
   4 Network Working Group                                        G. Richards
   5 Internet-Draft                         RSA, The Security Division of EMC
   6 Intended status: Standards Track                        October 11, 2006
   7 Expires: April 14, 2007
   8
   9
  10                               OTP Kerberos
  11                      draft-richards-otp-kerberos-01
  12
  13 Status of this Memo
  14
  15    By submitting this Internet-Draft, each author represents that any
  16    applicable patent or other IPR claims of which he or she is aware
  17    have been or will be disclosed, and any of which he or she becomes
  18    aware will be disclosed, in accordance with Section 6 of BCP 79.
  19
  20    Internet-Drafts are working documents of the Internet Engineering
  21    Task Force (IETF), its areas, and its working groups.  Note that
  22    other groups may also distribute working documents as Internet-
  23    Drafts.
  24
  25    Internet-Drafts are draft documents valid for a maximum of six months
  26    and may be updated, replaced, or obsoleted by other documents at any
  27    time.  It is inappropriate to use Internet-Drafts as reference
  28    material or to cite them other than as "work in progress."
  29
  30    The list of current Internet-Drafts can be accessed at
  31    http://www.ietf.org/ietf/1id-abstracts.txt.
  32
  33    The list of Internet-Draft Shadow Directories can be accessed at
  34    http://www.ietf.org/shadow.html.
  35
  36    This Internet-Draft will expire on April 14, 2007.
  37
  38 Copyright Notice
  39
  40    Copyright (C) The Internet Society (2006).
  41
  42 Abstract
  43
  44    The Kerberos protocol provides a framework authenticating a client
  45    using the exchange of pre-authentication data.  This document
  46    describes the use of this framework to carry out One Time Password
  47    (OTP) authentication.
  48
  49
  50
  51
  52
  53
  54
  55 Richards                 Expires April 14, 2007                 [Page 1]
  56 \f
  57 Internet-Draft                OTP Kerberos                  October 2006
  58
  59
  60 Table of Contents
  61
  62    1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
  63    2.  Usage Overview . . . . . . . . . . . . . . . . . . . . . . . .  3
  64      2.1.  Pre-Authentication . . . . . . . . . . . . . . . . . . . .  3
  65      2.2.  PIN Change . . . . . . . . . . . . . . . . . . . . . . . .  4
  66      2.3.  Re-Synchronization . . . . . . . . . . . . . . . . . . . .  4
  67    3.  Pre-Authentication Protocol Details  . . . . . . . . . . . . .  4
  68      3.1.  Shared Secret  . . . . . . . . . . . . . . . . . . . . . .  4
  69      3.2.  Client Request . . . . . . . . . . . . . . . . . . . . . .  5
  70      3.3.  KDC Challenge  . . . . . . . . . . . . . . . . . . . . . .  5
  71      3.4.  Client Response  . . . . . . . . . . . . . . . . . . . . .  7
  72      3.5.  Verifying the pre-auth Data  . . . . . . . . . . . . . . .  7
  73      3.6.  Updating the Secret  . . . . . . . . . . . . . . . . . . .  9
  74    4.  Reply Key Generation Algorithms  . . . . . . . . . . . . . . .  9
  75      4.1.  Using the OTP Value Directly . . . . . . . . . . . . . . .  9
  76      4.2.  Hardening the OTP Value  . . . . . . . . . . . . . . . . .  9
  77        4.2.1.  Using an Iteration Count . . . . . . . . . . . . . . . 10
  78        4.2.2.  Using a Shared Secret and OTP  . . . . . . . . . . . . 10
  79        4.2.3.  Using a Password and OTP . . . . . . . . . . . . . . . 11
  80      4.3.  Generating the Key without the OTP . . . . . . . . . . . . 11
  81        4.3.1.  Using the Password . . . . . . . . . . . . . . . . . . 11
  82        4.3.2.  Using a Shared Secret  . . . . . . . . . . . . . . . . 11
  83    5.  OTP Kerberos Types . . . . . . . . . . . . . . . . . . . . . . 12
  84      5.1.  PA-OTP-CHALLENGE . . . . . . . . . . . . . . . . . . . . . 12
  85      5.2.  PA-OTP-RESPONSE  . . . . . . . . . . . . . . . . . . . . . 13
  86      5.3.  PA-OTP-CONFIRM . . . . . . . . . . . . . . . . . . . . . . 16
  87      5.4.  PA-ENC-PIN . . . . . . . . . . . . . . . . . . . . . . . . 16
  88      5.5.  OTPChalKeyParam  . . . . . . . . . . . . . . . . . . . . . 17
  89      5.6.  OTPRespKeyParam  . . . . . . . . . . . . . . . . . . . . . 18
  90    6.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 19
  91    7.  Security Considerations  . . . . . . . . . . . . . . . . . . . 19
  92      7.1.  Active attacks . . . . . . . . . . . . . . . . . . . . . . 19
  93      7.2.  Denial of service attacks  . . . . . . . . . . . . . . . . 19
  94      7.3.  Use of a Shared Secret Value . . . . . . . . . . . . . . . 19
  95    8.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 20
  96      8.1.  Normative References . . . . . . . . . . . . . . . . . . . 20
  97      8.2.  Informative References . . . . . . . . . . . . . . . . . . 20
  98    Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 20
  99    Intellectual Property and Copyright Statements . . . . . . . . . . 22
 100
 101
 102
 103
 104
 105
 106
 107
 108
 109
 110
 111 Richards                 Expires April 14, 2007                 [Page 2]
 112 \f
 113 Internet-Draft                OTP Kerberos                  October 2006
 114
 115
 116 1.  Introduction
 117
 118    A One-Time Password (OTP) token may be a handheld hardware device, a
 119    hardware device connected to a personal computer through an
 120    electronic interface such as USB or a software module resident on a
 121    personal computer.  All these devices generate one-time passwords
 122    that may be used to authenticate a user towards some service.  This
 123    document describes extensions to Kerberos V5 [RFC4120] to support
 124    pre-authentication using an OTP.
 125
 126    In this proposal, the KDC sends the client a random nonce,
 127    information on which OTP token is to be used, how the OTP is to be
 128    generated using that token and how the Reply Key is to be generated.
 129    The Reply Key is then used to encrypt the nonce value and the
 130    encrypted value is returned to the KDC as the pre-authentication
 131    data.  Depending on whether the KDC can obtain the OTP value, the OTP
 132    value is either used in the generation of the Reply Key or is
 133    encrypted using the key and returned to the KDC along with the
 134    encrypted nonce.  The encrypted nonce, an optional encrypted OTP
 135    value and information on how the Reply Key and OTP value were
 136    generated are sent to the KDC and used by the KDC to generate the
 137    same Reply Key and decrypt and verify the nonce.
 138
 139    This proposal is partially based upon previous work on integrating
 140    single-use authentication mechanisms into Kerberos [HoReNeZo04] and
 141    uses the existing password-change extensions to handle PIN change as
 142    described in [RFC3244].
 143
 144    The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
 145    "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
 146    document are to be interpreted as described in [RFC2119].
 147
 148    << This is an early draft of this document and so is liable to change
 149    significantly. >>
 150
 151
 152 2.  Usage Overview
 153
 154 2.1.  Pre-Authentication
 155
 156    The approach uses pre-authentication data in KRB_AS_REQ, KRB_AS_REP
 157    and KRB_ERROR.  The client begins by sending an initial KRB_AS_REQ to
 158    the KDC that may contain pre-authentication data such as the standard
 159    Kerberos password data.  The KDC will then determine, in an
 160    implementation dependent fashion, whether OTP authentication is
 161    required and if it is, it will respond with a KRB_ERROR message
 162    containing a PA-OTP-CHALLENGE in the PA-DATA.
 163
 164
 165
 166
 167 Richards                 Expires April 14, 2007                 [Page 3]
 168 \f
 169 Internet-Draft                OTP Kerberos                  October 2006
 170
 171
 172    The PA-OTP-CHALLENGE contains information on how the OTP should be
 173    generated, how the Reply Key should be generated and a nonce.  The
 174    client uses this information to locate the token and generate the
 175    OTP, generate the Reply Key and then encrypt the nonce using the
 176    generated key.  Depending on the type of OTP, the Reply Key may be
 177    generated using the OTP value or alternatively, the generated OTP
 178    will instead be encrypted along with the nonce using the key.
 179
 180    The encrypted nonce along with information on how the OTP and Reply
 181    Key were generated are then sent to the KDC in a PA-OTP-RESPONSE PA-
 182    DATA element.  The KDC then uses this information to generate the
 183    same key as the client, allowing it to verify the pre-authentication
 184    by decrypting the nonce.  If the validation succeeds then the KDC
 185    returns the TGT in a KRB_AS_REP.
 186
 187 2.2.  PIN Change
 188
 189    If, following successful validation of a PA-OTP-RESPONSE in a
 190    KRB_AS_REQ, the KDC requires that the user changes their PIN then it
 191    will return PA-DATA of type PA-OTP-PIN-CHANGE in the KRB_AS_REP.
 192    This pre-auth data can be used to return a new PIN to the user if the
 193    KDC has updated the PIN or to indicate to the user that they must
 194    change their PIN.
 195
 196    In the latter case, user PIN change shall be handled by a PIN change
 197    service supporting the ChangePasswdData in a KRB_AP_REQ as described
 198    in [RFC3244].  If such a user PIN change is required then the KDC
 199    SHALL return a TGT in the KRB_AS_REP but it is RECOMMENDED that it
 200    only issues tickets for the PIN change service until the PIN has been
 201    changed.
 202
 203 2.3.  Re-Synchronization
 204
 205    It is possible with time and event-based tokens, that the client and
 206    OTP server will loose synchronization.  If, when processing a PA-OTP-
 207    RESPONSE, the pre-authentication validation fails for this reason
 208    then the KDC SHALL return a KRB_ERROR message containing a PA-OTP-
 209    CHALLENGE in the PA-DATA with the "nextOTP" flag set.  The setting of
 210    this flag will cause the client to re-try the authentication using
 211    the OTP for the next token "state".
 212
 213
 214 3.  Pre-Authentication Protocol Details
 215
 216 3.1.  Shared Secret
 217
 218    The method of deriving the Reply Key shall depend upon:
 219
 220
 221
 222
 223 Richards                 Expires April 14, 2007                 [Page 4]
 224 \f
 225 Internet-Draft                OTP Kerberos                  October 2006
 226
 227
 228    o  Whether the OTP is of sufficiently high entropy to generate the
 229       key alone.
 230
 231    o  Whether the OTP has insufficient entropy and so must be
 232       strengthened.
 233
 234    o  Whether the OTP value used can be obtained by the KDC.
 235
 236    If the OTP value is of low entropy then it is important to slow down
 237    an attacker sufficiently to make it economically unattractive to
 238    brute-force search for an OTP given an observed OTP-Kerberos
 239    exchange.  If the OTP value cannot be obtained by the KDC then it
 240    cannot be used in the derivation of the Reply Key but shall be
 241    encrypted using the generated key rather than used to derive the key
 242    and so the Reply Key must be derived from some other value.  Both of
 243    these issues can be solved using shared secret value known by the
 244    client and KDC but unknown to the attacker.
 245
 246    This protocol supports the following types of secret:
 247
 248    o  A pre-shared secret can be established between the client and KDC
 249       and stored on the client.
 250
 251    o  Diffie-Hellman key agreement (as defined in [RFC2631]) can be used
 252       to establish a shared secret value ZZ.  The server's public key,
 253       and the base and prime are stored on the client.
 254
 255    The pre-shared secret value or the Diffie-Hellman shared secret
 256    value, ZZ, are converted to a value of the required length for the
 257    encryption scheme's random-to-key function using the n-fold function
 258    (both defined in [RFC3961]).
 259
 260 3.2.  Client Request
 261
 262    The client begins by sending an initial KRB_AS_REQ possibly
 263    containing other pre-authentication data.  If the KDC determines that
 264    OTP-based pre-authentication is required and the request does not
 265    contain a PA-OTP-RESPONSE then it will respond as described in
 266    Section 3.3.
 267
 268    Alternatively, if the client has all the necessary information, it
 269    MAY construct a PA-OTP-RESPONSE as described in Section 3.4 and
 270    include it in the initial request.
 271
 272 3.3.  KDC Challenge
 273
 274    If the user is required to authenticate using an OTP then the KDC
 275    SHALL respond to the initial KRB_AS_REQ with a KRB_ERROR containing:
 276
 277
 278
 279 Richards                 Expires April 14, 2007                 [Page 5]
 280 \f
 281 Internet-Draft                OTP Kerberos                  October 2006
 282
 283
 284    o  An error code of KDC_ERR_PREAUTH_REQUIRED
 285
 286    o  An e-data field containing PA-DATA with a PA-OTP-CHALLENGE.
 287
 288    The PA-OTP-CHALLENGE SHALL contain a nonce value to be encrypted by
 289    the generated Reply Key and it MAY also contain information on how
 290    the OTP value is to be generated and information on how the Reply Key
 291    is to be generated in an otp-keyParam element.
 292
 293    Use of the otp-keyParam element is OPTIONAL.  If it is not present
 294    the Reply Key SHALL be generated directly from the OTP value as
 295    specified in Section 4.1 and the OTP value SHALL NOT be included in
 296    the client response.
 297
 298    If the otp-keyParam element is present and the "sendOTP" flag is set
 299    then the OTP value MUST NOT be used in the generation of the Reply
 300    Key but it must instead be returned to the KDC encrypted using the
 301    key.  The Reply Key MUST be derived using one of the methods
 302    described in Section 4.3.  If the "sendOTP" flag is not set then the
 303    OTP value is to be used in the key derivation then the client MUST
 304    use one of the methods described in Section 4.2.
 305
 306    The otp-keyParam element will control the use of a shared secret in
 307    the key derivation.  If the "noSecret" flag is set the the client
 308    MUST NOT use a secret value in the key derivation.  If the "noSecret"
 309    flag is not set and secret identifier is present then the client MUST
 310    NOT use any other secret value.  If the "noSecret" flag is not set
 311    and a secret identifier is not present then the client MAY still use
 312    a value if there is a value associated with the KDC.
 313
 314    If the "noSecret" flag is not set and the client can locate a secret
 315    value for the KDC then the Reply Key will be generated using one of
 316    the following methods:
 317
 318    o  If the OTP is to be included in the key derivation then the key
 319       SHALL be derived as specified in Section 4.2.2.
 320
 321    o  If the OTP is to be sent encrypted in the response then the key
 322       SHALL be derived as specified in Section 4.3.2.
 323
 324    If the client fails to find a shared secret for the KDC or the
 325    "noSecret" flag was set in the challenge then the Reply Key will be
 326    generated using one of the following methods:
 327
 328    o  If the OTP is to be used in the key derivation then the KDC MAY
 329       specify an iteration count.  If such a value is specified then the
 330       key SHALL be derived from the OTP as described in Section 4.2.1.
 331
 332
 333
 334
 335 Richards                 Expires April 14, 2007                 [Page 6]
 336 \f
 337 Internet-Draft                OTP Kerberos                  October 2006
 338
 339
 340    o  If the OTP is to be used in the key derivation but an iteration
 341       count was not specified then the key SHALL be derived from the OTP
 342       value and the user's Kerberos password as described in
 343       Section 4.2.3.
 344
 345    o  If the OTP is to be sent encrypted then the key SHALL be derived
 346       from the user's Kerberos password as described in section
 347       Section 4.3.1.
 348
 349 3.4.  Client Response
 350
 351    The client will use the generated Reply Key to encrypt the nonce from
 352    the KDC challenge and, if required, to encrypt the OTP value.  This
 353    encrypted data SHALL be sent to the KDC in the otp-encData of a PA-
 354    OTP-RESPONSE PA-DATA element included in a KRB_AS_REQ.
 355
 356    This response MAY also include information on how the Reply Key was
 357    generated in an optional otp-keyParam element.  The client MUST NOT
 358    include this element if the Reply Key was generated directly from the
 359    OTP value.  The element MUST be included if the Reply Key was
 360    generated using either a secret value or an iteration count and
 361    contain the secret identifier and iteration count value.  If the
 362    Reply Key was generated using a password then the element MUST be
 363    present and MUST be empty.
 364
 365    The response SHOULD also include information on the generated OTP
 366    value.
 367
 368 3.5.  Verifying the pre-auth Data
 369
 370    If KRB_AS_REQ contains a PA-OTP-RESPONSE then the KDC will then use
 371    the information in the otp-keyParam to generate the same Reply Key
 372    and decrypt the encrypted nonce contained in the otp-encData.
 373
 374    If the encrypted OTP value is not included in the otp-encData then
 375    the Reply Key was generated using the OTP value.  The KDC SHALL
 376    therefore use the OTP information in the PA-OTP-RESPONSE to obtain
 377    the OTP value for the user and use the value along with the
 378    information in the otp-keyParam to generate the Reply Key. This
 379    information SHALL be used as follows:
 380
 381    o  If the otp-keyParam is not present then the Reply Key SHALL be
 382       generated directly from the OTP value as described in Section 4.1.
 383
 384    o  If the otp-keyParam is present but empty then the Reply Key SHALL
 385       be generated using the OTP value and the user's Kerberos Password
 386       as described in Section 4.2.3.
 387
 388
 389
 390
 391 Richards                 Expires April 14, 2007                 [Page 7]
 392 \f
 393 Internet-Draft                OTP Kerberos                  October 2006
 394
 395
 396    o  If the otp-keyParam is present and contains a secret identifier
 397       then the Reply Key SHALL be generated using the OTP value and the
 398       secret value as described in Section 4.2.2.
 399
 400       If the identified secret value can not be found then the KDC SHALL
 401       respond with a KDC_ERR_PREAUTH_REQUIRED error as described above
 402       but SHALL set the "noSecret" flag in the PA-OTP-CHALLENGE.
 403
 404    o  if the otp-keyParam is present and contains an iteration count
 405       then the Reply Key shall be generated from the OTP value using the
 406       iteration count value as described in Section 4.2.1.
 407
 408    If the encrypted OTP value is included in the otp-encData then the
 409    Reply Key was not generated using the OTP value but was instead used
 410    to encrypt the OTP value.  The KDC SHALL therefore use the
 411    information in the otp-keyParam to generate the Reply Key and decrypt
 412    the OTP value.  It SHALL then validate the decrypted value using the
 413    OTP information included in the response and fail the authentication
 414    if the value is not valid.
 415
 416    This Reply Key SHALL be generated as follows:
 417
 418    o  If the otp-keyParam is not present the the KDC SHALL fail the pre-
 419       authentication with an error of KDC_ERR_PREAUTH_FAILED.
 420
 421       If the otp-keyParam is omitted then the Reply Key was generated
 422       directly from the OTP value and so is an error if the OTP value is
 423       encrypted using the key.
 424
 425    o  If the otp-keyParam is present but empty then the Reply Key SHALL
 426       be generated using the user's Kerberos Password as described in
 427       Section 4.3.1.
 428
 429    o  If the otp-keyParam is present and contains a secret identifier
 430       then the Reply Key SHALL be generated using the secret value as
 431       described in Section 4.3.2.
 432
 433       If the identified secret value can not be found then the KDC SHALL
 434       respond with a KDC_ERR_PREAUTH_REQUIRED error as described above
 435       but SHALL set the "noSecret" flag in the PA-OTP-CHALLENGE.
 436
 437    o  If the otp-keyParam is present and contains an iteration count
 438       then the KDC SHALL fail the authentication with an error of
 439       KDC_ERR_PREAUTH_FAILED.
 440
 441
 442
 443
 444
 445
 446
 447 Richards                 Expires April 14, 2007                 [Page 8]
 448 \f
 449 Internet-Draft                OTP Kerberos                  October 2006
 450
 451
 452 3.6.  Updating the Secret
 453
 454    The secret value can be pre-configured on the client but MAY also be
 455    transferred from the KDC to the client in encrypted form in the PA-
 456    OTP-CONFIRM of the KRB_AS_REP.  If a client receives a new secret
 457    value in this way then it MUST update any stored value associated
 458    with the KDC.
 459
 460
 461 4.  Reply Key Generation Algorithms
 462
 463 4.1.  Using the OTP Value Directly
 464
 465    If only the OTP value is to be used then the Reply Key SHALL be
 466    generated by passing the OTP value through string-to-key (defined in
 467    [RFC3961]).
 468
 469              K = string-to-key(OTP)
 470
 471    The salt and additional parameters for string-to-key will be as
 472    defined in section 3.1.3 of [RFC4120].
 473
 474 4.2.  Hardening the OTP Value
 475
 476    If the OTP value requires strengthening then several methods shall be
 477    supported.
 478
 479    o  The OTP can be used on its own in the key derivation but run
 480       through an iteration process many times as described in
 481       Section 4.2.1.
 482
 483    o  A secret value, shared between the KDC and client can be used
 484       along with the OTP value to derive the key as described in
 485       Section 4.2.2.
 486
 487    o  The user's Kerberos password can be used along with the OTP value
 488       in the key derivation as described in Section 4.2.3.
 489
 490    A shared secret can only be used if the client supports the storing
 491    of persistent values and has such a value stored.  The other two
 492    methods could be used to establish a secret value or when client are
 493    not capable of storing such values.
 494
 495    <<Is there value in another mode which uses the Kerberos password in
 496    conjunction with an iteration-hardened OTP value?>>
 497
 498
 499
 500
 501
 502
 503 Richards                 Expires April 14, 2007                 [Page 9]
 504 \f
 505 Internet-Draft                OTP Kerberos                  October 2006
 506
 507
 508 4.2.1.  Using an Iteration Count
 509
 510    An initial key is generated by running the OTP value through string-
 511    to-key.
 512
 513              K = string-to-key(OTP)
 514
 515    The following key generation process is then repeated iteration count
 516    times with the resulting key being used as the protocol key for the
 517    next iteration.
 518
 519    A sequence of octets, R, is produced from K by iterating over calls
 520    to the function pseudo-random (defined in [RFC3961]) and appending
 521    the results until at least the number of bits required by random-to-
 522    key have been produced.  If the result of the iteration is longer
 523    than the required length then the result shall be truncated.
 524
 525    The octet string parameter for pseudo-random shall be the ASCII
 526    string "CombineA" with the loop number appended.  This string has the
 527    following byte value:
 528
 529       {0x43, 0x6f, 0x6d, 0x62, 0x69, 0x6e, 0x65, 0x41}
 530
 531    A new key is then generated by running R through random-to-key.
 532
 533              K = random-to-key(R)
 534
 535 4.2.2.  Using a Shared Secret and OTP
 536
 537    Two intermediate keys, K1 and K2, shall be generated by running the
 538    OTP value once through string-to-key and the shared secret through
 539    random-to-key.
 540
 541              K1 = random-to-key(shared secret)
 542              K2 = string-to-key(OTP)
 543
 544    Two sequences of octets, R1 and R2, are then produced from K1 and K2
 545    by iterating over calls to pseudo-random and appending the results
 546    until the required number of bits have been generated for random-to-
 547    key.  If the result of the iteration is longer than the required
 548    length then the result shall be truncated.
 549
 550    The octet string parameter for pseudo-random shall be the ASCII
 551    string "CombineA" for K1 and "CombineB" for K2 with the loop number
 552    appended.  These have the following byte values:
 553
 554
 555
 556
 557
 558
 559 Richards                 Expires April 14, 2007                [Page 10]
 560 \f
 561 Internet-Draft                OTP Kerberos                  October 2006
 562
 563
 564       {0x43, 0x6f, 0x6d, 0x62, 0x69, 0x6e, 0x65, 0x41}
 565       {0x43, 0x6f, 0x6d, 0x62, 0x69, 0x6e, 0x65, 0x42}
 566
 567    The final key is then generated by combining R1 and R2 using
 568    exclusive-OR and running the result through random-to-key.
 569
 570              K = random-to-key(R1 ^ R2)
 571
 572    << Check on issue around combining DES keys. >>
 573
 574 4.2.3.  Using a Password and OTP
 575
 576    Two intermediate keys, K1 and K2, shall be generated by running the
 577    OTP and password through string-to-key.
 578
 579              K1 = string-to-key(Password)
 580              K2 = string-to-key(OTP)
 581
 582    The same process as described in Section 4.2.2 is then used to derive
 583    the final reply key.
 584
 585 4.3.  Generating the Key without the OTP
 586
 587    If the OTP value cannot be used in the derivation of the reply key
 588    then this protocol supports the following options:
 589
 590    o  A secret value, shared between the KDC and client can be used to
 591       derive the key as described in Section 4.3.2.
 592
 593    o  The user's Kerberos password can be used in the key derivation as
 594       described in Section 4.3.1.
 595
 596    A shared secret can only be used if the client supports the storing
 597    of persistent values and has such a value stored.  The password-only
 598    method could be used to establish a secret value or when clients are
 599    not capable of storing such values.
 600
 601 4.3.1.  Using the Password
 602
 603    The Reply Key SHALL be generated by passing the password value
 604    through string-to-key (defined in [RFC3961]).
 605
 606 4.3.2.  Using a Shared Secret
 607
 608    The reply key shall be generated by running the shared secret value
 609    through random-to-key.
 610
 611              K = random-to-key(shared secret)
 612
 613
 614
 615 Richards                 Expires April 14, 2007                [Page 11]
 616 \f
 617 Internet-Draft                OTP Kerberos                  October 2006
 618
 619
 620 5.  OTP Kerberos Types
 621
 622 5.1.  PA-OTP-CHALLENGE
 623
 624    This is a pre-authentication type sent by the KDC to the client in a
 625    KRB_ERROR.  It contains information for the client on how to generate
 626    the OTP and reply key.
 627
 628              PA-OTP-CHALLENGE ::= SEQUENCE {
 629                otp-flags         OTPFlags,
 630                otp-nonce         UInt32,
 631                otp-etype         INTEGER,
 632                otp-track-id  [0] OCTET STRING    OPTIONAL,
 633                otp-challenge [1] OCTET STRING    OPTIONAL,
 634                otp-length    [2] INTEGER         OPTIONAL,
 635                otp-service   [3] UTF8String      OPTIONAL,
 636                otp-keyID     [4] OCTET STRING    OPTIONAL,
 637                otp-algID     [5] INTEGER         OPTIONAL,
 638                otp-keyParam  [6] OTPChalKeyParam OPTIONAL
 639              }
 640
 641              OTPFlags ::= KerberosFlags
 642              -- nextOTP (0)
 643
 644    otp-flags
 645       If the "nextOTP" flag is set then the OTP calculated SHALL be
 646       based on the next token "state" rather than the current one.  As
 647       an example, for a time-based token, this means the next time slot.
 648       For an event-based token, this could mean the next counter value,
 649       if counter values are used.
 650
 651    otp-nonce
 652       A KDC-supplied nonce value to be encrypted by the client in the
 653       PA-OTP-RESPONSE.
 654
 655    otp-etype
 656       The encryption type to be used by the client for all encrypted
 657       fields in the PA-OTP-RESPONSE.
 658
 659    otp-track-id
 660       This optional element is used by the KDC to link a client response
 661       to the corresponding KDC challenge.  If present, this element MUST
 662       be copied by the client to the corresponding element in the PA-
 663       OTP-RESPONSE.
 664
 665
 666
 667
 668
 669
 670
 671 Richards                 Expires April 14, 2007                [Page 12]
 672 \f
 673 Internet-Draft                OTP Kerberos                  October 2006
 674
 675
 676    otp-challenge
 677       The otp-challenge is used by the KDC to send a challenge value for
 678       use in the OTP calculation.  The challenge is an optional octet
 679       string that SHOULD be uniquely generated for each request it is
 680       present in, and SHOULD be eight octets or longer when present.
 681       When the challenge is not present, the OTP will be calculated on
 682       the current token state only.  The client MAY ignore a provided
 683       challenge if and only if the OTP token the client is interacting
 684       with is not capable of including a challenge in the OTP
 685       calculation.  In this case, KDC policies will determine whether to
 686       accept a provided OTP value or not.
 687
 688    otp-length
 689       The otp-length is used by the KDC to specify the desired length of
 690       the generated OTP.
 691
 692    otp-service
 693       An identifier of the service supported by the KDC.  This value can
 694       be used by the client to locate information such as the shared
 695       secret value and OTP key to use.
 696
 697    otp-keyID
 698       The identifier of the OTP key to be used in the OTP calculation.
 699       If this value is not present then the client SHOULD use other
 700       values such as the otp-service and otp-algID to locate the
 701       appropriate key.
 702
 703    otp-algID
 704       The identifier of the algorithm to use when generating the OTP.
 705
 706    otp-keyParam
 707       Information on how the Reply Key should be generated from the OTP
 708       and shared secret.  If the value is not present then the reply key
 709       MUST be generated directly from the OTP value.
 710
 711    <<TBD: Should a checksum be added to allow the client to verify the
 712    challenge?>>
 713
 714 5.2.  PA-OTP-RESPONSE
 715
 716    This is a pre-authentication type sent by the client to the KDC in a
 717    KRB_AS_REQ containing the encrypted pre-authentication data.  It
 718    contains information on the OTP used and how the key was generated
 719    that encrypts the pre-authentication data.  This information will
 720    then allow the KDC to generate the same key and validate the pre-
 721    authentication data.
 722
 723
 724
 725
 726
 727 Richards                 Expires April 14, 2007                [Page 13]
 728 \f
 729 Internet-Draft                OTP Kerberos                  October 2006
 730
 731
 732              PA-OTP-RESPONSE ::= SEQUENCE {
 733                otp-flags         OTPFlags,
 734                otp-nonce         UInt32,
 735                otp-encData       EncryptedData,
 736                                       -- PA-ENC-RESPONSE
 737                                       -- Key usage of <<TBD>>
 738                otp-track-id  [0] OCTET STRING    OPTIONAL,
 739                otp-challenge [1] OCTET STRING    OPTIONAL,
 740                otp-time      [2] KerberosTime    OPTIONAL,
 741                otp-counter   [3] OCTET STRING    OPTIONAL,
 742                otp-format    [4] OTPFormat       OPTIONAL,
 743                otp-keyID     [5] OCTET STRING    OPTIONAL,
 744                otp-keyParam  [6] OTPRespKeyParam OPTIONAL
 745              }
 746
 747
 748
 749              OTPFormat ::= INTEGER {
 750                decimal(0),
 751                hexadecimal(1),
 752                alphanumeric(2),
 753                binary(3)
 754              }
 755
 756
 757
 758              PA-ENC-RESPONSE ::= SEQUENCE {
 759                nonce     OCTET STRING OPTIONAL,
 760                otp   [0] OCTET STRING OPTIONAL
 761              }
 762
 763    otp-flags
 764       If the "nextOTP" flag is set then the OTP was calculated based on
 765       the next token "state" rather than the current one.  This flag
 766       MUST be set if and only if it was set in a corresponding PA-OTP-
 767       CHALLENGE.
 768
 769    otp-nonce
 770       The nonce value encrypted in the otp-encData.  If the PA-OTP-
 771       RESPONSE is sent as a result of a PA-OTP_CHALLENGE then the value
 772       MUST be a copy of the corresponding value in the challenge.  If no
 773       challenge was received then the nonce value MUST be generated by
 774       the client.
 775
 776
 777
 778
 779
 780
 781
 782
 783 Richards                 Expires April 14, 2007                [Page 14]
 784 \f
 785 Internet-Draft                OTP Kerberos                  October 2006
 786
 787
 788    otp-track-id
 789       This element MUST be included if and only if an otp-track-id was
 790       included in the corresponding PA-OTP-CHALLENGE.  If included, then
 791       the value MUST be copied from the PA-OTP-CHALLENGE.
 792
 793    otp-challenge
 794       Value used by the client to send the challenge used in the OTP
 795       calculation.  It MUST be sent to the KDC if and only if the value
 796       would otherwise be unknown to the KDC.  For example, the token or
 797       client modified or generated challenge.
 798
 799    otp-time
 800       Value used by the client to send the time used in the OTP
 801       calculation.
 802
 803    otp-counter
 804       The counter value used in the OTP calculation.  Use of this
 805       element is OPTIONAL but it MAY be used by a client to simplify the
 806       OTP calculations of the KDC to contain the counter value as
 807       reported by the OTP token.
 808
 809    otp-format
 810       The format of the generated OTP.
 811
 812    otp-keyID
 813       The identifier of the OTP key used.
 814
 815    otp-keyParam
 816       Information on how the reply key was generated from the OTP and
 817       shared secret.  If the value is not present then the reply key was
 818       generated directly from the OTP value.
 819
 820    otp-encData
 821       The otp-encData field contains the result of the pre-
 822       authentication process and is encrypted using the generated Reply
 823       Key. The fields of this element are populated as follows:
 824
 825       nonce
 826          The value of otp-nonce.
 827
 828       otp
 829          The generated OTP value.  Present if the "sendOTP" flag is set
 830          in the challenge.
 831
 832    <<TBD: Does the response need something such as an encrypted
 833    timestamp to protect against replay?>>
 834
 835
 836
 837
 838
 839 Richards                 Expires April 14, 2007                [Page 15]
 840 \f
 841 Internet-Draft                OTP Kerberos                  October 2006
 842
 843
 844 5.3.  PA-OTP-CONFIRM
 845
 846    This is a pre-authentication type returned by the KDC in a KRB_AS_REP
 847    if the client requires a new shared secret value.  The value is
 848    encrypted as described in section 5.2.9 of [RFC4120] using the
 849    current reply key as derived by the KDC from the OTP.
 850
 851              PA-OTP-CONFIRM ::= SEQUENCE {
 852                identifier      OCTET STRING,
 853                newSecretValue  EncryptedData  -- OTPNewSecret
 854                                               -- Key usage of <<TBD>>
 855              }
 856
 857              OTPNewSecret ::= CHOICE {
 858                sharedSecret [0] OCTET STRING,
 859                dhParams     [1] DHParam
 860              }
 861
 862              DHParam ::= SEQUENCE {
 863                dhParameter DHParameter,
 864                dhPublic    INTEGER
 865              }
 866
 867    identifier
 868       An octet string identifying the new secret value.
 869
 870    newSecretValue
 871       The new secret data encrypted using the current Reply Key. The
 872       encrypted data can be of one of the following types:
 873
 874       sharedSecret
 875          A random bit string.
 876
 877       dhParams
 878          A Diffie-Hellman public value, prime and modulus.
 879
 880 5.4.  PA-ENC-PIN
 881
 882    Pre-authentication type returned by the KDC in a KRB_AS_REP if the
 883    user must change their PIN or if the user's PIN has been changed.
 884
 885
 886
 887
 888
 889
 890
 891
 892
 893
 894
 895 Richards                 Expires April 14, 2007                [Page 16]
 896 \f
 897 Internet-Draft                OTP Kerberos                  October 2006
 898
 899
 900              PA-ENC-PIN     ::= EncryptedData -- PA-ENC-PIN-ENC
 901                                               -- Key usage of <<TBD>>
 902              PA-ENC-PIN-ENC ::= SEQUENCE {
 903                flags         PinFlags,
 904                pin       [0] UTF8String OPTIONAL,
 905                minLength [1] INTEGER    OPTIONAL,
 906                maxLength [2] INTEGER    OPTIONAL
 907              }
 908
 909              PinFlags ::= KerberosFlags
 910                -- systemSetPin (0)
 911
 912    If the "systemSetPin" flag is set then the user's PIN has been
 913    changed and the new PIN value is contained in the pin field.  The PIN
 914    field MUST therefore be present.
 915
 916    If the "systemSetPin" flag is not set then the user's PIN has not
 917    been changed by the server but it MUST instead be changed by the user
 918    using the PIN change service.  Restrictions on the size of the PIN
 919    MAY be given by the minLength and maxLength fields.  If the pin field
 920    is present then it contains a PIN value that MAY be used by the user
 921    when changing the PIN.  The KDC MAY only issue tickets for the PIN
 922    change service until the PIN has been changed.
 923
 924 5.5.  OTPChalKeyParam
 925
 926    This data type can optionally be included by the KDC in a PA-OTP-
 927    CHALLENGE to instruct the client on how to generate the reply key.
 928
 929    This value is included in the challenge if the OTP generated by the
 930    token is too weak to be used alone in the generation of the key.
 931
 932              OTPChalKeyParam ::= SEQUENCE {
 933                flags              ChallengeFlags,
 934                identifer      [0] OCTET STRING OPTIONAL,
 935                iterationCount [1] INTEGER OPTIONAL
 936              }
 937
 938              ChallengeFlags ::= KerberosFlags
 939                -- sendOTP  (0)
 940                -- noSecret (1)
 941
 942    flags
 943       Flags controlling the generation of the Reply Key.
 944
 945
 946
 947
 948
 949
 950
 951 Richards                 Expires April 14, 2007                [Page 17]
 952 \f
 953 Internet-Draft                OTP Kerberos                  October 2006
 954
 955
 956       sendOTP
 957          If the "sendOTP" flag is set then the client MUST NOT use the
 958          OTP value to generate the reply key.  It must instead use the
 959          generated key to encrypt the OTP value and include the
 960          encrypted value in the PA-OTP-RESPONSE.
 961
 962       noSecret
 963          If the "noSecret" flag is set then the client MUST NOT use any
 964          stored secret value in the derivation of the Reply Key. If the
 965          "sendOTP" flag is also set then the Kerberos password MUST be
 966          used.  If the "sendOTP" flag is not set then the iteration
 967          count MUST be used if it is present or the Kerberos password
 968          MUST be used if the iteration count is not specified.
 969
 970    identifier
 971       Name of the secret that the client SHOULD use to generate the
 972       reply key.
 973
 974       If a secret is specified but cannot be located by the client and
 975       an iteration count is specified then the client should generate
 976       the key using the iteration count.  If a secret value is specified
 977       and cannot be located and an iteration count is not specified then
 978       the reply key MUST be generated using the user's Kerberos
 979       password.
 980
 981    iterationCount
 982       This value contains the iteration count to use when the generated
 983       OTP value is used in the derivation of the reply key.  This value
 984       is used by the client if a shared secret is not specified or is
 985       specified but cannot be found.  The value has no meaning if the
 986       "sendOTP" flag is set.
 987
 988 5.6.  OTPRespKeyParam
 989
 990    This data type can optionally be included by the client in a PA-OTP-
 991    RESPONSE to inform the KDC of how the reply key was generated.
 992
 993              OTPRespKeyParam ::= SEQUENCE {
 994                iterationCount [0] INTEGER OPTIONAL,
 995                secret SEQUENCE {
 996                  identifier       OCTET STRING,
 997                  dhPublic     [1] INTEGER OPTIONAL
 998                }
 999              }
1000
1001
1002
1003
1004
1005
1006
1007 Richards                 Expires April 14, 2007                [Page 18]
1008 \f
1009 Internet-Draft                OTP Kerberos                  October 2006
1010
1011
1012    iterationCount
1013       The actual value of the iteration count used by the client in the
1014       key derivation.  If omitted then no iteration was used in the
1015       derivation of the reply key.
1016
1017    secret
1018       Information on the secret used in the key derivation.  If this
1019       value is omitted then no shared secret was used.
1020
1021       identifier
1022          An octet string identifying the shared secret value used by the
1023          client in the key derivation.
1024       dhPublic
1025          The client's Diffie-Hellman public key.  Present only if a
1026          Diffie-Hellman secret was used.
1027
1028
1029 6.  IANA Considerations
1030
1031    A registry may be required for the otp-AlgID values as introduced in
1032    Section 5.1.  No other IANA actions are anticipated.
1033
1034
1035 7.  Security Considerations
1036
1037 7.1.  Active attacks
1038
1039    <<TBS >>
1040
1041 7.2.  Denial of service attacks
1042
1043    An active attacker may replace the iteration count value in the PA-
1044    OTP-RESPONSE sent by the client to slow down an authentication
1045    server.  Authentication servers SHOULD protect against this, e.g. by
1046    disregarding PA-OTP-RESPONSE elements with an iteration count value
1047    higher than some pre- or dynamically- (depending on load) set number.
1048
1049 7.3.  Use of a Shared Secret Value
1050
1051    As described in Section 3.1, the use of a shared secret value will
1052    slow down an attacker's search for a matching OTP.  The ability to
1053    transfer such a value in encrypted form from the KDC to the client
1054    means that, even though there may be an initial computational cost
1055    for the KDC to authenticate the user if an iteration count is used,
1056    subsequent authentications will be efficient, while at the same time
1057    more secure, since a pre-shared, value will not be easily found by an
1058    attacker.
1059
1060
1061
1062
1063 Richards                 Expires April 14, 2007                [Page 19]
1064 \f
1065 Internet-Draft                OTP Kerberos                  October 2006
1066
1067
1068    If a client does not have a pre-configured secret value for a KDC
1069    then it will have to generate the Reply Key using an iteration count
1070    or the Kerberos password.  If an iteration count is used then an
1071    attacker observing such a KRB_AS_REQ may, depending on available
1072    resources, be able to successfully attack that request.  Once the
1073    correct OTP has been found, eavesdropping on the KDC's PA_OTP_CONFIRM
1074    will potentially give the attacker access to the server-provided
1075    secret value.  For this reason, initial exchanges with KDC servers
1076    SHOULD occur in a secure environment and the lifetime of this value
1077    must also be calculated with this in mind.  Finally, the value MUST
1078    be securely stored by the client and the KDC, associated with the
1079    user.
1080
1081
1082 8.  References
1083
1084 8.1.  Normative References
1085
1086    [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
1087               Requirement Levels", BCP 14, RFC 2119, March 1997.
1088
1089    [RFC2631]  Rescorla, E., "Diffie-Hellman Key Agreement Method",
1090               RFC 2631, June 1999.
1091
1092    [RFC3244]  Swift, M., Trostle, J., and J. Brezak, "Microsoft Windows
1093               2000 Kerberos Change Password and Set Password Protocols",
1094               RFC 3244, February 2002.
1095
1096    [RFC3961]  Raeburn, K., "Encryption and Checksum Specifications for
1097               Kerberos 5", RFC 3961, February 2005.
1098
1099    [RFC4120]  Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The
1100               Kerberos Network Authentication Service (V5)", RFC 4120,
1101               July 2005.
1102
1103 8.2.  Informative References
1104
1105    [HoReNeZo04]
1106               Horstein, K., Renard, K., Neuman, C., and G. Zorn,
1107               "Integrating Single-use Authentication Mechanisms with
1108               Kerberos", draft-ietf-krb-wg-kerberos-sam-03 (work in
1109               progress), July 2004.
1110
1111
1112
1113
1114
1115
1116
1117
1118
1119 Richards                 Expires April 14, 2007                [Page 20]
1120 \f
1121 Internet-Draft                OTP Kerberos                  October 2006
1122
1123
1124 Author's Address
1125
1126    Gareth Richards
1127    RSA, The Security Division of EMC
1128    RSA House
1129    Western Road
1130    Bracknell, Berkshire  RG12 1RT
1131    UK
1132
1133    Email: grichards@rsa.com
1134
1135
1136
1137
1138
1139
1140
1141
1142
1143
1144
1145
1146
1147
1148
1149
1150
1151
1152
1153
1154
1155
1156
1157
1158
1159
1160
1161
1162
1163
1164
1165
1166
1167
1168
1169
1170
1171
1172
1173
1174
1175 Richards                 Expires April 14, 2007                [Page 21]
1176 \f
1177 Internet-Draft                OTP Kerberos                  October 2006
1178
1179
1180 Full Copyright Statement
1181
1182    Copyright (C) The Internet Society (2006).
1183
1184    This document is subject to the rights, licenses and restrictions
1185    contained in BCP 78, and except as set forth therein, the authors
1186    retain all their rights.
1187
1188    This document and the information contained herein are provided on an
1189    "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
1190    OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
1191    ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
1192    INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
1193    INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
1194    WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
1195
1196
1197 Intellectual Property
1198
1199    The IETF takes no position regarding the validity or scope of any
1200    Intellectual Property Rights or other rights that might be claimed to
1201    pertain to the implementation or use of the technology described in
1202    this document or the extent to which any license under such rights
1203    might or might not be available; nor does it represent that it has
1204    made any independent effort to identify any such rights.  Information
1205    on the procedures with respect to rights in RFC documents can be
1206    found in BCP 78 and BCP 79.
1207
1208    Copies of IPR disclosures made to the IETF Secretariat and any
1209    assurances of licenses to be made available, or the result of an
1210    attempt made to obtain a general license or permission for the use of
1211    such proprietary rights by implementers or users of this
1212    specification can be obtained from the IETF on-line IPR repository at
1213    http://www.ietf.org/ipr.
1214
1215    The IETF invites any interested party to bring to its attention any
1216    copyrights, patents or patent applications, or other proprietary
1217    rights that may cover technology that may be required to implement
1218    this standard.  Please address the information to the IETF at
1219    ietf-ipr@ietf.org.
1220
1221
1222 Acknowledgment
1223
1224    Funding for the RFC Editor function is provided by the IETF
1225    Administrative Support Activity (IASA).
1226
1227
1228
1229
1230
1231 Richards                 Expires April 14, 2007                [Page 22]
1232 \f