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