1 2 3 4Network Working Group G. Richards 5Internet-Draft RSA, The Security Division of EMC 6Intended status: Standards Track October 11, 2006 7Expires: April 14, 2007 8 9 10 OTP Kerberos 11 draft-richards-otp-kerberos-01 12 13Status 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 38Copyright Notice 39 40 Copyright (C) The Internet Society (2006). 41 42Abstract 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 55Richards Expires April 14, 2007 [Page 1] 56 57Internet-Draft OTP Kerberos October 2006 58 59 60Table 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 111Richards Expires April 14, 2007 [Page 2] 112 113Internet-Draft OTP Kerberos October 2006 114 115 1161. 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 1522. Usage Overview 153 1542.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 167Richards Expires April 14, 2007 [Page 3] 168 169Internet-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 1872.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 2032.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 2143. Pre-Authentication Protocol Details 215 2163.1. Shared Secret 217 218 The method of deriving the Reply Key shall depend upon: 219 220 221 222 223Richards Expires April 14, 2007 [Page 4] 224 225Internet-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 2603.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 2723.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 279Richards Expires April 14, 2007 [Page 5] 280 281Internet-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 335Richards Expires April 14, 2007 [Page 6] 336 337Internet-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 3493.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 3683.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 391Richards Expires April 14, 2007 [Page 7] 392 393Internet-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 447Richards Expires April 14, 2007 [Page 8] 448 449Internet-Draft OTP Kerberos October 2006 450 451 4523.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 4614. Reply Key Generation Algorithms 462 4634.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 4744.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 503Richards Expires April 14, 2007 [Page 9] 504 505Internet-Draft OTP Kerberos October 2006 506 507 5084.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 5354.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 559Richards Expires April 14, 2007 [Page 10] 560 561Internet-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 5744.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 5854.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 6014.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 6064.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 615Richards Expires April 14, 2007 [Page 11] 616 617Internet-Draft OTP Kerberos October 2006 618 619 6205. OTP Kerberos Types 621 6225.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 671Richards Expires April 14, 2007 [Page 12] 672 673Internet-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 7145.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 727Richards Expires April 14, 2007 [Page 13] 728 729Internet-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 783Richards Expires April 14, 2007 [Page 14] 784 785Internet-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 839Richards Expires April 14, 2007 [Page 15] 840 841Internet-Draft OTP Kerberos October 2006 842 843 8445.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 8805.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 895Richards Expires April 14, 2007 [Page 16] 896 897Internet-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 9245.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 951Richards Expires April 14, 2007 [Page 17] 952 953Internet-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 9885.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 1007Richards Expires April 14, 2007 [Page 18] 1008 1009Internet-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 10296. 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 10357. Security Considerations 1036 10377.1. Active attacks 1038 1039 <<TBS >> 1040 10417.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 10497.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 1063Richards Expires April 14, 2007 [Page 19] 1064 1065Internet-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 10828. References 1083 10848.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 11038.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 1119Richards Expires April 14, 2007 [Page 20] 1120 1121Internet-Draft OTP Kerberos October 2006 1122 1123 1124Author'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 1175Richards Expires April 14, 2007 [Page 21] 1176 1177Internet-Draft OTP Kerberos October 2006 1178 1179 1180Full 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 1197Intellectual 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 1222Acknowledgment 1223 1224 Funding for the RFC Editor function is provided by the IETF 1225 Administrative Support Activity (IASA). 1226 1227 1228 1229 1230 1231Richards Expires April 14, 2007 [Page 22] 1232 1233