1 2 3 4Network Working Group G. Richards 5Internet-Draft RSA, The Security Division of EMC 6Intended status: Standards Track July 14, 2008 7Expires: January 15, 2009 8 9 10 OTP Pre-authentication 11 draft-ietf-krb-wg-otp-preauth-05 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 January 15, 2009. 37 38Abstract 39 40 The Kerberos protocol provides a framework authenticating a client 41 using the exchange of pre-authentication data. This document 42 describes the use of this framework to carry out One Time Password 43 (OTP) authentication. 44 45 46 47 48 49 50 51 52 53 54 55Richards Expires January 15, 2009 [Page 1] 56 57Internet-Draft OTP Pre-authentication July 2008 58 59 60Table of Contents 61 62 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 63 1.1. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 3 64 1.2. Overall Design . . . . . . . . . . . . . . . . . . . . . . 3 65 1.3. Conventions Used in this Document . . . . . . . . . . . . 4 66 2. Usage Overview . . . . . . . . . . . . . . . . . . . . . . . . 4 67 2.1. OTP Mechanism Support . . . . . . . . . . . . . . . . . . 4 68 2.2. Pre-Authentication . . . . . . . . . . . . . . . . . . . . 4 69 2.3. PIN Change . . . . . . . . . . . . . . . . . . . . . . . . 5 70 2.4. Re-Synchronization . . . . . . . . . . . . . . . . . . . . 6 71 3. Pre-Authentication Protocol Details . . . . . . . . . . . . . 6 72 3.1. Initial Client Request . . . . . . . . . . . . . . . . . . 6 73 3.2. KDC Challenge . . . . . . . . . . . . . . . . . . . . . . 6 74 3.3. Client Response . . . . . . . . . . . . . . . . . . . . . 7 75 3.4. Verifying the pre-auth Data . . . . . . . . . . . . . . . 9 76 3.5. Confirming the Reply Key Change . . . . . . . . . . . . . 10 77 3.6. Reply Key Generation . . . . . . . . . . . . . . . . . . . 11 78 4. OTP Kerberos Message Types . . . . . . . . . . . . . . . . . . 13 79 4.1. PA-OTP-CHALLENGE . . . . . . . . . . . . . . . . . . . . . 13 80 4.2. PA-OTP-REQUEST . . . . . . . . . . . . . . . . . . . . . . 15 81 4.3. PA-OTP-CONFIRM . . . . . . . . . . . . . . . . . . . . . . 18 82 4.4. PA-OTP-PIN-CHANGE . . . . . . . . . . . . . . . . . . . . 19 83 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 84 6. Security Considerations . . . . . . . . . . . . . . . . . . . 19 85 6.1. Man-in-the-Middle . . . . . . . . . . . . . . . . . . . . 19 86 6.2. Reflection . . . . . . . . . . . . . . . . . . . . . . . . 20 87 6.3. Replay . . . . . . . . . . . . . . . . . . . . . . . . . . 20 88 6.4. Brute Force Attack . . . . . . . . . . . . . . . . . . . . 20 89 6.5. FAST Facilities . . . . . . . . . . . . . . . . . . . . . 20 90 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 21 91 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 21 92 8.1. Normative References . . . . . . . . . . . . . . . . . . . 21 93 8.2. Informative References . . . . . . . . . . . . . . . . . . 21 94 Appendix A. ASN.1 Module . . . . . . . . . . . . . . . . . . . . 22 95 Appendix B. Examples of OTP Pre-Authentication Exchanges . . . . 24 96 B.1. Four Pass Authentication . . . . . . . . . . . . . . . . . 24 97 B.2. Two Pass Authentication . . . . . . . . . . . . . . . . . 27 98 B.3. Pin Change . . . . . . . . . . . . . . . . . . . . . . . . 29 99 B.4. Resynchronization . . . . . . . . . . . . . . . . . . . . 30 100 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 32 101 Intellectual Property and Copyright Statements . . . . . . . . . . 33 102 103 104 105 106 107 108 109 110 111Richards Expires January 15, 2009 [Page 2] 112 113Internet-Draft OTP Pre-authentication July 2008 114 115 1161. Introduction 117 1181.1. Scope 119 120 This document describes a FAST [ZhHa07] factor that allows One-Time 121 Password (OTP) values to be used in the Kerberos V5 [RFC4120] pre- 122 authentication in a manner that does not require use of the user's 123 Kerberos password. The system is designed to work with different 124 types of OTP algorithms such as time-based OTPs [RFC2808], counter- 125 based tokens [RFC4226], challenge-response and [RFC2289] type 126 systems. It is also designed to work with tokens that are 127 electronically connected to the user's computer via means such as a 128 USB interface. 129 130 This FAST factor provides the following facilities (as defined in 131 [ZhHa07]): client-authentication, replacing-reply-key and KDC- 132 authentication. It does not provide the strengthening-reply-key 133 facility. 134 135 This proposal is partially based upon previous work on integrating 136 single-use authentication mechanisms into Kerberos [HoReNeZo04] and 137 allows for the use of the existing password-change extensions to 138 handle PIN change as described in [RFC3244]. 139 1401.2. Overall Design 141 142 This proposal supports 4-pass and 2-pass variants. In the 4-pass 143 system, the client sends the KDC an initial AS-REQ and the KDC 144 responds with a KRB-ERROR containing padata that includes a random 145 nonce. The client then encrypts the nonce and returns it along with 146 its own random value to the KDC in a second AS-REQ. Finally, the KDC 147 returns the client's random value encrypted within the padata of the 148 AS-REP. In the 2-pass variant, the client encrypts a timestamp 149 rather than a nonce from the KDC and the encrypted data is sent to 150 the KDC in the initial AS-REQ. This variant can be used in cases 151 where the client can determine in advance that OTP pre-authentication 152 is supported by the KDC and which OTP key should be used. 153 154 In both systems, in order to create the message sent to the KDC, the 155 client must generate the OTP value and three keys: the standard Reply 156 Key, a key to encrypt the data sent to the KDC and a final key to 157 decrypt the KDC's reply. In most cases, the OTP value will be used 158 in the key generation but in order to support algorithms where the 159 KDC cannot obtain the value (e.g. [RFC2289]), the system also 160 supports the option of including the OTP value in the request along 161 with the encrypted nonce. In addition, in order to support 162 situations where the KDC is unable to obtain the plaintext OTP value, 163 the system also supports the use of hashed OTP values in the key 164 165 166 167Richards Expires January 15, 2009 [Page 3] 168 169Internet-Draft OTP Pre-authentication July 2008 170 171 172 derivation. 173 174 The message from the client to the KDC is sent within the encrypted 175 data provided by the FAST padata type of the AS-REQ. The KDC then 176 obtains the OTP value, generates the same keys and verifies the pre- 177 authentication data by decrypting the nonce. If the verification 178 succeeds then it confirms knowledge of the Reply Key by returning the 179 client's nonce encrypted under one of the generated keys within the 180 encrypted part of the FAST padata of the AS-REP. 181 1821.3. Conventions Used in this Document 183 184 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 185 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 186 document are to be interpreted as described in [RFC2119]. 187 188 This document assumes familiarity with the Kerberos preauthentication 189 framework [ZhHa07] and so freely uses terminology and notation from 190 this document. 191 192 The word padata is used as shorthand for pre-authentication data. 193 194 1952. Usage Overview 196 1972.1. OTP Mechanism Support 198 199 As described above, this document describes a generic system for 200 supporting different OTP mechanisms in Kerberos pre-authentication. 201 However, to ensure interoperability, all implementations of this 202 specification SHOULD provide a mechanism for OTP mechanism support to 203 be added or removed. 204 2052.2. Pre-Authentication 206 207 The approach uses pre-authentication data in AS-REQ, AS-REP and KRB- 208 ERROR messages. 209 210 In the 4-pass system, the client begins by sending an initial AS-REQ 211 to the KDC that may contain pre-authentication data such as the 212 standard Kerberos password data. The KDC will then determine, in an 213 implementation dependent fashion, whether OTP authentication is 214 required and if it is, it will respond with a KRB-ERROR message 215 containing a PA-OTP-CHALLENGE in the PA-DATA. 216 217 The PA-OTP-CHALLENGE will contain a KDC generated nonce, an 218 encryption type, an optional list of hash algorithm identifiers, an 219 optional iteration count and optional information on how the OTP 220 221 222 223Richards Expires January 15, 2009 [Page 4] 224 225Internet-Draft OTP Pre-authentication July 2008 226 227 228 should be generated by the client. The client will then generate the 229 OTP value, its own nonce and two keys: a Client Key to encrypt the 230 KDC's nonce and a Reply Key used to decrypt the KDC's reply. 231 232 As described in Section 3.6, these keys will be generated from the 233 Armor Key (defined in [ZhHa07]) and the OTP value unless the OTP 234 algorithm does not allow the KDC to obtain the OTP value. If hash 235 algorithm identifiers were included in the PA-OTP-CHALLENGE then the 236 client will use the hash of the OTP value rather than the plaintext 237 value in the key generation. 238 239 The generated Client Key will be used to encrypt the nonce received 240 from the KDC using the specified encryption type. The encrypted 241 value, a random nonce generated by the client along with optional 242 information on how the OTP was generated are then sent to the KDC in 243 a PA-OTP-REQUEST element encrypted within the armored-data of a PA- 244 FX-FAST-REQUEST PA-DATA element of a second AS-REQ. 245 246 In the 2-pass system, the client sends the PA-OTP-REQUEST in the 247 initial AS-REQ instead of sending it in response to a PA-OTP- 248 CHALLENGE returned by the KDC. Since no challenge is received from 249 the KDC, the client includes an encrypted timestamp in the request 250 rather than the encrypted KDC nonce. 251 252 In both cases, on receipt of a PA-OTP-REQUEST, the KDC generate the 253 same keys as the client, and use the generated Client Key to verify 254 the pre-authentication by decrypting the encrypted data sent by the 255 client (either nonce or timestamp). If the validation succeeds then 256 the KDC will authenticate itself to the client and confirm that the 257 Reply Key has been updated by encrypting the client's nonce under the 258 Reply Key and returning the encrypted value in the encData of a PA- 259 OTP-CONFIRM. The PA-OTP-CONFIRM is encrypted within the armored-data 260 of a PA-FX-FAST-REPLY PA-DATA element of the AS-REP as described in 261 [ZhHa07]. 262 2632.3. PIN Change 264 265 If, following successful validation of a PA-OTP-REQUEST in a AS-REQ, 266 the KDC requires that the user changes their PIN then it will include 267 a PA-OTP-PIN-CHANGE element in the armored data of the PA-FX-FAST- 268 REPLY PA-DATA element of the AS-REP. This data can be used to return 269 a new PIN to the user if the KDC has updated the PIN or to indicate 270 to the user that they must change their PIN. 271 272 In the latter case, it is recommended that user PIN change be handled 273 by a PIN change service supporting the ChangePasswdData in a AP-REQ 274 as described in [RFC3244]. If a user PIN for OTP is required to 275 change and such a service is used then the KDC MUST NOT return a TGT 276 277 278 279Richards Expires January 15, 2009 [Page 5] 280 281Internet-Draft OTP Pre-authentication July 2008 282 283 284 when the user is authenticated using this PIN. The KDC SHOULD return 285 a service ticket to the PIN change service when the existing PIN is 286 required to change, in order for the client to compute an AP-REQ 287 according to [RFC3244]. In order to complicate stealing service 288 tickets intended for the PIN change service (and the corresponding 289 session keys), the lifetime of the PIN-change service tickets should 290 be just long enough to complete the PIN change, regardless whether 291 the exiting PIN needs to be changed or not. A 1-minute lifetime is 292 RECOMMENED. This way the PIN change service can effectively force 293 the user to present the existing PIN in order to change to use a new 294 PIN. 295 2962.4. Re-Synchronization 297 298 It is possible with time and event-based tokens that the OTP server 299 will lose synchronization with the current token state. If, when 300 processing a PA-OTP-REQUEST, the pre-authentication validation fails 301 for this reason then the KDC SHALL return a KRB-ERROR message 302 containing a PA-OTP-CHALLENGE in the PA-DATA with the "nextOTP" flag 303 set. If this flag is set then the client MUST re-try the 304 authentication using the OTP for the token "state" after that used in 305 the failed authentication attempt. 306 307 3083. Pre-Authentication Protocol Details 309 3103.1. Initial Client Request 311 312 In the 4-pass mode, the client begins by sending an initial AS-REQ 313 possibly containing other pre-authentication data. If the KDC 314 determines that OTP-based pre-authentication is required and the 315 request does not contain a PA-OTP-REQUEST then it will respond as 316 described in Section 3.2. 317 318 If the client has all the necessary information, it MAY use the 319 2-pass system by constructing a PA-OTP-REQUEST as described in 320 Section 3.3 and including it in the initial request. 321 3223.2. KDC Challenge 323 324 If the user is required to authenticate using an OTP then the KDC 325 SHALL respond to the initial AS-REQ with a KRB-ERROR containing: 326 327 o An error code of KDC_ERR_PREAUTH_REQUIRED 328 329 o An e-data field containing PA-DATA with a PA-OTP-CHALLENGE. 330 331 The PA-OTP-CHALLENGE SHALL contain a random nonce value to be 332 333 334 335Richards Expires January 15, 2009 [Page 6] 336 337Internet-Draft OTP Pre-authentication July 2008 338 339 340 returned encrypted in the client response and the encryption type to 341 be used by the client. 342 343 If the OTP is to be generated using an server generated challenge 344 then the value of the challenge SHALL be included in the otp- 345 challenge field. If the OTP is to be generated by combining the 346 challenge with the token's current state (e.g. time) then the 347 "combine" flag SHALL be set. 348 349 The KDC MAY use the otp-service to identify the service provided by 350 the KDC in order to assist the client in locating the OTP token to be 351 used. For example, this field could be used when a client has 352 multiple OTP tokens from different servers to identify the KDC. 353 Similarly, if the KDC can determine which OTP token key is the be 354 used, then the otp-keyID field MAY be used to pass that value to the 355 client. 356 357 The otp-algID field MAY be used to identify the algorithm that should 358 be used in the OTP calculation. For example, it could be used when a 359 user has been issued with multiple tokens of different types. 360 361 In order to support connected tokens that can generate OTP values of 362 varying length, the KDC MAY include the desired length of the OTP in 363 the otp-length field. 364 365 In order to support cases where the KDC cannot obtain plaintext 366 values for the OTPs, the challenge MAY also contain a sequence of one 367 way hash function algorithm identifiers and a minimum value of the 368 iteration count to be used by the client when hashing the OTP value. 369 3703.3. Client Response 371 372 The client response SHALL be sent to the KDC as a PA-OTP-REQUEST 373 included within the enc-fast-req of a PA-FX-FAST-REQUEST encrypted 374 under the current Armor Key as described in [ZhHa07]. 375 376 In order to generate its response, the client must generate an OTP 377 value. The OTP value MUST be based on the parameters in the KDC 378 challenge if present and the response SHOULD include any information 379 on the generated OTP value reported by the OTP token 380 381 If the "nextOTP" flag is set in the PA-OTP-CHALLENGE, then the client 382 MUST generate the OTP value in the next token state that that used in 383 the previous PA-OTP-REQUEST. The "nextOTP" flag must also be set in 384 the PA-OTP-REQUEST. 385 386 The otp-time and otp-counter fields MAY be used to return the time 387 and counter values used by the token. The otp-format field MAY be 388 389 390 391Richards Expires January 15, 2009 [Page 7] 392 393Internet-Draft OTP Pre-authentication July 2008 394 395 396 used to report the format of the generated OTP. This field SHOULD be 397 used if a token can generate OTP values in multiple formats. The 398 otp-algID field MAY be used by the client to report the algorithm 399 used in the OTP calculation and the otp-keyID MAY be used to report 400 the identifier of the OTP token key used. 401 402 If an otp-challenge is present in the PA-OTP-CHALLENGE then the OTP 403 value MUST be generated based on a challenge if the token is capable 404 of accepting a challenge. The client MAY ignore the provided 405 challenge if and only if the token is not capable of including a 406 challenge in the OTP calculation. If the "combine" flag is not set 407 in the PA-OTP-CHALLENGE then the OTP SHALL be calculated based only 408 the challenge and not the internal state (e.g. time or counter) of 409 the token. If the "combine" flag is set then the OTP SHALL be 410 calculated using both the internal state and the provided challenge. 411 If the flag is set but otp-challenge is not present then the client 412 SHALL regard the request as invalid. 413 414 If the OTP value was generated by a challenge not sent by the KDC 415 then the challenge SHALL be included in the otp-challenge of the PA- 416 OTP-RESPONSE. If the OTP was generated by combining a challenge 417 (either received from the KDC or generated by the client) with the 418 token state then the "combine" flag SHALL be set in the PA-OTP- 419 RESPONSE. 420 421 The client MUST derive the Client Key and Reply Key as described in 422 Section 3.6. In order to support OTP algorithms where the KDC cannot 423 obtain the OTP value, the client MAY include the generated value in 424 the otp-value field of the response. However, the client MUST NOT 425 include the OTP value in the response unless it is allowed by the 426 algorithm profile. If it is included then the OTP value MUST NOT be 427 used in the key derivation. 428 429 If the client used hashed OTP values in the key derivation process 430 then it MUST include the hash algorithm and iteration count used in 431 the hashAlg and iterationCount fields of the PA-OTP-REQUEST. These 432 fields MUST NOT be included if hashed OTP values were not used. It 433 is RECOMMENDED that the iteration count used by the client be chosen 434 in such a way that it is computationally infeasible/unattractive for 435 an attacker to brute-force search for the given OTP within the 436 lifetime of that OTP. 437 438 If the PA-OTP-REQUEST is being sent in response to a PA-OTP-CHALLENGE 439 that contained hash algorithm identifiers and the OTP value is to be 440 used in the key derivation then the client MUST use hashed OTP values 441 and MUST select the first algorithm from the list that it supports. 442 However, if the algorithm identifiers do not conform to local policy 443 restrictions then the authentication attempt MUST NOT proceed. If 444 445 446 447Richards Expires January 15, 2009 [Page 8] 448 449Internet-Draft OTP Pre-authentication July 2008 450 451 452 the iteration count specified in the PA-OTP-CHALLENGE does not 453 conform to local policy then the client MAY use a higher value but 454 MUST NOT use a lower value. That is, the value in the KDC challenge 455 is a minimum value. 456 457 The generated Client Key is used by the client to encrypt data to be 458 included in the encData of the response to allow the KDC to 459 authenticate the user. The key usage for this encryption is 460 KEY_USAGE_OTP_REQUEST. 461 462 o If the response is being generated in response to a KDC challenge 463 then client encrypts a PA-OTP-ENC-REQUEST containing the value of 464 nonce from the corresponding challenge using the encryption type 465 specified in the challenge. 466 467 o If the response is not in response to a KDC challenge then the 468 client encrypts a PA-ENC-TS-ENC containing the current time as in 469 the encrypted timestamp pre-authentication mechanism [RFC4120]. 470 471 If the client is working in 2-pass mode and so is not responding to 472 an initial KDC challenge then the values of the iteration count, hash 473 algorithms and encryption type cannot be obtained from that 474 challenge. The client SHOULD use any values obtained from a previous 475 PA-OTP-CHALLENGE or, if no values are available, it MAY use initial 476 configured values. 477 478 Finally, the client generates a random value to include in the nonce 479 of the response. This value will then be returned encrypted by the 480 KDC. 481 4823.4. Verifying the pre-auth Data 483 484 The KDC validates the pre-authentication data by generating the same 485 keys as the client and using the generated Client Key to decrypt the 486 value of encData from the PA-OTP-REQUEST. 487 488 If the otp-value field is included in the PA-OTP-REQUEST then the KDC 489 MUST use that value in the key generation. Otherwise, the KDC will 490 need to generate or obtain the value. 491 492 If the otp-challenge field is present, then the OTP was calculated 493 using that challenge. If the "combine" flag is also set, then the 494 OTP was calculated using the challenge and the token's current state. 495 496 It is RECOMMENDED that the KDC acts upon the values of otp-time, otp- 497 counter, otp-format, otp-algID and otp-keyID if they are present in 498 the PA-OTP-REQUEST. If the KDC receives a request containing these 499 values but cannot act upon theme then they MAY be ignored. 500 501 502 503Richards Expires January 15, 2009 [Page 9] 504 505Internet-Draft OTP Pre-authentication July 2008 506 507 508 The KDC generates the Client Key and Reply Key as described in 509 Section 3.6 from the OTP value using the hash algorithm and iteration 510 count if present in the PA-OTP-REQUEST. However, the client 511 authentication MUST fail if the KDC requires hashed OTP values and 512 the hashAlg field was not present in the PA-OTP-REQUEST, if the hash 513 algorithm identifier or the value of iterationCount included in the 514 PA-OTP-REQUEST do not conform to local KDC policy or if the value of 515 the iterationCount is less than that specified in the PA-OTP- 516 CHALLENGE. 517 518 The generated Client Key is then used to decrypt the encData from the 519 PA-OTP-REQUEST. If the client response was sent as a result of a PA- 520 OTP-CHALLENGE then decrypted data will be a PA-OTP-ENC-REQUEST and 521 the client authentication MUST fail if the nonce value from the PA- 522 OTP-ENC-REQUEST is not the same as the nonce value sent in the PA- 523 OTP-CHALLENGE. If the response was not sent as a result of a PA-OTP- 524 CHALLENGE then the decrypted value will be a PA-ENC-TS-ENC and the 525 authentication process will be the same as with standard encrypted 526 timestamp pre-authentication [RFC4120] 527 528 The authentication MUST fail if the encryption type used by the 529 client in the encData does not conform to policy. 530 531 If authentication fails due to the hash algorithm, iteration count or 532 encryption type used by the client then the KDC SHOULD return a PA- 533 OTP-CHALLENGE with the required values in the error response. If the 534 authentication fails due to the token state on the server no longer 535 being synchronized with the token used then the KDC SHALL return a 536 PA-OTP-CHALLENGE with the "nextOTP" flag set as described in 537 Section 2.4. 538 539 If during the authentication process, the KDC determines that the 540 user's PIN has expired then it MAY include a PA-OTP-PIN-CHANGE in the 541 response as described in Section 2.3 542 5433.5. Confirming the Reply Key Change 544 545 If the pre-authentication data was successfully verified, then, in 546 order to support mutual authentication, the KDC SHALL respond to the 547 client's PA-OTP-REQUEST by including in the AS-REP, a PA-OTP-CONFIRM 548 containing the client's nonce from PA-OTP-REQUEST encrypted under the 549 generated Reply Key. 550 551 The nonce SHALL be returned within a PA-OTP-ENC-CONFIRM encrypted 552 within the encData of the PA-OTP-CONFIRM. The key usage SHALL be 553 KEY_USAGE_OTP_CONFIRM and the encryption type SHOULD be the same as 554 used by the client in the encData of the PA-OTP-REQUEST. 555 556 557 558 559Richards Expires January 15, 2009 [Page 10] 560 561Internet-Draft OTP Pre-authentication July 2008 562 563 564 The PA-OTP-CONFIRM SHALL be sent to the client within the enc-fast- 565 rep of a PA-FX-FAST-REPLY encrypted under the current Armor Key. 566 567 The client then uses its generated Reply Key to decrypt the PA-OTP- 568 ENC-CONFIRM from the encData of the PA-OTP-CONFIRM. The client MUST 569 fail the authentication process if the nonce value in the PA-OTP-ENC- 570 CONFIRM is not the same as the nonce value sent in the PA-OTP- 571 REQUEST. 572 5733.6. Reply Key Generation 574 575 In order to authenticate the user, the client and KDC need to 576 generate two encryption keys: 577 578 o The Client Key to be used by the client to encrypt and by the KDC 579 to decrypt the encData in the PA-OTP-REQUEST. 580 581 o The Reply Key to be used in the standard manner by the KDC to 582 encrypt data in the AS-REP but also to be used by the KDC to 583 encrypt and by the client to decrypt the encData value in the PA- 584 OTP-CONFIRM. 585 586 The method used to generate the three keys will depend on the OTP 587 algorithm. 588 589 o If the OTP value is included in the otp-value of the PA-OTP- 590 REQUEST then all three keys SHALL be the same as the Armor Key 591 (defined in [ZhHa07]). 592 593 o If the OTP value is not included in the otp-value of the PA-OTP- 594 REQUEST then the three keys SHALL be derived from the Armor Key 595 and the OTP value as described below. 596 597 If the OTP value is not included in the PA-OTP-REQUEST, then the 598 Reply Key SHALL be generated using the KRB_FX_CF2 algorithm from 599 [ZhHa07] 600 601 Client Key = KRB_FX_CF2(K1, K2, O1, O2) 602 Reply Key = KRB_FX_CF2(K1, K2, O3, O4) 603 604 The first input keys, K1, shall be the Armor Key. The second input 605 key, K2, shall be derived from the OTP value using string-to-key 606 (defined in [RFC3961]). 607 608 The octet string parameters, O1, O2, O3 and O4, shall be the ASCII 609 string "Combine1", "Combine2", "Combine3" and "Combine4" as shown 610 below: 611 612 613 614 615Richards Expires January 15, 2009 [Page 11] 616 617Internet-Draft OTP Pre-authentication July 2008 618 619 620 {0x43, 0x6f, 0x6d, 0x62, 0x69, 0x6e, 0x65, 0x31} 621 {0x43, 0x6f, 0x6d, 0x62, 0x69, 0x6e, 0x65, 0x32} 622 {0x43, 0x6f, 0x6d, 0x62, 0x69, 0x6e, 0x65, 0x33} 623 {0x43, 0x6f, 0x6d, 0x62, 0x69, 0x6e, 0x65, 0x34} 624 625 If the hash of the OTP value is to be used then K2 SHALL be derived 626 as follows: 627 628 o An initial hash value, H, is generated: 629 630 H = hash(sname|nonce|OTP) 631 632 Where: 633 * "|" denotes concatenation 634 * hash is the hash algorithm selected by the client. 635 * sname is the UTF-8 encoding of the KDC's fully qualified domain 636 name. If the domain name is an Internationalized Domain Name 637 then the value shall be the output of nameprep [RFC3491] as 638 described in [RFC3490] 639 * nonce is the random nonce value generated by the client to be 640 included in the PA-OTP-REQUEST. 641 * OTP is the OTP value. 642 643 o The initial hash value is then hashed iterationCount-1 times to 644 produce a final hash value, H'. (Where iterationCount is the 645 value from the PA-OTP-REQUEST.) 646 647 H' = hash(hash(...(iterationCount-1 times)...(H))) 648 649 o The value of K2 is then derived from the base64 [RFC2045] encoding 650 of this final hash value. 651 652 K2 = string-to-key(Base64(H')||"Krb-preAuth") 653 654 If the OTP value is binary and the hash value is not used, then K2 655 SHALL be derived from the base64 encoding of the OTP value. 656 657 K2 = string-to-key(Base64(OTP)||"Krb-preAuth") 658 659 If the OTP value is not binary and the hash value is not used, then 660 K2 SHALL be derived by running the OTP value once through string-to- 661 key. 662 663 K2 = string-to-key(OTP||"Krb-preAuth") 664 665 The salt and any additional parameters for string-to-key will be 666 derived as described in section 3.1.3 of [RFC4120] using preauth data 667 or default values defined for the particular enctype. The symbol 668 669 670 671Richards Expires January 15, 2009 [Page 12] 672 673Internet-Draft OTP Pre-authentication July 2008 674 675 676 "||" denotes string concatenation. 677 678 6794. OTP Kerberos Message Types 680 6814.1. PA-OTP-CHALLENGE 682 683 The PA_OTP_CHALLENGE padata type is sent by the KDC to the client in 684 the PA-DATA of a KRB-ERROR when pre-authentication using an OTP value 685 is required. The corresponding padata-value field contains the DER 686 encoding of a PA-OTP-CHALLENGE containing a server generated nonce 687 and information for the client on how to generate the OTP. 688 689 PA_OTP_CHALLENGE << TBA >> 690 691 PA-OTP-CHALLENGE ::= SEQUENCE { 692 flags OTPFlags, 693 nonce UInt32, 694 etype Int32, 695 supportedHashAlg SEQUENCE OF AlgorithmIdentifier 696 OPTIONAL, 697 iterationCount INTEGER OPTIONAL, 698 otp-challenge OCTET STRING (SIZE(8..MAX)) OPTIONAL, 699 otp-length [0] Int32 OPTIONAL, 700 otp-service UTF8String OPTIONAL, 701 otp-keyID [1] OCTET STRING OPTIONAL, 702 otp-algID AnyURI OPTIONAL, 703 ... 704 } 705 706 OTPFlags ::= KerberosFlags 707 -- nextOTP (0) 708 -- combine (1) 709 710 flags 711 If the "nextOTP" flag is set then the OTP SHALL be based on the 712 next token "state" rather than the current one. As an example, 713 for a time-based token, this means the next time slot and for an 714 event-based token, this could mean the next counter value. 715 716 The "combine flag controls how the challenge included in otp- 717 challenge shall be used. If the flag is set then OTP SHALL be 718 calculated using the challenge from otp-challenge and the internal 719 token state (e.g. time or counter). If the "combine" flag is not 720 set then the OTP SHALL be calculated based only on the challenge. 721 If the flag is set and otp-challenge is not present then the 722 request SHALL be regarded as invalid. 723 724 725 726 727Richards Expires January 15, 2009 [Page 13] 728 729Internet-Draft OTP Pre-authentication July 2008 730 731 732 nonce 733 A KDC-supplied nonce value to be encrypted by the client in the 734 PA-OTP-REQUEST. 735 736 etype 737 The encryption type to be used by the client to encrypt the nonce 738 in the PA-OTP-REQUEST. 739 740 supportedHashAlg 741 If present then a hash of the OTP value MUST be used in the key 742 derivation rather than the plain text value. Each 743 AlgorithmIdentifier identifies a hash algorithm that is supported 744 by the KDC in decreasing order of preference. The client MUST 745 select the first algorithm from the list that it supports. 746 Support for SHA1 by both the client and KDC is REQUIRED. The 747 AlgorithmIdentifer selected by the client MUST be placed in the 748 hashAlg element of the PA-OTP-REQUEST. 749 750 iterationCount 751 The minimum value of the iteration count to be used by the client 752 when hashing the OTP value. This value MUST be present if and 753 only if supportedHashAlg is present. If the value of this element 754 does not conform to local policy on the client then the client MAY 755 use a larger value but MUST NOT use a lower value. The value of 756 the iteration count used by the client MUST be returned in the PA- 757 OTP-REQUEST sent to the KDC. 758 759 otp-challenge 760 The otp-challenge is used by the KDC to send a challenge value for 761 use in the OTP calculation. The challenge is an optional octet 762 string that SHOULD be uniquely generated for each request it is 763 present in, and SHOULD be eight octets or longer when present. 764 When the challenge is not present, the OTP will be calculated on 765 the current token state only. The client MAY ignore a provided 766 challenge if and only if the OTP token the client is interacting 767 with is not capable of including a challenge in the OTP 768 calculation. In this case, KDC policies will determine whether to 769 accept a provided OTP value or not. 770 771 otp-length 772 Use of this field is OPTIONAL, but MAY be used by the KDC to 773 specify the desired length of the generated OTP in octets. For 774 example, this field could be used when a token is capable of 775 producing OTP values of different lengths. 776 777 778 779 780 781 782 783Richards Expires January 15, 2009 [Page 14] 784 785Internet-Draft OTP Pre-authentication July 2008 786 787 788 otp-service 789 Use of this field is OPTIONAL, but MAY be used by the KDC to 790 identify the appropriate OTP tokens to be used. For example, this 791 field could be used when a client has multiple OTP tokens from 792 different servers. 793 794 otp-keyID 795 Use of this field is OPTIONAL, but MAY be used by the KDC to 796 identify which token key should be used for the authentication. 797 For example, this field could be used when a user has been issued 798 multiple token keys by the same server. 799 800 otp-algID 801 use of this field is OPTIONAL, but MAY be used by the KDC to 802 identify the algorithm to use when generating the OTP. 803 8044.2. PA-OTP-REQUEST 805 806 The padata-type PA_OTP_REQUEST is sent by the client to the KDC in 807 the KrbFastReq padata of a PA-FX-FAST-REQUEST that is included in the 808 PA-DATA of an AS-REQ. The corresponding padata-value field contains 809 the DER encoding of a PA-OTP-REQUEST. 810 811 The message contains pre-authentication data encrypted by the client 812 using the generated Client Key and optional information on how the 813 OTP was generated. It may also, optionally, contain the generated 814 OTP value. 815 816 PA_OTP_REQUEST << TBA >> 817 818 PA-OTP-REQUEST ::= SEQUENCE { 819 flags OTPFlags, 820 nonce UInt32, 821 encData EncryptedData, 822 -- PA-OTP-ENC-REQUEST or PA-ENC-TS-ENC 823 -- Key usage of KEY_USAGE_OTP_REQUEST 824 hashAlg AlgorithmIdentifier OPTIONAL, 825 iterationCount INTEGER OPTIONAL, 826 otp-value OCTET STRING OPTIONAL, 827 otp-challenge [0] OCTET STRING OPTIONAL, 828 otp-time KerberosTime OPTIONAL, 829 otp-counter [1] OCTET STRING OPTIONAL, 830 otp-format [2] OTPFormat OPTIONAL, 831 otp-keyID [3] OCTET STRING OPTIONAL, 832 otp-algID AnyURI OPTIONAL, 833 ... 834 } 835 836 837 838 839Richards Expires January 15, 2009 [Page 15] 840 841Internet-Draft OTP Pre-authentication July 2008 842 843 844 KEY_USAGE_OTP_REQUEST << TBA >> 845 846 847 PA-OTP-ENC-REQUEST ::= SEQUENCE { 848 nonce UInt32, 849 ... 850 } 851 852 853 OTPFormat ::= INTEGER { 854 decimal(0), 855 hexadecimal(1), 856 alphanumeric(2), 857 binary(3) 858 } 859 860 flags 861 If the "nextOTP" flag is set then the OTP was calculated based on 862 the next token "state" rather than the current one. This flag 863 MUST be set if and only if it was set in a corresponding PA-OTP- 864 CHALLENGE. 865 866 If the "combine" flag is set then the OTP was calculated based on 867 a challenge and the token state. 868 869 nonce 870 A random nonce value generated by the client to be returned 871 encrypted by the KDC in the PA-OTP-CONFIRM. 872 873 encData 874 This field contains the pre-authentication data encrypted under 875 the Client Key with a key usage of KEY_USAGE_OTP_REQUEST. If the 876 PA-OTP-REQUEST is sent as a result of a PA-OTP_CHALLENGE then this 877 MUST contain a PA-OTP-ENC-REQUEST with the nonce from the PA-OTP- 878 CHALLENGE. If no challenge was received then this MUST contain a 879 PA-ENC-TS-ENC. 880 881 hashAlg 882 This field MUST be present if and only if a hash of the OTP value 883 was used as input to string-to-key (see Section 3.6) and MUST 884 contain the AlgorithmIdentifier of the hash algorithm used. If 885 the PA-OTP-REQUEST is sent as a result of a PA-OTP-CHALLENGE then 886 the AlgorithmIdentifer MUST be the first one supported by the 887 client from the supportedHashAlg of the PA-OTP-CHALLENGE. 888 889 890 891 892 893 894 895Richards Expires January 15, 2009 [Page 16] 896 897Internet-Draft OTP Pre-authentication July 2008 898 899 900 iterationCount 901 This field MUST be present if and only if a hash of the OTP value 902 was used as input to string-to-key (see Section 3.6) and MUST 903 contain the iteration count used when hashing the OTP value. If 904 the PA-OTP-REQUEST is sent as a result of a PA-OTP-CHALLENGE then 905 the value MUST NOT be less that that specified in the PA-OTP- 906 CHALLENGE. 907 908 otp-value 909 The generated OTP value. This value MUST NOT be present unless 910 allowed by the OTP algorithm profile. 911 912 otp-challenge 913 Value used by the client in the OTP calculation. It MUST be sent 914 to the KDC if and only if the value would otherwise be unknown to 915 the KDC. For example, the token or client modified or generated 916 challenge. 917 918 otp-time 919 This field MAY be included by the client to carry the time value 920 as reported by the OTP token. Use of this element is OPTIONAL but 921 it MAY be used by a client to simplify the OTP calculations of the 922 KDC. It is RECOMMENDED that the KDC act upon this value if it is 923 present in the request and it is capable of using it in the 924 generation of the OTP value. 925 926 otp-counter 927 This field MAY be included by the client to carry the token 928 counter value, as reported by the OTP token. Use of this element 929 is OPTIONAL but it MAY be used by a client to simplify the OTP 930 calculations of the KDC. It is RECOMMENDED that the KDC act upon 931 this value if it is present in the request and it is capable of 932 using it in the generation of the OTP value. 933 934 otp-format 935 This field MAY be used by the client to send the format of the 936 generated OTP as reported by the OTP token. Use of this element 937 is OPTIONAL but it MAY be used by the client to simplify the OTP 938 calculation. It is RECOMMENDED that the KDC act upon this value 939 if it is present in the request and it is capable of using it in 940 the generation of the OTP value. 941 942 otp-keyID 943 This field MAY be used by the client to send the identifier of the 944 token key used, as reported by the OTP token. Use of this field 945 is OPTIONAL but MAY be used by the client to simplify the 946 authentication process by identifying a particular token key 947 associated with the user. It is RECOMMENDED that the KDC act upon 948 949 950 951Richards Expires January 15, 2009 [Page 17] 952 953Internet-Draft OTP Pre-authentication July 2008 954 955 956 this value if it is present in the request and it is capable of 957 using it in the generation of the OTP value. 958 959 otp-algID 960 This field MAY be used by the client to send the identifier of the 961 OTP algorithm used, as reported by the OTP token. Use of this 962 element is OPTIONAL but it MAY be used by the client to simplify 963 the OTP calculation. It is RECOMMENDED that the KDC act upon this 964 value if it is present in the request and it is capable of using 965 it in the generation of the OTP value. 966 9674.3. PA-OTP-CONFIRM 968 969 The padata-type PA_OTP_CONFIRM is returned by the KDC in the enc- 970 fast-rep of a PA-FX-FAST-REPLY in the AS-REP of the KDC. It is used 971 to return the client's nonce encrypted under the new Reply Key in 972 order to authenticate the KDC and confirm the Reply Key change. 973 974 The corresponding padata-value field contains the DER encoding of a 975 PA-OTP-CONFIRM. 976 977 PA_OTP_CONFIRM << TBA >> 978 979 PA-OTP-CONFIRM ::= SEQUENCE { 980 encData EncryptedData, 981 -- PA-OTP-ENC-CONFIRM 982 -- Key usage of KEY_USAGE_OTP_CONFIRM 983 ... 984 } 985 986 KEY_USAGE_OTP_CONFIRM << TBA >> 987 988 989 PA-OTP-ENC-CONFIRM ::= SEQUENCE { 990 nonce UInt32, 991 ... 992 } 993 994 encData 995 An EncryptedData containing a PA-OTP-ENC-CONFIRM containing the 996 value of the nonce from the corresponding PA-OTP-REQUEST encrypted 997 under the current Reply Key. The key usage SHALL be 998 KEY_USAGE_OTP_CONFIRM and the encryption type SHOULD be the same 999 as that used by the client in the PA-OTP-REQUEST. 1000 1001 1002 1003 1004 1005 1006 1007Richards Expires January 15, 2009 [Page 18] 1008 1009Internet-Draft OTP Pre-authentication July 2008 1010 1011 10124.4. PA-OTP-PIN-CHANGE 1013 1014 The padata-type PA_OTP_PIN_CHANGE is returned by the KDC in the enc- 1015 fast-rep of a PA-FX-FAST-REPLY in the AS-REP if the user must change 1016 their PIN or if the user's PIN has been changed. 1017 1018 The corresponding padata-value field contains the DER encoding of a 1019 PA-OTP-PIN-CHANGE. 1020 1021 PA_OTP_PIN_CHANGE << TBA >> 1022 1023 PA-OTP-PIN-CHANGE ::= SEQUENCE { 1024 flags PinFlags, 1025 pin UTF8String OPTIONAL, 1026 minLength INTEGER OPTIONAL, 1027 maxLength [1] INTEGER OPTIONAL, 1028 ... 1029 } 1030 1031 PinFlags ::= KerberosFlags 1032 -- systemSetPin (0) 1033 1034 If the "systemSetPin" flag is set then the user's PIN has been 1035 changed and the new PIN value is contained in the pin field. The pin 1036 field MUST therefore be present. 1037 1038 If the "systemSetPin" flag is not set then the user's PIN has not 1039 been changed by the server but it MUST instead be changed by the 1040 user. Restrictions on the size of the PIN MAY be given by the 1041 minLength and maxLength fields. If the pin field is present then it 1042 contains a PIN value that MAY be used by the user when changing the 1043 PIN. 1044 1045 10465. IANA Considerations 1047 1048 A registry may be required for the otp-algID values as introduced in 1049 Section 4.1. No other IANA actions are anticipated. 1050 1051 10526. Security Considerations 1053 10546.1. Man-in-the-Middle 1055 1056 In the system described in this document, the OTP pre-authentication 1057 protocol is tunnelled within the FAST Armor channel provided by the 1058 pre-authentication framework. As described in [AsNiNy02], tunneled 1059 protocols are potentially vulnerable to man-in-the-middle attacks if 1060 1061 1062 1063Richards Expires January 15, 2009 [Page 19] 1064 1065Internet-Draft OTP Pre-authentication July 2008 1066 1067 1068 the outer tunnel is compromised and it is generally considered good 1069 practice in such cases to bind the inner encryption to the outer 1070 tunnel. 1071 1072 Even though no such attacks are known at this point, the proposed 1073 system uses the outer Armor Key in the derivation of the inner Client 1074 and Reply keys and so achieve crypto-binding to the outer channel. 1075 10766.2. Reflection 1077 1078 The 4-pass system described above is a challenge-response protocol 1079 and such protocols are potentially vulnerable to reflection attacks. 1080 No such attacks are known at this point but to help mitigate against 1081 such attacks, the system uses different keys to encrypt the client 1082 and server nonces. 1083 10846.3. Replay 1085 1086 The 2-pass version of the protocol does not involve a server nonce 1087 and so the client instead encrypts a timestamp. To reduce the chance 1088 of replay attacks, the KDC must check that the client time used in 1089 such a request is later than that used in previous requests. 1090 10916.4. Brute Force Attack 1092 1093 A compromised or hostile KDC may be able to obtain the OTP value used 1094 by the client via a brute force attack. If the OTP value is short 1095 then the KDC could iterate over the possible OTP values until a 1096 Client Key is generated that can decrypt the encData sent in the PA- 1097 OTP-REQUEST. 1098 1099 As described in Section 3.6, an iteration count can be used in the 1100 generation of the Client Key and the value of the iteration count can 1101 be controlled by local client policy. Use of this iteration count 1102 can make it computationally infeasible/unattractive for an attacker 1103 to brute-force search for the given OTP within the lifetime of that 1104 OTP. 1105 11066.5. FAST Facilities 1107 1108 The secret used to generate the OTP is known only to the client and 1109 the KDC and so successful decryption of the encrypted nonce by the 1110 KDC authenticates the user. Similarly, successful decryption of the 1111 encrypted nonce by the client proves that the expected KDC replied. 1112 The Reply Key is replaced by a key generated from the OTP and Armor 1113 Key. This FAST factor therefore provides the following facilities: 1114 client-authentication, replacing-reply-key and KDC-authentication. 1115 1116 1117 1118 1119Richards Expires January 15, 2009 [Page 20] 1120 1121Internet-Draft OTP Pre-authentication July 2008 1122 1123 11247. Acknowledgments 1125 1126 Many significant contributions were made to this document by RSA 1127 employees but special thanks go to Magnus Nystrom, John Linn, Robert 1128 Polansky and Boris Khoutorski. 1129 1130 Many valuable suggestions were also made by members of the Kerberos 1131 Working group but special thanks go to Larry Zhu, Jeffrey Hutzelman, 1132 Tim Alsop, Henry Hotz and Nicolas Williams. 1133 1134 11358. References 1136 11378.1. Normative References 1138 1139 [RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail 1140 Extensions (MIME) Part One: Format of Internet Message 1141 Bodies", RFC 2045, November 1996. 1142 1143 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1144 Requirement Levels", BCP 14, RFC 2119, March 1997. 1145 1146 [RFC3490] Faltstrom, P., Hoffman, P., and A. Costello, 1147 "Internationalizing Domain Names in Applications (IDNA)", 1148 RFC 3490, March 2003. 1149 1150 [RFC3491] Hoffman, P. and M. Blanchet, "Nameprep: A Stringprep 1151 Profile for Internationalized Domain Names (IDN)", 1152 RFC 3491, March 2003. 1153 1154 [RFC3961] Raeburn, K., "Encryption and Checksum Specifications for 1155 Kerberos 5", RFC 3961, February 2005. 1156 1157 [RFC4120] Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The 1158 Kerberos Network Authentication Service (V5)", RFC 4120, 1159 July 2005. 1160 1161 [ZhHa07] Znu, L. and S. Hartman, "A generalized Framework for 1162 Kerberos Pre-Authentication", 1163 draft-ietf-krb-wg-preauth-framework-08 (work in progress), 1164 July 2008. 1165 11668.2. Informative References 1167 1168 [AsNiNy02] 1169 Asokan, N., Niemi, V., and K. Nyberg, "Man-in-the-Middle 1170 in Tunneled Authentication Protocols", Cryptology ePrint 1171 Archive Report 2002/163, November 2002. 1172 1173 1174 1175Richards Expires January 15, 2009 [Page 21] 1176 1177Internet-Draft OTP Pre-authentication July 2008 1178 1179 1180 [HoReNeZo04] 1181 Horstein, K., Renard, K., Neuman, C., and G. Zorn, 1182 "Integrating Single-use Authentication Mechanisms with 1183 Kerberos", draft-ietf-krb-wg-kerberos-sam-03 (work in 1184 progress), July 2004. 1185 1186 [RFC2289] Haller, N., Metz, C., Nesser, P., and M. Straw, "A One- 1187 Time Password System", RFC 2289, February 1998. 1188 1189 [RFC2808] Nystrom, M., "The SecurID(r) SASL Mechanism", RFC 2808, 1190 April 2000. 1191 1192 [RFC3244] Swift, M., Trostle, J., and J. Brezak, "Microsoft Windows 1193 2000 Kerberos Change Password and Set Password Protocols", 1194 RFC 3244, February 2002. 1195 1196 [RFC4226] M'Raihi, D., Bellare, M., Hoornaert, F., Naccache, D., and 1197 O. Ranen, "HOTP: An HMAC-Based One-Time Password 1198 Algorithm", RFC 4226, December 2005. 1199 1200 1201Appendix A. ASN.1 Module 1202 1203 OTPKerberos 1204 DEFINITIONS IMPLICIT TAGS ::= 1205 BEGIN 1206 1207 IMPORTS 1208 AnyURI 1209 FROM XSD {joint-iso-itu-t asn1(1) specification(0) 1210 modules(0) xsd-module(1)}; 1211 1212 KerberosTime, KerberosFlags, EncryptionKey, UInt32, 1213 Int32, EncryptedData 1214 FROM KerberosV5Spec2 {iso(1) identified-organization(3) 1215 dod(6) internet(1) security(5) 1216 kerberosV5(2) modules(4) krb5spec2(2)} 1217 -- as defined in RFC 4120. 1218 AlgorithmIdentifier 1219 FROM PKIX1Explicit88 { iso (1) identified-organization (3) 1220 dod (6) internet (1) 1221 security (5) mechanisms (5) pkix (7) 1222 id-mod (0) id-pkix1-explicit (18) }; 1223 -- As defined in RFC 3280. 1224 1225 PA-OTP-CHALLENGE ::= SEQUENCE { 1226 flags OTPFlags, 1227 nonce UInt32, 1228 1229 1230 1231Richards Expires January 15, 2009 [Page 22] 1232 1233Internet-Draft OTP Pre-authentication July 2008 1234 1235 1236 etype Int32, 1237 supportedHashAlg SEQUENCE OF AlgorithmIdentifier 1238 OPTIONAL, 1239 iterationCount INTEGER OPTIONAL, 1240 otp-challenge OCTET STRING (SIZE(8..MAX)) OPTIONAL, 1241 otp-length [0] Int32 OPTIONAL, 1242 otp-service UTF8String OPTIONAL, 1243 otp-keyID [1] OCTET STRING OPTIONAL, 1244 otp-algID AnyURI OPTIONAL, 1245 ... 1246 } 1247 1248 OTPFlags ::= KerberosFlags 1249 -- nextOTP (0) 1250 -- combine (1) 1251 1252 PA-OTP-REQUEST ::= SEQUENCE { 1253 flags OTPFlags, 1254 nonce UInt32, 1255 encData EncryptedData, 1256 -- PA-OTP-ENC-REQUEST or PA-ENC-TS-ENC 1257 -- Key usage of KEY_USAGE_OTP_REQUEST 1258 hashAlg AlgorithmIdentifier OPTIONAL, 1259 iterationCount INTEGER OPTIONAL, 1260 otp-value OCTET STRING OPTIONAL, 1261 otp-challenge [0] OCTET STRING (SIZE(8..MAX)) OPTIONAL, 1262 otp-time KerberosTime OPTIONAL, 1263 otp-counter [1] OCTET STRING OPTIONAL, 1264 otp-format [2] OTPFormat OPTIONAL, 1265 otp-keyID [3] OCTET STRING OPTIONAL, 1266 otp-algID AnyURI OPTIONAL, 1267 ... 1268 } 1269 1270 PA-OTP-ENC-REQUEST ::= SEQUENCE { 1271 nonce UInt32, 1272 ... 1273 } 1274 1275 OTPFormat ::= INTEGER { 1276 decimal(0), 1277 hexadecimal(1), 1278 alphanumeric(2), 1279 binary(3) 1280 } 1281 1282 PA-OTP-CONFIRM ::= SEQUENCE { 1283 encData EncryptedData, 1284 1285 1286 1287Richards Expires January 15, 2009 [Page 23] 1288 1289Internet-Draft OTP Pre-authentication July 2008 1290 1291 1292 -- PA-OTP-ENC-CONFIRM 1293 -- Key usage of KEY_USAGE_OTP_CONFIRM 1294 ... 1295 } 1296 1297 PA-OTP-ENC-CONFIRM ::= SEQUENCE { 1298 nonce UInt32, 1299 ... 1300 } 1301 1302 PA-OTP-PIN-CHANGE ::= SEQUENCE { 1303 flags PinFlags, 1304 pin UTF8String OPTIONAL, 1305 minLength INTEGER OPTIONAL, 1306 maxLength [0] INTEGER OPTIONAL, 1307 ... 1308 } 1309 1310 PinFlags ::= KerberosFlags 1311 -- systemSetPin (0) 1312 1313 END 1314 1315 1316Appendix B. Examples of OTP Pre-Authentication Exchanges 1317 1318 This section is non-normative. 1319 1320B.1. Four Pass Authentication 1321 1322 In this mode, the client sends an initial AS-REQ to the KDC that does 1323 not contain a PA-OTP-REQUEST and the KDC responds with a KRB-ERROR 1324 containing a PA-OTP-CHALLENGE. 1325 1326 In this example, the user has been issued with a connected, time- 1327 based token and the KDC requires hashed OTP values in the key 1328 generation with SHA-384 as the preferred hash algorithm and a minimum 1329 of 1024 iterations. It also requires that 256-bit AES be used to 1330 encrypt the nonce. The local policy on the client supports SHA-256 1331 and requires 100,000 iterations of the OTP value. 1332 1333 The basic sequence of steps involved is as follows: 1334 1335 1. The client obtains the user name of the user. 1336 1337 2. The client sends an initial AS-REQ to the KDC that does not 1338 contain a PA-OTP-REQUEST. 1339 1340 1341 1342 1343Richards Expires January 15, 2009 [Page 24] 1344 1345Internet-Draft OTP Pre-authentication July 2008 1346 1347 1348 3. The KDC determines that the user identified by the AS-REQ 1349 requires OTP authentication. 1350 1351 4. The KDC constructs a PA-OTP-CHALLENGE as follows: 1352 1353 flags 1354 0 1355 1356 nonce 1357 A randomly generated value. 1358 1359 etype 1360 aes256-cts-hmac-sha1-96 1361 1362 supportedHashAlg 1363 AlgorithmIdentifiers for SHA-384, SHA-256 and SHA-1 1364 1365 iterationCount 1366 1024 1367 1368 otp-service 1369 A string that can be used by the client to assist the user in 1370 locating the correct token. 1371 1372 5. The KDC returns a KRB-ERROR with an error code of 1373 KDC_ERR_PREAUTH_REQUIRED and the PA-OTP-CHALLENGE in the e-data. 1374 1375 6. The client displays the value of otp-service and prompts the 1376 user to connect the token. 1377 1378 7. The client obtains the current OTP value from the token and 1379 records the time as reported by the token. 1380 1381 8. The client generates Client Key and Reply Key as described in 1382 Section 3.6 using SHA-256 from the list of algorithms sent by 1383 the KDC and the iteration count of 100,000 as required by local 1384 policy. 1385 1386 9. The client constructs a PA-OTP-REQUEST as follows: 1387 1388 flags 1389 0 1390 1391 nonce 1392 A randomly generated value. 1393 1394 1395 1396 1397 1398 1399Richards Expires January 15, 2009 [Page 25] 1400 1401Internet-Draft OTP Pre-authentication July 2008 1402 1403 1404 encData 1405 An EncryptedData containing a PA-OTP-ENC-REQUEST encrypted 1406 under the Client Key with a key usage of 1407 KEY_USAGE_OTP_REQUEST and an encryption type of aes256-cts- 1408 hmac-sha1-96. The PA-OTP-ENC-REQUEST contains the nonce from 1409 the PA-OTP-CHALLENGE. 1410 1411 hashAlg 1412 SHA-256 1413 1414 iterationCount 1415 100,000 1416 1417 otp-time 1418 The time used in the OTP calculation as reported by the OTP 1419 token. 1420 1421 10. The client encrypts the PA-OTP-REQUEST within the enc-fast-req 1422 of a PA-FX-FAST-REQUEST. 1423 1424 11. The client sends an AS-REQ to the KDC containing the PA-FX-FAST- 1425 REQUEST within the padata. 1426 1427 12. The KDC validates the pre-authentication data in the PA-OTP- 1428 REQUEST: 1429 1430 * Generates the Client Key and Reply Key from the OTP value for 1431 the user identified in the AS-REQ, using an iteration count 1432 of 100,000 and hash algorithm of SHA-256 as specified in the 1433 PA-OTP-REQUEST. 1434 1435 * Uses the generated Client Key to decrypt the PA-OTP-ENC- 1436 REQUEST in the encData of the PA-OTP-REQUEST. 1437 1438 * Authenticates the user by comparing the nonce value from the 1439 decrypted PA-OTP-ENC-REQUEST to that sent in the 1440 corresponding PA-OTP-CHALLENGE. 1441 1442 13. The KDC constructs a TGT for the user. 1443 1444 14. The KDC constructs a PA-OTP-CONFIRM as follows: 1445 1446 encData 1447 An EncryptedData containing a PA-OTP-ENC-CONFIRM encrypted 1448 under the Reply Key with a key usage of KEY_USAGE_OTP_CONFIRM 1449 and an encryption type of aes256-cts-hmac-sha1-96 (the 1450 encryption type used by the client in the PA-OTP-REQUEST). 1451 The PA-OTP-ENC-CONFIRM contains the nonce from the PA-OTP- 1452 1453 1454 1455Richards Expires January 15, 2009 [Page 26] 1456 1457Internet-Draft OTP Pre-authentication July 2008 1458 1459 1460 REQUEST. 1461 1462 15. The KDC encrypts the PA-OTP-CONFIRM within the enc-fast-rep of a 1463 PA-FX-FAST-REPLY. 1464 1465 16. The KDC returns an AS-REP to the client, encrypted using the 1466 Reply Key, containing the TGT and padata with the PA-FX-FAST- 1467 REPLY. 1468 1469 17. The client authenticates the KDC and verifies the Reply Key 1470 change. 1471 1472 * Uses the generated Reply Key to decrypt the PA-OTP-ENC- 1473 CONFIRM in the encData of the PA-OTP-CONFIRM. 1474 1475 * Authenticates the KDC by comparing the nonce value from the 1476 decrypted PA-OTP-ENC-CONFIRM to that sent in the 1477 corresponding PA-OTP-REQUEST. 1478 1479B.2. Two Pass Authentication 1480 1481 In this mode, the client includes a PA-OTP-REQUEST within a PA-FX- 1482 FAST-REQUEST pre-auth of the initial AS-REQ sent to the KDC. 1483 1484 In this example, the user has been issued with a hand-held token and 1485 so none of the OTP generation parameters (otp-length etc) are 1486 included in the PA-OTP-RESPONSE. The KDC does not require hashed OTP 1487 values in the key generation. 1488 1489 It is assumed that the client has been configured with the following 1490 information or has obtained it from a previous PA-OTP-CHALLENGE. 1491 o The encryption type of aes128-cts-hmac-sha1-96 to use to encrypt 1492 the encData. 1493 o The fact that hashed OTP values are not required. 1494 1495 The basic sequence of steps involved is as follows: 1496 1497 1. The client obtains the user name and OTP value from the user. 1498 1499 2. The client generates Client Key and Reply Key using unhashed OTP 1500 values as described in Section 3.6. 1501 1502 3. The client constructs a PA-OTP-REQUEST as follows: 1503 1504 1505 1506 1507 1508 1509 1510 1511Richards Expires January 15, 2009 [Page 27] 1512 1513Internet-Draft OTP Pre-authentication July 2008 1514 1515 1516 flags 1517 0 1518 1519 nonce 1520 A randomly generated value. 1521 1522 encData 1523 An EncryptedData containing a PA-ENC-TS-ENC encrypted under 1524 the Client Key with a key usage of KEY_USAGE_OTP_REQUEST and 1525 an encryption type of aes128-cts-hmac-sha1-96. The PA-ENC- 1526 TS-ENC contains the current client time. 1527 1528 4. The client encrypts the PA-OTP-REQUEST within the enc-fast-req 1529 of a PA-FX-FAST-REQUEST. 1530 1531 5. The client sends an AS-REQ to the KDC containing the PA-FX-FAST- 1532 REQUEST within the padata. 1533 1534 6. The KDC validates the pre-authentication data: 1535 1536 * Generates the Client Key and Reply Key from the unhashed OTP 1537 value for the user identified in the AS-REQ. 1538 1539 * Uses the generated Client Key to decrypt the PA-ENC-TS-ENC in 1540 the encData of the PA-OTP-REQUEST. 1541 1542 * Authenticates the user using the timestamp in the standard 1543 manner. 1544 1545 7. The KDC constructs a TGT for the user. 1546 1547 8. The KDC constructs a PA-OTP-CONFIRM as follows: 1548 1549 encData 1550 An EncryptedData containing a PA-OTP-ENC-CONFIRM encrypted 1551 under the Reply Key with a key usage of KEY_USAGE_OTP_CONFIRM 1552 and an encryption type of aes128-cts-hmac-sha1-96 (the 1553 encryption type used by the client in the PA-OTP-REQUEST). 1554 The PA-OTP-ENC-CONFIRM contains the nonce from the PA-OTP- 1555 REQUEST. 1556 1557 9. The KDC encrypts the PA-OTP-CONFIRM within the enc-fast-rep of a 1558 PA-FX-FAST-REPLY. 1559 1560 10. The KDC returns an AS-REP to the client, encrypted using the 1561 Reply Key, containing the TGT and padata with the PA-FX-FAST- 1562 REPLY. 1563 1564 1565 1566 1567Richards Expires January 15, 2009 [Page 28] 1568 1569Internet-Draft OTP Pre-authentication July 2008 1570 1571 1572 11. The client authenticates the KDC and verifies the key change. 1573 1574 * Uses the generated Reply Key to decrypt the PA-OTP-ENC- 1575 CONFIRM in the encData of the PA-OTP-CONFIRM. 1576 1577 * Authenticates the KDC by comparing the nonce value from the 1578 decrypted PA-OTP-ENC-CONFIRM to that sent in the 1579 corresponding PA-OTP-REQUEST. 1580 1581B.3. Pin Change 1582 1583 This exchange follows from the point where the KDC receives the PA- 1584 OTP-REQUEST from the client in the examples in Appendix B.1 and 1585 Appendix B.2. During the validation of the pre-authentication data 1586 (whether encrypted nonce or encrypted timestamp), the KDC determines 1587 that the user's PIN has expired and so must be changed. The KDC 1588 therefore includes a PA-OTP-PIN-CHANGE along with the PA-OTP-CONFIRM 1589 in the AS-REP. 1590 1591 In this example, the KDC does not generate PIN values for the user 1592 but requires that the user generate a new PIN that is between 4 and 8 1593 characters in length. The actual PIN change is handled by a PIN 1594 change service that requires the "initial" bit to be set in the 1595 service ticket. 1596 1597 The basic sequence of steps involved is as follows: 1598 1599 1. The client constructs and sends a PA-OTP-REQUEST to the KDC as 1600 described in the previous examples. 1601 1602 2. The KDC validates the pre-authentication data and authenticates 1603 the user as in the previous examples but determines that the 1604 user's PIN has expired. 1605 1606 3. KDC constructs a ticket for a PIN change service with the 1607 "initial" flag set. 1608 1609 4. KDC constructs a PA-OTP-CONFIRM as in the previous examples. 1610 1611 5. KDC constructs a PA-OTP-PIN-CHANGE as follows: 1612 1613 flags 1614 0 1615 1616 1617 1618 1619 1620 1621 1622 1623Richards Expires January 15, 2009 [Page 29] 1624 1625Internet-Draft OTP Pre-authentication July 2008 1626 1627 1628 minLength 1629 4 1630 1631 maxLength 1632 8 1633 1634 6. KDC encrypts the PA-OTP-PIN-CHANGE and PA-OTP-CONFIRM within the 1635 enc-fast-rep of a PA-FX-FAST-REPLY. 1636 1637 7. KDC returns an AS-REP to the client containing the ticket to the 1638 PIN change service and padata containing the PA-FX-FAST-REPLY. 1639 1640 8. The client authenticates the KDC as in the previous examples. 1641 1642 9. The client uses the ticket in the AS-REP to call the PIN change 1643 service and change the user's PIN. 1644 1645 10. The client sends a second AS-REQ to the KDC containing a PA-OTP- 1646 REQUEST constructed using the new PIN. 1647 1648 11. The KDC responds with an AS-REP containing a TGT and a PA-OTP- 1649 CONFRIM. 1650 1651 1652B.4. Resynchronization 1653 1654 This exchange follows from the point where the KDC receives the PA- 1655 OTP-REQUEST from the client. During the validation of the pre- 1656 authentication data (whether encrypted nonce or encrypted timestamp), 1657 the KDC determines that the local record of the token's state needs 1658 to be re-synchronized with the token. The KDC therefore includes a 1659 KRB-ERROR containing a PA-OTP-CHALLENGE with the "nextOTP" flag set. 1660 1661 The sequence of steps below follows is a variation of the four pass 1662 examples shown in Appendix B.1 but the same process would also work 1663 in the two-pass case. 1664 1665 1. The client constructs and sends a PA-OTP-REQUEST to the KDC as 1666 described in the previous examples. 1667 1668 2. The KDC validates the pre-authentication data and authenticates 1669 the user as in the previous examples but determines that user's 1670 token requires re-synchronizing. 1671 1672 3. KDC constructs a PA-OTP-CHALLENGE as follows: 1673 1674 1675 1676 1677 1678 1679Richards Expires January 15, 2009 [Page 30] 1680 1681Internet-Draft OTP Pre-authentication July 2008 1682 1683 1684 flags 1685 nextOTP bit set 1686 1687 nonce 1688 A randomly generated value. 1689 1690 etype 1691 aes256-cts-hmac-sha1-96 1692 1693 supportedHashAlg 1694 AlgorithmIdentifiers for SHA-256 and SHA-1 1695 1696 iterationCount 1697 1024 1698 1699 otp-service 1700 Set to a string that can be used by the client to assist the 1701 user in locating the correct token. 1702 1703 4. KDC returns a KRB-ERROR with an error code of 1704 KDC_ERR_PREAUTH_REQUIRED and the PA-OTP-CHALLENGE in the e-data. 1705 1706 5. The client obtains the next OTP value from the token and records 1707 the time as reported by the token. 1708 1709 6. The client generates Client Key Reply Key as described in 1710 Section 3.6 using SHA-256 from the list of algorithms sent by 1711 the KDC and the iteration count of 100,000 as required by local 1712 policy. 1713 1714 7. The client constructs a PA-OTP-REQUEST as follows: 1715 1716 flags 1717 nextOTP bit set 1718 1719 nonce 1720 A randomly generated value. 1721 1722 encData 1723 An EncryptedData containing a PA-OTP-ENC-REQUEST encrypted 1724 under the Client Key with a key usage of 1725 KEY_USAGE_OTP_REQUEST and an encryption type of aes256-cts- 1726 hmac-sha1-96. The PA-OTP-ENC-REQUEST contains the nonce from 1727 the PA-OTP-CHALLENGE. 1728 1729 1730 1731 1732 1733 1734 1735Richards Expires January 15, 2009 [Page 31] 1736 1737Internet-Draft OTP Pre-authentication July 2008 1738 1739 1740 hashAlg 1741 SHA-256 1742 1743 iterationCount 1744 100,000 1745 1746 otp-time 1747 The time used in the OTP calculation as reported by the OTP 1748 token. 1749 1750 8. The client encrypts the PA-OTP-REQUEST within the enc-fast-req 1751 of a PA-FX-FAST-REQUEST. 1752 1753 9. The client sends an AS-REQ to the KDC containing the PA-FX-FAST- 1754 REQUEST within the padata. 1755 1756 10. Authentication process now proceeds as with the standard 1757 sequence. 1758 1759 1760Author's Address 1761 1762 Gareth Richards 1763 RSA, The Security Division of EMC 1764 RSA House 1765 Western Road 1766 Bracknell, Berkshire RG12 1RT 1767 UK 1768 1769 Email: gareth.richards@rsa.com 1770 1771 1772 1773 1774 1775 1776 1777 1778 1779 1780 1781 1782 1783 1784 1785 1786 1787 1788 1789 1790 1791Richards Expires January 15, 2009 [Page 32] 1792 1793Internet-Draft OTP Pre-authentication July 2008 1794 1795 1796Full Copyright Statement 1797 1798 Copyright (C) The IETF Trust (2008). 1799 1800 This document is subject to the rights, licenses and restrictions 1801 contained in BCP 78, and except as set forth therein, the authors 1802 retain all their rights. 1803 1804 This document and the information contained herein are provided on an 1805 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1806 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 1807 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 1808 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 1809 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1810 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1811 1812 1813Intellectual Property 1814 1815 The IETF takes no position regarding the validity or scope of any 1816 Intellectual Property Rights or other rights that might be claimed to 1817 pertain to the implementation or use of the technology described in 1818 this document or the extent to which any license under such rights 1819 might or might not be available; nor does it represent that it has 1820 made any independent effort to identify any such rights. Information 1821 on the procedures with respect to rights in RFC documents can be 1822 found in BCP 78 and BCP 79. 1823 1824 Copies of IPR disclosures made to the IETF Secretariat and any 1825 assurances of licenses to be made available, or the result of an 1826 attempt made to obtain a general license or permission for the use of 1827 such proprietary rights by implementers or users of this 1828 specification can be obtained from the IETF on-line IPR repository at 1829 http://www.ietf.org/ipr. 1830 1831 The IETF invites any interested party to bring to its attention any 1832 copyrights, patents or patent applications, or other proprietary 1833 rights that may cover technology that may be required to implement 1834 this standard. Please address the information to the IETF at 1835 ietf-ipr@ietf.org. 1836 1837 1838 1839 1840 1841 1842 1843 1844 1845 1846 1847Richards Expires January 15, 2009 [Page 33] 1848 1849