1INTERNET-DRAFT                                        Jonathan Trostle
2draft-ietf-cat-kerberos-extra-tgt-02.txt              Cisco Systems
3Updates: RFC 1510                                     Michael M. Swift
4expires January 30, 2000                              University of WA
5
6
7    Extension to Kerberos V5 For Additional Initial Encryption
8
90. Status Of This Memo
10
11   This document is an Internet-Draft and is in full conformance
12   with all provisions of Section 10 of RFC2026.
13
14   Internet-Drafts are working documents of the Internet Engineering
15   Task Force (IETF), its areas, and its working groups.  Note that
16   other groups may also distribute working documents as
17   Internet-Drafts.
18
19   Internet-Drafts are draft documents valid for a maximum of six
20   months and may be updated, replaced, or obsoleted by other
21   documents at any time.  It is inappropriate to use Internet-
22   Drafts as reference material or to cite them other than as
23   "work in progress."
24
25   The list of current Internet-Drafts can be accessed at
26   http://www.ietf.org/ietf/1id-abstracts.txt
27
28   The list of Internet-Draft Shadow Directories can be accessed at
29   http://www.ietf.org/shadow.html.
30
311. Abstract
32
33   This document defines an extension to the Kerberos protocol
34   specification (RFC 1510) [1] to enable a preauthentication field in
35   the AS_REQ message to carry a ticket granting ticket. The session
36   key from this ticket granting ticket will be used to
37   cryptographically strengthen the initial exchange in either the
38   conventional Kerberos V5 case or in the case the user stores their
39   encrypted private key on the KDC [2].
40
41
422. Motivation
43
44   In Kerberos V5, the initial exchange with the KDC consists of the
45   AS_REQ and AS_REP messages. For users, the encrypted part of the
46   AS_REP message is encrypted in a key derived from a password.
47   Although a password policy may be in place to prevent dictionary
48   attacks, brute force attacks may still be a concern due to
49   insufficient key length.
50
51   This draft specifies an extension to the Kerberos V5 protocol to
52   allow a ticket granting ticket to be included in an AS_REQ message
53   preauthentication field. The session key from this ticket granting
54   ticket will be used to cryptographically strengthen the initial
55
56   exchange in either the conventional Kerberos V5 case or in the case
57   the user stores their encrypted private key on the KDC [2]. The
58   session key from the ticket granting ticket is combined with the
59   user password key (key K2 in the encrypted private key on KDC
60   option) using HMAC to obtain a new triple des key that is used in
61   place of the user key in the initial exchange. The ticket granting
62   ticket could be obtained by the workstation using its host key.
63
643. The Extension
65
66   The following new preauthentication type is proposed:
67
68      PA-EXTRA-TGT                         22
69
70   The preauthentication-data field contains a ticket granting ticket
71   encoded as an ASN.1 octet string. The server realm of the ticket
72   granting ticket must be equal to the realm in the KDC-REQ-BODY of
73   the AS_REQ message. In the absence of a trust relationship, the
74   local Kerberos client should send the AS_REQ message without this
75   extension.
76
77   In the conventional (non-pkinit) case, we require the RFC 1510
78   PA-ENC-TIMESTAMP preauthentication field in the AS_REQ message.
79   If neither it or the PA-PK-KEY-REQ preauthentication field is
80   included in the AS_REQ message, the KDC will reply with a
81   KDC_ERR_PREAUTH_FAILED error message.
82
83   We propose the following new etypes:
84
85     des3-cbc-md5-xor                              16
86     des3-cbc-sha1-xor                             17
87
88   The encryption key is obtained by:
89
90   (1) Obtaining an output M from the HMAC-SHA1 function [3] using
91       the user password key (the key K2 in the encrypted private
92       key on KDC option of pkinit) as the text and the triple des
93       session key as the K input in HMAC:
94
95       M = H(K XOR opad, H(K XOR ipad, text)) where H = SHA1.
96
97       The session key from the accompanying ticket granting ticket
98       must be a triple des key when one of the triple des xor
99       encryption types is used.
100   (2) Concatenate the output M (20 bytes) with the first 8 non-parity
101       bits of the triple-des ticket granting ticket session key to
102       get 168 bits that will be used for the new triple-des encryption
103       key.
104   (3) Set the parity bits of the resulting key.
105
106   The resulting triple des key is used to encrypt the timestamp
107   for the PA-ENC-TIMESTAMP preauthentication value (or in the
108   encrypted private key on KDC option of pkinit, it is used in
109   place of the key K2 to both sign in the PA-PK-KEY-REQ and for
110   encryption in the PA-PK-KEY-REP preauthentication types).
111
112   If the KDC decrypts the encrypted timestamp and it is not within
113   the appropriate clock skew period, the KDC will reply with the
114   KDC_ERR_PREAUTH_FAILED error. The same error will also be sent if
115   the above ticket granting ticket fails to decrypt properly, or if
116   it is not a valid ticket.
117
118   The KDC will create the shared triple des key from the ticket
119   granting ticket session key and the user password key (the key K2
120   in the encrypted private key on KDC case) using HMAC as specified
121   above and use it to validate the AS_REQ message and then to
122   encrypt the encrypted part of the AS_REP message (use it in place
123   of the key K2 for encryption in the PA-PK-KEY-REP preauthentication
124   field).
125
126   Local workstation policy will determine the exact behaviour of
127   the Kerberos client with respect to the extension protocol. For
128   example, the client should consult policy to decide when to use
129   use the extension. This policy could be dependent on the user
130   identity, or whether the workstation is in the same realm as the
131   user. One possibility is for the workstation logon to fail if
132   the extension is not used. Another possibility is for the KDC
133   to set a flag in tickets issued when this extension is used.
134
135   A similar idea was proposed in OSF DCE RFC 26.0 [4]; there a
136   preauthentication field containing a ticket granting ticket,
137   a randomly generated subkey encrypted in the session key from
138   the ticket, and a timestamp structure encrypted in the user
139   password and then the randomly generated subkey was proposed.
140   Some advantages of the current proposal are that the KDC has two
141   fewer decryptions to perform per request and the client does not
142   have to generate a random key.
143
1444. Bibliography
145
146   [1] J. Kohl, C. Neuman. The Kerberos Network Authentication
147   Service (V5). Request for Comments 1510.
148
149   [2] B. Tung, C. Neuman, J. Wray, A. Medvinsky, M. Hur, J. Trostle.
150   Public Key Cryptography for Initial Authentication in Kerberos.
151   ftp://ds.internic.net/internet-drafts/
152   draft-ietf-cat-kerberos-pkinit-08.txt
153
154   [3] H. Krawczyk, M. Bellare, R. Canetti. HMAC: Keyed-Hashing for
155   Message Authentication. Request for Comments 2104.
156
157   [4] J. Pato. Using Pre-authentication to Avoid Password Guessing
158   Attacks. OSF DCE SIG Request for Comments 26.0.
159
1605. Acknowledgement: We thank Ken Hornstein for some helpful comments.
161
1626. Expires January 30, 2000.
163
1647. Authors' Addresses
165
166   Jonathan Trostle
167   170 W. Tasman Dr.
168   San Jose, CA 95134, U.S.A.
169
170   Email: jtrostle@cisco.com
171   Phone: (408) 527-6201
172
173   Michael Swift
174   Email: mikesw@cs.washington.edu
175