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