1
2
3
4
5
6Network Working Group                                        M. Horowitz
7<draft-ietf-cat-kerb-key-derivation-00.txt>             Cygnus Solutions
8Internet-Draft                                            November, 1996
9
10
11                     Key Derivation for Kerberos V5
12
13Status of this Memo
14
15   This document is an Internet-Draft.  Internet-Drafts are working
16   documents of the Internet Engineering Task Force (IETF), its areas,
17   and its working groups.  Note that other groups may also distribute
18   working documents as Internet-Drafts.
19
20   Internet-Drafts are draft documents valid for a maximum of six months
21   and may be updated, replaced, or obsoleted by other documents at any
22   time.  It is inappropriate to use Internet-Drafts as reference
23   material or to cite them other than as ``work in progress.''
24
25   To learn the current status of any Internet-Draft, please check the
26   ``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow
27   Directories on ds.internic.net (US East Coast), nic.nordu.net
28   (Europe), ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific
29   Rim).
30
31   Distribution of this memo is unlimited.  Please send comments to the
32   <cat-ietf@mit.edu> mailing list.
33
34Abstract
35
36   In the Kerberos protocol [RFC1510], cryptographic keys are used in a
37   number of places.  In order to minimize the effect of compromising a
38   key, it is desirable to use a different key for each of these places.
39   Key derivation [Horowitz96] can be used to construct different keys
40   for each operation from the keys transported on the network.  For
41   this to be possible, a small change to the specification is
42   necessary.
43
44
45Overview
46
47   Under RFC1510 as stated, key derivation could be specified as a set
48   of encryption types which share the same key type.  The constant for
49   each derivation would be a function of the encryption type.  However,
50   it is generally accepted that, for interoperability, key types and
51   encryption types must map one-to-one onto each other.  (RFC 1510 is
52   being revised to address this issue.)  Therefore, to use key
53   derivcation with Kerberos V5 requires a small change to the
54   specification.
55
56   For each place where a key is used in Kerberos, a ``key usage'' must
57   be specified for that purpose.  The key, key usage, and
58   encryption/checksum type together describe the transformation from
59   plaintext to ciphertext, or plaintext to checksum.  For backward
60
61
62
63Horowitz                                                        [Page 1]
64
65Internet Draft       Key Derivation for Kerberos V5       November, 1996
66
67
68   compatibility, old encryption types would be defined independently of
69   the key usage.
70
71
72Key Usage Values
73
74   This is a complete list of places keys are used in the kerberos
75   protocol, with key usage values and RFC 1510 section numbers:
76
77      1.  AS-REQ PA-ENC-TIMESTAMP padata timestamp, encrypted with the
78          client key (section 5.4.1)
79      2.  AS-REP Ticket and TGS-REP Ticket (includes tgs session key or
80          application session key), encrypted with the service key
81          (section 5.4.2)
82      3.  AS-REP encrypted part (includes tgs session key or application
83          session key), encrypted with the client key (section 5.4.2)
84
85      4.  TGS-REQ KDC-REQ-BODY AuthorizationData, encrypted with the tgs
86          session key (section 5.4.1)
87      5.  TGS-REQ KDC-REQ-BODY AuthorizationData, encrypted with the tgs
88          authenticator subkey (section 5.4.1)
89      6.  TGS-REQ PA-TGS-REQ padata AP-REQ Authenticator cksum, keyed
90          with the tgs session key (sections 5.3.2, 5.4.1)
91      7.  TGS-REQ PA-TGS-REQ padata AP-REQ Authenticator (includes tgs
92          authenticator subkey), encrypted with the tgs session key
93          (section 5.3.2)
94      8.  TGS-REP encrypted part (includes application session key),
95          encrypted with the tgs session key (section 5.4.2)
96      9.  TGS-REP encrypted part (includes application session key),
97          encrypted with the tgs authenticator subkey (section 5.4.2)
98
99      10. AP-REQ Authenticator cksum, keyed with the application session
100          key (section 5.3.2)
101      11. AP-REQ Authenticator (includes application authenticator
102          subkey), encrypted with the application session key (section
103          5.3.2)
104      12. AP-REP encrypted part (includes application session subkey),
105          encrypted with the application session key (section 5.5.2)
106
107      13. KRB-PRIV encrypted part, encrypted with a key chosen by the
108          application (section 5.7.1)
109      14. KRB-CRED encrypted part, encrypted with a key chosen by the
110          application (section 5.6.1)
111      15. KRB-SAVE cksum, keyed with a key chosen by the application
112          (section 5.8.1)
113
114      16. Data which is defined in some specification outside of
115          Kerberos to be encrypted using an RFC1510 encryption type.
116      17. Data which is defined in some specification outside of
117          Kerberos to be checksummed using an RFC1510 checksum type.
118
119   A few of these key usages need a little clarification.  A service
120   which receives an AP-REQ has no way to know if the enclosed Ticket
121   was part of an AS-REP or TGS-REP.  Therefore, key usage 2 must always
122
123
124
125Horowitz                                                        [Page 2]
126
127Internet Draft       Key Derivation for Kerberos V5       November, 1996
128
129
130   be used for generating a Ticket, whether it is in response to an AS-
131   REQ or TGS-REQ.
132
133   There might exist other documents which define protocols in terms of
134   the RFC1510 encryption types or checksum types.  Such documents would
135   not know about key usages.  In order that these documents continue to
136   be meaningful until they are updated, key usages 16 and 17 must be
137   used to derive keys for encryption and checksums, respectively.  New
138   protocols defined in terms of the Kerberos encryption and checksum
139   types should use their own key usages.  Key usages may be registered
140   with IANA to avoid conflicts.  Key usages shall be unsigned 32 bit
141   integers.  Zero is not permitted.
142
143
144Defining Cryptosystems Using Key Derivation
145
146   Kerberos requires that the ciphertext component of EncryptedData be
147   tamper-resistant as well as confidential.  This implies encryption
148   and integrity functions, which must each use their own separate keys.
149   So, for each key usage, two keys must be generated, one for
150   encryption (Ke), and one for integrity (Ki):
151
152      Ke = DK(protocol key, key usage | 0xAA)
153      Ki = DK(protocol key, key usage | 0x55)
154
155   where the key usage is represented as a 32 bit integer in network
156   byte order.  The ciphertest must be generated from the plaintext as
157   follows:
158
159      ciphertext = E(Ke, confounder | length | plaintext | padding) |
160                   H(Ki, confounder | length | plaintext | padding)
161
162   The confounder and padding are specific to the encryption algorithm
163   E.
164
165   When generating a checksum only, there is no need for a confounder or
166   padding.  Again, a new key (Kc) must be used.  Checksums must be
167   generated from the plaintext as follows:
168
169      Kc = DK(protocol key, key usage | 0x99)
170
171      MAC = H(Kc, length | plaintext)
172
173   Note that each enctype is described by an encryption algorithm E and
174   a keyed hash algorithm H, and each checksum type is described by a
175   keyed hash algorithm H.  HMAC, with an appropriate hash, is
176   recommended for use as H.
177
178
179Security Considerations
180
181   This entire document addresses shortcomings in the use of
182   cryptographic keys in Kerberos V5.
183
184
185
186
187Horowitz                                                        [Page 3]
188
189Internet Draft       Key Derivation for Kerberos V5       November, 1996
190
191
192Acknowledgements
193
194   I would like to thank Uri Blumenthal, Sam Hartman, and Bill
195   Sommerfeld for their contributions to this document.
196
197
198References
199
200   [Horowitz96] Horowitz, M., "Key Derivation for Authentication,
201      Integrity, and Privacy", draft-horowitz-key-derivation-00.txt,
202      November 1996.  [RFC1510] Kohl, J. and Neuman, C., "The Kerberos
203      Network Authentication Service (V5)", RFC 1510, September 1993.
204
205
206Author's Address
207
208   Marc Horowitz
209   Cygnus Solutions
210   955 Massachusetts Avenue
211   Cambridge, MA 02139
212
213   Phone: +1 617 354 7688
214   Email: marc@cygnus.com
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249Horowitz                                                        [Page 4]
250
251