1 2 3 4Network Working Group G. Richards 5Internet-Draft RSA Security UK Ltd. 6Expires: December 4, 2006 June 2, 2006 7 8 9 OTP Kerberos 10 draft-richards-otp-kerberos-00 11 12Status of this Memo 13 14 By submitting this Internet-Draft, each author represents that any 15 applicable patent or other IPR claims of which he or she is aware 16 have been or will be disclosed, and any of which he or she becomes 17 aware will be disclosed, in accordance with Section 6 of BCP 79. 18 19 Internet-Drafts are working documents of the Internet Engineering 20 Task Force (IETF), its areas, and its working groups. Note that 21 other groups may also distribute working documents as Internet- 22 Drafts. 23 24 Internet-Drafts are draft documents valid for a maximum of six months 25 and may be updated, replaced, or obsoleted by other documents at any 26 time. It is inappropriate to use Internet-Drafts as reference 27 material or to cite them other than as "work in progress." 28 29 The list of current Internet-Drafts can be accessed at 30 http://www.ietf.org/ietf/1id-abstracts.txt. 31 32 The list of Internet-Draft Shadow Directories can be accessed at 33 http://www.ietf.org/shadow.html. 34 35 This Internet-Draft will expire on December 4, 2006. 36 37Copyright Notice 38 39 Copyright (C) The Internet Society (2006). 40 41Abstract 42 43 The Kerberos protocol provides a framework authenticating a client 44 using the exchange of pre-authentication data. This document 45 describes the use of this framework to carry out One Time Password 46 (OTP) authentication. 47 48 49 50 51 52 53 54 55Richards Expires December 4, 2006 [Page 1] 56 57Internet-Draft OTP Kerberos June 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. OTP Hardening . . . . . . . . . . . . . . . . . . . . . . 4 67 2.4. Key Derivation . . . . . . . . . . . . . . . . . . . . . . 5 68 3. OTP Kerberos Types . . . . . . . . . . . . . . . . . . . . . . 6 69 3.1. PA-OTP-CHALLENGE . . . . . . . . . . . . . . . . . . . . . 6 70 3.2. PA-OTP-RESPONSE . . . . . . . . . . . . . . . . . . . . . 7 71 3.3. PA-OTP-CONFIRM . . . . . . . . . . . . . . . . . . . . . . 8 72 3.4. PA-ENC-PIN . . . . . . . . . . . . . . . . . . . . . . . . 9 73 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 74 5. Security Considerations . . . . . . . . . . . . . . . . . . . 9 75 5.1. Active attacks . . . . . . . . . . . . . . . . . . . . . . 9 76 5.2. Denial of service attacks . . . . . . . . . . . . . . . . 9 77 5.3. Use of Hardening Value . . . . . . . . . . . . . . . . . . 10 78 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 79 6.1. Normative References . . . . . . . . . . . . . . . . . . . 10 80 6.2. Informative References . . . . . . . . . . . . . . . . . . 11 81 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 12 82 Intellectual Property and Copyright Statements . . . . . . . . . . 13 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111Richards Expires December 4, 2006 [Page 2] 112 113Internet-Draft OTP Kerberos June 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, which generates one-time passwords that may be 122 used to authenticate a user towards some service. This document 123 describes an extensions to Kerberos V5 [RFC4120] to support pre- 124 authentication using a OTPs. 125 126 In this proposal, the KDC sends the client information on which token 127 to be used and how the OTP is to be generated. The client then uses 128 the OTP value instead of the conventional password to generate the 129 timestamp encryption key and sends the encrypted timestamp along with 130 information on the OTP to the KDC in in pre-authentication data of a 131 KRB_AS_REQ. The KDC then uses the OTP information provided by the 132 client to generate the same encryption key, allowing it to verify the 133 timestamp. 134 135 This proposal is partially based upon previous work on integrating 136 single-use authentication mechanisms into Kerberos [NeZoHo98] and 137 uses the existing password-change extensions to handle PIN change as 138 described in [RFC3244]. 139 140 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 141 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 142 document are to be interpreted as described in [RFC2119]. 143 144 << This is the first draft of this document and so is liable to 145 change significantly. >> 146 147 1482. Usage Overview 149 1502.1. Pre-Authentication 151 152 The approach uses pre-authentication data in KRB_AS_REQ, KRB_AS_REP 153 and KRB_ERROR. The client begins by sending an initial KRB_AS_REQ to 154 the KDC possibly containing pre-authentication data such as the 155 standard Kerberos password data. The KDC will then determine in an 156 implementation dependent fashion whether OTP authentication is 157 required and if it is, it will respond with a KRB_ERROR message with: 158 159 o An error code of KDC_ERR_PREAUTH_REQUIRED 160 o An e-data field containing PA-DATA with a PA-OTP-CHALLENGE. 161 162 The PA-OTP-CHALLENGE contains information on the type of OTP required 163 and the token to be used to generate it. The client uses this 164 165 166 167Richards Expires December 4, 2006 [Page 3] 168 169Internet-Draft OTP Kerberos June 2006 170 171 172 information to locate the token and generate the OTP which is used, 173 instead of the user's password, to generate an encryption key and 174 encrypt a timestamp. 175 176 The encrypted timestamp is then sent to the KDC as pre-auth data in a 177 second KRB_AS_REQ in the standard manner but additional information 178 on the OTP and the key derivation is also sent in a PA-OTP-RESPONSE. 179 180 The KDC then uses the information in the PA-OTP-RESPONSE to generate 181 the same key as the client allowing it to validate the encrypted 182 timestamp. If the validation succeeds then the KDC returns the TGT 183 in a KRB_AS_REP. 184 1852.2. PIN Change 186 187 If, following successful validation of a PA-OTP-RESPONSE in a 188 KRB_AS_REQ, the KDC requires that the user changes their PIN then it 189 will return PA-DATA of type PA-OTP-PIN-CHANGE in the KRB_AS_REP. 190 This pre-auth data can be used to return a new PIN to the user if the 191 KDC has updated the PIN or to indicate to the user that they must 192 change their PIN. 193 194 In the latter case, user PIN change shall be handled by a PIN change 195 service supporting the ChangePasswdData in a KRB_AP_REQ as described 196 in [RFC3244]. If such a user PIN change is required then the KDC 197 SHALL return a TGT in the KRB_AS_REP but it is RECOMMENDED that it 198 only issues tickets for the PIN change service until the PIN has been 199 changed. 200 2012.3. OTP Hardening 202 203 Since OTPs may be relatively short, it is important to slow down an 204 attacker sufficiently so that it is economically unattractive to 205 brute-force search for an OTP given an observed OTP-Kerberos 206 exchange. One way to do this is to derive the Kerberos user key from 207 the OTP instead of the password in the same manner as described in 208 [RFC3962] but to use a high number of iterated hashes of the OTP in 209 the PBKDF2 key derivation function from [RFC2898]. Another is for 210 the client to include a hardening value unknown to the attacker in 211 the key derivation. 212 213 Unlike the a traditional "salt" value which is normally sent in the 214 clear, this hardening value will instead be transferred from the KDC 215 to the client in encrypted form. When the client receives a PA-OTP- 216 CHALLENGE from a KDC it will search for an associated hardening 217 value. If it finds a value then it will use it in the key derivation 218 as specified in Section 2.4. 219 220 221 222 223Richards Expires December 4, 2006 [Page 4] 224 225Internet-Draft OTP Kerberos June 2006 226 227 228 The use of a hardening value will influence the iteration count used 229 by the client in the random-to-key calculation. The value sent by 230 the KDC in the s2kparams of the ETYPE-INFO2 pre-authentication type 231 specifies the value used if there is no hardening value stored on the 232 client for the server. If the client has a hardening value stored 233 for the server, then the iteration count of 1 SHOULD be used as the 234 security of the scheme is provided through the hardening value. If 235 the client does not have a hardening value stored, then it SHOULD set 236 the iteration count in the key derivation to the maximum value that 237 is both supported by the KDC and permitted by any local policy 238 constraints. The identifier of any hardening value used and the 239 value of the iteration count are sent by the client to the KDC in a 240 PA-OTP_RESPONSE included in the KRB_AS_REQ. 241 242 When the KDC receives a PA-OTP-RESPONSE, it will use the identifier 243 to locate the hardening value. If a hardening value is found then it 244 will be used along with the iterationCount to generate the user key. 245 If the hardening value identifier is omitted then only the 246 iterationCount SHALL be used. If a hardening value identifier is 247 included but the corresponding value could not be found then the KDC 248 SHALL respond with a KDC_ERR_PREAUTH_REQUIRED error as described 249 above but SHALL set the noHardening flag in the PA-OTP-CHALLENGE. 250 251 The hardening value to be used by the client in the next KRB_AS_REQ 252 will be sent by the KDC in a PA-OTP-CONFIRM contained in the 253 KRB_AS_REP. The inclusion of a PA-OTP-CONFIRM is only REQUIRED if 254 the client did not use a hardening value to generate the timestamp 255 encryption key. However, it is RECOMMENDED that it be included in 256 all such responses to ensure that a new hardening value is used in 257 all client requests. 258 2592.4. Key Derivation 260 261 The encryption key used to encrypt the time stamp SHALL be generated 262 using the PBKDF2 password-based key derivation function as specified 263 in [RFC3962]. Conformant KDCs MUST support at least one of the 264 encryption types aes128-cts-hmac-sha1-96 and aes256-cts-hmac-sha1-96 265 defined in [RFC3962] and MUST return PA-ETYPE-INFO2 pre- 266 authentication types with the corresponding etype values. 267 268 In order to use the hardening scheme described in Section 2.3, the 269 information provided by the KDC in the ETYPE-INFO2 pre-authentication 270 type SHALL be used by the client as follows: 271 272 o If the client does not have a hardening value associated with the 273 KDC then the number of iterations specified in the s2kparams SHALL 274 be used. If the client has a hardening value then an iteration 275 count of 1 SHALL be used instead. 276 277 278 279Richards Expires December 4, 2006 [Page 5] 280 281Internet-Draft OTP Kerberos June 2006 282 283 284 o The salt value SHALL have the hardening value concatenated if 285 there is one associated with the KDC. 286 287 tkey = random-to-key(PBKDF2(OTP, salt|hardening, 288 iteration_count, key_length)) 289 key = DK(tkey, "kerberos") 290 291 2923. OTP Kerberos Types 293 2943.1. PA-OTP-CHALLENGE 295 296 This is a pre-authentication type sent by the KDC to the client in a 297 KRB_ERROR. It contains information for the client on how to generate 298 an OTP and how to use the OTP in the generation of the key used to 299 encrypt the pre-authentication data. 300 301 PA-OTP-CHALLENGE ::= SEQUENCE { 302 flags ChallengeFlags 303 otp-challenge[0] OCTET STRING OPTIONAL, 304 otp-length [1] INTEGER OPTIONAL, 305 otp-service [2] UTF8String OPTIONAL, 306 otp-keyID [3] OCTET STRING OPTIONAL, 307 otp-algID [4] INTEGER OPTIONAL 308 } 309 ChallengeFlags ::= KerberosFlags 310 -- noHardening (0), 311 312 noHardening 313 If the noHardening flag is set then the client MUST NOT use any 314 stored hardening value in the key derivation. Instead, it MUST 315 use the iteration count provided by the KDC. 316 otp-challenge 317 The otp-challenge is used by the KDC to send a challenge value for 318 use in the OTP calculation. The challenge is an optional octet 319 string that SHOULD be uniquely generated for each request it is 320 present in, and SHOULD be eight octets or longer when present. 321 When the challenge is not present, the OTP will be calculated on 322 the current token state only. The client MAY ignore a provided 323 challenge if and only if the OTP token the client is interacting 324 with is not capable of including a challenge in the OTP 325 calculation. In this case, KDC policies will determine whether to 326 accept a provided OTP value or not. 327 328 329 330 331 332 333 334 335Richards Expires December 4, 2006 [Page 6] 336 337Internet-Draft OTP Kerberos June 2006 338 339 340 otp-length 341 The otp-length is used by the KDC to specify the desired length of 342 the generated OTP. 343 344 otp-service 345 An identifier of the service supported by the KDC. This value can 346 be used by the client to locate information such as the hardening 347 value and OTP key to use. 348 349 otp-keyID 350 The identifier of the OTP key to be used in the OTP calculation. 351 If this value is not present then the client SHOULD use other 352 values such as the otp-service and otp-algiID to locate the 353 appropriate key. 354 otp-algID 355 The identifier of the algorithm to use when generating the OTP. 356 3573.2. PA-OTP-RESPONSE 358 359 This is a pre-authentication type sent by the client to the KDC in a 360 KRB_AS_REQ containing the encrypted pre-authentication data. It 361 contains information on the OTP used and how the key was generated 362 that encrypts the pre-authentication data. This information will 363 then allow the KDC to generate the same key and validate the pre- 364 authentication data. 365 366 PA-OTP-RESPONSE ::= SEQUENCE { 367 iterationCount[0] INTEGER OPTIONAL, 368 identifier [1] OCTET STRING OPTIONAL, 369 otp-challenge [2] OCTET STRING OPTIONAL, 370 otp-time [2] KerberosTime OPTIONAL, 371 otp-counter [3] OCTET STRING OPTIONAL, 372 otp-format [4] OTPFormat OPTIONAL, 373 otp-keyID [5] OCTET STRING OPTIONAL 374 } 375 376 OTPFormat ::= INTEGER { 377 decimal(0), 378 hexadecimal(1), 379 alphanumeric(2), 380 binary(3) 381 } 382 383 iterationCount 384 The actual value of the iteration count used by the client in the 385 key derivation. If omitted then the specified or default 386 iteration count is used. If present then it will generally be 387 less than the value used in the string-to-key parameters if a 388 389 390 391Richards Expires December 4, 2006 [Page 7] 392 393Internet-Draft OTP Kerberos June 2006 394 395 396 hardening value is used. 397 398 identifier 399 An octet string identifying the hardening value used by the client 400 in the key derivation. If omitted then no hardening was used. 401 402 otp-challenge 403 Value used by the client to send the challenge used in the OTP 404 calculation. It MUST be sent to the KDC if and only if the value 405 would otherwise be unknown to the KDC. For example, the token or 406 client modified or generated challenge. 407 408 otp-time 409 Value used by the client to send the time used in the OTP 410 calculation. 411 412 otp-counter 413 The counter value used in the OTP calculation. Use of this 414 element is OPTIONAL but it MAY be used by a client to simplify the 415 OTP calculations of the KDC to contain the counter value as 416 reported by the OTP token. 417 418 otp-format 419 The format of the generated OTP. 420 421 otp-keyID 422 The identifier of the OTP key used. 423 4243.3. PA-OTP-CONFIRM 425 426 Pre-authentication type returned by the KDC in a KRB_AS_REP if the 427 client requires a new hardening value. 428 429 PA-OTP-CONFIRM ::= SEQUENCE { 430 identifier OCTET STRING, 431 encHardeningValue EncryptedData -- EncHardeningValue 432 } 433 EncHardeningValue ::= OCTET STRING SIZE (16..MAX) 434 435 identifier 436 An octet string identifying the hardening value used by the client 437 in the key derivation. 438 439 encHardeningValue 440 The hardening value that the client SHOULD use in future key 441 derivations. It is encrypted as described in section 5.2.9 of 442 [RFC4120] using the current user key as derived by the KDC from 443 the OTP. 444 445 446 447Richards Expires December 4, 2006 [Page 8] 448 449Internet-Draft OTP Kerberos June 2006 450 451 4523.4. PA-ENC-PIN 453 454 Pre-authentication type returned by the KDC in a KRB_AS_REP if the 455 user must change their PIN or if the user's PIN has been changed. 456 457 PA-ENC-PIN ::= EncryptedData -- PA-ENC-PIN-ENC 458 PA-ENC-PIN-ENC ::= SEQUENCE { 459 flags PinFlags 460 pin [0] UTF8String OPTIONAL 461 minLength [1] INTEGER OPTIONAL 462 maxLength [2] INTEGER OPTIONAL 463 } 464 465 PinFlags ::= KerberosFlags 466 -- systemSetPin (0) 467 468 If the systemSetPin flag is set then the pin field MUST be present 469 and the presence of this pre-auth type indicates that the user's PIN 470 has been changed to the value contained within the pin field. 471 472 If the pin field is omitted then this pre-auth type indicates that 473 the user must change their PIN using the PIN change service and that 474 the KDC will only issue tickets for the PIN change service until the 475 PIN has been changed. 476 477 If the pin field is present and the systemPin flag is not set then 478 the user must change their PIN subject to the restrictions of the 479 other fields or may alternatively use the returned PIN. 480 481 4824. IANA Considerations 483 484 A registry may be required for the otp-AlgID values as introduced in 485 Section 3.1. No other IANA actions are anticipated. 486 487 4885. Security Considerations 489 4905.1. Active attacks 491 492 <<TBD: Could an attacker change the iteration count in the PA- 493 ETYPE_INFO2? >> 494 4955.2. Denial of service attacks 496 497 An active attacker may replace the iteration count value in the PA- 498 OTP-RESPONSE sent by the client to slow down an authentication 499 server. Authentication servers SHOULD protect against this, e.g. by 500 501 502 503Richards Expires December 4, 2006 [Page 9] 504 505Internet-Draft OTP Kerberos June 2006 506 507 508 disregarding PA-OTP-RESPONSE elements with an iteration count value 509 higher than some pre- or dynamically- (depending on load) set number. 510 5115.3. Use of Hardening Value 512 513 As described in Section 2.3, the use of a hardening value will slow 514 down an attacker's search for a matching OTP. The ability to 515 transfer a hardening value in encrypted form from the KDC to the 516 client means that, even though there may be an initial computational 517 cost for the KDC to authenticate the user due to a high iteration 518 count, subsequent authentications will be efficient, while at the 519 same time more secure, since a pre-shared, 128 bits long, hardening 520 value will not be easily found by an attacker. 521 522 If a client does not have a hardening value for a KDC then it will 523 have to generate the user key using only an iteration count. An 524 attacker observing such a KRB_AS_REQ may, depending on available 525 resources, be able to successfully attack that request. Once the 526 correct OTP has been found, eavesdropping on the KDC's PA_OTP_CONFIRM 527 will potentially give the attacker access to the server-provided 528 hardening value. For this reason, initial exchanges with KDC servers 529 SHOULD occur in a secure environment, and if not, the iteration count 530 MUST be significantly higher than for messages where a pre-shared 531 hardening value is used. The lifetime of this value must also be 532 calculated with this in mind. Finally, the value MUST be securely 533 stored by the client and the KDC, associated with the user. 534 535 5366. References 537 5386.1. Normative References 539 540 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 541 Requirement Levels", BCP 14, RFC 2119, March 1997. 542 543 [RFC2898] Kaliski, B., "PKCS #5: Password-Based Cryptography 544 Specification Version 2.0", RFC 2898, September 2000. 545 546 [RFC3244] Swift, M., Trostle, J., and J. Brezak, "Microsoft Windows 547 2000 Kerberos Change Password and Set Password Protocols", 548 RFC 3244, February 2002. 549 550 [RFC3962] Raeburn, K., "Advanced Encryption Standard (AES) 551 Encryption for Kerberos 5", RFC 3962, February 2005. 552 553 [RFC4120] Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The 554 Kerberos Network Authentication Service (V5)", RFC 4120, 555 July 2005. 556 557 558 559Richards Expires December 4, 2006 [Page 10] 560 561Internet-Draft OTP Kerberos June 2006 562 563 5646.2. Informative References 565 566 [NeZoHo98] 567 Neuman, C., Zorn, G., Trostle, J., and K. Horstein, 568 "Integrating Single-use Authentication Mechanisms with 569 Kerberos", draft-ietf-cat-kerberos-password-04 (work in 570 progress), November 1998. 571 572 573 574 575 576 577 578 579 580 581 582 583 584 585 586 587 588 589 590 591 592 593 594 595 596 597 598 599 600 601 602 603 604 605 606 607 608 609 610 611 612 613 614 615Richards Expires December 4, 2006 [Page 11] 616 617Internet-Draft OTP Kerberos June 2006 618 619 620Author's Address 621 622 Gareth Richards 623 RSA Security UK Ltd. 624 RSA House 625 Western Road 626 Bracknell, Berkshire RG12 1RT 627 UK 628 629 Email: grichards@rsasecurity.com 630 631 632 633 634 635 636 637 638 639 640 641 642 643 644 645 646 647 648 649 650 651 652 653 654 655 656 657 658 659 660 661 662 663 664 665 666 667 668 669 670 671Richards Expires December 4, 2006 [Page 12] 672 673Internet-Draft OTP Kerberos June 2006 674 675 676Intellectual Property Statement 677 678 The IETF takes no position regarding the validity or scope of any 679 Intellectual Property Rights or other rights that might be claimed to 680 pertain to the implementation or use of the technology described in 681 this document or the extent to which any license under such rights 682 might or might not be available; nor does it represent that it has 683 made any independent effort to identify any such rights. Information 684 on the procedures with respect to rights in RFC documents can be 685 found in BCP 78 and BCP 79. 686 687 Copies of IPR disclosures made to the IETF Secretariat and any 688 assurances of licenses to be made available, or the result of an 689 attempt made to obtain a general license or permission for the use of 690 such proprietary rights by implementers or users of this 691 specification can be obtained from the IETF on-line IPR repository at 692 http://www.ietf.org/ipr. 693 694 The IETF invites any interested party to bring to its attention any 695 copyrights, patents or patent applications, or other proprietary 696 rights that may cover technology that may be required to implement 697 this standard. Please address the information to the IETF at 698 ietf-ipr@ietf.org. 699 700 701Disclaimer of Validity 702 703 This document and the information contained herein are provided on an 704 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 705 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 706 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 707 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 708 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 709 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 710 711 712Copyright Statement 713 714 Copyright (C) The Internet Society (2006). This document is subject 715 to the rights, licenses and restrictions contained in BCP 78, and 716 except as set forth therein, the authors retain all their rights. 717 718 719Acknowledgment 720 721 Funding for the RFC Editor function is currently provided by the 722 Internet Society. 723 724 725 726 727Richards Expires December 4, 2006 [Page 13] 728 729