idnits 2.17.1 draft-ietf-krb-wg-otp-preauth-21.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document seems to contain a disclaimer for pre-RFC5378 work, and may have content which was first submitted before 10 November 2008. The disclaimer is necessary when there are original authors that you have been unable to contact, or if some do not wish to grant the BCP78 rights to the IETF Trust. If you are able to get all authors (current and original) to grant those rights, you can and should remove the disclaimer; otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (November 23, 2011) is 4531 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Looks like a reference, but probably isn't: '0' on line 1566 -- Looks like a reference, but probably isn't: '1' on line 1567 -- Looks like a reference, but probably isn't: '2' on line 1568 -- Looks like a reference, but probably isn't: '3' on line 1569 -- Looks like a reference, but probably isn't: '4' on line 1570 -- Looks like a reference, but probably isn't: '5' on line 1571 -- Looks like a reference, but probably isn't: '6' on line 1549 -- Looks like a reference, but probably isn't: '7' on line 1550 -- Looks like a reference, but probably isn't: '8' on line 1551 -- Looks like a reference, but probably isn't: '9' on line 1552 -- Looks like a reference, but probably isn't: '10' on line 1553 -- Looks like a reference, but probably isn't: '11' on line 1554 -- Looks like a reference, but probably isn't: '12' on line 1555 -- Looks like a reference, but probably isn't: '13' on line 1556 -- Possible downref: Non-RFC (?) normative reference: ref. 'ISOIEC7812' ** Obsolete normative reference: RFC 4013 (Obsoleted by RFC 7613) ** Obsolete normative reference: RFC 6112 (Obsoleted by RFC 8062) Summary: 2 errors (**), 0 flaws (~~), 1 warning (==), 17 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group G. Richards 3 Internet-Draft RSA, The Security Division of 4 Intended status: Standards Track EMC 5 Expires: May 26, 2012 November 23, 2011 7 OTP Pre-authentication 8 draft-ietf-krb-wg-otp-preauth-21 10 Abstract 12 The Kerberos protocol provides a framework authenticating a client 13 using the exchange of pre-authentication data. This document 14 describes the use of this framework to carry out One Time Password 15 (OTP) authentication. 17 Status of this Memo 19 This Internet-Draft is submitted in full conformance with the 20 provisions of BCP 78 and BCP 79. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF). Note that other groups may also distribute 24 working documents as Internet-Drafts. The list of current Internet- 25 Drafts is at http://datatracker.ietf.org/drafts/current/. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 This Internet-Draft will expire on May 26, 2012. 34 Copyright Notice 36 Copyright (c) 2011 IETF Trust and the persons identified as the 37 document authors. All rights reserved. 39 This document is subject to BCP 78 and the IETF Trust's Legal 40 Provisions Relating to IETF Documents 41 (http://trustee.ietf.org/license-info) in effect on the date of 42 publication of this document. Please review these documents 43 carefully, as they describe your rights and restrictions with respect 44 to this document. Code Components extracted from this document must 45 include Simplified BSD License text as described in Section 4.e of 46 the Trust Legal Provisions and are provided without warranty as 47 described in the Simplified BSD License. 49 This document may contain material from IETF Documents or IETF 50 Contributions published or made publicly available before November 51 10, 2008. The person(s) controlling the copyright in some of this 52 material may not have granted the IETF Trust the right to allow 53 modifications of such material outside the IETF Standards Process. 54 Without obtaining an adequate license from the person(s) controlling 55 the copyright in such materials, this document may not be modified 56 outside the IETF Standards Process, and derivative works of it may 57 not be created outside the IETF Standards Process, except to format 58 it for publication as an RFC or to translate it into languages other 59 than English. 61 Table of Contents 63 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 64 1.1. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 4 65 1.2. Overall Design . . . . . . . . . . . . . . . . . . . . . . 4 66 1.3. Conventions Used in this Document . . . . . . . . . . . . 5 67 2. Usage Overview . . . . . . . . . . . . . . . . . . . . . . . . 5 68 2.1. OTP Mechanism Support . . . . . . . . . . . . . . . . . . 5 69 2.2. Pre-Authentication . . . . . . . . . . . . . . . . . . . . 5 70 2.3. PIN Change . . . . . . . . . . . . . . . . . . . . . . . . 6 71 2.4. Re-Synchronization . . . . . . . . . . . . . . . . . . . . 7 72 3. Pre-Authentication Protocol Details . . . . . . . . . . . . . 7 73 3.1. Initial Client Request . . . . . . . . . . . . . . . . . . 7 74 3.2. KDC Challenge . . . . . . . . . . . . . . . . . . . . . . 8 75 3.3. Client Response . . . . . . . . . . . . . . . . . . . . . 10 76 3.4. Verifying the pre-auth Data . . . . . . . . . . . . . . . 14 77 3.5. Confirming the Reply Key Change . . . . . . . . . . . . . 15 78 3.6. Reply Key Generation . . . . . . . . . . . . . . . . . . . 16 79 4. OTP Kerberos Message Types . . . . . . . . . . . . . . . . . . 18 80 4.1. PA-OTP-CHALLENGE . . . . . . . . . . . . . . . . . . . . . 18 81 4.2. PA-OTP-REQUEST . . . . . . . . . . . . . . . . . . . . . . 23 82 4.3. PA-OTP-PIN-CHANGE . . . . . . . . . . . . . . . . . . . . 26 83 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 28 84 6. Security Considerations . . . . . . . . . . . . . . . . . . . 28 85 6.1. Man-in-the-Middle . . . . . . . . . . . . . . . . . . . . 28 86 6.2. Reflection . . . . . . . . . . . . . . . . . . . . . . . . 29 87 6.3. Denial of Service . . . . . . . . . . . . . . . . . . . . 29 88 6.4. Replay . . . . . . . . . . . . . . . . . . . . . . . . . . 30 89 6.5. Brute Force Attack . . . . . . . . . . . . . . . . . . . . 30 90 6.6. FAST Facilities . . . . . . . . . . . . . . . . . . . . . 31 91 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 31 92 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 32 93 8.1. Normative References . . . . . . . . . . . . . . . . . . . 32 94 8.2. Informative References . . . . . . . . . . . . . . . . . . 33 95 Appendix A. ASN.1 Module . . . . . . . . . . . . . . . . . . . . 33 96 Appendix B. Examples of OTP Pre-Authentication Exchanges . . . . 36 97 B.1. Four Pass Authentication . . . . . . . . . . . . . . . . . 36 98 B.2. Two Pass Authentication . . . . . . . . . . . . . . . . . 38 99 B.3. PIN Change . . . . . . . . . . . . . . . . . . . . . . . . 40 100 B.4. Resynchronization . . . . . . . . . . . . . . . . . . . . 41 101 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 43 103 1. Introduction 105 1.1. Scope 107 This document describes a Flexible Authentication Secure Tunneling 108 (FAST) [RFC6113] factor that allows One-Time Password (OTP) values to 109 be used in the Kerberos V5 [RFC4120] pre-authentication in a manner 110 that does not require use of the user's Kerberos password. The 111 system is designed to work with different types of OTP algorithms 112 such as time-based OTPs [RFC2808], counter-based tokens [RFC4226] and 113 challenge-response systems such as [RFC2289]. It is also designed to 114 work with tokens that are electronically connected to the user's 115 computer via means such as a USB interface. 117 This FAST factor provides the following facilities (as defined in 118 [RFC6113]): client-authentication, replacing-reply-key and KDC- 119 authentication. It does not provide the strengthening-reply-key 120 facility. 122 This proposal is partially based upon previous work on integrating 123 single-use authentication mechanisms into Kerberos [HoReNeZo04]. 125 1.2. Overall Design 127 This proposal supports 4-pass and 2-pass variants. In the 4-pass 128 system, the client sends the KDC an initial AS-REQ and the KDC 129 responds with a KRB-ERROR containing padata that includes a random 130 nonce. The client then encrypts the nonce and returns it to the KDC 131 in a second AS-REQ. Finally, the KDC returns the AS-REP. In the 132 2-pass variant, the client encrypts a timestamp rather than a nonce 133 from the KDC and the encrypted data is sent to the KDC in the initial 134 AS-REQ. The two-pass system can be used in cases where the client 135 can determine in advance that OTP pre-authentication is supported by 136 the KDC, which OTP key should be used and the encryption parameters 137 required by the KDC. 139 In both systems, in order to create the message sent to the KDC, the 140 client must generate the OTP value and two keys: the classic Reply 141 Key used to decrypt the KDC's reply and a key to encrypt the data 142 sent to the KDC. In most cases, the OTP value will be used in the 143 key generation but in order to support algorithms where the KDC 144 cannot obtain the value (e.g. [RFC2289]), the system also supports 145 the option of including the OTP value in the request along with the 146 encrypted nonce. In addition, in order to support situations where 147 the KDC is unable to obtain the plaintext OTP value, the system also 148 supports the use of hashed OTP values in the key derivation. 150 The preauth data sent from the client to the KDC is sent within the 151 encrypted data provided by the FAST padata type of the AS-REQ. The 152 KDC then obtains the OTP value, generates the same keys and verifies 153 the pre-authentication data by decrypting the nonce. If the 154 verification succeeds then it confirms knowledge of the Reply Key by 155 using it to encrypt data in the AS-REP. 157 1.3. Conventions Used in this Document 159 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 160 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 161 document are to be interpreted as described in [RFC2119]. 163 This document assumes familiarity with the Kerberos pre- 164 authentication framework [RFC6113] and so freely uses terminology and 165 notation from this document. 167 The word padata is used as shorthand for pre-authentication data. 169 2. Usage Overview 171 2.1. OTP Mechanism Support 173 As described above, this document describes a generic system for 174 supporting different OTP mechanisms in Kerberos pre-authentication. 175 To ensure interoperability, all implementations of this specification 176 SHOULD provide a mechanism (e.g. a provider interface) to add or 177 remove support for a particular OTP mechanism. 179 2.2. Pre-Authentication 181 The approach uses pre-authentication data in AS-REQ, AS-REP and KRB- 182 ERROR messages. 184 In the 4-pass system, the client begins by sending an initial AS-REQ 185 to the KDC that may contain pre-authentication data such as the 186 standard Kerberos password data. The KDC will then determine, in an 187 implementation dependent fashion, whether OTP authentication is 188 required and if it is, it will respond with a KRB-ERROR message 189 containing a PA-OTP-CHALLENGE (see Section 4.1) in the PA-DATA. 191 The PA-OTP-CHALLENGE will contain a KDC generated nonce, a list of 192 hash algorithm identifiers and an iteration count if hashed OTP 193 values are used (see Section 3.6) and OPTIONAL information on how the 194 OTP should be generated by the client. The client will then generate 195 the OTP value and two keys: a Client Key to encrypt the KDC's nonce 196 and a Reply Key used to decrypt the KDC's reply. 198 As described in section 5.4.1 of [RFC6113], the FAST system uses an 199 Armor Key to set up an encrypted tunnel for use by FAST factors. As 200 described in Section 3.6 of this document, the Client Key and Reply 201 Key will be generated from the Armor Key and the OTP value unless the 202 OTP algorithm does not allow the KDC to obtain the OTP value. If 203 hash algorithm identifiers were included in the PA-OTP-CHALLENGE then 204 the client will use the hash of the OTP value rather than the 205 plaintext value in the key generation. Both keys will have the same 206 encryption type as the Armor Key. 208 The generated Client Key will be used to encrypt the nonce received 209 from the KDC. The encrypted value along with optional information on 210 how the OTP was generated are then sent to the KDC in a PA-OTP- 211 REQUEST (see Section 4.2) encrypted within the armored-data of a PA- 212 FX-FAST-REQUEST PA-DATA element of a second AS-REQ. 214 In the 2-pass system, the client sends the PA-OTP-REQUEST in the 215 initial AS-REQ instead of sending it in response to a PA-OTP- 216 CHALLENGE returned by the KDC. Since no challenge is received from 217 the KDC, the client includes an encrypted timestamp in the request 218 rather than the encrypted KDC nonce. 220 In both cases, on receipt of a PA-OTP-REQUEST, the KDC generates the 221 keys in the same way as the client, and uses the generated Client Key 222 to verify the pre-authentication by decrypting the encrypted data 223 sent by the client (either nonce or timestamp). If the validation 224 succeeds then the KDC will authenticate itself to the client and 225 confirm that the Reply Key has been updated by using the generated 226 Reply Key in the AS-REP response. 228 2.3. PIN Change 230 Most OTP tokens involve the use of a PIN in the generation of the OTP 231 value. This PIN value will be combined with the value generated by 232 the token to produce the final OTP value that will be used in this 233 protocol. 235 If, following successful validation of a PA-OTP-REQUEST in an AS-REQ, 236 the KDC determines that the user's PIN has expired and needs to 237 change then it SHOULD respond KRB-ERROR of type KDC_ERR_PIN_EXPIRED. 238 It MAY include formatting information on the PIN in a PA-OTP-PIN- 239 CHANGE (see Section 4.3) encrypted within the armored data of the PA- 240 FX-FAST-REPLY PA-DATA element. 242 KDC_ERR_PIN_EXPIRED 96 244 If the PIN change is to be handled by a PIN-change service then it is 245 assumed that authentication to that service will succeed if the PIN 246 has expired. 248 If the user's PIN has not expired but has been changed then the KDC 249 MAY return the new value to the client in a PA-OTP-PIN-CHANGE 250 encrypted within the armored data of the PA-FX-FAST-REPLY PA-DATA 251 element of the AS-REP. Similarly, if PIN change is not required then 252 the KDC MAY return a PA-OTP-PIN-CHANGE to inform the client of the 253 current PIN's expiration time. 255 2.4. Re-Synchronization 257 It is possible with time and event-based tokens that the OTP server 258 will lose synchronization with the current token state. For example, 259 event-based tokens may drift since the counter on the token is 260 incremented every time the token is used but the counter on the 261 server is only incremented on an authentication. Similarly, the 262 clocks on time-based tokens may drift. 264 Methods to recover from this type of situation are OTP algorithm 265 specific but may involve the client sending a sequence of OTP values 266 to allow the server to further validate the correct position in its 267 search window (see section 7.4 of [RFC4226] for an example). 269 If, when processing a PA-OTP-REQUEST, the pre-authentication 270 validation fails for this reason then the KDC MAY return a KRB-ERROR 271 message. The KRB-ERROR message MAY contain a PA-OTP-CHALLENGE in the 272 PA-DATA with a single otp-tokenInfo representing the token used in 273 the initial authentication attempt but with "nextOTP" flag set. If 274 this flag is set then the client SHOULD re-try the authentication 275 using an OTP value generated using the token in the "state" after 276 that used in the failed authentication attempt. For example, using 277 the next time interval or counter value. 279 3. Pre-Authentication Protocol Details 281 3.1. Initial Client Request 283 In the 4-pass mode, the client begins by sending an initial AS-REQ, 284 possibly containing other pre-authentication data. If the KDC 285 determines that OTP-based pre-authentication is required and the 286 request does not contain a PA-OTP-REQUEST then it will respond as 287 described in Section 3.2. 289 If the client has all the necessary information, it MAY use the 290 2-pass system by constructing a PA-OTP-REQUEST as described in 291 Section 3.3 and including it in the initial request. 293 3.2. KDC Challenge 295 If the user is required to authenticate using an OTP then the KDC 296 SHALL respond to the initial AS-REQ with a KRB-ERROR, as described in 297 section 2.2 of [RFC6113], with a PA-OTP-CHALLENGE contained within 298 the enc-fast-rep of the armored-data of a PA-FX-FAST-REPLY encrypted 299 under the current Armor Key as described in [RFC6113]. 301 If the OTP mechanism is to be carried out as an individual mechanism 302 then the PA-OTP-CHALLENGE SHALL be carried within the padata of the 303 KrbFastResponse. Alternatively, if the OTP mechanism is required as 304 part of an authentication set then the PA-OTP-CHALLENGE SHALL be 305 carried within a PA-AUTHENTICATION-SET-ELEM as described in section 306 5.3 of [RFC6113]. 308 The PA-OTP-CHALLENGE SHALL contain a nonce value to be returned 309 encrypted in the client's PA-OTP-REQUEST. This nonce string MUST 310 contain a randomly chosen component at least as long as the armor key 311 length. (See [RFC4086] for an in-depth discussion of > randomness.) 312 In order to allow it to maintain any state necessary to verify the 313 returned nonce, the KDC SHOULD use the mechanism described in section 314 5.2 of [RFC6113]. 316 The KDC MAY use the otp-service field to assist the client in 317 locating the OTP token to be used by identifying the purpose of the 318 authentication. For example, the otp-service field could assist a 319 user in identifying the token to be used when a user has multiple OTP 320 tokens that are used for different purposes. If the token is a 321 connected device, then these values SHOULD be an exact octet-level 322 match for the values present on the target token. 324 The KDC SHALL include a sequence of one or more otp-tokenInfo 325 elements containing information on the token or tokens that the user 326 can use for the authentication and how the OTP value is to be 327 generated using those tokens. If a single otp-tokenInfo element is 328 included then only a single token is acceptable by the KDC and any 329 OTP value generated by the client MUST be generated according to the 330 information contained within that element. If more than one otp- 331 tokenInfo element is included then the OTP value MUST be generated 332 according to the information contained within one of those elements. 334 The KDC MAY include the otp-vendor field in an otp-tokenInfo to 335 identify the vendor of the token that can be used in the 336 authentication request in order to assist the client in locating that 337 token. 339 If the KDC is able to obtain the OTP values for the token then the 340 OTP value SHOULD be used in the key generation as described in 341 Section 3.6 and so the KDC SHOULD set the "must-encrypt-nonce" flag 342 in the otp-tokenInfo. If the KDC is unable to obtain the OTP values 343 for the token then the "must-encrypt-nonce" flag MUST NOT be set. If 344 the flag is not set then the OTP value will be returned by the client 345 in the otp-value field of the PA-OTP-REQUEST and so if returning of 346 OTP values in this way does not conform to KDC policy then the KDC 347 SHOULD NOT include the otp-tokenInfo for that token in the PA-OTP- 348 CHALLENGE. 350 If the KDC requires that hashed OTPs be used in the key generation as 351 described in Section 3.6 (for example, it is only able to obtain 352 hashed OTP values for the token) then it MUST include the supported 353 hash algorithms in order of preference in the supportedHashAlg of the 354 otp-KeyInfo and the minimum value of the iteration count in the 355 iterationCount element. 357 Since the OTP mechanism described in this document is replacing the 358 Reply Key, the classic shared-key system cannot be relied upon to 359 allow the client to verify the KDC. Therefore, as described in 360 section 3.4 of [RFC6113], some other mechanism must be provided to 361 support this. If the OTP value is used in the Reply Key generation 362 then the client and KDC have a shared key and KDC-authentication is 363 provided by the KDC using the Reply Key generated from the OTP value. 364 However, if the OTP value is sent in the otp-value element of the PA- 365 OTP-REQUEST then there is no such shared key and the OTP mechanism 366 does not provide KDC-authentication. Therefore, if the OTP mechanism 367 is not being used in an environment where KDC-authentication is being 368 provided by other means (e.g. by the use of host key armor) then the 369 KDC MUST NOT include any otp-tokenInfo elements in the PA-OTP- 370 CHALLENGE that do not have the "must-encrypt-nonce" flag set. 372 If the OTP for a token is to be generated using a server generated 373 challenge then the value of the challenge SHALL be included in the 374 otp-challenge field of the otp-tokenInfo for that token. If the 375 token is a connected device and the OTP is to be generated by 376 combining the challenge with the token's current state (e.g. time) 377 then the "combine" flag SHALL be set within the otp-tokenInfo 378 containing the challenge. 380 If the KDC can determine which OTP token key (the seed value on the 381 token used to generate the OTP) is to be used, then the otp-tokenID 382 field MAY be included in the otp-tokenInfo to pass that value to the 383 client. 385 The otp-algID field MAY be included in an otp-tokenInfo to identify 386 the algorithm that should be used in the OTP calculation for that 387 token. For example, it could be used when a user has been issued 388 with multiple tokens that support different algorithms. 390 If the KDC can determine that an OTP token that can be used by the 391 user does not require the client to collect a PIN then it SHOULD set 392 the "do-not-collect-pin" flag in the otp-tokenInfo representing that 393 token. If the KDC can determine that the token requires the client 394 to collect a PIN then it SHOULD set the "collect-pin" flag. If the 395 KDC is unable to determine whether the client should collect a PIN or 396 not then the "collect-pin" and "do-not-collect-pin" flags MUST NOT be 397 set. 399 If the KDC requires the PIN of an OTP token to be returned to it 400 separately then it SHOULD set the "separate-pin-required" flag in the 401 otp-KeyInfo representing that token. 403 If the KDC requires that the OTPs generated by the token have a Luhn 404 check digit appended, as defined in [ISOIEC7812], then it MUST set 405 the "check-digit" flag. This flag only applies if the format of the 406 OTP is decimal and so the otp-format field, if present, MUST have the 407 value of "decimal". 409 Finally, in order to support connected tokens that can generate OTP 410 values of varying lengths or formats, the KDC MAY include the desired 411 length and format of the OTP in the otp-length and otp-format fields 412 of an otp-tokenInfo. 414 3.3. Client Response 416 The client response SHALL be sent to the KDC as a PA-OTP-REQUEST 417 included within the enc-fast-req of the armored-data within a PA-FX- 418 FAST-REQUEST encrypted under the current Armor Key as described in 419 [RFC6113]. 421 In order to generate its response, the client MUST generate an OTP 422 value. If the PA-OTP-CHALLENGE contained one or more otp-tokenInfo 423 elements then the OTP value MUST be based on the information 424 contained within one of those elements. 426 The otp-service, otp-vendor, otp-tokenID, otp-length, otp-format and 427 otp-algID elements of the PA-OTP-CHALLENGE are provided by the KDC to 428 assist the client in locating the correct token to use but the use of 429 the above fields will depend on the type of token. 431 If the token is a disconnected device, then the values of otp-service 432 and otp-vendor MAY be displayed to the user in order to help the user 433 select the correct token and the values of otp-algID, otp-tokenID, 434 otp-length and otp-format MAY be ignored. 436 If the token is a connected device, then these values, if present, 437 SHOULD be used by the client to locate the correct token. When the 438 token is connected, clients MUST support matching based on a binary 439 comparison of the otp-vendor and otp-service strings when comparing 440 the values against those present on the token. Clients MAY have 441 other comparisons including normalization insensitive comparisons to 442 try and find the right token. The values of otp-vendor and otp- 443 service MAY be displayed to prompt the user if the correct token is 444 not found. 446 If the "nextOTP" flag is set in the otp-tokenInfo from the PA-OTP- 447 CHALLENGE, then the OTP value MUST be generated from the next token 448 state than that used in the previous PA-OTP-REQUEST for that token. 449 The "nextOTP" flag MUST also be set in the new PA-OTP-REQUEST. 451 If the "collect-pin" flag is set then the token requires a PIN to be 452 collected by the client. If the "do-not-collect-pin" flag is set in 453 the otp-tokenInfo from the PA-OTP-CHALLENGE, then the token 454 represented by the otp-tokenInfo does not require a PIN to be 455 collected by the client as part of the OTP value. If neither of the 456 "collect-pin" nor "do-not-collect-pin" flags are set then PIN 457 requirements of the token are unspecified. If both flags are set 458 then client SHALL regard the request as invalid. 460 If the "separate-pin-required" flag is set then any PIN collected by 461 the client MUST be included as a UTF-8 string in the otp-pin of the 462 PA-OTP-REQUEST. 464 If the token is a connected device, then how the PIN is used to 465 generate the OTP value will depend on the type of device. However, 466 if the token is a disconnected device, then it will depend on the 467 "separate-pin-required" flag. If the flag is not set then the OTP 468 value MUST be generated by appending the PIN with the value from the 469 token entered by the user and, if the flag is set, then the OTP value 470 MUST be the value from the token. 472 The clients SHOULD NOT normalize the PIN value or any OTP value 473 collected from the user or returned by a connected token in any way. 475 If the "check-digit" flag is set then any OTP values SHOULD be 476 decimal and have a Luhn check digit appended [ISOIEC7812]. If the 477 token is disconnected then the Client MAY ignore this flag but if the 478 token is connected then the Client MUST enforce it. The Client MUST 479 regard the request as invalid if otp-format is present and set to any 480 value other than "decimal". 482 If an otp-challenge is present in the otp-tokenInfo selected by the 483 client from the PA-OTP-CHALLENGE then the OTP value for the token 484 MUST be generated based on a challenge if the token is capable of 485 accepting a challenge. The client MAY ignore the provided challenge 486 if and only if the token is not capable of including a challenge in 487 the OTP calculation. 489 If the "combine" flag is not set in the otp-tokenInfo of the PA-OTP- 490 CHALLENGE then the OTP SHALL be calculated based only the challenge 491 and not the internal state (e.g. time or counter) of the token. If 492 the "combine" flag is set then the OTP SHALL be calculated using both 493 the internal state and the provided challenge if that value is 494 obtainable by the client. If the flag is set but otp-challenge is 495 not present then the client SHALL regard the request as invalid. 497 If token is a connected device then the use of the challenge will 498 depend on the type of device but will involve passing the challenge 499 and the value of the "combine" flag in a token-specific manner to the 500 token, along with a PIN if collected and the values of otp-length and 501 otp-format if specified, in order to obtain the OTP value. If the 502 token is disconnected then the challenge MUST be displayed to the 503 user and the value of the "combine" flag MAY be ignored by the 504 client. 506 If the OTP value was generated using a challenge that was not sent by 507 the KDC then the challenge SHALL be included in the otp-challenge of 508 the PA-OTP-REQUEST. If the OTP was generated by combining a 509 challenge (either received from the KDC or generated by the client) 510 with the token state then the "combine" flag SHALL be set in the PA- 511 OTP-REQUEST. 513 If the "must-encrypt-nonce" flag is set in the otp-tokenInfo then the 514 OTP value MUST be used to generate the Client Key and Reply Key as 515 described in Section 3.6 and MUST NOT be included in the otp-value 516 field of the PA-OTP-REQUEST. If the flag is not set then the OTP 517 value MUST be included in the otp-value field of the PA-OTP-REQUEST 518 and MUST NOT be used in the key derivation. In this case, the Client 519 Key and Reply Key SHALL be the same as the Armor Key as described in 520 Section 3.6 and so if the returning of OTP values in this way does 521 not conform to local policy on the client (for example, if KDC- 522 Authentication is required and is not being provided by other means) 523 then it SHOULD NOT use the token for authentication. 525 If the supportedHashAlg and iterationCount elements are included in 526 the otp-tokenInfo then the client MUST use hashed OTP values in the 527 generation of the Reply Key and Client Key as described in 528 Section 3.6. The client MUST select the first algorithm from the 529 list that it supports and the AlgorithmIdentifer [RFC5280] selected 530 MUST be placed in the hashAlg element of the PA-OTP-REQUEST. 531 However, if none of the algorithm identifiers conform to local policy 532 restrictions then the authentication attempt MUST NOT proceed using 533 that token. If the value of iterationCount does not conform to local 534 policy on the client then the client MAY use a larger value but MUST 535 NOT use a lower value. The value of the iteration count used by the 536 client MUST be returned in the PA-OTP-REQUEST sent to the KDC. 538 If hashed OTP values are used then the nonce generated by the client 539 MUST be as long as the longest key length of the symmetric key types 540 that the it supports and MUST be chosen randomly. (See [RFC4086].) 541 The nonce MUST be included in the PA-OTP-REQUEST along with the hash 542 algorithm and iteration count used in the nonce, hashAlg and 543 iterationCount fields of the PA-OTP-REQUEST. These fields MUST NOT 544 be included if hashed OTP values were not used. It is RECOMMENDED 545 that the iteration count used by the client be chosen in such a way 546 that it is computationally infeasible/unattractive for an attacker to 547 brute-force search for the given OTP. 549 The PA-OTP-REQUEST returned by the client SHOULD include information 550 on the generated OTP value reported by the OTP token when available 551 to the client. The otp-time and otp-counter fields of the PA-OTP- 552 REQUEST SHOULD be used to return the time and counter values used by 553 the token if available to the client. The otp-format field MAY be 554 used to report the format of the generated OTP. This field SHOULD be 555 used if a token can generate OTP values in multiple formats. The 556 otp-algID field SHOULD be used by the client to report the algorithm 557 used in the OTP calculation and the otp-tokenID SHOULD be used to 558 report the identifier of the OTP token key used if the information is 559 known to the client. 561 If the PA-OTP-REQUEST is being sent in response to a PA-OTP-CHALLENGE 562 that contained an otp-vendor field in the selected otp-tokenInfo then 563 the otp-vendor field of the PA-OTP-REQUEST MUST be set to the same 564 value. If no otp-vendor field was provided by the KDC then the field 565 SHOULD be set to the vendor identifier of the token if known to the 566 client. 568 The generated Client Key is used by the client to encrypt data to be 569 included in the encData of the PA-OTP-REQUEST to allow the KDC to 570 authenticate the user. The key usage for this encryption is 571 KEY_USAGE_OTP_REQUEST. 573 o If the PA-OTP-REQUEST is being generated in response to a PA-OTP- 574 CHALLENGE returned by the KDC then the client SHALL encrypt a PA- 575 OTP-ENC-REQUEST containing the value of nonce from the PA-OTP- 576 CHALLENGE using the same encryption type as the Armor Key. 578 o If the PA-OTP-REQUEST is not in response to a PA-OTP-CHALLENGE 579 then the client SHALL encrypt a PA-ENC-TS-ENC containing the 580 current time as in the encrypted timestamp pre-authentication 581 mechanism [RFC4120]. 583 If the client is working in 2-pass mode and so is not responding to 584 an initial KDC challenge then the values of the iteration count and 585 hash algorithms cannot be obtained from that challenge. The client 586 SHOULD use any values obtained from a previous PA-OTP-CHALLENGE or, 587 if no values are available, it MAY use initial configured values. 589 3.4. Verifying the pre-auth Data 591 The KDC validates the pre-authentication data by generating the 592 Client Key and Reply Key in the same way as the client and using the 593 generated Client Key to decrypt the value of encData from the PA-OTP- 594 REQUEST. The generated Reply Key is used to encrypt data in the AS- 595 REP. 597 If the otp-value field is included in the PA-OTP-REQUEST then the KDC 598 MUST use that value unless the OTP method is required to support KDC- 599 authentication (see Section 3.2). If the otp-value is not included 600 in the PA-OTP-REQUEST then the KDC will need to generate or obtain 601 the OTP value. 603 If the otp-pin field is present in the PA-OTP-REQUEST then the PIN 604 value has be value provided by the client. The KDC SHOULD SASLPrep 605 [RFC4013] the value in lookup mode before comparison. 607 It should be noted that it is anticipated that, as improved string 608 comparison technologies are standardized, the processing done by the 609 KDC will change but efforts will be made to maintain as much 610 compatibility with SASLprep as possible. 612 If the otp-challenge field is present, then the OTP was calculated 613 using that challenge. If the "combine" flag is also set, then the 614 OTP was calculated using the challenge and the token's current state. 616 It is RECOMMENDED that the KDC acts upon the values of otp-time, otp- 617 counter, otp-format, otp-algID and otp-tokenID if they are present in 618 the PA-OTP-REQUEST. If the KDC receives a request containing these 619 values but cannot act upon them then they MAY be ignored. 621 The KDC generates the Client Key and Reply Key as described in 622 Section 3.6 from the OTP value using the nonce, hash algorithm and 623 iteration count if present in the PA-OTP-REQUEST. The KDC MUST fail 624 the request with KDC_ERR_INVALID_HASH_ALG if the KDC requires hashed 625 OTP values and the hashAlg field was not present in the PA-OTP- 626 REQUEST or if the value of this field does not conform to local KDC 627 policy. Similarly, the KDC MUST fail the request with 628 KDC_ERR_INVALID_ITERATION_COUNT if the value of the iterationCount 629 included in the PA-OTP-REQUEST does not conform to local KDC policy 630 or is less than that specified in the PA-OTP-CHALLENGE. In addition, 631 the KDC MUST fail the authentication request with 632 KDC_ERR_PIN_REQUIRED if it requires a separate PIN to the OTP value 633 and an otp-pin was not included in the PA-OTP-REQUEST 635 KDC_ERR_INVALID_HASH_ALG 94 636 KDC_ERR_INVALID_ITERATION_COUNT 95 637 KDC_ERR_PIN_REQUIRED 97 639 The generated Client Key is then used to decrypt the encData from the 640 PA-OTP-REQUEST. If the client response was sent as a result of a PA- 641 OTP-CHALLENGE then the decrypted data will be a PA-OTP-ENC-REQUEST 642 and the client authentication MUST fail with KDC_ERR_PREAUTH_FAILED 643 if the nonce value from the PA-OTP-ENC-REQUEST is not the same as the 644 nonce value sent in the PA-OTP-CHALLENGE. If the response was not 645 sent as a result of a PA-OTP-CHALLENGE then the decrypted value will 646 be a PA-ENC-TS-ENC and the authentication process will be the same as 647 with classic encrypted timestamp pre-authentication [RFC4120] 649 The KDC MUST fail the request with KDC_ERR_ETYPE_NOSUPP if the 650 encryption type used by the client in the encData does not conform to 651 KDC policy. 653 If authentication fails due to the hash algorithm, iteration count or 654 encryption type used by the client then the KDC SHOULD return a PA- 655 OTP-CHALLENGE with the required values in the error response. If the 656 authentication fails due to the token state on the server no longer 657 being synchronized with the token used then the KDC MAY return a PA- 658 OTP-CHALLENGE with the "nextOTP" flag set as described in 659 Section 2.4. 661 If, during the authentication process, the KDC determines that the 662 user's PIN has been changed then it SHOULD include a PA-OTP-PIN- 663 CHANGE in the response as described in Section 2.3 containing the new 664 PIN value. The KDC MAY also include the new PIN's expiration time 665 and the expiration time of the OTP account within the last-req field 666 of the PA-OTP-PIN-CHANGE. (These fields can be used by the KDC to 667 handle cases where the account related to the user's OTP token has a 668 different expiration time to the user's Kerberos account.) If the 669 KDC determines that the user's PIN or OTP account are about to 670 expire, it MAY return a PA-OTP-PIN-CHANGE with that information. 671 Finally, if the KDC determines that the user's PIN has expired then 672 it SHOULD return a KRB-ERROR of type KDC_ERR_PIN_EXPIRED as described 673 in Section 2.3 675 3.5. Confirming the Reply Key Change 677 If the pre-authentication data was successfully verified, then, in 678 order to support mutual authentication, the KDC SHALL respond to the 679 client's PA-OTP-REQUEST by using the generated Reply Key to encrypt 680 the data in the AS-REP. 682 The client then uses its generated Reply Key to decrypt the encrypted 683 data and MUST NOT continue with the authentication process if 684 decryption is not successful. 686 3.6. Reply Key Generation 688 In order to authenticate the user, the client and KDC need to 689 generate two encryption keys: 691 o The Client Key to be used by the client to encrypt and by the KDC 692 to decrypt the encData in the PA-OTP-REQUEST. 694 o The Reply Key to be used in the standard manner by the KDC to 695 encrypt data in the AS-REP. 697 The method used to generate the two keys will depend on the OTP 698 algorithm. 700 o If the OTP value is included in the otp-value of the PA-OTP- 701 REQUEST then the two keys SHALL be the same as the Armor Key 702 (defined in [RFC6113]). 704 o If the OTP value is not included in the otp-value of the PA-OTP- 705 REQUEST then the two keys SHALL be derived from the Armor Key and 706 the OTP value as described below. 708 If the OTP value is not included in the PA-OTP-REQUEST, then the 709 Reply Key and Client Key SHALL be generated using the KRB-FX-CF2 710 algorithm from [RFC6113] as follows: 712 Client Key = KRB-FX-CF2(K1, K2, O1, O2) 713 Reply Key = KRB-FX-CF2(K1, K2, O3, O4) 715 The octet string parameters, O1, O2, O3 and O4, shall be the ASCII 716 string "OTPComb1", "OTPComb2", "OTPComb3" and "OTPComb4" as shown 717 below: 719 {0x4f, 0x54, 0x50, 0x43, 0x6f, 0x6d, 0x62, 0x31} 720 {0x4f, 0x54, 0x50, 0x43, 0x6f, 0x6d, 0x62, 0x32} 721 {0x4f, 0x54, 0x50, 0x43, 0x6f, 0x6d, 0x62, 0x33} 722 {0x4f, 0x54, 0x50, 0x43, 0x6f, 0x6d, 0x62, 0x34} 724 The first input key, K1, SHALL be the Armor Key and so, as described 725 in section 5.1 of [RFC6113], the enctypes of the generated Client Key 726 and Reply Key will be the same as the enctype of Armor Key. The 727 second input key, K2, shall be derived from the OTP value using 728 string-to-key (defined in [RFC3961]) as follows. 730 If the hash of the OTP value is to be used then K2 SHALL be derived 731 as follows: 733 o An initial hash value, H, is generated: 735 H = hash(realm|nonce|OTP) 737 Where: 738 * "|" denotes concatenation 739 * hash is the hash algorithm selected by the client. 740 * realm is the name of the server's realm as carried in the realm 741 field of the AS-REQ. (Not including the tag and length from 742 the DER encoding.) 743 * nonce is the value of the random nonce value generated by the 744 client and carried in the nonce field of the PA-OTP-REQUEST. 745 (Not including the tag and length from the DER encoding.) 746 * If the OTP format is decimal, hexadecimal or alphanumeric, then 747 OTP is the value of the OTP generated as described in 748 Section 3.3 with SASLprep [RFC4013] applied in lookup mode, 749 otherwise it is the unnormalized OTP value. 751 o The initial hash value is then hashed iterationCount-1 times to 752 produce a final hash value, H'. (Where iterationCount is the 753 value from the PA-OTP-REQUEST.) 755 H' = hash(hash(...(iterationCount-1 times)...(H))) 757 o The value of K2 is then derived from the Base64 [RFC2045] encoding 758 of this final hash value. 760 K2 = string-to-key(Base64(H')|"Krb-preAuth") 762 If the hash value is not used, then K2 SHALL be derived from the 763 base64 encoding of the OTP value. 765 K2 = string-to-key(Base64(OTP)|"Krb-preAuth") 767 The enctype used for string-to-key SHALL be that of the Armor Key and 768 the salt and any additional parameters for string-to-key MAY be 769 provided by the KDC in the PA-OTP-CHALLENGE. If the salt and string- 770 to-key parameters are not provided then the default values defined 771 for the particular enctype SHALL be used. 773 If the strengthen-key is present in KrbFastResponse, then it is 774 combined with the Reply Key to generate the final AS-REQ as described 775 in [RFC6113]. The strengthen-key does not influence the Client Key. 777 4. OTP Kerberos Message Types 779 4.1. PA-OTP-CHALLENGE 781 The padata-type PA-OTP-CHALLENGE is returned by the KDC to the client 782 in the enc-fast-rep of a PA-FX-FAST-REPLY in the PA-DATA of a KRB- 783 ERROR when OTP pre-authentication is required. The corresponding 784 padata-value field contains the Distinguished Encoding Rules (DER) 785 [X.680] [X.690] encoding of a PA-OTP-CHALLENGE containing a server 786 generated nonce and information for the client on how to generate the 787 OTP. 789 PA-OTP-CHALLENGE 141 791 PA-OTP-CHALLENGE ::= SEQUENCE { 792 nonce [0] OCTET STRING, 793 otp-service [1] UTF8String OPTIONAL, 794 otp-tokenInfo [2] SEQUENCE (SIZE(1..MAX)) OF 795 OTP-TOKENINFO, 796 salt [3] KerberosString OPTIONAL, 797 s2kparams [4] OCTET STRING OPTIONAL, 798 ... 799 } 801 OTP-TOKENINFO ::= SEQUENCE { 802 flags [0] OTPFlags, 803 otp-vendor [1] UTF8String OPTIONAL, 804 otp-challenge [2] OCTET STRING (SIZE(1..MAX)) 805 OPTIONAL, 806 otp-length [3] Int32 OPTIONAL, 807 otp-format [4] OTPFormat OPTIONAL, 808 otp-tokenID [5] OCTET STRING OPTIONAL, 809 otp-algID [6] AnyURI OPTIONAL, 810 supportedHashAlg [7] SEQUENCE OF AlgorithmIdentifier 811 OPTIONAL, 812 iterationCount [8] Int32 OPTIONAL, 813 ... 814 } 816 OTPFormat ::= INTEGER { 817 decimal(0), 818 hexadecimal(1), 819 alphanumeric(2), 820 binary(3), 821 base64(4) 822 } 824 OTPFlags ::= KerberosFlags 825 -- reserved(0), 826 -- nextOTP(1), 827 -- combine(2), 828 -- collect-pin(3), 829 -- do-not-collect-pin(4), 830 -- must-encrypt-nonce (5), 831 -- separate-pin-required (6), 832 -- check-digit (7) 834 nonce 835 A KDC-supplied nonce value to be encrypted by the client in the 836 PA-OTP-REQUEST. This nonce string MUST contain a randomly chosen 837 component at least as long as the armor key length. 839 otp-service 840 Use of this field is OPTIONAL, but MAY be used by the KDC to 841 assist the client to locate the appropriate OTP tokens to be used. 842 For example, this field could be used when a user has multiple OTP 843 tokens for different purposes. 845 otp-tokenInfo 846 This element MUST be included and it is a sequence of one or more 847 OTP-TOKENINFO objects containing information on the token or 848 tokens that the user can use for the authentication and how the 849 OTP value is to be generated using those tokens. If a single OTP- 850 TOKENINFO object is included then only a single token is 851 acceptable by the KDC and any OTP value generated by the client 852 MUST be generated according to the information contained within 853 that element. If more than one OTP-TOKENINFO object is included 854 then the OTP value MUST be generated according to the information 855 contained within one of those objects. 857 flags 858 If the "nextOTP" flag is set then the OTP SHALL be based on the 859 next token "state" rather than the one used in the previous 860 authentication. As an example, for a time-based token, this 861 means the next time slot and for an event-based token, this 862 could mean the next counter value. If the "nextOTP" flag is 863 set then there MUST only be a single otp-tokenInfo element in 864 the PA-OTP-CHALLENGE. 866 The "combine" flag controls how the challenge included in otp- 867 challenge shall be used. If the flag is set then OTP SHALL be 868 calculated using the challenge from otp-challenge and the 869 internal token state (e.g. time or counter). If the "combine" 870 flag is not set then the OTP SHALL be calculated based only on 871 the challenge. If the flag is set and otp-challenge is not 872 present then the request SHALL be regarded as invalid. 874 If the "do-not-collect-pin" flag is set then the token 875 represented by the current otp-tokenInfo does not require a PIN 876 to be collected as part of the OTP. If the "collect-pin" flag 877 is set then the token requires a PIN. If neither flag is set 878 then whether or not a PIN is required is unspecified. The 879 flags are mutually exclusive and so both flags MUST NOT be set, 880 or the client MUST regard the request as invalid. 882 If the "must-encrypt-nonce" flag is set then the OTP value MUST 883 NOT be included in the otp-value field of the PA-OTP-REQUEST 884 but instead MUST be used in the generation of the Reply Key and 885 Client Key as described in Section 3.6. 887 If the "separate-pin-required" flag is set then the PIN 888 collected by the client SHOULD NOT be used in the generation of 889 the OTP value and SHOULD be returned in the otp-pin field of 890 the PA-OTP-REQUEST. 892 The "check-digit" flag controls whether or not the OTP values 893 generated by the token need to include a Luhn check digit 894 [ISOIEC7812]. If the token is disconnected then the Client MAY 895 ignore this flag but if this flag is set and the token is 896 connected then the OTP MUST be decimal with a check digit 897 appended. 899 otp-vendor 900 Use of this field is OPTIONAL, but MAY be used by the KDC to 901 identify the vendor of the OTP token to be used. 903 otp-challenge 904 The otp-challenge is used by the KDC to send a challenge value 905 for use in the OTP calculation. The challenge is an OPTIONAL 906 octet string that SHOULD be uniquely generated for each request 907 in which it is present. When the challenge is not present, the 908 OTP will be calculated on the current token state only. The 909 client MAY ignore a provided challenge if and only if the OTP 910 token the client is interacting with is not capable of 911 including a challenge in the OTP calculation. In this case, 912 KDC policies will determine whether to accept a provided OTP 913 value or not. 915 otp-length 916 Use of this field is OPTIONAL, but MAY be used by the KDC to 917 specify the desired length of the generated OTP. For example, 918 this field could be used when a token is capable of producing 919 OTP values of different lengths. If the format of the OTP is 920 'decimal', 'hexidecimal' or 'alphanumeric' then this value 921 indicates the desired length in digits/characters, if the OTP 922 format is 'binary' then this value indicates the desired length 923 in octets and if the OTP format is 'base64' then this value 924 indicates the desired length of the unencoded OTP value in 925 octets. 927 otp-format 928 Use of this field is OPTIONAL, but MAY be used by the KDC to 929 specify the desired format of the generated OTP value. For 930 example, this field could be used when a token is capable of 931 producing OTP values of different formats. 933 otp-tokenID 934 Use of this field is OPTIONAL, but MAY be used by the KDC to 935 identify which token key should be used for the authentication. 936 For example, this field could be used when a user has been 937 issued multiple token keys by the same server. 939 otp-algID 940 Use of this field is OPTIONAL, but MAY be used by the KDC to 941 identify the algorithm to use when generating the OTP. The 942 value of this field MUST be a URI [RFC3986] and SHOULD be 943 obtained from the PSKC algorithm registry [RFC6030]. 945 supportedHashAlg 946 If present then a hash of the OTP value MUST be used in the key 947 derivation rather than the plain text value. Each 948 AlgorithmIdentifier identifies a hash algorithm that is 949 supported by the KDC in decreasing order of preference. The 950 client MUST select the first algorithm from the list that it 951 supports. Support for SHA-256 by both the client and KDC is 952 REQUIRED. The AlgorithmIdentifier selected by the client MUST 953 be placed in the hashAlg element of the PA-OTP-REQUEST. 955 iterationCount 956 The minimum value of the iteration count to be used by the 957 client when hashing the OTP value. This value MUST be present 958 if supportedHashAlg is present and otherwise MUST NOT be 959 present. If the value of this element does not conform to 960 local policy on the client then the client MAY use a larger 961 value but MUST NOT use a lower value. The value of the 962 iteration count used by the client MUST be returned in the PA- 963 OTP-REQUEST sent to the KDC. 965 salt 966 The salt value to be used in string-to-key when used to calculate 967 the keys as described in Section 3.6. 969 s2kparams 970 Any additional parameters required by string-to-key as described 971 in Section 3.6. 973 4.2. PA-OTP-REQUEST 975 The padata-type PA-OTP-REQUEST is sent by the client to the KDC in 976 the KrbFastReq padata of a PA-FX-FAST-REQUEST that is included in the 977 PA-DATA of an AS-REQ. The corresponding padata-value field contains 978 the DER encoding of a PA-OTP-REQUEST. 980 The message contains pre-authentication data encrypted by the client 981 using the generated Client Key and optional information on how the 982 OTP was generated. It may also, optionally, contain the generated 983 OTP value. 985 PA-OTP-REQUEST 142 987 PA-OTP-REQUEST ::= SEQUENCE { 988 flags [0] OTPFlags, 989 nonce [1] OCTET STRING OPTIONAL, 990 encData [2] EncryptedData, 991 -- PA-OTP-ENC-REQUEST or PA-ENC-TS-ENC 992 -- Key usage of KEY_USAGE_OTP_REQUEST 993 hashAlg [3] AlgorithmIdentifier OPTIONAL, 994 iterationCount [4] Int32 OPTIONAL, 995 otp-value [5] OCTET STRING OPTIONAL, 996 otp-pin [6] UTF8String OPTIONAL, 997 otp-challenge [7] OCTET STRING (SIZE(1..MAX)) OPTIONAL, 998 otp-time [8] KerberosTime OPTIONAL, 999 otp-counter [9] OCTET STRING OPTIONAL, 1000 otp-format [10] OTPFormat OPTIONAL, 1001 otp-tokenID [11] OCTET STRING OPTIONAL, 1002 otp-algID [12] AnyURI OPTIONAL, 1003 otp-vendor [13] UTF8String OPTIONAL, 1004 ... 1005 } 1007 KEY_USAGE_OTP_REQUEST 45 1009 PA-OTP-ENC-REQUEST ::= SEQUENCE { 1010 nonce [0] OCTET STRING, 1011 ... 1012 } 1014 flags 1015 This field MUST be present. 1017 If the "nextOTP" flag is set then the OTP was calculated based on 1018 the next token "state" rather than the current one. This flag 1019 MUST be set if and only if it was set in a corresponding PA-OTP- 1020 CHALLENGE. 1022 If the "combine" flag is set then the OTP was calculated based on 1023 a challenge and the token state. 1025 No other OTPFlag bits are applicable and MUST be ignored by the 1026 KDC. 1028 nonce 1029 This field MUST be present if a hashed OTP value was used as input 1030 to string-to-key (see Section 3.6) and MUST NOT be present 1031 otherwise. If present, it MUST contain the nonce value generated 1032 by the client and used in the generation of hashed OTP values as 1033 described in Section 3.6. This nonce string MUST be as long as 1034 the longest key length of the symmetric key types that the client 1035 supports and MUST be chosen randomly. 1037 encData 1038 This field MUST be present and MUST contain the pre-authentication 1039 data encrypted under the Client Key with a key usage of 1040 KEY_USAGE_OTP_REQUEST. If the PA-OTP-REQUEST is sent as a result 1041 of a PA-OTP-CHALLENGE then this MUST contain a PA-OTP-ENC-REQUEST 1042 with the nonce from the PA-OTP-CHALLENGE. If no challenge was 1043 received then this MUST contain a PA-ENC-TS-ENC. 1045 hashAlg 1046 This field MUST be present if a hashed OTP value was used as input 1047 to string-to-key (see Section 3.6) and MUST NOT be present 1048 otherwise. If present, it MUST contain the AlgorithmIdentifier of 1049 the hash algorithm used. If the PA-OTP-REQUEST is sent as a 1050 result of a PA-OTP-CHALLENGE then the AlgorithmIdentifer MUST be 1051 the first one supported by the client from the supportedHashAlg of 1052 the PA-OTP-CHALLENGE. 1054 iterationCount 1055 This field MUST be present if a hashed OTP value was used as input 1056 to string-to-key (see Section 3.6) and MUST NOT be present 1057 otherwise. If present, it MUST contain the iteration count used 1058 when hashing the OTP value. If the PA-OTP-REQUEST is sent as a 1059 result of a PA-OTP-CHALLENGE then the value MUST NOT be less that 1060 that specified in the PA-OTP-CHALLENGE. 1062 otp-value 1063 The generated OTP value. This value MUST NOT be present if the 1064 "must-encrypt-nonce" flag was set in the PA-OTP-CHALLENGE. 1066 otp-pin 1067 The OTP PIN value entered by the user. This value MUST NOT be 1068 present unless the "separate-pin-required" flag was set in the PA- 1069 OTP-CHALLENGE. 1071 otp-challenge 1072 Value used by the client in the OTP calculation. It MUST be sent 1073 to the KDC if and only if the value would otherwise be unknown to 1074 the KDC. For example, the token or client modified or generated 1075 challenge. 1077 otp-time 1078 This field MAY be included by the client to carry the time value 1079 as reported by the OTP token. Use of this element is OPTIONAL but 1080 it MAY be used by a client to simplify the OTP calculations 1081 carried out by the KDC. It is RECOMMENDED that the KDC act upon 1082 this value if it is present in the request and it is capable of 1083 using it in the generation of the OTP value. 1085 otp-counter 1086 This field MAY be included by the client to carry the token 1087 counter value, as reported by the OTP token. Use of this element 1088 is OPTIONAL but it MAY be used by a client to simplify the OTP 1089 calculations carried out by the KDC. It is RECOMMENDED that the 1090 KDC act upon this value if it is present in the request and it is 1091 capable of using it in the generation of the OTP value. 1093 otp-format 1094 This field MAY be used by the client to send the format of the 1095 generated OTP as reported by the OTP token. Use of this element 1096 is OPTIONAL but it MAY be used by the client to simplify the OTP 1097 calculations carried out by the KDC. It is RECOMMENDED that the 1098 KDC act upon this value if it is present in the request and it is 1099 capable of using it in the generation of the OTP value. 1101 otp-tokenID 1102 This field MAY be used by the client to send the identifier of the 1103 token key used, as reported by the OTP token. Use of this field 1104 is OPTIONAL but MAY be used by the client to simplify the 1105 authentication process by identifying a particular token key 1106 associated with the user. It is RECOMMENDED that the KDC act upon 1107 this value if it is present in the request and it is capable of 1108 using it in the generation of the OTP value. 1110 otp-algID 1111 This field MAY be used by the client to send the identifier of the 1112 OTP algorithm used, as reported by the OTP token. Use of this 1113 element is OPTIONAL but it MAY be used by the client to simplify 1114 the OTP calculations carried out by the KDC. It is RECOMMENDED 1115 that the KDC act upon this value if it is present in the request 1116 and it is capable of using it in the generation of the OTP value. 1117 The value of this field MUST be a URI [RFC3986] and SHOULD be 1118 obtained from the PSKC algorithm registry [RFC6030]. 1120 otp-vendor 1121 If the PA-OTP-REQUEST is being sent in response to a PA-OTP- 1122 CHALLENGE that contained an otp-vendor field in the selected otp- 1123 tokenInfo then this field MUST be set to the same value, 1124 otherwise, this field SHOULD be set to the vendor identifier of 1125 the token if known to the client. It is RECOMMENDED that the KDC 1126 act upon this value if it is present in the request and it is 1127 capable of using it in the generation of the OTP value. 1129 4.3. PA-OTP-PIN-CHANGE 1131 The padata-type PA-OTP-PIN-CHANGE is returned by the KDC in the enc- 1132 fast-rep of a PA-FX-FAST-REPLY in the AS-REP if the user must change 1133 their PIN, if the user's PIN has been changed or to notify the user 1134 of the PIN's expiry time. 1136 The corresponding padata-value field contains the DER encoding of a 1137 PA-OTP-PIN-CHANGE. 1139 PA-OTP-PIN-CHANGE 144 1141 PA-OTP-PIN-CHANGE ::= SEQUENCE { 1142 flags [0] PinFlags, 1143 pin [1] UTF8String OPTIONAL, 1144 minLength [2] INTEGER OPTIONAL, 1145 maxLength [3] INTEGER OPTIONAL, 1146 last-req [4] LastReq OPTIONAL, 1147 format [5] OTPFormat OPTIONAL, 1148 ... 1149 } 1151 PinFlags ::= KerberosFlags 1152 -- reserved(0), 1153 -- systemSetPin(1), 1154 -- mandatory(2) 1156 flags 1157 The "systemSetPin" flag is used to indicate the type of PIN change 1158 that is taking place. If the flag is set then the user's PIN has 1159 been changed for the user by the system. If the flag is not set 1160 then the user's PIN needs to be changed by the user. 1162 If the "systemSetPin" flag is not set and the "mandatory" flag is 1163 set then user PIN change is required before the next 1164 authentication using the current OTP token. If the "mandatory" 1165 flag is not set then the user PIN change is optional. If the 1166 "systemSetPin" flag is set then the "mandatory" flag has no 1167 meaning and SHOULD be ignored by the client. 1169 pin 1170 The pin field is used to carry a new PIN value. If the 1171 "systemSetPin" flag is set then field is used to carry the new PIN 1172 value set for the user and MUST be present. If the "systemSetPin" 1173 flag is not set then use of this field OPTIONAL and MAY be used to 1174 carry a system generated PIN that MAY be used by the user when 1175 changing the PIN. 1177 minLength and maxLength 1178 Use of the minLength and maxLength fields is OPTIONAL. If the 1179 "systemSetPin" flag is not set then these fields MAY be included 1180 to pass restrictions on the size of the user selected PIN. 1182 last-req 1183 Use of the last-req field (as defined in section 5.4.2 of 1184 [RFC4120])) is OPTIONAL but MAY be included with an lr-type of 6 1185 to carry PIN expiration information. 1187 * If the "systemSetPin" flag is set then the expiration time MUST 1188 be that of the new system-set PIN. 1190 * If the "systemSetPin" flag is not set then the expiration time 1191 MUST be that of the current PIN of the token used in the 1192 authentication. 1194 The element MAY also be included with an lr-type of 7 to indicate 1195 when the OTP account will expire. 1197 format 1198 The format element MAY be included by the KDC to carry PIN format 1199 restrictions on the new PIN. 1201 * If the "systemSetPin" flag is set then the element MUST 1202 describe the format of the new system-generated PIN. 1204 * If the "systemSetPin" flag is not set then the element MUST 1205 describe restrictions on any new user generated PIN. 1207 5. IANA Considerations 1209 The OTP algorithm identifier URIs used as otp-algID values in the PA- 1210 OTP-CHALLENGE described in Section 4.1 and the PA-OTP-REQUEST 1211 described in Section 4.2 SHOULD be registered in the PSKC algorithm 1212 registry [RFC6030]. 1214 The following pre-authentication types are defined in this document: 1216 PA-OTP-CHALLENGE 141 1217 PA-OTP-REQUEST 142 1218 PA-OTP-PIN-CHANGE 144 1220 These values are currently registered in registry created by 1221 [RFC6113] but the entries will need to be updated to refer to this 1222 document. 1224 The following error codes and key usage values are defined in this 1225 document: 1227 KDC_ERR_INVALID_HASH_ALG 94 1228 KDC_ERR_INVALID_ITERATION_COUNT 95 1229 KDC_ERR_PIN_EXPIRED 96 1230 KDC_ERR_PIN_REQUIRED 97 1231 KEY_USAGE_OTP_REQUEST 45 1233 These values are currently not managed by IANA and have been 1234 accounted for. There is currently work in progress [LHA10] to define 1235 IANA registries and a registration process for these values. 1237 No other IANA actions are anticipated. 1239 6. Security Considerations 1241 6.1. Man-in-the-Middle 1243 In the system described in this document, the OTP pre-authentication 1244 protocol is tunneled within the FAST Armor channel provided by the 1245 pre-authentication framework. As described in [AsNiNy02], tunneled 1246 protocols are potentially vulnerable to man-in-the-middle attacks if 1247 the outer tunnel is compromised and it is generally considered good 1248 practice in such cases to bind the inner encryption to the outer 1249 tunnel. 1251 In order to mitigate against such attacks, the proposed system uses 1252 the outer Armor Key in the derivation of the inner Client and Reply 1253 keys and so achieve crypto-binding to the outer channel. 1255 As described in section 5.4 of [RFC6113], FAST can use an anonymous 1256 TGT obtained using anonymous PKINIT [RFC6112] [RFC4556] as the Armor 1257 Key. However, the current anonymous PKINIT proposal is open to man- 1258 in-the-middle attacks since the attacker can choose a session key 1259 such that the session key between the MITM and the real KDC is the 1260 same as the session key between the client and the MITM. 1262 As described in Section 3.6, if the OTP value is not being sent to 1263 the KDC then the Armor Key is used along with the OTP value in the 1264 generation of the Client Key and Reply Key. If the Armor Key is known 1265 then the only entropy remaining in the key generation is provided by 1266 the OTP value. If the OTP algorithm requires that the OTP value be 1267 sent to the KDC then it is sent encrypted within the tunnel provided 1268 by the FAST armor and so is exposed to the attacker if the attacker 1269 has the Armor Key. 1271 Therefore, unless the identity of the KDC has been verified, 1272 anonymous PKINIT SHALL NOT be used with OTP algorithms that require 1273 the OTP value to be sent to the KDC. In addition, the security 1274 considerations should be carefully considered before anonymous PKINIT 1275 is used with other algorithms such as those with short OTP values. 1277 Careful consideration should also be made if host key armor is used 1278 to provide the KDC-authentication facility with OTP algorithms where 1279 the OTP value is sent within the otp-value field of the PA-OTP- 1280 REQUEST since compromised host keys would allow an attacker to 1281 impersonate the KDC. 1283 6.2. Reflection 1285 The 4-pass system described above is a challenge-response protocol 1286 and such protocols are potentially vulnerable to reflection attacks. 1287 No such attacks are known at this point but to help mitigate against 1288 such attacks, the system uses different keys to encrypt the client 1289 and server nonces. 1291 6.3. Denial of Service 1293 The protocol supports the use of an iteration count in the generation 1294 of the Client and Reply keys and the client can send the number of 1295 iterations used as part of the PA-OTP-REQUEST. This could open the 1296 KDC up to a denial of service attack if a large value for the 1297 iteration count was specified by the attacker. It is therefore 1298 particularly important that, as described in Section 3.4, the KDC 1299 reject any authentication requests where the iteration count is above 1300 a maximum value specified by local policy. 1302 6.4. Replay 1304 In the 4-pass version of this protocol, the client encrypts a KDC 1305 generated nonce and so replay can be detected by the KDC. The 2-pass 1306 version of the protocol does not involve a server nonce but the 1307 client instead encrypts a timestamp and so is not protected from 1308 replay in this way but will instead require some other mechanism such 1309 as an OTP-server based system or a timestamp-based replay cache on 1310 the KDC. 1312 As described in section 5.2 of [RFC6113], a client can not be certain 1313 that it will use the same KDC for all messages in a conversation. 1314 Therefore, the client cannot assume that the PA-OTP-REQUEST will be 1315 sent to the same KDC that issued the PA-OTP-CHALLENGE. In order to 1316 support this, a KDC implementing this protocol requires a means of 1317 sharing session state. However, doing this does introduce the 1318 possibility of a replay attack where the same response is sent to 1319 multiple KDCs. 1321 In the case of time or event-based tokens or server-generated 1322 challenges, protection against replay may be provided by the OTP 1323 server being used if that server is capable of keeping track of the 1324 last used value. This protection therefore relies upon the 1325 assumption that the OTP server being used in this protocol is either 1326 not redundant or involves a commit protocol to synchronize between 1327 replicas. If this does not hold for an OTP server being used then 1328 the system may be vulnerable to replay attack. 1330 However, OTP servers may not be able to detect replay of OTPs 1331 generated using only a client generated challenge and since the KDC 1332 would not be able to detect replay in 2-pass mode, it is recommended 1333 that the use of OTPs generated from only a client-generated challenge 1334 (that is, not in combination with some other factor such as time) 1335 should not be supported in 2-pass mode. 1337 6.5. Brute Force Attack 1339 A compromised or hostile KDC may be able to obtain the OTP value used 1340 by the client via a brute force attack. If the OTP value is short 1341 then the KDC could iterate over the possible OTP values until a 1342 Client Key is generated that can decrypt the encData sent in the PA- 1343 OTP-REQUEST. 1345 As described in Section 3.6, an iteration count can be used in the 1346 generation of the Client Key and the value of the iteration count can 1347 be controlled by local client policy. Use of this iteration count 1348 can make it computationally infeasible/unattractive for an attacker 1349 to brute-force search for the given OTP within the lifetime of that 1350 OTP. 1352 If PINs contain international characters, similar looking or similar 1353 functioning characters may be mapped together. For example, the 1354 combined and decomposed forms of accented characters will typically 1355 be treated the same. Users who attempt to exploit artifacts of 1356 international characters to improve the strength of their PINs may 1357 experience false positives in the sense that PINs they intended to be 1358 distinct are not actually distinct. This decision was made in order 1359 to improve usability across the widest variety of input methods. 1360 Users can choose other methods to add strength to PINs. 1362 6.6. FAST Facilities 1364 The secret used to generate the OTP is known only to the client and 1365 the KDC and so successful decryption of the encrypted nonce by the 1366 KDC authenticates the user. If the OTP value is used in the Reply 1367 Key generation then successful decryption of the encrypted nonce by 1368 the client proves that the expected KDC replied. The Reply Key is 1369 replaced by either a key generated from the OTP and Armor Key or by 1370 the Armor Key. This FAST factor therefore provides the following 1371 facilities: client-authentication, replacing-reply-key and, depending 1372 on the OTP algorithm, KDC-authentication. 1374 7. Acknowledgments 1376 Many significant contributions were made to this document by RSA 1377 employees but special thanks go to Magnus Nystrom, John Linn, Richard 1378 Zhang, Piers Bowness, Robert Philpott, Robert Polansky and Boris 1379 Khoutorski. 1381 Many valuable suggestions were also made by members of the Kerberos 1382 Working Group but special thanks go to Larry Zhu, Jeffrey Hutzelman, 1383 Tim Alsop, Henry Hotz, Nicolas Williams, Sam Hartman, Frank Cusak, 1384 Simon Josefsson, Greg Hudson and Linus Nordberg. 1386 I would also like to thank Tim Alsop and Srinivas Cheruku of 1387 CyberSafe for many valuable review comments. 1389 8. References 1390 8.1. Normative References 1392 [ISOIEC7812] 1393 ISO, "ISO/IEC 7812-1:2006 Identification cards -- 1394 Identification of issuers -- Part 1: Numbering system", 1395 October 2006, . 1398 [RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail 1399 Extensions (MIME) Part One: Format of Internet Message 1400 Bodies", RFC 2045, November 1996. 1402 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1403 Requirement Levels", BCP 14, RFC 2119, March 1997. 1405 [RFC3961] Raeburn, K., "Encryption and Checksum Specifications for 1406 Kerberos 5", RFC 3961, February 2005. 1408 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 1409 Resource Identifier (URI): Generic Syntax", STD 66, 1410 RFC 3986, January 2005. 1412 [RFC4013] Zeilenga, K., "SASLprep: Stringprep Profile for User Names 1413 and Passwords", RFC 4013, February 2005. 1415 [RFC4086] Eastlake, D., Schiller, J., and S. Crocker, "Randomness 1416 Requirements for Security", BCP 106, RFC 4086, June 2005. 1418 [RFC4120] Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The 1419 Kerberos Network Authentication Service (V5)", RFC 4120, 1420 July 2005. 1422 [RFC4556] Zhu, L. and B. Tung, "Public Key Cryptography for Initial 1423 Authentication in Kerberos (PKINIT)", RFC 4556, June 2006. 1425 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 1426 Housley, R., and W. Polk, "Internet X.509 Public Key 1427 Infrastructure Certificate and Certificate Revocation List 1428 (CRL) Profile", RFC 5280, May 2008. 1430 [RFC6112] Zhu, L., Leach, P., and S. Hartman, "Anonymity Support for 1431 Kerberos", RFC 6112, April 2011. 1433 [RFC6113] Hartman, S. and L. Zhu, "A Generalized Framework for 1434 Kerberos Pre-Authentication", RFC 6113, April 2011. 1436 [X.680] ITU-T, "Recommendation X.680 (2002) | ISO/IEC 8824-1:2002, 1437 Information technology - Abstract Syntax Notation One 1438 (ASN.1): Specification of basic notation.", July 2002. 1440 [X.690] ITU-T, "Recommendation X.690 (2002) | ISO/IEC 8825-1:2002, 1441 Information technology - ASN.1 encoding Rules: 1442 Specification of Basic Encoding Rules (BER), Canonical 1443 Encoding Rules (CER) and Distinguished Encoding Rules 1444 (DER).", December 2002. 1446 8.2. Informative References 1448 [AsNiNy02] 1449 Asokan, N., Niemi, V., and K. Nyberg, "Man-in-the-Middle 1450 in Tunneled Authentication Protocols", Cryptology ePrint 1451 Archive Report 2002/163, November 2002. 1453 [HoReNeZo04] 1454 Horstein, K., Renard, K., Neuman, C., and G. Zorn, 1455 "Integrating Single-use Authentication Mechanisms with 1456 Kerberos", draft-ietf-krb-wg-kerberos-sam-03 (work in 1457 progress), July 2004. 1459 [LHA10] Hornquist Astrand, L., "Kerberos number registry to IANA", 1460 draft-lha-krb-wg-some-numbers-to-iana-00 (work in 1461 progress), March 2010. 1463 [RFC2289] Haller, N., Metz, C., Nesser, P., and M. Straw, "A One- 1464 Time Password System", RFC 2289, February 1998. 1466 [RFC2808] Nystrom, M., "The SecurID(r) SASL Mechanism", RFC 2808, 1467 April 2000. 1469 [RFC4226] M'Raihi, D., Bellare, M., Hoornaert, F., Naccache, D., and 1470 O. Ranen, "HOTP: An HMAC-Based One-Time Password 1471 Algorithm", RFC 4226, December 2005. 1473 [RFC6030] Hoyer, P., Pei, M., and S. Machani, "Portable Symmetric 1474 Key Container (PSKC)", RFC 6030, October 2010. 1476 Appendix A. ASN.1 Module 1478 OTPKerberos 1479 DEFINITIONS IMPLICIT TAGS ::= 1480 BEGIN 1482 IMPORTS 1484 KerberosTime, KerberosFlags, EncryptionKey, Int32, 1485 EncryptedData, LastReq, KerberosString 1486 FROM KerberosV5Spec2 {iso(1) identified-organization(3) 1487 dod(6) internet(1) security(5) 1488 kerberosV5(2) modules(4) krb5spec2(2)} 1489 -- as defined in RFC 4120. 1490 AlgorithmIdentifier 1491 FROM PKIX1Explicit88 { iso (1) identified-organization (3) 1492 dod (6) internet (1) 1493 security (5) mechanisms (5) pkix (7) 1494 id-mod (0) id-pkix1-explicit (18) }; 1495 -- As defined in RFC 5280. 1497 PA-OTP-CHALLENGE ::= SEQUENCE { 1498 nonce [0] OCTET STRING, 1499 otp-service [1] UTF8String OPTIONAL, 1500 otp-tokenInfo [2] SEQUENCE (SIZE(1..MAX)) OF 1501 OTP-TOKENINFO, 1502 salt [3] KerberosString OPTIONAL, 1503 s2kparams [4] OCTET STRING OPTIONAL, 1504 ... 1505 } 1507 OTP-TOKENINFO ::= SEQUENCE { 1508 flags [0] OTPFlags, 1509 otp-vendor [1] UTF8String OPTIONAL, 1510 otp-challenge [2] OCTET STRING (SIZE(1..MAX)) 1511 OPTIONAL, 1512 otp-length [3] Int32 OPTIONAL, 1513 otp-format [4] OTPFormat OPTIONAL, 1514 otp-tokenID [5] OCTET STRING OPTIONAL, 1515 otp-algID [6] AnyURI OPTIONAL, 1516 supportedHashAlg [7] SEQUENCE OF AlgorithmIdentifier 1517 OPTIONAL, 1518 iterationCount [8] Int32 OPTIONAL, 1519 ... 1520 } 1522 OTPFormat ::= INTEGER { 1523 decimal(0), 1524 hexadecimal(1), 1525 alphanumeric(2), 1526 binary(3), 1527 base64(4) 1528 } 1530 OTPFlags ::= KerberosFlags 1531 -- reserved(0), 1532 -- nextOTP(1), 1533 -- combine(2), 1534 -- collect-pin(3), 1535 -- do-not-collect-pin(4), 1536 -- must-encrypt-nonce (5), 1537 -- separate-pin-required (6), 1538 -- check-digit (7) 1540 PA-OTP-REQUEST ::= SEQUENCE { 1541 flags [0] OTPFlags, 1542 nonce [1] OCTET STRING OPTIONAL, 1543 encData [2] EncryptedData, 1544 -- PA-OTP-ENC-REQUEST or PA-ENC-TS-ENC 1545 -- Key usage of KEY_USAGE_OTP_REQUEST 1546 hashAlg [3] AlgorithmIdentifier OPTIONAL, 1547 iterationCount [4] Int32 OPTIONAL, 1548 otp-value [5] OCTET STRING OPTIONAL, 1549 otp-pin [6] UTF8String OPTIONAL, 1550 otp-challenge [7] OCTET STRING (SIZE(1..MAX)) OPTIONAL, 1551 otp-time [8] KerberosTime OPTIONAL, 1552 otp-counter [9] OCTET STRING OPTIONAL, 1553 otp-format [10] OTPFormat OPTIONAL, 1554 otp-tokenID [11] OCTET STRING OPTIONAL, 1555 otp-algID [12] AnyURI OPTIONAL, 1556 otp-vendor [13] UTF8String OPTIONAL, 1557 ... 1558 } 1560 PA-OTP-ENC-REQUEST ::= SEQUENCE { 1561 nonce [0] OCTET STRING, 1562 ... 1563 } 1565 PA-OTP-PIN-CHANGE ::= SEQUENCE { 1566 flags [0] PinFlags, 1567 pin [1] UTF8String OPTIONAL, 1568 minLength [2] INTEGER OPTIONAL, 1569 maxLength [3] INTEGER OPTIONAL, 1570 last-req [4] LastReq OPTIONAL, 1571 format [5] OTPFormat OPTIONAL, 1572 ... 1573 } 1575 PinFlags ::= KerberosFlags 1576 -- reserved(0), 1577 -- systemSetPin(1), 1578 -- mandatory(2) 1579 AnyURI ::= UTF8String 1580 (CONSTRAINED BY { 1581 -- MUST be a valid URI in accordance with IETF RFC 2396 1582 }) 1584 END 1586 Appendix B. Examples of OTP Pre-Authentication Exchanges 1588 This section is non-normative. 1590 B.1. Four Pass Authentication 1592 In this mode, the client sends an initial AS-REQ to the KDC that does 1593 not contain a PA-OTP-REQUEST and the KDC responds with a KRB-ERROR 1594 containing a PA-OTP-CHALLENGE. 1596 In this example, the user has been issued with a connected, time- 1597 based token and the KDC requires hashed OTP values in the key 1598 generation with SHA-384 as the preferred hash algorithm and a minimum 1599 of 1024 iterations. The local policy on the client supports SHA-256 1600 and requires 100,000 iterations of the hash of the OTP value. 1602 The basic sequence of steps involved is as follows: 1604 1. The client obtains the user name of the user. 1606 2. The client sends an initial AS-REQ to the KDC that does not 1607 contain a PA-OTP-REQUEST. 1609 3. The KDC determines that the user identified by the AS-REQ 1610 requires OTP authentication. 1612 4. The KDC constructs a PA-OTP-CHALLENGE as follows: 1614 nonce 1615 A randomly generated value. 1617 otp-service 1618 A string that can be used by the client to assist the user in 1619 locating the correct token. 1621 otp-tokenInfo 1622 Information about how the OTP should be generated from the 1623 token. 1625 flags 1626 must-encrypt-nonce and collect-pin bits set 1628 supportedHashAlg 1629 AlgorithmIdentifiers for SHA-384, SHA-256 and SHA-1 1631 iterationCount 1632 1024 1634 5. The KDC returns a KRB-ERROR with an error code of 1635 KDC_ERR_PREAUTH_REQUIRED and the PA-OTP-CHALLENGE in the e-data. 1637 6. The client displays the value of otp-service and prompts the 1638 user to connect the token. 1640 7. The client collects a PIN from the user. 1642 8. The client obtains the current OTP value from the token using 1643 the PIN and records the time as reported by the token. 1645 9. The client generates the Client Key and Reply Key as described 1646 in Section 3.6 using SHA-256 from the list of algorithms sent by 1647 the KDC, the iteration count of 100,000 as required by local 1648 policy and a randomly generated nonce. 1650 10. The client constructs a PA-OTP-REQUEST as follows: 1652 flags 1653 0 1655 nonce 1656 The randomly generated value. 1658 encData 1659 An EncryptedData containing a PA-OTP-ENC-REQUEST encrypted 1660 under the Client Key with a key usage of 1661 KEY_USAGE_OTP_REQUEST and the encryption type of the Armor 1662 Key. The PA-OTP-ENC-REQUEST contains the nonce from the PA- 1663 OTP-CHALLENGE. 1665 hashAlg 1666 SHA-256 1668 iterationCount 1669 100,000 1671 otp-time 1672 The time used in the OTP calculation as reported by the OTP 1673 token. 1675 11. The client encrypts the PA-OTP-REQUEST within the enc-fast-req 1676 of a PA-FX-FAST-REQUEST. 1678 12. The client sends an AS-REQ to the KDC containing the PA-FX-FAST- 1679 REQUEST within the padata. 1681 13. The KDC validates the pre-authentication data in the PA-OTP- 1682 REQUEST: 1684 * Generates the Client Key and Reply Key from the OTP value for 1685 the user identified in the AS-REQ, using an iteration count 1686 of 100,000, a hash algorithm of SHA-256 and the nonce as 1687 specified in the PA-OTP-REQUEST. 1689 * Uses the generated Client Key to decrypt the PA-OTP-ENC- 1690 REQUEST in the encData of the PA-OTP-REQUEST. 1692 * Authenticates the user by comparing the nonce value from the 1693 decrypted PA-OTP-ENC-REQUEST to that sent in the 1694 corresponding PA-OTP-CHALLENGE. 1696 14. The KDC constructs a TGT for the user. 1698 15. The KDC returns an AS-REP to the client, encrypted using the 1699 Reply Key, containing the TGT and padata with the PA-FX-FAST- 1700 REPLY. 1702 16. The client authenticates the KDC and verifies the Reply Key 1703 change. 1705 * Uses the generated Reply Key to decrypt the encrypted data in 1706 the AS-REP. 1708 B.2. Two Pass Authentication 1710 In this mode, the client includes a PA-OTP-REQUEST within a PA-FX- 1711 FAST-REQUEST pre-auth of the initial AS-REQ sent to the KDC. 1713 In this example, the user has been issued with a hand-held token and 1714 so none of the OTP generation parameters (otp-length etc) are 1715 included in the PA-OTP-REQUEST. The KDC does not require hashed OTP 1716 values in the key generation. 1718 It is assumed that the client has been configured with the following 1719 information or has obtained it from a previous PA-OTP-CHALLENGE. 1720 o The fact that the OTP value must not be carried in the otp-value 1721 o The fact that hashed OTP values are not required. 1723 The basic sequence of steps involved is as follows: 1725 1. The client obtains the user name and OTP value from the user. 1727 2. The client generates the Client Key and Reply Key using unhashed 1728 OTP values as described in Section 3.6. 1730 3. The client constructs a PA-OTP-REQUEST as follows: 1732 flags 1733 0 1735 encData 1736 An EncryptedData containing a PA-ENC-TS-ENC encrypted under 1737 the Client Key with a key usage of KEY_USAGE_OTP_REQUEST and 1738 an encryption type of the Armor Key. The PA-ENC-TS-ENC 1739 contains the current client time. 1741 4. The client encrypts the PA-OTP-REQUEST within the enc-fast-req of 1742 a PA-FX-FAST-REQUEST. 1744 5. The client sends an AS-REQ to the KDC containing the PA-FX-FAST- 1745 REQUEST within the padata. 1747 6. The KDC validates the pre-authentication data: 1749 * Generates the Client Key and Reply Key from the unhashed OTP 1750 value for the user identified in the AS-REQ. 1752 * Uses the generated Client Key to decrypt the PA-ENC-TS-ENC in 1753 the encData of the PA-OTP-REQUEST. 1755 * Authenticates the user using the timestamp in the standard 1756 manner. 1758 7. The KDC constructs a TGT for the user. 1760 8. The KDC returns an AS-REP to the client, encrypted using the 1761 Reply Key, containing the TGT and padata with the PA-FX-FAST- 1762 REPLY. 1764 9. The client authenticates the KDC and verifies the key change. 1766 * Uses the generated Reply Key to decrypt the encrypted data in 1767 the AS-REP. 1769 B.3. PIN Change 1771 This exchange follows from the point where the KDC receives the PA- 1772 OTP-REQUEST from the client in the examples in Appendix B.1 and 1773 Appendix B.2. During the validation of the pre-authentication data 1774 (whether encrypted nonce or encrypted timestamp), the KDC determines 1775 that the user's PIN has expired and so must be changed. The KDC 1776 therefore includes a PA-OTP-PIN-CHANGE in the AS-REP. 1778 In this example, the KDC does not generate PIN values for the user 1779 but requires that the user generate a new PIN that is between 4 and 8 1780 characters in length. The actual PIN change is handled by a PIN 1781 change service. 1783 The basic sequence of steps involved is as follows: 1785 1. The client constructs and sends a PA-OTP-REQUEST to the KDC as 1786 described in the previous examples. 1788 2. The KDC validates the pre-authentication data and authenticates 1789 the user as in the previous examples but determines that the 1790 user's PIN has expired. 1792 3. KDC constructs a ticket for a PIN change service with a one 1793 minute lifetime. 1795 4. KDC constructs a PA-OTP-PIN-CHANGE as follows: 1797 flags 1798 0 1800 minLength 1801 4 1803 maxLength 1804 8 1806 5. KDC encrypts the PA-OTP-PIN-CHANGE within the enc-fast-rep of a 1807 PA-FX-FAST-REPLY. 1809 6. KDC returns a KRB-ERROR to the client of type KDC_ERR_PIN_EXPIRED 1810 containing the ticket to the PIN change service and padata 1811 containing the PA-FX-FAST-REPLY. 1813 7. The client uses the ticket requests a ticket for a PIN change 1814 service and changes the user's PIN. 1816 8. The client sends a second AS-REQ to the KDC containing a PA-OTP- 1817 REQUEST constructed using the new PIN. 1819 9. The KDC responds with an AS-REP containing a TGT. 1821 B.4. Resynchronization 1823 This exchange follows from the point where the KDC receives the PA- 1824 OTP-REQUEST from the client. During the validation of the pre- 1825 authentication data (whether encrypted nonce or encrypted timestamp), 1826 the KDC determines that the local record of the token's state needs 1827 to be re-synchronized with the token. The KDC therefore includes a 1828 KRB-ERROR containing a PA-OTP-CHALLENGE with the "nextOTP" flag set. 1830 The sequence of steps below follows is a variation of the four pass 1831 examples shown in Appendix B.1 but the same process would also work 1832 in the two-pass case. 1834 1. The client constructs and sends a PA-OTP-REQUEST to the KDC as 1835 described in the previous examples. 1837 2. The KDC validates the pre-authentication data and authenticates 1838 the user as in the previous examples but determines that user's 1839 token requires re-synchronizing. 1841 3. KDC constructs a PA-OTP-CHALLENGE as follows: 1843 nonce 1844 A randomly generated value. 1846 otp-service 1847 Set to a string that can be used by the client to assist the 1848 user in locating the correct token. 1850 otp-tokenInfo 1851 Information about how the OTP should be generated from the 1852 token. 1854 flags 1855 must-encrypt-nonce, collect-pin and nextOTP bits set 1857 supportedHashAlg 1858 AlgorithmIdentifiers for SHA-256 and SHA-1 1860 iterationCount 1861 1024 1863 4. KDC returns a KRB-ERROR with an error code of 1864 KDC_ERR_PREAUTH_REQUIRED and the PA-OTP-CHALLENGE in the e-data. 1866 5. The client obtains the next OTP value from the token and records 1867 the time as reported by the token. 1869 6. The client generates the Client Key and Reply Key as described 1870 in Section 3.6 using SHA-256 from the list of algorithms sent by 1871 the KDC, the iteration count of 100,000 as required by local 1872 policy and a randomly generated nonce. 1874 7. The client constructs a PA-OTP-REQUEST as follows: 1876 flags 1877 nextOTP bit set 1879 nonce 1880 The randomly generated value. 1882 encData 1883 An EncryptedData containing a PA-OTP-ENC-REQUEST encrypted 1884 under the Client Key with a key usage of 1885 KEY_USAGE_OTP_REQUEST and the encryption type of the Armor 1886 Key. The PA-OTP-ENC-REQUEST contains the nonce from the PA- 1887 OTP-CHALLENGE. 1889 hashAlg 1890 SHA-256 1892 iterationCount 1893 100,000 1895 otp-time 1896 The time used in the OTP calculation as reported by the OTP 1897 token. 1899 8. The client encrypts the PA-OTP-REQUEST within the enc-fast-req 1900 of a PA-FX-FAST-REQUEST. 1902 9. The client sends an AS-REQ to the KDC containing the PA-FX-FAST- 1903 REQUEST within the padata. 1905 10. Authentication process now proceeds as with the classic 1906 sequence. 1908 Author's Address 1910 Gareth Richards 1911 RSA, The Security Division of EMC 1912 RSA House 1913 Western Road 1914 Bracknell, Berkshire RG12 1RT 1915 UK 1917 Email: gareth.richards@rsa.com