1INTERNET-DRAFT Brian Tung 2draft-ietf-cat-kerberos-pk-cross-01.txt Tatyana Ryutov 3Updates: RFC 1510 Clifford Neuman 4expires September 30, 1997 Gene Tsudik 5 ISI 6 Bill Sommerfeld 7 Hewlett-Packard 8 Ari Medvinsky 9 Matthew Hur 10 CyberSafe Corporation 11 12 13 Public Key Cryptography for Cross-Realm Authentication in Kerberos 14 15 160. Status Of this Memo 17 18 This document is an Internet-Draft. Internet-Drafts are working 19 documents of the Internet Engineering Task Force (IETF), its 20 areas, and its working groups. Note that other groups may also 21 distribute working documents as Internet-Drafts. 22 23 Internet-Drafts are draft documents valid for a maximum of six 24 months and may be updated, replaced, or obsoleted by other 25 documents at any time. It is inappropriate to use Internet-Drafts 26 as reference material or to cite them other than as ``work in 27 progress.'' 28 29 To learn the current status of any Internet-Draft, please check 30 the ``1id-abstracts.txt'' listing contained in the Internet-Drafts 31 Shadow Directories on ds.internic.net (US East Coast), 32 nic.nordu.net (Europe), ftp.isi.edu (US West Coast), or 33 munnari.oz.au (Pacific Rim). 34 35 The distribution of this memo is unlimited. It is filed as 36 draft-ietf-cat-kerberos-pk-cross-01.txt, and expires September 30, 37 1997. Please send comments to the authors. 38 39 401. Abstract 41 42 This document defines extensions to the Kerberos protocol 43 specification (RFC 1510, "The Kerberos Network Authentication 44 Service (V5)", September 1993) to provide a method for using 45 public key cryptography during cross-realm authentication. The 46 methods defined here specify the way in which message exchanges 47 are to be used to transport cross-realm secret keys protected by 48 encryption under public keys certified as belonging to KDCs. 49 50 512. Motivation 52 53 The advantages provided by public key cryptography--ease of 54 recoverability in the event of a compromise, the possibility of 55 an autonomous authentication infrastructure, to name a few--have 56 produced a demand for use by Kerberos authentication protocol. A 57 draft describing the use of public key cryptography in the initial 58 authentication exchange in Kerberos has already been submitted. 59 This draft describes its use in cross-realm authentication. 60 61 The principal advantage provided by public key cryptography in 62 cross-realm authentication lies in the ability to leverage the 63 existing public key infrastructure. It frees the Kerberos realm 64 administrator from having to maintain separate keys for each other 65 realm with which it wishes to exchange authentication information, 66 or to utilize a hierarchical arrangement, which may pose problems 67 of trust. 68 69 Even with the multi-hop cross-realm authentication, there must be 70 some way to locate the path by which separate realms are to be 71 transited. The current method, which makes use of the DNS-like 72 realm names typical to Kerberos, requires trust of the intermediate 73 KDCs. 74 75 The methods described in this draft allow a realm to specify, at 76 the time of authentication, which certification paths it will 77 trust. A shared key for cross-realm authentication can be 78 established, for a period of time. Furthermore, these methods are 79 transparent to the client, so that only the KDC's need to be 80 modified to use them. 81 82 It is not necessary to implement the changes described in the 83 "Public Key Cryptography for Initial Authentication" draft to make 84 use of the changes in this draft. We solicit comments about the 85 interaction between the two protocol changes, but as of this 86 writing, the authors do not perceive any obstacles to using both. 87 88 893. Protocol Amendments 90 91 We assume that the user has already obtained a TGT. To perform 92 cross-realm authentication, the user sends a request to the local 93 KDC as per RFC 1510. If the two realms share a secret key, then 94 cross-realm authentication proceeds as usual. Otherwise, the 95 local KDC may attempt to establish a shared key with the remote 96 KDC using public key cryptography, and exchange this key through 97 the cross-realm ticket granting ticket. 98 99 We will consider the specific channel on which the message 100 exchanges take place in Section 5 below. 101 102 1033.1. Changes to the Cross-Realm Ticket Granting Ticket 104 105 In order to avoid the need for changes to the "installed base" of 106 Kerberos application clients and servers, the only protocol change 107 is to the way in which cross-realm ticket granting tickets (TGTs) 108 are encrypted; as these tickets are opaque to clients and servers, 109 the only change visible to them will be the increased size of the 110 tickets. 111 112 Cross-realm TGTs are granted by a local KDC to authenticate a user 113 to a remote KDC's ticket granting service. In standard Kerberos, 114 they are encrypted using a shared secret key manually configured 115 into each KDC. 116 117 In order to incorporate public key cryptography, we define a new 118 encryption type, "ENCTYPE_PK_CROSS". Operationally, this encryption 119 type transforms an OCTET STRING of plaintext (normally an EncTktPart) 120 into the following SEQUENCE: 121 122 PKCrossOutput ::= SEQUENCE { 123 certificate [0] OCTET STRING OPTIONAL, 124 -- public key certificate 125 -- of local KDC 126 encSharedKey [1] EncryptedData, 127 -- of type EncryptionKey 128 -- containing random symmetric key 129 -- encrypted using public key 130 -- of remote KDC 131 sigSharedKey [2] Signature, 132 -- of encSharedKey 133 -- using signature key 134 -- of local KDC 135 pkEncData [3] EncryptedData, 136 -- (normally) of type EncTktPart 137 -- encrypted using encryption key 138 -- found in encSharedKey 139 } 140 141 PKCROSS operates as follows: when a client submits a request for 142 cross-realm authentication, the local KDC checks to see if it has 143 a long-term shared key established for that realm. If so, it uses 144 this key as per RFC 1510. 145 146 If not, it sends a request for information to the remote KDC. The 147 content of this message is immaterial, as it does not need to be 148 processed by the remote KDC; for the sake of consistency, we define 149 it as follows: 150 151 RemoteRequest ::= [APPLICATION 41] SEQUENCE { 152 nonce [0] INTEGER 153 } 154 155 The remote KDC replies with a list of all trusted certifiers and 156 all its (the remote KDC's) certificates. We note that this response 157 is universal and does not depend on which KDC makes the request: 158 159 RemoteReply ::= [APPLICATION 42] SEQUENCE { 160 trustedCertifiers [0] SEQUENCE OF PrincipalName, 161 certificates[1] SEQUENCE OF Certificate, 162 encTypeToUse [1] SEQUENCE OF INTEGER 163 -- encryption types usable 164 -- for encrypting pkEncData 165 } 166 167 Certificate ::= SEQUENCE { 168 CertType [0] INTEGER, 169 -- type of certificate 170 -- 1 = X.509v3 (DER encoding) 171 -- 2 = PGP (per PGP draft) 172 CertData [1] OCTET STRING 173 -- actual certificate 174 -- type determined by CertType 175 } -- from pk-init draft 176 177 Upon receiving this reply, the local KDC determines whether it has 178 a certificate the remote KDC trusts, and whether the remote KDC has 179 a certificate the local KDC trusts. If so, it issues a ticket 180 encrypted using the ENCTYPE_PK_CROSS encryption type defined above. 181 182 1833.2. Profile Caches 184 185 We observe that using PKCROSS as specified above requires two 186 private key operations: a signature generation by the local KDC and 187 a decryption by the remote KDC. This cost can be reduced in the 188 long term by judicious caching of the encSharedKey and the 189 sigSharedKey. 190 191 Let us define a "profile" as the encSharedKey and sigSharedKey, in 192 conjunction with the associated remote realm name and decrypted 193 shared key (the key encrypted in the encSharedKey). 194 195 To optimize these interactions, each KDC maintains two caches, one 196 for outbound profiles and one for inbound profiles. When generating 197 an outbound TGT for another realm, the local KDC first checks to see 198 if the corresponding entry exists in the outbound profile cache; if 199 so, it uses its contents to form the first three fields of the 200 PKCrossOutput; the shared key is used to encrypt the data for the 201 fourth field. If not, the components are generated fresh and stored 202 in the outbound profile cache. 203 204 Upon receipt of the TGT, the remote realm checks its inbound profile 205 cache for the corresponding entry. If it exists, then it uses the 206 contents of the entry to decrypt the data encrypted in the pkEncData. 207 If not, then it goes through the full process of verifying and 208 extracting the shared key; if this is successful, then a new entry 209 is created in the inbound profile cache. 210 211 The inbound profile cache should support multiple entries per realm, 212 in the event that the initiating realm is replicated. 213 214 2154. Finding Realms Supporting PKCROSS 216 217 If either the local realm or the destination realm does not support 218 PKCROSS, or both do not, the mechanism specified in Section 3 can 219 still be used in obtaining the desired remote TGT. 220 221 In the reference Kerberos implementations, the default behavior is 222 to traverse a path up and down the realm name hierarchy, if the 223 two realms do not share a key. There is, however, the possibility 224 of using cross links--i.e., keys shared between two realms that 225 are non-contiguous in the realm name hierarchy--to shorten the 226 path, both to minimize delay and the number of intermediate realms 227 that need to be trusted. 228 229 PKCROSS can be used as a way to provide cross-links even in the 230 absence of shared keys. If the client is aware that one or two 231 intermediate realms support PKCROSS, then a combination of 232 PKCROSS and conventional cross-realm authentication can be used 233 to reach the final destination realm. 234 235 We solicit discussion on the best methods for clients and KDCs to 236 determine or advertise support for PKCROSS. 237 238 2395. Message Ports 240 241 We have not specified the port on which KDCs supporting PKCROSS 242 should listen to receive the request for information messages noted 243 above. We solicit discussion on which port should be used. We 244 propose to use the standard Kerberos ports (well-known 88 or 750), 245 but another possibility is to use a completely different port. 246 247 We also solicit discussion on what other approaches can be taken to 248 obtain the information in the RemoteReply (e.g., secure DNS or some 249 other repository). 250 251 2526. Expiration Date 253 254 This Internet-Draft will expire on September 30, 1997. 255 256 2577. Authors' Addresses 258 259 Brian Tung 260 Tatyana Ryutov 261 Clifford Neuman 262 Gene Tsudik 263 USC/Information Sciences Institute 264 4676 Admiralty Way Suite 1001 265 Marina del Rey, CA 90292-6695 266 Phone: +1 310 822 1511 267 E-Mail: {brian, tryutov, bcn, gts}@isi.edu 268 269 Bill Sommerfeld 270 Hewlett Packard 271 300 Apollo Drive 272 Chelmsford MA 01824 273 Phone: +1 508 436 4352 274 E-Mail: sommerfeld@apollo.hp.com 275 276 Ari Medvinsky 277 Matthew Hur 278 CyberSafe Corporation 279 1605 NW Sammamish Road Suite 310 280 Issaquah WA 98027-5378 281 Phone: +1 206 391 6000 282 E-mail: {ari.medvinsky, matt.hur}@cybersafe.com 283