idnits 2.17.1 draft-sirbu-kerb-ext-00.txt: ** The Abstract section seems to be numbered Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-25) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. ** The document is more than 15 pages and seems to lack a Table of Contents. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 1) being 953 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction section. ** The document seems to lack a Security Considerations section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** There is 1 instance of lines with control characters in the document. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 402: '... SEQUENCE OF PA-DATA OPTIONAL,...' RFC 2119 keyword, line 410: '... KerberosTime OPTIONAL,...' RFC 2119 keyword, line 412: '... KerberosTime OPTIONAL,...' RFC 2119 keyword, line 415: '...es HostAddresses OPTIONAL,...' RFC 2119 keyword, line 417: '...tickets SEQUENCE OF Ticket OPTIONAL...' (15 more instances...) == The 'Updates: ' line in the draft header should list only the _numbers_ of the RFCs which will be updated by this document (if approved); it should not include the word 'RFC' in the list. -- The draft header indicates that this document updates RFC1510, but the abstract doesn't seem to directly say this. It does mention RFC1510 though, so this could be OK. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 10 has weird spacing: '...-Drafts are ...' == Line 383 has weird spacing: '... scert serv...' == Line 880 has weird spacing: '...al. If the i...' (Using the creation date from RFC1510, updated by this document, for RFC5378 checks: 1993-09-01) -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (May 6, 1996) is 10216 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Missing reference section? 'CTS95' on line 683 looks like a reference -- Missing reference section? 'Bra96' on line 678 looks like a reference -- Missing reference section? 'Sch95' on line 693 looks like a reference -- Missing reference section? 'X509' on line 695 looks like a reference -- Missing reference section? 'PKCS7' on line 687 looks like a reference -- Missing reference section? '0' on line 855 looks like a reference -- Missing reference section? '1' on line 537 looks like a reference -- Missing reference section? '11' on line 853 looks like a reference Summary: 13 errors (**), 0 flaws (~~), 6 warnings (==), 12 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 INTERNET-DRAFT M. Sirbu 2 draft-sirbu-kerb-ext-00.txt J. Chuang 3 Updates: RFC 1510 CMU/INI 4 May 6, 1996 6 Public-Key Based Ticket Granting Service in Kerberos 8 0. Status of this Memo 10 This document is an Internet-Draft. Internet-Drafts are working 11 documents of the Internet Engineering Task Force (IETF), its areas, 12 and its working groups. Note that other groups may also distribute 13 working documents as Internet-Drafts. 15 Internet-Drafts are draft documents valid for a maximum of six 16 months and may be updated, replaced, or obsoleted by other 17 documents at any time. It is inappropriate to use Internet-Drafts 18 as reference material or to cite them other than as ``work in 19 progress.'' 21 To learn the current status of any Internet-Draft, please check the 22 ``1id-abstracts.txt'' listing contained in the Internet-Drafts 23 Shadow Directories on ds.internic.net (US East Coast), 24 nic.nordu.net (Europe), ftp.isi.edu (US West Coast), or 25 munnari.oz.au (Pacific Rim). 27 The distribution of this memo is unlimited. It is filed as 28 draft-sirbu-kerb-ext-00.txt, and expires November 11, 1996. 29 Please send comments to the authors. 31 1. Abstract 33 This document defines extensions to the Kerberos protocol 34 specification (RFC 1510, "The Kerberos Network Authentication 35 Service (V5)", September 1993) to provide a method for supporting 36 ticket-granting services based on public-key cryptographic 37 algorithms. 39 2. Motivation 41 Conventional Kerberos uses a two-level ticket scheme. The client 42 first obtains a Ticket Granting Ticket (TGT) via a request from the 43 Authentication Server (AS) at the Key Distribution Center (KDC). 44 The client then presents the TGT to the Ticket Granting Server 45 (TGS) to request for a service ticket for the application server it 46 wishes to communicate with. Upon verifying the client's identity 47 from the TGT, the TGS establishes a shared symmetric session 48 key between the client and server, with mutual authentication of 49 the two principals achieved. 51 The Kerberos KDC/TGS arrangement introduces two significant 52 security and performance concerns. First, because the KDC 53 maintains a shared symmetric cipher key with every principal in the 54 system, it is an attractive target for attack; recovering from 55 compromise of the KDC requires establishing new shared keys with 56 all users of the system. Second, a centralized KDC will be a 57 communications or processing bottleneck if a large number of users 58 present a heavy traffic load. 60 Both of these problems will be alleviated with this proposed 61 public-key based extension to Kerberos, which is first described 62 in [CTS95]. 64 In the proposed extension, there is no need for a trusted third 65 party beyond the certificate authority, which distributes public- 66 key certificates for the principals. The client and server can 67 authenticate themselves to each other. There is no longer a 68 centralized database of symmetric keys to be compromised. 70 In addition, the decentralized storage and usage of public-private 71 key pairs distribute the authentication workload across the 72 network to individual client/server pairs. This is especially 73 attractive from a scalability point of view. 75 3. Public-Key Based Ticket Granting Service (PKTGS) 77 In the proposed mode of "Public-Key Kerberos" or "PK Kerberos" 78 operation, only the initial authentication between parties will be 79 based on public key cryptography. All subsequent communications, 80 including repeated authentications, will continue to use the more 81 computationally efficient symmetric key methods. 83 The only message exchanges affected by the proposed extension are 84 those involving the AS and TGS exchanges, as specified in section 85 5.4 of [rfc1510]. Once a session key is established between the 86 client and the server, normal operation proceeds as per RFC1510. 88 3.1 PK Kerberos Operation 90 In Kerberos V5, the client obtains a TGT from the Authentication 91 Service (AS) of the KDC and sends it to the TGS to secure a shared 92 session key between itself and the server it wishes to communicate 93 with. In PK Kerberos, however, the client is allowed to 94 authenticate itself with the server directly. The distribution of 95 public key certificates is performed by either a certificate 96 authority (CA) or the application server itself. The server also 97 assumes the role of the TGS. 99 In PK Kerberos, the client presents a service ticket request 100 encrypted with a certified public key (we call this a Public-Key 101 based TGS request, or PKTGS-REQ) to the server. Since this request 102 is digitally signed with the client's private key, and encrypted 103 with the server's public key, the server and only the server can 104 authenticate the identity of the client. Conversely, the client is 105 assured of the identity of the server because only the server can 106 decrypt the PKTGS-REQ and construct a valid response. 108 In addition to the client's identity and other relevant 109 information, a randomly generated one-time key is also included in 110 the service ticket request. This key is not the actual session 111 key, but is instead used by the server to return the service ticket 112 to the client. This key works identically to the symmetric key 113 generated by the KDC to be shared by the client and the TGS in the 114 traditional TGT-REQ/TGS-REP exchange. 116 The client's public key certificate is also included with this 117 request to facilitate the verification of its signature. 119 The server, in response to the above PKTGS-REQ message, returns a 120 symmetric-cipher-based service ticket. This service ticket is 121 identical in form to a Kerberos service ticket. Therefore, the 122 message format for PKTGS-REP is very similar to that for TGS-REP. 123 With this service ticket, the client and the server can proceed to 124 communicate normally. 126 A client application can also choose to present the PKTGS-REQ to a 127 centralized Ticket Granting Server. This may be necessary, 128 especially during the period of migration to public-key based 129 Kerberos, when some of the application servers are not yet equipped 130 to process service ticket requests. This option, described in 131 Section 4.3, is a special case where the server in question 132 is simply a PK-aware TGS. 134 4. Message Exchanges 136 In Kerberos V5, a normally executed authentication procedure begins 137 with the following five message exchanges: 139 1. client to KDC: AS-REQ 140 2. KDC to client: AS-REP 141 3. client to TGS: TGS-REQ 142 4. TGS to client: TGS-REP 143 5. client to server: AP-REQ 145 In Public key Kerberos, the five step exchange for initial 146 authentication is maintained, but the first four steps are replaced 147 by PK-equivalent versions of the messages. Normal operations 148 proceed from step 5 onwards. 150 1. client to server/CA: SCERT-REQ 151 2. server/CA to client: SCERT-REP 152 3. client to server: PKTGS-REQ 153 4. server to client: PKTGS-REP 154 5. client to server: AP-REQ 156 Each of the new steps is described in detail in the following sub- 157 sections. A sample specification of the protocol, based upon the 158 Interface Specification Language (ISL) [Bra96], can be found in 159 Appendix A. 161 4.1 Obtaining the Server's Public Key Certificate 163 The construction of a PKTGS-REQ requires encryption using the 164 recipient's (server's) public key. Therefore, the client must 165 obtain the server's public key certificate before it can generate 166 the PKTGS-REQ message. This request may either be serviced by a 167 certificate authority (CA), or the server itself. 169 If the client has certificate caching capabilities, steps 1 and 2 170 may be bypassed for subsequent authentication attempts with a 171 server. It is the responsibility of the client to check with the 172 CRL for any revoked certificates. If the client obtains the 173 server's certificate from the CA, it can be sure that the 174 certificate has not been revoked. 176 4.1.1 Generation of SCERT-REQ 178 The client initiates the authentication exchange by generating a 179 simple request message, which consists of the principal name and 180 realm of the server it wishes to communicate with. This message can 181 be transmitted over any available channel, such as an unsecured 182 remote procedure call. 184 4.1.2 Generation of SCERT-REP 186 In response to a certificate request, the server or the CA returns 187 the certificate, which contains the public key information. Again, 188 this message can be transmitted via an unprotected channel. 190 4.2 Client/Server Authentication Using Public Key Cryptography 192 4.2.1 Generation of PKTGS-REQ 194 Once the client has obtained and verified the server's public key 195 certificate, it can proceed to generate the ticket request. The 196 PKTGS-REQ message contains information fields similar to those in 197 KDC-REQ messages, except that the authorization fields are now 198 encrypted using the server's public key instead of the shared 199 symmetric key shared by the KDC and the client in traditional 200 Kerberos. In addition, these fields are also signed by the client, 201 allowing the server to verify the identity of the client. 203 In traditional Kerberos, the KDC generates a random symmetric key 204 for the client to use in communicating with the TGS. The client 205 now generates this random key, which will be referred to in the 206 rest of this document as "Kr", and sends it in encrypted form to 207 the server. The server will then retrieve and use this key to 208 encrypt the responding message PKTGS-REP. 210 The generation of this random key "Kr" does not impose any 211 additional security requirements on the client. The same random 212 number generator used to generate the 'nonce' field in KRB-KDC-REQ 213 can be used to generate this key "Kr", as long as a proper key 214 length is used. In fact, the inclusion of this one-time random key 215 in the message eliminates the need for a separate 'nonce' field. 217 An object containing all the necessary authorization information is 218 first constructed. This object, named 'auth-data' (Section 5.3.2), 219 includes the random key "Kr", the server's identity (to prevent 220 replay attacks first addressed by Denning-Sacco [Sch95]), the 221 server's public key information (to avert "man-in-the-middle" 222 attacks), ticket life-time information, and a timestamp (to prevent 223 replay attacks). 225 The 'auth-data' field is signed with the client's private key using 226 the 'SignedData' construct defined in PKCS #7. The resulting 227 message digest, but not the content itself, is then encrypted with 228 the server's public key using the 'EnvelopedData' construct. 229 The omission of the 'auth-data' content field results in a shorter 230 message length for PKTGS-REQ. This omission is possible because 231 all the information needed to construct and verify the hash of 232 'auth-data' is available to the server through other means. 234 4.2.2 Receipt of PKTGS-REQ 236 Upon receipt of the PKTGS-REQ message, the server first decrypts 237 and retrieves the content-encryption key using its private key. 238 Using this key, it can decrypt the actual enveloped content. The 239 server retrieves the client's public key, which is included in 240 the 'certificate' field of the signed content. Using this public 241 key, the client's signature (and authenticity of the request) is 242 verified by comparing the retrieved message digest with an 243 independently constructed message digest of 'auth-data'. 245 While the 'auth-data' content field is omitted from the PKTGS-REQ 246 message, the server can retrieve all the necessary information. 247 Specifically, the field 'sPKeyInfo' can be retrieved from the 248 server's own copy of its public key certificate. All the other 249 fields present in 'auth-data' can and should be retrieved from the 250 plaintext portion of PKTGS-REQ. 252 4.2.3 Generation of PKTGS-REP 254 The message format for PKTGS-REP is similar to that for TGS-REP in 255 traditional Kerberos [rfc1510], and will be described in Section 256 5.4 of this document. 258 The process of generating this message is also identical to that 259 of generating the TGS-REP, with the following three exceptions. 261 First, this message is now generated by the server (acting in the 262 capacity of the Ticket Granting Service) rather than the TGS. 264 Second, while the ciphertext portion of the message is encrypted 265 using the session key extracted from the TGT in traditional 266 Kerberos, it is now encrypted using the symmetric 'randomKey' "Kr" 267 extracted from PKTGS-REQ. 269 Third, while the traditional service ticket is encrypted using a 270 symmetric key shared by the TGS and the server, it is now encrypted 271 using a symmetric key known only to the server. This is consistent 272 with the fact that the server and the TGS are really one entity in 273 this scenario. 275 4.2.4 Receipt of PKTGS-REP 277 The client receives and processes this message in the same manner 278 as it would a traditional TGS-REP. As in traditional Kerberos, 279 the client will not be able to decrypt and/or modify the ticket. 280 It will be able to retrieve the session key and use it to generate 281 the appropriate authenticators for the subsequent AP-REQ message. 283 From this point on, all operations can proceed per normal Kerberos 284 procedures. 286 4.3 Obtaining Service Tickets From a "PK-Aware" TGS 288 If the server with whom the client wishes to communicate is not 289 capable of handling service ticket requests, the client has to 290 resort to sending the request to a Ticket Granting Service (TGS). 291 This section describes this scenario, and the appropriate course 292 of action to be taken by the client. This escape mechanism will 293 help preserve the functionality and integrity of the Kerberos 294 Authentication scheme during the transition to PK Kerberos, when 295 there can be a hybrid of "PK-aware" and "non-PK-aware" application 296 servers. 298 The client initially assumes that the server is "PK-aware" and 299 sends a SCERT-REQ message to the application server as described in 300 Section 4.1. From the lack of a timely SCERT-REP, the client can 301 either assume that the server is unable to handle a certificate 302 request, or that it is not "PK-aware" at all. In the former case, 303 the client can choose to resend the SCERT-REQ to the certificate 304 authority (CA) and obtain the server's certificate. If the CA is 305 unable to return a certificate for S, then the client knows that 306 the server is not "PK-aware." Else if the client succesfully 307 receives a SCERT-REP from the CA, it can proceed to send a 308 PKTGS-REQ to the server. 310 Once it is established that the server is not "PK-aware," the 311 client will have to communicate with a TGS to get a traditional 312 TGT and subsequent service ticket for the destination server. 313 This is accomplished by the following 7-step exchange. 315 1. client to TGS/CA: SCERT-REQ 316 2. TGS/CA to client: SCERT-REP 317 3. client to TGS: PKTGS-REQ 318 4. TGS to client: PKTGS-REP 319 5. client to TGS: TGS-REQ 320 6. TGS to client: TGS-REP 321 7. client to server: AP-REQ 323 The first four steps of the message exchange are identical to those 324 of PK Kerberos as described in the beginning of Section 4, except 325 that the server being contacted now is a PK-aware TGS. In effect, 326 the client is issuing a PKTGS-REQ to the TGS to request for a 327 traditional TGT. Then, steps 5-7 are really identical to steps 3-5 328 of the traditional Kerberos exchange, where the client uses the TGT 329 to request for an actual service ticket. 331 It is worth noting that the client will be communicating with the 332 TGS for the first six steps of the exchange. Therefore, the 333 performance bottleneck associated with a centralized KDC remains. 334 However, the centralized database of symmetric keys will be much 335 smaller in size, since the clients will now authenticate themselves 336 to the TGS using public keys instead. The symmetric keys shared 337 between the KDC and the servers are still required. 339 5. Message Specifications 341 5.1 SCERT-REQ 343 The construction of PKTGS-REQ requires encryption using the 344 recipient's (server's) public key. Therefore, the client must 345 first obtain the server's public key certificate. This request may 346 be serviced by a certificate authority (CA), or the server itself. 347 This simple request message can be transmitted over any available 348 channel, such as an unsecured remote procedure call. 350 SCERT-REQ ::= SEQUENCE{ 351 pvno INTEGER, 352 msg-type INTEGER, 353 srealm Realm, 354 sname PrincipalName 355 } 357 pvno This field is included in each message, and specifies the 358 protocol version number (version '5' for this document). 360 msg-type This field indicates the type of a protocol message, and 361 is as described in Section 5.4.1 of [rfc1510]. 363 srealm This field specifies the realm part of the server's 364 principal identifier. 366 sname This field specifies the name part of the server's 367 principal identifier. 369 5.2 SCERT-REP 371 In response to a certificate request, the server or the CA returns 372 the certificate, which contains the public key information. Again, 373 this message can be transmitted via an unprotected channel. 375 SCERT-REP ::= SEQUENCE{ 376 pvno INTEGER, 377 msg-type INTEGER, 378 scert Certificate 379 } 381 pvno and msg-type These fields are described above in Section 5.1 383 scert server's certificate (and public key), as defined in X.509 384 or other certificate standards. The X.509 certificate in 385 ASN.1 notation can be found in Annex G of [X509]. It is 386 excerpted as Appendix B of this document. 388 5.3 PKTGS-REQ 390 PKTGS-REQ is sent to the server directly, rather than to the AS or 391 the TGS in the conventional Kerberos protocol. This message 392 contains similar information as conventional ticket requests. The 393 authorization fields, which includes the proposed one-time random 394 key "Kr", is signed with the client's private key and enveloped 395 with the server's public key. This is the basic mechanism 396 underlying authentication and key exchange without the KDC serving 397 as the trusted intermediary. 399 PKTGS-REQ ::= SEQUENCE { 400 pvno INTEGER, 401 msg-type INTEGER, 402 padata SEQUENCE OF PA-DATA OPTIONAL, 403 req-body PKTGS-REQ-BODY 404 } 406 PKTGS-REQ-BODY ::= SEQUENCE { 407 kdc-options KDCOptions, 408 srealm Realm, 409 sname PrincipalName, 410 from KerberosTime OPTIONAL, 411 till KerberosTime, 412 rtime KerberosTime OPTIONAL, 413 authtime KerberosTime, 414 etype SEQUENCE OF INTEGER, 415 addresses HostAddresses OPTIONAL, 416 envelopedContent ContentInfo, -- type 'envelopedData' 417 additional-tickets SEQUENCE OF Ticket OPTIONAL 418 } 420 Other than the following two fields, all the other fields are 421 as described for KDC-REQ in Section 5.4.1 of [rfc1510]. 423 authtime This field indicates the time of initial authentication 424 request. 426 envelopedContent This field contains the enveloped portions of the 427 ticket request message. It is defined to be of type 428 'ContentInfo', which is a generic data-type exported from 429 RSA Lab's PKCS #7 specification [PKCS7]. 431 The message format differs from that of KDC-REQ in the following 432 four ways: 434 First, the encrypted portion of the request body is no longer 435 an 'EncryptedData' object as defined in [rfc1510], but rather a 436 'ContentInfo' container of type 'envelopedData'. This is because 437 public key encryption is used here, using the PKCS specification. 439 Second, 'cname' is excluded from the cleartext portion of the 440 message. Instead, the client's identity is available in its public 441 key certificate, which is transmitted, in encrypted form, within 442 'envelopedContent'. 444 Third, the 'nonce' field is removed. This is possible because 445 its function can be subsumed by the 'randomKey' field in Section 446 5.3.2. The 'randomKey' can serve the role of a nonce since it is 447 also randomly generated by the client, and used only once. 449 Fourth, the field 'authtime' is added. Since the client generates 450 this timestamp, the server will have to verify the time elapsed 451 between this timestamp and when it receives this message. By 452 refusing to service a ticket request that occurred "too far" in the 453 past, i.e., beyond the acceptable clock skew, the server can 454 prevent replay attacks. While this field is transmitted in the 455 clear, its integrity is assured by its inclusion in the signed 456 'auth-data' field. 458 5.3.1 EnvelopedData 460 'ContentInfo' is a generic data-type exported from RSA Lab's PKCS 461 #7 specification [PKCS7]. This data type can take on one of 462 several content-types as enumerated in PKCS #7. In this instance, 463 it takes on the type of 'envelopedData', which is essentially the 464 encryption of the content using a randomly generated symmetric key, 465 followed by the encryption of the symmetric key using the 466 recipient's public key. Syntatically, however, the encrypted key 467 preceeds the encrypted content, such that the content can be 468 decrypted with one pass of the message stream. The syntax relevant 469 to this document is shown below. Appendix C provides a brief 470 discussion of the usage of 'ContentInfo', and its ASN.1 notation. 471 A complete specification of the 'EnvelopedData' type can be found 472 in PKCS #7. 474 -- ContentInfo of type 'envelopedData' 475 ContentInfo ::= SEQUENCE { 476 contentType envelopedData, 477 content EnvelopedData } 479 EnvelopedData ::= SEQUENCE { 480 version Version, 481 recipientInfos RecipientInfos, 482 encryptedContentInfo EncryptedContentInfo } 484 RecipientInfos ::= SET OF RecipientInfo 486 RecipientInfo ::= SEQUENCE { 487 version Version, 488 issuerAndSerialNumber IssuerAndSerialNumber, 489 keyEncryptionAlgorithm KeyEncryptionAlgorithmIdentifier, 490 encryptedKey EncryptedKey } 492 EncryptedContentInfo ::= SEQUENCE { 493 contentType ContentType, 494 contentEncryptionAlgorithm 495 ContentEncryptionAlgorithmIdentifier, 496 encryptedContent 497 [0] IMPLICIT EncryptedContent OPTIONAL } 499 EncryptedKey ::= OCTET STRING -- content encryption key 501 EncryptedContent ::= OCTET STRING -- encryption of Protected-body 503 5.3.2 SignedData 505 The authorization fields, encapsulated in 'auth-data', needs to be 506 signed by the client before it is ready for envelopment. The 507 result of this signing operation is 'Protected-body'. PKCS #7 508 provides a framework for signing, which is used here. Therefore, 509 we have another instance of 'ContentInfo'; but this time 510 it takes on the content-type of 'SignedData'. 512 Protected-body ::= SEQUENCE { 513 randomKey OCTET STRING, 514 contentInfo ContentInfo -- of type 'signedData' 515 } 517 randomKey A randomly generated one-time key. This key is used 518 by the server to encrypt the ciphertext portion of 519 PKTGS-REP in section 5.4. This field also serves as 520 the nonce for PKTGS-REQ. 522 contentInfo This second instance of 'ContentInfo' is used here to 523 declare the object 'SignedData', as required by PKCS #7. 525 -- ContentInfo of type 'signedData' 526 ContentInfo ::= SEQUENCE { 527 contentType signedData, 528 content SignedData } 530 SignedData ::= SEQUENCE { 531 version Version, 532 digestAlgorithms DigestAlgorithmIdentifiers, 533 contentInfo ContentInfo, -- of type 'data' 534 certificates 535 [0] IMPLICIT ExtendedCertificatesAndCertificates 536 OPTIONAL, -- MANDATORY in this context 537 crls [1] IMPLICIT CertificateRevocationLists OPTIONAL, 538 signerInfos SignerInfos } 540 A complete description of 'SignedData' can again be found in 541 [PKCS7]. It is worthwhile to note that the actual message digest 542 of this signature can be found under the field 'signerInfos'. 544 Note that the client's certificate must be included in this 545 construct, even though it is defined as an optional field in 546 PKCS #7. The client's certificate is mandatory here for the 547 signature verification process. Appendix D offers a brief 548 discussion of the rationale behind this requirement. 550 The input to be signed is a third instance of 'ContentInfo', this 551 time simply of type 'data'. 553 -- ContentInfo of type 'data' 554 ContentInfo ::= SEQUENCE { 555 contentType data, 556 content auth-data OPTIONAL -- not present 557 } 559 auth-data ::= SEQUENCE { 560 randomKey OCTET STRING, 561 etype SEQUENCE OF INTEGER, 562 srealm Realm, 563 sname PrincipalName, 564 sPKeyInfo SubjectPublicKeyInfo, 565 from KerberosTime OPTIONAL, 566 till KerberosTime, 567 rtime KerberosTime OPTIONAL, 568 authtime KerberosTime 569 } 571 The field 'randomKey' is identical to that found earlier in 572 'Protected-body'; the fields 'etype', 'srealm', 'sname', 'from', 573 'till', 'rtime' and 'authtime' are identical to those fields found 574 in the plaintext of PKTGS-REQ. All of the above fields are 575 included here for signing purposes only. The only new field is: 577 sPKeyInfo the server's public key which is retrieved by the client 578 from the server's certificate found in SCERT-REP. 580 It is important to note that the 'content' field pointing to 581 'auth-data' is actually a null field. PKCS #7 allows this field to 582 be not present when the content is supplied through other means. In 583 this case, 'etype', 'srealm', 'sname', 'from', 'till', 'rtime', 584 'authtime' are available in the plaintext portion of PKTGS-REQ; 585 'randomKey' can be retrieved from 'Protected-body'; and the server 586 can retrieve 'sPKeyInfo' from its own public-key certificate. 588 There is no advantage from the point of view of either security or 589 privacy to encrypt the fields 'etype', 'srealm', 'sname', 'from', 590 'till', 'rtime' or 'authtime', as long as the integrity of these 591 fields are guaranteed by the signature. The 'sname' and 'srealm' 592 fields must be in the clear so that the listener process receiving 593 the PKTGS-REQ message knows for which principal the message is 594 intended in the event that multiple principals are served from the 595 same server port. Processing speed is enhanced by limiting the 596 enveloped data to the minimum which needs to be protected. The 597 client's certificate is encrypted to protect the privacy of the 598 client who is attempting to communicate with this server. 600 5.4 PKTGS-REP 602 The server, in its ticket granting service capacity, returns a 603 PKTGS-REP message. This message is similar to the TGS-REP message 604 of traditional Kerberos, which is defined in Section 5.4.2 of 605 [rfc1510]. 607 This message, like the TGS-REP, consists of the ticket and an 608 encrypted part, the latter of which includes the session key 'key' 609 which will be used by the client to generate the authenticator in 610 AP-REQ. 612 The fields 'crealm' and 'cname' are moved from the plaintext 613 portion of the message into the encrypted part to protect client 614 privacy. Discussion of the merits of this change is warranted. 615 On the one hand, except for multi-user hosts, client identity can 616 often be inferred from the IP address. Moreover, encrypting 617 'cname' requires the use of the client port address to match the 618 returning PKTGS-REP to the correct PKTGS-REQ. On the other hand, 619 this change does prevent a network observer from being able to 620 track session requests between identifiable client and server 621 pairs, as is the case with Kerberos V5. 623 PKTGS-REP ::= SEQUENCE { 624 pvno INTEGER, 625 msg-type INTEGER, 626 padata SEQUENCE OF PA-DATA OPTIONAL, 627 ticket Ticket, 628 enc-part EncryptedData 629 -- of instance 'PKTGS-EncPart' 630 } 632 All of the fields are as described in Section 5.4.2 of [rfc1510]. 634 enc-part This field is a place holder for the ciphertext and 635 related information that forms the encrypted part of a 636 message. The description of the encrypted part of the 637 message follows each appearance of this field. The 638 encrypted part is encoded as described in section 6.1 of 639 [rfc1510]. The key used to encrypt this part is 640 'randomKey' "Kr" extracted from PKTGS-REQ. 642 PKTGS-EncPart ::= SEQUENCE { 643 key EncryptionKey, 644 last-req LastReq, 645 randomKey OCTET STRING OPTIONAL, 646 key-expiration KerberosTime OPTIONAL, 647 flags TicketFlags, 648 authtime KerberosTime, 649 starttime KerberosTime OPTIONAL, 650 endtime KerberosTime, 651 renew-till KerberosTime OPTIONAL, 652 srealm Realm, 653 sname PrincipalName, 654 caddr HostAddresses OPTIONAL, 655 crealm Realm, 656 cname PrincipalName 657 } 659 All of the fields above are as described in Section 5.4.2 of 660 [rfc1510]. 662 The 'nonce' field found in KDC-REP is substituted by the 663 'randomKey' field here, which serves the same function. In 664 reality, this field is redundant since the entire PKTGS-EncPart is 665 already encrypted using this one-time 'randomKey'. 667 From this point on, all operations can proceed per normal Kerberos 668 procedures. 670 6. Definition of New Message Types 672 New and appropriate application numbers need to be assigned to the 673 new message types described in this document, namely SCERT-REQ, 674 SCERT-REP, PKTGS-REQ and PKTGS-REP. 676 7. References 678 [Bra96] S.H. Brackin: An Interface Specification Language for 679 Cryptographic Protocols and Its Translation into HOL. 680 Submitted to the New Security Paradigm Workshop, Lake 681 Arrowhead, CA, September 16-19, 1996. 683 [CTS95] B. Cox, J.D. Tygar, M. Sirbu: NetBill Security and 684 Transaction Protocol. Proceedings of the USENIX 685 Workshop on Electronic Commerce, July 1995. 687 [PKCS7] RSA Laboratories. PKCS #7: Cryptographic Message Syntax 688 Standard. Version 1.5, November 1993. 690 [rfc1510] J. Kohl, C. Neuman. RFC 1510: The Kerberos 691 Authentication Service (v5). September 1993. 693 [Sch95] B. Schneier, Applied Cryptography, 2nd Ed. 1995. 695 [X509] CCITT. Recommendation X.509: The Directory 696 Authentication Framework. 1988. 698 8. Security Concerns 700 Security issues are discussed throughout this document. 702 9. Expiration 704 This Internet-Draft expires on November 11, 1996. 706 10. Authors' Addresses 708 Marvin Sirbu 709 Information Networking Institute 710 Carnegie Mellon University 711 Pittsburgh, PA 15213-3890 712 (412)268-3436 713 Email: sirbu@cmu.edu 715 John Chung-I Chuang 716 Carnegie Mellon University 717 Pittsburgh, PA 15213-3890 718 (412)268-5618 719 Email: chuang+@cmu.edu 721 Appendix A: Sample ISL Specification for PK Kerberos Protocol 722 (simplified) 724 DEFINITIONS: 725 PRINCIPALS: C, S, CA; 726 SYMMETRIC KEYS: Kr, Kcs, Ks; 727 PUBLIC KEYS: PKC, PKS, PKCA; 728 PRIVATE KEYS: ^PKC, ^PKS, ^PKCA; 729 OTHER: Ts1, Ts2, Ts3, Tsc, Tss; 730 ENCRYPT FUNCTIONS: des, rsa; 731 HASH FUNCTIONS: MD5; 732 des WITH ANYKEY HASINVERSE des WITH ANYKEY; 733 rsa WITH ^PKCA HASINVERSE rsa WITH PKCA; 734 rsa WITH ^PKC HASINVERSE rsa WITH PKC; 735 rsa WITH ^PKS HASINVERSE rsa WITH PKS; 736 rsa WITH PKCA HASINVERSE rsa WITH ^PKCA; 737 rsa WITH PKC HASINVERSE rsa WITH ^PKC; 738 rsa WITH PKS HASINVERSE rsa WITH ^PKS; 740 INITIALCONDITIONS: 741 CA Received C, S, CA, Tsc, Tss, PKC, PKS, ^PKCA, PKCA, rsa, MD5; 742 CA Believes (PublicKey CA rsa PKCA; PrivateKey CA rsa ^PKCA; 743 PublicKey S rsa PKS; PublicKey C rsa PKC; 744 Fresh Tss; Fresh Tsc 745 ); 746 C Received C, S, CA, Kr, Ts1, Ts3, ^PKC, PKCA, rsa, des, MD5; 747 C Received [CA, Tsc, C, PKC](MD5,rsa)(^PKCA) || 748 (PublicKey C rsa PKC) From CA; 749 C Believes (PublicKey CA rsa PKCA; PublicKey C rsa PKC; 750 PrivateKey C rsa ^PKC; SharedSecret C S Kr; 751 Fresh Ts1; Fresh Ts2; Fresh Ts3; Fresh Tsb; 752 C Recognizes C; C Recognizes S; C Recognizes CA; 753 Trustworthy CA; Trustworthy S 754 ); 755 S Received S, Ks, Kcs, Ts2, PKCA, ^PKS, rsa, des, MD5; 756 S Received [CA, Tss, S, PKS](MD5,rsa)(^PKCA) || 757 (PublicKey S rsa PKS) From CA; 758 S Believes (PublicKey S rsa PKS; PrivateKey S rsa ^PKS; 759 PublicKey CA rsa PKCA; 760 SharedSecret S S Ks; SharedSecret C S Kcs; 761 Fresh Ts1; Fresh Ts2; Fresh Ts3; Fresh Tsc; 762 S Recognizes C; S Recognizes S; S Recognizes CA; 763 Trustworthy CA; Trustworthy C 764 ); 766 PROTOCOL: 767 1. C -> CA: S; 768 2. CA -> C: [CA,Tss,S,PKS](MD5,rsa)(^PKCA)||(PublicKey S rsa PKS); 769 3. C -> S: S, Ts1, 770 {Kr, C, 771 [CA,Tsc,C,PKC](MD5,rsa)(^PKCA)||(PublicKey C rsa PKC), 772 {S, Ts1, Kr, 773 [CA,Tss,S,PKS](MD5,rsa)(^PKCA)||(PublicKey S rsa PKS) 774 }(MD5,rsa)(^PKC) 775 }rsa(PKS)||(SharedSecret C S Kr); 776 4. S -> C: S, {Kcs,C,Ts2}des(Ks), {C,S,Kr,Kcs,Ts2}des(Kr)|| 777 (SharedSecret C S Kcs); 778 5. C -> S: S, {Kcs,C,Ts2}des(Ks), {C,Ts3}des(Kcs)|| 779 (SharedSecret C S Kcs); 781 GOALS: 782 1. C Believes (PublicKey S rsa PKS); 783 2. S Believes (PublicKey C rsa PKC); 784 3. S Possesses Kr; 785 S Believes (SharedSecret C S Kr); 786 S Believes (C Possesses Kr); 787 S Believes (C Believes (SharedSecret C S Kr)); 788 4. C Possesses Kcs; 789 C Believes (SharedSecret C S Kcs); 790 C Believes (S Possesses Kcs); 791 C Believes (S Believes (SharedSecret C S Kcs)); 792 5. S Believes (C Possesses Kcs); 793 S Believes (C Believes (SharedSecret C S Kcs)); 795 Appendix B: ASN.1 Notation for 'Certificate' as specified in Annex G 796 of X.509. 798 Certificate :: = SIGNED SEQUENCE{ 799 version[0] Version DEFAULT 1988, 800 serialNumber SerialNumber, 801 signature AlgorithmIdentifier, 802 issuer Name, 803 validity Validity, 804 subject Name, 805 subjectPublicKeyInfo SubjectPublicKeyInfo 806 } 808 Version ::= INTEGER {1988(0)} 810 SerialNumber ::= INTEGER 812 Validity ::= SEQUENCE{ 813 notBefore UTCTime 814 notAfter UTCTime 815 } 817 SubjectPublicKeyInfo ::= SEQUENCE{ 818 algorithm AlgorithmIdentifier 819 subjectPublicKey BIT STRING 820 } 822 AlgorithmIdentifier ::= SEQUENCE{ 823 algorithm OBJECT IDENTIFIER, 824 parameters ANY DEFINED BY algorithm OPTIONAL 825 } 827 SIGNED MACRO :: = 828 BEGIN 829 TYPE NOTATION ::= type (ToBeSigned) 830 VALUE NOTATION ::= value(VALUE 831 SEQUENCE{ 832 ToBeSigned, 833 AlgorithmIdentifier, 834 -- of the algorithm used to generate the signature 835 ENCRYPTED OCTET STRING 836 -- where the octet string is the result 837 -- of the hashing of the value of 838 -- "ToBeSigned"-- 839 } 840 ) 841 END -- of SIGNED 843 Appendix C: PKCS #7 Definition for 'ContentInfo' 845 'ContentInfo' is a general data type defined in, and exported by 846 PKCS #7 for use in conjunction with operations such as enveloping 847 and signing. It is used as a "wrapper" for calling specific data 848 types such as 'signedData' and 'envelopedData', which themselves 849 are not exported from PKCS #7. Nesting is permitted explicitly by 850 the recursive nature of the 'ContentInfo' syntax. 852 ContentInfo ::= SEQUENCE{ 853 caddr[11] HostAddresses OPTIONAL 854 contentType ContentType, 855 content[0] EXPLICIT ANY DEFINED BY contentType OPTIONAL 856 } 858 contentType 859 an object identifier, with six content types defined 860 in PKCS #7, Section 14: data, signedData, envelopedData, 861 signedAndEnvelopedData, digestedData, and encryptedData. 863 content 864 the content field is optional, and if the field is 865 not present, its intended value must be supplied by other 866 means. Its type is defined along with the object identifier 867 for contentType. 869 Appendix D: Discussion on Mandatory Inclusion of 'ccert' in PKTGS-REQ 871 In this proposal, inclusion of the client's certificate, ccert, is 872 mandatory. However there are several situations where inclusion of 873 the client certificate might be superfluous. 875 1. the server intends to check with the CA every time to assure 876 the certificate is fresh and not revoked. 877 2. the intended server is the CA. 879 Thus, one could consider making the inclusion of ccert in the 880 PKTGS-REQ optional. If the inclusion of ccert is optional, three 881 additional changes to the protocol are required. 883 1. Inclusion of a TGS-REP message which says, in effect, "please 884 resubmit this request including the certificate. 886 2. The inclusion of a flag in the SCERT-REP message indicating the 887 server's preference for receiving or not receiving the 888 certificate. The use of such a flag can dramatically reduce 889 the number of rejected PKTGS-REQ messages due to failure to 890 include ccert. 892 3. If ccert is not included in the PKTGS-REQ, than the following 893 fields must be included in its place so that the server can 894 obtain the correct certificate: 895 - cname and crealm 896 - issuer of the client's certificate 897 - serial number of the client's certificate. 899 Actually, cname and crealm are redundant. 901 Both for simplicity and because we believe that the costs of 902 sending a superfluous certificate on occasion are outweighed by the 903 costs likely to be incurred due to retransmission of PKTGS-REQ 904 messages because a certificate was not originally included, we have 905 chosen to make inclusion of ccert mandatory. We welcome further 906 discussion on this issue.