From 51f78097a6a7e24d8906d85c56ede2eb6a540326 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Love=20H=C3=B6rnquist=20=C3=85strand?= Date: Wed, 3 Jan 2007 00:06:49 +0000 Subject: [PATCH] original from Brian Tung git-svn-id: svn://svn.h5l.se/heimdal/trunk/heimdal@19623 ec53bebd-3082-4978-b11e-865c3cabbd6b --- .../draft-ietf-cat-kerberos-pk-init-00.txt | 373 +++ .../draft-ietf-cat-kerberos-pk-init-01.txt | 614 +++++ .../draft-ietf-cat-kerberos-pk-init-02.txt | 1120 ++++++++ .../draft-ietf-cat-kerberos-pk-init-03.txt | 588 ++++ .../draft-ietf-cat-kerberos-pk-init-04.txt | 868 ++++++ .../draft-ietf-cat-kerberos-pk-init-05.txt | 916 +++++++ .../draft-ietf-cat-kerberos-pk-init-06.txt | 959 +++++++ .../draft-ietf-cat-kerberos-pk-init-07.txt | 1181 ++++++++ .../draft-ietf-cat-kerberos-pk-init-08.txt | 944 +++++++ .../draft-ietf-cat-kerberos-pk-init-09.txt | 908 +++++++ .../draft-ietf-cat-kerberos-pk-init-10.txt | 957 +++++++ .../draft-ietf-cat-kerberos-pk-init-13.txt | 1062 ++++++++ .../draft-ietf-cat-kerberos-pk-init-14.txt | 1104 ++++++++ .../draft-ietf-cat-kerberos-pk-init-15.txt | 1116 ++++++++ .../draft-ietf-cat-kerberos-pk-init-17.txt | 2 - .../draft-ietf-cat-kerberos-pk-init-20.txt | 202 -- .../draft-ietf-cat-kerberos-pk-init-21.txt | 215 +- .../draft-ietf-cat-kerberos-pk-init-22.txt | 2403 +++++++---------- .../draft-ietf-cat-kerberos-pk-init-23.txt | 3 +- .../draft-ietf-cat-kerberos-pk-init-24.txt | 640 ++--- .../draft-ietf-cat-kerberos-pk-init-26.txt | 5 +- .../draft-ietf-cat-kerberos-pk-init-27.txt | 3 - .../draft-ietf-cat-kerberos-pk-init-28.txt | 1897 +++++++++++++ .../draft-ietf-cat-kerberos-pk-init-29.txt | 3 - .../draft-ietf-cat-kerberos-pk-init-30.txt | 2183 +++++++++++++++ .../draft-ietf-cat-kerberos-pk-init-31.txt | 614 ++--- .../draft-ietf-cat-kerberos-pk-init-32.txt | 5 - .../draft-ietf-cat-kerberos-pk-init-33.txt | 11 +- .../draft-ietf-cat-kerberos-pk-init-34.txt | 5 - 29 files changed, 18294 insertions(+), 2607 deletions(-) create mode 100644 doc/standardisation/draft-ietf-cat-kerberos-pk-init-00.txt create mode 100644 doc/standardisation/draft-ietf-cat-kerberos-pk-init-01.txt create mode 100644 doc/standardisation/draft-ietf-cat-kerberos-pk-init-02.txt create mode 100644 doc/standardisation/draft-ietf-cat-kerberos-pk-init-03.txt create mode 100644 doc/standardisation/draft-ietf-cat-kerberos-pk-init-04.txt create mode 100644 doc/standardisation/draft-ietf-cat-kerberos-pk-init-05.txt create mode 100644 doc/standardisation/draft-ietf-cat-kerberos-pk-init-06.txt create mode 100644 doc/standardisation/draft-ietf-cat-kerberos-pk-init-07.txt create mode 100644 doc/standardisation/draft-ietf-cat-kerberos-pk-init-08.txt create mode 100644 doc/standardisation/draft-ietf-cat-kerberos-pk-init-09.txt create mode 100644 doc/standardisation/draft-ietf-cat-kerberos-pk-init-10.txt create mode 100644 doc/standardisation/draft-ietf-cat-kerberos-pk-init-13.txt create mode 100644 doc/standardisation/draft-ietf-cat-kerberos-pk-init-14.txt create mode 100644 doc/standardisation/draft-ietf-cat-kerberos-pk-init-15.txt create mode 100644 doc/standardisation/draft-ietf-cat-kerberos-pk-init-28.txt create mode 100644 doc/standardisation/draft-ietf-cat-kerberos-pk-init-30.txt diff --git a/doc/standardisation/draft-ietf-cat-kerberos-pk-init-00.txt b/doc/standardisation/draft-ietf-cat-kerberos-pk-init-00.txt new file mode 100644 index 000000000..704c7caf2 --- /dev/null +++ b/doc/standardisation/draft-ietf-cat-kerberos-pk-init-00.txt @@ -0,0 +1,373 @@ + +INTERNET-DRAFT Clifford Neuman +draft-ietf-cat-kerberos-pk-init-00.txt Brian Tung +Updates: RFC 1510 ISI +expires September 3, 1995 John Wray + Digital Equipment Corporation + + + Public Key Cryptography for Initial Authentication in Kerberos + + +0. Status Of this Memo + + This document is an Internet-Draft. Internet-Drafts are working + documents of the Internet Engineering Task Force (IETF), its areas, + and its working groups. Note that other groups may also distribute + working documents as Internet-Drafts. + + Internet-Drafts are draft documents valid for a maximum of six + months and may be updated, replaced, or obsoleted by other docu- + ments at any time. It is inappropriate to use Internet-Drafts as + reference material or to cite them other than as ``work in pro- + gress.'' + + To learn the current status of any Internet-Draft, please check the + ``1id-abstracts.txt'' listing contained in the Internet-Drafts Sha- + dow Directories on ds.internic.net (US East Coast), nic.nordu.net + (Europe), ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific + Rim). + + The distribution of this memo is unlimited. It is filed as + draft-ietf-cat-kerberos-pk-init-00.txt, and expires August 6, 1995. + Please send comments to the authors. + + +1. Abstract + + This document defines extensions to the Kerberos protocol specifi- + cation (RFC 1510, "The Kerberos Network Authentication Service + (V5)", September 1993) to provide a method for using public key + cryptography during initial authentication. The method defined + specifies the way in which preauthentication data fields and error + data fields in Kerberos messages are to be used to transport public + key data. + +2. Motivation + + Public key cryptography provides a means by which a principal may + demonstrate possession of a key, without ever having divulged this + key to anyone else. In conventional cryptography, the encryption key + and decryption key are either identical or can easily be derived from + each other. In public key cryptography, however, neither key can be + derived easily from the other; hence, the ability to encrypt a message + does not imply the ability to decrypt it in turn. Additionally, each + key is a full inverse of the other, so that either key can be used + for encryption or decryption. + + The advantages provided by public key cryptography have produced a + demand for its integration into the Kerberos authentication protocol. + There are two important areas where public key cryptography will have + immediate use: in the initial authentication of users registered with + the KDC or using public key certificates from outside authorities, + and to establish inter-realm keys for cross-realm authentication. + This memo describes a method by which the first of these can be done. + The second case will be the topic for a separate proposal. + + Some of the ideas on which this proposal is based arose during + discussions over several years between members of the SAAG, the + IETF-CAT working group, and the PSRG, regarding integration of + Kerberos and SPX. Some ideas are drawn from the DASS system, and + similar extensions have been discussed for use in DCE. These changes + are by no means endorsed by these groups. This is an attempt to + revive some of the goals of that group, and the proposal approaches + those goals primarily from the Kerberos perspective. + + This proposal will allow users with keys already registered for use + with X.509, PEM, or PGP, to use those keys to obtain Kerberos + credentials which can then be used for authentication with application + servers supporting Kerberos. + + Use of public-key will not be a requirement for Kerberos, but if one's + organization runs a KDC supporting public key, then users may choose + to be registered with public keys instead of the current secret key. + The application request and response, between Kerberos clients and + application servers, will continue to be based on conventional + cryptography, and the application servers will continue to be + registered with conventional keys. + + +3. Initial authentication of users with public keys + + This section proposes extensions to Version 5 of the Kerberos + protocol that will support the use of public key cryptography + by users in the initial request for a ticket granting ticket. + + The advantage of registering public keys with the KDC lies in the + ease of recovery in case the KDC is compromised. With Kerberos as it + currently stands, compromise of the security KDC is disastrous. All + keys become known by the attacker and all keys must be changed. + + If users register public keys, compromise of the KDC does not divulge + their private key. Compromise of security on the KDC is still + disastrous, since the attacker can impersonate any user. An + attacker with the private key of the KDC can use it to certify a + bogus nonce key, and impersonate a user. Changing this key + invalidates all bogus certifications. Legitimate users must + re-certify their keys with the new KDC key, but users' public + keys do not have to be changed. (Users who store their private + keys in an encrypted form on the KDC do have to change their + keys, since the encryption key is a symmetric key derived from + a password (as described below) and hence vulnerable to dictionary + attacks. The difference is that, assuming good password policy, + site policy may allow the use of the old password only for the + purpose of key change for a time after the compromise, which means + that users can change their own passwords, rather than forcing the + administrator to re-key everyone.) + + In the event of compromise of the KDC, recovery is simple since only + the KDC's key, keys for application servers, and users' private keys + stored in the KDC (as described above) must be changed. + Since there are usually fewer servers than users, and since an + organization usually has better procedures for updating servers, + changing these keys is much easier than having to individually + contact every user. + + This proposed extension will not require users to register with + public keys. It is intended to allow them to do so, but we recognize + that there are many reasons, including licensing terms, that users or + an organization as a whole will choose not to use the public key + option. Users registered will public keys will only be able to + perform initial authentication from a client that support public key, + and must be registered in a realm that supports public key. But they + will be able to use services registered in realms that support only + conventional Kerberos. Further, users registered with conventional + Kerberos keys will be able to use all clients. + + This proposal specifically does not address the registration of + public keys for services. The application request and response, + between Kerberos clients and application servers, will continue to be + based on conventional cryptography, and the application servers will + continue to be registered with conventional keys. There are + performance issues and other reasons that servers may be better off + using conventional cryptography. There are also reasons that they + may want to use public key. For this proposal, however, we feel that + 80 percent of the benefits of integrating public key with Kerberos + can be attained for 20 percent of the effort, by addressing only + initial authentication. This proposal does not preclude separate + extensions. + + This proposal address two ways in which users may use public key + cryptography for initial authentication with Kerberos. In both + cases, the end result is that the user obtains a conventional ticket + granting ticket, or conventional server ticket, that may be used for + subsequent authentication, with such subsequent authentication using + only conventional cryptography. + + Users may register keys directly with the KDC, or they may present + certificates by outside certification authorities (or certifications + by other users) attesting to the association of the public key with + the named user. We first consider the case where the user's key is + registered with the KDC. + + +3.1 Initial request for user registered with public key on KDC + + In this scenario it is assumed that the user is registered with a public + key on the KDC. The user's private key may be known to the user, or + may be stored on the KDC, encrypted so that it can not be used by the KDC. + + We consider first the case where the user knows the private key, then + add support for retrieving the private key from the KDC. + + The initial request to the KDC for a ticket granting ticket proceeds + according to RFC 1510. Typically, preauthentication using a secret + key would not be included, but if included it may be ignored by the + KDC. (This may introduce a problem: even if the KDC should ignore + the preauthentication, an attacker may not, and use an + intercepted message to guess the password off-line.) + If the private key is known to the client in advance, the + response from the KDC would be identical to the response in RFC1510, + except that instead of being encrypted in the secret key shared by the + client and the KDC, it is encrypted in a random key freshly generated + by the KDC. A preauthentication field (specified below) + accompanies the response, containing a certificate with the public + key for the KDC, and a package containing the secret key in which the + rest of the response is encrypted, itself encrypted in the private key + of the KDC, and the public key of the user. This package also contains + the same nonce used in the rest of the response, in order to prevent + replays of this part of the message, accompanied by a reconstructed + response. + + PA-PK-AS-REP ::= SEQUENCE { + kdc-cert SEQUENCE OF OCTET STRING, + encryptPack EncryptedData -- EncPaPkAsRepPart + } + + EncPaPkAsRepPart ::= SEQUENCE { + enc-sess-key INTEGER, + nonce INTEGER + } + + Upon receipt of the response from the KDC, the client will verify the + public key for the KDC from PA-PK-AS-REP preauthentication data field, + The certificate must certify the key as belonging to a principal whose + name can be derived from the realm name. We solicit discussion on the + form of the kdc-cert. If client systems are expected to know (by + being hard-coded, for example) at least one public key, and to verify + certificates from that key, then there should be at least some policy + about which key that is, or alternatively some way to inform the KDC + which key the client possesses. + + If the certificate checks + out, the client then extracts the message key for the rest of the + response by decrypting the field in the PA-PK-AS-REP with the public + key of the KDC and the private key of the user. The client then uses + the message key to decrypt the rest of the response, and continues as + per RFC1510[1]. + + +3.1.1. Private key held by KDC + + When the user's private key is not carried with the user, the user may + encrypt the private key using conventional cryptography, and register + the encrypted private key with the KDC. + + When the user's private key is registered with the KDC, the KDC record + will also indicate whether preauthentication is required before + returning the record (we recommend that it be required). If such + preauthentication is required, when the initial request is received + the KDC will respond with a KRB_ERROR message of type + KDC_ERR_PREAUTH_REQUIRED and with an error data field set to: + + PA-PK-AS-INFO ::= SEQUENCE { + kdc-cert OCTET STRING} + } + + The kdc-cert field is identical to that in the PA-PK-AS-REP + preauthentication data field returned with the KDC response, and must + be validated as belonging to the KDC in the same manner. + + Upon receipt of the KRB_ERROR message with a PA-PK-AS-INFO field, the + client will prompt the user for the password that will be used to + decrypt the private key when returned, calculate a one way hash H1 of the + key, and send a request to the KDC, including a timestamp and a + client-generated nonce secret key that will be used to super-encrypt + the encrypted private key before it is returned to the client. This + information is sent to the KDC in a subsequent AS_REQ message in a + preauthentication data field: + + PA-PK-AS-REQ ::= SEQUENCE { + enc-part EncryptedData -- EncPaPkAsReqPart + } + + EncPaPkAsReqPart ::= SEQUENCE { + tstamp KerberosTime, + noncekey INTEGER + } + + encrypted first with the hash H1, then the public key of the KDC from + the certificate in the PA-PK-AS-INFO field of the error response. + + Upon receipt of the authentication request with the PA-PK-AS-REQ the + KDC verifies the hash of the user's DES encryption key by comparing it + to the hash stored in the users database record. If valid, it + generates the AS response as defined in RFC1510, but additionally + includes a preauthentication field of type PA-PK-USER KEY. This + response will also be included in response to the initial request + without preauthentication if preauthentication is not required for the + user and the user's encrypted private key is stored on the KDC. The + KDC generates a preauthentication data field of type PA-PK-USER-KEY + which will be returned with the KDC reply (together with the + PA-PK-AS-REP that is already returned). + + PA-PK-USER-KEY ::= SEQUENCE { + enc-priv-key OCTET STRING OPTIONAL + } + + This message contains the encrypted private key that has been + registered with the KDC by the user, as encrypted by the user, + super-encrypted with the noncekey from the PA-PK-AS-REQ message if + preauthentication using that method was provided. Note that since + H1 is a one-way hash, it is not possible for one to decrypt the + message if one possesses H1 but not the noncekey that H1 is derived + from. + + +3.2. Clients with a public key certified by an outside authority + + In the case where the client is not registered with the current KDC, + the client is responsible for obtaining the private key on its own. + The client will request initial tickets from the KDC using the TGS + exchange, but instead of performing pre-authentication using a + Kerberos ticket granting ticket, or with the PA-PK-AS-REQ that is used + when the public key is known to the KDC, the client performs + preauthentication using the preauthentication data field of type + PA-PK-AS-EXT-CERT: + + PA-PK-AS-EXT-CERT ::= SEQUENCE { + user-cert SEQUENCE OF OCTET STRING, + authent EncryptedData -- PKAuthenticator + } + + PKAuthenticator ::= SEQUENCE { + cksum Checksum OPTIONAL, + cusec INTEGER, + ctime KerberosTime, + } + + The fields in the encrypted authenticator are the same as those + in the Kerberos authenticator. The structure is itself signed using + the user's private key corresponding to the public key in the + certificate. + + The KDC will verify the preauthentication authenticator, and check the + certification path against its own policy of legitimate certifiers. + This may be based on a certification hierarchy, or simply a list of + recognized certifiers in a system like PGP. + + If all checks out, the KDC will issue Kerberos credentials, as in 3.1, + but with the names of all the certifiers in the certification path + added to the transited field of the ticket, with a principal name + taken from the certificate (this might be a long path for X.509, or a + string like "John Q. Public " if the certificate + was a PGP certificate. The realm will identify the kind of + certificate and the final certifier (e.g. PGP:)[2]. + + +4. Compatibility with One-Time Passcodes + + We solicit discussion on how the use of public key crytpgraphy for + intial authentication will interact with the proposed use of one time + passwords discussed in Internet Draft + draft-ietf-cat-kerberos-passwords-00.txt + +5. Expiration + + This Internet-Draft expires on August 6, 1995. + + +6. Authors' Addresses + + B. Clifford Neuman + USC/Information Sciences Institute + 4676 Admiralty Way #1001 + Marina del Rey, CA 90292-6695 + + Phone: 310-822-1511 + EMail: bcn@isi.edu + + + Brian Tung + USC/Information Sciences Institute + 4676 Admiralty Way #1001 + Marina del Rey, CA 90292-6695 + + Phone: 310-822-1511 + EMail: brian@isi.edu + + + John Wray + Digital Equipment Corporation + 550 King Street, LKG2-2/Z7 + Littleton, MA 01460 + + Phone: 508-486-5210 + EMail: wray@tuxedo.enet.dec.com + +[1] Note: We have not yet defined the public key encryption method for +encrypting the enc-sess-key field in the PA-PK-AS-REP. + +[2] Note: We are soliciting input on the form of the name. We believe the +name part must be taken without modification from the certificate, but the +realm part is open for discussion. diff --git a/doc/standardisation/draft-ietf-cat-kerberos-pk-init-01.txt b/doc/standardisation/draft-ietf-cat-kerberos-pk-init-01.txt new file mode 100644 index 000000000..e6ae54d97 --- /dev/null +++ b/doc/standardisation/draft-ietf-cat-kerberos-pk-init-01.txt @@ -0,0 +1,614 @@ +INTERNET-DRAFT Clifford Neuman +draft-ietf-cat-kerberos-pk-init-01.txt Brian Tung +Updates: RFC 1510 ISI +expires December 7, 1996 John Wray + Digital Equipment Corporation + + + Public Key Cryptography for Initial Authentication in Kerberos + + +0. Status Of this Memo + + This document is an Internet-Draft. Internet-Drafts are working + documents of the Internet Engineering Task Force (IETF), its areas, + and its working groups. Note that other groups may also distribute + working documents as Internet-Drafts. + + Internet-Drafts are draft documents valid for a maximum of six + months and may be updated, replaced, or obsoleted by other docu- + ments at any time. It is inappropriate to use Internet-Drafts as + reference material or to cite them other than as ``work in pro- + gress.'' + + To learn the current status of any Internet-Draft, please check the + ``1id-abstracts.txt'' listing contained in the Internet-Drafts Sha- + dow Directories on ds.internic.net (US East Coast), nic.nordu.net + (Europe), ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific + Rim). + + The distribution of this memo is unlimited. It is filed as + draft-ietf-cat-kerberos-pk-init-01.txt, and expires December 7, 1996. + Please send comments to the authors. + + +1. Abstract + + This document defines extensions to the Kerberos protocol specifi- + cation (RFC 1510, "The Kerberos Network Authentication Service + (V5)", September 1993) to provide a method for using public key + cryptography during initial authentication. The method defined + specifies the way in which preauthentication data fields and error + data fields in Kerberos messages are to be used to transport public + key data. + +2. Motivation + + Public key cryptography presents a means by which a principal may + demonstrate possession of a key, without ever having divulged this + key to anyone else. In conventional cryptography, the encryption key + and decryption key are either identical or can easily be derived from + one another. In public key cryptography, however, neither the public + key nor the private key can be derived from the other (although the + private key RECORD may include the information required to generate + BOTH keys). Hence, a message encrypted with a public key is private, + since only the person possessing the private key can decrypt it; + similarly, someone possessing the private key can also encrypt a + message, thus providing a digital signature. + + Furthermore, conventional keys are often derived from passwords, so + messages encrypted with these keys are susceptible to dictionary + attacks, whereas public key pairs are generated from a pseudo-random + number sequence. While it is true that messages encrypted using + public key cryptography are actually encrypted with a conventional + secret key, which is in turn encrypted using the public key pair, + the secret key is also randomly generated and is hence not vulnerable + to a dictionary attack. + + The advantages provided by public key cryptography have produced a + demand for its integration into the Kerberos authentication protocol. + The primary advantage of registering public keys with the KDC lies in + the ease of recovery in case the KDC is compromised. With Kerberos as + it currently stands, compromise of the KDC is disastrous. All + keys become known by the attacker and all keys must be changed. + + If users register public keys, compromise of the KDC does not divulge + their private key. Compromise of security on the KDC is still a + problem, since an attacker can impersonate any user by certifying a + bogus key with the KDC's private key. However, all bogus + certificates can be invalidated by revoking and changing the + KDC's public key. Legitimate users have to re-certify their public + keys with the new KDC key, but the users's keys themselves do not + need to be changed. Keys for application servers are conventional + symmetric keys and must be changed. + + Note: If a user stores his private key, in an encrypted form, on the + KDC, then he does have to change the key pair, since the private key + is encrypted using a symmetric key derived from a password (as + described below), and is therefore vulnerable to dictionary attack. + Assuming good password policy, however, legitimate users may be + allowed to use the old password for a limited time, solely for the + purpose of changing the key pair. The realm administrator is then + not forced to re-key all users. + + There are two important areas where public key cryptography will have + immediate use: in the initial authentication of users registered with + the KDC or using public key certificates from outside authorities, + and to establish inter-realm keys for cross-realm authentication. + This memo describes a method by which the first of these can be done. + The second case will be the topic for a separate proposal. + + Some of the ideas on which this proposal is based arose during + discussions over several years between members of the SAAG, the + IETF-CAT working group, and the PSRG, regarding integration of + Kerberos and SPX. Some ideas are drawn from the DASS system, and + similar extensions have been discussed for use in DCE. These changes + are by no means endorsed by these groups. This is an attempt to + revive some of the goals of that group, and the proposal approaches + those goals primarily from the Kerberos perspective. + + +3. Initial authentication of users with public keys + + This section describes the extensions to Version 5 of the Kerberos + protocol that will support the use of public key cryptography by + users in the initial request for a ticket granting ticket. This + proposal is based on the implementation already made available; + nevertheless, we solicit any comments on modifications or additions + to the protocol description below. + + Roughly speaking, the following changes to RFC 1510 are proposed: + a. The KDC's response is encrypted using a random nonce key, + rather than the user's secret key. + b. This random key accompanies the response in a + preauthentication field, encrypted and signed using the + public key pairs of the user and the KDC. + Certificate and message formats are also defined in this section. + + This proposal will allow users either to use keys registered directly + with the KDC, or to use keys already registered for use with X.509, + PEM, or PGP, to obtain Kerberos credentials. These credentials can + then be used, as before, with application servers supporting Kerberos. + Use of public key cryptography will not be a requirement for Kerberos, + but if one's organization runs a KDC supporting public key, then users + may choose to be registered with a public key pair, instead of the + current secret key. + + The application request and response between Kerberos clients and + application servers will continue to be based on conventional + cryptography, or will be converted to use user-to-user + authentication. There are performance issues and other reasons + that servers may be better off using conventional cryptography. + For this proposal, we feel that 80 percent of the benefits of + integrating public key with Kerberos can be attained for 20 percent + of the effort, by addressing only initial authentication. This + proposal does not preclude separate extensions. + + With these changes, users will be able to register public keys, only + in realms that support public key, and they will then only be able + to perform initial authentication from a client that supports public key, + although they will be able to use services registered in any realm. + Furthermore, users registered with conventional keys will be able + to use any client. + + This proposal addresses three ways in which users may use public key + cryptography for initial authentication with Kerberos, with minimal + change to the existing protocol. Users may register keys directly + with the KDC, or they may present certificates by outside certification + authorities (or certifications by other users) attesting to the + association of the public key with the named user. In both cases, + the end result is that the user obtains a conventional ticket + granting ticket or conventional server ticket that may be used for + subsequent authentication, with such subsequent authentication using + only conventional cryptography. + + Additionally, users may also register a digital signature key with + the KDC. We provide this option for the licensing benefits, as well + as a simpler variant of the initial authentication exchange. However, + this option relies on the client to generate random keys. + + We first consider the case where the user's key is registered with + the KDC. + + +3.1 Definitions + + Before we proceed, we will lay some groundwork definitions for + encryption and signatures. We propose the following definitions + of signature and encryption modes (and their corresponding values + on the wire): + + #define ENCTYPE_SIGN_MD5_RSA 0x0011 + + #define ENCTYPE_ENCRYPT_RSA_PRIV 0x0021 + #define ENCTYPE_ENCRYPT_RSA_PUB 0x0022 + + allowing further modes to be defined accordingly. + + In the exposition below, we will use the notation E (T, K) to denote + the encryption of data T, with key (or parameters) K. + + If E is ENCTYPE_SIGN_MD5_RSA, then + + E (T, K) = {T, RSAEncryptPrivate (MD5Hash (T), K)} + + If E is ENCTYPE_ENCRYPT_RSA_PRIV, then + + E (T, K) = RSAEncryptPrivate (T, K) + + Correspondingly, if E is ENCTYPE_ENCRYPT_RSA_PUB, then + + E (T, K) = RSAEncryptPublic (T, K) + + +3.2 Initial request for user registered with public key on KDC + + In this scenario it is assumed that the user is registered with a + public key on the KDC. The user's private key may be held by the + user, or it may be stored on the KDC, encrypted so that it cannot be + used by the KDC. + +3.2.1 User's private key is stored locally + + If the user stores his private key locally, the initial request to + the KDC for a ticket granting ticket proceeds according to RFC 1510, + except that a preauthentication field containing a nonce signed by + the user's private key is included. The preauthentication field + may also include a list of the root certifiers trusted by the user. + + PA-PK-AS-ROOT ::= SEQUENCE { + rootCert[0] SEQUENCE OF OCTET STRING, + signedAuth[1] SignedPKAuthenticator + } + + SignedPKAuthenticator ::= SEQUENCE { + authent[0] PKAuthenticator, + authentSig[1] Signature + } + + PKAuthenticator ::= SEQUENCE { + cksum[0] Checksum OPTIONAL, + cusec[1] INTEGER, + ctime[2] KerberosTime, + nonce[3] INTEGER, + kdcRealm[4] Realm, + kdcName[5] PrincipalName + } + + Signature ::= SEQUENCE { + sigType[0] INTEGER, + kvno[1] INTEGER OPTIONAL, + sigHash[2] OCTET STRING + } + + Notationally, sigHash is then + + sigType (authent, userPrivateKey) + + where userPrivateKey is the user's private key (corresponding to the + public key held in the user's database record). Valid sigTypes are + thus far limited to the above-listed ENCTYPE_SIGN_MD5_RSA; we expect + that other types may be listed (and given on-the-wire values between + 0x0011 and 0x001f). + + The format of each certificate depends on the particular + service used. (Alternatively, the KDC could send, with its reply, + a sequence of certifications (see below), but since the KDC is likely + to have more certifications than users have trusted root certifiers, + we have chosen the first method.) In the event that the client + believes it already possesses the current public key of the KDC, + a zero-length root-cert field is sent. + + The fields in the signed authenticator are the same as those + in the Kerberos authenticator; in addition, we include a client- + generated nonce, and the name of the KDC. The structure is itself + signed using the user's private key corresponding to the public key + registered with the KDC. + + Typically, preauthentication using a secret key would not be included, + but if included it may be ignored by the KDC. (We recommend that it + not be included: even if the KDC should ignore the preauthentication, + an attacker may not, and use an intercepted message to guess the + password off-line.) + + The response from the KDC would be identical to the response in RFC 1510, + except that instead of being encrypted in the secret key shared by the + client and the KDC, it is encrypted in a random key freshly generated + by the KDC (of type ENCTYPE_ENC_CBC_CRC). A preauthentication field + (specified below) accompanies the response, optionally containing a + certificate with the public key for the KDC (since we do not assume + that the client knows this public key), and a package containing the + secret key in which the rest of the response is encrypted, along with + the same nonce used in the rest of the response, in order to prevent + replays. This package is itself encrypted with the private key of the + KDC, then encrypted with the public key of the user. + + PA-PK-AS-REP ::= SEQUENCE { + kdcCert[0] SEQUENCE OF Certificate, + encryptShell[1] EncryptedData, -- EncPaPkAsRepPartShell + -- encrypted by encReplyTmpKey + encryptKey[2] EncryptedData -- EncPaPkAsRepTmpKey + -- encrypted by userPubliKey + } + + EncPaPkAsRepPartShell ::= SEQUENCE { + encReplyPart[0] EncPaPkAsRepPart, + encReplyPartSig[1] Signature -- encReplyPart + -- signed by kdcPrivateKey + } + + EncPaPkAsRepPart ::= SEQUENCE { + encReplyKey[0] EncryptionKey, + nonce[1] INTEGER + } + + EncPaPkAsRepTmpKey ::= SEQUENCE { + encReplyTmpKey[0] EncryptionKey + } + + Notationally, assume that encryptPack is encrypted (or signed) with + algorithm Ak, and that encryptShell is encrypted with algorithm Au. + Then, encryptShell is + + Au (Ak ({encReplyKey, nonce}, kdcPrivateKey), userPublicKey) + + where kdcPrivateKey is the KDC's private key, and userPublicKey is the + user's public key. + + The kdc-cert specification is lifted, with slight modifications, + from v3 of the X.509 certificate specification: + + Certificate ::= SEQUENCE { + version[0] Version DEFAULT v1 (1), + serialNumber[1] CertificateSerialNumber, + signature[2] AlgorithmIdentifier, + issuer[3] PrincipalName, + validity[4] Validity, + subjectRealm[5] Realm, + subject[6] PrincipalName, + subjectPublicKeyInfo[7] SubjectPublicKeyInfo, + issuerUniqueID[8] IMPLICIT UniqueIdentifier OPTIONAL, + subjectUniqueID[9] IMPLICIT UniqueIdentifier OPTIONAL, + authentSig[10] Signature + } + + The kdc-cert must have as its root certification one of the certifiers + sent to the KDC with the original request. If the KDC has no such + certification, then it will instead reply with a KRB_ERROR of type + KDC_ERROR_PREAUTH_FAILED. If a zero-length root-cert was sent by the + client as part of the PA-PK-AS-ROOT, then a correspondingly zero-length + kdc-cert may be absent, in which case the client uses its copy of the + KDC's public key. + + Upon receipt of the response from the KDC, the client will verify the + public key for the KDC from PA-PK-AS-REP preauthentication data field, + The certificate must certify the key as belonging to a principal whose + name can be derived from the realm name. If the certificate checks + out, the client then decrypts the EncPaPkAsRepPart using the private + key of the user, and verifies the signature of the KDC. It then uses + the random key contained therein to decrypt the rest of the response, + and continues as per RFC 1510. Because there is direct trust between + the user and the KDC, the transited field of the ticket returned by + the KDC should remain empty. (Cf. Section 3.3.) + + +3.2.2. Private key held by KDC + + Implementation of the changes in this section is OPTIONAL. + + When the user's private key is not carried with the user, the user may + encrypt the private key using conventional cryptography, and register + the encrypted private key with the KDC. The MD5 hash of the DES key + used to encrypt the private key must also be registered with the KDC. + + We provide this option with the warning that storing the private key + on the KDC carries the risk of exposure in case the KDC is compromised. + If a suffiently good password is chosen to encrypt the key, then this + password can be used for a limited time to change the private key. + If the user wishes to authenticate himself without storing the private + key on each local disk, then a safer, albeit possibly less practical, + alternative is to use a smart card to store the keys. + + When the user's private key is stored on the KDC, the KDC record + will also indicate whether preauthentication is required before + returning the key (we recommend that it be required). If such + preauthentication is required, when the initial request is received, + the KDC will respond with a KRB_ERROR message, with msg-type set + to KDC_ERR_PREAUTH_REQUIRED, and e-data set to: + + PA-PK-AS-INFO ::= SEQUENCE { + kdcCert[0] SEQUENCE OF Certificate + } + + The kdc-cert field is identical to that in the PA-PK-AS-REP + preauthentication data field returned with the KDC response, and must + be validated as belonging to the KDC in the same manner. + + Upon receipt of the KRB_ERROR message with a PA-PK-AS-INFO field, the + client will prompt the user for the password that was used to + encrypt the private key, derive the DES key from that password, + and calculate the MD5 hash H1 of the DES key. The client then sends + a request to the KDC, which includes a timestamp and a + client-generated random secret key that will be used by the KDC + to super-encrypt the encrypted private key before it is returned + to the client. This information is sent to the KDC in a subsequent + AS_REQ message in a preauthentication data field: + + PA-PK-AS-REQ ::= SEQUENCE { + encHashShell[0] EncryptedData -- EncPaPkAsReqShell + } + + EncPaPkAsReqShell ::= SEQUENCE { + encHashPart[0] EncryptedData -- EncPaPkAsReqPart + } + + EncPaPkAsReqPart ::= SEQUENCE { + encHashKey[0] EncryptionKey, + nonce[1] INTEGER + } + + The EncPaPkAsReqPart is first encrypted with a DES key K1, derived + by string_to_key from the hash H1 (with null salt), then encrypted + again with the KDC's public key from the certificate in the + PA-PK-AS-INFO field of the error response. + + Notationally, if encryption algorithm A is used for DES encryption, + and Ak is used for the public key encryption, then enc-shell is + + Ak (A ({encHashKey, nonce}, K1), kdcPublicKey) + + Upon receipt of the authentication request with the PA-PK-AS-REQ, the + KDC verifies the hash of the user's DES encryption key by attempting + to decrypt the EncPaPkAsReqPart of the PA-PK-AS-REQ. If decryption + is successful, the KDC generates the AS response as defined in + RFC 1510, but additionally includes a preauthentication field of type + PA-PK-USER-KEY. (This response will also be included in response to + the initial request without preauthentication if preauthentication is + not required for the user and the user's encrypted private key is + stored on the KDC.) + + PA-PK-USER-KEY ::= SEQUENCE { + encUserKeyPart[0] EncryptedData -- EncPaPkUserKeyPart + } + + EncPaPkUserKeyPart ::= SEQUENCE { + encUserKey[0] OCTET STRING, + nonce[1] INTEGER + } + + Notationally, if encryption algorithm A is used, then enc-key-part is + + A ({encUserKey, nonce}, enc-hash-key) + + (where A could be null encryption). + + This message contains the encrypted private key that has been + registered with the KDC by the user, as encrypted by the user, + optionally super-encrypted with the enc-hash-key from the PA-PK-AS-REQ + message if preauthentication using that method was provided (otherwise, + the EncryptedData should denote null encryption). Note that since + H1 is a one-way hash, it is not possible for one to decrypt the + message if one possesses H1 but not the DES key that H1 is derived + from. Because there is direct trust between the user and the + KDC, the transited field of the ticket returned by the KDC should + remain empty. (Cf. Section 3.3.) + + +3.3. Clients with a public key certified by an outside authority + + Implementation of the changes in this section is OPTIONAL. + + In the case where the client is not registered with the current KDC, + the client is responsible for obtaining the private key on its own. + The client will request initial tickets from the KDC using the TGS + exchange, but instead of performing pre-authentication using a + Kerberos ticket granting ticket, or with the PA-PK-AS-REQ that is used + when the public key is known to the KDC, the client performs + preauthentication using the preauthentication data field of type + PA-PK-AS-EXT-CERT: + + PA-PK-AS-EXT-CERT ::= SEQUENCE { + userCert[0] SEQUENCE OF OCTET STRING, + signedAuth[1] SignedPKAuthenticator + } + + where the user-cert specification depends on the type of certificate + that the user possesses. In cases where the service has separate + key pairs for digital signature and for encryption, we recommend + that the signature keys be used for the purposes of sending the + preauthentication (and deciphering the response). + + The authenticator is the one used from the exchange in section 3.2.1, + except that it is signed using the private key corresponding to + the public key in the user-cert. + + The KDC will verify the preauthentication authenticator, and check the + certification path against its own policy of legitimate certifiers. + This may be based on a certification hierarchy, or simply a list of + recognized certifiers in a system like PGP. + + If all checks out, the KDC will issue Kerberos credentials, as in 3.2, + but with the names of all the certifiers in the certification path + added to the transited field of the ticket, with a principal name + taken from the certificate (this might be a long path for X.509, or a + string like "John Q. Public " if the certificate + was a PGP certificate. The realm will identify the kind of + certificate and the final certifier as follows: + + cert_type/final_certifier + + as in PGP/. + + +3.4. Digital Signature + + Implementation of the changes in this section is OPTIONAL. + + We offer this option with the warning that it requires the client + process to generate a random DES key; this generation may not + be able to guarantee the same level of randomness as the KDC. + + If a user registered a digital signature key pair with the KDC, + a separate exchange may be used. The client sends a KRB_AS_REQ as + described in section 3.2.2. If the user's database record + indicates that a digital signature key is to be used, then the + KDC sends back a KRB_ERROR as in section 3.2.2. + + It is assumed here that the signature key is stored on local disk. + The client generates a random key of enctype ENCTYPE_DES_CBC_CRC, + signs it using the signature key (otherwise the signature is + performed as described in section 3.2.1), then encrypts the whole with + the public key of the KDC. This is returned with a separate KRB_AS_REQ + in a preauthentication of type + + PA-PK-AS-SIGNED ::= SEQUENCE { + signedKey[0] EncryptedData -- PaPkAsSignedData + } + + PaPkAsSignedData ::= SEQUENCE { + signedKeyPart[0] SignedKeyPart, + signedKeyAuth[1] PKAuthenticator + } + + SignedKeyPart ::= SEQUENCE { + encSignedKey[0] EncryptionKey, + nonce[1] INTEGER + } + + where the nonce is the one from the request. Upon receipt of the + request, the KDC decrypts, then verifies the random key. It then + replies as per RFC 1510, except that instead of being encrypted + with the password-derived DES key, the reply is encrypted using + the randomKey sent by the client. Since the client already knows + this key, there is no need to accompany the reply with an extra + preauthentication field. Because there is direct trust between + the user and the KDC, the transited field of the ticket returned + by the KDC should remain empty. (Cf. Section 3.3.) + + +4. Preauthentication Data Types + + We propose that the following preauthentication types be allocated + for the preauthentication data packages described in this draft: + + #define KRB5_PADATA_ROOT_CERT 17 /* PA-PK-AS-ROOT */ + #define KRB5_PADATA_PUBLIC_REP 18 /* PA-PK-AS-REP */ + #define KRB5_PADATA_PUBLIC_REQ 19 /* PA-PK-AS-REQ */ + #define KRB5_PADATA_PRIVATE_REP 20 /* PA-PK-USER-KEY */ + #define KRB5_PADATA_PUBLIC_EXT 21 /* PA-PK-AS-EXT-CERT */ + #define KRB5_PADATA_PUBLIC_SIGN 22 /* PA-PK-AS-SIGNED */ + + +5. Encryption Information + + For the public key cryptography used in direct registration, we used + (in our implementation) the RSAREF library supplied with the PGP 2.6.2 + release. Encryption and decryption functions were implemented directly + on top of the primitives made available therein, rather than the + fully sealing operations in the API. + + +6. Compatibility with One-Time Passcodes + + We solicit discussion on how the use of public key cryptography for initial + authentication will interact with the proposed use of one time passwords + discussed in Internet Draft . + + +7. Strength of Encryption and Signature Mechanisms + + In light of recent findings on the strengths of MD5 and various DES + modes, we solicit discussion on which modes to incorporate into the + protocol changes. + + +8. Expiration + + This Internet-Draft expires on December 7, 1996. + + +9. Authors' Addresses + + B. Clifford Neuman + USC/Information Sciences Institute + 4676 Admiralty Way Suite 1001 + Marina del Rey, CA 90292-6695 + + Phone: 310-822-1511 + EMail: bcn@isi.edu + + Brian Tung + USC/Information Sciences Institute + 4676 Admiralty Way Suite 1001 + Marina del Rey, CA 90292-6695 + + Phone: 310-822-1511 + EMail: brian@isi.edu + + John Wray + Digital Equipment Corporation + 550 King Street, LKG2-2/Z7 + Littleton, MA 01460 + + Phone: 508-486-5210 + EMail: wray@tuxedo.enet.dec.com diff --git a/doc/standardisation/draft-ietf-cat-kerberos-pk-init-02.txt b/doc/standardisation/draft-ietf-cat-kerberos-pk-init-02.txt new file mode 100644 index 000000000..1a15ae33e --- /dev/null +++ b/doc/standardisation/draft-ietf-cat-kerberos-pk-init-02.txt @@ -0,0 +1,1120 @@ +INTERNET-DRAFT Clifford Neuman +draft-ietf-cat-kerberos-pk-init-02.txt Brian Tung +Updates: RFC 1510 ISI +expires April 19, 1997 John Wray + Digital Equipment Corporation + Jonathan Trostle + CyberSafe Corporation + + + Public Key Cryptography for Initial Authentication in Kerberos + + +0. Status Of this Memo + + This document is an Internet-Draft. Internet-Drafts are working + documents of the Internet Engineering Task Force (IETF), its areas, + and its working groups. Note that other groups may also distribute + working documents as Internet-Drafts. + + Internet-Drafts are draft documents valid for a maximum of six + months and may be updated, replaced, or obsoleted by other docu- + ments at any time. It is inappropriate to use Internet-Drafts as + reference material or to cite them other than as ``work in pro- + gress.'' + + To learn the current status of any Internet-Draft, please check the + ``1id-abstracts.txt'' listing contained in the Internet-Drafts Sha- + dow Directories on ds.internic.net (US East Coast), nic.nordu.net + (Europe), ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific + Rim). + + The distribution of this memo is unlimited. It is filed as + draft-ietf-cat-kerberos-pk-init-02.txt, and expires April 19, 1997. + Please send comments to the authors. + + +1. Abstract + + This document defines extensions to the Kerberos protocol + specification (RFC 1510, "The Kerberos Network Authentication + Service (V5)", September 1993) to provide a method for using public + key cryptography during initial authentication. The method defined + specifies the way in which preauthentication data fields and error + data fields in Kerberos messages are to be used to transport public + key data. + +2. Motivation + + Public key cryptography presents a means by which a principal may + demonstrate possession of a key, without ever having divulged this + key to anyone else. In conventional cryptography, the encryption + key and decryption key are either identical or can easily be + derived from one another. In public key cryptography, however, + neither the public key nor the private key can be derived from the + other (although the private key RECORD may include the information + required to generate BOTH keys). Hence, a message encrypted with a + public key is private, since only the person possessing the private + key can decrypt it; similarly, someone possessing the private key + can also encrypt a message, thus providing a digital signature. + + Furthermore, conventional keys are often derived from passwords, so + messages encrypted with these keys are susceptible to dictionary + attacks, whereas public key pairs are generated from a + pseudo-random number sequence. While it is true that messages + encrypted using public key cryptography are actually encrypted with + a conventional secret key, which is in turn encrypted using the + public key pair, the secret key is also randomly generated and is + hence not vulnerable to a dictionary attack. + + The advantages provided by public key cryptography have produced a + demand for its integration into the Kerberos authentication + protocol. The public key integration into Kerberos described in + this document has three goals. + + First, by allowing users to register public keys with the KDC, the + KDC can be recovered much more easily in the event it is + compromised. With Kerberos as it currently stands, compromise of + the KDC is disastrous. All keys become known by the attacker and + all keys must be changed. Second, we allow users that have public + key certificates signed by outside authorities to obtain Kerberos + credentials for access to Kerberized services. Third, we obtain the + above benefits while maintaining the performance advantages of + Kerberos over protocols that use only public key authentication. + + If users register public keys, compromise of the KDC does not + divulge their private key. Compromise of security on the KDC is + still a problem, since an attacker can impersonate any user by + creating a ticket granting ticket for the user. When the compromise + is detected, the KDC can be cleaned up and restored from backup + media and loaded with a backup private/public key pair. Keys for + application servers are conventional symmetric keys and must be + changed. + + Note: If a user stores his private key, in an encrypted form, on + the KDC, then it may be desirable to change the key pair, since the + private key is encrypted using a symmetric key derived from a + password (as described below), and can therefore be vulnerable to + dictionary attack if a good password policy is not used. + Alternatively, if the encrypting symmetric key has 56 bits, then it + may also be desirable to change the key pair after a short period + due to the short key length. The KDC does not have access to the + user's unencrypted private key. + + There are two important areas where public key cryptography will + have immediate use: in the initial authentication of users + registered with the KDC or using public key certificates from + outside authorities, and to establish inter-realm keys for + cross-realm authentication. This memo describes a method by which + the first of these can be done. The second case will be the topic + for a separate proposal. + + Some of the ideas on which this proposal is based arose during + discussions over several years between members of the SAAG, the + IETF-CAT working group, and the PSRG, regarding integration of + Kerberos and SPX. Some ideas are drawn from the DASS system, and + similar extensions have been discussed for use in DCE. These + changes are by no means endorsed by these groups. This is an + attempt to revive some of the goals of that group, and the + proposal approaches those goals primarily from the Kerberos + perspective. + +3. Initial authentication of users with public keys + + This section describes the extensions to Version 5 of the Kerberos + protocol that will support the use of public key cryptography by + users in the initial request for a ticket granting ticket. + + Roughly speaking, the following changes to RFC 1510 are proposed: + Users can initially authenticate using public key or conventional + (symmetric key) cryptography. After a KDC compromise, the KDC + replies with an error message that informs the client of the new + KDC public backup key. Users must authenticate using public key + cryptography in response to the error message. If applicable, the + client generates the new user secret key at this point as well. + + Public key initial authentication is performed using either the + RSA encryption or Diffie Hellman public key algorithms. There is + also an option to allow the user to store his/her private key + encrypted in the user password in the KDC database; this option + solves the problem of transporting the user private key to + different workstations. The combination of this option and the + provision for conventional symmetric key authentication allows + organizations to smoothly migrate to public key cryptography. + + This proposal will allow users either to use keys registered + directly with the KDC, or to use keys already registered for use + with X.509, PEM, or PGP, to obtain Kerberos credentials. These + credentials can then be used, as before, with application servers + supporting Kerberos. Use of public key cryptography will not be a + requirement for Kerberos, but if one's organization runs a KDC + supporting public key, then users may choose to be registered with + a public key pair, instead of or in addition to the current secret + key. + + The application request and response between Kerberos clients and + application servers will continue to be based on conventional + cryptography, or will be converted to use user-to-user + authentication. There are performance issues and other reasons + that servers may be better off using conventional cryptography. + For this proposal, we feel that 80 percent of the benefits of + integrating public key with Kerberos can be attained for 20 percent + of the effort, by addressing only initial authentication. This + proposal does not preclude separate extensions. + + With these changes, users will be able to register public keys, + only in realms that support public key, but they will still be able + to perform initial authentication from a client that does not + support public key. They will be able to use services registered in + any realm. Furthermore, users registered with conventional keys + will be able to use any client. + + This proposal addresses three ways in which users may use public + key cryptography for initial authentication with Kerberos, with + minimal change to the existing protocol. Users may register keys + directly with the KDC, or they may present certificates by outside + certification authorities (or certifications by other users) + attesting to the association of the public key with the named user. + In both cases, the end result is that the user obtains a + conventional ticket granting ticket or conventional server ticket + that may be used for subsequent authentication, with such + subsequent authentication using only conventional cryptography. + + Additionally, users may also register a digital signature + verification key with the KDC. We provide this option for the + licensing benefits, as well as a simpler variant of the initial + authentication exchange. However, this option relies on the client + to generate random keys. + + We first consider the case where the user's key is registered with + the KDC. + +3.1 Definitions + + Before we proceed, we will lay some groundwork definitions for + encryption and signatures. We propose the following definitions + of signature and encryption modes (and their corresponding values + on the wire): + + #define ENCTYPE_SIGN_MD5_RSA 0x0011 + + #define ENCTYPE_ENCRYPT_RSA_PRIV 0x0021 + #define ENCTYPE_ENCRYPT_RSA_PUB 0x0022 + + allowing further modes to be defined accordingly. + + In the exposition below, we will use the notation E (T, K) to + denote the encryption of data T, with key (or parameters) K. + + If E is ENCTYPE_SIGN_MD5_RSA, then + + E (T, K) = {T, RSAEncryptPrivate (MD5Hash (T), K)} + + If E is ENCTYPE_ENCRYPT_RSA_PRIV, then + + E (T, K) = RSAEncryptPrivate (T, K) + + Correspondingly, if E is ENCTYPE_ENCRYPT_RSA_PUB, then + + E (T, K) = RSAEncryptPublic (T, K) + + +3.2 Initial request for user registered with public key on KDC + + In this scenario it is assumed that the user is registered with a + public key on the KDC. The user's private key may be held by the + user, or it may be stored on the KDC, encrypted so that it cannot + be used by the KDC. + +3.2.1 User's private key is stored locally + + Implementation of the changes in this section is REQUIRED. + + In this section, we present the basic Kerberos V5 pk-init protocol + that all conforming implementations must support. The key features + of the protocol are: (1) easy, automatic (for the clients) recovery + after a KDC compromise, (2) the ability for a realm to support a + mix of old and new Kerberos V5 clients with the new clients being a + mix of both public key and symmetric key configured clients, and + (3) support for Diffie-Hellman (DH) key exchange as well as RSA + public key encryption. The benefit of having new clients being able + to use either symmetric key or public key initial authentication is + that it allows an organization to roll out the new clients as + rapidly as possible without having to be concerned about the need + to purchase additional hardware to support the CPU intensive public + key cryptographic operations. + + In order to give a brief overview of the four protocols in this + section, we now give diagrams of the protocols. We denote + encryption of message M with key K by {M}K and the signature of + message M with key K by [M]K. All messages from the KDC to the + client are AS_REP messages unless denoted otherwise; similarly, all + messages from the client to the KDC are AS_REQ messages unless + denoted otherwise. Since only the padata fields are affected by + this specification in the AS_REQ and AS_REP messages, we do not + show the other fields. We first show the RSA encryption option in + normal mode: + + certifier list, [cksum, time, nonce, kdcRealm, + kdcName]User PrivateKey + C ------------------------------------------------------> KDC + + list of cert's, {[encReplyKey, nonce]KDC privkey} + EncReplyTmpKey, {EncReplyTmpKey}Userpubkey + C <------------------------------------------------------ KDC + + + We now show RSA encryption in recovery mode: + + certifier list, [cksum, time, nonce, kdcRealm, + kdcName]User PrivateKey + C ------------------------------------------------------> KDC + + + KRB_ERROR (error code KDC_RECOVERY_NEEDED) + error data: [nonce, algID (RSA), + KDC PublicKey Kvno and PublicKey, KDC Salt] + Signed with KDC PrivateKey + C <------------------------------------------------------ KDC + + + certifier list, [cksum, time, nonce, kdcRealm, kdcName, + {newUserSymmKey, nonce}KDC public key]User PrivateKey + C ------------------------------------------------------> KDC + + + list of cert's, {[encReplyKey, nonce]KDC privkey} + EncReplyTmpKey, {EncReplyTmpKey}Userpubkey + C <------------------------------------------------------ KDC + + Next, we show Diffie Hellman in normal mode: + + certifier list, [cksum, time, nonce, kdcRealm, kdcName, + User DH public parameter]User PrivateKey + C ------------------------------------------------------> KDC + + + list of cert's, {encReplyKey, nonce}DH shared symmetric + key, [KDC DH public parameter]KDC Private Key + C <------------------------------------------------------ KDC + + + Finally, we show Diffie Hellman in recovery mode: + + certifier list, [cksum, time, nonce, kdcRealm, kdcName, + User DH public parameter]User PrivateKey + C ------------------------------------------------------> KDC + + + KRB_ERROR (error code KDC_RECOVERY_NEEDED) + error data: [nonce, algID (DH), KDC DH public + parameter, KDC DH ID, KDC PublicKey + Kvno and PublicKey, KDC Salt] + Signed with KDC PrivateKey + C <------------------------------------------------------ KDC + + + certifier list, [cksum, time, nonce, kdcRealm, + kdcName, User DH public parameter, {newUserSymmKey, + nonce}DH shared key, KDC DH ID]User PrivateKey + C ------------------------------------------------------> KDC + + + list of cert's, {encReplyKey, nonce}DH shared + symmetric key + C <------------------------------------------------------ KDC + + + + If the user stores his private key locally, the initial request + to the KDC for a ticket granting ticket proceeds according to + RFC 1510, except that a preauthentication field containing a + nonce signed by the user's private key is included. The + preauthentication field may also include a list of the root + certifiers trusted by the user. + + PA-PK-AS-ROOT ::= SEQUENCE { + rootCert[0] SEQUENCE OF OCTET STRING, + signedAuth[1] SignedPKAuthenticator + } + + SignedPKAuthenticator ::= SEQUENCE { + authent[0] PKAuthenticator, + authentSig[1] Signature + } + + PKAuthenticator ::= SEQUENCE { + cksum[0] Checksum OPTIONAL, + cusec[1] INTEGER, + ctime[2] KerberosTime, + nonce[3] INTEGER, + kdcRealm[4] Realm, + kdcName[5] PrincipalName, + clientPubValue[6] SubjectPublicKeyInfo OPTIONAL, + -- DH algorithm + recoveryData[7] RecoveryData OPTIONAL + -- Recovery Alg. + } + + RecoveryData ::= SEQUENCE { + clientRecovData[0] ClientRecovData, + kdcPubValueId[1] INTEGER OPTIONAL + -- DH algorithm, copied + -- from KDC response + } + + ClientRecovData ::= CHOICE { + newPrincKey[0] EncryptedData, -- EncPaPkAsRoot + -- encrypted with + -- either KDC + -- public key or + -- DH shared key + recovDoneFlag[1] INTEGER -- let KDC know that + -- recovery is done + -- when user uses a + -- mix of clients or + -- does not want to + -- keep a symmetric + -- key in the database + } + + EncPaPkAsRoot ::= SEQUENCE { + newSymmKey[0] EncryptionKey -- the principal's new + -- symmetric key + nonce[1] INTEGER -- the same nonce as + -- the one in the + -- PKAuthenticator + } + + Signature ::= SEQUENCE { + sigType[0] INTEGER, + kvno[1] INTEGER OPTIONAL, + sigHash[2] OCTET STRING + } + + Notationally, sigHash is then + + sigType (authent, userPrivateKey) + + where userPrivateKey is the user's private key (corresponding to the + public key held in the user's database record). Valid sigTypes are + thus far limited to the above-listed ENCTYPE_SIGN_MD5_RSA; we expect + that other types may be listed (and given on-the-wire values between + 0x0011 and 0x001f). + + The format of each certificate depends on the particular service + used. (Alternatively, the KDC could send, with its reply, a + sequence of certifications (see below), but since the KDC is likely + to have more certifications than users have trusted root certifiers, + we have chosen the first method.) In the event that the client + believes it already possesses the current public key of the KDC, a + zero-length root-cert field is sent. + + The fields in the signed authenticator are the same as those in the + Kerberos authenticator; in addition, we include a client-generated + nonce, and the name of the KDC. The structure is itself signed + using the user's private key corresponding to the public key + registered with the KDC. We include the newSymmKey field so clients + can generate a new symmetric key (for users, this key is based on + a password and a salt value generated by the KDC) and + confidentially send this key to the KDC during the recovery phase. + + We now describe the recovery phase of the protocol. There is a bit + associated with each principal in the database indicating whether + recovery for that principal is necessary. After a KDC compromise, + the KDC software is reloaded from backup media and a new backup + KDC public/private pair is generated. The public half of this pair + is then either made available to the KDC, or given to the + appropriate certification authorities for certification. The private + half is not made available to the KDC until after the next + compromise clean-up. If clients are maintaining a copy of the KDC + public key, they also have a copy of the backup public key. + + After the reload of KDC software, the bits associated with + recovery of each principal are all set. The KDC clears the bit + for each principal that undergoes the recovery phase. In addition, + there is a bit associated with each principal to indicate whether + there is a valid symmetric key in the database for the principal. + These bits are all cleared after the reload of the KDC software + (the old symmetric keys are no longer valid). Finally, there is a + bit associated with each principal indicating whether that + principal still uses non-public key capable clients. If a user + principal falls into this category, a public key capable client + cannot transparently re-establish a symmetric key for that user, + since the older clients would not be able to compute the new + symmetric key that includes hashing the password with a KDC + supplied salt value. The re-establishment of the symmetric key + in this case is outside the scope of this protocol. + + One method of re-establishing a symmetric key for public key + capable clients is to generate a hash of the user password and a + KDC supplied salt value. The KDC salt is changed after every + compromise of the KDC. In the recovery protocol, if the principal + does not still use old clients, the KDC supplied salt is sent to + the client principal in a KRB_ERROR message with error code + KDC_RECOVERY_NEEDED. The error data field of the message contains + the following structure which is encoded into an octet string. + + PA-PK-KDC-ERR ::= CHOICE { + recoveryDhErr SignedDHError, -- Used during recovery + -- when algorithm is DH + -- based + recoveryPKEncErr SignedPKEncError -- Used during recovery + -- for PK encryption + -- (RSA,...) + } + + SignedDHError ::= SEQUENCE { + dhErr DHError, + dhErrSig Signature + } + + SignedPKEncError ::= SEQUENCE { + pkEncErr PKEncryptError, + pkEncErrSig Signature + } + + DHError ::= SEQUENCE { + nonce INTEGER, -- From AS_REQ + algorithmId INTEGER, -- DH algorithm + kdcPubValue SubjectPublicKeyInfo, -- DH algorithm + kdcPubValueId INTEGER, -- DH algorithm + kdcPublicKeyKvno INTEGER OPTIONAL, -- New KDC public + -- key kvno + kdcPublicKey OCTET STRING OPTIONAL, -- New KDC pubkey + kdcSalt OCTET STRING OPTIONAL -- If user uses + -- only new + -- clients + } + + PKEncryptError ::= SEQUENCE { + nonce INTEGER, -- From AS_REQ + algorithmId INTEGER, -- Public Key + -- encryption alg + kdcPublicKeyKvno INTEGER OPTIONAL, -- New KDC public + -- key kvno + kdcPublicKey OCTET STRING OPTIONAL, -- New KDC public + -- key + kdcSalt OCTET STRING OPTIONAL -- If user uses + -- only new + -- clients + } + + The KDC_RECOVERY_NEEDED error message is sent in response to a + client AS_REQ message if the client principal needs to be + recovered, unless the client AS_REQ contains the PKAuthenticator + with a nonempty RecoveryData field (in this case the client has + already received the KDC_RECOVERY_NEEDED error message. We will + also see in section 3.2.2 that a different error response is + sent by the KDC if the encrypted user private key is stored in + the KDC database.) If the client principal uses only new clients, + then the kdcSalt field is returned; otherwise, the kdcSalt field + is absent. + + If the client uses the Diffie Hellman algorithm during the recovery + phase then the DHError field contains the public Diffie Hellman + parameter (kdcPubValue) for the KDC along with an identifier + (kdcPubValueID). The client will then send this identifier to + the KDC in an AS_REQ message; the identifier allows the KDC to + look up the Diffie Hellman private value corresponding to the + identifier. Depending on how often the KDC updates its private + Diffie Hellman parameters, it will have to store anywhere between a + handful and several dozen of these identifiers and their parameters. + The KDC must send its Diffie Hellman public value to the client + first so the client can encrypt its new symmetric key. + + In the case where the user principal does not need to be recovered + and the user still uses old clients as well as new clients, the + KDC_ERR_NULL_KEY error is sent in response to symmetric AS_REQ + messages when there is no valid symmetric key in the KDC database. + This situation can occur if the user principal has been recovered + but no new symmetric key has been established in the database. + + In addition, the two error messages with error codes + KDC_ERR_PREAUTH_FAILED and KDC_ERR_PREAUTH_REQUIRED are modified + so the error data contains the kdcSalt encoded as an OCTET STRING. + The reason for the modification is to allow principals that use + new clients only to have their symmetric key transparently updated + by the client software during the recovery phase. The kdcSalt is + used to create the new symmetric key. As a performance optimization, + the kdcSalt is stored in the /krb5/salt file along with the realm. + Thus the /krb5/salt file consists of realm-salt pairs. If the file + is missing, or the salt is not correct, the above error messages + allow the client to find out the correct salt. New clients which + are configured for symmetric key authentication attempt to + preauthenticate with the salt from the /krb5/salt file as an + input into their key, and if the file is not present, the new client + does not use preauthentication. The error messages above return + either the correct salt to use, or no salt at all which indicates + that the principal is still using old clients (the client software + should use the existing mapping from the user password to the + symmetric key). + + In order to assure interoperability between clients from different + vendors and organizations, a standard algorithm is needed for + creating the symmetric key from the principal password and kdcSalt. + The algorithm for creating the symmetric key is as follows: take the + SHA-1 hash of the kdcSalt concatenated with the principal password + and use the 20 byte output as the input into the existing key + generation process (string to key function). After a compromise, the + KDC changes the kdcSalt; thus, the recovery algorithm allows users + to obtain a new symmetric key without actually changing their + password. + + The response from the KDC would be identical to the response in RFC + 1510, except that instead of being encrypted in the secret key + shared by the client and the KDC, it is encrypted in a random key + freshly generated by the KDC (of type ENCTYPE_ENC_CBC_CRC). A + preauthentication field (specified below) accompanies the response, + optionally containing a certificate with the public key for the KDC + (since we do not assume that the client knows this public key), and + a package containing the secret key in which the rest of the + response is encrypted, along with the same nonce used in the rest + of the response, in order to prevent replays. This package is itself + signed with the private key of the KDC, then encrypted with the + symmetric key that is returned encrypted in the public key of the + user (or for Diffie Hellman, encrypted in the shared secret Diffie + Hellman symmetric key). + + Pictorially, in the public key encryption case we have: + + kdcCert, {[encReplyKey, nonce] Sig w/KDC + privkey}EncReplyTmpKey, {EncReplyTmpKey}Userpubkey + + Pictorially, in the Diffie Hellman case we have: + + kdcCert, {encReplyKey, nonce}DH shared symmetric key, + [DH public value]Sig w/KDC privkey + + PA-PK-AS-REP ::= SEQUENCE { + kdcCert[0] SEQUENCE OF Certificate, + encryptShell[1] EncryptedData, + -- EncPaPkAsRepPartShell + -- encrypted by + -- encReplyTmpKey or DH + -- shared symmetric key + pubKeyExchange[2] PubKeyExchange OPTIONAL, + -- a choice between + -- a KDC signed DH + -- value and a public + -- key encrypted + -- symmetric key. + -- Not needed after + -- recovery when + -- DH is used. + } + + PubKeyExchange ::= CHOICE { + signedDHPubVal SignedDHPublicValue, + encryptKey EncryptedData + -- EncPaPkAsRepTmpKey + -- encrypted by + -- userPublicKey + } + + SignedDHPublicValue ::= SEQUENCE { + dhPublic[0] SubjectPublicKeyInfo, + dhPublicSig[1] Signature + } + + EncPaPkAsRepPartShell ::= SEQUENCE { + encReplyPart[0] EncPaPkAsRepPart, + encReplyPartSig[1] Signature OPTIONAL + -- encReplyPart + -- signed by kdcPrivateKey + -- except not present in + -- DH case + } + + EncPaPkAsRepPart ::= SEQUENCE { + encReplyKey[0] EncryptionKey, + nonce[1] INTEGER, + } + + EncPaPkAsRepTmpKey ::= SEQUENCE { + encReplyTmpKey[0] EncryptionKey + } + + The kdc-cert specification is lifted, with slight modifications, + from v3 of the X.509 certificate specification: + + Certificate ::= SEQUENCE { + version[0] Version DEFAULT v1 (1), + serialNumber[1] CertificateSerialNumber, + signature[2] AlgorithmIdentifier, + issuer[3] PrincipalName, + validity[4] Validity, + subjectRealm[5] Realm, + subject[6] PrincipalName, + subjectPublicKeyInfo[7] SubjectPublicKeyInfo, + issuerUniqueID[8] IMPLICIT UniqueIdentifier OPTIONAL, + subjectUniqueID[9] IMPLICIT UniqueIdentifier OPTIONAL, + authentSig[10] Signature + } + + The kdc-cert must have as its root certification one of the + certifiers sent to the KDC with the original request. If the KDC + has no such certification, then it will instead reply with a + KRB_ERROR of type KDC_ERROR_PREAUTH_FAILED. If a zero-length + root-cert was sent by the client as part of the PA-PK-AS-ROOT, then + a correspondingly zero-length kdc-cert may be absent, in which case + the client uses its copy of the KDC's public key. In the case of + recovery, the client uses its copy of the backup KDC public key. + + Upon receipt of the response from the KDC, the client will verify + the public key for the KDC from PA-PK-AS-REP preauthentication data + field. The certificate must certify the key as belonging to a + principal whose name can be derived from the realm name. If the + certificate checks out, the client then decrypts the EncPaPkAsRepPart + and verifies the signature of the KDC. It then uses the random key + contained therein to decrypt the rest of the response, and continues + as per RFC 1510. Because there is direct trust between the user and + the KDC, the transited field of the ticket returned by the KDC should + remain empty. (Cf. Section 3.3.) + + Examples + + We now give several examples illustrating the protocols in this + section. Encryption of message M with key K is denoted {M}K and + the signature of message M with key K is denoted [M]K. + + Example 1: The requesting user principal needs to be recovered and + uses only new clients. The recovery algorithm is Diffie Hellman (DH). + Then the exchange sequence between the user principal and the KDC is: + + + Client --------> AS_REQ (with or without preauth) --------> KDC + + Client <--- KRB_ERROR (error code KDC_RECOVERY_NEEDED) <--- KDC + error data: [nonce, algID (DH), KDC DH public parameter, + KDC DH ID, KDC PublicKey Kvno and PublicKey, + KDC Salt]Signed with KDC PrivateKey + + At this point, the client validates the KDC signature, checks to + see if the nonce is the same as the one in the AS_REQ, and stores + the new KDC public key and public key version number. The client + then generates a Diffie Hellman private parameter and computes + the corresponding Diffie Hellman public parameter; the client + also computes the shared Diffie Hellman symmetric key using the + KDC Diffie Hellman public parameter and its own Diffie Hellman + private parameter. Next, the client prompts the user for his/her + password (if it does not already have the password). The password + is concatenated with the KDC Salt and then SHA1 hashed; the + result is fed into the string to key function to obtain the new + user DES key. + + The new user DES key will be encrypted (along with the AS_REQ + nonce) using the Diffie Hellman symmetric key and sent to the + KDC in the new AS_REQ message: + + Client -> AS_REQ with preauth: rootCert, [PKAuthenticator with + user DH public parameter, {newUser DES key, nonce}DH + symmetric key, KDC DH ID]Signed with User PrivateKey + -> KDC + + The KDC DH ID is copied by the client from the KDC_ERROR message + received above. Upon receipt and validation of this message, the + KDC first uses the KDC DH ID as an index to locate its + private Diffie Hellman parameter; it uses this parameter in + combination with the user public Diffie Hellman parameter + to compute the symmetric Diffie Hellman key. The KDC checks + if the encrypted nonce is the same as the one in the + PKAuthenticator and the AS_REQ part. The KDC then enters + the new user DES key into the database, resets the recovery + needed bit, and sets the valid symmetric key in database + bit. The KDC then creates the AS_REP message: + + Client <-- AS_REP with preauth: kdcCert, {encReplyKey, + nonce}DH symmetric key <-------------------- KDC + + + The AS_REP encrypted part is encrypted with the encReplyKey + that is generated on the KDC. The nonces are copied from the + client AS_REQ. The kdcCert is a sequence of certificates + that have been certified by certifiers listed in the client + rootCert field, unless a zero length rootCert field was sent. + In the last case, the kdcCert will also have zero length. + +3.2.2. Private key held by KDC + + Implementation of the changes in this section is RECOMMENDED. + + When the user's private key is not carried with the user, the + user may encrypt the private key using conventional cryptography, + and register the encrypted private key with the KDC. As + described in the previous section, the SHA1 hash of the password + concatenated with the kdcSalt is also stored in the KDC database + if the user only uses new clients. We restrict users of this + protocol to using new clients only. The reason for this restriction + is that it is not secure to store both the user private key + encrypted in the user's password and the user password on the KDC + simultaneously. + + There are several options for storing private keys. If the + user stores their private key on a removable disk, it is + less convenient since they need to always carry the disk + around with them; in addition, the procedures for extracting + the key may vary between different operating systems. + Alternatively, the user can store a private key on the hard + disks of systems that he/she uses; besides limiting the + systems that the user can login from there is also a + greater security risk to the private key. If smart card + readers or slots are deployed in an organization, then the + user can store his/her private key on a smart card. Finally, + the user can store his/her private key encrypted in a password + on the KDC. This last option is probably the most practical + option currently; it is important that a good password policy + be used. + + When the user's private key is stored on the KDC, + preauthentication is required. There are two cases depending on + whether the requesting user principal needs to be recovered. + + In order to obtain its private key, a user principal includes the + padata type PA-PK-AS-REQ in the preauthentication data + field of the AS_REQ message. The accompanying pa-data field is: + + PA-PK-AS-REQ ::= SEQUENCE { + algorithmId[0] INTEGER, -- Public Key Alg. + encClientPubVal[1] EncryptedData -- EncPaPkAsReqDH + -- (encrypted with key + -- K1) + } + + EncPaPkAsReqDH ::= SEQUENCE { + clientPubValue[0] SubjectPublicKeyInfo + } + + Pictorially, PA-PK-AS-REQ is algorithmID, {clientPubValue}K1. + + The user principal sends its Diffie-Hellman public value encrypted + in the key K1. The key K1 is derived by performing string to key on + the SHA1 hash of the user password concatenated with the kdcSalt + which is stored in the /krb5/salt file. If the file is absent, + the concatenation step is skipped in the above algorithm. The + Diffie Hellman parameters g and p are implied by the algorithmID + field. By choosing g and p correctly, dictionary attacks against + the key K1 can be made more difficult [Jaspan]. + + If the requesting user principal needs recovery, the encrypted + user private key is stored in the KDC database, and the AS_REQ + RecoveryData field is not present in the PKAuthenticator, then + the KDC replies with a KRB_ERROR message, with msg-type set to + KDC_ERR_PREAUTH_REQUIRED, and e-data set to: + + PA-PK-AS-INFO ::= SEQUENCE { + signedDHErr SignedDHError, -- signed by KDC + encUserKey OCTET STRING OPTIONAL -- encrypted by + -- user password + -- key; (recovery + -- response) + + } + + The user principal should then continue with the section 3.2.1.1 + protocol using the Diffie Hellman algorithm. + + We now assume that the requesting user principal does not need + recovery. + + Upon receipt of the authentication request with the PA-PK-AS-REQ, + the KDC generates the AS response as defined in RFC 1510, but + additionally includes a preauthentication field of type + PA-PK-USER-KEY. + + PA-PK-USER-KEY ::= SEQUENCE { + kdcCert SEQUENCE OF Certificate, + encUserKeyPart EncryptedData, -- EncPaPkUserKeyPart + kdcPrivKey KDCPrivKey, + kdcPrivKeySig Signature + } + + The kdc-cert field is identical to that in the PA-PK-AS-REP + preauthentication data field returned with the KDC response, and + must be validated as belonging to the KDC in the same manner. + + KDCPrivKey ::= SEQUENCE { + nonce INTEGER, -- From AS_REQ + algorithmId INTEGER, -- DH algorithm + kdcPubValue SubjectPublicKeyInfo, -- DH algorithm + kdcSalt OCTET STRING -- Since user + -- uses only new + -- clients + } + + The KDCPrivKey field is signed using the KDC private key. + The encrypted part of the AS_REP message is encrypted using the + Diffie Hellman derived symmetric key, as is the EncPaPkUserKeyPart. + + EncPaPkUserKeyPart ::= SEQUENCE { + encUserKey OCTET STRING, + nonce INTEGER -- From AS_REQ + } + + Notationally, if encryption algorithm A is used, then enc-key-part + is + + A ({encUserKey, nonce}, Diffie-Hellman-symmetric-key). + + If the client has used an incorrect kdcSalt to compute the + key K1, then the client needs to resubmit the above AS_REQ + message using the correct kdcSalt field from the KDCPrivKey + field. + + This message contains the encrypted private key that has been + registered with the KDC by the user, as encrypted by the user, + super-encrypted with the Diffie Hellman derived symmetric key. + Because there is direct trust between the user and the KDC, the + transited field of the ticket returned by the KDC should remain + empty. (Cf. Section 3.3.) + + Examples + + We now give several examples illustrating the protocols in this + section. + + Example 1: The requesting user principal needs to be recovered + and stores his/her encrypted private key on the KDC. Then the + exchange sequence between the user principal and the KDC is: + + Client --------> AS_REQ (with or without preauth) -----> KDC + + Client <--- KRB_ERROR (error code KDC_ERR_PREAUTH_REQUIRED) + error data: [nonce, algID (DH), KDC DH public + parameter, KDC DH ID, KDC PublicKey + Kvno and PublicKey, KDC Salt]Signed + with KDC PrivateKey, {user private + key}user password <------------- KDC + + The protocol now continues with the second AS_REQ as in Example + 1 of section 3.2.1.1. + + Example 2: The requesting user principal does not need to be + recovered and stores his/her encrypted private key on the KDC. + Then the exchange sequence between the user principal and the KDC + when the user principal wants to obtain his/her private key is: + + Client -> AS_REQ with preauth: algID, + {DH public parameter}K1 -> KDC + + The key K1 is generated by using the string to key function + on the SHA1 hash of the password concatenated with the kdcSalt + from the /krb5/salt file. If the file is absent, then + the concatenation step is skipped, and the client will learn + the correct kdcSalt in the following AS_REP message from the + KDC. The algID should indicate some type of Diffie Hellman + algorithm. + + The KDC replies with the AS_REP message with a preauthentication + data field: + + Client <-- AS_REP with preauth: kdcCert, {encUserKey, <-- KDC + nonce}DH symmetric key, [nonce, algID, DH + public parameter, kdcSalt]KDC privateKey + + The client validates the KDC's signature and checks that + the nonce matches the nonce in its AS_REQ message. + If the kdcSalt does not match what the client used, it + starts the protocol over. The client then uses the KDC + Diffie Hellman public parameter along with its own Diffie + Hellman private parameter to compute the Diffie Hellman + symmetric key. This key is used to decrypt the encUserKey + field; the client checks if the nonce matches its AS_REQ + nonce. At this point, the initial authentication protocol + is complete. + + Example 3: The requesting user principal does not need to be + recovered and stores his/her encrypted private key on the KDC. + In this example, the user principal uses the conventional + symmetric key Kerberos V5 initial authentication protocol + exchange. + + We note that the conventional protocol exposes the user + password to dictionary attacks; therefore, the user password + must be changed more often. An example of when this protocol + would be used is when new clients have been installed but an + organization has not phased in public key authentication for + all clients due to performance concerns. + + Client ----> AS_REQ with preauthentication: {time}K1 --> KDC + + Client <-------------------- AS_REP <------------------ KDC + + The key K1 is derived as in the preceding two examples. + + +3.3. Clients with a public key certified by an outside authority + + Implementation of the changes in this section is OPTIONAL. + + In the case where the client is not registered with the current + KDC, the client is responsible for obtaining the private key on + its own. The client will request initial tickets from the KDC + using the TGS exchange, but instead of performing + preauthentication using a Kerberos ticket granting ticket, or + with the PA-PK-AS-REQ that is used when the public key is known + to the KDC, the client performs preauthentication using the + preauthentication data field of type PA-PK-AS-EXT-CERT: + + PA-PK-AS-EXT-CERT ::= SEQUENCE { + userCert[0] SEQUENCE OF OCTET STRING, + signedAuth[1] SignedPKAuthenticator + } + + where the user-cert specification depends on the type of + certificate that the user possesses. In cases where the service + has separate key pairs for digital signature and for encryption, + we recommend that the signature keys be used for the purposes of + sending the preauthentication (and deciphering the response). + + The authenticator is the one used from the exchange in section + 3.2.1, except that it is signed using the private key corresponding + to the public key in the user-cert. + + The KDC will verify the preauthentication authenticator, and check the + certification path against its own policy of legitimate certifiers. + This may be based on a certification hierarchy, or simply a list of + recognized certifiers in a system like PGP. + + If all checks out, the KDC will issue Kerberos credentials, as in 3.2, + but with the names of all the certifiers in the certification path + added to the transited field of the ticket, with a principal name + taken from the certificate (this might be a long path for X.509, or a + string like "John Q. Public " if the certificate + was a PGP certificate. The realm will identify the kind of + certificate and the final certifier as follows: + + cert_type/final_certifier + + as in PGP/. + + +3.4. Digital Signature + + Implementation of the changes in this section is OPTIONAL. + + We offer this option with the warning that it requires the client + process to generate a random DES key; this generation may not + be able to guarantee the same level of randomness as the KDC. + + If a user registered a digital signature key pair with the KDC, + a separate exchange may be used. The client sends a KRB_AS_REQ + as described in section 3.2.2. If the user's database record + indicates that a digital signature key is to be used, then the + KDC sends back a KRB_ERROR as in section 3.2.2. + + It is assumed here that the signature key is stored on local disk. + The client generates a random key of enctype ENCTYPE_DES_CBC_CRC, + signs it using the signature key (otherwise the signature is + performed as described in section 3.2.1), then encrypts the whole + with the public key of the KDC. This is returned with a separate + KRB_AS_REQ in a preauthentication of type + + PA-PK-AS-SIGNED ::= SEQUENCE { + signedKey[0] EncryptedData -- PaPkAsSignedData + } + + PaPkAsSignedData ::= SEQUENCE { + signedKeyPart[0] SignedKeyPart, + signedKeyAuth[1] PKAuthenticator, + sig[2] Signature + } + + SignedKeyPart ::= SEQUENCE { + encSignedKey[0] EncryptionKey, + nonce[1] INTEGER + } + + where the nonce is the one from the request. Upon receipt of the + request, the KDC decrypts, then verifies the random key. It then + replies as per RFC 1510, except that instead of being encrypted + with the password-derived DES key, the reply is encrypted using + the randomKey sent by the client. Since the client already knows + this key, there is no need to accompany the reply with an extra + preauthentication field. Because there is direct trust between + the user and the KDC, the transited field of the ticket returned + by the KDC should remain empty. (Cf. Section 3.3.) + + In the event that the KDC database indicates that the user + principal must be recovered, and the PKAuthenticator does not + contain the RecoveryData field, the KDC will reply with the + KDC_RECOVERY_NEEDED error. The user principal then sends + another AS_REQ message that includes the RecoveryData field + in the PKAuthenticator. The AS_REP message is the same as + in the basic Kerberos V5 protocol. + + +4. Preauthentication Data Types + + We propose that the following preauthentication types be allocated + for the preauthentication data packages described in this draft: + + #define KRB5_PADATA_ROOT_CERT 17 /* PA-PK-AS-ROOT */ + #define KRB5_PADATA_PUBLIC_REP 18 /* PA-PK-AS-REP */ + #define KRB5_PADATA_PUBLIC_REQ 19 /* PA-PK-AS-REQ */ + #define KRB5_PADATA_PRIVATE_REP 20 /* PA-PK-USER-KEY */ + #define KRB5_PADATA_PUBLIC_EXT 21 /* PA-PK-AS-EXT-CERT */ + #define KRB5_PADATA_PUBLIC_SIGN 22 /* PA-PK-AS-SIGNED */ + + +5. Encryption Information + + For the public key cryptography used in direct registration, we + used (in our implementation) the RSAREF library supplied with the + PGP 2.6.2 release. Encryption and decryption functions were + implemented directly on top of the primitives made available + therein, rather than the fully sealing operations in the API. + + +6. Compatibility with One-Time Passcodes + + We solicit discussion on how the use of public key cryptography + for initial authentication will interact with the proposed use of + one time passwords discussed in Internet Draft + . + +7. Strength of Encryption and Signature Mechanisms + + In light of recent findings on the strengths of MD5 and various DES + modes, we solicit discussion on which modes to incorporate into the + protocol changes. + + +8. Expiration + + This Internet-Draft expires on April 19, 1997. + + +9. Authors' Addresses + + B. Clifford Neuman + USC/Information Sciences Institute + 4676 Admiralty Way Suite 1001 + Marina del Rey, CA 90292-6695 + + Phone: 310-822-1511 + EMail: bcn@isi.edu + + Brian Tung + USC/Information Sciences Institute + 4676 Admiralty Way Suite 1001 + Marina del Rey, CA 90292-6695 + + Phone: 310-822-1511 + EMail: brian@isi.edu + + John Wray + Digital Equipment Corporation + 550 King Street, LKG2-2/Z7 + Littleton, MA 01460 + + Phone: 508-486-5210 + EMail: wray@tuxedo.enet.dec.com + + Jonathan Trostle + CyberSafe Corporation + 1605 NW Sammamish Rd., Suite 310 + Issaquah, WA 98027-5378 + + Phone: 206-391-6000 + EMail: jonathan.trostle@cybersafe.com diff --git a/doc/standardisation/draft-ietf-cat-kerberos-pk-init-03.txt b/doc/standardisation/draft-ietf-cat-kerberos-pk-init-03.txt new file mode 100644 index 000000000..c59aa3c0e --- /dev/null +++ b/doc/standardisation/draft-ietf-cat-kerberos-pk-init-03.txt @@ -0,0 +1,588 @@ +INTERNET-DRAFT Clifford Neuman +draft-ietf-cat-kerberos-pk-init-03.txt Brian Tung +Updates: RFC 1510 ISI +expires September 30, 1997 John Wray + Digital Equipment Corporation + Ari Medvinsky + Matthew Hur + CyberSafe Corporation + Jonathan Trostle + Novell + + + Public Key Cryptography for Initial Authentication in Kerberos + + +0. Status Of this Memo + + This document is an Internet-Draft. Internet-Drafts are working + documents of the Internet Engineering Task Force (IETF), its + areas, and its working groups. Note that other groups may also + distribute working documents as Internet-Drafts. + + Internet-Drafts are draft documents valid for a maximum of six + months and may be updated, replaced, or obsoleted by other + documents at any time. It is inappropriate to use Internet-Drafts + as reference material or to cite them other than as "work in + progress." + + To learn the current status of any Internet-Draft, please check + the "1id-abstracts.txt" listing contained in the Internet-Drafts + Shadow Directories on ds.internic.net (US East Coast), + nic.nordu.net (Europe), ftp.isi.edu (US West Coast), or + munnari.oz.au (Pacific Rim). + + The distribution of this memo is unlimited. It is filed as + draft-ietf-cat-kerberos-pk-init-03.txt, and expires September 30, + 1997. Please send comments to the authors. + + +1. Abstract + + This document defines extensions (PKINIT) to the Kerberos protocol + specification (RFC 1510 [1]) to provide a method for using public + key cryptography during initial authentication. The methods + defined specify the ways in which preauthentication data fields and + error data fields in Kerberos messages are to be used to transport + public key data. + + +2. Introduction + + The popularity of public key cryptography has produced a desire for + its support in Kerberos [2]. The advantages provided by public key + cryptography include simplified key management (from the Kerberos + perspective) and the ability to leverage existing and developing + public key certification infrastructures. + + Public key cryptography can be integrated into Kerberos in a number + of ways. One is to to associate a key pair with each realm, which + can then be used to facilitate cross-realm authentication; this is + the topic of another draft proposal. Another way is to allow users + with public key certificates to use them in initial authentication. + This is the concern of the current document. + + One of the guiding principles in the design of PKINIT is that + changes should be as minimal as possible. As a result, the basic + mechanism of PKINIT is as follows: The user sends a request to the + KDC as before, except that if that user is to use public key + cryptography in the initial authentication step, his certificate + accompanies the initial request, in the preauthentication fields. + + Upon receipt of this request, the KDC verifies the certificate and + issues a ticket granting ticket (TGT) as before, except that instead + of being encrypted in the user's long-term key (which is derived + from a password), it is encrypted in a randomly-generated key. This + random key is in turn encrypted using the public key certificate + that came with the request and signed using the KDC's signature key, + and accompanies the reply, in the preauthentication fields. + + PKINIT also allows for users with only digital signature keys to + authenticate using those keys, and for users to store and retrieve + private keys on the KDC. + + The PKINIT specification may also be used for direct peer to peer + authentication without contacting a central KDC. This application + of PKINIT is described in PKTAPP [4] and is based on concepts + introduced in [5, 6]. For direct client-to-server authentication, + the client uses PKINIT to authenticate to the end server (instead + of a central KDC), which then issues a ticket for itself. This + approach has an advantage over SSL [7] in that the server does not + need to save state (cache session keys). Furthermore, an + additional benefit is that Kerberos tickets can facilitate + delegation (see [8]). + + +3. Proposed Extensions + + This section describes extensions to RFC 1510 for supporting the + use of public key cryptography in the initial request for a ticket + granting ticket (TGT). + + In summary, the following changes to RFC 1510 are proposed: + + --> Users may authenticate using either a public key pair or a + conventional (symmetric) key. If public key cryptography is + used, public key data is transported in preauthentication + data fields to help establish identity. + --> Users may store private keys on the KDC for retrieval during + Kerberos initial authentication. + + This proposal addresses two ways that users may use public key + cryptography for initial authentication. Users may present public + key certificates, or they may generate their own session key, + signed by their digital signature key. In either case, the end + result is that the user obtains an ordinary TGT that may be used for + subsequent authentication, with such authentication using only + conventional cryptography. + + Section 3.1 provides definitions to help specify message formats. + Section 3.2 and 3.3 describe the extensions for the two initial + authentication methods. Section 3.3 describes a way for the user to + store and retrieve his private key on the KDC. + + +3.1. Definitions + + Hash and encryption types will be specified using ENCTYPE tags; we + propose the addition of the following types: + + #define ENCTYPE_SIGN_DSA_GENERATE 0x0011 + #define ENCTYPE_SIGN_DSA_VERIFY 0x0012 + #define ENCTYPE_ENCRYPT_RSA_PRIV 0x0021 + #define ENCTYPE_ENCRYPT_RSA_PUB 0x0022 + + allowing further signature types to be defined in the range 0x0011 + through 0x001f, and further encryption types to be defined in the + range 0x0021 through 0x002f. + + The extensions involve new preauthentication fields. The + preauthentication data types are in the range 17 through 21. + These values are also specified along with their corresponding + ASN.1 definition. + + #define PA-PK-AS-REQ 17 + #define PA-PK-AS-REP 18 + #define PA-PK-AS-SIGN 19 + #define PA-PK-KEY-REQ 20 + #define PA-PK-KEY-REP 21 + + The extensions also involve new error types. The new error types + are in the range 227 through 229. They are: + + #define KDC_ERROR_CLIENT_NOT_TRUSTED 227 + #define KDC_ERROR_KDC_NOT_TRUSTED 228 + #define KDC_ERROR_INVALID_SIG 229 + + In the exposition below, we use the following terms: encryption key, + decryption key, signature key, verification key. It should be + understood that encryption and verification keys are essentially + public keys, and decryption and signature keys are essentially + private keys. The fact that they are logically distinct does + not preclude the assignment of bitwise identical keys. + + +3.2. Standard Public Key Authentication + + Implementation of the changes in this section is REQUIRED for + compliance with pk-init. + + It is assumed that all public keys are signed by some certification + authority (CA). The initial authentication request is sent as per + RFC 1510, except that a preauthentication field containing data + signed by the user's signature key accompanies the request: + + PA-PK-AS-REQ ::- SEQUENCE { + -- PA TYPE 17 + signedPKAuth [0] SignedPKAuthenticator, + userCert [1] SEQUENCE OF Certificate OPTIONAL, + -- the user's certificate + -- optionally followed by that + -- certificate's certifier chain + trustedCertifiers [2] SEQUENCE OF PrincipalName OPTIONAL + -- CAs that the client trusts + } + + SignedPKAuthenticator ::= SEQUENCE { + pkAuth [0] PKAuthenticator, + pkAuthSig [1] Signature, + -- of pkAuth + -- using user's signature key + } + + PKAuthenticator ::= SEQUENCE { + cusec [0] INTEGER, + -- for replay prevention + ctime [1] KerberosTime, + -- for replay prevention + nonce [2] INTEGER, + -- binds response to this request + kdcName [3] PrincipalName, + clientPubValue [4] SubjectPublicKeyInfo OPTIONAL, + -- for Diffie-Hellman algorithm + } + + Signature ::= SEQUENCE { + signedHash [0] EncryptedData + -- of type Checksum + -- encrypted under signature key + } + + Checksum ::= SEQUENCE { + cksumtype [0] INTEGER, + checksum [1] OCTET STRING + } -- as specified by RFC 1510 + + SubjectPublicKeyInfo ::= SEQUENCE { + algorithm [0] algorithmIdentifier, + subjectPublicKey [1] BIT STRING + } -- as specified by the X.509 recommendation [9] + + Certificate ::= SEQUENCE { + CertType [0] INTEGER, + -- type of certificate + -- 1 = X.509v3 (DER encoding) + -- 2 = PGP (per PGP draft) + CertData [1] OCTET STRING + -- actual certificate + -- type determined by CertType + } + + Note: If the signature uses RSA keys, then it is to be performed + as per PKCS #1. + + The PKAuthenticator carries information to foil replay attacks, + to bind the request and response, and to optionally pass the + client's Diffie-Hellman public value (i.e. for using DSA in + combination with Diffie-Hellman). The PKAuthenticator is signed + with the private key corresponding to the public key in the + certificate found in userCert (or cached by the KDC). + + In the PKAuthenticator, the client may specify the KDC name in one + of two ways: 1) a Kerberos principal name, or 2) the name in the + KDC's certificate (e.g., an X.500 name, or a PGP name). Note that + case #1 requires that the certificate name and the Kerberos principal + name be bound together (e.g., via an X.509v3 extension). + + The userCert field is a sequence of certificates, the first of which + must be the user's public key certificate. Any subsequent + certificates will be certificates of the certifiers of the user's + certificate. These cerificates may be used by the KDC to verify the + user's public key. This field is empty if the KDC already has the + user's certifcate. + + The trustedCertifiers field contains a list of certification + authorities trusted by the client, in the case that the client does + not possess the KDC's public key certificate. + + Upon receipt of the AS_REQ with PA-PK-AS-REQ pre-authentication + type, the KDC attempts to verify the user's certificate chain + (userCert), if one is provided in the request. This is done by + verifying the certification path against the KDC's policy of + legitimate certifiers. This may be based on a certification + hierarchy, or it may be simply a list of recognized certifiers in a + system like PGP. If the certification path does not match one of + the KDC's trusted certifiers, the KDC sends back an error message of + type KDC_ERROR_CLIENT_NOT_TRUSTED, and it includes in the error data + field a list of its own trusted certifiers, upon which the client + resends the request. + + If trustedCertifiers is provided in the PA-PK-AS-REQ, the KDC + verifies that it has a certificate issued by one of the certifiers + trusted by the client. If it does not have a suitable certificate, + the KDC returns an error message of type KDC_ERROR_KDC_NOT_TRUSTED + to the client. + + If a trust relationship exists, the KDC then verifies the client's + signature on PKAuthenticator. If that fails, the KDC returns an + error message of type KDC_ERROR_INVALID_SIG. Otherwise, the KDC + uses the timestamp in the PKAuthenticator to assure that the request + is not a replay. The KDC also verifies that its name is specified + in PKAuthenticator. + + Assuming no errors, the KDC replies as per RFC 1510, except that it + encrypts the reply not with the user's key, but with a random key + generated only for this particular response. This random key + is sealed in the preauthentication field: + + PA-PK-AS-REP ::= SEQUENCE { + -- PA TYPE 18 + kdcCert [0] SEQUENCE OF Certificate OPTIONAL, + -- the KDC's certificate + -- optionally followed by that + -- certificate's certifier chain + encPaReply [1] EncryptedData, + -- of type PaReply + -- using either the client public + -- key or the Diffie-Hellman key + -- specified by SignedDHPublicValue + signedDHPublicValue [2] SignedDHPublicValue OPTIONAL + } + + + PaReply ::= SEQUENCE { + replyEncKeyPack [0] ReplyEncKeyPack, + replyEncKeyPackSig [1] Signature, + -- of replyEncKeyPack + -- using KDC's signature key + } + + ReplyEncKeyPack ::= SEQUENCE { + replyEncKey [0] EncryptionKey, + -- used to encrypt main reply + nonce [1] INTEGER + -- binds response to the request + -- passed in the PKAuthenticator + } + + SignedDHPublicValue ::= SEQUENCE { + dhPublicValue [0] SubjectPublicKeyInfo, + dhPublicValueSig [1] Signature + -- of dhPublicValue + -- using KDC's signature key + } + + The kdcCert field is a sequence of certificates, the first of which + must have as its root certifier one of the certifiers sent to the + KDC in the PA-PK-AS-REQ. Any subsequent certificates will be + certificates of the certifiers of the KDC's certificate. These + cerificates may be used by the client to verify the KDC's public + key. This field is empty if the client did not send to the KDC a + list of trusted certifiers (the trustedCertifiers field was empty). + + Since each certifier in the certification path of a user's + certificate is essentially a separate realm, the name of each + certifier shall be added to the transited field of the ticket. The + format of these realm names shall follow the naming constraints set + forth in RFC 1510 (sections 7.1 and 3.3.3.1). Note that this will + require new nametypes to be defined for PGP certifiers and other + types of realms as they arise. + + The KDC's certificate must bind the public key to a name derivable + from the name of the realm for that KDC. The client then extracts + the random key used to encrypt the main reply. This random key (in + encPaReply) is encrypted with either the client's public key or + with a key derived from the DH values exchanged between the client + and the KDC. + + +3.3. Digital Signature + + Implementation of the changes in this section are OPTIONAL for + compliance with pk-init. + + We offer this option with the warning that it requires the client to + generate a random key; the client may not be able to guarantee the + same level of randomness as the KDC. + + If the user registered a digital signature key with the KDC instead + of an encryption key, then a separate exchange must be used. The + client sends a request for a TGT as usual, except that it (rather + than the KDC) generates the random key that will be used to encrypt + the KDC response. This key is sent to the KDC along with the + request in a preauthentication field: + + PA-PK-AS-SIGN ::= SEQUENCE { + -- PA TYPE 19 + encSignedKeyPack [0] EncryptedData + -- of SignedKeyPack + -- using the KDC's public key + } + + SignedKeyPack ::= SEQUENCE { + signedKey [0] KeyPack, + signedKeyAuth [1] PKAuthenticator, + signedKeySig [2] Signature + -- of signedKey.signedKeyAuth + -- using user's signature key + } + + KeyPack ::= SEQUENCE { + randomKey [0] EncryptionKey, + -- will be used to encrypt reply + nonce [1] INTEGER + } + + where the nonce is copied from the request. + + Upon receipt of the PA-PK-AS-SIGN, the KDC decrypts then verifies + the randomKey. It then replies as per RFC 1510, except that the + reply is encrypted not with a password-derived user key, but with + the randomKey sent in the request. Since the client already knows + this key, there is no need to accompany the reply with an extra + preauthentication field. The transited field of the ticket should + specify the certification path as described in Section 3.2. + + +3.4. Retrieving the Private Key From the KDC + + Implementation of the changes in this section is RECOMMENDED for + compliance with pk-init. + + When the user's private key is not stored local to the user, he may + choose to store the private key (normally encrypted using a + password-derived key) on the KDC. We provide this option to present + the user with an alternative to storing the private key on local + disk at each machine where he expects to authenticate himself using + pk-init. It should be noted that it replaces the added risk of + long-term storage of the private key on possibly many workstations + with the added risk of storing the private key on the KDC in a + form vulnerable to brute-force attack. + + In order to obtain a private key, the client includes a + preauthentication field with the AS-REQ message: + + PA-PK-KEY-REQ ::= SEQUENCE { + -- PA TYPE 20 + patimestamp [0] KerberosTime OPTIONAL, + -- used to address replay attacks. + pausec [1] INTEGER OPTIONAL, + -- used to address replay attacks. + nonce [2] INTEGER, + -- binds the reply to this request + privkeyID [3] SEQUENCE OF KeyID OPTIONAL + -- constructed as a hash of + -- public key corresponding to + -- desired private key + } + + KeyID ::= SEQUENCE { + KeyIdentifier [0] OCTET STRING + } + + The client may request a specific private key by sending the + corresponding ID. If this field is left empty, then all + private keys are returned. + + If all checks out, the KDC responds as described in the above + sections, except that an additional preauthentication field, + containing the user's private key, accompanies the reply: + + PA-PK-KEY-REP ::= SEQUENCE { + -- PA TYPE 21 + nonce [0] INTEGER, + -- binds the reply to the request + KeyData [1] SEQUENCE OF KeyPair + } + + KeyPair ::= SEQUENCE { + privKeyID [0] OCTET STRING, + -- corresponding to encPrivKey + encPrivKey [1] OCTET STRING + } + + +3.4.1. Additional Protection of Retrieved Private Keys + + We solicit discussion on the following proposal: that the client may + optionally include in its request additional data to encrypt the + private key, which is currently only protected by the user's + password. One possibility is that the client might generate a + random string of bits, encrypt it with the public key of the KDC (as + in the SignedKeyPack, but with an ordinary OCTET STRING in place of + an EncryptionKey), and include this with the request. The KDC then + XORs each returned key with this random bit string. (If the bit + string is too short, the KDC could either return an error, or XOR + the returned key with a repetition of the bit string.) + + In order to make this work, additional means of preauthentication + need to be devised in order to prevent attackers from simply + inserting their own bit string. One way to do this is to store + a hash of the password-derived key (the one used to encrypt the + private key). This hash is then used in turn to derive a second + key (called the hash-key); the hash-key is used to encrypt an ASN.1 + structure containing the generated bit string and a nonce value + that binds it to the request. + + Since the KDC possesses the hash, it can generate the hash-key and + verify this (weaker) preauthentication, and yet cannot reproduce + the private key itself, since the hash is a one-way function. + + +4. Logistics and Policy Issues + + We solicit discussion on how clients and KDCs should be configured + in order to determine which of the options described above (if any) + should be used. One possibility is to set the user's database + record to indicate that authentication is to use public key + cryptography; this will not work, however, in the event that the + client needs to know before making the initial request. + +5. Compatibility with One-Time Passcodes + + We solicit discussion on how the protocol changes proposed in this + draft will interact with the proposed use of one-time passcodes + discussed in draft-ietf-cat-kerberos-passwords-00.txt. + + +6. Strength of Cryptographic Schemes + + In light of recent findings on the strength of MD5 and DES, + we solicit discussion on which encryption types to incorporate + into the protocol changes. + + +7. Bibliography + + [1] J. Kohl, C. Neuman. The Kerberos Network Authentication + Service (V5). Request for Comments: 1510 + + [2] B.C. Neuman, Theodore Ts'o. Kerberos: An Authentication Service + for Computer Networks, IEEE Communications, 32(9):33-38. + September 1994. + + [3] A. Medvinsky, M. Hur. Addition of Kerberos Cipher Suites to + Transport Layer Security (TLS). + draft-ietf-tls-kerb-cipher-suites-00.txt + + [4] A. Medvinsky, M. Hur, B. Clifford Neuman. Public Key Utilizing + Tickets for Application Servers (PKTAPP). + draft-ietf-cat-pktapp-00.txt + + [5] M. Sirbu, J. Chuang. Distributed Authentication in Kerberos Using + Public Key Cryptography. Symposium On Network and Distributed System + Security, 1997. + + [6] B. Cox, J.D. Tygar, M. Sirbu. NetBill Security and Transaction + Protocol. In Proceedings of the USENIX Workshop on Electronic Commerce, + July 1995. + + [7] Alan O. Freier, Philip Karlton and Paul C. Kocher. + The SSL Protocol, Version 3.0 - IETF Draft. + + [8] B.C. Neuman, Proxy-Based Authorization and Accounting for + Distributed Systems. In Proceedings of the 13th International + Conference on Distributed Computing Systems, May 1993 + + [9] ITU-T (formerly CCITT) + Information technology - Open Systems Interconnection - + The Directory: Authentication Framework Recommendation X.509 + ISO/IEC 9594-8 + + +8. Acknowledgements + + Some of the ideas on which this proposal is based arose during + discussions over several years between members of the SAAG, the IETF + CAT working group, and the PSRG, regarding integration of Kerberos + and SPX. Some ideas have also been drawn from the DASS system. + These changes are by no means endorsed by these groups. This is an + attempt to revive some of the goals of those groups, and this + proposal approaches those goals primarily from the Kerberos + perspective. Lastly, comments from groups working on similar ideas + in DCE have been invaluable. + + +9. Expiration Date + + This draft expires September 30, 1997. + + +10. Authors + + Clifford Neuman + Brian Tung + USC Information Sciences Institute + 4676 Admiralty Way Suite 1001 + Marina del Rey CA 90292-6695 + Phone: +1 310 822 1511 + E-mail: {bcn, brian}@isi.edu + + John Wray + Digital Equipment Corporation + 550 King Street, LKG2-2/Z7 + Littleton, MA 01460 + Phone: +1 508 486 5210 + E-mail: wray@tuxedo.enet.dec.com + + Ari Medvinsky + Matthew Hur + CyberSafe Corporation + 1605 NW Sammamish Road Suite 310 + Issaquah WA 98027-5378 + Phone: +1 206 391 6000 + E-mail: {ari.medvinsky, matt.hur}@cybersafe.com + + Jonathan Trostle + Novell + E-mail: jonathan.trostle@novell.com diff --git a/doc/standardisation/draft-ietf-cat-kerberos-pk-init-04.txt b/doc/standardisation/draft-ietf-cat-kerberos-pk-init-04.txt new file mode 100644 index 000000000..f26cc722d --- /dev/null +++ b/doc/standardisation/draft-ietf-cat-kerberos-pk-init-04.txt @@ -0,0 +1,868 @@ +INTERNET-DRAFT Brian Tung +draft-ietf-cat-kerberos-pk-init-04.txt Clifford Neuman +Updates: RFC 1510 ISI +expires January 31, 1998 John Wray + Digital Equipment Corporation + Ari Medvinsky + Matthew Hur + CyberSafe Corporation + Jonathan Trostle + Novell + + + Public Key Cryptography for Initial Authentication in Kerberos + + +0. Status Of This Memo + + This document is an Internet-Draft. Internet-Drafts are working + documents of the Internet Engineering Task Force (IETF), its + areas, and its working groups. Note that other groups may also + distribute working documents as Internet-Drafts. + + Internet-Drafts are draft documents valid for a maximum of six + months and may be updated, replaced, or obsoleted by other + documents at any time. It is inappropriate to use Internet-Drafts + as reference material or to cite them other than as "work in + progress." + + To learn the current status of any Internet-Draft, please check + the "1id-abstracts.txt" listing contained in the Internet-Drafts + Shadow Directories on ds.internic.net (US East Coast), + nic.nordu.net (Europe), ftp.isi.edu (US West Coast), or + munnari.oz.au (Pacific Rim). + + The distribution of this memo is unlimited. It is filed as + draft-ietf-cat-kerberos-pk-init-04.txt, and expires January 31, + 1998. Please send comments to the authors. + + +1. Abstract + + This document defines extensions (PKINIT) to the Kerberos protocol + specification (RFC 1510 [1]) to provide a method for using public + key cryptography during initial authentication. The methods + defined specify the ways in which preauthentication data fields and + error data fields in Kerberos messages are to be used to transport + public key data. + + +2. Introduction + + The popularity of public key cryptography has produced a desire for + its support in Kerberos [2]. The advantages provided by public key + cryptography include simplified key management (from the Kerberos + perspective) and the ability to leverage existing and developing + public key certification infrastructures. + + Public key cryptography can be integrated into Kerberos in a number + of ways. One is to associate a key pair with each realm, which can + then be used to facilitate cross-realm authentication; this is the + topic of another draft proposal. Another way is to allow users with + public key certificates to use them in initial authentication. This + is the concern of the current document. + + One of the guiding principles in the design of PKINIT is that + changes should be as minimal as possible. As a result, the basic + mechanism of PKINIT is as follows: The user sends a request to the + KDC as before, except that if that user is to use public key + cryptography in the initial authentication step, his certificate + accompanies the initial request, in the preauthentication fields. + + Upon receipt of this request, the KDC verifies the certificate and + issues a ticket granting ticket (TGT) as before, except that instead + of being encrypted in the user's long-term key (which is derived + from a password), it is encrypted in a randomly-generated key. This + random key is in turn encrypted using the public key from the + certificate that came with the request and signed using the KDC's + private key, and accompanies the reply, in the preauthentication + fields. + + PKINIT also allows for users with only digital signature keys to + authenticate using those keys, and for users to store and retrieve + private keys on the KDC. + + The PKINIT specification may also be used for direct peer to peer + authentication without contacting a central KDC. This application + of PKINIT is described in PKTAPP [4] and is based on concepts + introduced in [5, 6]. For direct client-to-server authentication, + the client uses PKINIT to authenticate to the end server (instead + of a central KDC), which then issues a ticket for itself. This + approach has an advantage over SSL [7] in that the server does not + need to save state (cache session keys). Furthermore, an + additional benefit is that Kerberos tickets can facilitate + delegation (see [8]). + + +3. Proposed Extensions + + This section describes extensions to RFC 1510 for supporting the + use of public key cryptography in the initial request for a ticket + granting ticket (TGT). + + In summary, the following changes to RFC 1510 are proposed: + + --> Users may authenticate using either a public key pair or a + conventional (symmetric) key. If public key cryptography is + used, public key data is transported in preauthentication + data fields to help establish identity. + --> Users may store private keys on the KDC for retrieval during + Kerberos initial authentication. + + This proposal addresses two ways that users may use public key + cryptography for initial authentication. Users may present public + key certificates, or they may generate their own session key, + signed by their digital signature key. In either case, the end + result is that the user obtains an ordinary TGT that may be used for + subsequent authentication, with such authentication using only + conventional cryptography. + + Section 3.1 provides definitions to help specify message formats. + Section 3.2 and 3.3 describe the extensions for the two initial + authentication methods. Section 3.4 describes a way for the user to + store and retrieve his private key on the KDC, as an adjunct to the + initial authentication. + + +3.1. Definitions + + The extensions involve new encryption methods; we propose the + addition of the following types: + + dsa-sign 8 + rsa-priv 9 + rsa-pub 10 + rsa-pub-md5 11 + rsa-pub-sha1 12 + + The proposal of these encryption types notwithstanding, we do not + mandate the use of any particular public key encryption method. + + The extensions involve new preauthentication fields; we propose the + addition of the following types: + + PA-PK-AS-REQ 14 + PA-PK-AS-REP 15 + PA-PK-AS-SIGN 16 + PA-PK-KEY-REQ 17 + PA-PK-KEY-REP 18 + + The extensions also involve new error types; we propose the addition + of the following types: + + KDC_ERR_CLIENT_NOT_TRUSTED 62 + KDC_ERR_KDC_NOT_TRUSTED 63 + KDC_ERR_INVALID_SIG 64 + KDC_ERR_KEY_TOO_WEAK 65 + + In many cases, PKINIT requires the encoding of an X.500 name as a + Realm. In these cases, the realm will be represented using a + different style, specified in RFC 1510 with the following example: + + NAMETYPE:rest/of.name=without-restrictions + + For a realm derived from an X.500 name, NAMETYPE will have the value + X500-ASN1-BASE64. The full realm name will appear as follows: + + X500-ASN1-BASE64:Base64Encode(DistinguishedName) + + where Base64 is an ASCII encoding of binary data as per RFC 1521, + and DistinguishedName is the ASN.1 encoding of the X.500 + Distinguished Name from the X.509 certificate. + + Similarly, PKINIT may require the encoding of an X.500 name as a + PrincipalName. In these cases, the name-type of the principal name + shall be set to NT-X500-PRINCIPAL, and the name-string shall be set + as follows: + + Base64Encode(DistinguishedName) + + as described above. + + [Similar description needed on how realm names and principal names + are to be derived from PGP names.] + + +3.1.1. Encryption and Key Formats + + In the exposition below, we use the terms public key and private + key generically. It should be understood that the term "public + key" may be used to refer to either a public encryption key or a + signature verification key, and that the term "private key" may be + used to refer to either a private decryption key or a signature + generation key. The fact that these are logically distinct does + not preclude the assignment of bitwise identical keys. + + All additional symmetric keys specified in this draft shall use the + same encryption type as the session key in the response from the + KDC. These include the temporary keys used to encrypt the signed + random key encrypting the response, as well as the key derived from + Diffie-Hellman agreement. In the case of Diffie-Hellman, the key + shall be produced from the agreed bit string as follows: + + * Truncate the bit string to the appropriate length. + * Rectify parity in each byte (if necessary) to obtain the key. + + For instance, in the case of a DES key, we take the first eight + bytes of the bit stream, and then adjust the least significant bit + of each byte to ensure that each byte has odd parity. + + RFC 1510, Section 6.1, defines EncryptedData as follows: + + EncryptedData ::= SEQUENCE { + etype [0] INTEGER, + kvno [1] INTEGER OPTIONAL, + cipher [2] OCTET STRING + -- is CipherText + } + + RFC 1510 suggests that ciphertext is coded as follows: + + CipherText ::= ENCRYPTED SEQUENCE { + confounder [0] UNTAGGED OCTET STRING(conf_length) + OPTIONAL, + check [1] UNTAGGED OCTET STRING(checksum_length) + OPTIONAL, + msg-seq [2] MsgSequence, + pad [3] UNTAGGED OCTET STRING(pad_length) + OPTIONAL + } + + The PKINIT protocol introduces several new types of encryption. + Data that is encrypted with a public key will allow only the check + optional field, as it is defined above. This type of the checksum + will be specified in the etype field, together with the encryption + type. + + In order to identify the checksum type, etype will have the + following values: + + rsa-pub-MD5 + rsa-pub-SHA1 + + In the case that etype is set to rsa-pub, the optional 'check' + field will not be provided. + + Data that is encrypted with a private key will not use any optional + fields. PKINIT uses private key encryption only for signatures, + which are encrypted checksums. Therefore, the optional check field + is not needed. + + +3.2. Standard Public Key Authentication + + Implementation of the changes in this section is REQUIRED for + compliance with PKINIT. + + It is assumed that all public keys are signed by some certification + authority (CA). The initial authentication request is sent as per + RFC 1510, except that a preauthentication field containing data + signed by the user's private key accompanies the request: + + PA-PK-AS-REQ ::= SEQUENCE { + -- PA TYPE 14 + signedAuthPack [0] SignedAuthPack + userCert [1] SEQUENCE OF Certificate OPTIONAL, + -- the user's certificate chain + trustedCertifiers [2] SEQUENCE OF PrincipalName OPTIONAL + -- CAs that the client trusts + } + + SignedAuthPack ::= SEQUENCE { + authPack [0] AuthPack, + authPackSig [1] Signature, + -- of authPack + -- using user's private key + } + + AuthPack ::= SEQUENCE { + pkAuthenticator [0] PKAuthenticator, + clientPublicValue [1] SubjectPublicKeyInfo OPTIONAL + -- if client is using Diffie-Hellman + } + + PKAuthenticator ::= SEQUENCE { + kdcName [0] PrincipalName, + kdcRealm [1] Realm, + cusec [2] INTEGER, + -- for replay prevention + ctime [3] KerberosTime, + -- for replay prevention + nonce [4] INTEGER + } + + Signature ::= SEQUENCE { + signedHash [0] EncryptedData + -- of type Checksum + } + + Checksum ::= SEQUENCE { + cksumtype [0] INTEGER, + checksum [1] OCTET STRING + } -- as specified by RFC 1510 + + SubjectPublicKeyInfo ::= SEQUENCE { + algorithm [0] AlgorithmIdentifier, + subjectPublicKey [1] BIT STRING + -- for DH, equals + -- public exponent (INTEGER encoded + -- as payload of BIT STRING) + } -- as specified by the X.509 recommendation [9] + + AlgorithmIdentifier ::= SEQUENCE { + algorithm [0] ALGORITHM.&id, + -- for DH, equals + -- dhKeyAgreement + -- ({iso(1) member-body(2) US(840) + -- rsadsi(113549) pkcs(1) pkcs-3(3) + -- 1}) + parameters [1] ALGORITHM.&type + -- for DH, is DHParameter + } -- as specified by the X.509 recommendation [9] + + DHParameter ::= SEQUENCE { + prime [0] INTEGER, + -- p + base [1] INTEGER, + -- g + privateValueLength [2] INTEGER OPTIONAL + } + + Certificate ::= SEQUENCE { + certType [0] INTEGER, + -- type of certificate + -- 1 = X.509v3 (DER encoding) + -- 2 = PGP (per PGP specification) + certData [1] OCTET STRING + -- actual certificate + -- type determined by certType + } + + The PKAuthenticator carries information to foil replay attacks, + to bind the request and response, and to optionally pass the + client's Diffie-Hellman public value (i.e. for using DSA in + combination with Diffie-Hellman). The PKAuthenticator is signed + with the private key corresponding to the public key in the + certificate found in userCert (or cached by the KDC). + + In the PKAuthenticator, the client may specify the KDC name in one + of two ways: + + * The Kerberos principal name krbtgt/@, + where is replaced by the applicable realm name. + * The name in the KDC's certificate (e.g., an X.500 name, or a + PGP name). + + Note that the first case requires that the certificate name and the + Kerberos principal name be bound together (e.g., via an X.509v3 + extension). + + The userCert field is a sequence of certificates, the first of which + must be the user's public key certificate. Any subsequent + certificates will be certificates of the certifiers of the user's + certificate. These cerificates may be used by the KDC to verify the + user's public key. This field may be left empty if the KDC already + has the user's certificate. + + The trustedCertifiers field contains a list of certification + authorities trusted by the client, in the case that the client does + not possess the KDC's public key certificate. + + Upon receipt of the AS_REQ with PA-PK-AS-REQ pre-authentication + type, the KDC attempts to verify the user's certificate chain + (userCert), if one is provided in the request. This is done by + verifying the certification path against the KDC's policy of + legitimate certifiers. This may be based on a certification + hierarchy, or it may be simply a list of recognized certifiers in a + system like PGP. + + If verification of the user's certificate fails, the KDC sends back + an error message of type KDC_ERR_CLIENT_NOT_TRUSTED. The e-data + field contains additional information pertaining to this error, and + is formatted as follows: + + METHOD-DATA ::= SEQUENCE { + method-type [0] INTEGER, + -- 1 = cannot verify public key + -- 2 = invalid certificate + -- 3 = revoked certificate + -- 4 = invalid KDC name + method-data [1] OCTET STRING OPTIONAL + } -- syntax as for KRB_AP_ERR_METHOD (RFC 1510) + + The values for the method-type and method-data fields are described + in Section 3.2.1. + + If trustedCertifiers is provided in the PA-PK-AS-REQ, the KDC + verifies that it has a certificate issued by one of the certifiers + trusted by the client. If it does not have a suitable certificate, + the KDC returns an error message of type KDC_ERR_KDC_NOT_TRUSTED to + the client. + + If a trust relationship exists, the KDC then verifies the client's + signature on PKAuthenticator. If that fails, the KDC returns an + error message of type KDC_ERR_INVALID_SIG. Otherwise, the KDC uses + the timestamp in the PKAuthenticator to assure that the request is + not a replay. The KDC also verifies that its name is specified in + the PKAuthenticator. + + If the clientPublicValue field is filled in, indicating that the + client wishes to use Diffie-Hellman key agreement, then the KDC + checks to see that the parameters satisfy its policy. If they do + not (e.g., the prime size is insufficient for the expected + encryption type), then the KDC sends back an error message of type + KDC_ERR_KEY_TOO_WEAK. Otherwise, it generates its own public and + private values for the response. + + The KDC also checks that the timestamp in the PKAuthenticator is + within the allowable window. If the local (server) time and the + client time in the authenticator differ by more than the allowable + clock skew, then the KDC returns an error message of type + KRB_AP_ERR_SKEW. + + Assuming no errors, the KDC replies as per RFC 1510, except as + follows: The user's name in the ticket is as represented in the + certificate, unless a Kerberos principal name is bound to the name + in the certificate (e.g., via an X.509v3 extension). The user's + realm in the ticket shall be the name of the Certification + Authority that issued the user's public key certificate. + + The KDC encrypts the reply not with the user's long-term key, but + with a random key generated only for this particular response. This + random key is sealed in the preauthentication field: + + PA-PK-AS-REP ::= SEQUENCE { + -- PA TYPE 15 + encSignedReplyKeyPack [0] EncryptedData, + -- of type SignedReplyKeyPack + -- using the temporary key + -- in encTmpKey + encTmpKeyPack [1] EncryptedData, + -- of type TmpKeyPack + -- using either the client public + -- key or the Diffie-Hellman key + -- specified by SignedDHPublicValue + signedKDCPublicValue [2] SignedKDCPublicValue OPTIONAL + -- if one was passed in the request + kdcCert [3] SEQUENCE OF Certificate OPTIONAL, + -- the KDC's certificate chain + } + + SignedReplyKeyPack ::= SEQUENCE { + replyKeyPack [0] ReplyKeyPack, + replyKeyPackSig [1] Signature, + -- of replyEncKeyPack + -- using KDC's private key + } + + ReplyKeyPack ::= SEQUENCE { + replyKey [0] EncryptionKey, + -- used to encrypt main reply + nonce [1] INTEGER + -- binds response to the request + -- must be same as the nonce + -- passed in the PKAuthenticator + } + + TmpKeyPack ::= SEQUENCE { + tmpKey [0] EncryptionKey, + -- used to encrypt the + -- SignedReplyKeyPack + } + + SignedKDCPublicValue ::= SEQUENCE { + kdcPublicValue [0] SubjectPublicKeyInfo, + -- as described above + kdcPublicValueSig [1] Signature + -- of kdcPublicValue + -- using KDC's private key + } + + The kdcCert field is a sequence of certificates, the first of which + must be the KDC's public key certificate. Any subsequent + certificates will be certificates of the certifiers of the KDC's + certificate. The last of these must have as its certifier one of + the certifiers sent to the KDC in the PA-PK-AS-REQ. These + cerificates may be used by the client to verify the KDC's public + key. This field is empty if the client did not send to the KDC a + list of trusted certifiers (the trustedCertifiers field was empty). + + Since each certifier in the certification path of a user's + certificate is essentially a separate realm, the name of each + certifier shall be added to the transited field of the ticket. The + format of these realm names is defined in Section 3.1 of this + document. If applicable, the transit-policy-checked flag should be + set in the issued ticket. + + The KDC's certificate must bind the public key to a name derivable + from the name of the realm for that KDC. For an X.509 certificate, + this is done as follows. The certificate will contain a + distinguished X.500 name contains, in addition to other attributes, + an extended attribute, called principalName, with the KDC's + principal name as its value (as the text string + krbtgt/@, where is the realm + name of the KDC): + + principalName ATTRIBUTE ::= { + WITH SYNTAX PrintableString(SIZE(1..ub-prinicipalName)) + EQUALITY MATCHING RULE caseExactMatch + ORDERING MATCHING RULE caseExactOrderingMatch + SINGLE VALUE TRUE + ID id-at-principalName + } + + ub-principalName INTEGER ::= 1024 + + id-at OBJECT IDENTIFIER ::= {joint-iso-ccitt(2) ds(5) 4} + + id-at-principalName OBJECT IDENTIFIER ::= {id-at 60} + + where ATTRIBUTE is as defined in X.501, and the matching rules are + as defined in X.520. + + [Still need to register principalName.] + + [Still need to discuss what is done for a PGP certificate.] + + The client then extracts the random key used to encrypt the main + reply. This random key (in encPaReply) is encrypted with either the + client's public key or with a key derived from the DH values + exchanged between the client and the KDC. + + +3.2.1. Additional Information for Errors + + This section describes the interpretation of the method-type and + method-data fields of the KDC_ERR_CLIENT_NOT_TRUSTED error. + + If method-type=1, the client's public key certificate chain does not + contain a certificate that is signed by a certification authority + trusted by the KDC. The format of the method-data field will be an + ASN.1 encoding of a list of trusted certifiers, as defined above: + + TrustedCertifiers ::= SEQUENCE OF PrincipalName + + If method-type=2, the signature on one of the certificates in the + chain cannot be verified. The format of the method-data field will + be an ASN.1 encoding of the integer index of the certificate in + question: + + CertificateIndex ::= INTEGER + -- 0 = 1st certificate, + -- 1 = 2nd certificate, etc + + If method-type=3, one of the certificates in the chain has been + revoked. The format of the method-data field will be an ASN.1 + encoding of the integer index of the certificate in question: + + CertificateIndex ::= INTEGER + -- 0 = 1st certificate, + -- 1 = 2nd certificate, etc + + If method-type=4, the KDC name or realm in the PKAuthenticator does + not match the principal name of the KDC. There is no method-data + field in this case. + + +3.3. Digital Signature + + Implementation of the changes in this section are OPTIONAL for + compliance with PKINIT. + + We offer this option with the warning that it requires the client to + generate a random key; the client may not be able to guarantee the + same level of randomness as the KDC. + + If the user registered, or presents a certificate for, a digital + signature key with the KDC instead of an encryption key, then a + separate exchange must be used. The client sends a request for a + TGT as usual, except that it (rather than the KDC) generates the + random key that will be used to encrypt the KDC response. This key + is sent to the KDC along with the request in a preauthentication + field, encrypted with the KDC's public key: + + PA-PK-AS-SIGN ::= SEQUENCE { + -- PA TYPE 16 + encSignedRandomKeyPack [0] EncryptedData, + -- of type SignedRandomKeyPack + -- using the key in encTmpKeyPack + encTmpKeyPack [1] EncryptedData, + -- of type TmpKeyPack + -- using the KDC's public key + userCert [2] SEQUENCE OF Certificate OPTIONAL + -- the user's certificate chain + } + + SignedRandomKeyPack ::= SEQUENCE { + randomkeyPack [0] RandomKeyPack, + randomkeyPackSig [1] Signature + -- of keyPack + -- using user's private key + } + + RandomKeyPack ::= SEQUENCE { + randomKey [0] EncryptionKey, + -- will be used to encrypt reply + randomKeyAuth [1] PKAuthenticator + -- nonce copied from AS-REQ + } + + If the KDC does not accept client-generated random keys as a matter + of policy, then it sends back an error message of type + KDC_ERR_KEY_TOO_WEAK. Otherwise, it extracts the random key as + follows. + + Upon receipt of the PA-PK-AS-SIGN, the KDC decrypts then verifies + the randomKey. It then replies as per RFC 1510, except that the + reply is encrypted not with a password-derived user key, but with + the randomKey sent in the request. Since the client already knows + this key, there is no need to accompany the reply with an extra + preauthentication field. The transited field of the ticket should + specify the certification path as described in Section 3.2. + + +3.4. Retrieving the User's Private Key from the KDC + + Implementation of the changes described in this section are OPTIONAL + for compliance with PKINIT. + + When the user's private key is not stored local to the user, he may + choose to store the private key (normally encrypted using a + password-derived key) on the KDC. In this case, the client makes a + request as described above, except that instead of preauthenticating + with his private key, he uses a symmetric key shared with the KDC. + + For simplicity's sake, this shared key is derived from the password- + derived key used to encrypt the private key, in such a way that the + KDC can authenticate the user with the shared key without being able + to extract the private key. + + We provide this option to present the user with an alternative to + storing the private key on local disk at each machine where he + expects to authenticate himself using PKINIT. It should be noted + that it replaces the added risk of long-term storage of the private + key on possibly many workstations with the added risk of storing the + private key on the KDC in a form vulnerable to brute-force attack. + + Denote by K1 the symmetric key used to encrypt the private key. + Then construct symmetric key K2 as follows: + + * Perform a hash on K1. + * Truncate the digest to Length(K1) bytes. + * Rectify parity in each byte (if necessary) to obtain K2. + + The KDC stores K2, the public key, and the encrypted private key. + This key pair is designated as the "primary" key pair for that user. + This primary key pair is the one used to perform initial + authentication using the PA-PK-AS-REP preauthentication field. If + he desires, he may also store additional key pairs on the KDC; these + may be requested in addition to the primary. When the client + requests initial authentication using public key cryptography, it + must then include in its request, instead of a PA-PK-AS-REQ, the + following preauthentication sequence: + + PA-PK-KEY-REQ ::= SEQUENCE { + -- PA TYPE 17 + signedPKAuth [0] SignedPKAuth, + trustedCertifiers [1] SEQUENCE OF PrincipalName OPTIONAL, + -- CAs that the client trusts + keyIDList [2] SEQUENCE OF Checksum OPTIONAL + -- payload is hash of public key + -- corresponding to desired + -- private key + -- if absent, KDC will return all + -- stored private keys + } + + SignedPKAuth ::= SEQUENCE { + pkAuth [0] PKAuthenticator, + pkAuthSig [1] Signature + -- of pkAuth + -- using the symmetric key K2 + } + + If a keyIDList is present, the first identifier should indicate + the primary private key. No public key certificate is required, + since the KDC stores the public key along with the private key. + If there is no keyIDList, all the user's private keys are returned. + + Upon receipt, the KDC verifies the signature using K2. If the + verification fails, the KDC sends back an error of type + KDC_ERR_INVALID_SIG. If the signature verifies, but the requested + keys are not found on the KDC, then the KDC sends back an error of + type KDC_ERR_PREAUTH_FAILED. If all checks out, the KDC responds as + described in Section 3.2, except that in addition, the KDC appends + the following preauthentication sequence: + + PA-PK-KEY-REP ::= SEQUENCE { + -- PA TYPE 18 + encKeyRep [0] EncryptedData + -- of type EncKeyReply + -- using the symmetric key K2 + } + + EncKeyReply ::= SEQUENCE { + keyPackList [0] SEQUENCE OF KeyPack, + -- the first KeyPair is + -- the primary key pair + nonce [1] INTEGER + -- binds reply to request + -- must be identical to the nonce + -- sent in the SignedAuthPack + } + + KeyPack ::= SEQUENCE { + keyID [0] Checksum, + encPrivKey [1] OCTET STRING + } + + Upon receipt of the reply, the client extracts the encrypted private + keys (and may store them, at the client's option). The primary + private key, which must be the first private key in the keyPack + SEQUENCE, is used to decrypt the random key in the PA-PK-AS-REP; + this key in turn is used to decrypt the main reply as described in + Section 3.2. + + +4. Logistics and Policy + + This section describes a way to define the policy on the use of + PKINIT for each principal and request. + + The KDC is not required to contain a database record for users + that use either the Standard Public Key Authentication or Public Key + Authentication with a Digital Signature. However, if these users + are registered with the KDC, it is recommended that the database + record for these users be modified to include three additional flags + in the attributes field. + + The first flag, use_standard_pk_init, indicates that the user should + authenticate using standard PKINIT as described in Section 3.2. The + second flag, use_digital_signature, indicates that the user should + authenticate using digital signature PKINIT as described in Section + 3.3. The third flag, store_private_key, indicates that the user + has stored his private key on the KDC and should retrieve it using + the exchange described in Section 3.4. + + If one of the preauthentication fields defined above is included in + the request, then the KDC shall respond as described in Sections 3.2 + through 3.4, ignoring the aforementioned database flags. If more + than one of the preauthentication fields is present, the KDC shall + respond with an error of type KDC_ERR_PREAUTH_FAILED. + + In the event that none of the preauthentication fields defined above + are included in the request, the KDC checks to see if any of the + above flags are set. If the first flag is set, then it sends back + an error of type KDC_ERR_PREAUTH_REQUIRED indicating that a + preauthentication field of type PA-PK-AS-REQ must be included in the + request. + + Otherwise, if the first flag is clear, but the second flag is set, + then the KDC sends back an error of type KDC_ERR_PREAUTH_REQUIRED + indicating that a preauthentication field of type PA-PK-AS-SIGN must + be included in the request. + + Lastly, if the first two flags are clear, but the third flag is set, + then the KDC sends back an error of type KDC_ERR_PREAUTH_REQUIRED + indicating that a preauthentication field of type PA-PK-KEY-REQ must + be included in the request. + + +5. Dependence on Transport Mechanisms + + Certificate chains can potentially grow quite large and span several + UDP packets; this in turn increases the probability that a Kerberos + message involving PKINIT extensions will be broken in transit. In + light of the possibility that the Kerberos specification will + allow TCP as a transport mechanism, we solicit discussion on whether + using PKINIT should encourage the use of TCP. + + +6. Bibliography + + [1] J. Kohl, C. Neuman. The Kerberos Network Authentication Service + (V5). Request for Comments 1510. + + [2] B.C. Neuman, Theodore Ts'o. Kerberos: An Authentication Service + for Computer Networks, IEEE Communications, 32(9):33-38. September + 1994. + + [3] A. Medvinsky, M. Hur. Addition of Kerberos Cipher Suites to + Transport Layer Security (TLS). + draft-ietf-tls-kerb-cipher-suites-00.txt + + [4] A. Medvinsky, M. Hur, B. Clifford Neuman. Public Key Utilizing + Tickets for Application Servers (PKTAPP). + draft-ietf-cat-pktapp-00.txt + + [5] M. Sirbu, J. Chuang. Distributed Authentication in Kerberos + Using Public Key Cryptography. Symposium On Network and Distributed + System Security, 1997. + + [6] B. Cox, J.D. Tygar, M. Sirbu. NetBill Security and Transaction + Protocol. In Proceedings of the USENIX Workshop on Electronic + Commerce, July 1995. + + [7] Alan O. Freier, Philip Karlton and Paul C. Kocher. The SSL + Protocol, Version 3.0 - IETF Draft. + + [8] B.C. Neuman, Proxy-Based Authorization and Accounting for + Distributed Systems. In Proceedings of the 13th International + Conference on Distributed Computing Systems, May 1993. + + [9] ITU-T (formerly CCITT) Information technology - Open Systems + Interconnection - The Directory: Authentication Framework + Recommendation X.509 ISO/IEC 9594-8 + + +7. Acknowledgements + + Sasha Medvinsky contributed several ideas to the protocol changes + and specifications in this document. His additions have been most + appreciated. + + Some of the ideas on which this proposal is based arose during + discussions over several years between members of the SAAG, the IETF + CAT working group, and the PSRG, regarding integration of Kerberos + and SPX. Some ideas have also been drawn from the DASS system. + These changes are by no means endorsed by these groups. This is an + attempt to revive some of the goals of those groups, and this + proposal approaches those goals primarily from the Kerberos + perspective. Lastly, comments from groups working on similar ideas + in DCE have been invaluable. + + +8. Expiration Date + + This draft expires January 31, 1997. + + +9. Authors + + Brian Tung + Clifford Neuman + USC Information Sciences Institute + 4676 Admiralty Way Suite 1001 + Marina del Rey CA 90292-6695 + Phone: +1 310 822 1511 + E-mail: {brian, bcn}@isi.edu + + John Wray + Digital Equipment Corporation + 550 King Street, LKG2-2/Z7 + Littleton, MA 01460 + Phone: +1 508 486 5210 + E-mail: wray@tuxedo.enet.dec.com + + Ari Medvinsky + Matthew Hur + CyberSafe Corporation + 1605 NW Sammamish Road Suite 310 + Issaquah WA 98027-5378 + Phone: +1 206 391 6000 + E-mail: {ari.medvinsky, matt.hur}@cybersafe.com + + Jonathan Trostle + Novell Corporation + Provo UT + E-mail: jtrostle@novell.com diff --git a/doc/standardisation/draft-ietf-cat-kerberos-pk-init-05.txt b/doc/standardisation/draft-ietf-cat-kerberos-pk-init-05.txt new file mode 100644 index 000000000..068edc2c0 --- /dev/null +++ b/doc/standardisation/draft-ietf-cat-kerberos-pk-init-05.txt @@ -0,0 +1,916 @@ +INTERNET-DRAFT Brian Tung +draft-ietf-cat-kerberos-pk-init-05.txt Clifford Neuman +Updates: RFC 1510 ISI +expires May 26, 1998 John Wray + Digital Equipment Corporation + Ari Medvinsky + Matthew Hur + CyberSafe Corporation + Jonathan Trostle + Novell + + + Public Key Cryptography for Initial Authentication in Kerberos + + +0. Status Of This Memo + + This document is an Internet-Draft. Internet-Drafts are working + documents of the Internet Engineering Task Force (IETF), its + areas, and its working groups. Note that other groups may also + distribute working documents as Internet-Drafts. + + Internet-Drafts are draft documents valid for a maximum of six + months and may be updated, replaced, or obsoleted by other + documents at any time. It is inappropriate to use Internet-Drafts + as reference material or to cite them other than as "work in + progress." + + To learn the current status of any Internet-Draft, please check + the "1id-abstracts.txt" listing contained in the Internet-Drafts + Shadow Directories on ds.internic.net (US East Coast), + nic.nordu.net (Europe), ftp.isi.edu (US West Coast), or + munnari.oz.au (Pacific Rim). + + The distribution of this memo is unlimited. It is filed as + draft-ietf-cat-kerberos-pk-init-05.txt, and expires May 26, 1998. + Please send comments to the authors. + + +1. Abstract + + This document defines extensions (PKINIT) to the Kerberos protocol + specification (RFC 1510 [1]) to provide a method for using public + key cryptography during initial authentication. The methods + defined specify the ways in which preauthentication data fields and + error data fields in Kerberos messages are to be used to transport + public key data. + + +2. Introduction + + The popularity of public key cryptography has produced a desire for + its support in Kerberos [2]. The advantages provided by public key + cryptography include simplified key management (from the Kerberos + perspective) and the ability to leverage existing and developing + public key certification infrastructures. + + Public key cryptography can be integrated into Kerberos in a number + of ways. One is to associate a key pair with each realm, which can + then be used to facilitate cross-realm authentication; this is the + topic of another draft proposal. Another way is to allow users with + public key certificates to use them in initial authentication. This + is the concern of the current document. + + One of the guiding principles in the design of PKINIT is that + changes should be as minimal as possible. As a result, the basic + mechanism of PKINIT is as follows: The user sends a request to the + KDC as before, except that if that user is to use public key + cryptography in the initial authentication step, his certificate + accompanies the initial request, in the preauthentication fields. + + Upon receipt of this request, the KDC verifies the certificate and + issues a ticket granting ticket (TGT) as before, except that + the encPart from the AS-REP message carrying the TGT is now + encrypted in a randomly-generated key, instead of the user's + long-term key (which is derived from a password). This + random key is in turn encrypted using the public key from the + certificate that came with the request and signed using the KDC's + private key, and accompanies the reply, in the preauthentication + fields. + + PKINIT also allows for users with only digital signature keys to + authenticate using those keys, and for users to store and retrieve + private keys on the KDC. + + The PKINIT specification may also be used for direct peer to peer + authentication without contacting a central KDC. This application + of PKINIT is described in PKTAPP [4] and is based on concepts + introduced in [5, 6]. For direct client-to-server authentication, + the client uses PKINIT to authenticate to the end server (instead + of a central KDC), which then issues a ticket for itself. This + approach has an advantage over SSL [7] in that the server does not + need to save state (cache session keys). Furthermore, an + additional benefit is that Kerberos tickets can facilitate + delegation (see [8]). + + +3. Proposed Extensions + + This section describes extensions to RFC 1510 for supporting the + use of public key cryptography in the initial request for a ticket + granting ticket (TGT). + + In summary, the following changes to RFC 1510 are proposed: + + * Users may authenticate using either a public key pair or a + conventional (symmetric) key. If public key cryptography is + used, public key data is transported in preauthentication + data fields to help establish identity. + * Users may store private keys on the KDC for retrieval during + Kerberos initial authentication. + + This proposal addresses two ways that users may use public key + cryptography for initial authentication. Users may present public + key certificates, or they may generate their own session key, + signed by their digital signature key. In either case, the end + result is that the user obtains an ordinary TGT that may be used for + subsequent authentication, with such authentication using only + conventional cryptography. + + Section 3.1 provides definitions to help specify message formats. + Section 3.2 and 3.3 describe the extensions for the two initial + authentication methods. Section 3.4 describes a way for the user to + store and retrieve his private key on the KDC, as an adjunct to the + initial authentication. + + +3.1. Definitions + + The extensions involve new encryption methods; we propose the + addition of the following types: + + dsa-sign 8 + rsa-priv 9 + rsa-pub 10 + rsa-pub-md5 11 + rsa-pub-sha1 12 + + The proposal of these encryption types notwithstanding, we do not + mandate the use of any particular public key encryption method. + + The extensions involve new preauthentication fields; we propose the + addition of the following types: + + PA-PK-AS-REQ 14 + PA-PK-AS-REP 15 + PA-PK-AS-SIGN 16 + PA-PK-KEY-REQ 17 + PA-PK-KEY-REP 18 + + The extensions also involve new error types; we propose the addition + of the following types: + + KDC_ERR_CLIENT_NOT_TRUSTED 62 + KDC_ERR_KDC_NOT_TRUSTED 63 + KDC_ERR_INVALID_SIG 64 + KDC_ERR_KEY_TOO_WEAK 65 + KDC_ERR_CERTIFICATE_MISMATCH 66 + + In many cases, PKINIT requires the encoding of an X.500 name as a + Realm. In these cases, the realm will be represented using a + different style, specified in RFC 1510 with the following example: + + NAMETYPE:rest/of.name=without-restrictions + + For a realm derived from an X.500 name, NAMETYPE will have the value + X500-RFC1779. The full realm name will appear as follows: + + X500-RFC1779:RFC1779Encode(DistinguishedName) + + where DistinguishedName is an X.500 name, and RFC1779Encode is a + readable ASCII encoding of an X.500 name, as defined by RFC 1779. + To ensure that this encoding is unique, we add the following rules + to those specified by RFC 1779: + + * The optional spaces specified in RFC 1779 are not allowed. + * The character that separates relative distinguished names + must be ',' (i.e., it must never be ';'). + * Attribute values must not be enclosed in double quotes. + * Attribute values must not be specified as hexadecimal + numbers. + * When an attribute name is specified in the form of an OID, + it must start with the 'OID.' prefix, and not the 'oid.' + prefix. + * The order in which the attributes appear in the RFC 1779 + encoding must be the reverse of the order in the ASN.1 + encoding of the X.500 name that appears in the public key + certificate, because RFC 1779 requires that the least + significant relative distinguished name appear first. The + order of the relative distinguished names, as well as the + order of the attributes within each relative distinguished + name, will be reversed. + + Similarly, PKINIT may require the encoding of an X.500 name as a + PrincipalName. In these cases, the name-type of the principal name + shall be set to NT-X500-PRINCIPAL. This new name type is defined + as: + #define CSFC5c_NT_X500_PRINCIPAL 6 + + The name-string shall be set as follows: + + RFC1779Encode(DistinguishedName) + + as described above. + + +3.1.1. Encryption and Key Formats + + In the exposition below, we use the terms public key and private + key generically. It should be understood that the term "public + key" may be used to refer to either a public encryption key or a + signature verification key, and that the term "private key" may be + used to refer to either a private decryption key or a signature + generation key. The fact that these are logically distinct does + not preclude the assignment of bitwise identical keys. + + All additional symmetric keys specified in this draft shall use the + same encryption type as the session key in the response from the + KDC. These include the temporary keys used to encrypt the signed + random key encrypting the response, as well as the key derived from + Diffie-Hellman agreement. In the case of Diffie-Hellman, the key + shall be produced from the agreed bit string as follows: + + * Truncate the bit string to the appropriate length. + * Rectify parity in each byte (if necessary) to obtain the key. + + For instance, in the case of a DES key, we take the first eight + bytes of the bit stream, and then adjust the least significant bit + of each byte to ensure that each byte has odd parity. + + RFC 1510, Section 6.1, defines EncryptedData as follows: + + EncryptedData ::= SEQUENCE { + etype [0] INTEGER, + kvno [1] INTEGER OPTIONAL, + cipher [2] OCTET STRING + -- is CipherText + } + + RFC 1510 also defines how CipherText is to be composed. It is not + an ASN.1 data structure, but rather an octet string which is the + encryption of a plaintext string. This plaintext string is in turn + a concatenation of the following octet strings: a confounder, a + checksum, the message, and padding. Details of how these components + are arranged can be found in RFC 1510. + + The PKINIT protocol introduces several new types of encryption. + Data that is encrypted with a public key will allow only the check + optional field, as it is defined above. This type of the checksum + will be specified in the etype field, together with the encryption + type. + + In order to identify the checksum type, etype will have the + following values: + + rsa-pub-MD5 + rsa-pub-SHA1 + + In the case that etype is set to rsa-pub, the optional 'check' + field will not be provided. + + Data that is encrypted with a private key will not use any optional + fields. PKINIT uses private key encryption only for signatures, + which are encrypted checksums. Therefore, the optional check field + is not needed. + + +3.2. Standard Public Key Authentication + + Implementation of the changes in this section is REQUIRED for + compliance with PKINIT. + + It is assumed that all public keys are signed by some certification + authority (CA). The initial authentication request is sent as per + RFC 1510, except that a preauthentication field containing data + signed by the user's private key accompanies the request: + + PA-PK-AS-REQ ::= SEQUENCE { + -- PA TYPE 14 + signedAuthPack [0] SignedAuthPack + userCert [1] SEQUENCE OF Certificate OPTIONAL, + -- the user's certificate chain + trustedCertifiers [2] SEQUENCE OF PrincipalName OPTIONAL, + -- CAs that the client trusts + serialNumber [3] CertificateSerialNumber OPTIONAL + -- specifying a particular + -- certificate if the client + -- already has it; + -- must be accompanied by + -- a single trustedCertifier + } + + CertificateSerialNumber ::= INTEGER + -- as specified by PKCS 6 + + SignedAuthPack ::= SEQUENCE { + authPack [0] AuthPack, + authPackSig [1] Signature, + -- of authPack + -- using user's private key + } + + AuthPack ::= SEQUENCE { + pkAuthenticator [0] PKAuthenticator, + clientPublicValue [1] SubjectPublicKeyInfo OPTIONAL + -- if client is using Diffie-Hellman + } + + PKAuthenticator ::= SEQUENCE { + kdcName [0] PrincipalName, + kdcRealm [1] Realm, + cusec [2] INTEGER, + -- for replay prevention + ctime [3] KerberosTime, + -- for replay prevention + nonce [4] INTEGER + } + + Signature ::= SEQUENCE { + signedHash [0] EncryptedData + -- of type Checksum + } + + Checksum ::= SEQUENCE { + cksumtype [0] INTEGER, + checksum [1] OCTET STRING + } -- as specified by RFC 1510 + + SubjectPublicKeyInfo ::= SEQUENCE { + algorithm [0] AlgorithmIdentifier, + subjectPublicKey [1] BIT STRING + -- for DH, equals + -- public exponent (INTEGER encoded + -- as payload of BIT STRING) + } -- as specified by the X.509 recommendation [9] + + AlgorithmIdentifier ::= SEQUENCE { + algorithm [0] ALGORITHM.&id, + -- for DH, equals + -- dhKeyAgreement + -- ({iso(1) member-body(2) US(840) + -- rsadsi(113549) pkcs(1) pkcs-3(3) + -- 1}) + parameters [1] ALGORITHM.&type + -- for DH, is DHParameter + } -- as specified by the X.509 recommendation [9] + + DHParameter ::= SEQUENCE { + prime [0] INTEGER, + -- p + base [1] INTEGER, + -- g + privateValueLength [2] INTEGER OPTIONAL + } + + Certificate ::= SEQUENCE { + certType [0] INTEGER, + -- type of certificate + -- 1 = X.509v3 (DER encoding) + -- 2 = PGP (per PGP specification) + certData [1] OCTET STRING + -- actual certificate + -- type determined by certType + } + + If the client passes a certificate serial number in the request, + the KDC is requested to use the referred-to certificate. If none + exists, then the KDC returns an error of type + KDC_ERR_CERTIFICATE_MISMATCH. It also returns this error if, on the + other hand, the client does not pass any trustedCertifiers, + believing that it has the KDC's certificate, but the KDC has more + than one certificate. + + The PKAuthenticator carries information to foil replay attacks, + to bind the request and response, and to optionally pass the + client's Diffie-Hellman public value (i.e. for using DSA in + combination with Diffie-Hellman). The PKAuthenticator is signed + with the private key corresponding to the public key in the + certificate found in userCert (or cached by the KDC). + + In the PKAuthenticator, the client may specify the KDC name in one + of two ways: + + * The Kerberos principal name krbtgt/@, + where is replaced by the applicable realm name. + * The name in the KDC's certificate (e.g., an X.500 name, or a + PGP name). + + Note that the first case requires that the certificate name and the + Kerberos principal name be bound together (e.g., via an X.509v3 + extension). + + The userCert field is a sequence of certificates, the first of which + must be the user's public key certificate. Any subsequent + certificates will be certificates of the certifiers of the user's + certificate. These cerificates may be used by the KDC to verify the + user's public key. This field may be left empty if the KDC already + has the user's certificate. + + The trustedCertifiers field contains a list of certification + authorities trusted by the client, in the case that the client does + not possess the KDC's public key certificate. If the KDC has no + certificate signed by any of the trustedCertifiers, then it returns + an error of type KDC_ERR_CERTIFICATE_MISMATCH. + + Upon receipt of the AS_REQ with PA-PK-AS-REQ pre-authentication + type, the KDC attempts to verify the user's certificate chain + (userCert), if one is provided in the request. This is done by + verifying the certification path against the KDC's policy of + legitimate certifiers. This may be based on a certification + hierarchy, or it may be simply a list of recognized certifiers in a + system like PGP. + + If verification of the user's certificate fails, the KDC sends back + an error message of type KDC_ERR_CLIENT_NOT_TRUSTED. The e-data + field contains additional information pertaining to this error, and + is formatted as follows: + + METHOD-DATA ::= SEQUENCE { + method-type [0] INTEGER, + -- 1 = cannot verify public key + -- 2 = invalid certificate + -- 3 = revoked certificate + -- 4 = invalid KDC name + -- 5 = client name mismatch + method-data [1] OCTET STRING OPTIONAL + } -- syntax as for KRB_AP_ERR_METHOD (RFC 1510) + + The values for the method-type and method-data fields are described + in Section 3.2.1. + + If trustedCertifiers is provided in the PA-PK-AS-REQ, the KDC + verifies that it has a certificate issued by one of the certifiers + trusted by the client. If it does not have a suitable certificate, + the KDC returns an error message of type KDC_ERR_KDC_NOT_TRUSTED to + the client. + + If a trust relationship exists, the KDC then verifies the client's + signature on AuthPack. If that fails, the KDC returns an error + message of type KDC_ERR_INVALID_SIG. Otherwise, the KDC uses the + timestamp in the PKAuthenticator to assure that the request is not a + replay. The KDC also verifies that its name is specified in the + PKAuthenticator. + + If the clientPublicValue field is filled in, indicating that the + client wishes to use Diffie-Hellman key agreement, then the KDC + checks to see that the parameters satisfy its policy. If they do + not (e.g., the prime size is insufficient for the expected + encryption type), then the KDC sends back an error message of type + KDC_ERR_KEY_TOO_WEAK. Otherwise, it generates its own public and + private values for the response. + + The KDC also checks that the timestamp in the PKAuthenticator is + within the allowable window. If the local (server) time and the + client time in the authenticator differ by more than the allowable + clock skew, then the KDC returns an error message of type + KRB_AP_ERR_SKEW. + + Assuming no errors, the KDC replies as per RFC 1510, except as + follows: The user's name in the ticket is as represented in the + certificate, unless a Kerberos principal name is bound to the name + in the certificate (e.g., via an X.509v3 extension). The user's + realm in the ticket shall be the name of the Certification + Authority that issued the user's public key certificate. + + The KDC encrypts the reply not with the user's long-term key, but + with a random key generated only for this particular response. This + random key is sealed in the preauthentication field: + + PA-PK-AS-REP ::= SEQUENCE { + -- PA TYPE 15 + encSignedReplyKeyPack [0] EncryptedData, + -- of type SignedReplyKeyPack + -- using the temporary key + -- in encTmpKey + encTmpKeyPack [1] EncryptedData, + -- of type TmpKeyPack + -- using either the client public + -- key or the Diffie-Hellman key + -- specified by SignedDHPublicValue + signedKDCPublicValue [2] SignedKDCPublicValue OPTIONAL + -- if one was passed in the request + kdcCert [3] SEQUENCE OF Certificate OPTIONAL, + -- the KDC's certificate chain + } + + SignedReplyKeyPack ::= SEQUENCE { + replyKeyPack [0] ReplyKeyPack, + replyKeyPackSig [1] Signature, + -- of replyEncKeyPack + -- using KDC's private key + } + + ReplyKeyPack ::= SEQUENCE { + replyKey [0] EncryptionKey, + -- used to encrypt main reply + -- of same ENCTYPE as session key + nonce [1] INTEGER + -- binds response to the request + -- must be same as the nonce + -- passed in the PKAuthenticator + } + + TmpKeyPack ::= SEQUENCE { + tmpKey [0] EncryptionKey, + -- used to encrypt the + -- SignedReplyKeyPack + -- of same ENCTYPE as session key + } + + SignedKDCPublicValue ::= SEQUENCE { + kdcPublicValue [0] SubjectPublicKeyInfo, + -- as described above + kdcPublicValueSig [1] Signature + -- of kdcPublicValue + -- using KDC's private key + } + + The kdcCert field is a sequence of certificates, the first of which + must be the KDC's public key certificate. Any subsequent + certificates will be certificates of the certifiers of the KDC's + certificate. The last of these must have as its certifier one of + the certifiers sent to the KDC in the PA-PK-AS-REQ. These + cerificates may be used by the client to verify the KDC's public + key. This field is empty if the client did not send to the KDC a + list of trusted certifiers (the trustedCertifiers field was empty). + + Since each certifier in the certification path of a user's + certificate is essentially a separate realm, the name of each + certifier shall be added to the transited field of the ticket. The + format of these realm names is defined in Section 3.1 of this + document. If applicable, the transit-policy-checked flag should be + set in the issued ticket. + + The KDC's certificate must bind the public key to a name derivable + from the name of the realm for that KDC. For an X.509 certificate, + this is done as follows. The name of the KDC will be represented + as an OtherName, encoded as a GeneralString: + + GeneralName ::= CHOICE { + otherName [0] KDCPrincipalName, + ... + } + + KDCPrincipalNameTypes OTHER-NAME ::= { + { PrincipalNameSrvInst IDENTIFIED BY principalNameSrvInst } + } + + KDCPrincipalName ::= SEQUENCE { + nameType OTHER-NAME.&id ( { KDCPrincipalNameTypes } ), + name OTHER-NAME.&type ( { KDCPrincipalNameTypes } + { @nameType } ) + } + + PrincipalNameSrvInst ::= GeneralString + + where (from the Kerberos specification) we have + + krb5 OBJECT IDENTIFIER ::= { iso (1) + org (3) + dod (6) + internet (1) + security (5) + kerberosv5 (2) } + + principalName OBJECT IDENTIFIER ::= { krb5 2 } + + principalNameSrvInst OBJECT IDENTIFIER ::= { principalName 2 } + + The client then extracts the random key used to encrypt the main + reply. This random key (in encPaReply) is encrypted with either the + client's public key or with a key derived from the DH values + exchanged between the client and the KDC. + + +3.2.1. Additional Information for Errors + + This section describes the interpretation of the method-type and + method-data fields of the KDC_ERR_CLIENT_NOT_TRUSTED error. + + If method-type=1, the client's public key certificate chain does not + contain a certificate that is signed by a certification authority + trusted by the KDC. The format of the method-data field will be an + ASN.1 encoding of a list of trusted certifiers, as defined above: + + TrustedCertifiers ::= SEQUENCE OF PrincipalName + + If method-type=2, the signature on one of the certificates in the + chain cannot be verified. The format of the method-data field will + be an ASN.1 encoding of the integer index of the certificate in + question: + + CertificateIndex ::= INTEGER + -- 0 = 1st certificate, + -- 1 = 2nd certificate, etc + + If method-type=3, one of the certificates in the chain has been + revoked. The format of the method-data field will be an ASN.1 + encoding of the integer index of the certificate in question: + + CertificateIndex ::= INTEGER + -- 0 = 1st certificate, + -- 1 = 2nd certificate, etc + + If method-type=4, the KDC name or realm in the PKAuthenticator does + not match the principal name of the KDC. There is no method-data + field in this case. + + If method-type=5, the client name or realm in the certificate does + not match the principal name of the client. There is no + method-data field in this case. + + +3.3. Digital Signature + + Implementation of the changes in this section are OPTIONAL for + compliance with PKINIT. + + We offer this option with the warning that it requires the client to + generate a random key; the client may not be able to guarantee the + same level of randomness as the KDC. + + If the user registered, or presents a certificate for, a digital + signature key with the KDC instead of an encryption key, then a + separate exchange must be used. The client sends a request for a + TGT as usual, except that it (rather than the KDC) generates the + random key that will be used to encrypt the KDC response. This key + is sent to the KDC along with the request in a preauthentication + field, encrypted with the KDC's public key: + + PA-PK-AS-SIGN ::= SEQUENCE { + -- PA TYPE 16 + encSignedRandomKeyPack [0] EncryptedData, + -- of type SignedRandomKeyPack + -- using the key in encTmpKeyPack + encTmpKeyPack [1] EncryptedData, + -- of type TmpKeyPack + -- using the KDC's public key + userCert [2] SEQUENCE OF Certificate OPTIONAL + -- the user's certificate chain + } + + SignedRandomKeyPack ::= SEQUENCE { + randomkeyPack [0] RandomKeyPack, + randomkeyPackSig [1] Signature + -- of keyPack + -- using user's private key + } + + RandomKeyPack ::= SEQUENCE { + randomKey [0] EncryptionKey, + -- will be used to encrypt reply + randomKeyAuth [1] PKAuthenticator + -- nonce copied from AS-REQ + } + + If the KDC does not accept client-generated random keys as a matter + of policy, then it sends back an error message of type + KDC_ERR_KEY_TOO_WEAK. Otherwise, it extracts the random key as + follows. + + Upon receipt of the PA-PK-AS-SIGN, the KDC decrypts then verifies + the randomKey. It then replies as per RFC 1510, except that the + reply is encrypted not with a password-derived user key, but with + the randomKey sent in the request. Since the client already knows + this key, there is no need to accompany the reply with an extra + preauthentication field. The transited field of the ticket should + specify the certification path as described in Section 3.2. + + +3.4. Retrieving the User's Private Key from the KDC + + Implementation of the changes described in this section are OPTIONAL + for compliance with PKINIT. + + When the user's private key is not stored local to the user, he may + choose to store the private key (normally encrypted using a + password-derived key) on the KDC. In this case, the client makes a + request as described above, except that instead of preauthenticating + with his private key, he uses a symmetric key shared with the KDC. + + For simplicity's sake, this shared key is derived from the password- + derived key used to encrypt the private key, in such a way that the + KDC can authenticate the user with the shared key without being able + to extract the private key. + + We provide this option to present the user with an alternative to + storing the private key on local disk at each machine where he + expects to authenticate himself using PKINIT. It should be noted + that it replaces the added risk of long-term storage of the private + key on possibly many workstations with the added risk of storing the + private key on the KDC in a form vulnerable to brute-force attack. + + Denote by K1 the symmetric key used to encrypt the private key. + Then construct symmetric key K2 as follows: + + * Perform a hash on K1. + * Truncate the digest to Length(K1) bytes. + * Rectify parity in each byte (if necessary) to obtain K2. + + The KDC stores K2, the public key, and the encrypted private key. + This key pair is designated as the "primary" key pair for that user. + This primary key pair is the one used to perform initial + authentication using the PA-PK-AS-REP preauthentication field. If + he desires, he may also store additional key pairs on the KDC; these + may be requested in addition to the primary. When the client + requests initial authentication using public key cryptography, it + must then include in its request, instead of a PA-PK-AS-REQ, the + following preauthentication sequence: + + PA-PK-KEY-REQ ::= SEQUENCE { + -- PA TYPE 17 + signedPKAuth [0] SignedPKAuth, + trustedCertifiers [1] SEQUENCE OF PrincipalName OPTIONAL, + -- CAs that the client trusts + keyIDList [2] SEQUENCE OF Checksum OPTIONAL + -- payload is hash of public key + -- corresponding to desired + -- private key + -- if absent, KDC will return all + -- stored private keys + } + + SignedPKAuth ::= SEQUENCE { + pkAuth [0] PKAuthenticator, + pkAuthSig [1] Signature + -- of pkAuth + -- using the symmetric key K2 + } + + If a keyIDList is present, the first identifier should indicate + the primary private key. No public key certificate is required, + since the KDC stores the public key along with the private key. + If there is no keyIDList, all the user's private keys are returned. + + Upon receipt, the KDC verifies the signature using K2. If the + verification fails, the KDC sends back an error of type + KDC_ERR_INVALID_SIG. If the signature verifies, but the requested + keys are not found on the KDC, then the KDC sends back an error of + type KDC_ERR_PREAUTH_FAILED. If all checks out, the KDC responds as + described in Section 3.2, except that in addition, the KDC appends + the following preauthentication sequence: + + PA-PK-KEY-REP ::= SEQUENCE { + -- PA TYPE 18 + encKeyRep [0] EncryptedData + -- of type EncKeyReply + -- using the symmetric key K2 + } + + EncKeyReply ::= SEQUENCE { + keyPackList [0] SEQUENCE OF KeyPack, + -- the first KeyPair is + -- the primary key pair + nonce [1] INTEGER + -- binds reply to request + -- must be identical to the nonce + -- sent in the SignedAuthPack + } + + KeyPack ::= SEQUENCE { + keyID [0] Checksum, + encPrivKey [1] OCTET STRING + } + + Upon receipt of the reply, the client extracts the encrypted private + keys (and may store them, at the client's option). The primary + private key, which must be the first private key in the keyPack + SEQUENCE, is used to decrypt the random key in the PA-PK-AS-REP; + this key in turn is used to decrypt the main reply as described in + Section 3.2. + + +4. Logistics and Policy + + This section describes a way to define the policy on the use of + PKINIT for each principal and request. + + The KDC is not required to contain a database record for users + that use either the Standard Public Key Authentication or Public Key + Authentication with a Digital Signature. However, if these users + are registered with the KDC, it is recommended that the database + record for these users be modified to include three additional flags + in the attributes field. + + The first flag, use_standard_pk_init, indicates that the user should + authenticate using standard PKINIT as described in Section 3.2. The + second flag, use_digital_signature, indicates that the user should + authenticate using digital signature PKINIT as described in Section + 3.3. The third flag, store_private_key, indicates that the user + has stored his private key on the KDC and should retrieve it using + the exchange described in Section 3.4. + + If one of the preauthentication fields defined above is included in + the request, then the KDC shall respond as described in Sections 3.2 + through 3.4, ignoring the aforementioned database flags. If more + than one of the preauthentication fields is present, the KDC shall + respond with an error of type KDC_ERR_PREAUTH_FAILED. + + In the event that none of the preauthentication fields defined above + are included in the request, the KDC checks to see if any of the + above flags are set. If the first flag is set, then it sends back + an error of type KDC_ERR_PREAUTH_REQUIRED indicating that a + preauthentication field of type PA-PK-AS-REQ must be included in the + request. + + Otherwise, if the first flag is clear, but the second flag is set, + then the KDC sends back an error of type KDC_ERR_PREAUTH_REQUIRED + indicating that a preauthentication field of type PA-PK-AS-SIGN must + be included in the request. + + Lastly, if the first two flags are clear, but the third flag is set, + then the KDC sends back an error of type KDC_ERR_PREAUTH_REQUIRED + indicating that a preauthentication field of type PA-PK-KEY-REQ must + be included in the request. + + +5. Transport Issues + + Certificate chains can potentially grow quite large and span several + UDP packets; this in turn increases the probability that a Kerberos + message involving PKINIT extensions will be broken in transit. In + light of the possibility that the Kerberos specification will + require KDCs to accept requests using TCP as a transport mechanism, + we make the same recommendation with respect to the PKINIT + extensions as well. + + +6. Bibliography + + [1] J. Kohl, C. Neuman. The Kerberos Network Authentication Service + (V5). Request for Comments 1510. + + [2] B.C. Neuman, Theodore Ts'o. Kerberos: An Authentication Service + for Computer Networks, IEEE Communications, 32(9):33-38. September + 1994. + + [3] A. Medvinsky, M. Hur. Addition of Kerberos Cipher Suites to + Transport Layer Security (TLS). + draft-ietf-tls-kerb-cipher-suites-00.txt + + [4] A. Medvinsky, M. Hur, B. Clifford Neuman. Public Key Utilizing + Tickets for Application Servers (PKTAPP). + draft-ietf-cat-pktapp-00.txt + + [5] M. Sirbu, J. Chuang. Distributed Authentication in Kerberos + Using Public Key Cryptography. Symposium On Network and Distributed + System Security, 1997. + + [6] B. Cox, J.D. Tygar, M. Sirbu. NetBill Security and Transaction + Protocol. In Proceedings of the USENIX Workshop on Electronic + Commerce, July 1995. + + [7] Alan O. Freier, Philip Karlton and Paul C. Kocher. The SSL + Protocol, Version 3.0 - IETF Draft. + + [8] B.C. Neuman, Proxy-Based Authorization and Accounting for + Distributed Systems. In Proceedings of the 13th International + Conference on Distributed Computing Systems, May 1993. + + [9] ITU-T (formerly CCITT) Information technology - Open Systems + Interconnection - The Directory: Authentication Framework + Recommendation X.509 ISO/IEC 9594-8 + + +7. Acknowledgements + + Sasha Medvinsky contributed several ideas to the protocol changes + and specifications in this document. His additions have been most + appreciated. + + Some of the ideas on which this proposal is based arose during + discussions over several years between members of the SAAG, the IETF + CAT working group, and the PSRG, regarding integration of Kerberos + and SPX. Some ideas have also been drawn from the DASS system. + These changes are by no means endorsed by these groups. This is an + attempt to revive some of the goals of those groups, and this + proposal approaches those goals primarily from the Kerberos + perspective. Lastly, comments from groups working on similar ideas + in DCE have been invaluable. + + +8. Expiration Date + + This draft expires May 26, 1998. + + +9. Authors + + Brian Tung + Clifford Neuman + USC Information Sciences Institute + 4676 Admiralty Way Suite 1001 + Marina del Rey CA 90292-6695 + Phone: +1 310 822 1511 + E-mail: {brian, bcn}@isi.edu + + John Wray + Digital Equipment Corporation + 550 King Street, LKG2-2/Z7 + Littleton, MA 01460 + Phone: +1 508 486 5210 + E-mail: wray@tuxedo.enet.dec.com + + Ari Medvinsky + Matthew Hur + CyberSafe Corporation + 1605 NW Sammamish Road Suite 310 + Issaquah WA 98027-5378 + Phone: +1 206 391 6000 + E-mail: {ari.medvinsky, matt.hur}@cybersafe.com + + Jonathan Trostle + Novell Corporation + Provo UT + E-mail: jtrostle@novell.com diff --git a/doc/standardisation/draft-ietf-cat-kerberos-pk-init-06.txt b/doc/standardisation/draft-ietf-cat-kerberos-pk-init-06.txt new file mode 100644 index 000000000..cb18eb5ca --- /dev/null +++ b/doc/standardisation/draft-ietf-cat-kerberos-pk-init-06.txt @@ -0,0 +1,959 @@ +INTERNET-DRAFT Brian Tung +draft-ietf-cat-kerberos-pk-init-06.txt Clifford Neuman +Updates: RFC 1510 ISI +expires September 15, 1998 John Wray + Digital Equipment Corporation + Ari Medvinsky + Matthew Hur + CyberSafe Corporation + Jonathan Trostle + Novell + + + Public Key Cryptography for Initial Authentication in Kerberos + + +0. Status Of This Memo + + This document is an Internet-Draft. Internet-Drafts are working + documents of the Internet Engineering Task Force (IETF), its + areas, and its working groups. Note that other groups may also + distribute working documents as Internet-Drafts. + + Internet-Drafts are draft documents valid for a maximum of six + months and may be updated, replaced, or obsoleted by other + documents at any time. It is inappropriate to use Internet-Drafts + as reference material or to cite them other than as "work in + progress." + + To learn the current status of any Internet-Draft, please check + the "1id-abstracts.txt" listing contained in the Internet-Drafts + Shadow Directories on ds.internic.net (US East Coast), + nic.nordu.net (Europe), ftp.isi.edu (US West Coast), or + munnari.oz.au (Pacific Rim). + + The distribution of this memo is unlimited. It is filed as + draft-ietf-cat-kerberos-pk-init-05.txt, and expires September 15, + 1998. Please send comments to the authors. + + +1. Abstract + + This document defines extensions (PKINIT) to the Kerberos protocol + specification (RFC 1510 [1]) to provide a method for using public + key cryptography during initial authentication. The methods + defined specify the ways in which preauthentication data fields and + error data fields in Kerberos messages are to be used to transport + public key data. + + +2. Introduction + + The popularity of public key cryptography has produced a desire for + its support in Kerberos [2]. The advantages provided by public key + cryptography include simplified key management (from the Kerberos + perspective) and the ability to leverage existing and developing + public key certification infrastructures. + + Public key cryptography can be integrated into Kerberos in a number + of ways. One is to associate a key pair with each realm, which can + then be used to facilitate cross-realm authentication; this is the + topic of another draft proposal. Another way is to allow users with + public key certificates to use them in initial authentication. This + is the concern of the current document. + + One of the guiding principles in the design of PKINIT is that + changes should be as minimal as possible. As a result, the basic + mechanism of PKINIT is as follows: The user sends a request to the + KDC as before, except that if that user is to use public key + cryptography in the initial authentication step, his certificate + accompanies the initial request, in the preauthentication fields. + + Upon receipt of this request, the KDC verifies the certificate and + issues a ticket granting ticket (TGT) as before, except that + the encPart from the AS-REP message carrying the TGT is now + encrypted in a randomly-generated key, instead of the user's + long-term key (which is derived from a password). This + random key is in turn encrypted using the public key from the + certificate that came with the request and signed using the KDC's + private key, and accompanies the reply, in the preauthentication + fields. + + PKINIT also allows for users with only digital signature keys to + authenticate using those keys, and for users to store and retrieve + private keys on the KDC. + + The PKINIT specification may also be used for direct peer to peer + authentication without contacting a central KDC. This application + of PKINIT is described in PKTAPP [4] and is based on concepts + introduced in [5, 6]. For direct client-to-server authentication, + the client uses PKINIT to authenticate to the end server (instead + of a central KDC), which then issues a ticket for itself. This + approach has an advantage over SSL [7] in that the server does not + need to save state (cache session keys). Furthermore, an + additional benefit is that Kerberos tickets can facilitate + delegation (see [8]). + + +3. Proposed Extensions + + This section describes extensions to RFC 1510 for supporting the + use of public key cryptography in the initial request for a ticket + granting ticket (TGT). + + In summary, the following changes to RFC 1510 are proposed: + + * Users may authenticate using either a public key pair or a + conventional (symmetric) key. If public key cryptography is + used, public key data is transported in preauthentication + data fields to help establish identity. + * Users may store private keys on the KDC for retrieval during + Kerberos initial authentication. + + This proposal addresses two ways that users may use public key + cryptography for initial authentication. Users may present public + key certificates, or they may generate their own session key, + signed by their digital signature key. In either case, the end + result is that the user obtains an ordinary TGT that may be used for + subsequent authentication, with such authentication using only + conventional cryptography. + + Section 3.1 provides definitions to help specify message formats. + Section 3.2 and 3.3 describe the extensions for the two initial + authentication methods. Section 3.4 describes a way for the user to + store and retrieve his private key on the KDC, as an adjunct to the + initial authentication. + + +3.1. Definitions + + The extensions involve new encryption methods; we propose the + addition of the following types: + + dsa-sign 8 + rsa-priv 9 + rsa-pub 10 + rsa-pub-md5 11 + rsa-pub-sha1 12 + + The proposal of these encryption types notwithstanding, we do not + mandate the use of any particular public key encryption method. + + The extensions involve new preauthentication fields; we propose the + addition of the following types: + + PA-PK-AS-REQ 14 + PA-PK-AS-REP 15 + PA-PK-AS-SIGN 16 + PA-PK-KEY-REQ 17 + PA-PK-KEY-REP 18 + + The extensions also involve new error types; we propose the addition + of the following types: + + KDC_ERR_CLIENT_NOT_TRUSTED 62 + KDC_ERR_KDC_NOT_TRUSTED 63 + KDC_ERR_INVALID_SIG 64 + KDC_ERR_KEY_TOO_WEAK 65 + KDC_ERR_CERTIFICATE_MISMATCH 66 + + In addition, PKINIT does not define, but does permit, the following + algorithm identifiers for use with the Signature data structure: + + md4WithRSAEncryption (as defined in PKCS 1) + md5WithRSAEncryption (as defined in PKCS 1) + sha-1WithRSAEncryption ::= { iso(1) member-body(2) us(840) + rsadsi(113549) pkcs(1) pkcs-1(1) 5 } + dsaWithSHA1 ::= { OIW oIWSecSig(3) oIWSecAlgorithm(2) + dsaWithSHA1(27) } + + where + + OIW ::= iso(1) identifiedOrganization(3) oIW(14) + + In many cases, PKINIT requires the encoding of an X.500 name as a + Realm. In these cases, the realm will be represented using a + different style, specified in RFC 1510 with the following example: + + NAMETYPE:rest/of.name=without-restrictions + + For a realm derived from an X.500 name, NAMETYPE will have the value + X500-RFC1779. The full realm name will appear as follows: + + X500-RFC1779:RFC1779Encode(DistinguishedName) + + where DistinguishedName is an X.500 name, and RFC1779Encode is a + readable ASCII encoding of an X.500 name, as defined by RFC 1779. + To ensure that this encoding is unique, we add the following rules + to those specified by RFC 1779: + + * The optional spaces specified in RFC 1779 are not allowed. + * The character that separates relative distinguished names + must be ',' (i.e., it must never be ';'). + * Attribute values must not be enclosed in double quotes. + * Attribute values must not be specified as hexadecimal + numbers. + * When an attribute name is specified in the form of an OID, + it must start with the 'OID.' prefix, and not the 'oid.' + prefix. + * The order in which the attributes appear in the RFC 1779 + encoding must be the reverse of the order in the ASN.1 + encoding of the X.500 name that appears in the public key + certificate, because RFC 1779 requires that the least + significant relative distinguished name appear first. The + order of the relative distinguished names, as well as the + order of the attributes within each relative distinguished + name, will be reversed. + + Similarly, PKINIT may require the encoding of an X.500 name as a + PrincipalName. In these cases, the name-type of the principal name + shall be set to NT-X500-PRINCIPAL. This new name type is defined + as: + + #define CSFC5c_NT_X500_PRINCIPAL 6 + + The name-string shall be set as follows: + + RFC1779Encode(DistinguishedName) + + as described above. + + +3.1.1. Encryption and Key Formats + + In the exposition below, we use the terms public key and private + key generically. It should be understood that the term "public + key" may be used to refer to either a public encryption key or a + signature verification key, and that the term "private key" may be + used to refer to either a private decryption key or a signature + generation key. The fact that these are logically distinct does + not preclude the assignment of bitwise identical keys. + + All additional symmetric keys specified in this draft shall use the + same encryption type as the session key in the response from the + KDC. These include the temporary keys used to encrypt the signed + random key encrypting the response, as well as the key derived from + Diffie-Hellman agreement. In the case of Diffie-Hellman, the key + shall be produced from the agreed bit string as follows: + + * Truncate the bit string to the appropriate length. + * Rectify parity in each byte (if necessary) to obtain the key. + + For instance, in the case of a DES key, we take the first eight + bytes of the bit stream, and then adjust the least significant bit + of each byte to ensure that each byte has odd parity. + + RFC 1510, Section 6.1, defines EncryptedData as follows: + + EncryptedData ::= SEQUENCE { + etype [0] INTEGER, + kvno [1] INTEGER OPTIONAL, + cipher [2] OCTET STRING + -- is CipherText + } + + RFC 1510 also defines how CipherText is to be composed. It is not + an ASN.1 data structure, but rather an octet string which is the + encryption of a plaintext string. This plaintext string is in turn + a concatenation of the following octet strings: a confounder, a + checksum, the message, and padding. Details of how these components + are arranged can be found in RFC 1510. + + The PKINIT protocol introduces several new types of encryption. + Data that is encrypted with a public key will allow only the check + optional field, as it is defined above. This type of the checksum + will be specified in the etype field, together with the encryption + type. + + In order to identify the checksum type, etype will have the + following values: + + rsa-pub-MD5 + rsa-pub-SHA1 + + In the case that etype is set to rsa-pub, the optional 'check' + field will not be provided. + + Data that is encrypted with a private key will not use any optional + fields. PKINIT uses private key encryption only for signatures, + which are encrypted checksums. Therefore, the optional check field + is not needed. + + +3.2. Standard Public Key Authentication + + Implementation of the changes in this section is REQUIRED for + compliance with PKINIT. + + It is assumed that all public keys are signed by some certification + authority (CA). The initial authentication request is sent as per + RFC 1510, except that a preauthentication field containing data + signed by the user's private key accompanies the request: + + PA-PK-AS-REQ ::= SEQUENCE { + -- PA TYPE 14 + signedAuthPack [0] SignedAuthPack + userCert [1] SEQUENCE OF Certificate OPTIONAL, + -- the user's certificate chain + trustedCertifiers [2] SEQUENCE OF PrincipalName OPTIONAL, + -- CAs that the client trusts + serialNumber [3] CertificateSerialNumber OPTIONAL + -- specifying a particular + -- certificate if the client + -- already has it; + -- must be accompanied by + -- a single trustedCertifier + } + + CertificateSerialNumber ::= INTEGER + -- as specified by PKCS 6 + + SignedAuthPack ::= SEQUENCE { + authPack [0] AuthPack, + authPackSig [1] Signature, + -- of authPack + -- using user's private key + } + + AuthPack ::= SEQUENCE { + pkAuthenticator [0] PKAuthenticator, + clientPublicValue [1] SubjectPublicKeyInfo OPTIONAL + -- if client is using Diffie-Hellman + } + + PKAuthenticator ::= SEQUENCE { + kdcName [0] PrincipalName, + kdcRealm [1] Realm, + cusec [2] INTEGER, + -- for replay prevention + ctime [3] KerberosTime, + -- for replay prevention + nonce [4] INTEGER + } + + Signature ::= SEQUENCE { + signatureAlgorithm [0] SignatureAlgorithmIdentifier, + pkcsSignature [1] BIT STRING + -- octet-aligned big-endian bit + -- string (encrypted with signer's + -- private key) + } + + SignatureAlgorithmIdentifier ::= AlgorithmIdentifier + + AlgorithmIdentifier ::= SEQUENCE { + algorithm ALGORITHM.&id, + -- for DH, equals + -- dhKeyAgreement + -- ({iso(1) member-body(2) US(840) + -- rsadsi(113549) pkcs(1) pkcs-3(3) + -- 1}) + parameters ALGORITHM.&type + -- for DH, is DHParameter + } -- as specified by the X.509 recommendation [9] + + SubjectPublicKeyInfo ::= SEQUENCE { + algorithm AlgorithmIdentifier, + subjectPublicKey BIT STRING + -- for DH, equals + -- public exponent (INTEGER encoded + -- as payload of BIT STRING) + } -- as specified by the X.509 recommendation [9] + + DHParameter ::= SEQUENCE { + prime INTEGER, + -- p + base INTEGER, + -- g + privateValueLength INTEGER OPTIONAL + } -- as specified by the X.509 recommendation [9] + + Certificate ::= SEQUENCE { + certType [0] INTEGER, + -- type of certificate + -- 1 = X.509v3 (DER encoding) + -- 2 = PGP (per PGP specification) + certData [1] OCTET STRING + -- actual certificate + -- type determined by certType + } + + If the client passes a certificate serial number in the request, + the KDC is requested to use the referred-to certificate. If none + exists, then the KDC returns an error of type + KDC_ERR_CERTIFICATE_MISMATCH. It also returns this error if, on the + other hand, the client does not pass any trustedCertifiers, + believing that it has the KDC's certificate, but the KDC has more + than one certificate. + + The PKAuthenticator carries information to foil replay attacks, + to bind the request and response, and to optionally pass the + client's Diffie-Hellman public value (i.e. for using DSA in + combination with Diffie-Hellman). The PKAuthenticator is signed + with the private key corresponding to the public key in the + certificate found in userCert (or cached by the KDC). + + In the PKAuthenticator, the client may specify the KDC name in one + of two ways: + + * The Kerberos principal name krbtgt/@, + where is replaced by the applicable realm name. + * The name in the KDC's certificate (e.g., an X.500 name, or a + PGP name). + + Note that the first case requires that the certificate name and the + Kerberos principal name be bound together (e.g., via an X.509v3 + extension). + + The userCert field is a sequence of certificates, the first of which + must be the user's public key certificate. Any subsequent + certificates will be certificates of the certifiers of the user's + certificate. These cerificates may be used by the KDC to verify the + user's public key. This field may be left empty if the KDC already + has the user's certificate. + + The trustedCertifiers field contains a list of certification + authorities trusted by the client, in the case that the client does + not possess the KDC's public key certificate. If the KDC has no + certificate signed by any of the trustedCertifiers, then it returns + an error of type KDC_ERR_CERTIFICATE_MISMATCH. + + Upon receipt of the AS_REQ with PA-PK-AS-REQ pre-authentication + type, the KDC attempts to verify the user's certificate chain + (userCert), if one is provided in the request. This is done by + verifying the certification path against the KDC's policy of + legitimate certifiers. This may be based on a certification + hierarchy, or it may be simply a list of recognized certifiers in a + system like PGP. + + If verification of the user's certificate fails, the KDC sends back + an error message of type KDC_ERR_CLIENT_NOT_TRUSTED. The e-data + field contains additional information pertaining to this error, and + is formatted as follows: + + METHOD-DATA ::= SEQUENCE { + method-type [0] INTEGER, + -- 1 = cannot verify public key + -- 2 = invalid certificate + -- 3 = revoked certificate + -- 4 = invalid KDC name + -- 5 = client name mismatch + method-data [1] OCTET STRING OPTIONAL + } -- syntax as for KRB_AP_ERR_METHOD (RFC 1510) + + The values for the method-type and method-data fields are described + in Section 3.2.1. + + If trustedCertifiers is provided in the PA-PK-AS-REQ, the KDC + verifies that it has a certificate issued by one of the certifiers + trusted by the client. If it does not have a suitable certificate, + the KDC returns an error message of type KDC_ERR_KDC_NOT_TRUSTED to + the client. + + If a trust relationship exists, the KDC then verifies the client's + signature on AuthPack. If that fails, the KDC returns an error + message of type KDC_ERR_INVALID_SIG. Otherwise, the KDC uses the + timestamp in the PKAuthenticator to assure that the request is not a + replay. The KDC also verifies that its name is specified in the + PKAuthenticator. + + If the clientPublicValue field is filled in, indicating that the + client wishes to use Diffie-Hellman key agreement, then the KDC + checks to see that the parameters satisfy its policy. If they do + not (e.g., the prime size is insufficient for the expected + encryption type), then the KDC sends back an error message of type + KDC_ERR_KEY_TOO_WEAK. Otherwise, it generates its own public and + private values for the response. + + The KDC also checks that the timestamp in the PKAuthenticator is + within the allowable window. If the local (server) time and the + client time in the authenticator differ by more than the allowable + clock skew, then the KDC returns an error message of type + KRB_AP_ERR_SKEW. + + Assuming no errors, the KDC replies as per RFC 1510, except as + follows: The user's name in the ticket is as represented in the + certificate, unless a Kerberos principal name is bound to the name + in the certificate (e.g., via an X.509v3 extension). The user's + realm in the ticket shall be the name of the Certification + Authority that issued the user's public key certificate. + + The KDC encrypts the reply not with the user's long-term key, but + with a random key generated only for this particular response. This + random key is sealed in the preauthentication field: + + PA-PK-AS-REP ::= SEQUENCE { + -- PA TYPE 15 + encSignedReplyKeyPack [0] EncryptedData, + -- of type SignedReplyKeyPack + -- using the temporary key + -- in encTmpKey + encTmpKeyPack [1] EncryptedData, + -- of type TmpKeyPack + -- using either the client public + -- key or the Diffie-Hellman key + -- specified by SignedDHPublicValue + signedKDCPublicValue [2] SignedKDCPublicValue OPTIONAL + -- if one was passed in the request + kdcCert [3] SEQUENCE OF Certificate OPTIONAL, + -- the KDC's certificate chain + } + + SignedReplyKeyPack ::= SEQUENCE { + replyKeyPack [0] ReplyKeyPack, + replyKeyPackSig [1] Signature, + -- of replyEncKeyPack + -- using KDC's private key + } + + ReplyKeyPack ::= SEQUENCE { + replyKey [0] EncryptionKey, + -- used to encrypt main reply + -- of same ENCTYPE as session key + nonce [1] INTEGER + -- binds response to the request + -- must be same as the nonce + -- passed in the PKAuthenticator + } + + TmpKeyPack ::= SEQUENCE { + tmpKey [0] EncryptionKey, + -- used to encrypt the + -- SignedReplyKeyPack + -- of same ENCTYPE as session key + } + + SignedKDCPublicValue ::= SEQUENCE { + kdcPublicValue [0] SubjectPublicKeyInfo, + -- as described above + kdcPublicValueSig [1] Signature + -- of kdcPublicValue + -- using KDC's private key + } + + The kdcCert field is a sequence of certificates, the first of which + must be the KDC's public key certificate. Any subsequent + certificates will be certificates of the certifiers of the KDC's + certificate. The last of these must have as its certifier one of + the certifiers sent to the KDC in the PA-PK-AS-REQ. These + cerificates may be used by the client to verify the KDC's public + key. This field is empty if the client did not send to the KDC a + list of trusted certifiers (the trustedCertifiers field was empty). + + Since each certifier in the certification path of a user's + certificate is essentially a separate realm, the name of each + certifier shall be added to the transited field of the ticket. The + format of these realm names is defined in Section 3.1 of this + document. If applicable, the transit-policy-checked flag should be + set in the issued ticket. + + The KDC's certificate must bind the public key to a name derivable + from the name of the realm for that KDC. For an X.509 certificate, + this is done as follows. The name of the KDC will be represented + as an OtherName, encoded as a GeneralString: + + GeneralName ::= CHOICE { + otherName [0] KDCPrincipalName, + ... + } + + KDCPrincipalNameTypes OTHER-NAME ::= { + { PrincipalNameSrvInst IDENTIFIED BY principalNameSrvInst } + } + + KDCPrincipalName ::= SEQUENCE { + nameType [0] OTHER-NAME.&id ( { KDCPrincipalNameTypes } ), + name [1] OTHER-NAME.&type ( { KDCPrincipalNameTypes } + { @nameType } ) + } + + PrincipalNameSrvInst ::= GeneralString + + where (from the Kerberos specification) we have + + krb5 OBJECT IDENTIFIER ::= { iso (1) + org (3) + dod (6) + internet (1) + security (5) + kerberosv5 (2) } + + principalName OBJECT IDENTIFIER ::= { krb5 2 } + + principalNameSrvInst OBJECT IDENTIFIER ::= { principalName 2 } + + The client then extracts the random key used to encrypt the main + reply. This random key (in encPaReply) is encrypted with either the + client's public key or with a key derived from the DH values + exchanged between the client and the KDC. + + +3.2.1. Additional Information for Errors + + This section describes the interpretation of the method-type and + method-data fields of the KDC_ERR_CLIENT_NOT_TRUSTED error. + + If method-type=1, the client's public key certificate chain does not + contain a certificate that is signed by a certification authority + trusted by the KDC. The format of the method-data field will be an + ASN.1 encoding of a list of trusted certifiers, as defined above: + + TrustedCertifiers ::= SEQUENCE OF PrincipalName + + If method-type=2, the signature on one of the certificates in the + chain cannot be verified. The format of the method-data field will + be an ASN.1 encoding of the integer index of the certificate in + question: + + CertificateIndex ::= INTEGER + -- 0 = 1st certificate, + -- 1 = 2nd certificate, etc + + If method-type=3, one of the certificates in the chain has been + revoked. The format of the method-data field will be an ASN.1 + encoding of the integer index of the certificate in question: + + CertificateIndex ::= INTEGER + -- 0 = 1st certificate, + -- 1 = 2nd certificate, etc + + If method-type=4, the KDC name or realm in the PKAuthenticator does + not match the principal name of the KDC. There is no method-data + field in this case. + + If method-type=5, the client name or realm in the certificate does + not match the principal name of the client. There is no + method-data field in this case. + + +3.3. Digital Signature + + Implementation of the changes in this section are OPTIONAL for + compliance with PKINIT. + + We offer this option with the warning that it requires the client to + generate a random key; the client may not be able to guarantee the + same level of randomness as the KDC. + + If the user registered, or presents a certificate for, a digital + signature key with the KDC instead of an encryption key, then a + separate exchange must be used. The client sends a request for a + TGT as usual, except that it (rather than the KDC) generates the + random key that will be used to encrypt the KDC response. This key + is sent to the KDC along with the request in a preauthentication + field, encrypted with the KDC's public key: + + PA-PK-AS-SIGN ::= SEQUENCE { + -- PA TYPE 16 + encSignedRandomKeyPack [0] EncryptedData, + -- of type SignedRandomKeyPack + -- using the key in encTmpKeyPack + encTmpKeyPack [1] EncryptedData, + -- of type TmpKeyPack + -- using the KDC's public key + userCert [2] SEQUENCE OF Certificate OPTIONAL + -- the user's certificate chain + } + + SignedRandomKeyPack ::= SEQUENCE { + randomkeyPack [0] RandomKeyPack, + randomkeyPackSig [1] Signature + -- of keyPack + -- using user's private key + } + + RandomKeyPack ::= SEQUENCE { + randomKey [0] EncryptionKey, + -- will be used to encrypt reply + randomKeyAuth [1] PKAuthenticator + -- nonce copied from AS-REQ + } + + If the KDC does not accept client-generated random keys as a matter + of policy, then it sends back an error message of type + KDC_ERR_KEY_TOO_WEAK. Otherwise, it extracts the random key as + follows. + + Upon receipt of the PA-PK-AS-SIGN, the KDC decrypts then verifies + the randomKey. It then replies as per RFC 1510, except that the + reply is encrypted not with a password-derived user key, but with + the randomKey sent in the request. Since the client already knows + this key, there is no need to accompany the reply with an extra + preauthentication field. The transited field of the ticket should + specify the certification path as described in Section 3.2. + + +3.4. Retrieving the User's Private Key from the KDC + + Implementation of the changes described in this section are OPTIONAL + for compliance with PKINIT. + + When the user's private key is not stored local to the user, he may + choose to store the private key (normally encrypted using a + password-derived key) on the KDC. In this case, the client makes a + request as described above, except that instead of preauthenticating + with his private key, he uses a symmetric key shared with the KDC. + + For simplicity's sake, this shared key is derived from the password- + derived key used to encrypt the private key, in such a way that the + KDC can authenticate the user with the shared key without being able + to extract the private key. + + We provide this option to present the user with an alternative to + storing the private key on local disk at each machine where he + expects to authenticate himself using PKINIT. It should be noted + that it replaces the added risk of long-term storage of the private + key on possibly many workstations with the added risk of storing the + private key on the KDC in a form vulnerable to brute-force attack. + + Denote by K1 the symmetric key used to encrypt the private key. + Then construct symmetric key K2 as follows: + + * Perform a hash on K1. + * Truncate the digest to Length(K1) bytes. + * Rectify parity in each byte (if necessary) to obtain K2. + + The KDC stores K2, the public key, and the encrypted private key. + This key pair is designated as the "primary" key pair for that user. + This primary key pair is the one used to perform initial + authentication using the PA-PK-AS-REP preauthentication field. If + he desires, he may also store additional key pairs on the KDC; these + may be requested in addition to the primary. When the client + requests initial authentication using public key cryptography, it + must then include in its request, instead of a PA-PK-AS-REQ, the + following preauthentication sequence: + + PA-PK-KEY-REQ ::= SEQUENCE { + -- PA TYPE 17 + signedPKAuth [0] SignedPKAuth, + trustedCertifiers [1] SEQUENCE OF PrincipalName OPTIONAL, + -- CAs that the client trusts + keyIDList [2] SEQUENCE OF Checksum OPTIONAL + -- payload is hash of public key + -- corresponding to desired + -- private key + -- if absent, KDC will return all + -- stored private keys + } + + Checksum ::= SEQUENCE { + cksumtype [0] INTEGER, + checksum [1] OCTET STRING + } -- as specified by RFC 1510 + + SignedPKAuth ::= SEQUENCE { + pkAuth [0] PKAuthenticator, + pkAuthSig [1] Signature + -- of pkAuth + -- using the symmetric key K2 + } + + If a keyIDList is present, the first identifier should indicate + the primary private key. No public key certificate is required, + since the KDC stores the public key along with the private key. + If there is no keyIDList, all the user's private keys are returned. + + Upon receipt, the KDC verifies the signature using K2. If the + verification fails, the KDC sends back an error of type + KDC_ERR_INVALID_SIG. If the signature verifies, but the requested + keys are not found on the KDC, then the KDC sends back an error of + type KDC_ERR_PREAUTH_FAILED. If all checks out, the KDC responds as + described in Section 3.2, except that in addition, the KDC appends + the following preauthentication sequence: + + PA-PK-KEY-REP ::= SEQUENCE { + -- PA TYPE 18 + encKeyRep [0] EncryptedData + -- of type EncKeyReply + -- using the symmetric key K2 + } + + EncKeyReply ::= SEQUENCE { + keyPackList [0] SEQUENCE OF KeyPack, + -- the first KeyPair is + -- the primary key pair + nonce [1] INTEGER + -- binds reply to request + -- must be identical to the nonce + -- sent in the SignedAuthPack + } + + KeyPack ::= SEQUENCE { + keyID [0] Checksum, + encPrivKey [1] OCTET STRING + } + + Upon receipt of the reply, the client extracts the encrypted private + keys (and may store them, at the client's option). The primary + private key, which must be the first private key in the keyPack + SEQUENCE, is used to decrypt the random key in the PA-PK-AS-REP; + this key in turn is used to decrypt the main reply as described in + Section 3.2. + + +4. Logistics and Policy + + This section describes a way to define the policy on the use of + PKINIT for each principal and request. + + The KDC is not required to contain a database record for users + that use either the Standard Public Key Authentication or Public Key + Authentication with a Digital Signature. However, if these users + are registered with the KDC, it is recommended that the database + record for these users be modified to include three additional flags + in the attributes field. + + The first flag, use_standard_pk_init, indicates that the user should + authenticate using standard PKINIT as described in Section 3.2. The + second flag, use_digital_signature, indicates that the user should + authenticate using digital signature PKINIT as described in Section + 3.3. The third flag, store_private_key, indicates that the user + has stored his private key on the KDC and should retrieve it using + the exchange described in Section 3.4. + + If one of the preauthentication fields defined above is included in + the request, then the KDC shall respond as described in Sections 3.2 + through 3.4, ignoring the aforementioned database flags. If more + than one of the preauthentication fields is present, the KDC shall + respond with an error of type KDC_ERR_PREAUTH_FAILED. + + In the event that none of the preauthentication fields defined above + are included in the request, the KDC checks to see if any of the + above flags are set. If the first flag is set, then it sends back + an error of type KDC_ERR_PREAUTH_REQUIRED indicating that a + preauthentication field of type PA-PK-AS-REQ must be included in the + request. + + Otherwise, if the first flag is clear, but the second flag is set, + then the KDC sends back an error of type KDC_ERR_PREAUTH_REQUIRED + indicating that a preauthentication field of type PA-PK-AS-SIGN must + be included in the request. + + Lastly, if the first two flags are clear, but the third flag is set, + then the KDC sends back an error of type KDC_ERR_PREAUTH_REQUIRED + indicating that a preauthentication field of type PA-PK-KEY-REQ must + be included in the request. + + +5. Security Considerations + + PKINIT raises a few security considerations, which we will address + in this section. + + First of all, PKINIT introduces a new trust model, where KDCs do not + (necessarily) certify the identity of those for whom they issue + tickets. PKINIT does allow KDCs to act as their own CAs, in order + to simplify key management, but one of the additional benefits is to + align Kerberos authentication with a global public key + infrastructure. Anyone using PKINIT in this way must be aware of + how the certification infrastructure they are linking to works. + + Secondly, PKINIT also introduces the possibility of interactions + between different cryptosystems, which may be of widely varying + strengths. Many systems, for instance, allow the use of 512-bit + public keys. Using such keys to wrap data encrypted under strong + conventional cryptosystems, such as triple-DES, is inappropriate; + it adds a weak link to a strong one at extra cost. Implementors + and administrators should take care to avoid such wasteful and + deceptive interactions. + + +5. Transport Issues + + Certificate chains can potentially grow quite large and span several + UDP packets; this in turn increases the probability that a Kerberos + message involving PKINIT extensions will be broken in transit. In + light of the possibility that the Kerberos specification will + require KDCs to accept requests using TCP as a transport mechanism, + we make the same recommendation with respect to the PKINIT + extensions as well. + + +6. Bibliography + + [1] J. Kohl, C. Neuman. The Kerberos Network Authentication Service + (V5). Request for Comments 1510. + + [2] B.C. Neuman, Theodore Ts'o. Kerberos: An Authentication Service + for Computer Networks, IEEE Communications, 32(9):33-38. September + 1994. + + [3] A. Medvinsky, M. Hur. Addition of Kerberos Cipher Suites to + Transport Layer Security (TLS). + draft-ietf-tls-kerb-cipher-suites-00.txt + + [4] A. Medvinsky, M. Hur, B. Clifford Neuman. Public Key Utilizing + Tickets for Application Servers (PKTAPP). + draft-ietf-cat-pktapp-00.txt + + [5] M. Sirbu, J. Chuang. Distributed Authentication in Kerberos + Using Public Key Cryptography. Symposium On Network and Distributed + System Security, 1997. + + [6] B. Cox, J.D. Tygar, M. Sirbu. NetBill Security and Transaction + Protocol. In Proceedings of the USENIX Workshop on Electronic + Commerce, July 1995. + + [7] Alan O. Freier, Philip Karlton and Paul C. Kocher. The SSL + Protocol, Version 3.0 - IETF Draft. + + [8] B.C. Neuman, Proxy-Based Authorization and Accounting for + Distributed Systems. In Proceedings of the 13th International + Conference on Distributed Computing Systems, May 1993. + + [9] ITU-T (formerly CCITT) Information technology - Open Systems + Interconnection - The Directory: Authentication Framework + Recommendation X.509 ISO/IEC 9594-8 + + +7. Acknowledgements + + Sasha Medvinsky contributed several ideas to the protocol changes + and specifications in this document. His additions have been most + appreciated. + + Some of the ideas on which this proposal is based arose during + discussions over several years between members of the SAAG, the IETF + CAT working group, and the PSRG, regarding integration of Kerberos + and SPX. Some ideas have also been drawn from the DASS system. + These changes are by no means endorsed by these groups. This is an + attempt to revive some of the goals of those groups, and this + proposal approaches those goals primarily from the Kerberos + perspective. Lastly, comments from groups working on similar ideas + in DCE have been invaluable. + + +8. Expiration Date + + This draft expires September 15, 1998. + + +9. Authors + + Brian Tung + Clifford Neuman + USC Information Sciences Institute + 4676 Admiralty Way Suite 1001 + Marina del Rey CA 90292-6695 + Phone: +1 310 822 1511 + E-mail: {brian, bcn}@isi.edu + + John Wray + Digital Equipment Corporation + 550 King Street, LKG2-2/Z7 + Littleton, MA 01460 + Phone: +1 508 486 5210 + E-mail: wray@tuxedo.enet.dec.com + + Ari Medvinsky + Matthew Hur + CyberSafe Corporation + 1605 NW Sammamish Road Suite 310 + Issaquah WA 98027-5378 + Phone: +1 206 391 6000 + E-mail: {ari.medvinsky, matt.hur}@cybersafe.com + + Jonathan Trostle + Novell Corporation + Provo UT + E-mail: jtrostle@novell.com diff --git a/doc/standardisation/draft-ietf-cat-kerberos-pk-init-07.txt b/doc/standardisation/draft-ietf-cat-kerberos-pk-init-07.txt new file mode 100644 index 000000000..9609440b9 --- /dev/null +++ b/doc/standardisation/draft-ietf-cat-kerberos-pk-init-07.txt @@ -0,0 +1,1181 @@ +INTERNET-DRAFT Brian Tung +draft-ietf-cat-kerberos-pk-init-07.txt Clifford Neuman +Updates: RFC 1510 ISI +expires May 15, 1999 John Wray + Digital Equipment Corporation + Ari Medvinsky + Matthew Hur + Sasha Medvinsky + CyberSafe Corporation + Jonathan Trostle + Cisco + + + Public Key Cryptography for Initial Authentication in Kerberos + + +0. Status Of This Memo + + This document is an Internet-Draft. Internet-Drafts are working + documents of the Internet Engineering Task Force (IETF), its + areas, and its working groups. Note that other groups may also + distribute working documents as Internet-Drafts. + + Internet-Drafts are draft documents valid for a maximum of six + months and may be updated, replaced, or obsoleted by other + documents at any time. It is inappropriate to use Internet-Drafts + as reference material or to cite them other than as "work in + progress." + + To learn the current status of any Internet-Draft, please check + the "1id-abstracts.txt" listing contained in the Internet-Drafts + Shadow Directories on ftp.ietf.org (US East Coast), + nic.nordu.net (Europe), ftp.isi.edu (US West Coast), or + munnari.oz.au (Pacific Rim). + + The distribution of this memo is unlimited. It is filed as + draft-ietf-cat-kerberos-pk-init-07.txt, and expires May 15, 1999. + Please send comments to the authors. + + +1. Abstract + + This document defines extensions (PKINIT) to the Kerberos protocol + specification (RFC 1510 [1]) to provide a method for using public + key cryptography during initial authentication. The methods + defined specify the ways in which preauthentication data fields and + error data fields in Kerberos messages are to be used to transport + public key data. + + +2. Introduction + + The popularity of public key cryptography has produced a desire for + its support in Kerberos [2]. The advantages provided by public key + cryptography include simplified key management (from the Kerberos + perspective) and the ability to leverage existing and developing + public key certification infrastructures. + + Public key cryptography can be integrated into Kerberos in a number + of ways. One is to associate a key pair with each realm, which can + then be used to facilitate cross-realm authentication; this is the + topic of another draft proposal. Another way is to allow users with + public key certificates to use them in initial authentication. This + is the concern of the current document. + + One of the guiding principles in the design of PKINIT is that + changes should be as minimal as possible. As a result, the basic + mechanism of PKINIT is as follows: The user sends a request to the + KDC as before, except that if that user is to use public key + cryptography in the initial authentication step, his certificate + accompanies the initial request, in the preauthentication fields. + + Upon receipt of this request, the KDC verifies the certificate and + issues a ticket granting ticket (TGT) as before, except that + the encPart from the AS-REP message carrying the TGT is now + encrypted in a randomly-generated key, instead of the user's + long-term key (which is derived from a password). This + random key is in turn encrypted using the public key from the + certificate that came with the request and signed using the KDC's + private key, and accompanies the reply, in the preauthentication + fields. + + PKINIT also allows for users with only digital signature keys to + authenticate using those keys, and for users to store and retrieve + private keys on the KDC. + + The PKINIT specification may also be used as a building block for + other specifications. PKCROSS [3] utilizes PKINIT for establishing + the inter-realm key and associated inter-realm policy to be applied + in issuing cross realm service tickets. As specified in [4], anonymous + Kerberos tickets can be issued by applying a NULL signature in + combination with Diffie-Hellman in the PKINIT exchange. Additionally, + The PKINIT specification may be used for direct peer to peer + authentication without contacting a central KDC. This application + of PKINIT is described in PKTAPP [5] and is based on concepts + introduced in [6, 7]. For direct client-to-server authentication, + the client uses PKINIT to authenticate to the end server (instead + of a central KDC), which then issues a ticket for itself. This + approach has an advantage over SSL [8] in that the server does not + need to save state (cache session keys). Furthermore, an + additional benefit is that Kerberos tickets can facilitate + delegation (see [9]). + + +3. Proposed Extensions + + This section describes extensions to RFC 1510 for supporting the + use of public key cryptography in the initial request for a ticket + granting ticket (TGT). + + In summary, the following changes to RFC 1510 are proposed: + + * Users may authenticate using either a public key pair or a + conventional (symmetric) key. If public key cryptography is + used, public key data is transported in preauthentication + data fields to help establish identity. + * Users may store private keys on the KDC for retrieval during + Kerberos initial authentication. + + This proposal addresses two ways that users may use public key + cryptography for initial authentication. Users may present public + key certificates, or they may generate their own session key, + signed by their digital signature key. In either case, the end + result is that the user obtains an ordinary TGT that may be used for + subsequent authentication, with such authentication using only + conventional cryptography. + + Section 3.1 provides definitions to help specify message formats. + Section 3.2 and 3.3 describe the extensions for the two initial + authentication methods. Section 3.4 describes a way for the user to + store and retrieve his private key on the KDC, as an adjunct to the + initial authentication. + + +3.1. Definitions + + The extensions involve new preauthentication fields; we propose the + addition of the following types: + + PA-PK-AS-REQ 14 + PA-PK-AS-REP 15 + PA-PK-AS-SIGN 16 + PA-PK-KEY-REQ 17 + PA-PK-KEY-REP 18 + + The extensions also involve new error types; we propose the addition + of the following types: + + KDC_ERR_CLIENT_NOT_TRUSTED 62 + KDC_ERR_KDC_NOT_TRUSTED 63 + KDC_ERR_INVALID_SIG 64 + KDC_ERR_KEY_TOO_WEAK 65 + KDC_ERR_CERTIFICATE_MISMATCH 66 + + In many cases, PKINIT requires the encoding of an X.500 name as a + Realm. In these cases, the realm will be represented using a + different style, specified in RFC 1510 with the following example: + + NAMETYPE:rest/of.name=without-restrictions + + For a realm derived from an X.500 name, NAMETYPE will have the value + X500-RFC2253. The full realm name will appear as follows: + + X500-RFC2253:RFC2253Encode(DistinguishedName) + + where DistinguishedName is an X.500 name, and RFC2253Encode is a + readable ASCII encoding of an X.500 name, as defined by + RFC 2253 [14] (part of LDAPv3). (RFC 2253 obsoleted RFC 1779, which + is not supported by this version of PKINIT.) + + To ensure that this encoding is unique, we add the following rule + to those specified by RFC 2253: + + The order in which the attributes appear in the RFC 2253 + encoding must be the reverse of the order in the ASN.1 + encoding of the X.500 name that appears in the public key + certificate. The order of the relative distinguished names + (RDNs), as well as the order of the AttributeTypeAndValues + within each RDN, will be reversed. (This is despite the fact + that an RDN is defined as a SET of AttributeTypeAndValues, where + an order is normally not important.) + + Similarly, PKINIT may require the encoding of an X.500 name as a + PrincipalName. In these cases, the name-type of the principal name + shall be set to NT-X500-PRINCIPAL. This new name type is defined + as: + + #define CSFC5c_NT_X500_PRINCIPAL 6 + + The name-string shall be set as follows: + + RFC2253Encode(DistinguishedName) + + as described above. + + +3.1.1. Encryption and Key Formats + + In the exposition below, we use the terms public key and private + key generically. It should be understood that the term "public + key" may be used to refer to either a public encryption key or a + signature verification key, and that the term "private key" may be + used to refer to either a private decryption key or a signature + generation key. The fact that these are logically distinct does + not preclude the assignment of bitwise identical keys. + + All additional symmetric keys specified in this draft shall use the + same encryption type as the session key in the response from the + KDC. These include the temporary keys used to encrypt the signed + random key encrypting the response, as well as the key derived from + Diffie-Hellman agreement. In the case of Diffie-Hellman, the key + shall be produced from the agreed bit string as follows: + + * Truncate the bit string to the appropriate length. + * Rectify parity in each byte (if necessary) to obtain the key. + + For instance, in the case of a DES key, we take the first eight + bytes of the bit stream, and then adjust the least significant bit + of each byte to ensure that each byte has odd parity. + + +3.1.2. Algorithm Identifiers + + PKINIT does not define, but does permit, the algorithm identifiers + listed below. + +3.1.2.1. Signature Algorithm Identifiers + + These are the algorithm identifiers for use in the Signature data + structure: + + sha-1WithRSAEncryption ALGORITHM PARAMETER NULL + ::= { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) + pkcs-1(1) 5 } + + dsaWithSHA1 ALGORITHM PARAMETER NULL + ::= { iso(1) identifiedOrganization(3) oIW(14) oIWSecSig(3) + oIWSecAlgorithm(2) dsaWithSHA1(27) } + + md4WithRsaEncryption ALGORITHM PARAMETER NULL + ::= { iso(1) identifiedOrganization(3) oIW(14) oIWSecSig(3) + oIWSecAlgorithm(2) md4WithRSAEncryption(4) } + + md5WithRSAEncryption ALGORITHM PARAMETER NULL + ::= { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) + pkcs-1(1) md5WithRSAEncryption(4) } + + +3.1.2.2 Diffie-Hellman Key Agreement Algorithm Identifier + + This algorithm identifier is used inside the SubjectPublicKeyInfo + data structure: + + dhKeyAgreement ALGORITHM PARAMETER DHParameters + ::= { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) + pkcs-3(3) dhKeyAgreement(1) } + + DHParameters ::= SEQUENCE { + prime INTEGER, + -- p + base INTEGER, + -- g + privateValueLength INTEGER OPTIONAL + } -- as specified by the X.509 recommendation [9] + + +3.1.2.3. Algorithm Identifiers for RSA Encryption + + These algorithm identifiers are used inside the EnvelopedData data + structure, for encrypting the temporary key with a public key: + + rsaEncryption ALGORITHM PARAMETER NULL + ::= { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) + pkcs-1(1) rsaEncryption(1) + + +3.1.2.4. Algorithm Identifiers for Encryption with Secret Keys + + These algorithm identifiers are used inside the EnvelopedData data + structure, for encrypting the temporary key with a Diffie-Hellman- + derived key, or for encrypting the reply key: + + desCBC ALGORITHM PARAMETER IV8 + ::= { iso(1) identifiedOrganization(3) oIW(14) oIWSecSig(3) + oIWSecAlgorithm(2) desCBC(7) } + + DES-EDE3-CBC ALGORITHM PARAMETER IV8 + ::= { iso(1) member-body(2) US(840) rsadsi(113549) + encryptionAlgorithm(3) desEDE3(7) } + + IV8 ::= OCTET STRING (SIZE(8)) -- initialization vector + + rc2CBC ALGORITHM PARAMETER RC2-CBCParameter + ::= { iso(1) member-body(2) US(840) rsadsi(113549) + encryptionAlgorithm(3) rc2CBC(2) } + + The rc2CBC algorithm parameters (RC2-CBCParameter) are defined + in the following section. + + rc4 ALGORITHM PARAMETER NULL + ::= { iso(1) member-body(2) US(840) rsadsi(113549) + encryptionAlgorithm(3) rc4(4) } + + The rc4 algorithm cannot be used with the Diffie-Hellman-derived + keys, because its parameters do not specify the size of the key. + + +3.1.2.5. rc2CBC Algorithm Parameters + + This definition of the RC2 parameters is taken from a paper by + Ron Rivest [13]. Refer to [13] for the complete description of the + RC2 algorithm. + + RC2-CBCParameter ::= CHOICE { + iv IV, + params SEQUENCE { + version RC2Version, + iv IV + } + } + + where + + IV ::= OCTET STRING -- 8 octets + RC2Version ::= INTEGER -- 1-1024 + + RC2 in CBC mode has two parameters: an 8-byte initialization + vector (IV) and a version number in the range 1-1024 which + specifies in a roundabout manner the number of effective key bits + to be used for the RC2 encryption/decryption. + + The correspondence between effective key bits and version number + is as follows: + + 1. If the number EKB of effective key bits is in the range 1-255, + then the version number is given by Table[EKB], where the + 256-byte translation table is specified below. It specifies a + permutation on the numbers 0-255. + + 2. If the number EKB of effective key bits is in the range + 256-1024, then the version number is simply EKB. + + The default number of effective key bits for RC2 is 32. + If RC2-CBC is being performed with 32 effective key bits, the + parameters should be supplied as a simple IV, rather than as a + SEQUENCE containing a version and an IV. + + 0 1 2 3 4 5 6 7 8 9 a b c d e f + + 00: bd 56 ea f2 a2 f1 ac 2a b0 93 d1 9c 1b 33 fd d0 + 10: 30 04 b6 dc 7d df 32 4b f7 cb 45 9b 31 bb 21 5a + 20: 41 9f e1 d9 4a 4d 9e da a0 68 2c c3 27 5f 80 36 + 30: 3e ee fb 95 1a fe ce a8 34 a9 13 f0 a6 3f d8 0c + 40: 78 24 af 23 52 c1 67 17 f5 66 90 e7 e8 07 b8 60 + 50: 48 e6 1e 53 f3 92 a4 72 8c 08 15 6e 86 00 84 fa + 60: f4 7f 8a 42 19 f6 db cd 14 8d 50 12 ba 3c 06 4e + 70: ec b3 35 11 a1 88 8e 2b 94 99 b7 71 74 d3 e4 bf + 80: 3a de 96 0e bc 0a ed 77 fc 37 6b 03 79 89 62 c6 + 90: d7 c0 d2 7c 6a 8b 22 a3 5b 05 5d 02 75 d5 61 e3 + a0: 18 8f 55 51 ad 1f 0b 5e 85 e5 c2 57 63 ca 3d 6c + b0: b4 c5 cc 70 b2 91 59 0d 47 20 c8 4f 58 e0 01 e2 + c0: 16 38 c4 6f 3b 0f 65 46 be 7e 2d 7b 82 f9 40 b5 + d0: 1d 73 f8 eb 26 c7 87 97 25 54 b1 28 aa 98 9d a5 + e0: 64 6d 7a d4 10 81 44 ef 49 d6 ae 2e dd 76 5c 2f + f0: a7 1c c9 09 69 9a 83 cf 29 39 b9 e9 4c ff 43 ab + + +3.2. Standard Public Key Authentication + + Implementation of the changes in this section is REQUIRED for + compliance with PKINIT. + + It is assumed that all public keys are signed by some certification + authority (CA). The initial authentication request is sent as per + RFC 1510, except that a preauthentication field containing data + signed by the user's private key accompanies the request: + + PA-PK-AS-REQ ::= SEQUENCE { + -- PA TYPE 14 + signedAuthPack [0] SignedAuthPack + userCert [1] SEQUENCE OF Certificate OPTIONAL, + -- the user's certificate chain; + -- if present, the KDC must use + -- the public key from this + -- particular certificate chain to + -- verify the signature in the + -- request + trustedCertifiers [2] SEQUENCE OF PrincipalName OPTIONAL, + -- CAs that the client trusts + serialNumber [3] CertificateSerialNumber OPTIONAL + -- specifying a particular KDC + -- certificate if the client + -- already has it; + -- must be accompanied by + -- a single trustedCertifier + } + + CertificateSerialNumber ::= INTEGER + -- as specified by PKCS #6 [15] + + SignedAuthPack ::= SEQUENCE { + authPack [0] AuthPack, + authPackSig [1] Signature, + -- of authPack + -- using user's private key + } + + AuthPack ::= SEQUENCE { + pkAuthenticator [0] PKAuthenticator, + clientPublicValue [1] SubjectPublicKeyInfo OPTIONAL + -- if client is using Diffie-Hellman + } + + PKAuthenticator ::= SEQUENCE { + kdcName [0] PrincipalName, + kdcRealm [1] Realm, + cusec [2] INTEGER, + -- for replay prevention + ctime [3] KerberosTime, + -- for replay prevention + nonce [4] INTEGER + } + + Signature ::= SEQUENCE { + signatureAlgorithm [0] SignatureAlgorithmIdentifier, + pkcsSignature [1] BIT STRING + -- octet-aligned big-endian bit + -- string (encrypted with signer's + -- private key) + } + + SignatureAlgorithmIdentifier ::= AlgorithmIdentifier + + AlgorithmIdentifier ::= SEQUENCE { + algorithm ALGORITHM.&id, + parameters ALGORITHM.&type + } -- as specified by the X.509 recommendation [10] + + SubjectPublicKeyInfo ::= SEQUENCE { + algorithm AlgorithmIdentifier, + -- dhKeyAgreement + subjectPublicKey BIT STRING + -- for DH, equals + -- public exponent (INTEGER encoded + -- as payload of BIT STRING) + } -- as specified by the X.509 recommendation [9] + + Certificate ::= SEQUENCE { + certType [0] INTEGER, + -- type of certificate + -- 1 = X.509v3 (DER encoding) + -- 2 = PGP (per PGP specification) + -- 3 = PKIX (per PKCS #6 [15]) + certData [1] OCTET STRING + -- actual certificate + -- type determined by certType + } + + If the client passes a certificate serial number in the request, + the KDC is requested to use the referred-to certificate. If none + exists, then the KDC returns an error of type + KDC_ERR_CERTIFICATE_MISMATCH. It also returns this error if, on the + other hand, the client does not pass any trustedCertifiers, + believing that it has the KDC's certificate, but the KDC has more + than one certificate. + + The PKAuthenticator carries information to foil replay attacks, + to bind the request and response, and to optionally pass the + client's Diffie-Hellman public value (i.e. for using DSA in + combination with Diffie-Hellman). The PKAuthenticator is signed + with the private key corresponding to the public key in the + certificate found in userCert (or cached by the KDC). + + The userCert field is a sequence of certificates, the first of which + must be the user's public key certificate. Any subsequent + certificates will be certificates of the certifiers of the user's + certificate. These cerificates may be used by the KDC to verify the + user's public key. This field may be left empty if the KDC already + has the user's certificate. + + The trustedCertifiers field contains a list of certification + authorities trusted by the client, in the case that the client does + not possess the KDC's public key certificate. If the KDC has no + certificate signed by any of the trustedCertifiers, then it returns + an error of type KDC_ERR_CERTIFICATE_MISMATCH. + + Upon receipt of the AS_REQ with PA-PK-AS-REQ pre-authentication + type, the KDC attempts to verify the user's certificate chain + (userCert), if one is provided in the request. This is done by + verifying the certification path against the KDC's policy of + legitimate certifiers. This may be based on a certification + hierarchy, or it may be simply a list of recognized certifiers in a + system like PGP. + + If verification of the user's certificate fails, the KDC sends back + an error message of type KDC_ERR_CLIENT_NOT_TRUSTED. The e-data + field contains additional information pertaining to this error, and + is formatted as follows: + + METHOD-DATA ::= SEQUENCE { + method-type [0] INTEGER, + -- 1 = cannot verify public key + -- 2 = invalid certificate + -- 3 = revoked certificate + -- 4 = invalid KDC name + -- 5 = client name mismatch + method-data [1] OCTET STRING OPTIONAL + } -- syntax as for KRB_AP_ERR_METHOD (RFC 1510) + + The values for the method-type and method-data fields are described + in Section 3.2.1. + + If trustedCertifiers is provided in the PA-PK-AS-REQ, the KDC + verifies that it has a certificate issued by one of the certifiers + trusted by the client. If it does not have a suitable certificate, + the KDC returns an error message of type KDC_ERR_KDC_NOT_TRUSTED to + the client. + + If a trust relationship exists, the KDC then verifies the client's + signature on AuthPack. If that fails, the KDC returns an error + message of type KDC_ERR_INVALID_SIG. Otherwise, the KDC uses the + timestamp in the PKAuthenticator to assure that the request is not a + replay. The KDC also verifies that its name is specified in the + PKAuthenticator. + + If the clientPublicValue field is filled in, indicating that the + client wishes to use Diffie-Hellman key agreement, then the KDC + checks to see that the parameters satisfy its policy. If they do + not (e.g., the prime size is insufficient for the expected + encryption type), then the KDC sends back an error message of type + KDC_ERR_KEY_TOO_WEAK. Otherwise, it generates its own public and + private values for the response. + + The KDC also checks that the timestamp in the PKAuthenticator is + within the allowable window. If the local (server) time and the + client time in the authenticator differ by more than the allowable + clock skew, then the KDC returns an error message of type + KRB_AP_ERR_SKEW. + + Assuming no errors, the KDC replies as per RFC 1510, except as + follows. The user's name in the ticket is determined by the + following decision algorithm: + + 1. If the KDC has a mapping from the name in the certificate + to a Kerberos name, then use that name. Else + 2. If the certificate contains a Kerberos name in an extension + field, and local KDC policy allows, then use that name. + Else + 3. Use the name as represented in the certificate, mapping + as necessary (e.g., as per RFC 2253 for X.500 names). In + this case the realm in the ticket shall be the name of the + certification authority that issued the user's certificate. + + The KDC encrypts the reply not with the user's long-term key, but + with a random key generated only for this particular response. This + random key is sealed in the preauthentication field: + + PA-PK-AS-REP ::= SEQUENCE { + -- PA TYPE 15 + encKeyPack [1] EnvelopedKeyPack, + -- temporary key is encrypted + -- using either the client public + -- key or the Diffie-Hellman key + -- specified by SignedKDCPublicValue. + -- SignedReplyKeyPack, encrypted + -- with the temporary key, is also + -- included. + signedKDCPublicValue [2] SignedKDCPublicValue OPTIONAL, + -- if one was passed in the request + kdcCert [3] SEQUENCE OF Certificate OPTIONAL + -- the KDC's certificate chain + } + + + The EnvelopedKeyPack data type below contains an encrypted + temporary key (either with the PKINIT client's public key or with a + symmetric key, resulting from the Diffie-Hellman exchange). It also + contains a signed and encrypted reply key. This data structure is + similar to EnvelopedData, defined in CMS [11] and PKCS #7 [12]. + + EnvelopedKeyPack ::= SEQUENCE { + version Version, + -- Always set to 0. + recipientInfos RecipientInfos, + -- This is a SET, which must contain + -- exactly one member. Contains a + -- temporary key, encrypted with the + -- client's public key. This + -- temporary key is used to encrypt + -- the reply key. + encryptedContentInfo EncryptedContentInfo + -- contains the signed and encrypted + -- reply key + } + + Version ::= INTEGER + + RecipientInfos ::= SET OF RecipientInfo + + RecipientInfo ::= SEQUENCE { + version Version, + -- shall be 0 + rid RecipientIdentifier, + -- Since this is an optional field, + -- it supports both CMS and PKCS #7 + keyEncryptionAlgorithm KeyEncryptionAlgorithmIdentifier, + EncryptedKey OCTET STRING + -- the temporary key, encrypted with + -- the PKINIT client's public key + } + + KeyEncryptionAlgorithmIdentifier ::= AlgorithmIdentifier + + RecipientIdentifier ::= IssuerAndSerialNumber + -- Corresponds to the X.509 V3 extension + -- SubjectKeyIdentifier. + + IssuerAndSerialNumber ::= SEQUENCE { + issuer Name, + -- a distinguished name, as defined + -- by X.509 + serialNumber CertificateSerialNumber + } + + CertificateSerialNumber ::= INTEGER + + EncryptedContentInfo ::= SEQUENCE { + contentType ContentType, + -- shall be: + -- iso(1) member-body(2) us(840) + -- rsadsi(113549) pkcs(1) pkcs7(7) + -- EnvelopedData(3) + contentEncryptionAlgorithm ContentEncryptionAlgorithmIdentifier + -- Algorithm used to encrypt the + -- SignedReplyKeyPack. + encryptedContent OCTET STRING + -- The encrypted data is of the type + -- SignedReplyKeyPack. + } + + ContentType ::= OBJECT IDENTIFIER + + ContentEncryptionAlgorithmIdentifier ::= AlgorithmIdentifier + + SignedReplyKeyPack ::= SEQUENCE { + replyKeyPack [0] ReplyKeyPack, + replyKeyPackSig [1] Signature, + -- of replyKeyPack + -- using KDC's private key + } + + ReplyKeyPack ::= SEQUENCE { + replyKey [0] EncryptionKey, + -- used to encrypt main reply + -- of same ENCTYPE as session key + nonce [1] INTEGER + -- binds response to the request + -- must be same as the nonce + -- passed in the PKAuthenticator + } + + SignedKDCPublicValue ::= SEQUENCE { + kdcPublicValue [0] SubjectPublicKeyInfo, + -- as described above + kdcPublicValueSig [1] Signature + -- of kdcPublicValue + -- using KDC's private key + } + + + The kdcCert field is a sequence of certificates, the first of which + must be the KDC's public key certificate. Any subsequent + certificates will be certificates of the certifiers of the KDC's + certificate. The last of these must have as its certifier one of + the certifiers sent to the KDC in the PA-PK-AS-REQ. These + cerificates may be used by the client to verify the KDC's public + key. This field is empty if the client did not send to the KDC a + list of trusted certifiers (the trustedCertifiers field was empty). + + Since each certifier in the certification path of a user's + certificate is essentially a separate realm, the name of each + certifier shall be added to the transited field of the ticket. The + format of these realm names is defined in Section 3.1 of this + document. If applicable, the transit-policy-checked flag should be + set in the issued ticket. + + The KDC's certificate must bind the public key to a name derivable + from the name of the realm for that KDC. X.509 certificates shall + contain the principal name of the KDC as the SubjectAltName version + 3 extension. Below is the definition of this version 3 extension, as + specified by the X.509 standard: + + subjectAltName EXTENSION ::= { + SYNTAX GeneralNames + IDENTIFIED BY id-ce-subjectAltName + } + + GeneralNames ::= SEQUENCE SIZE(1..MAX) OF GeneralName + + GeneralName ::= CHOICE { + otherName [0] INSTANCE OF OTHER-NAME, + ... + } + + OTHER-NAME ::= TYPE-IDENTIFIER + + In this definition, otherName is a name of any form defined as an + instance of the OTHER-NAME information object class. For the purpose + of specifying a Kerberos principal name, INSTANCE OF OTHER-NAME will + be replaced by the type KerberosPrincipalName: + + KerberosPrincipalName ::= SEQUENCE { + nameType [0] OTHER-NAME.&id ( { PrincipalNameTypes } ), + name [1] OTHER-NAME.&type ( { PrincipalNameTypes } + { @nameType } ) + } + + PrincipalNameTypes OTHER-NAME ::= { + { PrincipalNameSrvInst IDENTIFIED BY principalNameSrvInst } + } + + PrincipalNameSrvInst ::= GeneralString + + where (from the Kerberos specification) we have + + krb5 OBJECT IDENTIFIER ::= { iso (1) + org (3) + dod (6) + internet (1) + security (5) + kerberosv5 (2) } + + principalName OBJECT IDENTIFIER ::= { krb5 2 } + + principalNameSrvInst OBJECT IDENTIFIER ::= { principalName 2 } + + (This specification can also be used to specify a Kerberos name + within the user's certificate.) + + The client then extracts the random key used to encrypt the main + reply. This random key (in encPaReply) is encrypted with either the + client's public key or with a key derived from the DH values + exchanged between the client and the KDC. + + +3.2.1. Additional Information for Errors + + This section describes the interpretation of the method-type and + method-data fields of the KDC_ERR_CLIENT_NOT_TRUSTED error. + + If method-type=1, the client's public key certificate chain does not + contain a certificate that is signed by a certification authority + trusted by the KDC. The format of the method-data field will be an + ASN.1 encoding of a list of trusted certifiers, as defined above: + + TrustedCertifiers ::= SEQUENCE OF PrincipalName + + If method-type=2, the signature on one of the certificates in the + chain cannot be verified. The format of the method-data field will + be an ASN.1 encoding of the integer index of the certificate in + question: + + CertificateIndex ::= INTEGER + -- 0 = 1st certificate, + -- 1 = 2nd certificate, etc + + If method-type=3, one of the certificates in the chain has been + revoked. The format of the method-data field will be an ASN.1 + encoding of the integer index of the certificate in question: + + CertificateIndex ::= INTEGER + -- 0 = 1st certificate, + -- 1 = 2nd certificate, etc + + If method-type=4, the KDC name or realm in the PKAuthenticator does + not match the principal name of the KDC. There is no method-data + field in this case. + + If method-type=5, the client name or realm in the certificate does + not match the principal name of the client. There is no + method-data field in this case. + + +3.2.2. Required Algorithms and Data Formats + + Not all of the algorithms in the PKINIT protocol specification have + to be implemented in order to comply with the proposed standard. + Below is a list of the required algorithms and data formats: + + - Diffie-Hellman public/private key pairs + - SHA1 digest and DSA for signatures + - X.509 version 3 certificates + - 3-key triple DES keys derived from the Diffie-Hellman Exchange + - 3-key triple DES Temporary and Reply keys + + +3.3. Digital Signature + + Implementation of the changes in this section are OPTIONAL for + compliance with PKINIT. + + We offer this option with the warning that it requires the client to + generate a random key; the client may not be able to guarantee the + same level of randomness as the KDC. + + If the user registered, or presents a certificate for, a digital + signature key with the KDC instead of an encryption key, then a + separate exchange must be used. The client sends a request for a + TGT as usual, except that it (rather than the KDC) generates the + random key that will be used to encrypt the KDC response. This key + is sent to the KDC along with the request in a preauthentication + field, encrypted with the KDC's public key: + + PA-PK-AS-SIGN ::= SEQUENCE { + -- PA TYPE 16 + encKeyPack [1] EnvelopedKeyPack, + -- temporary key is encrypted + -- using the KDC public + -- key. + -- SignedRandomKeyPack, encrypted + -- with the temporary key, is also + -- included. + userCert [2] SEQUENCE OF Certificate OPTIONAL + -- the user's certificate chain; + -- if present, the KDC must use + -- the public key from this + -- particular certificate chain to + -- verify the signature in the + -- request + } + + In the above message, the content of the encKeyPack is similar to + the content of the encKeyPack field in the PA-PK-AS-REP message, + except that it is the KDC's public key and not the client's public + key that is used to encrypt the temporary key. And, the + encryptedContentInfo field inside the EnvelopedKeyPack contains + encrypted data of the type SignedRandomKeyPack instead of the + SignedReplyKeyPack. + + SignedRandomKeyPack ::= SEQUENCE { + randomkeyPack [0] RandomKeyPack, + randomkeyPackSig [1] Signature + -- of keyPack + -- using user's private key + } + + RandomKeyPack ::= SEQUENCE { + randomKey [0] EncryptionKey, + -- will be used to encrypt reply + randomKeyAuth [1] PKAuthenticator + } + + If the KDC does not accept client-generated random keys as a matter + of policy, then it sends back an error message of type + KDC_ERR_KEY_TOO_WEAK. Otherwise, it extracts the random key as + follows. + + Upon receipt of the PA-PK-AS-SIGN, the KDC decrypts then verifies + the randomKey. It then replies as per RFC 1510, except that the + reply is encrypted not with a password-derived user key, but with + the randomKey sent in the request. Since the client already knows + this key, there is no need to accompany the reply with an extra + preauthentication field. The transited field of the ticket should + specify the certification path as described in Section 3.2. + + +3.4. Retrieving the User's Private Key from the KDC + + Implementation of the changes described in this section are OPTIONAL + for compliance with PKINIT. (This section may or may not fall under + the purview of a patent for private key storage; please see Section + 8 for more information.) + + When the user's private key is not stored local to the user, he may + choose to store the private key (normally encrypted using a + password-derived key) on the KDC. In this case, the client makes a + request as described above, except that instead of preauthenticating + with his private key, he uses a symmetric key shared with the KDC. + + For simplicity's sake, this shared key is derived from the password- + derived key used to encrypt the private key, in such a way that the + KDC can authenticate the user with the shared key without being able + to extract the private key. + + We provide this option to present the user with an alternative to + storing the private key on local disk at each machine where he + expects to authenticate himself using PKINIT. It should be noted + that it replaces the added risk of long-term storage of the private + key on possibly many workstations with the added risk of storing the + private key on the KDC in a form vulnerable to brute-force attack. + + Denote by K1 the symmetric key used to encrypt the private key. + Then construct symmetric key K2 as follows: + + * Perform a hash on K1. + * Truncate the digest to Length(K1) bytes. + * Rectify parity in each byte (if necessary) to obtain K2. + + The KDC stores K2, the public key, and the encrypted private key. + This key pair is designated as the "primary" key pair for that user. + This primary key pair is the one used to perform initial + authentication using the PA-PK-AS-REP preauthentication field. If + he desires, he may also store additional key pairs on the KDC; these + may be requested in addition to the primary. When the client + requests initial authentication using public key cryptography, it + must then include in its request, instead of a PA-PK-AS-REQ, the + following preauthentication sequence: + + PA-PK-KEY-REQ ::= SEQUENCE { + -- PA TYPE 17 + signedPKAuth [0] SignedPKAuth, + trustedCertifiers [1] SEQUENCE OF PrincipalName OPTIONAL, + -- CAs that the client trusts + keyIDList [2] SEQUENCE OF Checksum OPTIONAL + -- payload is hash of public key + -- corresponding to desired + -- private key + -- if absent, KDC will return all + -- stored private keys + } + + Checksum ::= SEQUENCE { + cksumtype [0] INTEGER, + checksum [1] OCTET STRING + } -- as specified by RFC 1510 + + SignedPKAuth ::= SEQUENCE { + pkAuth [0] PKAuthenticator, + pkAuthSig [1] Signature + -- of pkAuth + -- using the symmetric key K2 + } + + If a keyIDList is present, the first identifier should indicate + the primary private key. No public key certificate is required, + since the KDC stores the public key along with the private key. + If there is no keyIDList, all the user's private keys are returned. + + Upon receipt, the KDC verifies the signature using K2. If the + verification fails, the KDC sends back an error of type + KDC_ERR_INVALID_SIG. If the signature verifies, but the requested + keys are not found on the KDC, then the KDC sends back an error of + type KDC_ERR_PREAUTH_FAILED. If all checks out, the KDC responds as + described in Section 3.2, except that in addition, the KDC appends + the following preauthentication sequence: + + PA-PK-KEY-REP ::= SEQUENCE { + -- PA TYPE 18 + encKeyRep [0] EncryptedData + -- of type EncKeyReply + -- using the symmetric key K2 + } + + EncKeyReply ::= SEQUENCE { + keyPackList [0] SEQUENCE OF KeyPack, + -- the first KeyPair is + -- the primary key pair + nonce [1] INTEGER + -- binds reply to request + -- must be identical to the nonce + -- sent in the SignedAuthPack + } + + KeyPack ::= SEQUENCE { + keyID [0] Checksum, + encPrivKey [1] OCTET STRING + } + + Upon receipt of the reply, the client extracts the encrypted private + keys (and may store them, at the client's option). The primary + private key, which must be the first private key in the keyPack + SEQUENCE, is used to decrypt the random key in the PA-PK-AS-REP; + this key in turn is used to decrypt the main reply as described in + Section 3.2. + + +4. Logistics and Policy + + This section describes a way to define the policy on the use of + PKINIT for each principal and request. + + The KDC is not required to contain a database record for users + that use either the Standard Public Key Authentication or Public Key + Authentication with a Digital Signature. However, if these users + are registered with the KDC, it is recommended that the database + record for these users be modified to include three additional flags + in the attributes field. + + The first flag, use_standard_pk_init, indicates that the user should + authenticate using standard PKINIT as described in Section 3.2. The + second flag, use_digital_signature, indicates that the user should + authenticate using digital signature PKINIT as described in Section + 3.3. The third flag, store_private_key, indicates that the user + has stored his private key on the KDC and should retrieve it using + the exchange described in Section 3.4. + + If one of the preauthentication fields defined above is included in + the request, then the KDC shall respond as described in Sections 3.2 + through 3.4, ignoring the aforementioned database flags. If more + than one of the preauthentication fields is present, the KDC shall + respond with an error of type KDC_ERR_PREAUTH_FAILED. + + In the event that none of the preauthentication fields defined above + are included in the request, the KDC checks to see if any of the + above flags are set. If the first flag is set, then it sends back + an error of type KDC_ERR_PREAUTH_REQUIRED indicating that a + preauthentication field of type PA-PK-AS-REQ must be included in the + request. + + Otherwise, if the first flag is clear, but the second flag is set, + then the KDC sends back an error of type KDC_ERR_PREAUTH_REQUIRED + indicating that a preauthentication field of type PA-PK-AS-SIGN must + be included in the request. + + Lastly, if the first two flags are clear, but the third flag is set, + then the KDC sends back an error of type KDC_ERR_PREAUTH_REQUIRED + indicating that a preauthentication field of type PA-PK-KEY-REQ must + be included in the request. + + +5. Security Considerations + + PKINIT raises a few security considerations, which we will address + in this section. + + First of all, PKINIT introduces a new trust model, where KDCs do not + (necessarily) certify the identity of those for whom they issue + tickets. PKINIT does allow KDCs to act as their own CAs, in order + to simplify key management, but one of the additional benefits is to + align Kerberos authentication with a global public key + infrastructure. Anyone using PKINIT in this way must be aware of + how the certification infrastructure they are linking to works. + + Secondly, PKINIT also introduces the possibility of interactions + between different cryptosystems, which may be of widely varying + strengths. Many systems, for instance, allow the use of 512-bit + public keys. Using such keys to wrap data encrypted under strong + conventional cryptosystems, such as triple-DES, is inappropriate; + it adds a weak link to a strong one at extra cost. Implementors + and administrators should take care to avoid such wasteful and + deceptive interactions. + + Lastly, PKINIT calls for randomly generated keys for conventional + cryptosystems. Many such systems contain systematically "weak" + keys. PKINIT implementations MUST avoid use of these keys, either + by discarding those keys when they are generated, or by fixing them + in some way (e.g., by XORing them with a given mask). These + precautions vary from system to system; it is not our intention to + give an explicit recipe for them here. + + +5. Transport Issues + + Certificate chains can potentially grow quite large and span several + UDP packets; this in turn increases the probability that a Kerberos + message involving PKINIT extensions will be broken in transit. In + light of the possibility that the Kerberos specification will + require KDCs to accept requests using TCP as a transport mechanism, + we make the same recommendation with respect to the PKINIT + extensions as well. + + +6. Bibliography + + [1] J. Kohl, C. Neuman. The Kerberos Network Authentication Service + (V5). Request for Comments 1510. + + [2] B.C. Neuman, Theodore Ts'o. Kerberos: An Authentication Service + for Computer Networks, IEEE Communications, 32(9):33-38. September + 1994. + + [3] B. Tung, T. Ryutov, C. Neuman, G. Tsudik, B. Sommerfeld, + A. Medvinsky, M. Hur. Public Key Cryptography for Cross-Realm + Authentication in Kerberos. + draft-ietf-cat-kerberos-pk-cross-04.txt + + [4] A. Medvinsky, J. Cargille, M. Hur. Anonymous Credentials in + Kerberos. + draft-ietf-cat-kerberos-anoncred-00.txt + + [5] A. Medvinsky, M. Hur, B. Clifford Neuman. Public Key Utilizing + Tickets for Application Servers (PKTAPP). + draft-ietf-cat-pktapp-00.txt + + [6] M. Sirbu, J. Chuang. Distributed Authentication in Kerberos + Using Public Key Cryptography. Symposium On Network and Distributed + System Security, 1997. + + [7] B. Cox, J.D. Tygar, M. Sirbu. NetBill Security and Transaction + Protocol. In Proceedings of the USENIX Workshop on Electronic + Commerce, July 1995. + + [8] Alan O. Freier, Philip Karlton and Paul C. Kocher. The SSL + Protocol, Version 3.0 - IETF Draft. + + [9] B.C. Neuman, Proxy-Based Authorization and Accounting for + Distributed Systems. In Proceedings of the 13th International + Conference on Distributed Computing Systems, May 1993. + + [10] ITU-T (formerly CCITT) Information technology - Open Systems + Interconnection - The Directory: Authentication Framework + Recommendation X.509 ISO/IEC 9594-8 + + [11] R. Hously. Cryptographic Message Syntax. + draft-ietf-smime-cms-04.txt, March 1998. + + [12] PKCS #7: Cryptographic Message Syntax Standard, + An RSA Laboratories Technical Note Version 1.5 + Revised November 1, 1993 + + [13] Ron Rivest, MIT Laboratory for Computer Science and + RSA Data Security, Inc. A Description of the RC2(r) Encryption + Algorithm, November 1997. + + [14] M. Wahl, S. Kille, T. Howes. Lightweight Directory Access + Protocol (v3): UTF-8 String Representation of Distinguished Names. + Request for Comments 2253. + + [15] PKCS #6: Cryptographic Message Syntax Standard, + An RSA Laboratories Technical Note Version 1.5 + Revised November 1, 1993 + + +7. Patent Issues + + The private key storage and retrieval process described in Section + 3.4 may be covered by U.S. Patent 5,418,854 (Charles Kaufman, Morrie + Gasser, Butler Lampson, Joseph Tardo, Kannan Alagappan, all then of + Digital Corporation). At this time, inquiries into this patent are + inconclusive. We solicit discussion from any party who can illuminate + the coverage of this particular patent. + + +8. Acknowledgements + + Some of the ideas on which this proposal is based arose during + discussions over several years between members of the SAAG, the IETF + CAT working group, and the PSRG, regarding integration of Kerberos + and SPX. Some ideas have also been drawn from the DASS system. + These changes are by no means endorsed by these groups. This is an + attempt to revive some of the goals of those groups, and this + proposal approaches those goals primarily from the Kerberos + perspective. Lastly, comments from groups working on similar ideas + in DCE have been invaluable. + + +9. Expiration Date + + This draft expires May 15, 1999. + + +10. Authors + + Brian Tung + Clifford Neuman + USC Information Sciences Institute + 4676 Admiralty Way Suite 1001 + Marina del Rey CA 90292-6695 + Phone: +1 310 822 1511 + E-mail: {brian, bcn}@isi.edu + + John Wray + Digital Equipment Corporation + 550 King Street, LKG2-2/Z7 + Littleton, MA 01460 + Phone: +1 508 486 5210 + E-mail: wray@tuxedo.enet.dec.com + + Ari Medvinsky + Matthew Hur + Sasha Medvinsky + CyberSafe Corporation + 1605 NW Sammamish Road Suite 310 + Issaquah WA 98027-5378 + Phone: +1 206 391 6000 + E-mail: {ari.medvinsky, matt.hur, sasha.medvinsky}@cybersafe.com + + Jonathan Trostle + 170 W. Tasman Dr. + San Jose, CA 95134 + E-mail: jtrostle@cisco.com diff --git a/doc/standardisation/draft-ietf-cat-kerberos-pk-init-08.txt b/doc/standardisation/draft-ietf-cat-kerberos-pk-init-08.txt new file mode 100644 index 000000000..51e252acf --- /dev/null +++ b/doc/standardisation/draft-ietf-cat-kerberos-pk-init-08.txt @@ -0,0 +1,944 @@ +INTERNET-DRAFT Brian Tung +draft-ietf-cat-kerberos-pk-init-08.txt Clifford Neuman +Updates: RFC 1510 ISI +expires November 12, 1999 Matthew Hur + CyberSafe Corporation + Ari Medvinsky + Excite + Sasha Medvinsky + General Instrument + John Wray + Iris Associates, Inc. + Jonathan Trostle + Cisco + + Public Key Cryptography for Initial Authentication in Kerberos + +0. Status Of This Memo + + This document is an Internet-Draft and is in full conformance with + all provisions of Section 10 of RFC 2026. Internet-Drafts are + working documents of the Internet Engineering Task Force (IETF), + its areas, and its working groups. Note that other groups may also + distribute working documents as Internet-Drafts. + + Internet-Drafts are draft documents valid for a maximum of six + months and may be updated, replaced, or obsoleted by other + documents at any time. It is inappropriate to use Internet-Drafts + as reference material or to cite them other than as "work in + progress." + + The list of current Internet-Drafts can be accessed at + http://www.ietf.org/ietf/1id-abstracts.txt + + The list of Internet-Draft Shadow Directories can be accessed at + http://www.ietf.org/shadow.html. + + To learn the current status of any Internet-Draft, please check + the "1id-abstracts.txt" listing contained in the Internet-Drafts + Shadow Directories on ftp.ietf.org (US East Coast), + nic.nordu.net (Europe), ftp.isi.edu (US West Coast), or + munnari.oz.au (Pacific Rim). + + The distribution of this memo is unlimited. It is filed as + draft-ietf-cat-kerberos-pk-init-09.txt, and expires November 12, + 1999. Please send comments to the authors. + +1. Abstract + + This document defines extensions (PKINIT) to the Kerberos protocol + specification (RFC 1510 [1]) to provide a method for using public + key cryptography during initial authentication. The methods + defined specify the ways in which preauthentication data fields and + error data fields in Kerberos messages are to be used to transport + public key data. + +2. Introduction + + The popularity of public key cryptography has produced a desire for + its support in Kerberos [2]. The advantages provided by public key + cryptography include simplified key management (from the Kerberos + perspective) and the ability to leverage existing and developing + public key certification infrastructures. + + Public key cryptography can be integrated into Kerberos in a number + of ways. One is to associate a key pair with each realm, which can + then be used to facilitate cross-realm authentication; this is the + topic of another draft proposal. Another way is to allow users with + public key certificates to use them in initial authentication. This + is the concern of the current document. + + PKINIT utilizes Diffie-Hellman keys in combination with digital + signature keys as the primary, required mechanism. It also allows + for the use of RSA keys. Note that PKINIT supports the use of + separate signature and encryption keys. + + PKINIT enables access to Kerberos-secured services based on initial + authentication utilizing public key cryptography. PKINIT utilizes + standard public key signature and encryption data formats within the + standard Kerberos messages. The basic mechanism is as follows: The + user sends a request to the KDC as before, except that if that user + is to use public key cryptography in the initial authentication + step, his certificate and a signature accompany the initial request + in the preauthentication fields. Upon receipt of this request, the + KDC verifies the certificate and issues a ticket granting ticket + (TGT) as before, except that the encPart from the AS-REP message + carrying the TGT is now encrypted utilizing either a Diffie-Hellman + derived key or the user's public key. This message is authenticated + utilizing the public key signature of the KDC. + + The PKINIT specification may also be used as a building block for + other specifications. PKCROSS [3] utilizes PKINIT for establishing + the inter-realm key and associated inter-realm policy to be applied + in issuing cross realm service tickets. As specified in [4], + anonymous Kerberos tickets can be issued by applying a NULL + signature in combination with Diffie-Hellman in the PKINIT exchange. + Additionally, the PKINIT specification may be used for direct peer + to peer authentication without contacting a central KDC. This + application of PKINIT is described in PKTAPP [5] and is based on + concepts introduced in [6, 7]. For direct client-to-server + authentication, the client uses PKINIT to authenticate to the end + server (instead of a central KDC), which then issues a ticket for + itself. This approach has an advantage over TLS [8] in that the + server does not need to save state (cache session keys). + Furthermore, an additional benefit is that Kerberos tickets can + facilitate delegation (see [9]). + +3. Proposed Extensions + + This section describes extensions to RFC 1510 for supporting the + use of public key cryptography in the initial request for a ticket + granting ticket (TGT). + + In summary, the following change to RFC 1510 is proposed: + + * Users may authenticate using either a public key pair or a + conventional (symmetric) key. If public key cryptography is + used, public key data is transported in preauthentication + data fields to help establish identity. The user presents + a public key certificate and obtains an ordinary TGT that may + be used for subsequent authentication, with such + authentication using only conventional cryptography. + + Section 3.1 provides definitions to help specify message formats. + Section 3.2 describes the extensions for the initial authentication + method. + +3.1. Definitions + + The extensions involve new preauthentication fields; we introduce + the following preauthentication types: + + PA-PK-AS-REQ 14 + PA-PK-AS-REP 15 + PA-PK-KEY-REQ 18 + PA-PK-KEY-REP 19 + + The extensions also involve new error types; we introduce the + following types: + + KDC_ERR_CLIENT_NOT_TRUSTED 62 + KDC_ERR_KDC_NOT_TRUSTED 63 + KDC_ERR_INVALID_SIG 64 + KDC_ERR_KEY_TOO_WEAK 65 + KDC_ERR_CERTIFICATE_MISMATCH 66 + + We utilize the following typed data for errors: + + ETD-PKINIT-CMS-CERTIFICATES 101 + ETD-KRB-PRINCIPAL 102 + ETD-KRB-REALM 103 + + We utilize the following encryption types (which map directly to + OIDs): + sha1WithRSAEncryption-CmsOID 8 + dsaWithSHA1-CmsOID 9 + md4WithRsaEncryption-CmsOID 10 + md5WithRSAEncryption-CmsOID 11 + rc2CBC-EnvOID 12 + rc4-EnvOID 13 + + In many cases, PKINIT requires the encoding of an X.500 name as a + Realm. In these cases, the realm will be represented using a + different style, specified in RFC 1510 with the following example: + + NAMETYPE:rest/of.name=without-restrictions + + For a realm derived from an X.500 name, NAMETYPE will have the value + X500-RFC2253. The full realm name will appear as follows: + + X500-RFC2253:RFC2253Encode(DistinguishedName) + + where DistinguishedName is an X.500 name, and RFC2253Encode is a + readable ASCII encoding of an X.500 name, as defined by + RFC 2253 [14] (part of LDAPv3). + + To ensure that this encoding is unique, we add the following rule + to those specified by RFC 2253: + + The order in which the attributes appear in the RFC 2253 + encoding must be the reverse of the order in the ASN.1 + encoding of the X.500 name that appears in the public key + certificate. The order of the relative distinguished names + (RDNs), as well as the order of the AttributeTypeAndValues + within each RDN, will be reversed. (This is despite the fact + that an RDN is defined as a SET of AttributeTypeAndValues, where + an order is normally not important.) + + Similarly, PKINIT may require the encoding of an X.500 name as a + PrincipalName. In these cases, the name-type of the principal name + shall be set to KRB_NT-X500-PRINCIPAL. This new name type is + defined as: + + KRB_NT_X500_PRINCIPAL 6 + + The name-string shall be set as follows: + + RFC2253Encode(DistinguishedName) + + as described above. + + Note that name mapping may be required or optional based on policy. + +3.1.1. Encryption and Key Formats + + In the exposition below, we use the terms public key and private + key generically. It should be understood that the term "public + key" may be used to refer to either a public encryption key or a + signature verification key, and that the term "private key" may be + used to refer to either a private decryption key or a signature + generation key. The fact that these are logically distinct does + not preclude the assignment of bitwise identical keys. + + In the case of Diffie-Hellman, the key shall be produced from the + agreed bit string as follows: + + * Truncate the bit string to the appropriate length. + * Rectify parity in each byte (if necessary) to obtain the key. + + For instance, in the case of a DES key, we take the first eight + bytes of the bit stream, and then adjust the least significant bit + of each byte to ensure that each byte has odd parity. + +3.1.2. Algorithm Identifiers + + PKINIT does not define, but does permit, the algorithm identifiers + listed below. + +3.1.2.1. Signature Algorithm Identifiers + + These are the algorithm identifiers for use in the Signature data + structure as specified in CMS [11]: + + sha-1WithRSAEncryption ALGORITHM PARAMETER NULL + ::= { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) + pkcs-1(1) 5 } + + dsaWithSHA1 ALGORITHM PARAMETER NULL + ::= { iso(1) identifiedOrganization(3) oIW(14) oIWSecSig(3) + oIWSecAlgorithm(2) dsaWithSHA1(27) } + + md4WithRsaEncryption ALGORITHM PARAMETER NULL + ::= { iso(1) identifiedOrganization(3) oIW(14) oIWSecSig(3) + oIWSecAlgorithm(2) md4WithRSAEncryption(4) } + + md5WithRSAEncryption ALGORITHM PARAMETER NULL + ::= { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) + pkcs-1(1) md5WithRSAEncryption(4) } + +3.1.2.2 Diffie-Hellman Key Agreement Algorithm Identifier + + This algorithm identifier is used inside the SubjectPublicKeyInfo + data structure: + + dhKeyAgreement ALGORITHM PARAMETER DHParameters + ::= { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) + pkcs-3(3) dhKeyAgreement(1) } + + DHParameters ::= SEQUENCE { + prime INTEGER, + -- p + base INTEGER, + -- g + privateValueLength INTEGER OPTIONAL + } -- as specified by the X.509 recommendation [9] + +3.1.2.3. Algorithm Identifiers for RSA Encryption + + These algorithm identifiers are used inside the EnvelopedData data + structure, for encrypting the temporary key with a public key: + + id-RSAES-OAEP OBJECT IDENTIFIER + ::= { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) + pkcs-1(1) 7 } + +3.1.2.4. Algorithm Identifiers for Encryption with Secret Keys + + These algorithm identifiers are used inside the EnvelopedData data + structure, for encrypting the temporary key with a Diffie-Hellman- + derived key, or for encrypting the reply key: + + desCBC ALGORITHM PARAMETER IV8 + ::= { iso(1) identifiedOrganization(3) oIW(14) oIWSecSig(3) + oIWSecAlgorithm(2) desCBC(7) } + + DES-EDE3-CBC ALGORITHM PARAMETER IV8 + ::= { iso(1) member-body(2) US(840) rsadsi(113549) + encryptionAlgorithm(3) desEDE3(7) } + + IV8 ::= OCTET STRING (SIZE(8)) -- initialization vector + + rc2CBC ALGORITHM PARAMETER RC2-CBCParameter + ::= { iso(1) member-body(2) US(840) rsadsi(113549) + encryptionAlgorithm(3) rc2CBC(2) } + + The rc2CBC algorithm parameters (RC2-CBCParameter) are defined + in the following section. + + rc4 ALGORITHM PARAMETER NULL + ::= { iso(1) member-body(2) US(840) rsadsi(113549) + encryptionAlgorithm(3) rc4(4) } + + The rc4 algorithm cannot be used with the Diffie-Hellman-derived + keys, because its parameters do not specify the size of the key. + +3.1.2.5. rc2CBC Algorithm Parameters + + This definition of the RC2 parameters is taken from a paper by + Ron Rivest [13]. Refer to [13] for the complete description of the + RC2 algorithm. + + RC2-CBCParameter ::= CHOICE { + iv IV, + params SEQUENCE { + version RC2Version, + iv IV + } + } + + where + + IV ::= OCTET STRING -- 8 octets + RC2Version ::= INTEGER -- 1-1024 + + RC2 in CBC mode has two parameters: an 8-byte initialization + vector (IV) and a version number in the range 1-1024 which + specifies in a roundabout manner the number of effective key bits + to be used for the RC2 encryption/decryption. + + The correspondence between effective key bits and version number + is as follows: + + 1. If the number EKB of effective key bits is in the range 1-255, + then the version number is given by Table[EKB], where the + 256-byte translation table is specified below. It specifies a + permutation on the numbers 0-255. + + 2. If the number EKB of effective key bits is in the range + 256-1024, then the version number is simply EKB. + + The default number of effective key bits for RC2 is 32. + If RC2-CBC is being performed with 32 effective key bits, the + parameters should be supplied as a simple IV, rather than as a + SEQUENCE containing a version and an IV. + + 0 1 2 3 4 5 6 7 8 9 a b c d e f + + 00: bd 56 ea f2 a2 f1 ac 2a b0 93 d1 9c 1b 33 fd d0 + 10: 30 04 b6 dc 7d df 32 4b f7 cb 45 9b 31 bb 21 5a + 20: 41 9f e1 d9 4a 4d 9e da a0 68 2c c3 27 5f 80 36 + 30: 3e ee fb 95 1a fe ce a8 34 a9 13 f0 a6 3f d8 0c + 40: 78 24 af 23 52 c1 67 17 f5 66 90 e7 e8 07 b8 60 + 50: 48 e6 1e 53 f3 92 a4 72 8c 08 15 6e 86 00 84 fa + 60: f4 7f 8a 42 19 f6 db cd 14 8d 50 12 ba 3c 06 4e + 70: ec b3 35 11 a1 88 8e 2b 94 99 b7 71 74 d3 e4 bf + 80: 3a de 96 0e bc 0a ed 77 fc 37 6b 03 79 89 62 c6 + 90: d7 c0 d2 7c 6a 8b 22 a3 5b 05 5d 02 75 d5 61 e3 + a0: 18 8f 55 51 ad 1f 0b 5e 85 e5 c2 57 63 ca 3d 6c + b0: b4 c5 cc 70 b2 91 59 0d 47 20 c8 4f 58 e0 01 e2 + c0: 16 38 c4 6f 3b 0f 65 46 be 7e 2d 7b 82 f9 40 b5 + d0: 1d 73 f8 eb 26 c7 87 97 25 54 b1 28 aa 98 9d a5 + e0: 64 6d 7a d4 10 81 44 ef 49 d6 ae 2e dd 76 5c 2f + f0: a7 1c c9 09 69 9a 83 cf 29 39 b9 e9 4c ff 43 ab + + +3.2. Public Key Authentication + + Implementation of the changes in this section is REQUIRED for + compliance with PKINIT. + + It is assumed that all public keys are signed by some certification + authority (CA). The initial authentication request is sent as per + RFC 1510, except that a preauthentication field containing data + signed by the user's private key accompanies the request: + + PA-PK-AS-REQ ::= SEQUENCE { + -- PA TYPE 14 + signedAuthPack [0] SignedData + -- defined in CMS [11] + -- AuthPack (below) defines the data + -- that is signed + trustedCertifiers [1] SEQUENCE OF PrincipalName OPTIONAL, + -- CAs that the client trusts + kdcCert [2] IssuerAndSerialNumber OPTIONAL + -- as defined in CMS [11] + -- specifies a particular KDC + -- certificate if the client + -- already has it; + -- must be accompanied by + -- a single trustedCertifier + } + + Usage of SignedData: + The SignedData data type is specified in the Cryptographic + Message Syntax, a product of the S/MIME working group of the IETF. + - The encapContentInfo field must contain the PKAuthenticator + and, optionally, the client's Diffie Hellman public value. + - The eContentType field shall contain the OID value for + id-data: iso(1) member-body(2) us(840) rsadsi(113549) + pkcs(1) pkcs7(7) data(1) + - The eContent field is data of the type AuthPack (below). + - The signerInfos field is a SET of SignerInfo that is required by + CMS; however, the set may contain zero elements. When non-empty, + this field contains the client's certificate chain. If present, + the KDC uses the public key from the client's certificate to + verify the signature in the request. Note that the client may + pass different certificates that are used for signing or for + encrypting. Thus, the KDC may utilize a different client + certificate for signature verification than the one it uses to + encrypt the reply to the client. + + AuthPack ::= SEQUENCE { + pkAuthenticator [0] PKAuthenticator, + clientPublicValue [1] SubjectPublicKeyInfo OPTIONAL + -- if client is using Diffie-Hellman + } + + PKAuthenticator ::= SEQUENCE { + kdcName [0] PrincipalName, + kdcRealm [1] Realm, + cusec [2] INTEGER, + -- for replay prevention + ctime [3] KerberosTime, + -- for replay prevention + nonce [4] INTEGER + } + + SubjectPublicKeyInfo ::= SEQUENCE { + algorithm AlgorithmIdentifier, + -- dhKeyAgreement + subjectPublicKey BIT STRING + -- for DH, equals + -- public exponent (INTEGER encoded + -- as payload of BIT STRING) + } -- as specified by the X.509 recommendation [9] + + AlgorithmIdentifier ::= SEQUENCE { + algorithm ALGORITHM.&id, + parameters ALGORITHM.&type + } -- as specified by the X.509 recommendation [10] + + If the client passes an issuer and serial number in the request, + the KDC is requested to use the referred-to certificate. If none + exists, then the KDC returns an error of type + KDC_ERR_CERTIFICATE_MISMATCH. It also returns this error if, on the + other hand, the client does not pass any trustedCertifiers, + believing that it has the KDC's certificate, but the KDC has more + than one certificate. The KDC should include information in the + KRB-ERROR message that indicates the KDC certificate(s) that a + client may utilize. This data is specified in the e-typed-data + type as follows: + + ETypedData ::= SEQUENCE { + e-data-type [1] INTEGER, + e-data-value [2] OCTET STRING, + } -- per Kerberos RFC 1510 revisions + + where: + e-data-type = ETD-PKINIT-CMS-CERTIFICATES = 101 + e-data-value = CertificateSet // as specified by CMS [11] + + The PKAuthenticator carries information to foil replay attacks, + to bind the request and response. The PKAuthenticator is signed + with the private key corresponding to the public key in the + certificate found in userCert (or cached by the KDC). + + The trustedCertifiers field contains a list of certification + authorities trusted by the client, in the case that the client does + not possess the KDC's public key certificate. If the KDC has no + certificate signed by any of the trustedCertifiers, then it returns + an error of type KDC_ERR_KDC_NOT_TRUSTED. + + KDCs should try to (in order of preference): + 1. Use the KDC certificate identified by the serialNumber included + in the client's request. + 2. Use a certificate issued to the KDC by the client's CA (if in the + middle of a CA key roll-over, use the KDC cert issued under same + CA key as user cert used to verify request). + 3. Use a certificate issued to the KDC by one of the client's + trustedCertifier(s); + If the KDC is unable to comply with any of these options, then the + KDC returns an error message of type KDC_ERR_KDC_NOT_TRUSTED to the + client. + + Upon receipt of the AS_REQ with PA-PK-AS-REQ pre-authentication + type, the KDC attempts to verify the user's certificate chain + (userCert), if one is provided in the request. This is done by + verifying the certification path against the KDC's policy of + legitimate certifiers. This may be based on a certification + hierarchy, or it may be simply a list of recognized certifiers in a + system like PGP. + + If verification of the user's certificate fails, the KDC sends back + an error message of type KDC_ERR_CLIENT_NOT_TRUSTED. The e-data + field contains additional information pertaining to this error, and + is formatted as follows: + + METHOD-DATA ::= SEQUENCE { + method-type [0] INTEGER, + -- 0 = not specified + -- 1 = cannot verify public key + -- 2 = invalid certificate + -- 3 = revoked certificate + -- 4 = invalid KDC name + -- 5 = client name mismatch + method-data [1] OCTET STRING OPTIONAL + } -- syntax as for KRB_AP_ERR_METHOD (RFC 1510) + + The values for the method-type and method-data fields are described + in Section 3.2.1. + + If a trust relationship exists, the KDC then verifies the client's + signature on AuthPack. If that fails, the KDC returns an error + message of type KDC_ERR_INVALID_SIG. Otherwise, the KDC uses the + timestamp (ctime and cusec) in the PKAuthenticator to assure that + the request is not a replay. The KDC also verifies that its name + is specified in the PKAuthenticator. + + If the clientPublicValue field is filled in, indicating that the + client wishes to use Diffie-Hellman key agreement, then the KDC + checks to see that the parameters satisfy its policy. If they do + not (e.g., the prime size is insufficient for the expected + encryption type), then the KDC sends back an error message of type + KDC_ERR_KEY_TOO_WEAK. Otherwise, it generates its own public and + private values for the response. + + The KDC also checks that the timestamp in the PKAuthenticator is + within the allowable window and that the principal name and realm + are correct. If the local (server) time and the client time in the + authenticator differ by more than the allowable clock skew, then the + KDC returns an error message of type KRB_AP_ERR_SKEW. If the + principal name or realm do not match the KDC, then the KDC returns + an error message of type KDC_ERR_NAME_MISMATCH for which the + e-typed-data may contain the correct name to use + (EDT-KRB-PRINCIPAL=102 or EDT-KRB-REALM=103 where + e-data-value = PrincipalName or Realm as defined by RFC 1510). + + Assuming no errors, the KDC replies as per RFC 1510, except as + follows. The user's name in the ticket is determined by the + following decision algorithm: + + 1. If the KDC has a mapping from the name in the certificate + to a Kerberos name, then use that name. + Else + 2. If the certificate contains a Kerberos name in an extension + field, and local KDC policy allows, then use that name. + Else + 3. Use the name as represented in the certificate, mapping + as necessary (e.g., as per RFC 2253 for X.500 names). In + this case the realm in the ticket shall be the name of the + certification authority that issued the user's certificate. + + The KDC encrypts the reply not with the user's long-term key, but + with a random key generated only for this particular response. This + random key is sealed in the preauthentication field: + + PA-PK-AS-REP ::= CHOICE { + -- PA TYPE 15 + dhSignedData [0] SignedData, + -- Defined in CMS and used only with + -- Diffie-Helman key exchange + encKeyPack [1] EnvelopedData, + -- Defined in CMS + -- The temporary key is encrypted + -- using the client public key + -- key + -- SignedReplyKeyPack, encrypted + -- with the temporary key, is also + -- included. + } + + Usage of SignedData: + If the Diffie-Hellman option is used, dhSignedData in PA-PK-AS-REP + provides authenticated Diffie-Hellman parameters of the KDC. The + reply key used to encrypt part of the KDC reply message is derived + from the Diffie-Hellman exchange: + - Both the KDC and the client calculate a secret value (g^ab mod p), + where a is the client's private exponent and b is the KDC's + private exponent. + - Both the KDC and the client take the first N bits of this secret + value and convert it into a reply key. N depends on the reply key + type. + - If the reply key is DES, N=64 bits, where some of the bits are + replaced with parity bits, according to FIPS PUB 74. + - If the reply key is (3-key) 3-DES, N=192 bits, where some of the + bits are replaced with parity bits, according to FIPS PUB 74. + - The encapContentInfo field must contain the KdcDHKeyInfo as + defined below. + - The eContentType field shall contain the OID value for + id-data: iso(1) member-body(2) us(840) rsadsi(113549) + pkcs(1) pkcs7(7) data(1) + - The certificates field must contain the certificates necessary + for the client to establish trust in the KDC's certificate + based on the list of trusted certifiers sent by the client in + the PA-PK-AS-REQ. This field may be empty if the client did + not send to the KDC a list of trusted certifiers (the + trustedCertifiers field was empty, meaning that the client + already possesses the KDC's certificate). + - The signerInfos field is a SET that must contain at least one + member, since it contains the actual signature. + + Usage of EnvelopedData: + The EnvelopedData data type is specified in the Cryptographic + Message Syntax, a product of the S/MIME working group of the IETF. + It contains an temporary key encrypted with the PKINIT + client's public key. It also contains a signed and encrypted + reply key. + - The originatorInfo field is not required, since that information + may be presented in the signedData structure that is encrypted + within the encryptedContentInfo field. + - The optional unprotectedAttrs field is not required for PKINIT. + - The recipientInfos field is a SET which must contain exactly one + member of the KeyTransRecipientInfo type for encryption + with an RSA public key. + - The encryptedKey field (in KeyTransRecipientInfo) contains + the temporary key which is encrypted with the PKINIT client's + public key. + - The encryptedContentInfo field contains the signed and encrypted + reply key. + - The contentType field shall contain the OID value for + id-signedData: iso(1) member-body(2) us(840) rsadsi(113549) + pkcs(1) pkcs7(7) signedData(2) + - The encryptedContent field is encrypted data of the CMS type + signedData as specified below. + - The encapContentInfo field must contains the ReplyKeyPack. + - The eContentType field shall contain the OID value for + id-data: iso(1) member-body(2) us(840) rsadsi(113549) + pkcs(1) pkcs7(7) data(1) + - The eContent field is data of the type ReplyKeyPack (below). + - The certificates field must contain the certificates necessary + for the client to establish trust in the KDC's certificate + based on the list of trusted certifiers sent by the client in + the PA-PK-AS-REQ. This field may be empty if the client did + not send to the KDC a list of trusted certifiers (the + trustedCertifiers field was empty, meaning that the client + already possesses the KDC's certificate). + - The signerInfos field is a SET that must contain at least one + member, since it contains the actual signature. + + KdcDHKeyInfo ::= SEQUENCE { + -- used only when utilizing Diffie-Hellman + nonce [0] INTEGER, + -- binds responce to the request + subjectPublicKey [2] BIT STRING + -- Equals public exponent (g^a mod p) + -- INTEGER encoded as payload of + -- BIT STRING + } + + ReplyKeyPack ::= SEQUENCE { + -- not used for Diffie-Hellman + replyKey [0] EncryptionKey, + -- used to encrypt main reply + -- ENCTYPE is at least as strong as + -- ENCTYPE of session key + nonce [1] INTEGER, + -- binds response to the request + -- must be same as the nonce + -- passed in the PKAuthenticator + } + + + Since each certifier in the certification path of a user's + certificate is essentially a separate realm, the name of each + certifier must be added to the transited field of the ticket. The + format of these realm names is defined in Section 3.1 of this + document. If applicable, the transit-policy-checked flag should be + set in the issued ticket. + + The KDC's certificate must bind the public key to a name derivable + from the name of the realm for that KDC. X.509 certificates shall + contain the principal name of the KDC as the SubjectAltName version + 3 extension. Below is the definition of this version 3 extension, as + specified by the X.509 standard: + + subjectAltName EXTENSION ::= { + SYNTAX GeneralNames + IDENTIFIED BY id-ce-subjectAltName + } + + GeneralNames ::= SEQUENCE SIZE(1..MAX) OF GeneralName + + GeneralName ::= CHOICE { + otherName [0] INSTANCE OF OTHER-NAME, + ... + } + + OTHER-NAME ::= TYPE-IDENTIFIER + + In this definition, otherName is a name of any form defined as an + instance of the OTHER-NAME information object class. For the purpose + of specifying a Kerberos principal name, INSTANCE OF OTHER-NAME will + be replaced by the type KerberosPrincipalName: + + KerberosPrincipalName ::= SEQUENCE { + nameType [0] OTHER-NAME.&id ( { PrincipalNameTypes } ), + name [1] OTHER-NAME.&type ( { PrincipalNameTypes } + { @nameType } ) + } + + PrincipalNameTypes OTHER-NAME ::= { + { PrincipalNameSrvInst IDENTIFIED BY principalNameSrvInst } + } + + PrincipalNameSrvInst ::= GeneralString + + where (from the Kerberos specification) we have + + krb5 OBJECT IDENTIFIER ::= { iso (1) + org (3) + dod (6) + internet (1) + security (5) + kerberosv5 (2) } + + principalName OBJECT IDENTIFIER ::= { krb5 2 } + + principalNameSrvInst OBJECT IDENTIFIER ::= { principalName 2 } + + (This specification can also be used to specify a Kerberos name + within the user's certificate.) + + The client then extracts the random key used to encrypt the main + reply. This random key (in encPaReply) is encrypted with either the + client's public key or with a key derived from the DH values + exchanged between the client and the KDC. + +3.2.1. Additional Information for Errors + + This section describes the interpretation of the method-type and + method-data fields of the KDC_ERR_CLIENT_NOT_TRUSTED error. + + If method-type=1, the client's public key certificate chain does not + contain a certificate that is signed by a certification authority + trusted by the KDC. The format of the method-data field will be an + ASN.1 encoding of a list of trusted certifiers, as defined above: + + TrustedCertifiers ::= SEQUENCE OF PrincipalName + + If method-type=2, the signature on one of the certificates in the + chain cannot be verified. The format of the method-data field will + be an ASN.1 encoding of the integer index of the certificate in + question: + + CertificateIndex ::= INTEGER + -- 0 = 1st certificate, + -- 1 = 2nd certificate, etc + + If method-type=3, one of the certificates in the chain has been + revoked. The format of the method-data field will be an ASN.1 + encoding of the integer index of the certificate in question: + + CertificateIndex ::= INTEGER + -- 0 = 1st certificate, + -- 1 = 2nd certificate, etc + + If method-type=4, the KDC name or realm in the PKAuthenticator does + not match the principal name of the KDC. There is no method-data + field in this case. + + If method-type=5, the client name or realm in the certificate does + not match the principal name of the client. There is no + method-data field in this case. + +3.2.2. Required Algorithms + + Not all of the algorithms in the PKINIT protocol specification have + to be implemented in order to comply with the proposed standard. + Below is a list of the required algorithms: + + - Diffie-Hellman public/private key pairs + - SHA1 digest and DSA for signatures + - 3-key triple DES keys derived from the Diffie-Hellman Exchange + - 3-key triple DES Temporary and Reply keys + +4. Logistics and Policy + + This section describes a way to define the policy on the use of + PKINIT for each principal and request. + + The KDC is not required to contain a database record for users + that use either the Standard Public Key Authentication. However, + if these users are registered with the KDC, it is recommended that + the database record for these users be modified to an additional + flag in the attributes field to indicate that the user should + authenticate using PKINIT. If this flag is set and a request + message does not contain the PKINIT preauthentication field, then + the KDC sends back as error of type KDC_ERR_PREAUTH_REQUIRED + indicating that a preauthentication field of type PA-PK-AS-REQ must + be included in the request. + +5. Security Considerations + + PKINIT raises a few security considerations, which we will address + in this section. + + First of all, PKINIT introduces a new trust model, where KDCs do not + (necessarily) certify the identity of those for whom they issue + tickets. PKINIT does allow KDCs to act as their own CAs, in order + to simplify key management, but one of the additional benefits is to + align Kerberos authentication with a global public key + infrastructure. Anyone using PKINIT in this way must be aware of + how the certification infrastructure they are linking to works. + + Secondly, PKINIT also introduces the possibility of interactions + between different cryptosystems, which may be of widely varying + strengths. Many systems, for instance, allow the use of 512-bit + public keys. Using such keys to wrap data encrypted under strong + conventional cryptosystems, such as triple-DES, is inappropriate; + it adds a weak link to a strong one at extra cost. Implementors + and administrators should take care to avoid such wasteful and + deceptive interactions. + + Lastly, PKINIT calls for randomly generated keys for conventional + cryptosystems. Many such systems contain systematically "weak" + keys. PKINIT implementations MUST avoid use of these keys, either + by discarding those keys when they are generated, or by fixing them + in some way (e.g., by XORing them with a given mask). These + precautions vary from system to system; it is not our intention to + give an explicit recipe for them here. + +6. Transport Issues + + Certificate chains can potentially grow quite large and span several + UDP packets; this in turn increases the probability that a Kerberos + message involving PKINIT extensions will be broken in transit. In + light of the possibility that the Kerberos specification will + require KDCs to accept requests using TCP as a transport mechanism, + we make the same recommendation with respect to the PKINIT + extensions as well. + +7. Bibliography + + [1] J. Kohl, C. Neuman. The Kerberos Network Authentication Service + (V5). Request for Comments 1510. + + [2] B.C. Neuman, Theodore Ts'o. Kerberos: An Authentication Service + for Computer Networks, IEEE Communications, 32(9):33-38. September + 1994. + + [3] B. Tung, T. Ryutov, C. Neuman, G. Tsudik, B. Sommerfeld, + A. Medvinsky, M. Hur. Public Key Cryptography for Cross-Realm + Authentication in Kerberos. + draft-ietf-cat-kerberos-pk-cross-04.txt + + [4] A. Medvinsky, J. Cargille, M. Hur. Anonymous Credentials in + Kerberos. + draft-ietf-cat-kerberos-anoncred-00.txt + + [5] A. Medvinsky, M. Hur, B. Clifford Neuman. Public Key Utilizing + Tickets for Application Servers (PKTAPP). + draft-ietf-cat-pktapp-00.txt + + [6] M. Sirbu, J. Chuang. Distributed Authentication in Kerberos + Using Public Key Cryptography. Symposium On Network and Distributed + System Security, 1997. + + [7] B. Cox, J.D. Tygar, M. Sirbu. NetBill Security and Transaction + Protocol. In Proceedings of the USENIX Workshop on Electronic + Commerce, July 1995. + + [8] T. Dierks, C. Allen. The TLS Protocol, Version 1.0 + Request for Comments 2246, January 1999. + + [9] B.C. Neuman, Proxy-Based Authorization and Accounting for + Distributed Systems. In Proceedings of the 13th International + Conference on Distributed Computing Systems, May 1993. + + [10] ITU-T (formerly CCITT) Information technology - Open Systems + Interconnection - The Directory: Authentication Framework + Recommendation X.509 ISO/IEC 9594-8 + + [11] R. Housley. Cryptographic Message Syntax. + draft-ietf-smime-cms-10.txt, December 1998. + + [12] PKCS #7: Cryptographic Message Syntax Standard, + An RSA Laboratories Technical Note Version 1.5 + Revised November 1, 1993 + + [13] R. Rivest, MIT Laboratory for Computer Science and RSA Data + Security, Inc. A Description of the RC2(r) Encryption Algorithm + March 1998. + Request for Comments 2268. + + [14] M. Wahl, S. Kille, T. Howes. Lightweight Directory Access + Protocol (v3): UTF-8 String Representation of Distinguished Names. + Request for Comments 2253. + +8. Acknowledgements + + Some of the ideas on which this proposal is based arose during + discussions over several years between members of the SAAG, the IETF + CAT working group, and the PSRG, regarding integration of Kerberos + and SPX. Some ideas have also been drawn from the DASS system. + These changes are by no means endorsed by these groups. This is an + attempt to revive some of the goals of those groups, and this + proposal approaches those goals primarily from the Kerberos + perspective. Lastly, comments from groups working on similar ideas + in DCE have been invaluable. + +9. Expiration Date + + This draft expires November 12, 1999. + +10. Authors + + Brian Tung + Clifford Neuman + USC Information Sciences Institute + 4676 Admiralty Way Suite 1001 + Marina del Rey CA 90292-6695 + Phone: +1 310 822 1511 + E-mail: {brian, bcn}@isi.edu + + Matthew Hur + CyberSafe Corporation + 1605 NW Sammamish Road + Issaquah WA 98027-5378 + Phone: +1 425 391 6000 + E-mail: matt.hur@cybersafe.com + + Ari Medvinsky + Excite + 555 Broadway + Redwood City, CA 94063 + Phone +1 650 569 2119 + E-mail: amedvins@excitecorp.com + + Sasha Medvinsky + General Instrument + 6450 Sequence Drive + San Diego, CA 92121 + Phone +1 619 404 2825 + E-mail: smedvinsky@gi.com + + John Wray + Iris Associates, Inc. + 5 Technology Park Dr. + Westford, MA 01886 + E-mail: John_Wray@iris.com + + Jonathan Trostle + 170 W. Tasman Dr. + San Jose, CA 95134 + E-mail: jtrostle@cisco.com diff --git a/doc/standardisation/draft-ietf-cat-kerberos-pk-init-09.txt b/doc/standardisation/draft-ietf-cat-kerberos-pk-init-09.txt new file mode 100644 index 000000000..748f08954 --- /dev/null +++ b/doc/standardisation/draft-ietf-cat-kerberos-pk-init-09.txt @@ -0,0 +1,908 @@ +INTERNET-DRAFT Brian Tung +draft-ietf-cat-kerberos-pk-init-09.txt Clifford Neuman +Updates: RFC 1510 ISI +expires December 1, 1999 Matthew Hur + CyberSafe Corporation + Ari Medvinsky + Excite + Sasha Medvinsky + General Instrument + John Wray + Iris Associates, Inc. + Jonathan Trostle + Cisco + + Public Key Cryptography for Initial Authentication in Kerberos + +0. Status Of This Memo + + This document is an Internet-Draft and is in full conformance with + all provisions of Section 10 of RFC 2026. Internet-Drafts are + working documents of the Internet Engineering Task Force (IETF), + its areas, and its working groups. Note that other groups may also + distribute working documents as Internet-Drafts. + + Internet-Drafts are draft documents valid for a maximum of six + months and may be updated, replaced, or obsoleted by other + documents at any time. It is inappropriate to use Internet-Drafts + as reference material or to cite them other than as "work in + progress." + + + The list of current Internet-Drafts can be accessed at + http://www.ietf.org/ietf/1id-abstracts.txt + + The list of Internet-Draft Shadow Directories can be accessed at + http://www.ietf.org/shadow.html. + + To learn the current status of any Internet-Draft, please check + the "1id-abstracts.txt" listing contained in the Internet-Drafts + Shadow Directories on ftp.ietf.org (US East Coast), + nic.nordu.net (Europe), ftp.isi.edu (US West Coast), or + munnari.oz.au (Pacific Rim). + + The distribution of this memo is unlimited. It is filed as + draft-ietf-cat-kerberos-pk-init-09.txt, and expires December 1, + 1999. Please send comments to the authors. + +1. Abstract + + This document defines extensions (PKINIT) to the Kerberos protocol + specification (RFC 1510 [1]) to provide a method for using public + key cryptography during initial authentication. The methods + defined specify the ways in which preauthentication data fields and + error data fields in Kerberos messages are to be used to transport + public key data. + +2. Introduction + + The popularity of public key cryptography has produced a desire for + its support in Kerberos [2]. The advantages provided by public key + cryptography include simplified key management (from the Kerberos + perspective) and the ability to leverage existing and developing + public key certification infrastructures. + + Public key cryptography can be integrated into Kerberos in a number + of ways. One is to associate a key pair with each realm, which can + then be used to facilitate cross-realm authentication; this is the + topic of another draft proposal. Another way is to allow users with + public key certificates to use them in initial authentication. This + is the concern of the current document. + + PKINIT utilizes Diffie-Hellman keys in combination with digital + signature keys as the primary, required mechanism. It also allows + for the use of RSA keys. Note that PKINIT supports the use of + separate signature and encryption keys. + + PKINIT enables access to Kerberos-secured services based on initial + authentication utilizing public key cryptography. PKINIT utilizes + standard public key signature and encryption data formats within the + standard Kerberos messages. The basic mechanism is as follows: The + user sends a request to the KDC as before, except that if that user + is to use public key cryptography in the initial authentication + step, his certificate and a signature accompany the initial request + in the preauthentication fields. Upon receipt of this request, the + KDC verifies the certificate and issues a ticket granting ticket + (TGT) as before, except that the encPart from the AS-REP message + carrying the TGT is now encrypted utilizing either a Diffie-Hellman + derived key or the user's public key. This message is authenticated + utilizing the public key signature of the KDC. + + The PKINIT specification may also be used as a building block for + other specifications. PKCROSS [3] utilizes PKINIT for establishing + the inter-realm key and associated inter-realm policy to be applied + in issuing cross realm service tickets. As specified in [4], + anonymous Kerberos tickets can be issued by applying a NULL + signature in combination with Diffie-Hellman in the PKINIT exchange. + Additionally, the PKINIT specification may be used for direct peer + to peer authentication without contacting a central KDC. This + application of PKINIT is described in PKTAPP [5] and is based on + concepts introduced in [6, 7]. For direct client-to-server + authentication, the client uses PKINIT to authenticate to the end + server (instead of a central KDC), which then issues a ticket for + itself. This approach has an advantage over TLS [8] in that the + server does not need to save state (cache session keys). + Furthermore, an additional benefit is that Kerberos tickets can + facilitate delegation (see [9]). + +3. Proposed Extensions + + This section describes extensions to RFC 1510 for supporting the + use of public key cryptography in the initial request for a ticket + granting ticket (TGT). + + In summary, the following change to RFC 1510 is proposed: + + * Users may authenticate using either a public key pair or a + conventional (symmetric) key. If public key cryptography is + used, public key data is transported in preauthentication + data fields to help establish identity. The user presents + a public key certificate and obtains an ordinary TGT that may + be used for subsequent authentication, with such + authentication using only conventional cryptography. + + Section 3.1 provides definitions to help specify message formats. + Section 3.2 describes the extensions for the initial authentication + method. + +3.1. Definitions + + The extensions involve new preauthentication fields; we introduce + the following preauthentication types: + + PA-PK-AS-REQ 14 + PA-PK-AS-REP 15 + + The extensions also involve new error types; we introduce the + following types: + + KDC_ERR_CLIENT_NOT_TRUSTED 62 + KDC_ERR_KDC_NOT_TRUSTED 63 + KDC_ERR_INVALID_SIG 64 + KDC_ERR_KEY_TOO_WEAK 65 + KDC_ERR_CERTIFICATE_MISMATCH 66 + KDC_ERR_CANT_VERIFY_CERTIFICATE 70 + KDC_ERR_INVALID_CERTIFICATE 71 + KDC_ERR_REVOKED_CERTIFICATE 72 + KDC_ERR_REVOCATION_STATUS_UNKNOWN 73 + KDC_ERR_REVOCATION_STATUS_UNAVAILABLE 74 + KDC_ERR_CLIENT_NAME_MISMATCH 75 + KDC_ERR_KDC_NAME_MISMATCH 76 + + We utilize the following typed data for errors: + + TD-PKINIT-CMS-CERTIFICATES 101 + TD-KRB-PRINCIPAL 102 + TD-KRB-REALM 103 + TD-TRUSTED-CERTIFIERS 104 + TD-CERTIFICATE-INDEX 105 + + We utilize the following encryption types (which map directly to + OIDs): + + dsaWithSHA1-CmsOID 9 + md5WithRSAEncryption-CmsOID 10 + sha1WithRSAEncryption-CmsOID 11 + rc2CBC-EnvOID 12 + rsaEncryption-EnvOID (PKCS#1 v1.5) 13 + rsaES-OAEP-ENV-OID (PKCS#1 v2.0) 14 + des-ede3-cbc-Env-OID 15 + + These mappings are provided so that a client may send the + appropriate enctypes in the AS-REQ message in order to indicate + support for the corresponding OIDs (for performing PKINIT). + + In many cases, PKINIT requires the encoding of an X.500 name as a + Realm. In these cases, the realm will be represented using a + different style, specified in RFC 1510 with the following example: + + NAMETYPE:rest/of.name=without-restrictions + + For a realm derived from an X.500 name, NAMETYPE will have the value + X500-RFC2253. The full realm name will appear as follows: + + X500-RFC2253:RFC2253Encode(DistinguishedName) + + where DistinguishedName is an X.500 name, and RFC2253Encode is a + readable UTF encoding of an X.500 name, as defined by + RFC 2253 [14] (part of LDAPv3). + + To ensure that this encoding is unique, we add the following rule + to those specified by RFC 2253: + + The order in which the attributes appear in the RFC 2253 + encoding must be the reverse of the order in the ASN.1 + encoding of the X.500 name that appears in the public key + certificate. The order of the relative distinguished names + (RDNs), as well as the order of the AttributeTypeAndValues + within each RDN, will be reversed. (This is despite the fact + that an RDN is defined as a SET of AttributeTypeAndValues, where + an order is normally not important.) + + Similarly, PKINIT may require the encoding of an X.500 name as a + PrincipalName. In these cases, the name-type of the principal name + shall be set to KRB_NT-X500-PRINCIPAL. This new name type is + defined as: + + KRB_NT_X500_PRINCIPAL 6 + + The name-string shall be set as follows: + + RFC2253Encode(DistinguishedName) + + as described above. + + RFC 1510 specifies the ASN.1 structure for PrincipalName as follows: + + PrincipalName ::= SEQUENCE { + name-type[0] INTEGER, + name-string[1] SEQUENCE OF GeneralString + } + + For the purposes of encoding an X.500 name within this structure, + the name-string shall be encoded as a single GeneralString. + + Note that name mapping may be required or optional based on + policy. + +3.1.1. Encryption and Key Formats + + In the exposition below, we use the terms public key and private + key generically. It should be understood that the term "public + key" may be used to refer to either a public encryption key or a + signature verification key, and that the term "private key" may be + used to refer to either a private decryption key or a signature + generation key. The fact that these are logically distinct does + not preclude the assignment of bitwise identical keys. + + In the case of Diffie-Hellman, the key shall be produced from the + agreed bit string as follows: + + * Truncate the bit string to the appropriate length. + * Rectify parity in each byte (if necessary) to obtain the key. + + For instance, in the case of a DES key, we take the first eight + bytes of the bit stream, and then adjust the least significant bit + of each byte to ensure that each byte has odd parity. + +3.1.2. Algorithm Identifiers + + PKINIT does not define, but does permit, the algorithm identifiers + listed below. + +3.1.2.1. Signature Algorithm Identifiers + + The following signature algorithm identifiers specified in [11] and + in [15] shall be used with PKINIT: + + id-dsa-with-sha1 (DSA with SHA1) + md5WithRSAEncryption (RSA with MD5) + sha-1WithRSAEncryption (RSA with SHA1) + +3.1.2.2 Diffie-Hellman Key Agreement Algorithm Identifier + + The following algorithm identifier shall be used within the + SubjectPublicKeyInfo data structure: dhpublicnumber + + This identifier and the associated algorithm parameters are + specified in RFC 2459 [15]. + +3.1.2.3. Algorithm Identifiers for RSA Encryption + + These algorithm identifiers are used inside the EnvelopedData data + structure, for encrypting the temporary key with a public key: + + rsaEncryption (RSA encryption, PKCS#1 v1.5) + id-RSAES-OAEP (RSA encryption, PKCS#1 v2.0) + + Both of the above RSA encryption schemes are specified in [16]. + Currently, only PKCS#1 v1.5 is specified by CMS [11], although the + CMS specification says that it will likely include PKCS#1 v2.0 in + the future. (PKCS#1 v2.0 addresses adaptive chosen ciphertext + vulnerability discovered in PKCS#1 v1.5.) + +3.1.2.4. Algorithm Identifiers for Encryption with Secret Keys + + These algorithm identifiers are used inside the EnvelopedData data + structure in the PKINIT Reply, for encrypting the reply key with the + temporary key: + des-ede3-cbc (3-key 3-DES, CBC mode) + rc2-cbc (RC2, CBC mode) + + The full definition of the above algorithm identifiers and their + corresponding parameters (an IV for block chaining) is provided in + the CMS specification [11]. + +3.2. Public Key Authentication + + Implementation of the changes in this section is REQUIRED for + compliance with PKINIT. + + It is assumed that all public keys are signed by some certification + authority (CA). The initial authentication request is sent as per + RFC 1510, except that a preauthentication field containing data + signed by the user's private key accompanies the request: + + PA-PK-AS-REQ ::= SEQUENCE { + -- PA TYPE 14 + signedAuthPack [0] SignedData + -- defined in CMS [11] + -- AuthPack (below) defines the data + -- that is signed + trustedCertifiers [1] SEQUENCE OF TrustedCas OPTIONAL, + -- CAs that the client trusts + kdcCert [2] IssuerAndSerialNumber OPTIONAL + -- as defined in CMS [11] + -- specifies a particular KDC + -- certificate if the client + -- already has it; + -- must be accompanied by + -- a single trustedCertifier + encryptionCert [3] IssuerAndSerialNumber OPTIONAL + -- For example, this may be the + -- client's Diffie-Hellman + -- certificate, or it may be the + -- client's RSA encryption + -- certificate. + } + + TrustedCas ::= CHOICE { + principalName [0] KerberosName, + -- as defined below + caName [1] Name + -- fully qualified X.500 name + -- as defined by X.509 + issuerAndSerial [2] IssuerAndSerialNumber OPTIONAL + -- Since a CA may have a number of + -- certificates, only one of which + -- a client trusts + } + + Usage of SignedData: + The SignedData data type is specified in the Cryptographic + Message Syntax, a product of the S/MIME working group of the IETF. + - The encapContentInfo field must contain the PKAuthenticator + and, optionally, the client's Diffie Hellman public value. + - The eContentType field shall contain the OID value for + id-data: iso(1) member-body(2) us(840) rsadsi(113549) + pkcs(1) pkcs7(7) data(1) + - The eContent field is data of the type AuthPack (below). + - The signerInfos field contains the signature of AuthPack. + - The Certificates field, when non-empty, contains the client's + certificate chain. If present, the KDC uses the public key from + the client's certificate to verify the signature in the request. + Note that the client may pass different certificates that are used + for signing or for encrypting. Thus, the KDC may utilize a + different client certificate for signature verification than the + one it uses to encrypt the reply to the client. For example, the + client may place a Diffie-Hellman certificate in this field in + order to convey its static Diffie Hellman certificate to the KDC + enable static-ephemeral Diffie-Hellman mode for the reply. As + another example, the client may place an RSA encryption + certificate in this field. + + AuthPack ::= SEQUENCE { + pkAuthenticator [0] PKAuthenticator, + clientPublicValue [1] SubjectPublicKeyInfo OPTIONAL + -- if client is using Diffie-Hellman + } + + PKAuthenticator ::= SEQUENCE { + kdcName [0] PrincipalName, + kdcRealm [1] Realm, + cusec [2] INTEGER, + -- for replay prevention + ctime [3] KerberosTime, + -- for replay prevention + nonce [4] INTEGER + } + + SubjectPublicKeyInfo ::= SEQUENCE { + algorithm AlgorithmIdentifier, + -- dhKeyAgreement + subjectPublicKey BIT STRING + -- for DH, equals + -- public exponent (INTEGER encoded + -- as payload of BIT STRING) + } -- as specified by the X.509 recommendation [10] + + AlgorithmIdentifier ::= SEQUENCE { + algorithm ALGORITHM.&id, + parameters ALGORITHM.&type + } -- as specified by the X.509 recommendation [10] + + If the client passes an issuer and serial number in the request, + the KDC is requested to use the referred-to certificate. If none + exists, then the KDC returns an error of type + KDC_ERR_CERTIFICATE_MISMATCH. It also returns this error if, on the + other hand, the client does not pass any trustedCertifiers, + believing that it has the KDC's certificate, but the KDC has more + than one certificate. The KDC should include information in the + KRB-ERROR message that indicates the KDC certificate(s) that a + client may utilize. This data is specified in the e-data, which + is defined in RFC 1510 revisions as a SEQUENCE of TypedData: + + TypedData ::= SEQUENCE { + data-type [0] INTEGER, + data-value [1] OCTET STRING, + } -- per Kerberos RFC 1510 revisions + + where: + data-type = TD-PKINIT-CMS-CERTIFICATES = 101 + data-value = CertificateSet // as specified by CMS [11] + + The PKAuthenticator carries information to foil replay attacks, + to bind the request and response. The PKAuthenticator is signed + with the private key corresponding to the public key in the + certificate found in userCert (or cached by the KDC). + + The trustedCertifiers field contains a list of certification + authorities trusted by the client, in the case that the client does + not possess the KDC's public key certificate. If the KDC has no + certificate signed by any of the trustedCertifiers, then it returns + an error of type KDC_ERR_KDC_NOT_TRUSTED. + + KDCs should try to (in order of preference): + 1. Use the KDC certificate identified by the serialNumber included + in the client's request. + 2. Use a certificate issued to the KDC by the client's CA (if in the + middle of a CA key roll-over, use the KDC cert issued under same + CA key as user cert used to verify request). + 3. Use a certificate issued to the KDC by one of the client's + trustedCertifier(s); + If the KDC is unable to comply with any of these options, then the + KDC returns an error message of type KDC_ERR_KDC_NOT_TRUSTED to the + client. + + Upon receipt of the AS_REQ with PA-PK-AS-REQ pre-authentication + type, the KDC attempts to verify the user's certificate chain + (userCert), if one is provided in the request. This is done by + verifying the certification path against the KDC's policy of + legitimate certifiers. This may be based on a certification + hierarchy, or it may be simply a list of recognized certifiers in a + system like PGP. + + If the client's certificate chain contains no certificate signed by + a CA trusted by the KDC, then the KDC sends back an error message + of type KDC_ERR_CANT_VERIFY_CERTIFICATE. The accompanying e-data + is a SEQUENCE of one TypedData (with type TD-TRUSTED-CERTIFIERS=104) + whose data-value is an OCTET STRING which is the DER encoding of + + TrustedCertifiers ::= SEQUENCE OF PrincipalName + -- X.500 name encoded as a principal name + -- see Section 3.1 + + If the signature on one of the certificates in the client's chain + fails verification, then the KDC returns an error of type + KDC_ERR_INVALID_CERTIFICATE. The accompanying e-data is a SEQUENCE + of one TypedData (with type TD-CERTIFICATE-INDEX=105) whose + data-value is an OCTET STRING which is the DER encoding of + + CertificateIndex ::= INTEGER + -- 0 = 1st certificate, + -- (in order of encoding) + -- 1 = 2nd certificate, etc + + The KDC may also check whether any of the certificates in the + client's chain has been revoked. If one of the certificates has + been revoked, then the KDC returns an error of type + KDC_ERR_REVOKED_CERTIFICATE; if such a query reveals that the + certificate's revocation status is unknown, the KDC returns an + error of type KDC_ERR_REVOCATION_STATUS_UNKNOWN; if the revocation + status is unavailable, the KDC returns an error of type + KDC_ERR_REVOCATION_STATUS_UNAVAILABLE. In any of these three + cases, the affected certificate is identified by the accompanying + e-data, which contains a CertificateIndex as described for + KDC_ERR_INVALID_CERTIFICATE. + + If the certificate chain can be verified, but the name of the + client in the certificate does not match the client's name in the + request, then the KDC returns an error of type + KDC_ERR_CLIENT_NAME_MISMATCH. There is no accompanying e-data + field in this case. + + Finally, if the certificate chain is verified, but the KDC's name + or realm as given in the PKAuthenticator does not match the KDC's + actual principal name, then the KDC returns an error of type + KDC_ERR_KDC_NAME_MISMATCH. The accompanying e-data field is again + a SEQUENCE of one TypedData (with type TD-KRB-PRINCIPAL=102 or + TD-KRB-REALM=103 as appropriate) whose data-value is an OCTET + STRING whose data-value is the DER encoding of a PrincipalName or + Realm as defined in RFC 1510 revisions. + + Even if all succeeds, the KDC may--for policy reasons--decide not + to trust the client. In this case, the KDC returns an error message + of type KDC_ERR_CLIENT_NOT_TRUSTED. + + If a trust relationship exists, the KDC then verifies the client's + signature on AuthPack. If that fails, the KDC returns an error + message of type KDC_ERR_INVALID_SIG. Otherwise, the KDC uses the + timestamp (ctime and cusec) in the PKAuthenticator to assure that + the request is not a replay. The KDC also verifies that its name + is specified in the PKAuthenticator. + + If the clientPublicValue field is filled in, indicating that the + client wishes to use Diffie-Hellman key agreement, then the KDC + checks to see that the parameters satisfy its policy. If they do + not (e.g., the prime size is insufficient for the expected + encryption type), then the KDC sends back an error message of type + KDC_ERR_KEY_TOO_WEAK. Otherwise, it generates its own public and + private values for the response. + + The KDC also checks that the timestamp in the PKAuthenticator is + within the allowable window and that the principal name and realm + are correct. If the local (server) time and the client time in the + authenticator differ by more than the allowable clock skew, then the + KDC returns an error message of type KRB_AP_ERR_SKEW. + + Assuming no errors, the KDC replies as per RFC 1510, except as + follows. The user's name in the ticket is determined by the + following decision algorithm: + + 1. If the KDC has a mapping from the name in the certificate + to a Kerberos name, then use that name. + Else + 2. If the certificate contains a Kerberos name in an extension + field, and local KDC policy allows, then use that name. + Else + 3. Use the name as represented in the certificate, mapping + as necessary (e.g., as per RFC 2253 for X.500 names). In + this case the realm in the ticket shall be the name of the + certification authority that issued the user's certificate. + + The KDC encrypts the reply not with the user's long-term key, but + with a random key generated only for this particular response. This + random key is sealed in the preauthentication field: + + PA-PK-AS-REP ::= CHOICE { + -- PA TYPE 15 + dhSignedData [0] SignedData, + -- Defined in CMS and used only with + -- Diffie-Helman key exchange + -- This choice MUST be supported + -- by compliant implementations. + encKeyPack [1] EnvelopedData, + -- Defined in CMS + -- The temporary key is encrypted + -- using the client public key + -- key + -- SignedReplyKeyPack, encrypted + -- with the temporary key, is also + -- included. + } + + Usage of SignedData: + If the Diffie-Hellman option is used, dhSignedData in PA-PK-AS-REP + provides authenticated Diffie-Hellman parameters of the KDC. The + reply key used to encrypt part of the KDC reply message is derived + from the Diffie-Hellman exchange: + - Both the KDC and the client calculate a secret value (g^ab mod p), + where a is the client's private exponent and b is the KDC's + private exponent. + - Both the KDC and the client take the first N bits of this secret + value and convert it into a reply key. N depends on the reply key + type. + - If the reply key is DES, N=64 bits, where some of the bits are + replaced with parity bits, according to FIPS PUB 74. + - If the reply key is (3-key) 3-DES, N=192 bits, where some of the + bits are replaced with parity bits, according to FIPS PUB 74. + - The encapContentInfo field must contain the KdcDHKeyInfo as + defined below. + - The eContentType field shall contain the OID value for + id-data: iso(1) member-body(2) us(840) rsadsi(113549) + pkcs(1) pkcs7(7) data(1) + - The certificates field must contain the certificates necessary + for the client to establish trust in the KDC's certificate + based on the list of trusted certifiers sent by the client in + the PA-PK-AS-REQ. This field may be empty if the client did + not send to the KDC a list of trusted certifiers (the + trustedCertifiers field was empty, meaning that the client + already possesses the KDC's certificate). + - The signerInfos field is a SET that must contain at least one + member, since it contains the actual signature. + + Usage of EnvelopedData: + The EnvelopedData data type is specified in the Cryptographic + Message Syntax, a product of the S/MIME working group of the IETF. + It contains an temporary key encrypted with the PKINIT + client's public key. It also contains a signed and encrypted + reply key. + - The originatorInfo field is not required, since that information + may be presented in the signedData structure that is encrypted + within the encryptedContentInfo field. + - The optional unprotectedAttrs field is not required for PKINIT. + - The recipientInfos field is a SET which must contain exactly one + member of the KeyTransRecipientInfo type for encryption + with an RSA public key. + - The encryptedKey field (in KeyTransRecipientInfo) contains + the temporary key which is encrypted with the PKINIT client's + public key. + - The encryptedContentInfo field contains the signed and encrypted + reply key. + - The contentType field shall contain the OID value for + id-signedData: iso(1) member-body(2) us(840) rsadsi(113549) + pkcs(1) pkcs7(7) signedData(2) + - The encryptedContent field is encrypted data of the CMS type + signedData as specified below. + - The encapContentInfo field must contains the ReplyKeyPack. + - The eContentType field shall contain the OID value for + id-data: iso(1) member-body(2) us(840) rsadsi(113549) + pkcs(1) pkcs7(7) data(1) + - The eContent field is data of the type ReplyKeyPack (below). + - The certificates field must contain the certificates necessary + for the client to establish trust in the KDC's certificate + based on the list of trusted certifiers sent by the client in + the PA-PK-AS-REQ. This field may be empty if the client did + not send to the KDC a list of trusted certifiers (the + trustedCertifiers field was empty, meaning that the client + already possesses the KDC's certificate). + - The signerInfos field is a SET that must contain at least one + member, since it contains the actual signature. + + KdcDHKeyInfo ::= SEQUENCE { + -- used only when utilizing Diffie-Hellman + nonce [0] INTEGER, + -- binds responce to the request + subjectPublicKey [2] BIT STRING + -- Equals public exponent (g^a mod p) + -- INTEGER encoded as payload of + -- BIT STRING + } + + ReplyKeyPack ::= SEQUENCE { + -- not used for Diffie-Hellman + replyKey [0] EncryptionKey, + -- used to encrypt main reply + -- ENCTYPE is at least as strong as + -- ENCTYPE of session key + nonce [1] INTEGER, + -- binds response to the request + -- must be same as the nonce + -- passed in the PKAuthenticator + } + + + Since each certifier in the certification path of a user's + certificate is essentially a separate realm, the name of each + certifier must be added to the transited field of the ticket. The + format of these realm names is defined in Section 3.1 of this + document. If applicable, the transit-policy-checked flag should be + set in the issued ticket. + + The KDC's certificate must bind the public key to a name derivable + from the name of the realm for that KDC. X.509 certificates shall + contain the principal name of the KDC as the SubjectAltName version + 3 extension. Below is the definition of this version 3 extension, as + specified by the X.509 standard: + + subjectAltName EXTENSION ::= { + SYNTAX GeneralNames + IDENTIFIED BY id-ce-subjectAltName + } + + GeneralNames ::= SEQUENCE SIZE(1..MAX) OF GeneralName + + GeneralName ::= CHOICE { + otherName [0] INSTANCE OF OTHER-NAME, + ... + } + + OTHER-NAME ::= TYPE-IDENTIFIER + + In this definition, otherName is a name of any form defined as an + instance of the OTHER-NAME information object class. For the purpose + of specifying a Kerberos principal name, INSTANCE OF OTHER-NAME will + be chosen and replaced by the type KerberosName: + + KerberosName ::= SEQUENCE { + realm [0] Realm, + -- as define in RFC 1510 + principalName [1] PrincipalName, + -- as define in RFC 1510 + } + + This specific syntax is identified within subjectAltName by setting + the OID id-ce-subjectAltName to krb5PrincipalName, where (from the + Kerberos specification) we have + + krb5 OBJECT IDENTIFIER ::= { iso (1) + org (3) + dod (6) + internet (1) + security (5) + kerberosv5 (2) } + + krb5PrincipalName OBJECT IDENTIFIER ::= { krb5 2 } + + This specification may also be used to specify a Kerberos name + within the user's certificate. + + If a non-KDC X.509 certificate contains the principal name within + the subjectAltName version 3 extension , that name may utilize + KerberosName as defined below, or, in the case of an S/MIME + certificate [17], may utilize the email address. If the KDC + is presented with as S/MIME certificate, then the email address + within subjectAltName will be interpreted as a principal and realm + separated by the "@" sign, or as a name that needs to be + canonicalized. If the resulting name does not correspond to a + registered principal name, then the principal name is formed as + defined in section 3.1. + + The client then extracts the random key used to encrypt the main + reply. This random key (in encPaReply) is encrypted with either the + client's public key or with a key derived from the DH values + exchanged between the client and the KDC. + +3.2.2. Required Algorithms + + Not all of the algorithms in the PKINIT protocol specification have + to be implemented in order to comply with the proposed standard. + Below is a list of the required algorithms: + + - Diffie-Hellman public/private key pairs + - utilizing Diffie-Hellman ephemeral-ephemeral mode + - SHA1 digest and DSA for signatures + - 3-key triple DES keys derived from the Diffie-Hellman Exchange + - 3-key triple DES Temporary and Reply keys + +4. Logistics and Policy + + This section describes a way to define the policy on the use of + PKINIT for each principal and request. + + The KDC is not required to contain a database record for users + who use public key authentication. However, if these users are + registered with the KDC, it is recommended that the database record + for these users be modified to an additional flag in the attributes + field to indicate that the user should authenticate using PKINIT. + If this flag is set and a request message does not contain the + PKINIT preauthentication field, then the KDC sends back as error of + type KDC_ERR_PREAUTH_REQUIRED indicating that a preauthentication + field of type PA-PK-AS-REQ must be included in the request. + +5. Security Considerations + + PKINIT raises a few security considerations, which we will address + in this section. + + First of all, PKINIT introduces a new trust model, where KDCs do not + (necessarily) certify the identity of those for whom they issue + tickets. PKINIT does allow KDCs to act as their own CAs, in order + to simplify key management, but one of the additional benefits is to + align Kerberos authentication with a global public key + infrastructure. Anyone using PKINIT in this way must be aware of + how the certification infrastructure they are linking to works. + + Secondly, PKINIT also introduces the possibility of interactions + between different cryptosystems, which may be of widely varying + strengths. Many systems, for instance, allow the use of 512-bit + public keys. Using such keys to wrap data encrypted under strong + conventional cryptosystems, such as triple-DES, is inappropriate; + it adds a weak link to a strong one at extra cost. Implementors + and administrators should take care to avoid such wasteful and + deceptive interactions. + + Lastly, PKINIT calls for randomly generated keys for conventional + cryptosystems. Many such systems contain systematically "weak" + keys. PKINIT implementations MUST avoid use of these keys, either + by discarding those keys when they are generated, or by fixing them + in some way (e.g., by XORing them with a given mask). These + precautions vary from system to system; it is not our intention to + give an explicit recipe for them here. + +6. Transport Issues + + Certificate chains can potentially grow quite large and span several + UDP packets; this in turn increases the probability that a Kerberos + message involving PKINIT extensions will be broken in transit. In + light of the possibility that the Kerberos specification will + require KDCs to accept requests using TCP as a transport mechanism, + we make the same recommendation with respect to the PKINIT + extensions as well. + +7. Bibliography + + [1] J. Kohl, C. Neuman. The Kerberos Network Authentication Service + (V5). Request for Comments 1510. + + [2] B.C. Neuman, Theodore Ts'o. Kerberos: An Authentication Service + for Computer Networks, IEEE Communications, 32(9):33-38. September + 1994. + + [3] B. Tung, T. Ryutov, C. Neuman, G. Tsudik, B. Sommerfeld, + A. Medvinsky, M. Hur. Public Key Cryptography for Cross-Realm + Authentication in Kerberos. + draft-ietf-cat-kerberos-pk-cross-04.txt + + [4] A. Medvinsky, J. Cargille, M. Hur. Anonymous Credentials in + Kerberos. + draft-ietf-cat-kerberos-anoncred-00.txt + + [5] A. Medvinsky, M. Hur, B. Clifford Neuman. Public Key Utilizing + Tickets for Application Servers (PKTAPP). + draft-ietf-cat-pktapp-00.txt + + [6] M. Sirbu, J. Chuang. Distributed Authentication in Kerberos + Using Public Key Cryptography. Symposium On Network and Distributed + System Security, 1997. + + [7] B. Cox, J.D. Tygar, M. Sirbu. NetBill Security and Transaction + Protocol. In Proceedings of the USENIX Workshop on Electronic + Commerce, July 1995. + + [8] T. Dierks, C. Allen. The TLS Protocol, Version 1.0 + Request for Comments 2246, January 1999. + + [9] B.C. Neuman, Proxy-Based Authorization and Accounting for + Distributed Systems. In Proceedings of the 13th International + Conference on Distributed Computing Systems, May 1993. + + [10] ITU-T (formerly CCITT) Information technology - Open Systems + Interconnection - The Directory: Authentication Framework + Recommendation X.509 ISO/IEC 9594-8 + + [11] R. Housley. Cryptographic Message Syntax. + draft-ietf-smime-cms-13.txt, April 1999. + + [12] PKCS #7: Cryptographic Message Syntax Standard, + An RSA Laboratories Technical Note Version 1.5 + Revised November 1, 1993 + + [13] R. Rivest, MIT Laboratory for Computer Science and RSA Data + Security, Inc. A Description of the RC2(r) Encryption Algorithm + March 1998. + Request for Comments 2268. + + [14] M. Wahl, S. Kille, T. Howes. Lightweight Directory Access + Protocol (v3): UTF-8 String Representation of Distinguished Names. + Request for Comments 2253. + + [15] R. Housley, W. Ford, W. Polk, D. Solo. Internet X.509 Public + Key Infrastructure, Certificate and CRL Profile, January 1999. + Request for Comments 2459. + + [16] B. Kaliski, J. Staddon. PKCS #1: RSA Cryptography + Specifications, October 1998. + Request for Comments 2437. + + [17] S. Dusse, P. Hoffman, B. Ramsdell, J. Weinstein. + S/MIME Version 2 Certificate Handling, March 1998. + Request for Comments 2312 + +8. Acknowledgements + + Some of the ideas on which this proposal is based arose during + discussions over several years between members of the SAAG, the IETF + CAT working group, and the PSRG, regarding integration of Kerberos + and SPX. Some ideas have also been drawn from the DASS system. + These changes are by no means endorsed by these groups. This is an + attempt to revive some of the goals of those groups, and this + proposal approaches those goals primarily from the Kerberos + perspective. Lastly, comments from groups working on similar ideas + in DCE have been invaluable. + +9. Expiration Date + + This draft expires December 1, 1999. + +10. Authors + + Brian Tung + Clifford Neuman + USC Information Sciences Institute + 4676 Admiralty Way Suite 1001 + Marina del Rey CA 90292-6695 + Phone: +1 310 822 1511 + E-mail: {brian, bcn}@isi.edu + + Matthew Hur + CyberSafe Corporation + 1605 NW Sammamish Road + Issaquah WA 98027-5378 + Phone: +1 425 391 6000 + E-mail: matt.hur@cybersafe.com + + Ari Medvinsky + Excite + 555 Broadway + Redwood City, CA 94063 + Phone +1 650 569 2119 + E-mail: amedvins@excitecorp.com + + Sasha Medvinsky + General Instrument + 6450 Sequence Drive + San Diego, CA 92121 + Phone +1 619 404 2825 + E-mail: smedvinsky@gi.com + + John Wray + Iris Associates, Inc. + 5 Technology Park Dr. + Westford, MA 01886 + E-mail: John_Wray@iris.com + + Jonathan Trostle + 170 W. Tasman Dr. + San Jose, CA 95134 + E-mail: jtrostle@cisco.com diff --git a/doc/standardisation/draft-ietf-cat-kerberos-pk-init-10.txt b/doc/standardisation/draft-ietf-cat-kerberos-pk-init-10.txt new file mode 100644 index 000000000..7dcb06a60 --- /dev/null +++ b/doc/standardisation/draft-ietf-cat-kerberos-pk-init-10.txt @@ -0,0 +1,957 @@ +INTERNET-DRAFT Brian Tung +draft-ietf-cat-kerberos-pk-init-10.txt Clifford Neuman +Updates: RFC 1510 ISI +expires April 30, 2000 Matthew Hur + CyberSafe Corporation + Ari Medvinsky + Excite + Sasha Medvinsky + General Instrument + John Wray + Iris Associates, Inc. + Jonathan Trostle + Cisco + + Public Key Cryptography for Initial Authentication in Kerberos + +0. Status Of This Memo + + This document is an Internet-Draft and is in full conformance with + all provisions of Section 10 of RFC 2026. Internet-Drafts are + working documents of the Internet Engineering Task Force (IETF), + its areas, and its working groups. Note that other groups may also + distribute working documents as Internet-Drafts. + + Internet-Drafts are draft documents valid for a maximum of six + months and may be updated, replaced, or obsoleted by other + documents at any time. It is inappropriate to use Internet-Drafts + as reference material or to cite them other than as "work in + progress." + + The list of current Internet-Drafts can be accessed at + http://www.ietf.org/ietf/1id-abstracts.txt + + The list of Internet-Draft Shadow Directories can be accessed at + http://www.ietf.org/shadow.html. + + To learn the current status of any Internet-Draft, please check + the "1id-abstracts.txt" listing contained in the Internet-Drafts + Shadow Directories on ftp.ietf.org (US East Coast), + nic.nordu.net (Europe), ftp.isi.edu (US West Coast), or + munnari.oz.au (Pacific Rim). + + The distribution of this memo is unlimited. It is filed as + draft-ietf-cat-kerberos-pk-init-10.txt, and expires April 30, + 2000. Please send comments to the authors. + +1. Abstract + + This document defines extensions (PKINIT) to the Kerberos protocol + specification (RFC 1510 [1]) to provide a method for using public + key cryptography during initial authentication. The methods + defined specify the ways in which preauthentication data fields and + error data fields in Kerberos messages are to be used to transport + public key data. + +2. Introduction + + The popularity of public key cryptography has produced a desire for + its support in Kerberos [2]. The advantages provided by public key + cryptography include simplified key management (from the Kerberos + perspective) and the ability to leverage existing and developing + public key certification infrastructures. + + Public key cryptography can be integrated into Kerberos in a number + of ways. One is to associate a key pair with each realm, which can + then be used to facilitate cross-realm authentication; this is the + topic of another draft proposal. Another way is to allow users with + public key certificates to use them in initial authentication. This + is the concern of the current document. + + PKINIT utilizes ephemeral-ephemeral Diffie-Hellman keys in + combination with digital signature keys as the primary, required + mechanism. It also allows for the use of RSA keys and/or (static) + Diffie-Hellman certificates. Note in particular that PKINIT supports + the use of separate signature and encryption keys. + + PKINIT enables access to Kerberos-secured services based on initial + authentication utilizing public key cryptography. PKINIT utilizes + standard public key signature and encryption data formats within the + standard Kerberos messages. The basic mechanism is as follows: The + user sends an AS-REQ message to the KDC as before, except that if that + user is to use public key cryptography in the initial authentication + step, his certificate and a signature accompany the initial request + in the preauthentication fields. Upon receipt of this request, the + KDC verifies the certificate and issues a ticket granting ticket + (TGT) as before, except that the encPart from the AS-REP message + carrying the TGT is now encrypted utilizing either a Diffie-Hellman + derived key or the user's public key. This message is authenticated + utilizing the public key signature of the KDC. + + Note that PKINIT does not require the use of certificates. A KDC + may store the public key of a principal as part of that principal's + record. In this scenario, the KDC is the trusted party that vouches + for the principal (as in a standard, non-cross realm, Kerberos + environment). Thus, for any principal, the KDC may maintain a + secret key, a public key, or both. + + The PKINIT specification may also be used as a building block for + other specifications. PKCROSS [3] utilizes PKINIT for establishing + the inter-realm key and associated inter-realm policy to be applied + in issuing cross realm service tickets. As specified in [4], + anonymous Kerberos tickets can be issued by applying a NULL + signature in combination with Diffie-Hellman in the PKINIT exchange. + Additionally, the PKINIT specification may be used for direct peer + to peer authentication without contacting a central KDC. This + application of PKINIT is described in PKTAPP [5] and is based on + concepts introduced in [6, 7]. For direct client-to-server + authentication, the client uses PKINIT to authenticate to the end + server (instead of a central KDC), which then issues a ticket for + itself. This approach has an advantage over TLS [8] in that the + server does not need to save state (cache session keys). + Furthermore, an additional benefit is that Kerberos tickets can + facilitate delegation (see [9]). + +3. Proposed Extensions + + This section describes extensions to RFC 1510 for supporting the + use of public key cryptography in the initial request for a ticket + granting ticket (TGT). + + In summary, the following change to RFC 1510 is proposed: + + * Users may authenticate using either a public key pair or a + conventional (symmetric) key. If public key cryptography is + used, public key data is transported in preauthentication + data fields to help establish identity. The user presents + a public key certificate and obtains an ordinary TGT that may + be used for subsequent authentication, with such + authentication using only conventional cryptography. + + Section 3.1 provides definitions to help specify message formats. + Section 3.2 describes the extensions for the initial authentication + method. + +3.1. Definitions + + The extensions involve new preauthentication fields; we introduce + the following preauthentication types: + + PA-PK-AS-REQ 14 + PA-PK-AS-REP 15 + + The extensions also involve new error types; we introduce the + following types: + + KDC_ERR_CLIENT_NOT_TRUSTED 62 + KDC_ERR_KDC_NOT_TRUSTED 63 + KDC_ERR_INVALID_SIG 64 + KDC_ERR_KEY_TOO_WEAK 65 + KDC_ERR_CERTIFICATE_MISMATCH 66 + KDC_ERR_CANT_VERIFY_CERTIFICATE 70 + KDC_ERR_INVALID_CERTIFICATE 71 + KDC_ERR_REVOKED_CERTIFICATE 72 + KDC_ERR_REVOCATION_STATUS_UNKNOWN 73 + KDC_ERR_REVOCATION_STATUS_UNAVAILABLE 74 + KDC_ERR_CLIENT_NAME_MISMATCH 75 + KDC_ERR_KDC_NAME_MISMATCH 76 + + We utilize the following typed data for errors: + + TD-PKINIT-CMS-CERTIFICATES 101 + TD-KRB-PRINCIPAL 102 + TD-KRB-REALM 103 + TD-TRUSTED-CERTIFIERS 104 + TD-CERTIFICATE-INDEX 105 + + We utilize the following encryption types (which map directly to + OIDs): + + dsaWithSHA1-CmsOID 9 + md5WithRSAEncryption-CmsOID 10 + sha1WithRSAEncryption-CmsOID 11 + rc2CBC-EnvOID 12 + rsaEncryption-EnvOID (PKCS#1 v1.5) 13 + rsaES-OAEP-ENV-OID (PKCS#1 v2.0) 14 + des-ede3-cbc-Env-OID 15 + + These mappings are provided so that a client may send the + appropriate enctypes in the AS-REQ message in order to indicate + support for the corresponding OIDs (for performing PKINIT). + + In many cases, PKINIT requires the encoding of the X.500 name of a + certificate authority as a Realm. When such a name appears as + a ream it will be represented using the "other" form of the realm + name as specified in the naming constraints section of RFC1510. + For a realm derived from an X.500 name, NAMETYPE will have the value + X500-RFC2253. The full realm name will appear as follows: + + + ":" + + + where nametype is "X500-RFC2253" and string is the result of doing + an RFC2253 encoding of the distinguished name, i.e. + + "X500-RFC2253:" + RFC2253Encode(DistinguishedName) + + where DistinguishedName is an X.500 name, and RFC2253Encode is a + function returing a readable UTF encoding of an X.500 name, as + defined by RFC 2253 [14] (part of LDAPv3 [18]). + + To ensure that this encoding is unique, we add the following rule + to those specified by RFC 2253: + + The order in which the attributes appear in the RFC 2253 + encoding must be the reverse of the order in the ASN.1 + encoding of the X.500 name that appears in the public key + certificate. The order of the relative distinguished names + (RDNs), as well as the order of the AttributeTypeAndValues + within each RDN, will be reversed. (This is despite the fact + that an RDN is defined as a SET of AttributeTypeAndValues, where + an order is normally not important.) + + Similarly, in cases where the KDC does not provide a specific + policy based mapping from the X.500 name or X.509 Version 3 + SubjectAltName extension in the user's certificate to a Kerberos + principal name, PKINIT requires the direct encoding of the X.500 + name as a PrincipalName. In this case, the name-type of the + principal name shall be set to KRB_NT-X500-PRINCIPAL. This new + name type is defined in RFC 1510 as: + + KRB_NT_X500_PRINCIPAL 6 + + The name-string shall be set as follows: + + RFC2253Encode(DistinguishedName) + + as described above. When this name type is used, the principal's + realm shall be set to the certificate authority's distinguished + name using the X500-RFC2253 realm name format described earlier in + this section + + RFC 1510 specifies the ASN.1 structure for PrincipalName as follows: + + PrincipalName ::= SEQUENCE { + name-type[0] INTEGER, + name-string[1] SEQUENCE OF GeneralString + } + + For the purposes of encoding an X.500 name within this structure, + the name-string shall be encoded as a single GeneralString. + + Note that name mapping may be required or optional based on + policy. All names must conform to validity requirements as given + in RFC 1510. + +3.1.1. Encryption and Key Formats + + In the exposition below, we use the terms public key and private + key generically. It should be understood that the term "public + key" may be used to refer to either a public encryption key or a + signature verification key, and that the term "private key" may be + used to refer to either a private decryption key or a signature + generation key. The fact that these are logically distinct does + not preclude the assignment of bitwise identical keys for RSA + keys. + + In the case of Diffie-Hellman, the key shall be produced from the + agreed bit string as follows: + + * Truncate the bit string to the appropriate length. + * Rectify parity in each byte (if necessary) to obtain the key. + + For instance, in the case of a DES key, we take the first eight + bytes of the bit stream, and then adjust the least significant bit + of each byte to ensure that each byte has odd parity. + +3.1.2. Algorithm Identifiers + + PKINIT does not define, but does permit, the algorithm identifiers + listed below. + +3.1.2.1. Signature Algorithm Identifiers + + The following signature algorithm identifiers specified in [11] and + in [15] shall be used with PKINIT: + + id-dsa-with-sha1 (DSA with SHA1) + md5WithRSAEncryption (RSA with MD5) + sha-1WithRSAEncryption (RSA with SHA1) + +3.1.2.2 Diffie-Hellman Key Agreement Algorithm Identifier + + The following algorithm identifier shall be used within the + SubjectPublicKeyInfo data structure: dhpublicnumber + + This identifier and the associated algorithm parameters are + specified in RFC 2459 [15]. + +3.1.2.3. Algorithm Identifiers for RSA Encryption + + These algorithm identifiers are used inside the EnvelopedData data + structure, for encrypting the temporary key with a public key: + + rsaEncryption (RSA encryption, PKCS#1 v1.5) + id-RSAES-OAEP (RSA encryption, PKCS#1 v2.0) + + Both of the above RSA encryption schemes are specified in [16]. + Currently, only PKCS#1 v1.5 is specified by CMS [11], although the + CMS specification says that it will likely include PKCS#1 v2.0 in + the future. (PKCS#1 v2.0 addresses adaptive chosen ciphertext + vulnerability discovered in PKCS#1 v1.5.) + +3.1.2.4. Algorithm Identifiers for Encryption with Secret Keys + + These algorithm identifiers are used inside the EnvelopedData data + structure in the PKINIT Reply, for encrypting the reply key with the + temporary key: + des-ede3-cbc (3-key 3-DES, CBC mode) + rc2-cbc (RC2, CBC mode) + + The full definition of the above algorithm identifiers and their + corresponding parameters (an IV for block chaining) is provided in + the CMS specification [11]. + +3.2. Public Key Authentication + + Implementation of the changes in this section is REQUIRED for + compliance with PKINIT. + +3.2.1. Client Request + + Public keys may be signed by some certification authority (CA), or + they may be maintained by the KDC in which case the KDC is the + trusted authority. Note that the latter mode does not require the + use of certificates. + + The initial authentication request is sent as per RFC 1510, except + that a preauthentication field containing data signed by the user's + private key accompanies the request: + + PA-PK-AS-REQ ::= SEQUENCE { + -- PA TYPE 14 + signedAuthPack [0] SignedData + -- defined in CMS [11] + -- AuthPack (below) defines the data + -- that is signed + trustedCertifiers [1] SEQUENCE OF TrustedCas OPTIONAL, + -- CAs that the client trusts + kdcCert [2] IssuerAndSerialNumber OPTIONAL + -- as defined in CMS [11] + -- specifies a particular KDC + -- certificate if the client + -- already has it; + encryptionCert [3] IssuerAndSerialNumber OPTIONAL + -- For example, this may be the + -- client's Diffie-Hellman + -- certificate, or it may be the + -- client's RSA encryption + -- certificate. + } + + TrustedCas ::= CHOICE { + principalName [0] KerberosName, + -- as defined below + caName [1] Name + -- fully qualified X.500 name + -- as defined by X.509 + issuerAndSerial [2] IssuerAndSerialNumber + -- Since a CA may have a number of + -- certificates, only one of which + -- a client trusts + } + + Usage of SignedData: + The SignedData data type is specified in the Cryptographic + Message Syntax, a product of the S/MIME working group of the IETF. + - The encapContentInfo field must contain the PKAuthenticator + and, optionally, the client's Diffie Hellman public value. + - The eContentType field shall contain the OID value for + id-data: iso(1) member-body(2) us(840) rsadsi(113549) + pkcs(1) pkcs7(7) data(1) + - The eContent field is data of the type AuthPack (below). + - The signerInfos field contains the signature of AuthPack. + - The Certificates field, when non-empty, contains the client's + certificate chain. If present, the KDC uses the public key from + the client's certificate to verify the signature in the request. + Note that the client may pass different certificates that are used + for signing or for encrypting. Thus, the KDC may utilize a + different client certificate for signature verification than the + one it uses to encrypt the reply to the client. For example, the + client may place a Diffie-Hellman certificate in this field in + order to convey its static Diffie Hellman certificate to the KDC to + enable static-ephemeral Diffie-Hellman mode for the reply; in this + case, the client does NOT place its public value in the AuthPack + (defined below). As another example, the client may place an RSA + encryption certificate in this field. However, there must always + be (at least) a signature certificate. + + AuthPack ::= SEQUENCE { + pkAuthenticator [0] PKAuthenticator, + clientPublicValue [1] SubjectPublicKeyInfo OPTIONAL + -- if client is using Diffie-Hellman + -- (ephemeral-ephemeral only) + } + + PKAuthenticator ::= SEQUENCE { + kdcName [0] PrincipalName, + kdcRealm [1] Realm, + cusec [2] INTEGER, + -- for replay prevention as in RFC1510 + ctime [3] KerberosTime, + -- for replay prevention as in RFC1510 + nonce [4] INTEGER + } + + SubjectPublicKeyInfo ::= SEQUENCE { + algorithm AlgorithmIdentifier, + -- dhKeyAgreement + subjectPublicKey BIT STRING + -- for DH, equals + -- public exponent (INTEGER encoded + -- as payload of BIT STRING) + } -- as specified by the X.509 recommendation [10] + + AlgorithmIdentifier ::= SEQUENCE { + algorithm ALGORITHM.&id, + parameters ALGORITHM.&type + } -- as specified by the X.509 recommendation [10] + + If the client passes an issuer and serial number in the request, + the KDC is requested to use the referred-to certificate. If none + exists, then the KDC returns an error of type + KDC_ERR_CERTIFICATE_MISMATCH. It also returns this error if, on the + other hand, the client does not pass any trustedCertifiers, + believing that it has the KDC's certificate, but the KDC has more + than one certificate. The KDC should include information in the + KRB-ERROR message that indicates the KDC certificate(s) that a + client may utilize. This data is specified in the e-data, which + is defined in RFC 1510 revisions as a SEQUENCE of TypedData: + + TypedData ::= SEQUENCE { + data-type [0] INTEGER, + data-value [1] OCTET STRING, + } -- per Kerberos RFC 1510 revisions + + where: + data-type = TD-PKINIT-CMS-CERTIFICATES = 101 + data-value = CertificateSet // as specified by CMS [11] + + The PKAuthenticator carries information to foil replay attacks, and + to bind the request and response. The PKAuthenticator is signed + with the client's signature key. + +3.2.2. KDC Response + + Upon receipt of the AS_REQ with PA-PK-AS-REQ pre-authentication + type, the KDC attempts to verify the user's certificate chain + (userCert), if one is provided in the request. This is done by + verifying the certification path against the KDC's policy of + legitimate certifiers. This may be based on a certification + hierarchy, or it may be simply a list of recognized certifiers in a + system like PGP. + + If the client's certificate chain contains no certificate signed by + a CA trusted by the KDC, then the KDC sends back an error message + of type KDC_ERR_CANT_VERIFY_CERTIFICATE. The accompanying e-data + is a SEQUENCE of one TypedData (with type TD-TRUSTED-CERTIFIERS=104) + whose data-value is an OCTET STRING which is the DER encoding of + + TrustedCertifiers ::= SEQUENCE OF PrincipalName + -- X.500 name encoded as a principal name + -- see Section 3.1 + + If while verifying a certificate chain the KDC determines that the + signature on one of the certificates in the CertificateSet from + the signedAuthPack fails verification, then the KDC returns an + error of type KDC_ERR_INVALID_CERTIFICATE. The accompanying + e-data is a SEQUENCE of one TypedData (with type + TD-CERTIFICATE-INDEX=105) whose data-value is an OCTET STRING + which is the DER encoding of the index into the CertificateSet + ordered as sent by the client. + + CertificateIndex ::= INTEGER + -- 0 = 1st certificate, + -- (in order of encoding) + -- 1 = 2nd certificate, etc + + The KDC may also check whether any of the certificates in the + client's chain has been revoked. If one of the certificates has + been revoked, then the KDC returns an error of type + KDC_ERR_REVOKED_CERTIFICATE; if such a query reveals that + the certificate's revocation status is unknown or not + available, then if required by policy, the KDC returns the + appropriate error of type KDC_ERR_REVOCATION_STATUS_UNKNOWN or + KDC_ERR_REVOCATION_STATUS_UNAVAILABLE. In any of these three + cases, the affected certificate is identified by the accompanying + e-data, which contains a CertificateIndex as described for + KDC_ERR_INVALID_CERTIFICATE. + + If the certificate chain can be verified, but the name of the + client in the certificate does not match the client's name in the + request, then the KDC returns an error of type + KDC_ERR_CLIENT_NAME_MISMATCH. There is no accompanying e-data + field in this case. + + Finally, if the certificate chain is verified, but the KDC's name + or realm as given in the PKAuthenticator does not match the KDC's + actual principal name, then the KDC returns an error of type + KDC_ERR_KDC_NAME_MISMATCH. The accompanying e-data field is again + a SEQUENCE of one TypedData (with type TD-KRB-PRINCIPAL=102 or + TD-KRB-REALM=103 as appropriate) whose data-value is an OCTET + STRING whose data-value is the DER encoding of a PrincipalName or + Realm as defined in RFC 1510 revisions. + + Even if all succeeds, the KDC may--for policy reasons--decide not + to trust the client. In this case, the KDC returns an error message + of type KDC_ERR_CLIENT_NOT_TRUSTED. + + If a trust relationship exists, the KDC then verifies the client's + signature on AuthPack. If that fails, the KDC returns an error + message of type KDC_ERR_INVALID_SIG. Otherwise, the KDC uses the + timestamp (ctime and cusec) in the PKAuthenticator to assure that + the request is not a replay. The KDC also verifies that its name + is specified in the PKAuthenticator. + + If the clientPublicValue field is filled in, indicating that the + client wishes to use Diffie-Hellman key agreement, then the KDC + checks to see that the parameters satisfy its policy. If they do + not (e.g., the prime size is insufficient for the expected + encryption type), then the KDC sends back an error message of type + KDC_ERR_KEY_TOO_WEAK. Otherwise, it generates its own public and + private values for the response. + + The KDC also checks that the timestamp in the PKAuthenticator is + within the allowable window and that the principal name and realm + are correct. If the local (server) time and the client time in the + authenticator differ by more than the allowable clock skew, then the + KDC returns an error message of type KRB_AP_ERR_SKEW as defined in 1510. + + Assuming no errors, the KDC replies as per RFC 1510, except as + follows. The user's name in the ticket is determined by the + following decision algorithm: + + 1. If the KDC has a mapping from the name in the certificate + to a Kerberos name, then use that name. + Else + 2. If the certificate contains the SubjectAltName extention + and the local KDC policy defines a mapping from the + SubjectAltName to a Kerberos name, then use that name. + Else + 3. Use the name as represented in the certificate, mapping + mapping as necessary (e.g., as per RFC 2253 for X.500 + names). In this case the realm in the ticket shall be the + name of the certifier that issued the user's certificate. + + Note that a principal name may be carried in the subject alt name + field of a certificate. This name may be mapped to a principal + record in a security database based on local policy, for example + the subject alt name may be kerberos/principal@realm format. In + this case the realm name is not that of the CA but that of the + local realm doing the mapping (or some realm name chosen by that + realm). + + If a non-KDC X.509 certificate contains the principal name within + the subjectAltName version 3 extension , that name may utilize + KerberosName as defined below, or, in the case of an S/MIME + certificate [17], may utilize the email address. If the KDC + is presented with as S/MIME certificate, then the email address + within subjectAltName will be interpreted as a principal and realm + separated by the "@" sign, or as a name that needs to be + canonicalized. If the resulting name does not correspond to a + registered principal name, then the principal name is formed as + defined in section 3.1. + + The trustedCertifiers field contains a list of certification + authorities trusted by the client, in the case that the client does + not possess the KDC's public key certificate. If the KDC has no + certificate signed by any of the trustedCertifiers, then it returns + an error of type KDC_ERR_KDC_NOT_TRUSTED. + + KDCs should try to (in order of preference): + 1. Use the KDC certificate identified by the serialNumber included + in the client's request. + 2. Use a certificate issued to the KDC by the client's CA (if in the + middle of a CA key roll-over, use the KDC cert issued under same + CA key as user cert used to verify request). + 3. Use a certificate issued to the KDC by one of the client's + trustedCertifier(s); + If the KDC is unable to comply with any of these options, then the + KDC returns an error message of type KDC_ERR_KDC_NOT_TRUSTED to the + client. + + The KDC encrypts the reply not with the user's long-term key, but + with the Diffie Hellman derived key or a random key generated + for this particular response which is carried in the padata field of + the TGS-REP message. + + PA-PK-AS-REP ::= CHOICE { + -- PA TYPE 15 + dhSignedData [0] SignedData, + -- Defined in CMS and used only with + -- Diffie-Hellman key exchange (if the + -- client public value was present in the + -- request). + -- This choice MUST be supported + -- by compliant implementations. + encKeyPack [1] EnvelopedData, + -- Defined in CMS + -- The temporary key is encrypted + -- using the client public key + -- key + -- SignedReplyKeyPack, encrypted + -- with the temporary key, is also + -- included. + } + + Usage of SignedData: + If the Diffie-Hellman option is used, dhSignedData in PA-PK-AS-REP + provides authenticated Diffie-Hellman parameters of the KDC. The + reply key used to encrypt part of the KDC reply message is derived + from the Diffie-Hellman exchange: + - Both the KDC and the client calculate a secret value (g^ab mod p), + where a is the client's private exponent and b is the KDC's + private exponent. + - Both the KDC and the client take the first N bits of this secret + value and convert it into a reply key. N depends on the reply key + type. + - If the reply key is DES, N=64 bits, where some of the bits are + replaced with parity bits, according to FIPS PUB 74. + - If the reply key is (3-key) 3-DES, N=192 bits, where some of the + bits are replaced with parity bits, according to FIPS PUB 74. + - The encapContentInfo field must contain the KdcDHKeyInfo as + defined below. + - The eContentType field shall contain the OID value for + id-data: iso(1) member-body(2) us(840) rsadsi(113549) + pkcs(1) pkcs7(7) data(1) + - The certificates field must contain the certificates necessary + for the client to establish trust in the KDC's certificate + based on the list of trusted certifiers sent by the client in + the PA-PK-AS-REQ. This field may be empty if the client did + not send to the KDC a list of trusted certifiers (the + trustedCertifiers field was empty, meaning that the client + already possesses the KDC's certificate). + - The signerInfos field is a SET that must contain at least one + member, since it contains the actual signature. + + KdcDHKeyInfo ::= SEQUENCE { + -- used only when utilizing Diffie-Hellman + nonce [0] INTEGER, + -- binds responce to the request + subjectPublicKey [2] BIT STRING + -- Equals public exponent (g^a mod p) + -- INTEGER encoded as payload of + -- BIT STRING + } + + Usage of EnvelopedData: + The EnvelopedData data type is specified in the Cryptographic + Message Syntax, a product of the S/MIME working group of the IETF. + It contains an temporary key encrypted with the PKINIT + client's public key. It also contains a signed and encrypted + reply key. + - The originatorInfo field is not required, since that information + may be presented in the signedData structure that is encrypted + within the encryptedContentInfo field. + - The optional unprotectedAttrs field is not required for PKINIT. + - The recipientInfos field is a SET which must contain exactly one + member of the KeyTransRecipientInfo type for encryption + with an RSA public key. + - The encryptedKey field (in KeyTransRecipientInfo) contains + the temporary key which is encrypted with the PKINIT client's + public key. + - The encryptedContentInfo field contains the signed and encrypted + reply key. + - The contentType field shall contain the OID value for + id-signedData: iso(1) member-body(2) us(840) rsadsi(113549) + pkcs(1) pkcs7(7) signedData(2) + - The encryptedContent field is encrypted data of the CMS type + signedData as specified below. + - The encapContentInfo field must contains the ReplyKeyPack. + - The eContentType field shall contain the OID value for + id-data: iso(1) member-body(2) us(840) rsadsi(113549) + pkcs(1) pkcs7(7) data(1) + - The eContent field is data of the type ReplyKeyPack (below). + - The certificates field must contain the certificates necessary + for the client to establish trust in the KDC's certificate + based on the list of trusted certifiers sent by the client in + the PA-PK-AS-REQ. This field may be empty if the client did + not send to the KDC a list of trusted certifiers (the + trustedCertifiers field was empty, meaning that the client + already possesses the KDC's certificate). + - The signerInfos field is a SET that must contain at least one + member, since it contains the actual signature. + + ReplyKeyPack ::= SEQUENCE { + -- not used for Diffie-Hellman + replyKey [0] EncryptionKey, + -- used to encrypt main reply + -- ENCTYPE is at least as strong as + -- ENCTYPE of session key + nonce [1] INTEGER, + -- binds response to the request + -- must be same as the nonce + -- passed in the PKAuthenticator + } + + Since each certifier in the certification path of a user's + certificate is equivalent to a separate Kerberos realm, the name + of each certifier in the certificate chain must be added to the + transited field of the ticket. The format of these realm names is + defined in Section 3.1 of this document. If applicable, the + transit-policy-checked flag should be set in the issued ticket. + + The KDC's certificate(s) must bind the public key(s) of the KDC to + a name derivable from the name of the realm for that KDC. X.509 + certificates shall contain the principal name of the KDC + (defined in section 8.2 of RFC 1510) as the SubjectAltName version + 3 extension. Below is the definition of this version 3 extension, + as specified by the X.509 standard: + + subjectAltName EXTENSION ::= { + SYNTAX GeneralNames + IDENTIFIED BY id-ce-subjectAltName + } + + GeneralNames ::= SEQUENCE SIZE(1..MAX) OF GeneralName + + GeneralName ::= CHOICE { + otherName [0] INSTANCE OF OTHER-NAME, + ... + } + + OTHER-NAME ::= TYPE-IDENTIFIER + + In this definition, otherName is a name of any form defined as an + instance of the OTHER-NAME information object class. For the purpose + of specifying a Kerberos principal name, INSTANCE OF OTHER-NAME will + be chosen and replaced by the type KerberosName: + + KerberosName ::= SEQUENCE { + realm [0] Realm, + -- as defined in RFC 1510 + principalName [1] PrincipalName, + -- as defined in RFC 1510 + } + + This specific syntax is identified within subjectAltName by setting + the OID id-ce-subjectAltName to krb5PrincipalName, where (from the + Kerberos specification) we have + + krb5 OBJECT IDENTIFIER ::= { iso (1) + org (3) + dod (6) + internet (1) + security (5) + kerberosv5 (2) } + + krb5PrincipalName OBJECT IDENTIFIER ::= { krb5 2 } + + (This specification may also be used to specify a Kerberos name + within the user's certificate.) The KDC's certificate may be signed + directly by a CA, or there may be intermediaries if the server resides + within a large organization, or it may be unsigned if the client + indicates possession (and trust) of the KDC's certificate. + + The client then extracts the random key used to encrypt the main + reply. This random key (in encPaReply) is encrypted with either the + client's public key or with a key derived from the DH values + exchanged between the client and the KDC. The client uses this + random key to decrypt the main reply, and subsequently proceeds as + described in RFC 1510. + +3.2.3. Required Algorithms + + Not all of the algorithms in the PKINIT protocol specification have + to be implemented in order to comply with the proposed standard. + Below is a list of the required algorithms: + + - Diffie-Hellman public/private key pairs + - utilizing Diffie-Hellman ephemeral-ephemeral mode + - SHA1 digest and DSA for signatures + - 3-key triple DES keys derived from the Diffie-Hellman Exchange + - 3-key triple DES Temporary and Reply keys + +4. Logistics and Policy + + This section describes a way to define the policy on the use of + PKINIT for each principal and request. + + The KDC is not required to contain a database record for users + who use public key authentication. However, if these users are + registered with the KDC, it is recommended that the database record + for these users be modified to an additional flag in the attributes + field to indicate that the user should authenticate using PKINIT. + If this flag is set and a request message does not contain the + PKINIT preauthentication field, then the KDC sends back as error of + type KDC_ERR_PREAUTH_REQUIRED indicating that a preauthentication + field of type PA-PK-AS-REQ must be included in the request. + +5. Security Considerations + + PKINIT raises a few security considerations, which we will address + in this section. + + First of all, PKINIT introduces a new trust model, where KDCs do not + (necessarily) certify the identity of those for whom they issue + tickets. PKINIT does allow KDCs to act as their own CAs, in order + to simplify key management, but one of the additional benefits is to + align Kerberos authentication with a global public key + infrastructure. Anyone using PKINIT in this way must be aware of + how the certification infrastructure they are linking to works. + + Secondly, PKINIT also introduces the possibility of interactions + between different cryptosystems, which may be of widely varying + strengths. Many systems, for instance, allow the use of 512-bit + public keys. Using such keys to wrap data encrypted under strong + conventional cryptosystems, such as triple-DES, is inappropriate; + it adds a weak link to a strong one at extra cost. Implementors + and administrators should take care to avoid such wasteful and + deceptive interactions. + + Lastly, PKINIT calls for randomly generated keys for conventional + cryptosystems. Many such systems contain systematically "weak" + keys. PKINIT implementations MUST avoid use of these keys, either + by discarding those keys when they are generated, or by fixing them + in some way (e.g., by XORing them with a given mask). These + precautions vary from system to system; it is not our intention to + give an explicit recipe for them here. + +6. Transport Issues + + Certificate chains can potentially grow quite large and span several + UDP packets; this in turn increases the probability that a Kerberos + message involving PKINIT extensions will be broken in transit. In + light of the possibility that the Kerberos specification will + require KDCs to accept requests using TCP as a transport mechanism, + we make the same recommendation with respect to the PKINIT + extensions as well. + +7. Bibliography + + [1] J. Kohl, C. Neuman. The Kerberos Network Authentication Service + (V5). Request for Comments 1510. + + [2] B.C. Neuman, Theodore Ts'o. Kerberos: An Authentication Service + for Computer Networks, IEEE Communications, 32(9):33-38. September + 1994. + + [3] B. Tung, T. Ryutov, C. Neuman, G. Tsudik, B. Sommerfeld, + A. Medvinsky, M. Hur. Public Key Cryptography for Cross-Realm + Authentication in Kerberos. + draft-ietf-cat-kerberos-pk-cross-04.txt + + [4] A. Medvinsky, J. Cargille, M. Hur. Anonymous Credentials in + Kerberos. + draft-ietf-cat-kerberos-anoncred-00.txt + + [5] A. Medvinsky, M. Hur, B. Clifford Neuman. Public Key Utilizing + Tickets for Application Servers (PKTAPP). + draft-ietf-cat-pktapp-00.txt + + [6] M. Sirbu, J. Chuang. Distributed Authentication in Kerberos + Using Public Key Cryptography. Symposium On Network and Distributed + System Security, 1997. + + [7] B. Cox, J.D. Tygar, M. Sirbu. NetBill Security and Transaction + Protocol. In Proceedings of the USENIX Workshop on Electronic + Commerce, July 1995. + + [8] T. Dierks, C. Allen. The TLS Protocol, Version 1.0 + Request for Comments 2246, January 1999. + + [9] B.C. Neuman, Proxy-Based Authorization and Accounting for + Distributed Systems. In Proceedings of the 13th International + Conference on Distributed Computing Systems, May 1993. + + [10] ITU-T (formerly CCITT) Information technology - Open Systems + Interconnection - The Directory: Authentication Framework + Recommendation X.509 ISO/IEC 9594-8 + + [11] R. Housley. Cryptographic Message Syntax. + draft-ietf-smime-cms-13.txt, April 1999, approved for publication + as RFC. + + [12] PKCS #7: Cryptographic Message Syntax Standard, + An RSA Laboratories Technical Note Version 1.5 + Revised November 1, 1993 + + [13] R. Rivest, MIT Laboratory for Computer Science and RSA Data + Security, Inc. A Description of the RC2(r) Encryption Algorithm + March 1998. + Request for Comments 2268. + + [14] M. Wahl, S. Kille, T. Howes. Lightweight Directory Access + Protocol (v3): UTF-8 String Representation of Distinguished Names. + Request for Comments 2253. + + [15] R. Housley, W. Ford, W. Polk, D. Solo. Internet X.509 Public + Key Infrastructure, Certificate and CRL Profile, January 1999. + Request for Comments 2459. + + [16] B. Kaliski, J. Staddon. PKCS #1: RSA Cryptography + Specifications, October 1998. Request for Comments 2437. + + [17] S. Dusse, P. Hoffman, B. Ramsdell, J. Weinstein. S/MIME + Version 2 Certificate Handling, March 1998. Request for + Comments 2312. + + [18] M. Wahl, T. Howes, S. Kille. Lightweight Directory Access + Protocol (v3), December 1997. Request for Comments 2251. + +8. Acknowledgements + + Some of the ideas on which this proposal is based arose during + discussions over several years between members of the SAAG, the IETF + CAT working group, and the PSRG, regarding integration of Kerberos + and SPX. Some ideas have also been drawn from the DASS system. + These changes are by no means endorsed by these groups. This is an + attempt to revive some of the goals of those groups, and this + proposal approaches those goals primarily from the Kerberos + perspective. Lastly, comments from groups working on similar ideas + in DCE have been invaluable. + +9. Expiration Date + + This draft expires April 30, 2000. + +10. Authors + + Brian Tung + Clifford Neuman + USC Information Sciences Institute + 4676 Admiralty Way Suite 1001 + Marina del Rey CA 90292-6695 + Phone: +1 310 822 1511 + E-mail: {brian, bcn}@isi.edu + + Matthew Hur + CyberSafe Corporation + 1605 NW Sammamish Road + Issaquah WA 98027-5378 + Phone: +1 425 391 6000 + E-mail: matt.hur@cybersafe.com + + Ari Medvinsky + Excite + 555 Broadway + Redwood City, CA 94063 + Phone +1 650 569 2119 + E-mail: amedvins@excitecorp.com + + Sasha Medvinsky + General Instrument + 6450 Sequence Drive + San Diego, CA 92121 + Phone +1 619 404 2825 + E-mail: smedvinsky@gi.com + + John Wray + Iris Associates, Inc. + 5 Technology Park Dr. + Westford, MA 01886 + E-mail: John_Wray@iris.com + + Jonathan Trostle + 170 W. Tasman Dr. + San Jose, CA 95134 + E-mail: jtrostle@cisco.com diff --git a/doc/standardisation/draft-ietf-cat-kerberos-pk-init-13.txt b/doc/standardisation/draft-ietf-cat-kerberos-pk-init-13.txt new file mode 100644 index 000000000..1bcc2ad45 --- /dev/null +++ b/doc/standardisation/draft-ietf-cat-kerberos-pk-init-13.txt @@ -0,0 +1,1062 @@ +INTERNET-DRAFT Brian Tung +draft-ietf-cat-kerberos-pk-init-13.txt Clifford Neuman +Updates: RFC 1510 USC/ISI +expires August 31, 2001 Matthew Hur + Cisco + Ari Medvinsky + Keen.com, Inc. + Sasha Medvinsky + Motorola + John Wray + Iris Associates, Inc. + Jonathan Trostle + Cisco + + Public Key Cryptography for Initial Authentication in Kerberos + +0. Status Of This Memo + + This document is an Internet-Draft and is in full conformance with + all provisions of Section 10 of RFC 2026. Internet-Drafts are + working documents of the Internet Engineering Task Force (IETF), + its areas, and its working groups. Note that other groups may also + distribute working documents as Internet-Drafts. + + Internet-Drafts are draft documents valid for a maximum of six + months and may be updated, replaced, or obsoleted by other + documents at any time. It is inappropriate to use Internet-Drafts + as reference material or to cite them other than as "work in + progress." + + The list of current Internet-Drafts can be accessed at + http://www.ietf.org/ietf/1id-abstracts.txt + + The list of Internet-Draft Shadow Directories can be accessed at + http://www.ietf.org/shadow.html. + + To learn the current status of any Internet-Draft, please check + the "1id-abstracts.txt" listing contained in the Internet-Drafts + Shadow Directories on ftp.ietf.org (US East Coast), + nic.nordu.net (Europe), ftp.isi.edu (US West Coast), or + munnari.oz.au (Pacific Rim). + + The distribution of this memo is unlimited. It is filed as + draft-ietf-cat-kerberos-pk-init-11.txt, and expires August 31, + 2001. Please send comments to the authors. + +1. Abstract + + This document defines extensions (PKINIT) to the Kerberos protocol + specification (RFC 1510 [1]) to provide a method for using public + key cryptography during initial authentication. The methods + defined specify the ways in which preauthentication data fields and + error data fields in Kerberos messages are to be used to transport + public key data. + +2. Introduction + + The popularity of public key cryptography has produced a desire for + its support in Kerberos [2]. The advantages provided by public key + cryptography include simplified key management (from the Kerberos + perspective) and the ability to leverage existing and developing + public key certification infrastructures. + + Public key cryptography can be integrated into Kerberos in a number + of ways. One is to associate a key pair with each realm, which can + then be used to facilitate cross-realm authentication; this is the + topic of another draft proposal. Another way is to allow users with + public key certificates to use them in initial authentication. This + is the concern of the current document. + + PKINIT utilizes ephemeral-ephemeral Diffie-Hellman keys in + combination with DSA keys as the primary, required mechanism. Note + that PKINIT supports the use of separate signature and encryption + keys. + + PKINIT enables access to Kerberos-secured services based on initial + authentication utilizing public key cryptography. PKINIT utilizes + standard public key signature and encryption data formats within the + standard Kerberos messages. The basic mechanism is as follows: The + user sends an AS-REQ message to the KDC as before, except that if that + user is to use public key cryptography in the initial authentication + step, his certificate and a signature accompany the initial request + in the preauthentication fields. Upon receipt of this request, the + KDC verifies the certificate and issues a ticket granting ticket + (TGT) as before, except that the encPart from the AS-REP message + carrying the TGT is now encrypted utilizing either a Diffie-Hellman + derived key or the user's public key. This message is authenticated + utilizing the public key signature of the KDC. + + Note that PKINIT does not require the use of certificates. A KDC + may store the public key of a principal as part of that principal's + record. In this scenario, the KDC is the trusted party that vouches + for the principal (as in a standard, non-cross realm, Kerberos + environment). Thus, for any principal, the KDC may maintain a + symmetric key, a public key, or both. + + The PKINIT specification may also be used as a building block for + other specifications. PKINIT may be utilized to establish + inter-realm keys for the purposes of issuing cross-realm service + tickets. It may also be used to issue anonymous Kerberos tickets + using the Diffie-Hellman option. Efforts are under way to draft + specifications for these two application protocols. + + Additionally, the PKINIT specification may be used for direct peer + to peer authentication without contacting a central KDC. This + application of PKINIT is described in PKTAPP [5] and is based on + concepts introduced in [6, 7]. For direct client-to-server + authentication, the client uses PKINIT to authenticate to the end + server (instead of a central KDC), which then issues a ticket for + itself. This approach has an advantage over TLS [8] in that the + server does not need to save state (cache session keys). + Furthermore, an additional benefit is that Kerberos tickets can + facilitate delegation (see [9]). + +3. Proposed Extensions + + This section describes extensions to RFC 1510 for supporting the + use of public key cryptography in the initial request for a ticket + granting ticket (TGT). + + In summary, the following change to RFC 1510 is proposed: + + * Users may authenticate using either a public key pair or a + conventional (symmetric) key. If public key cryptography is + used, public key data is transported in preauthentication + data fields to help establish identity. The user presents + a public key certificate and obtains an ordinary TGT that may + be used for subsequent authentication, with such + authentication using only conventional cryptography. + + Section 3.1 provides definitions to help specify message formats. + Section 3.2 describes the extensions for the initial authentication + method. + +3.1. Definitions + + The extensions involve new preauthentication fields; we introduce + the following preauthentication types: + + PA-PK-AS-REQ 14 + PA-PK-AS-REP 15 + + The extensions also involve new error types; we introduce the + following types: + + KDC_ERR_CLIENT_NOT_TRUSTED 62 + KDC_ERR_KDC_NOT_TRUSTED 63 + KDC_ERR_INVALID_SIG 64 + KDC_ERR_KEY_TOO_WEAK 65 + KDC_ERR_CERTIFICATE_MISMATCH 66 + KDC_ERR_CANT_VERIFY_CERTIFICATE 70 + KDC_ERR_INVALID_CERTIFICATE 71 + KDC_ERR_REVOKED_CERTIFICATE 72 + KDC_ERR_REVOCATION_STATUS_UNKNOWN 73 + KDC_ERR_REVOCATION_STATUS_UNAVAILABLE 74 + KDC_ERR_CLIENT_NAME_MISMATCH 75 + KDC_ERR_KDC_NAME_MISMATCH 76 + + We utilize the following typed data for errors: + + TD-PKINIT-CMS-CERTIFICATES 101 + TD-KRB-PRINCIPAL 102 + TD-KRB-REALM 103 + TD-TRUSTED-CERTIFIERS 104 + TD-CERTIFICATE-INDEX 105 + + We utilize the following encryption types (which map directly to + OIDs): + + dsaWithSHA1-CmsOID 9 + md5WithRSAEncryption-CmsOID 10 + sha1WithRSAEncryption-CmsOID 11 + rc2CBC-EnvOID 12 + rsaEncryption-EnvOID (PKCS#1 v1.5) 13 + rsaES-OAEP-ENV-OID (PKCS#1 v2.0) 14 + des-ede3-cbc-Env-OID 15 + + These mappings are provided so that a client may send the + appropriate enctypes in the AS-REQ message in order to indicate + support for the corresponding OIDs (for performing PKINIT). + + In many cases, PKINIT requires the encoding of the X.500 name of a + certificate authority as a Realm. When such a name appears as + a realm it will be represented using the "Other" form of the realm + name as specified in the naming constraints section of RFC1510. + For a realm derived from an X.500 name, NAMETYPE will have the value + X500-RFC2253. The full realm name will appear as follows: + + + ":" + + + where nametype is "X500-RFC2253" and string is the result of doing + an RFC2253 encoding of the distinguished name, i.e. + + "X500-RFC2253:" + RFC2253Encode(DistinguishedName) + + where DistinguishedName is an X.500 name, and RFC2253Encode is a + function returing a readable UTF encoding of an X.500 name, as + defined by RFC 2253 [14] (part of LDAPv3 [18]). + + To ensure that this encoding is unique, we add the following rule + to those specified by RFC 2253: + + The order in which the attributes appear in the RFC 2253 + encoding MUST be the reverse of the order in the ASN.1 + encoding of the X.500 name that appears in the public key + certificate. The order of the relative distinguished names + (RDNs), as well as the order of the AttributeTypeAndValues + within each RDN, will be reversed. (This is despite the fact + that an RDN is defined as a SET of AttributeTypeAndValues, where + an order is normally not important.) + + Similarly, in cases where the KDC does not provide a specific + policy-based mapping from the X.500 name or X.509 Version 3 + SubjectAltName extension in the user's certificate to a Kerberos + principal name, PKINIT requires the direct encoding of the X.500 + name as a PrincipalName. In this case, the name-type of the + principal name MUST be set to KRB_NT-X500-PRINCIPAL. This new + name type is defined in RFC 1510 as: + + KRB_NT_X500_PRINCIPAL 6 + + For this type, the name-string MUST be set as follows: + + RFC2253Encode(DistinguishedName) + + as described above. When this name type is used, the principal's + realm MUST be set to the certificate authority's distinguished + name using the X500-RFC2253 realm name format described earlier in + this section. + + RFC 1510 specifies the ASN.1 structure for PrincipalName as follows: + + PrincipalName ::= SEQUENCE { + name-type[0] INTEGER, + name-string[1] SEQUENCE OF GeneralString + } + + The following rules relate to the the matching of PrincipalNames + with regard to the PKI name constraints for CAs as laid out in RFC + 2459 [15]. In order to be regarded as a match (for permitted and + excluded name trees), the following MUST be satisfied. + + 1. If the constraint is given as a user plus realm name, or + as a client principal name plus realm name (as specified in + RFC 1510), the realm name MUST be valid (see 2.a-d below) + and the match MUST be exact, byte for byte. + + 2. If the constraint is given only as a realm name, matching + depends on the type of the realm: + + a. If the realm contains a colon (':') before any equal + sign ('='), it is treated as a realm of type Other, + and MUST match exactly, byte for byte. + + b. Otherwise, if the realm name conforms to rules regarding + the format of DNS names, it is considered a realm name of + type Domain. The constraint may be given as a realm + name 'FOO.BAR', which matches any PrincipalName within + the realm 'FOO.BAR' but not those in subrealms such as + 'CAR.FOO.BAR'. A constraint of the form '.FOO.BAR' + matches PrincipalNames in subrealms of the form + 'CAR.FOO.BAR' but not the realm 'FOO.BAR' itself. + + c. Otherwise, the realm name is invalid and does not match + under any conditions. + +3.1.1. Encryption and Key Formats + + In the exposition below, we use the terms public key and private + key generically. It should be understood that the term "public + key" may be used to refer to either a public encryption key or a + signature verification key, and that the term "private key" may be + used to refer to either a private decryption key or a signature + generation key. The fact that these are logically distinct does + not preclude the assignment of bitwise identical keys for RSA + keys. + + In the case of Diffie-Hellman, the key is produced from the agreed + bit string as follows: + + * Truncate the bit string to the appropriate length. + * Rectify parity in each byte (if necessary) to obtain the key. + + For instance, in the case of a DES key, we take the first eight + bytes of the bit stream, and then adjust the least significant bit + of each byte to ensure that each byte has odd parity. + +3.1.2. Algorithm Identifiers + + PKINIT does not define, but does permit, the algorithm identifiers + listed below. + +3.1.2.1. Signature Algorithm Identifiers + + The following signature algorithm identifiers specified in [11] and + in [15] are used with PKINIT: + + id-dsa-with-sha1 (DSA with SHA1) + md5WithRSAEncryption (RSA with MD5) + sha-1WithRSAEncryption (RSA with SHA1) + +3.1.2.2 Diffie-Hellman Key Agreement Algorithm Identifier + + The following algorithm identifier shall be used within the + SubjectPublicKeyInfo data structure: dhpublicnumber + + This identifier and the associated algorithm parameters are + specified in RFC 2459 [15]. + +3.1.2.3. Algorithm Identifiers for RSA Encryption + + These algorithm identifiers are used inside the EnvelopedData data + structure, for encrypting the temporary key with a public key: + + rsaEncryption (RSA encryption, PKCS#1 v1.5) + id-RSAES-OAEP (RSA encryption, PKCS#1 v2.0) + + Both of the above RSA encryption schemes are specified in [16]. + Currently, only PKCS#1 v1.5 is specified by CMS [11], although the + CMS specification says that it will likely include PKCS#1 v2.0 in + the future. (PKCS#1 v2.0 addresses adaptive chosen ciphertext + vulnerability discovered in PKCS#1 v1.5.) + +3.1.2.4. Algorithm Identifiers for Encryption with Secret Keys + + These algorithm identifiers are used inside the EnvelopedData data + structure in the PKINIT Reply, for encrypting the reply key with the + temporary key: + des-ede3-cbc (3-key 3-DES, CBC mode) + rc2-cbc (RC2, CBC mode) + + The full definition of the above algorithm identifiers and their + corresponding parameters (an IV for block chaining) is provided in + the CMS specification [11]. + +3.2. Public Key Authentication + + Implementation of the changes in this section is REQUIRED for + compliance with PKINIT. + +3.2.1. Client Request + + Public keys may be signed by some certification authority (CA), or + they may be maintained by the KDC in which case the KDC is the + trusted authority. Note that the latter mode does not require the + use of certificates. + + The initial authentication request is sent as per RFC 1510, except + that a preauthentication field containing data signed by the user's + private key accompanies the request: + + PA-PK-AS-REQ ::= SEQUENCE { + -- PA TYPE 14 + signedAuthPack [0] SignedData + -- Defined in CMS [11]; + -- AuthPack (below) defines the + -- data that is signed. + trustedCertifiers [1] SEQUENCE OF TrustedCas OPTIONAL, + -- This is a list of CAs that the + -- client trusts and that certify + -- KDCs. + kdcCert [2] IssuerAndSerialNumber OPTIONAL + -- As defined in CMS [11]; + -- specifies a particular KDC + -- certificate if the client + -- already has it. + encryptionCert [3] IssuerAndSerialNumber OPTIONAL + -- For example, this may be the + -- client's Diffie-Hellman + -- certificate, or it may be the + -- client's RSA encryption + -- certificate. + } + + TrustedCas ::= CHOICE { + principalName [0] KerberosName, + -- as defined below + caName [1] Name + -- fully qualified X.500 name + -- as defined by X.509 + issuerAndSerial [2] IssuerAndSerialNumber + -- Since a CA may have a number of + -- certificates, only one of which + -- a client trusts + } + + Usage of SignedData: + + The SignedData data type is specified in the Cryptographic + Message Syntax, a product of the S/MIME working group of the + IETF. The following describes how to fill in the fields of + this data: + + 1. The encapContentInfo field MUST contain the PKAuthenticator + and, optionally, the client's Diffie Hellman public value. + + a. The eContentType field MUST contain the OID value for + pkauthdata: iso (1) org (3) dod (6) internet (1) + security (5) kerberosv5 (2) pkinit (3) pkauthdata (1) + + b. The eContent field is data of the type AuthPack (below). + + 2. The signerInfos field contains the signature of AuthPack. + + 3. The Certificates field, when non-empty, contains the client's + certificate chain. If present, the KDC uses the public key + from the client's certificate to verify the signature in the + request. Note that the client may pass different certificate + chains that are used for signing or for encrypting. Thus, + the KDC may utilize a different client certificate for + signature verification than the one it uses to encrypt the + reply to the client. For example, the client may place a + Diffie-Hellman certificate in this field in order to convey + its static Diffie Hellman certificate to the KDC to enable + static-ephemeral Diffie-Hellman mode for the reply; in this + case, the client does NOT place its public value in the + AuthPack (defined below). As another example, the client may + place an RSA encryption certificate in this field. However, + there MUST always be (at least) a signature certificate. + + AuthPack ::= SEQUENCE { + pkAuthenticator [0] PKAuthenticator, + clientPublicValue [1] SubjectPublicKeyInfo OPTIONAL + -- if client is using Diffie-Hellman + -- (ephemeral-ephemeral only) + } + + PKAuthenticator ::= SEQUENCE { + cusec [0] INTEGER, + -- for replay prevention as in RFC1510 + ctime [1] KerberosTime, + -- for replay prevention as in RFC1510 + nonce [2] INTEGER, + pachecksum [3] Checksum + -- Checksum over KDC-REQ-BODY + -- Defined by Kerberos spec + } + + SubjectPublicKeyInfo ::= SEQUENCE { + algorithm AlgorithmIdentifier, + -- dhKeyAgreement + subjectPublicKey BIT STRING + -- for DH, equals + -- public exponent (INTEGER encoded + -- as payload of BIT STRING) + } -- as specified by the X.509 recommendation [10] + + AlgorithmIdentifier ::= SEQUENCE { + algorithm OBJECT IDENTIFIER, + -- for dhKeyAgreement, this is + -- { iso (1) member-body (2) US (840) + -- rsadsi (113459) pkcs (1) 3 1 } + -- from PKCS #3 [20] + parameters ANY DEFINED by algorithm OPTIONAL + -- for dhKeyAgreement, this is + -- DHParameter + } -- as specified by the X.509 recommendation [10] + + DHParameter ::= SEQUENCE { + prime INTEGER, + -- p + base INTEGER, + -- g + privateValueLength INTEGER OPTIONAL + -- l + } -- as defined in PKCS #3 [20] + + If the client passes an issuer and serial number in the request, + the KDC is requested to use the referred-to certificate. If none + exists, then the KDC returns an error of type + KDC_ERR_CERTIFICATE_MISMATCH. It also returns this error if, on the + other hand, the client does not pass any trustedCertifiers, + believing that it has the KDC's certificate, but the KDC has more + than one certificate. The KDC should include information in the + KRB-ERROR message that indicates the KDC certificate(s) that a + client may utilize. This data is specified in the e-data, which + is defined in RFC 1510 revisions as a SEQUENCE of TypedData: + + TypedData ::= SEQUENCE { + data-type [0] INTEGER, + data-value [1] OCTET STRING, + } -- per Kerberos RFC 1510 revisions + + where: + data-type = TD-PKINIT-CMS-CERTIFICATES = 101 + data-value = CertificateSet // as specified by CMS [11] + + The PKAuthenticator carries information to foil replay attacks, to + bind the pre-authentication data to the KDC-REQ-BODY, and to bind the + request and response. The PKAuthenticator is signed with the client's + signature key. + +3.2.2. KDC Response + + Upon receipt of the AS_REQ with PA-PK-AS-REQ pre-authentication + type, the KDC attempts to verify the user's certificate chain + (userCert), if one is provided in the request. This is done by + verifying the certification path against the KDC's policy of + legitimate certifiers. + + If the client's certificate chain contains no certificate signed by + a CA trusted by the KDC, then the KDC sends back an error message + of type KDC_ERR_CANT_VERIFY_CERTIFICATE. The accompanying e-data + is a SEQUENCE of one TypedData (with type TD-TRUSTED-CERTIFIERS=104) + whose data-value is an OCTET STRING which is the DER encoding of + + TrustedCertifiers ::= SEQUENCE OF PrincipalName + -- X.500 name encoded as a principal name + -- see Section 3.1 + + If while verifying a certificate chain the KDC determines that the + signature on one of the certificates in the CertificateSet from + the signedAuthPack fails verification, then the KDC returns an + error of type KDC_ERR_INVALID_CERTIFICATE. The accompanying + e-data is a SEQUENCE of one TypedData (with type + TD-CERTIFICATE-INDEX=105) whose data-value is an OCTET STRING + which is the DER encoding of the index into the CertificateSet + ordered as sent by the client. + + CertificateIndex ::= INTEGER + -- 0 = 1st certificate, + -- (in order of encoding) + -- 1 = 2nd certificate, etc + + The KDC may also check whether any of the certificates in the + client's chain has been revoked. If one of the certificates has + been revoked, then the KDC returns an error of type + KDC_ERR_REVOKED_CERTIFICATE; if such a query reveals that + the certificate's revocation status is unknown or not + available, then if required by policy, the KDC returns the + appropriate error of type KDC_ERR_REVOCATION_STATUS_UNKNOWN or + KDC_ERR_REVOCATION_STATUS_UNAVAILABLE. In any of these three + cases, the affected certificate is identified by the accompanying + e-data, which contains a CertificateIndex as described for + KDC_ERR_INVALID_CERTIFICATE. + + If the certificate chain can be verified, but the name of the + client in the certificate does not match the client's name in the + request, then the KDC returns an error of type + KDC_ERR_CLIENT_NAME_MISMATCH. There is no accompanying e-data + field in this case. + + Finally, if the certificate chain is verified, but the KDC's name + or realm as given in the PKAuthenticator does not match the KDC's + actual principal name, then the KDC returns an error of type + KDC_ERR_KDC_NAME_MISMATCH. The accompanying e-data field is again + a SEQUENCE of one TypedData (with type TD-KRB-PRINCIPAL=102 or + TD-KRB-REALM=103 as appropriate) whose data-value is an OCTET + STRING whose data-value is the DER encoding of a PrincipalName or + Realm as defined in RFC 1510 revisions. + + Even if all succeeds, the KDC may--for policy reasons--decide not + to trust the client. In this case, the KDC returns an error message + of type KDC_ERR_CLIENT_NOT_TRUSTED. One specific case of this is + the presence or absence of an Enhanced Key Usage (EKU) OID within + the certificate extensions. The rules regarding acceptability of + an EKU sequence (or the absence of any sequence) are a matter of + local policy. For the benefit of implementers, we define a PKINIT + EKU OID as the following: iso (1) org (3) dod (6) internet (1) + security (5) kerberosv5 (2) pkinit (3) pkekuoid (2). + + If a trust relationship exists, the KDC then verifies the client's + signature on AuthPack. If that fails, the KDC returns an error + message of type KDC_ERR_INVALID_SIG. Otherwise, the KDC uses the + timestamp (ctime and cusec) in the PKAuthenticator to assure that + the request is not a replay. The KDC also verifies that its name + is specified in the PKAuthenticator. + + If the clientPublicValue field is filled in, indicating that the + client wishes to use Diffie-Hellman key agreement, then the KDC + checks to see that the parameters satisfy its policy. If they do + not (e.g., the prime size is insufficient for the expected + encryption type), then the KDC sends back an error message of type + KDC_ERR_KEY_TOO_WEAK. Otherwise, it generates its own public and + private values for the response. + + The KDC also checks that the timestamp in the PKAuthenticator is + within the allowable window and that the principal name and realm + are correct. If the local (server) time and the client time in the + authenticator differ by more than the allowable clock skew, then the + KDC returns an error message of type KRB_AP_ERR_SKEW as defined in 1510. + + Assuming no errors, the KDC replies as per RFC 1510, except as + follows. The user's name in the ticket is determined by the + following decision algorithm: + + 1. If the KDC has a mapping from the name in the certificate + to a Kerberos name, then use that name. + Else + 2. If the certificate contains the SubjectAltName extention + and the local KDC policy defines a mapping from the + SubjectAltName to a Kerberos name, then use that name. + Else + 3. Use the name as represented in the certificate, mapping + as necessary (e.g., as per RFC 2253 for X.500 names). In + this case the realm in the ticket MUST be the name of the + certifier that issued the user's certificate. + + Note that a principal name may be carried in the subjectAltName + field of a certificate. This name may be mapped to a principal + record in a security database based on local policy, for example + the subjectAltName may be kerberos/principal@realm format. In + this case the realm name is not that of the CA but that of the + local realm doing the mapping (or some realm name chosen by that + realm). + + If a non-KDC X.509 certificate contains the principal name within + the subjectAltName version 3 extension, that name may utilize + KerberosName as defined below, or, in the case of an S/MIME + certificate [17], may utilize the email address. If the KDC + is presented with an S/MIME certificate, then the email address + within subjectAltName will be interpreted as a principal and realm + separated by the "@" sign, or as a name that needs to be mapped + according to local policy. If the resulting name does not correspond + to a registered principal name, then the principal name is formed as + defined in section 3.1. + + The trustedCertifiers field contains a list of certification + authorities trusted by the client, in the case that the client does + not possess the KDC's public key certificate. If the KDC has no + certificate signed by any of the trustedCertifiers, then it returns + an error of type KDC_ERR_KDC_NOT_TRUSTED. + + KDCs should try to (in order of preference): + 1. Use the KDC certificate identified by the serialNumber included + in the client's request. + 2. Use a certificate issued to the KDC by one of the client's + trustedCertifier(s); + If the KDC is unable to comply with any of these options, then the + KDC returns an error message of type KDC_ERR_KDC_NOT_TRUSTED to the + client. + + The KDC encrypts the reply not with the user's long-term key, but + with the Diffie Hellman derived key or a random key generated + for this particular response which is carried in the padata field of + the TGS-REP message. + + PA-PK-AS-REP ::= CHOICE { + -- PA TYPE 15 + dhSignedData [0] SignedData, + -- Defined in CMS and used only with + -- Diffie-Hellman key exchange (if the + -- client public value was present in the + -- request). + -- This choice MUST be supported + -- by compliant implementations. + encKeyPack [1] EnvelopedData, + -- Defined in CMS + -- The temporary key is encrypted + -- using the client public key + -- key + -- SignedReplyKeyPack, encrypted + -- with the temporary key, is also + -- included. + } + + Usage of SignedData: + + When the Diffie-Hellman option is used, dhSignedData in + PA-PK-AS-REP provides authenticated Diffie-Hellman parameters + of the KDC. The reply key used to encrypt part of the KDC reply + message is derived from the Diffie-Hellman exchange: + + 1. Both the KDC and the client calculate a secret value + (g^ab mod p), where a is the client's private exponent and + b is the KDC's private exponent. + + 2. Both the KDC and the client take the first N bits of this + secret value and convert it into a reply key. N depends on + the reply key type. + + a. For example, if the reply key is DES, N=64 bits, where + some of the bits are replaced with parity bits, according + to FIPS PUB 74. + + b. As another example, if the reply key is (3-key) 3-DES, + N=192 bits, where some of the bits are replaced with + parity bits, according to FIPS PUB 74. + + 3. The encapContentInfo field MUST contain the KdcDHKeyInfo as + defined below. + + a. The eContentType field MUST contain the OID value for + pkdhkeydata: iso (1) org (3) dod (6) internet (1) + security (5) kerberosv5 (2) pkinit (3) pkdhkeydata (2) + + b. The eContent field is data of the type KdcDHKeyInfo + (below). + + 4. The certificates field MUST contain the certificates + necessary for the client to establish trust in the KDC's + certificate based on the list of trusted certifiers sent by + the client in the PA-PK-AS-REQ. This field may be empty if + the client did not send to the KDC a list of trusted + certifiers (the trustedCertifiers field was empty, meaning + that the client already possesses the KDC's certificate). + + 5. The signerInfos field is a SET that MUST contain at least + one member, since it contains the actual signature. + + KdcDHKeyInfo ::= SEQUENCE { + -- used only when utilizing Diffie-Hellman + nonce [0] INTEGER, + -- binds responce to the request + subjectPublicKey [2] BIT STRING + -- Equals public exponent (g^a mod p) + -- INTEGER encoded as payload of + -- BIT STRING + } + + Usage of EnvelopedData: + + The EnvelopedData data type is specified in the Cryptographic + Message Syntax, a product of the S/MIME working group of the + IETF. It contains a temporary key encrypted with the PKINIT + client's public key. It also contains a signed and encrypted + reply key. + + 1. The originatorInfo field is not required, since that + information may be presented in the signedData structure + that is encrypted within the encryptedContentInfo field. + + 2. The optional unprotectedAttrs field is not required for + PKINIT. + + 3. The recipientInfos field is a SET which MUST contain exactly + one member of the KeyTransRecipientInfo type for encryption + with a public key. + + a. The encryptedKey field (in KeyTransRecipientInfo) + contains the temporary key which is encrypted with the + PKINIT client's public key. + + 4. The encryptedContentInfo field contains the signed and + encrypted reply key. + + a. The contentType field MUST contain the OID value for + id-signedData: iso (1) member-body (2) us (840) + rsadsi (113549) pkcs (1) pkcs7 (7) signedData (2) + + b. The encryptedContent field is encrypted data of the CMS + type signedData as specified below. + + i. The encapContentInfo field MUST contains the + ReplyKeyPack. + + * The eContentType field MUST contain the OID value + for pkrkeydata: iso (1) org (3) dod (6) internet (1) + security (5) kerberosv5 (2) pkinit (3) pkrkeydata (3) + + * The eContent field is data of the type ReplyKeyPack + (below). + + ii. The certificates field MUST contain the certificates + necessary for the client to establish trust in the + KDC's certificate based on the list of trusted + certifiers sent by the client in the PA-PK-AS-REQ. + This field may be empty if the client did not send + to the KDC a list of trusted certifiers (the + trustedCertifiers field was empty, meaning that the + client already possesses the KDC's certificate). + + iii. The signerInfos field is a SET that MUST contain at + least one member, since it contains the actual + signature. + + ReplyKeyPack ::= SEQUENCE { + -- not used for Diffie-Hellman + replyKey [0] EncryptionKey, + -- from RFC 1510bis + -- used to encrypt main reply + -- ENCTYPE is at least as strong as + -- ENCTYPE of session key + nonce [1] INTEGER, + -- binds response to the request + -- must be same as the nonce + -- passed in the PKAuthenticator + } + + +3.2.2.1. Use of transited Field + + Since each certifier in the certification path of a user's + certificate is equivalent to a separate Kerberos realm, the name + of each certifier in the certificate chain MUST be added to the + transited field of the ticket. The format of these realm names is + defined in Section 3.1 of this document. If applicable, the + transit-policy-checked flag should be set in the issued ticket. + + +3.2.2.2. Kerberos Names in Certificates + + The KDC's certificate(s) MUST bind the public key(s) of the KDC to + a name derivable from the name of the realm for that KDC. X.509 + certificates MUST contain the principal name of the KDC + (defined in section 8.2 of RFC 1510) as the SubjectAltName version + 3 extension. Below is the definition of this version 3 extension, + as specified by the X.509 standard: + + subjectAltName EXTENSION ::= { + SYNTAX GeneralNames + IDENTIFIED BY id-ce-subjectAltName + } + + GeneralNames ::= SEQUENCE SIZE(1..MAX) OF GeneralName + + GeneralName ::= CHOICE { + otherName [0] OtherName, + ... + } + + OtherName ::= SEQUENCE { + type-id OBJECT IDENTIFIER, + value [0] EXPLICIT ANY DEFINED BY type-id + } + + For the purpose of specifying a Kerberos principal name, the value + in OtherName MUST be a KerberosName as defined in RFC 1510: + + KerberosName ::= SEQUENCE { + realm [0] Realm, + principalName [1] PrincipalName + } + + This specific syntax is identified within subjectAltName by setting + the type-id in OtherName to krb5PrincipalName, where (from the + Kerberos specification) we have + + krb5 OBJECT IDENTIFIER ::= { iso (1) + org (3) + dod (6) + internet (1) + security (5) + kerberosv5 (2) } + + krb5PrincipalName OBJECT IDENTIFIER ::= { krb5 2 } + + (This specification may also be used to specify a Kerberos name + within the user's certificate.) The KDC's certificate may be signed + directly by a CA, or there may be intermediaries if the server resides + within a large organization, or it may be unsigned if the client + indicates possession (and trust) of the KDC's certificate. + + Note that the KDC's principal name has the instance equal to the + realm, and those fields should be appropriately set in the realm + and principalName fields of the KerberosName. This is the case + even when obtaining a cross-realm ticket using PKINIT. + + +3.2.3. Client Extraction of Reply + + The client then extracts the random key used to encrypt the main + reply. This random key (in encPaReply) is encrypted with either the + client's public key or with a key derived from the DH values + exchanged between the client and the KDC. The client uses this + random key to decrypt the main reply, and subsequently proceeds as + described in RFC 1510. + +3.2.4. Required Algorithms + + Not all of the algorithms in the PKINIT protocol specification have + to be implemented in order to comply with the proposed standard. + Below is a list of the required algorithms: + + * Diffie-Hellman public/private key pairs + * utilizing Diffie-Hellman ephemeral-ephemeral mode + * SHA1 digest and DSA for signatures + * SHA1 digest also for the Checksum in the PKAuthenticator + * 3-key triple DES keys derived from the Diffie-Hellman Exchange + * 3-key triple DES Temporary and Reply keys + +4. Logistics and Policy + + This section describes a way to define the policy on the use of + PKINIT for each principal and request. + + The KDC is not required to contain a database record for users + who use public key authentication. However, if these users are + registered with the KDC, it is recommended that the database record + for these users be modified to an additional flag in the attributes + field to indicate that the user should authenticate using PKINIT. + If this flag is set and a request message does not contain the + PKINIT preauthentication field, then the KDC sends back as error of + type KDC_ERR_PREAUTH_REQUIRED indicating that a preauthentication + field of type PA-PK-AS-REQ must be included in the request. + +5. Security Considerations + + PKINIT raises a few security considerations, which we will address + in this section. + + First of all, PKINIT introduces a new trust model, where KDCs do not + (necessarily) certify the identity of those for whom they issue + tickets. PKINIT does allow KDCs to act as their own CAs, in the + limited capacity of self-signing their certificates, but one of the + additional benefits is to align Kerberos authentication with a global + public key infrastructure. Anyone using PKINIT in this way must be + aware of how the certification infrastructure they are linking to + works. + + Secondly, PKINIT also introduces the possibility of interactions + between different cryptosystems, which may be of widely varying + strengths. Many systems, for instance, allow the use of 512-bit + public keys. Using such keys to wrap data encrypted under strong + conventional cryptosystems, such as triple-DES, is inappropriate; + it adds a weak link to a strong one at extra cost. Implementors + and administrators should take care to avoid such wasteful and + deceptive interactions. + + Lastly, PKINIT calls for randomly generated keys for conventional + cryptosystems. Many such systems contain systematically "weak" + keys. PKINIT implementations MUST avoid use of these keys, either + by discarding those keys when they are generated, or by fixing them + in some way (e.g., by XORing them with a given mask). These + precautions vary from system to system; it is not our intention to + give an explicit recipe for them here. + +6. Transport Issues + + Certificate chains can potentially grow quite large and span several + UDP packets; this in turn increases the probability that a Kerberos + message involving PKINIT extensions will be broken in transit. In + light of the possibility that the Kerberos specification will + require KDCs to accept requests using TCP as a transport mechanism, + we make the same recommendation with respect to the PKINIT + extensions as well. + +7. Bibliography + + [1] J. Kohl, C. Neuman. The Kerberos Network Authentication Service + (V5). Request for Comments 1510. + + [2] B.C. Neuman, Theodore Ts'o. Kerberos: An Authentication Service + for Computer Networks, IEEE Communications, 32(9):33-38. September + 1994. + + [3] B. Tung, T. Ryutov, C. Neuman, G. Tsudik, B. Sommerfeld, + A. Medvinsky, M. Hur. Public Key Cryptography for Cross-Realm + Authentication in Kerberos. draft-ietf-cat-kerberos-pk-cross-04.txt + + [4] A. Medvinsky, J. Cargille, M. Hur. Anonymous Credentials in + Kerberos. draft-ietf-cat-kerberos-anoncred-00.txt + + [5] Ari Medvinsky, M. Hur, Alexander Medvinsky, B. Clifford Neuman. + Public Key Utilizing Tickets for Application Servers (PKTAPP). + draft-ietf-cat-pktapp-02.txt + + [6] M. Sirbu, J. Chuang. Distributed Authentication in Kerberos + Using Public Key Cryptography. Symposium On Network and Distributed + System Security, 1997. + + [7] B. Cox, J.D. Tygar, M. Sirbu. NetBill Security and Transaction + Protocol. In Proceedings of the USENIX Workshop on Electronic + Commerce, July 1995. + + [8] T. Dierks, C. Allen. The TLS Protocol, Version 1.0 + Request for Comments 2246, January 1999. + + [9] B.C. Neuman, Proxy-Based Authorization and Accounting for + Distributed Systems. In Proceedings of the 13th International + Conference on Distributed Computing Systems, May 1993. + + [10] ITU-T (formerly CCITT) Information technology - Open Systems + Interconnection - The Directory: Authentication Framework + Recommendation X.509 ISO/IEC 9594-8 + + [11] R. Housley. Cryptographic Message Syntax. + draft-ietf-smime-cms-13.txt, April 1999, approved for publication + as RFC. + + [12] PKCS #7: Cryptographic Message Syntax Standard, + An RSA Laboratories Technical Note Version 1.5 + Revised November 1, 1993 + + [13] R. Rivest, MIT Laboratory for Computer Science and RSA Data + Security, Inc. A Description of the RC2(r) Encryption Algorithm + March 1998. + Request for Comments 2268. + + [14] M. Wahl, S. Kille, T. Howes. Lightweight Directory Access + Protocol (v3): UTF-8 String Representation of Distinguished Names. + Request for Comments 2253. + + [15] R. Housley, W. Ford, W. Polk, D. Solo. Internet X.509 Public + Key Infrastructure, Certificate and CRL Profile, January 1999. + Request for Comments 2459. + + [16] B. Kaliski, J. Staddon. PKCS #1: RSA Cryptography + Specifications, October 1998. Request for Comments 2437. + + [17] S. Dusse, P. Hoffman, B. Ramsdell, J. Weinstein. S/MIME + Version 2 Certificate Handling, March 1998. Request for + Comments 2312. + + [18] M. Wahl, T. Howes, S. Kille. Lightweight Directory Access + Protocol (v3), December 1997. Request for Comments 2251. + + [19] ITU-T (formerly CCITT) Information Processing Systems - Open + Systems Interconnection - Specification of Abstract Syntax Notation + One (ASN.1) Rec. X.680 ISO/IEC 8824-1 + + [20] PKCS #3: Diffie-Hellman Key-Agreement Standard, An RSA + Laboratories Technical Note, Version 1.4, Revised November 1, 1993. + +8. Acknowledgements + + Some of the ideas on which this proposal is based arose during + discussions over several years between members of the SAAG, the IETF + CAT working group, and the PSRG, regarding integration of Kerberos + and SPX. Some ideas have also been drawn from the DASS system. + These changes are by no means endorsed by these groups. This is an + attempt to revive some of the goals of those groups, and this + proposal approaches those goals primarily from the Kerberos + perspective. Lastly, comments from groups working on similar ideas + in DCE have been invaluable. + +9. Expiration Date + + This draft expires August 31, 2001. + +10. Authors + + Brian Tung + Clifford Neuman + USC Information Sciences Institute + 4676 Admiralty Way Suite 1001 + Marina del Rey CA 90292-6695 + Phone: +1 310 822 1511 + E-mail: {brian, bcn}@isi.edu + + Matthew Hur + Cisco Systems + 500 108th Ave. NE, Suite 500 + Bellevue, WA 98004 + Phone: (408) 525-0034 + EMail: mhur@cisco.com + + Ari Medvinsky + Keen.com, Inc. + 150 Independence Drive + Menlo Park CA 94025 + Phone: +1 650 289 3134 + E-mail: ari@keen.com + + Sasha Medvinsky + Motorola + 6450 Sequence Drive + San Diego, CA 92121 + +1 858 404 2367 + E-mail: smedvinsky@gi.com + + John Wray + Iris Associates, Inc. + 5 Technology Park Dr. + Westford, MA 01886 + E-mail: John_Wray@iris.com + + Jonathan Trostle + Cisco Systems + 170 W. Tasman Dr. + San Jose, CA 95134 + E-mail: jtrostle@cisco.com diff --git a/doc/standardisation/draft-ietf-cat-kerberos-pk-init-14.txt b/doc/standardisation/draft-ietf-cat-kerberos-pk-init-14.txt new file mode 100644 index 000000000..49ea9de8e --- /dev/null +++ b/doc/standardisation/draft-ietf-cat-kerberos-pk-init-14.txt @@ -0,0 +1,1104 @@ +INTERNET-DRAFT Brian Tung +draft-ietf-cat-kerberos-pk-init-14.txt Clifford Neuman +Updates: RFC 1510bis USC/ISI +expires January 15, 2002 Matthew Hur + Cisco + Ari Medvinsky + Keen.com, Inc. + Sasha Medvinsky + Motorola + John Wray + Iris Associates, Inc. + Jonathan Trostle + Cisco + + Public Key Cryptography for Initial Authentication in Kerberos + +0. Status Of This Memo + + This document is an Internet-Draft and is in full conformance with + all provisions of Section 10 of RFC 2026. Internet-Drafts are + working documents of the Internet Engineering Task Force (IETF), + its areas, and its working groups. Note that other groups may also + distribute working documents as Internet-Drafts. + + Internet-Drafts are draft documents valid for a maximum of six + months and may be updated, replaced, or obsoleted by other + documents at any time. It is inappropriate to use Internet-Drafts + as reference material or to cite them other than as "work in + progress." + + The list of current Internet-Drafts can be accessed at + http://www.ietf.org/ietf/1id-abstracts.txt + + The list of Internet-Draft Shadow Directories can be accessed at + http://www.ietf.org/shadow.html. + + To learn the current status of any Internet-Draft, please check + the "1id-abstracts.txt" listing contained in the Internet-Drafts + Shadow Directories on ftp.ietf.org (US East Coast), + nic.nordu.net (Europe), ftp.isi.edu (US West Coast), or + munnari.oz.au (Pacific Rim). + + The distribution of this memo is unlimited. It is filed as + draft-ietf-cat-kerberos-pk-init-14.txt, and expires January 15, + 2002. Please send comments to the authors. + +1. Abstract + + This document defines extensions (PKINIT) to the Kerberos protocol + specification (RFC 1510bis [1]) to provide a method for using public + key cryptography during initial authentication. The methods + defined specify the ways in which preauthentication data fields and + error data fields in Kerberos messages are to be used to transport + public key data. + +2. Introduction + + The popularity of public key cryptography has produced a desire for + its support in Kerberos [2]. The advantages provided by public key + cryptography include simplified key management (from the Kerberos + perspective) and the ability to leverage existing and developing + public key certification infrastructures. + + Public key cryptography can be integrated into Kerberos in a number + of ways. One is to associate a key pair with each realm, which can + then be used to facilitate cross-realm authentication; this is the + topic of another draft proposal. Another way is to allow users with + public key certificates to use them in initial authentication. This + is the concern of the current document. + + PKINIT utilizes ephemeral-ephemeral Diffie-Hellman keys in + combination with DSA keys as the primary, required mechanism. Note + that PKINIT supports the use of separate signature and encryption + keys. + + PKINIT enables access to Kerberos-secured services based on initial + authentication utilizing public key cryptography. PKINIT utilizes + standard public key signature and encryption data formats within the + standard Kerberos messages. The basic mechanism is as follows: The + user sends an AS-REQ message to the KDC as before, except that if that + user is to use public key cryptography in the initial authentication + step, his certificate and a signature accompany the initial request + in the preauthentication fields. Upon receipt of this request, the + KDC verifies the certificate and issues a ticket granting ticket + (TGT) as before, except that the encPart from the AS-REP message + carrying the TGT is now encrypted utilizing either a Diffie-Hellman + derived key or the user's public key. This message is authenticated + utilizing the public key signature of the KDC. + + Note that PKINIT does not require the use of certificates. A KDC + may store the public key of a principal as part of that principal's + record. In this scenario, the KDC is the trusted party that vouches + for the principal (as in a standard, non-cross realm, Kerberos + environment). Thus, for any principal, the KDC may maintain a + symmetric key, a public key, or both. + + The PKINIT specification may also be used as a building block for + other specifications. PKINIT may be utilized to establish + inter-realm keys for the purposes of issuing cross-realm service + tickets. It may also be used to issue anonymous Kerberos tickets + using the Diffie-Hellman option. Efforts are under way to draft + specifications for these two application protocols. + + Additionally, the PKINIT specification may be used for direct peer + to peer authentication without contacting a central KDC. This + application of PKINIT is based on concepts introduced in [6, 7]. + For direct client-to-server authentication, the client uses PKINIT + to authenticate to the end server (instead of a central KDC), which + then issues a ticket for itself. This approach has an advantage + over TLS [5] in that the server does not need to save state (cache + session keys). Furthermore, an additional benefit is that Kerberos + tickets can facilitate delegation (see [6]). + +3. Proposed Extensions + + This section describes extensions to RFC 1510bis for supporting the + use of public key cryptography in the initial request for a ticket + granting ticket (TGT). + + In summary, the following change to RFC 1510bis is proposed: + + * Users may authenticate using either a public key pair or a + conventional (symmetric) key. If public key cryptography is + used, public key data is transported in preauthentication + data fields to help establish identity. The user presents + a public key certificate and obtains an ordinary TGT that may + be used for subsequent authentication, with such + authentication using only conventional cryptography. + + Section 3.1 provides definitions to help specify message formats. + Section 3.2 describes the extensions for the initial authentication + method. + +3.1. Definitions + + The extensions involve new preauthentication fields; we introduce + the following preauthentication types: + + PA-PK-AS-REQ 14 + PA-PK-AS-REP 15 + + The extensions also involve new error types; we introduce the + following types: + + KDC_ERR_CLIENT_NOT_TRUSTED 62 + KDC_ERR_KDC_NOT_TRUSTED 63 + KDC_ERR_INVALID_SIG 64 + KDC_ERR_KEY_TOO_WEAK 65 + KDC_ERR_CERTIFICATE_MISMATCH 66 + KDC_ERR_CANT_VERIFY_CERTIFICATE 70 + KDC_ERR_INVALID_CERTIFICATE 71 + KDC_ERR_REVOKED_CERTIFICATE 72 + KDC_ERR_REVOCATION_STATUS_UNKNOWN 73 + KDC_ERR_REVOCATION_STATUS_UNAVAILABLE 74 + KDC_ERR_CLIENT_NAME_MISMATCH 75 + KDC_ERR_KDC_NAME_MISMATCH 76 + + We utilize the following typed data for errors: + + TD-PKINIT-CMS-CERTIFICATES 101 + TD-KRB-PRINCIPAL 102 + TD-KRB-REALM 103 + TD-TRUSTED-CERTIFIERS 104 + TD-CERTIFICATE-INDEX 105 + + We utilize the following encryption types (which map directly to + OIDs): + + dsaWithSHA1-CmsOID 9 + md5WithRSAEncryption-CmsOID 10 + sha1WithRSAEncryption-CmsOID 11 + rc2CBC-EnvOID 12 + rsaEncryption-EnvOID (PKCS#1 v1.5) 13 + rsaES-OAEP-ENV-OID (PKCS#1 v2.0) 14 + des-ede3-cbc-Env-OID 15 + + These mappings are provided so that a client may send the + appropriate enctypes in the AS-REQ message in order to indicate + support for the corresponding OIDs (for performing PKINIT). + + In many cases, PKINIT requires the encoding of the X.500 name of a + certificate authority as a Realm. When such a name appears as + a realm it will be represented using the "Other" form of the realm + name as specified in the naming constraints section of RFC 1510bis. + For a realm derived from an X.500 name, NAMETYPE will have the value + X500-RFC2253. The full realm name will appear as follows: + + + ":" + + + where nametype is "X500-RFC2253" and string is the result of doing + an RFC2253 encoding of the distinguished name, i.e. + + "X500-RFC2253:" + RFC2253Encode(DistinguishedName) + + where DistinguishedName is an X.500 name, and RFC2253Encode is a + function returing a readable UTF encoding of an X.500 name, as + defined by RFC 2253 [11] (part of LDAPv3 [15]). + + To ensure that this encoding is unique, we add the following rule + to those specified by RFC 2253: + + The order in which the attributes appear in the RFC 2253 + encoding MUST be the reverse of the order in the ASN.1 + encoding of the X.500 name that appears in the public key + certificate. The order of the relative distinguished names + (RDNs), as well as the order of the AttributeTypeAndValues + within each RDN, will be reversed. (This is despite the fact + that an RDN is defined as a SET of AttributeTypeAndValues, where + an order is normally not important.) + + Similarly, in cases where the KDC does not provide a specific + policy-based mapping from the X.500 name or X.509 Version 3 + SubjectAltName extension in the user's certificate to a Kerberos + principal name, PKINIT requires the direct encoding of the X.500 + name as a PrincipalName. In this case, the name-type of the + principal name MUST be set to KRB_NT-X500-PRINCIPAL. This new + name type is defined in RFC 1510bis as: + + KRB_NT_X500_PRINCIPAL 6 + + For this type, the name-string MUST be set as follows: + + RFC2253Encode(DistinguishedName) + + as described above. When this name type is used, the principal's + realm MUST be set to the certificate authority's distinguished + name using the X500-RFC2253 realm name format described earlier in + this section. + + RFC 1510bis specifies the ASN.1 structure for PrincipalName as follows: + + PrincipalName ::= SEQUENCE { + name-type[0] INTEGER, + name-string[1] SEQUENCE OF GeneralString + } + + The following rules relate to the the matching of PrincipalNames + with regard to the PKI name constraints for CAs as laid out in RFC + 2459 [12]. In order to be regarded as a match (for permitted and + excluded name trees), the following MUST be satisfied. + + 1. If the constraint is given as a user plus realm name, or + as a client principal name plus realm name (as specified in + RFC 1510bis), the realm name MUST be valid (see 2.a-d below) + and the match MUST be exact, byte for byte. + + 2. If the constraint is given only as a realm name, matching + depends on the type of the realm: + + a. If the realm contains a colon (':') before any equal + sign ('='), it is treated as a realm of type Other, + and MUST match exactly, byte for byte. + + b. Otherwise, if the realm name conforms to rules regarding + the format of DNS names, it is considered a realm name of + type Domain. The constraint may be given as a realm + name 'FOO.BAR', which matches any PrincipalName within + the realm 'FOO.BAR' but not those in subrealms such as + 'CAR.FOO.BAR'. A constraint of the form '.FOO.BAR' + matches PrincipalNames in subrealms of the form + 'CAR.FOO.BAR' but not the realm 'FOO.BAR' itself. + + c. Otherwise, the realm name is invalid and does not match + under any conditions. + +3.1.1. Encryption and Key Formats + + In the exposition below, we use the terms public key and private + key generically. It should be understood that the term "public + key" may be used to refer to either a public encryption key or a + signature verification key, and that the term "private key" may be + used to refer to either a private decryption key or a signature + generation key. The fact that these are logically distinct does + not preclude the assignment of bitwise identical keys for RSA + keys. + + In the case of Diffie-Hellman, the key is produced from the agreed + bit string as follows: + + * Truncate the bit string to the appropriate length. + * Rectify parity in each byte (if necessary) to obtain the key. + + For instance, in the case of a DES key, we take the first eight + bytes of the bit stream, and then adjust the least significant bit + of each byte to ensure that each byte has odd parity. Appropriate + key constraints for each valid cryptosystem are given in RFC + 1510bis. + +3.1.2. Algorithm Identifiers + + PKINIT does not define, but does permit, the algorithm identifiers + listed below. + +3.1.2.1. Signature Algorithm Identifiers + + The following signature algorithm identifiers specified in [8] and + in [12] are used with PKINIT: + + id-dsa-with-sha1 (DSA with SHA1) + md5WithRSAEncryption (RSA with MD5) + sha-1WithRSAEncryption (RSA with SHA1) + +3.1.2.2 Diffie-Hellman Key Agreement Algorithm Identifier + + The following algorithm identifier shall be used within the + SubjectPublicKeyInfo data structure: dhpublicnumber + + This identifier and the associated algorithm parameters are + specified in RFC 2459 [12]. + +3.1.2.3. Algorithm Identifiers for RSA Encryption + + These algorithm identifiers are used inside the EnvelopedData data + structure, for encrypting the temporary key with a public key: + + rsaEncryption (RSA encryption, PKCS#1 v1.5) + id-RSAES-OAEP (RSA encryption, PKCS#1 v2.0) + + Both of the above RSA encryption schemes are specified in [13]. + Currently, only PKCS#1 v1.5 is specified by CMS [8], although the + CMS specification says that it will likely include PKCS#1 v2.0 in + the future. (PKCS#1 v2.0 addresses adaptive chosen ciphertext + vulnerability discovered in PKCS#1 v1.5.) + +3.1.2.4. Algorithm Identifiers for Encryption with Secret Keys + + These algorithm identifiers are used inside the EnvelopedData data + structure in the PKINIT Reply, for encrypting the reply key with the + temporary key: + des-ede3-cbc (3-key 3-DES, CBC mode) + rc2-cbc (RC2, CBC mode) + + The full definition of the above algorithm identifiers and their + corresponding parameters (an IV for block chaining) is provided in + the CMS specification [8]. + +3.2. Public Key Authentication + + Implementation of the changes in this section is REQUIRED for + compliance with PKINIT. + +3.2.1. Client Request + + Public keys may be signed by some certification authority (CA), or + they may be maintained by the KDC in which case the KDC is the + trusted authority. Note that the latter mode does not require the + use of certificates. + + The initial authentication request is sent as per RFC 1510bis, except + that a preauthentication field containing data signed by the user's + private key accompanies the request: + + PA-PK-AS-REQ ::= SEQUENCE { + -- PA TYPE 14 + signedAuthPack [0] SignedData + -- Defined in CMS [8]; + -- AuthPack (below) defines the + -- data that is signed. + trustedCertifiers [1] SEQUENCE OF TrustedCas OPTIONAL, + -- This is a list of CAs that the + -- client trusts and that certify + -- KDCs. + kdcCert [2] IssuerAndSerialNumber OPTIONAL + -- As defined in CMS [8]; + -- specifies a particular KDC + -- certificate if the client + -- already has it. + encryptionCert [3] IssuerAndSerialNumber OPTIONAL + -- For example, this may be the + -- client's Diffie-Hellman + -- certificate, or it may be the + -- client's RSA encryption + -- certificate. + } + + TrustedCas ::= CHOICE { + principalName [0] KerberosName, + -- as defined below + caName [1] Name + -- fully qualified X.500 name + -- as defined by X.509 + issuerAndSerial [2] IssuerAndSerialNumber + -- Since a CA may have a number of + -- certificates, only one of which + -- a client trusts + } + + Usage of SignedData: + + The SignedData data type is specified in the Cryptographic + Message Syntax, a product of the S/MIME working group of the + IETF. The following describes how to fill in the fields of + this data: + + 1. The encapContentInfo field MUST contain the PKAuthenticator + and, optionally, the client's Diffie Hellman public value. + + a. The eContentType field MUST contain the OID value for + pkauthdata: iso (1) org (3) dod (6) internet (1) + security (5) kerberosv5 (2) pkinit (3) pkauthdata (1) + + b. The eContent field is data of the type AuthPack (below). + + 2. The signerInfos field contains the signature of AuthPack. + + 3. The Certificates field, when non-empty, contains the client's + certificate chain. If present, the KDC uses the public key + from the client's certificate to verify the signature in the + request. Note that the client may pass different certificate + chains that are used for signing or for encrypting. Thus, + the KDC may utilize a different client certificate for + signature verification than the one it uses to encrypt the + reply to the client. For example, the client may place a + Diffie-Hellman certificate in this field in order to convey + its static Diffie Hellman certificate to the KDC to enable + static-ephemeral Diffie-Hellman mode for the reply; in this + case, the client does NOT place its public value in the + AuthPack (defined below). As another example, the client may + place an RSA encryption certificate in this field. However, + there MUST always be (at least) a signature certificate. + + 4. When a DH key is being used, the public exponent is provided + in the subjectPublicKey field of the SubjectPublicKeyInfo and + the DH parameters are supplied as a DHParameter in the + AlgorithmIdentitfier parameters. The DH paramters SHOULD be + chosen from the First and Second defined Oakley Groups [The + Internet Key Exchange (IKE) RFC-2409], if a server will not + accept either of these groups, it will respond with a krb-error + of KDC_ERR_KEY_TOO_WEAK and the e_data will contain a + DHParameter with appropriate parameters for the client to use. + + 5. The KDC may wish to use cached Diffie-Hellman parameters + (see Section 3.2.2, KDC Response). To indicate acceptance + of cached parameters, the client sends zero in the nonce + field of the PKAuthenticator. Zero is not a valid value + for this field under any other circumstances. If cached + parameters are used, the client and the KDC MUST perform + key derivation (for the appropriate cryptosystem) on the + resulting encryption key, as specified in RFC 1510bis. (With + a zero nonce, message binding is performed using the nonce + in the main request, which must be encrypted using the + encapsulated reply key.) + + AuthPack ::= SEQUENCE { + pkAuthenticator [0] PKAuthenticator, + clientPublicValue [1] SubjectPublicKeyInfo OPTIONAL + -- if client is using Diffie-Hellman + -- (ephemeral-ephemeral only) + } + + PKAuthenticator ::= SEQUENCE { + cusec [0] INTEGER, + -- for replay prevention as in RFC 1510bis + ctime [1] KerberosTime, + -- for replay prevention as in RFC 1510bis + nonce [2] INTEGER, + -- zero only if client will accept + -- cached DH parameters from KDC; + -- must be non-zero otherwise + pachecksum [3] Checksum + -- Checksum over KDC-REQ-BODY + -- Defined by Kerberos spec + } + + SubjectPublicKeyInfo ::= SEQUENCE { + algorithm AlgorithmIdentifier, + -- dhKeyAgreement + subjectPublicKey BIT STRING + -- for DH, equals + -- public exponent (INTEGER encoded + -- as payload of BIT STRING) + } -- as specified by the X.509 recommendation [7] + + AlgorithmIdentifier ::= SEQUENCE { + algorithm OBJECT IDENTIFIER, + -- for dhKeyAgreement, this is + -- { iso (1) member-body (2) US (840) + -- rsadsi (113459) pkcs (1) 3 1 } + -- from PKCS #3 [17] + parameters ANY DEFINED by algorithm OPTIONAL + -- for dhKeyAgreement, this is + -- DHParameter + } -- as specified by the X.509 recommendation [7] + + DHParameter ::= SEQUENCE { + prime INTEGER, + -- p + base INTEGER, + -- g + privateValueLength INTEGER OPTIONAL + -- l + } -- as defined in PKCS #3 [17] + + If the client passes an issuer and serial number in the request, + the KDC is requested to use the referred-to certificate. If none + exists, then the KDC returns an error of type + KDC_ERR_CERTIFICATE_MISMATCH. It also returns this error if, on the + other hand, the client does not pass any trustedCertifiers, + believing that it has the KDC's certificate, but the KDC has more + than one certificate. The KDC should include information in the + KRB-ERROR message that indicates the KDC certificate(s) that a + client may utilize. This data is specified in the e-data, which + is defined in RFC 1510bis revisions as a SEQUENCE of TypedData: + + TypedData ::= SEQUENCE { + data-type [0] INTEGER, + data-value [1] OCTET STRING, + } -- per Kerberos RFC 1510bis + + where: + data-type = TD-PKINIT-CMS-CERTIFICATES = 101 + data-value = CertificateSet // as specified by CMS [8] + + The PKAuthenticator carries information to foil replay attacks, to + bind the pre-authentication data to the KDC-REQ-BODY, and to bind the + request and response. The PKAuthenticator is signed with the client's + signature key. + +3.2.2. KDC Response + + Upon receipt of the AS_REQ with PA-PK-AS-REQ pre-authentication + type, the KDC attempts to verify the user's certificate chain + (userCert), if one is provided in the request. This is done by + verifying the certification path against the KDC's policy of + legitimate certifiers. + + If the client's certificate chain contains no certificate signed by + a CA trusted by the KDC, then the KDC sends back an error message + of type KDC_ERR_CANT_VERIFY_CERTIFICATE. The accompanying e-data + is a SEQUENCE of one TypedData (with type TD-TRUSTED-CERTIFIERS=104) + whose data-value is an OCTET STRING which is the DER encoding of + + TrustedCertifiers ::= SEQUENCE OF PrincipalName + -- X.500 name encoded as a principal name + -- see Section 3.1 + + If while verifying a certificate chain the KDC determines that the + signature on one of the certificates in the CertificateSet from + the signedAuthPack fails verification, then the KDC returns an + error of type KDC_ERR_INVALID_CERTIFICATE. The accompanying + e-data is a SEQUENCE of one TypedData (with type + TD-CERTIFICATE-INDEX=105) whose data-value is an OCTET STRING + which is the DER encoding of the index into the CertificateSet + ordered as sent by the client. + + CertificateIndex ::= INTEGER + -- 0 = 1st certificate, + -- (in order of encoding) + -- 1 = 2nd certificate, etc + + The KDC may also check whether any of the certificates in the + client's chain has been revoked. If one of the certificates has + been revoked, then the KDC returns an error of type + KDC_ERR_REVOKED_CERTIFICATE; if such a query reveals that + the certificate's revocation status is unknown or not + available, then if required by policy, the KDC returns the + appropriate error of type KDC_ERR_REVOCATION_STATUS_UNKNOWN or + KDC_ERR_REVOCATION_STATUS_UNAVAILABLE. In any of these three + cases, the affected certificate is identified by the accompanying + e-data, which contains a CertificateIndex as described for + KDC_ERR_INVALID_CERTIFICATE. + + If the certificate chain can be verified, but the name of the + client in the certificate does not match the client's name in the + request, then the KDC returns an error of type + KDC_ERR_CLIENT_NAME_MISMATCH. There is no accompanying e-data + field in this case. + + Even if all succeeds, the KDC may--for policy reasons--decide not + to trust the client. In this case, the KDC returns an error message + of type KDC_ERR_CLIENT_NOT_TRUSTED. One specific case of this is + the presence or absence of an Enhanced Key Usage (EKU) OID within + the certificate extensions. The rules regarding acceptability of + an EKU sequence (or the absence of any sequence) are a matter of + local policy. For the benefit of implementers, we define a PKINIT + EKU OID as the following: iso (1) org (3) dod (6) internet (1) + security (5) kerberosv5 (2) pkinit (3) pkekuoid (2). + + If a trust relationship exists, the KDC then verifies the client's + signature on AuthPack. If that fails, the KDC returns an error + message of type KDC_ERR_INVALID_SIG. Otherwise, the KDC uses the + timestamp (ctime and cusec) in the PKAuthenticator to assure that + the request is not a replay. The KDC also verifies that its name + is specified in the PKAuthenticator. + + If the clientPublicValue field is filled in, indicating that the + client wishes to use Diffie-Hellman key agreement, then the KDC + checks to see that the parameters satisfy its policy. If they do + not (e.g., the prime size is insufficient for the expected + encryption type), then the KDC sends back an error message of type + KDC_ERR_KEY_TOO_WEAK, with an e-data containing a structure of + type DHParameter with appropriate DH parameters for the client to + retry the request. Otherwise, it generates its own public and + private values for the response. + + The KDC also checks that the timestamp in the PKAuthenticator is + within the allowable window and that the principal name and realm + are correct. If the local (server) time and the client time in the + authenticator differ by more than the allowable clock skew, then the + KDC returns an error message of type KRB_AP_ERR_SKEW as defined in + RFC 1510bis. + + Assuming no errors, the KDC replies as per RFC 1510bis, except as + follows. The user's name in the ticket is determined by the + following decision algorithm: + + 1. If the KDC has a mapping from the name in the certificate + to a Kerberos name, then use that name. + Else + 2. If the certificate contains the SubjectAltName extention + and the local KDC policy defines a mapping from the + SubjectAltName to a Kerberos name, then use that name. + Else + 3. Use the name as represented in the certificate, mapping + as necessary (e.g., as per RFC 2253 for X.500 names). In + this case the realm in the ticket MUST be the name of the + certifier that issued the user's certificate. + + Note that a principal name may be carried in the subjectAltName + field of a certificate. This name may be mapped to a principal + record in a security database based on local policy, for example + the subjectAltName may be kerberos/principal@realm format. In + this case the realm name is not that of the CA but that of the + local realm doing the mapping (or some realm name chosen by that + realm). + + If a non-KDC X.509 certificate contains the principal name within + the subjectAltName version 3 extension, that name may utilize + KerberosName as defined below, or, in the case of an S/MIME + certificate [14], may utilize the email address. If the KDC + is presented with an S/MIME certificate, then the email address + within subjectAltName will be interpreted as a principal and realm + separated by the "@" sign, or as a name that needs to be mapped + according to local policy. If the resulting name does not correspond + to a registered principal name, then the principal name is formed as + defined in section 3.1. + + The trustedCertifiers field contains a list of certification + authorities trusted by the client, in the case that the client does + not possess the KDC's public key certificate. If the KDC has no + certificate signed by any of the trustedCertifiers, then it returns + an error of type KDC_ERR_KDC_NOT_TRUSTED. + + KDCs should try to (in order of preference): + 1. Use the KDC certificate identified by the serialNumber included + in the client's request. + 2. Use a certificate issued to the KDC by one of the client's + trustedCertifier(s); + If the KDC is unable to comply with any of these options, then the + KDC returns an error message of type KDC_ERR_KDC_NOT_TRUSTED to the + client. + + The KDC encrypts the reply not with the user's long-term key, but + with the Diffie Hellman derived key or a random key generated + for this particular response which is carried in the padata field of + the TGS-REP message. + + PA-PK-AS-REP ::= CHOICE { + -- PA TYPE 15 + dhSignedData [0] SignedData, + -- Defined in CMS and used only with + -- Diffie-Hellman key exchange (if the + -- client public value was present in the + -- request). + -- This choice MUST be supported + -- by compliant implementations. + encKeyPack [1] EnvelopedData, + -- Defined in CMS + -- The temporary key is encrypted + -- using the client public key + -- key + -- SignedReplyKeyPack, encrypted + -- with the temporary key, is also + -- included. + } + + Usage of SignedData: + + When the Diffie-Hellman option is used, dhSignedData in + PA-PK-AS-REP provides authenticated Diffie-Hellman parameters + of the KDC. The reply key used to encrypt part of the KDC reply + message is derived from the Diffie-Hellman exchange: + + 1. Both the KDC and the client calculate a secret value + (g^ab mod p), where a is the client's private exponent and + b is the KDC's private exponent. + + 2. Both the KDC and the client take the first N bits of this + secret value and convert it into a reply key. N depends on + the reply key type. + + a. For example, if the reply key is DES, N=64 bits, where + some of the bits are replaced with parity bits, according + to FIPS PUB 74. + + b. As another example, if the reply key is (3-key) 3-DES, + N=192 bits, where some of the bits are replaced with + parity bits, according to FIPS PUB 74. + + 3. The encapContentInfo field MUST contain the KdcDHKeyInfo as + defined below. + + a. The eContentType field MUST contain the OID value for + pkdhkeydata: iso (1) org (3) dod (6) internet (1) + security (5) kerberosv5 (2) pkinit (3) pkdhkeydata (2) + + b. The eContent field is data of the type KdcDHKeyInfo + (below). + + 4. The certificates field MUST contain the certificates + necessary for the client to establish trust in the KDC's + certificate based on the list of trusted certifiers sent by + the client in the PA-PK-AS-REQ. This field may be empty if + the client did not send to the KDC a list of trusted + certifiers (the trustedCertifiers field was empty, meaning + that the client already possesses the KDC's certificate). + + 5. The signerInfos field is a SET that MUST contain at least + one member, since it contains the actual signature. + + 6. If the client indicated acceptance of cached Diffie-Hellman + parameters from the KDC, and the KDC supports such an option + (for performance reasons), the KDC should return a zero in + the nonce field and include the expiration time of the + parameters in the dhKeyExpiration field. If this time is + exceeded, the client SHOULD NOT use the reply. If the time + is absent, the client SHOULD NOT use the reply and MAY + resubmit a request with a non-zero nonce (thus indicating + non-acceptance of cached Diffie-Hellman parameters). As + indicated above in Section 3.2.1, Client Request, when the + KDC uses cached parameters, the client and the KDC MUST + perform key derivation (for the appropriate cryptosystem) + on the resulting encryption key, as specified in RFC 1510bis. + + KdcDHKeyInfo ::= SEQUENCE { + -- used only when utilizing Diffie-Hellman + subjectPublicKey [0] BIT STRING, + -- Equals public exponent (g^a mod p) + -- INTEGER encoded as payload of + -- BIT STRING + nonce [1] INTEGER, + -- Binds response to the request + -- Exception: Set to zero when KDC + -- is using a cached DH value + dhKeyExpiration [2] KerberosTime OPTIONAL + -- Expiration time for KDC's cached + -- DH value + } + + Usage of EnvelopedData: + + The EnvelopedData data type is specified in the Cryptographic + Message Syntax, a product of the S/MIME working group of the + IETF. It contains a temporary key encrypted with the PKINIT + client's public key. It also contains a signed and encrypted + reply key. + + 1. The originatorInfo field is not required, since that + information may be presented in the signedData structure + that is encrypted within the encryptedContentInfo field. + + 2. The optional unprotectedAttrs field is not required for + PKINIT. + + 3. The recipientInfos field is a SET which MUST contain exactly + one member of the KeyTransRecipientInfo type for encryption + with a public key. + + a. The encryptedKey field (in KeyTransRecipientInfo) + contains the temporary key which is encrypted with the + PKINIT client's public key. + + 4. The encryptedContentInfo field contains the signed and + encrypted reply key. + + a. The contentType field MUST contain the OID value for + id-signedData: iso (1) member-body (2) us (840) + rsadsi (113549) pkcs (1) pkcs7 (7) signedData (2) + + b. The encryptedContent field is encrypted data of the CMS + type signedData as specified below. + + i. The encapContentInfo field MUST contains the + ReplyKeyPack. + + * The eContentType field MUST contain the OID value + for pkrkeydata: iso (1) org (3) dod (6) internet (1) + security (5) kerberosv5 (2) pkinit (3) pkrkeydata (3) + + * The eContent field is data of the type ReplyKeyPack + (below). + + ii. The certificates field MUST contain the certificates + necessary for the client to establish trust in the + KDC's certificate based on the list of trusted + certifiers sent by the client in the PA-PK-AS-REQ. + This field may be empty if the client did not send + to the KDC a list of trusted certifiers (the + trustedCertifiers field was empty, meaning that the + client already possesses the KDC's certificate). + + iii. The signerInfos field is a SET that MUST contain at + least one member, since it contains the actual + signature. + + ReplyKeyPack ::= SEQUENCE { + -- not used for Diffie-Hellman + replyKey [0] EncryptionKey, + -- from RFC 1510bis + -- used to encrypt main reply + -- ENCTYPE is at least as strong as + -- ENCTYPE of session key + nonce [1] INTEGER, + -- binds response to the request + -- must be same as the nonce + -- passed in the PKAuthenticator + } + + +3.2.2.1. Use of transited Field + + Since each certifier in the certification path of a user's + certificate is equivalent to a separate Kerberos realm, the name + of each certifier in the certificate chain MUST be added to the + transited field of the ticket. The format of these realm names is + defined in Section 3.1 of this document. If applicable, the + transit-policy-checked flag should be set in the issued ticket. + + +3.2.2.2. Kerberos Names in Certificates + + The KDC's certificate(s) MUST bind the public key(s) of the KDC to + a name derivable from the name of the realm for that KDC. X.509 + certificates MUST contain the principal name of the KDC (defined in + RFC 1510bis) as the SubjectAltName version 3 extension. Below is + the definition of this version 3 extension, as specified by the + X.509 standard: + + subjectAltName EXTENSION ::= { + SYNTAX GeneralNames + IDENTIFIED BY id-ce-subjectAltName + } + + GeneralNames ::= SEQUENCE SIZE(1..MAX) OF GeneralName + + GeneralName ::= CHOICE { + otherName [0] OtherName, + ... + } + + OtherName ::= SEQUENCE { + type-id OBJECT IDENTIFIER, + value [0] EXPLICIT ANY DEFINED BY type-id + } + + For the purpose of specifying a Kerberos principal name, the value + in OtherName MUST be a KerberosName as defined in RFC 1510bis: + + KerberosName ::= SEQUENCE { + realm [0] Realm, + principalName [1] PrincipalName + } + + This specific syntax is identified within subjectAltName by setting + the type-id in OtherName to krb5PrincipalName, where (from the + Kerberos specification) we have + + krb5 OBJECT IDENTIFIER ::= { iso (1) + org (3) + dod (6) + internet (1) + security (5) + kerberosv5 (2) } + + krb5PrincipalName OBJECT IDENTIFIER ::= { krb5 2 } + + (This specification may also be used to specify a Kerberos name + within the user's certificate.) The KDC's certificate may be signed + directly by a CA, or there may be intermediaries if the server resides + within a large organization, or it may be unsigned if the client + indicates possession (and trust) of the KDC's certificate. + + Note that the KDC's principal name has the instance equal to the + realm, and those fields should be appropriately set in the realm + and principalName fields of the KerberosName. This is the case + even when obtaining a cross-realm ticket using PKINIT. + + +3.2.3. Client Extraction of Reply + + The client then extracts the random key used to encrypt the main + reply. This random key (in encPaReply) is encrypted with either the + client's public key or with a key derived from the DH values + exchanged between the client and the KDC. The client uses this + random key to decrypt the main reply, and subsequently proceeds as + described in RFC 1510bis. + +3.2.4. Required Algorithms + + Not all of the algorithms in the PKINIT protocol specification have + to be implemented in order to comply with the proposed standard. + Below is a list of the required algorithms: + + * Diffie-Hellman public/private key pairs + * utilizing Diffie-Hellman ephemeral-ephemeral mode + * SHA1 digest and DSA for signatures + * SHA1 digest also for the Checksum in the PKAuthenticator + * 3-key triple DES keys derived from the Diffie-Hellman Exchange + * 3-key triple DES Temporary and Reply keys + +4. Logistics and Policy + + This section describes a way to define the policy on the use of + PKINIT for each principal and request. + + The KDC is not required to contain a database record for users + who use public key authentication. However, if these users are + registered with the KDC, it is recommended that the database record + for these users be modified to an additional flag in the attributes + field to indicate that the user should authenticate using PKINIT. + If this flag is set and a request message does not contain the + PKINIT preauthentication field, then the KDC sends back as error of + type KDC_ERR_PREAUTH_REQUIRED indicating that a preauthentication + field of type PA-PK-AS-REQ must be included in the request. + +5. Security Considerations + + PKINIT raises a few security considerations, which we will address + in this section. + + First of all, PKINIT introduces a new trust model, where KDCs do not + (necessarily) certify the identity of those for whom they issue + tickets. PKINIT does allow KDCs to act as their own CAs, in the + limited capacity of self-signing their certificates, but one of the + additional benefits is to align Kerberos authentication with a global + public key infrastructure. Anyone using PKINIT in this way must be + aware of how the certification infrastructure they are linking to + works. + + Also, PKINIT introduces the possibility of interactions between + different cryptosystems, which may be of widely varying strengths. + Many systems, for instance, allow the use of 512-bit public keys. + Using such keys to wrap data encrypted under strong conventional + cryptosystems, such as triple-DES, is inappropriate; it adds a + weak link to a strong one at extra cost. Implementors and + administrators should take care to avoid such wasteful and + deceptive interactions. + + Care should be taken in how certificates are choosen for the purposes + of authentication using PKINIT. Some local policies require that key + escrow be applied for certain certificate types. People deploying + PKINIT should be aware of the implications of using certificates that + have escrowed keys for the purposes of authentication. + + As described in Section 3.2, PKINIT allows for the caching of the + Diffie-Hellman parameters on the KDC side, for performance reasons. + For similar reasons, the signed data in this case does not vary from + message to message, until the cached parameters expire. Because of + the persistence of these parameters, the client and the KDC are to + use the appropriate key derivation measures (as described in RFC + 1510bis) when using cached DH parameters. + + Lastly, PKINIT calls for randomly generated keys for conventional + cryptosystems. Many such systems contain systematically "weak" + keys. PKINIT implementations MUST avoid use of these keys, either + by discarding those keys when they are generated, or by fixing them + in some way (e.g., by XORing them with a given mask). These + precautions vary from system to system; it is not our intention to + give an explicit recipe for them here. + +6. Transport Issues + + Certificate chains can potentially grow quite large and span several + UDP packets; this in turn increases the probability that a Kerberos + message involving PKINIT extensions will be broken in transit. In + light of the possibility that the Kerberos specification will + require KDCs to accept requests using TCP as a transport mechanism, + we make the same recommendation with respect to the PKINIT + extensions as well. + +7. Bibliography + + [1] J. Kohl, C. Neuman. The Kerberos Network Authentication Service + (V5). Request for Comments 1510. + + [2] B.C. Neuman, Theodore Ts'o. Kerberos: An Authentication Service + for Computer Networks, IEEE Communications, 32(9):33-38. September + 1994. + + [3] M. Sirbu, J. Chuang. Distributed Authentication in Kerberos + Using Public Key Cryptography. Symposium On Network and Distributed + System Security, 1997. + + [4] B. Cox, J.D. Tygar, M. Sirbu. NetBill Security and Transaction + Protocol. In Proceedings of the USENIX Workshop on Electronic + Commerce, July 1995. + + [5] T. Dierks, C. Allen. The TLS Protocol, Version 1.0 + Request for Comments 2246, January 1999. + + [6] B.C. Neuman, Proxy-Based Authorization and Accounting for + Distributed Systems. In Proceedings of the 13th International + Conference on Distributed Computing Systems, May 1993. + + [7] ITU-T (formerly CCITT) Information technology - Open Systems + Interconnection - The Directory: Authentication Framework + Recommendation X.509 ISO/IEC 9594-8 + + [8] R. Housley. Cryptographic Message Syntax. + draft-ietf-smime-cms-13.txt, April 1999, approved for publication + as RFC. + + [9] PKCS #7: Cryptographic Message Syntax Standard, + An RSA Laboratories Technical Note Version 1.5 + Revised November 1, 1993 + + [10] R. Rivest, MIT Laboratory for Computer Science and RSA Data + Security, Inc. A Description of the RC2(r) Encryption Algorithm + March 1998. + Request for Comments 2268. + + [11] M. Wahl, S. Kille, T. Howes. Lightweight Directory Access + Protocol (v3): UTF-8 String Representation of Distinguished Names. + Request for Comments 2253. + + [12] R. Housley, W. Ford, W. Polk, D. Solo. Internet X.509 Public + Key Infrastructure, Certificate and CRL Profile, January 1999. + Request for Comments 2459. + + [13] B. Kaliski, J. Staddon. PKCS #1: RSA Cryptography + Specifications, October 1998. Request for Comments 2437. + + [14] S. Dusse, P. Hoffman, B. Ramsdell, J. Weinstein. S/MIME + Version 2 Certificate Handling, March 1998. Request for + Comments 2312. + + [15] M. Wahl, T. Howes, S. Kille. Lightweight Directory Access + Protocol (v3), December 1997. Request for Comments 2251. + + [16] ITU-T (formerly CCITT) Information Processing Systems - Open + Systems Interconnection - Specification of Abstract Syntax Notation + One (ASN.1) Rec. X.680 ISO/IEC 8824-1 + + [17] PKCS #3: Diffie-Hellman Key-Agreement Standard, An RSA + Laboratories Technical Note, Version 1.4, Revised November 1, 1993. + +8. Acknowledgements + + Some of the ideas on which this proposal is based arose during + discussions over several years between members of the SAAG, the IETF + CAT working group, and the PSRG, regarding integration of Kerberos + and SPX. Some ideas have also been drawn from the DASS system. + These changes are by no means endorsed by these groups. This is an + attempt to revive some of the goals of those groups, and this + proposal approaches those goals primarily from the Kerberos + perspective. Lastly, comments from groups working on similar ideas + in DCE have been invaluable. + +9. Expiration Date + + This draft expires January 15, 2002. + +10. Authors + + Brian Tung + Clifford Neuman + USC Information Sciences Institute + 4676 Admiralty Way Suite 1001 + Marina del Rey CA 90292-6695 + Phone: +1 310 822 1511 + E-mail: {brian, bcn}@isi.edu + + Matthew Hur + Cisco Systems + 500 108th Ave. NE, Suite 500 + Bellevue, WA 98004 + Phone: (408) 525-0034 + E-Mail: mhur@cisco.com + + Ari Medvinsky + Keen.com, Inc. + 150 Independence Drive + Menlo Park CA 94025 + Phone: +1 650 289 3134 + E-mail: ari@keen.com + + Sasha Medvinsky + Motorola + 6450 Sequence Drive + San Diego, CA 92121 + +1 858 404 2367 + E-mail: smedvinsky@gi.com + + John Wray + Iris Associates, Inc. + 5 Technology Park Dr. + Westford, MA 01886 + E-mail: John_Wray@iris.com + + Jonathan Trostle + Cisco Systems + 170 W. Tasman Dr. + San Jose, CA 95134 + E-mail: jtrostle@cisco.com diff --git a/doc/standardisation/draft-ietf-cat-kerberos-pk-init-15.txt b/doc/standardisation/draft-ietf-cat-kerberos-pk-init-15.txt new file mode 100644 index 000000000..7d5a223eb --- /dev/null +++ b/doc/standardisation/draft-ietf-cat-kerberos-pk-init-15.txt @@ -0,0 +1,1116 @@ +INTERNET-DRAFT Brian Tung +draft-ietf-cat-kerberos-pk-init-15.txt Clifford Neuman +Updates: RFC 1510bis USC/ISI +expires May 25, 2002 Matthew Hur + Cisco + Ari Medvinsky + Keen.com, Inc. + Sasha Medvinsky + Motorola + John Wray + Iris Associates, Inc. + Jonathan Trostle + Cisco + + Public Key Cryptography for Initial Authentication in Kerberos + +0. Status Of This Memo + + This document is an Internet-Draft and is in full conformance with + all provisions of Section 10 of RFC 2026. Internet-Drafts are + working documents of the Internet Engineering Task Force (IETF), + its areas, and its working groups. Note that other groups may also + distribute working documents as Internet-Drafts. + + Internet-Drafts are draft documents valid for a maximum of six + months and may be updated, replaced, or obsoleted by other + documents at any time. It is inappropriate to use Internet-Drafts + as reference material or to cite them other than as "work in + progress." + + The list of current Internet-Drafts can be accessed at + http://www.ietf.org/ietf/1id-abstracts.txt + + The list of Internet-Draft Shadow Directories can be accessed at + http://www.ietf.org/shadow.html. + + To learn the current status of any Internet-Draft, please check + the "1id-abstracts.txt" listing contained in the Internet-Drafts + Shadow Directories on ftp.ietf.org (US East Coast), + nic.nordu.net (Europe), ftp.isi.edu (US West Coast), or + munnari.oz.au (Pacific Rim). + + The distribution of this memo is unlimited. It is filed as + draft-ietf-cat-kerberos-pk-init-15.txt, and expires May 25, 2002. + Please send comments to the authors. + +1. Abstract + + This document defines extensions (PKINIT) to the Kerberos protocol + specification (RFC 1510bis [1]) to provide a method for using public + key cryptography during initial authentication. The methods + defined specify the ways in which preauthentication data fields and + error data fields in Kerberos messages are to be used to transport + public key data. + +2. Introduction + + The popularity of public key cryptography has produced a desire for + its support in Kerberos [2]. The advantages provided by public key + cryptography include simplified key management (from the Kerberos + perspective) and the ability to leverage existing and developing + public key certification infrastructures. + + Public key cryptography can be integrated into Kerberos in a number + of ways. One is to associate a key pair with each realm, which can + then be used to facilitate cross-realm authentication; this is the + topic of another draft proposal. Another way is to allow users with + public key certificates to use them in initial authentication. This + is the concern of the current document. + + PKINIT utilizes ephemeral-ephemeral Diffie-Hellman keys in + combination with DSA keys as the primary, required mechanism. Note + that PKINIT supports the use of separate signature and encryption + keys. + + PKINIT enables access to Kerberos-secured services based on initial + authentication utilizing public key cryptography. PKINIT utilizes + standard public key signature and encryption data formats within the + standard Kerberos messages. The basic mechanism is as follows: The + user sends an AS-REQ message to the KDC as before, except that if that + user is to use public key cryptography in the initial authentication + step, his certificate and a signature accompany the initial request + in the preauthentication fields. Upon receipt of this request, the + KDC verifies the certificate and issues a ticket granting ticket + (TGT) as before, except that the encPart from the AS-REP message + carrying the TGT is now encrypted utilizing either a Diffie-Hellman + derived key or the user's public key. This message is authenticated + utilizing the public key signature of the KDC. + + Note that PKINIT does not require the use of certificates. A KDC + may store the public key of a principal as part of that principal's + record. In this scenario, the KDC is the trusted party that vouches + for the principal (as in a standard, non-cross realm, Kerberos + environment). Thus, for any principal, the KDC may maintain a + symmetric key, a public key, or both. + + The PKINIT specification may also be used as a building block for + other specifications. PKINIT may be utilized to establish + inter-realm keys for the purposes of issuing cross-realm service + tickets. It may also be used to issue anonymous Kerberos tickets + using the Diffie-Hellman option. Efforts are under way to draft + specifications for these two application protocols. + + Additionally, the PKINIT specification may be used for direct peer + to peer authentication without contacting a central KDC. This + application of PKINIT is based on concepts introduced in [6, 7]. + For direct client-to-server authentication, the client uses PKINIT + to authenticate to the end server (instead of a central KDC), which + then issues a ticket for itself. This approach has an advantage + over TLS [5] in that the server does not need to save state (cache + session keys). Furthermore, an additional benefit is that Kerberos + tickets can facilitate delegation (see [6]). + +3. Proposed Extensions + + This section describes extensions to RFC 1510bis for supporting the + use of public key cryptography in the initial request for a ticket + granting ticket (TGT). + + In summary, the following change to RFC 1510bis is proposed: + + * Users may authenticate using either a public key pair or a + conventional (symmetric) key. If public key cryptography is + used, public key data is transported in preauthentication + data fields to help establish identity. The user presents + a public key certificate and obtains an ordinary TGT that may + be used for subsequent authentication, with such + authentication using only conventional cryptography. + + Section 3.1 provides definitions to help specify message formats. + Section 3.2 describes the extensions for the initial authentication + method. + +3.1. Definitions + + The extensions involve new preauthentication fields; we introduce + the following preauthentication types: + + PA-PK-AS-REQ 14 + PA-PK-AS-REP 15 + + The extensions also involve new error types; we introduce the + following types: + + KDC_ERR_CLIENT_NOT_TRUSTED 62 + KDC_ERR_KDC_NOT_TRUSTED 63 + KDC_ERR_INVALID_SIG 64 + KDC_ERR_KEY_TOO_WEAK 65 + KDC_ERR_CERTIFICATE_MISMATCH 66 + KDC_ERR_CANT_VERIFY_CERTIFICATE 70 + KDC_ERR_INVALID_CERTIFICATE 71 + KDC_ERR_REVOKED_CERTIFICATE 72 + KDC_ERR_REVOCATION_STATUS_UNKNOWN 73 + KDC_ERR_REVOCATION_STATUS_UNAVAILABLE 74 + KDC_ERR_CLIENT_NAME_MISMATCH 75 + KDC_ERR_KDC_NAME_MISMATCH 76 + + We utilize the following typed data for errors: + + TD-PKINIT-CMS-CERTIFICATES 101 + TD-KRB-PRINCIPAL 102 + TD-KRB-REALM 103 + TD-TRUSTED-CERTIFIERS 104 + TD-CERTIFICATE-INDEX 105 + + We utilize the following encryption types (which map directly to + OIDs): + + dsaWithSHA1-CmsOID 9 + md5WithRSAEncryption-CmsOID 10 + sha1WithRSAEncryption-CmsOID 11 + rc2CBC-EnvOID 12 + rsaEncryption-EnvOID (PKCS#1 v1.5) 13 + rsaES-OAEP-ENV-OID (PKCS#1 v2.0) 14 + des-ede3-cbc-Env-OID 15 + + These mappings are provided so that a client may send the + appropriate enctypes in the AS-REQ message in order to indicate + support for the corresponding OIDs (for performing PKINIT). The + above encryption types are utilized only within CMS structures + within the PKINIT preauthentication fields. Their use within + the Kerberos EncryptedData structure is unspecified. + + In many cases, PKINIT requires the encoding of the X.500 name of a + certificate authority as a Realm. When such a name appears as + a realm it will be represented using the "Other" form of the realm + name as specified in the naming constraints section of RFC 1510bis. + For a realm derived from an X.500 name, NAMETYPE will have the value + X500-RFC2253. The full realm name will appear as follows: + + + ":" + + + where nametype is "X500-RFC2253" and string is the result of doing + an RFC2253 encoding of the distinguished name, i.e. + + "X500-RFC2253:" + RFC2253Encode(DistinguishedName) + + where DistinguishedName is an X.500 name, and RFC2253Encode is a + function returing a readable UTF encoding of an X.500 name, as + defined by RFC 2253 [11] (part of LDAPv3 [15]). + + Each component of a DistinguishedName is called a + RelativeDistinguishedName, where a RelativeDistinguishedName is a + SET OF AttributeTypeAndValue. RFC 2253 does not specify the order + in which to encode the elements of the RelativeDistinguishedName and + so to ensure that this encoding is unique, we add the following rule + to those specified by RFC 2253: + + When converting a multi-valued RelativeDistinguishedName + to a string, the output consists of the string encodings + of each AttributeTypeAndValue, in the same order as + specified by the DER encoding. + + Similarly, in cases where the KDC does not provide a specific + policy-based mapping from the X.500 name or X.509 Version 3 + SubjectAltName extension in the user's certificate to a Kerberos + principal name, PKINIT requires the direct encoding of the X.500 + name as a PrincipalName. In this case, the name-type of the + principal name MUST be set to KRB_NT-X500-PRINCIPAL. This new + name type is defined in RFC 1510bis as: + + KRB_NT_X500_PRINCIPAL 6 + + For this type, the name-string MUST be set as follows: + + RFC2253Encode(DistinguishedName) + + as described above. When this name type is used, the principal's + realm MUST be set to the certificate authority's distinguished + name using the X500-RFC2253 realm name format described earlier in + this section. + + Note that the same string may be represented using several different + ASN.1 data types. As the result, the reverse conversion from an + RFC2253-encoded principal name back to an X.500 name may not be + unique and may result in an X.500 name that is not the same as the + original X.500 name found in the client certificate. + + RFC 1510bis describes an alternate encoding of an X.500 name into a + realm name. However, as described in RFC 1510bis, the alternate + encoding does not guarantee a unique mapping from a + DistinguishedName inside a certificate into a realm name and + similarly cannot be used to produce a unique principal name. PKINIT + therefore uses an RFC 2253-based name mapping approach, as specified + above. + + RFC 1510bis specifies the ASN.1 structure for PrincipalName as follows: + + PrincipalName ::= SEQUENCE { + name-type[0] INTEGER, + name-string[1] SEQUENCE OF GeneralString + } + + The following rules relate to the the matching of PrincipalNames + with regard to the PKI name constraints for CAs as laid out in RFC + 2459 [12]. In order to be regarded as a match (for permitted and + excluded name trees), the following MUST be satisfied. + + 1. If the constraint is given as a user plus realm name, or + as a client principal name plus realm name (as specified in + RFC 1510bis), the realm name MUST be valid (see 2.a-d below) + and the match MUST be exact, byte for byte. + + 2. If the constraint is given only as a realm name, matching + depends on the type of the realm: + + a. If the realm contains a colon (':') before any equal + sign ('='), it is treated as a realm of type Other, + and MUST match exactly, byte for byte. + + b. Otherwise, if the realm name conforms to rules regarding + the format of DNS names, it is considered a realm name of + type Domain. The constraint may be given as a realm + name 'FOO.BAR', which matches any PrincipalName within + the realm 'FOO.BAR' but not those in subrealms such as + 'CAR.FOO.BAR'. A constraint of the form '.FOO.BAR' + matches PrincipalNames in subrealms of the form + 'CAR.FOO.BAR' but not the realm 'FOO.BAR' itself. + + c. Otherwise, the realm name is invalid and does not match + under any conditions. + +3.1.1. Encryption and Key Formats + + In the exposition below, we use the terms public key and private + key generically. It should be understood that the term "public + key" may be used to refer to either a public encryption key or a + signature verification key, and that the term "private key" may be + used to refer to either a private decryption key or a signature + generation key. The fact that these are logically distinct does + not preclude the assignment of bitwise identical keys for RSA + keys. + + In the case of Diffie-Hellman, the key is produced from the agreed + bit string as follows: + + * Truncate the bit string to the required length. + * Apply the specific cryptosystem's random-to-key function. + + Appropriate key constraints for each valid cryptosystem are given + in RFC 1510bis. + +3.1.2. Algorithm Identifiers + + PKINIT does not define, but does permit, the algorithm identifiers + listed below. + +3.1.2.1. Signature Algorithm Identifiers + + The following signature algorithm identifiers specified in [8] and + in [12] are used with PKINIT: + + id-dsa-with-sha1 (DSA with SHA1) + md5WithRSAEncryption (RSA with MD5) + sha-1WithRSAEncryption (RSA with SHA1) + +3.1.2.2 Diffie-Hellman Key Agreement Algorithm Identifier + + The following algorithm identifier shall be used within the + SubjectPublicKeyInfo data structure: dhpublicnumber + + This identifier and the associated algorithm parameters are + specified in RFC 2459 [12]. + +3.1.2.3. Algorithm Identifiers for RSA Encryption + + These algorithm identifiers are used inside the EnvelopedData data + structure, for encrypting the temporary key with a public key: + + rsaEncryption (RSA encryption, PKCS#1 v1.5) + id-RSAES-OAEP (RSA encryption, PKCS#1 v2.0) + + Both of the above RSA encryption schemes are specified in [13]. + Currently, only PKCS#1 v1.5 is specified by CMS [8], although the + CMS specification says that it will likely include PKCS#1 v2.0 in + the future. (PKCS#1 v2.0 addresses adaptive chosen ciphertext + vulnerability discovered in PKCS#1 v1.5.) + +3.1.2.4. Algorithm Identifiers for Encryption with Secret Keys + + These algorithm identifiers are used inside the EnvelopedData data + structure in the PKINIT Reply, for encrypting the reply key with the + temporary key: + des-ede3-cbc (3-key 3-DES, CBC mode) + rc2-cbc (RC2, CBC mode) + + The full definition of the above algorithm identifiers and their + corresponding parameters (an IV for block chaining) is provided in + the CMS specification [8]. + +3.2. Public Key Authentication + + Implementation of the changes in this section is REQUIRED for + compliance with PKINIT. + +3.2.1. Client Request + + Public keys may be signed by some certification authority (CA), or + they may be maintained by the KDC in which case the KDC is the + trusted authority. Note that the latter mode does not require the + use of certificates. + + The initial authentication request is sent as per RFC 1510bis, except + that a preauthentication field containing data signed by the user's + private key accompanies the request: + + PA-PK-AS-REQ ::= SEQUENCE { + -- PA TYPE 14 + signedAuthPack [0] ContentInfo, + -- Defined in CMS [8]; + -- SignedData OID is {pkcs7 2} + -- AuthPack (below) defines the + -- data that is signed. + trustedCertifiers [1] SEQUENCE OF TrustedCas OPTIONAL, + -- This is a list of CAs that the + -- client trusts and that certify + -- KDCs. + kdcCert [2] IssuerAndSerialNumber OPTIONAL + -- As defined in CMS [8]; + -- specifies a particular KDC + -- certificate if the client + -- already has it. + encryptionCert [3] IssuerAndSerialNumber OPTIONAL + -- For example, this may be the + -- client's Diffie-Hellman + -- certificate, or it may be the + -- client's RSA encryption + -- certificate. + } + + TrustedCas ::= CHOICE { + principalName [0] KerberosName, + -- as defined below + caName [1] Name + -- fully qualified X.500 name + -- as defined by X.509 + issuerAndSerial [2] IssuerAndSerialNumber + -- Since a CA may have a number of + -- certificates, only one of which + -- a client trusts + } + + The type of the ContentInfo in the signedAuthPack is SignedData. + Its usage is as follows: + + The SignedData data type is specified in the Cryptographic + Message Syntax, a product of the S/MIME working group of the + IETF. The following describes how to fill in the fields of + this data: + + 1. The encapContentInfo field MUST contain the PKAuthenticator + and, optionally, the client's Diffie Hellman public value. + + a. The eContentType field MUST contain the OID value for + pkauthdata: iso (1) org (3) dod (6) internet (1) + security (5) kerberosv5 (2) pkinit (3) pkauthdata (1) + + b. The eContent field is data of the type AuthPack (below). + + 2. The signerInfos field contains the signature of AuthPack. + + 3. The Certificates field, when non-empty, contains the client's + certificate chain. If present, the KDC uses the public key + from the client's certificate to verify the signature in the + request. Note that the client may pass different certificate + chains that are used for signing or for encrypting. Thus, + the KDC may utilize a different client certificate for + signature verification than the one it uses to encrypt the + reply to the client. For example, the client may place a + Diffie-Hellman certificate in this field in order to convey + its static Diffie Hellman certificate to the KDC to enable + static-ephemeral Diffie-Hellman mode for the reply; in this + case, the client does NOT place its public value in the + AuthPack (defined below). As another example, the client may + place an RSA encryption certificate in this field. However, + there MUST always be (at least) a signature certificate. + + 4. When a DH key is being used, the public exponent is provided + in the subjectPublicKey field of the SubjectPublicKeyInfo and + the DH parameters are supplied as a DHParameter in the + AlgorithmIdentitfier parameters. The DH paramters SHOULD be + chosen from the First and Second defined Oakley Groups [The + Internet Key Exchange (IKE) RFC-2409], if a server will not + accept either of these groups, it will respond with a krb-error + of KDC_ERR_KEY_TOO_WEAK and the e_data will contain a + DHParameter with appropriate parameters for the client to use. + + 5. The KDC may wish to use cached Diffie-Hellman parameters + (see Section 3.2.2, KDC Response). To indicate acceptance + of cached parameters, the client sends zero in the nonce + field of the PKAuthenticator. Zero is not a valid value + for this field under any other circumstances. If cached + parameters are used, the client and the KDC MUST perform + key derivation (for the appropriate cryptosystem) on the + resulting encryption key, as specified in RFC 1510bis. (With + a zero nonce, message binding is performed using the nonce + in the main request, which must be encrypted using the + encapsulated reply key.) + + AuthPack ::= SEQUENCE { + pkAuthenticator [0] PKAuthenticator, + clientPublicValue [1] SubjectPublicKeyInfo OPTIONAL + -- if client is using Diffie-Hellman + -- (ephemeral-ephemeral only) + } + + PKAuthenticator ::= SEQUENCE { + cusec [0] INTEGER, + -- for replay prevention as in RFC 1510bis + ctime [1] KerberosTime, + -- for replay prevention as in RFC 1510bis + nonce [2] INTEGER, + -- zero only if client will accept + -- cached DH parameters from KDC; + -- must be non-zero otherwise + pachecksum [3] Checksum + -- Checksum over KDC-REQ-BODY + -- Defined by Kerberos spec; + -- must be unkeyed, e.g. sha1 or rsa-md5 + } + + SubjectPublicKeyInfo ::= SEQUENCE { + algorithm AlgorithmIdentifier, + -- dhKeyAgreement + subjectPublicKey BIT STRING + -- for DH, equals + -- public exponent (INTEGER encoded + -- as payload of BIT STRING) + } -- as specified by the X.509 recommendation [7] + + AlgorithmIdentifier ::= SEQUENCE { + algorithm OBJECT IDENTIFIER, + -- for dhKeyAgreement, this is + -- { iso (1) member-body (2) US (840) + -- rsadsi (113459) pkcs (1) 3 1 } + -- from PKCS #3 [17] + parameters ANY DEFINED by algorithm OPTIONAL + -- for dhKeyAgreement, this is + -- DHParameter + } -- as specified by the X.509 recommendation [7] + + DHParameter ::= SEQUENCE { + prime INTEGER, + -- p + base INTEGER, + -- g + privateValueLength INTEGER OPTIONAL + -- l + } -- as defined in PKCS #3 [17] + + If the client passes an issuer and serial number in the request, + the KDC is requested to use the referred-to certificate. If none + exists, then the KDC returns an error of type + KDC_ERR_CERTIFICATE_MISMATCH. It also returns this error if, on the + other hand, the client does not pass any trustedCertifiers, + believing that it has the KDC's certificate, but the KDC has more + than one certificate. The KDC should include information in the + KRB-ERROR message that indicates the KDC certificate(s) that a + client may utilize. This data is specified in the e-data, which + is defined in RFC 1510bis revisions as a SEQUENCE of TypedData: + + TypedData ::= SEQUENCE { + data-type [0] INTEGER, + data-value [1] OCTET STRING, + } -- per Kerberos RFC 1510bis + + where: + data-type = TD-PKINIT-CMS-CERTIFICATES = 101 + data-value = CertificateSet // as specified by CMS [8] + + The PKAuthenticator carries information to foil replay attacks, to + bind the pre-authentication data to the KDC-REQ-BODY, and to bind the + request and response. The PKAuthenticator is signed with the client's + signature key. + +3.2.2. KDC Response + + Upon receipt of the AS_REQ with PA-PK-AS-REQ pre-authentication + type, the KDC attempts to verify the user's certificate chain + (userCert), if one is provided in the request. This is done by + verifying the certification path against the KDC's policy of + legitimate certifiers. + + If the client's certificate chain contains no certificate signed by + a CA trusted by the KDC, then the KDC sends back an error message + of type KDC_ERR_CANT_VERIFY_CERTIFICATE. The accompanying e-data + is a SEQUENCE of one TypedData (with type TD-TRUSTED-CERTIFIERS=104) + whose data-value is an OCTET STRING which is the DER encoding of + + TrustedCertifiers ::= SEQUENCE OF PrincipalName + -- X.500 name encoded as a principal name + -- see Section 3.1 + + If while verifying a certificate chain the KDC determines that the + signature on one of the certificates in the CertificateSet from + the signedAuthPack fails verification, then the KDC returns an + error of type KDC_ERR_INVALID_CERTIFICATE. The accompanying + e-data is a SEQUENCE of one TypedData (with type + TD-CERTIFICATE-INDEX=105) whose data-value is an OCTET STRING + which is the DER encoding of the index into the CertificateSet + ordered as sent by the client. + + CertificateIndex ::= INTEGER + -- 0 = 1st certificate, + -- (in order of encoding) + -- 1 = 2nd certificate, etc + + The KDC may also check whether any of the certificates in the + client's chain has been revoked. If one of the certificates has + been revoked, then the KDC returns an error of type + KDC_ERR_REVOKED_CERTIFICATE; if such a query reveals that + the certificate's revocation status is unknown or not + available, then if required by policy, the KDC returns the + appropriate error of type KDC_ERR_REVOCATION_STATUS_UNKNOWN or + KDC_ERR_REVOCATION_STATUS_UNAVAILABLE. In any of these three + cases, the affected certificate is identified by the accompanying + e-data, which contains a CertificateIndex as described for + KDC_ERR_INVALID_CERTIFICATE. + + If the certificate chain can be verified, but the name of the + client in the certificate does not match the client's name in the + request, then the KDC returns an error of type + KDC_ERR_CLIENT_NAME_MISMATCH. There is no accompanying e-data + field in this case. + + Even if all succeeds, the KDC may--for policy reasons--decide not + to trust the client. In this case, the KDC returns an error message + of type KDC_ERR_CLIENT_NOT_TRUSTED. One specific case of this is + the presence or absence of an Enhanced Key Usage (EKU) OID within + the certificate extensions. The rules regarding acceptability of + an EKU sequence (or the absence of any sequence) are a matter of + local policy. For the benefit of implementers, we define a PKINIT + EKU OID as the following: iso (1) org (3) dod (6) internet (1) + security (5) kerberosv5 (2) pkinit (3) pkekuoid (2). + + If a trust relationship exists, the KDC then verifies the client's + signature on AuthPack. If that fails, the KDC returns an error + message of type KDC_ERR_INVALID_SIG. Otherwise, the KDC uses the + timestamp (ctime and cusec) in the PKAuthenticator to assure that + the request is not a replay. The KDC also verifies that its name + is specified in the PKAuthenticator. + + If the clientPublicValue field is filled in, indicating that the + client wishes to use Diffie-Hellman key agreement, then the KDC + checks to see that the parameters satisfy its policy. If they do + not (e.g., the prime size is insufficient for the expected + encryption type), then the KDC sends back an error message of type + KDC_ERR_KEY_TOO_WEAK, with an e-data containing a structure of + type DHParameter with appropriate DH parameters for the client to + retry the request. Otherwise, it generates its own public and + private values for the response. + + The KDC also checks that the timestamp in the PKAuthenticator is + within the allowable window and that the principal name and realm + are correct. If the local (server) time and the client time in the + authenticator differ by more than the allowable clock skew, then the + KDC returns an error message of type KRB_AP_ERR_SKEW as defined in + RFC 1510bis. + + Assuming no errors, the KDC replies as per RFC 1510bis, except as + follows. The user's name in the ticket is determined by the + following decision algorithm: + + 1. If the KDC has a mapping from the name in the certificate + to a Kerberos name, then use that name. + Else + 2. If the certificate contains the SubjectAltName extention + and the local KDC policy defines a mapping from the + SubjectAltName to a Kerberos name, then use that name. + Else + 3. Use the name as represented in the certificate, mapping + as necessary (e.g., as per RFC 2253 for X.500 names). In + this case the realm in the ticket MUST be the name of the + certifier that issued the user's certificate. + + Note that a principal name may be carried in the subjectAltName + field of a certificate. This name may be mapped to a principal + record in a security database based on local policy, for example + the subjectAltName may be kerberos/principal@realm format. In + this case the realm name is not that of the CA but that of the + local realm doing the mapping (or some realm name chosen by that + realm). + + If a non-KDC X.509 certificate contains the principal name within + the subjectAltName version 3 extension, that name may utilize + KerberosName as defined below, or, in the case of an S/MIME + certificate [14], may utilize the email address. If the KDC + is presented with an S/MIME certificate, then the email address + within subjectAltName will be interpreted as a principal and realm + separated by the "@" sign, or as a name that needs to be mapped + according to local policy. If the resulting name does not correspond + to a registered principal name, then the principal name is formed as + defined in section 3.1. + + The trustedCertifiers field contains a list of certification + authorities trusted by the client, in the case that the client does + not possess the KDC's public key certificate. If the KDC has no + certificate signed by any of the trustedCertifiers, then it returns + an error of type KDC_ERR_KDC_NOT_TRUSTED. + + KDCs should try to (in order of preference): + 1. Use the KDC certificate identified by the serialNumber included + in the client's request. + 2. Use a certificate issued to the KDC by one of the client's + trustedCertifier(s); + If the KDC is unable to comply with any of these options, then the + KDC returns an error message of type KDC_ERR_KDC_NOT_TRUSTED to the + client. + + The KDC encrypts the reply not with the user's long-term key, but + with the Diffie Hellman derived key or a random key generated + for this particular response which is carried in the padata field of + the TGS-REP message. + + PA-PK-AS-REP ::= CHOICE { + -- PA TYPE 15 + dhSignedData [0] ContentInfo, + -- Defined in CMS [8] and used only with + -- Diffie-Hellman key exchange (if the + -- client public value was present in the + -- request). + -- SignedData OID is {pkcs7 2} + -- This choice MUST be supported + -- by compliant implementations. + encKeyPack [1] ContentInfo + -- Defined in CMS [8]. + -- The temporary key is encrypted + -- using the client public key + -- key. + -- EnvelopedData OID is {pkcs7 3} + -- SignedReplyKeyPack, encrypted + -- with the temporary key, is also + -- included. + } + + The type of the ContentInfo in the dhSignedData is SignedData. + Its usage is as follows: + + When the Diffie-Hellman option is used, dhSignedData in + PA-PK-AS-REP provides authenticated Diffie-Hellman parameters + of the KDC. The reply key used to encrypt part of the KDC reply + message is derived from the Diffie-Hellman exchange: + + 1. Both the KDC and the client calculate a secret value + (g^ab mod p), where a is the client's private exponent and + b is the KDC's private exponent. + + 2. Both the KDC and the client take the first N bits of this + secret value and convert it into a reply key. N depends on + the reply key type. + + a. For example, if the reply key is DES, N=64 bits, where + some of the bits are replaced with parity bits, according + to FIPS PUB 74. + + b. As another example, if the reply key is (3-key) 3-DES, + N=192 bits, where some of the bits are replaced with + parity bits, according to FIPS PUB 74. + + 3. The encapContentInfo field MUST contain the KdcDHKeyInfo as + defined below. + + a. The eContentType field MUST contain the OID value for + pkdhkeydata: iso (1) org (3) dod (6) internet (1) + security (5) kerberosv5 (2) pkinit (3) pkdhkeydata (2) + + b. The eContent field is data of the type KdcDHKeyInfo + (below). + + 4. The certificates field MUST contain the certificates + necessary for the client to establish trust in the KDC's + certificate based on the list of trusted certifiers sent by + the client in the PA-PK-AS-REQ. This field may be empty if + the client did not send to the KDC a list of trusted + certifiers (the trustedCertifiers field was empty, meaning + that the client already possesses the KDC's certificate). + + 5. The signerInfos field is a SET that MUST contain at least + one member, since it contains the actual signature. + + 6. If the client indicated acceptance of cached Diffie-Hellman + parameters from the KDC, and the KDC supports such an option + (for performance reasons), the KDC should return a zero in + the nonce field and include the expiration time of the + parameters in the dhKeyExpiration field. If this time is + exceeded, the client SHOULD NOT use the reply. If the time + is absent, the client SHOULD NOT use the reply and MAY + resubmit a request with a non-zero nonce (thus indicating + non-acceptance of cached Diffie-Hellman parameters). As + indicated above in Section 3.2.1, Client Request, when the + KDC uses cached parameters, the client and the KDC MUST + perform key derivation (for the appropriate cryptosystem) + on the resulting encryption key, as specified in RFC 1510bis. + + KdcDHKeyInfo ::= SEQUENCE { + -- used only when utilizing Diffie-Hellman + subjectPublicKey [0] BIT STRING, + -- Equals public exponent (g^a mod p) + -- INTEGER encoded as payload of + -- BIT STRING + nonce [1] INTEGER, + -- Binds response to the request + -- Exception: Set to zero when KDC + -- is using a cached DH value + dhKeyExpiration [2] KerberosTime OPTIONAL + -- Expiration time for KDC's cached + -- DH value + } + + The type of the ContentInfo in the encKeyPack is EnvelopedData. Its + usage is as follows: + + The EnvelopedData data type is specified in the Cryptographic + Message Syntax, a product of the S/MIME working group of the + IETF. It contains a temporary key encrypted with the PKINIT + client's public key. It also contains a signed and encrypted + reply key. + + 1. The originatorInfo field is not required, since that + information may be presented in the signedData structure + that is encrypted within the encryptedContentInfo field. + + 2. The optional unprotectedAttrs field is not required for + PKINIT. + + 3. The recipientInfos field is a SET which MUST contain exactly + one member of the KeyTransRecipientInfo type for encryption + with a public key. + + a. The encryptedKey field (in KeyTransRecipientInfo) + contains the temporary key which is encrypted with the + PKINIT client's public key. + + 4. The encryptedContentInfo field contains the signed and + encrypted reply key. + + a. The contentType field MUST contain the OID value for + id-signedData: iso (1) member-body (2) us (840) + rsadsi (113549) pkcs (1) pkcs7 (7) signedData (2) + + b. The encryptedContent field is encrypted data of the CMS + type signedData as specified below. + + i. The encapContentInfo field MUST contains the + ReplyKeyPack. + + * The eContentType field MUST contain the OID value + for pkrkeydata: iso (1) org (3) dod (6) internet (1) + security (5) kerberosv5 (2) pkinit (3) pkrkeydata (3) + + * The eContent field is data of the type ReplyKeyPack + (below). + + ii. The certificates field MUST contain the certificates + necessary for the client to establish trust in the + KDC's certificate based on the list of trusted + certifiers sent by the client in the PA-PK-AS-REQ. + This field may be empty if the client did not send + to the KDC a list of trusted certifiers (the + trustedCertifiers field was empty, meaning that the + client already possesses the KDC's certificate). + + iii. The signerInfos field is a SET that MUST contain at + least one member, since it contains the actual + signature. + + ReplyKeyPack ::= SEQUENCE { + -- not used for Diffie-Hellman + replyKey [0] EncryptionKey, + -- from RFC 1510bis + -- used to encrypt main reply + -- ENCTYPE is at least as strong as + -- ENCTYPE of session key + nonce [1] INTEGER, + -- binds response to the request + -- must be same as the nonce + -- passed in the PKAuthenticator + } + + +3.2.2.1. Use of transited Field + + Since each certifier in the certification path of a user's + certificate is equivalent to a separate Kerberos realm, the name + of each certifier in the certificate chain MUST be added to the + transited field of the ticket. The format of these realm names is + defined in Section 3.1 of this document. If applicable, the + transit-policy-checked flag should be set in the issued ticket. + + +3.2.2.2. Kerberos Names in Certificates + + The KDC's certificate(s) MUST bind the public key(s) of the KDC to + a name derivable from the name of the realm for that KDC. X.509 + certificates MUST contain the principal name of the KDC (defined in + RFC 1510bis) as the SubjectAltName version 3 extension. Below is + the definition of this version 3 extension, as specified by the + X.509 standard: + + subjectAltName EXTENSION ::= { + SYNTAX GeneralNames + IDENTIFIED BY id-ce-subjectAltName + } + + GeneralNames ::= SEQUENCE SIZE(1..MAX) OF GeneralName + + GeneralName ::= CHOICE { + otherName [0] OtherName, + ... + } + + OtherName ::= SEQUENCE { + type-id OBJECT IDENTIFIER, + value [0] EXPLICIT ANY DEFINED BY type-id + } + + For the purpose of specifying a Kerberos principal name, the value + in OtherName MUST be a KerberosName, defined as follows: + + KerberosName ::= SEQUENCE { + realm [0] Realm, + principalName [1] PrincipalName + } + + This specific syntax is identified within subjectAltName by setting + the type-id in OtherName to krb5PrincipalName, where (from the + Kerberos specification) we have + + krb5 OBJECT IDENTIFIER ::= { iso (1) + org (3) + dod (6) + internet (1) + security (5) + kerberosv5 (2) } + + krb5PrincipalName OBJECT IDENTIFIER ::= { krb5 2 } + + (This specification may also be used to specify a Kerberos name + within the user's certificate.) The KDC's certificate may be signed + directly by a CA, or there may be intermediaries if the server resides + within a large organization, or it may be unsigned if the client + indicates possession (and trust) of the KDC's certificate. + + Note that the KDC's principal name has the instance equal to the + realm, and those fields should be appropriately set in the realm + and principalName fields of the KerberosName. This is the case + even when obtaining a cross-realm ticket using PKINIT. + + +3.2.3. Client Extraction of Reply + + The client then extracts the random key used to encrypt the main + reply. This random key (in encPaReply) is encrypted with either the + client's public key or with a key derived from the DH values + exchanged between the client and the KDC. The client uses this + random key to decrypt the main reply, and subsequently proceeds as + described in RFC 1510bis. + +3.2.4. Required Algorithms + + Not all of the algorithms in the PKINIT protocol specification have + to be implemented in order to comply with the proposed standard. + Below is a list of the required algorithms: + + * Diffie-Hellman public/private key pairs + * utilizing Diffie-Hellman ephemeral-ephemeral mode + * SHA1 digest and DSA for signatures + * SHA1 digest for the Checksum in the PKAuthenticator + * using Kerberos checksum type 'sha1' + * 3-key triple DES keys derived from the Diffie-Hellman Exchange + * 3-key triple DES Temporary and Reply keys + +4. Logistics and Policy + + This section describes a way to define the policy on the use of + PKINIT for each principal and request. + + The KDC is not required to contain a database record for users + who use public key authentication. However, if these users are + registered with the KDC, it is recommended that the database record + for these users be modified to an additional flag in the attributes + field to indicate that the user should authenticate using PKINIT. + If this flag is set and a request message does not contain the + PKINIT preauthentication field, then the KDC sends back as error of + type KDC_ERR_PREAUTH_REQUIRED indicating that a preauthentication + field of type PA-PK-AS-REQ must be included in the request. + +5. Security Considerations + + PKINIT raises a few security considerations, which we will address + in this section. + + First of all, PKINIT extends the cross-realm model to the public + key infrastructure. Anyone using PKINIT must be aware of how the + certification infrastructure they are linking to works. + + Also, as in standard Kerberos, PKINIT presents the possibility of + interactions between different cryptosystems of varying strengths, + and this now includes public-key cryptosystems. Many systems, for + instance, allow the use of 512-bit public keys. Using such keys + to wrap data encrypted under strong conventional cryptosystems, + such as triple-DES, may be inappropriate. + + Care should be taken in how certificates are choosen for the purposes + of authentication using PKINIT. Some local policies require that key + escrow be applied for certain certificate types. People deploying + PKINIT should be aware of the implications of using certificates that + have escrowed keys for the purposes of authentication. + + As described in Section 3.2, PKINIT allows for the caching of the + Diffie-Hellman parameters on the KDC side, for performance reasons. + For similar reasons, the signed data in this case does not vary from + message to message, until the cached parameters expire. Because of + the persistence of these parameters, the client and the KDC are to + use the appropriate key derivation measures (as described in RFC + 1510bis) when using cached DH parameters. + + Lastly, PKINIT calls for randomly generated keys for conventional + cryptosystems. Many such systems contain systematically "weak" + keys. For recommendations regarding these weak keys, see RFC + 1510bis. + +6. Transport Issues + + Certificate chains can potentially grow quite large and span several + UDP packets; this in turn increases the probability that a Kerberos + message involving PKINIT extensions will be broken in transit. In + light of the possibility that the Kerberos specification will + require KDCs to accept requests using TCP as a transport mechanism, + we make the same recommendation with respect to the PKINIT + extensions as well. + +7. Bibliography + + [1] J. Kohl, C. Neuman. The Kerberos Network Authentication Service + (V5). Request for Comments 1510. + + [2] B.C. Neuman, Theodore Ts'o. Kerberos: An Authentication Service + for Computer Networks, IEEE Communications, 32(9):33-38. September + 1994. + + [3] M. Sirbu, J. Chuang. Distributed Authentication in Kerberos + Using Public Key Cryptography. Symposium On Network and Distributed + System Security, 1997. + + [4] B. Cox, J.D. Tygar, M. Sirbu. NetBill Security and Transaction + Protocol. In Proceedings of the USENIX Workshop on Electronic + Commerce, July 1995. + + [5] T. Dierks, C. Allen. The TLS Protocol, Version 1.0 + Request for Comments 2246, January 1999. + + [6] B.C. Neuman, Proxy-Based Authorization and Accounting for + Distributed Systems. In Proceedings of the 13th International + Conference on Distributed Computing Systems, May 1993. + + [7] ITU-T (formerly CCITT) Information technology - Open Systems + Interconnection - The Directory: Authentication Framework + Recommendation X.509 ISO/IEC 9594-8 + + [8] R. Housley. Cryptographic Message Syntax. + draft-ietf-smime-cms-13.txt, April 1999, approved for publication + as RFC. + + [9] PKCS #7: Cryptographic Message Syntax Standard, + An RSA Laboratories Technical Note Version 1.5 + Revised November 1, 1993 + + [10] R. Rivest, MIT Laboratory for Computer Science and RSA Data + Security, Inc. A Description of the RC2(r) Encryption Algorithm + March 1998. + Request for Comments 2268. + + [11] M. Wahl, S. Kille, T. Howes. Lightweight Directory Access + Protocol (v3): UTF-8 String Representation of Distinguished Names. + Request for Comments 2253. + + [12] R. Housley, W. Ford, W. Polk, D. Solo. Internet X.509 Public + Key Infrastructure, Certificate and CRL Profile, January 1999. + Request for Comments 2459. + + [13] B. Kaliski, J. Staddon. PKCS #1: RSA Cryptography + Specifications, October 1998. Request for Comments 2437. + + [14] S. Dusse, P. Hoffman, B. Ramsdell, J. Weinstein. S/MIME + Version 2 Certificate Handling, March 1998. Request for + Comments 2312. + + [15] M. Wahl, T. Howes, S. Kille. Lightweight Directory Access + Protocol (v3), December 1997. Request for Comments 2251. + + [16] ITU-T (formerly CCITT) Information Processing Systems - Open + Systems Interconnection - Specification of Abstract Syntax Notation + One (ASN.1) Rec. X.680 ISO/IEC 8824-1 + + [17] PKCS #3: Diffie-Hellman Key-Agreement Standard, An RSA + Laboratories Technical Note, Version 1.4, Revised November 1, 1993. + +8. Acknowledgements + + Some of the ideas on which this proposal is based arose during + discussions over several years between members of the SAAG, the IETF + CAT working group, and the PSRG, regarding integration of Kerberos + and SPX. Some ideas have also been drawn from the DASS system. + These changes are by no means endorsed by these groups. This is an + attempt to revive some of the goals of those groups, and this + proposal approaches those goals primarily from the Kerberos + perspective. Lastly, comments from groups working on similar ideas + in DCE have been invaluable. + +9. Expiration Date + + This draft expires May 25, 2002. + +10. Authors + + Brian Tung + Clifford Neuman + USC Information Sciences Institute + 4676 Admiralty Way Suite 1001 + Marina del Rey CA 90292-6695 + Phone: +1 310 822 1511 + E-mail: {brian, bcn}@isi.edu + + Matthew Hur + Cisco Systems + 2901 Third Avenue + Seattle WA 98121 + Phone: (206) 256-3197 + E-Mail: mhur@cisco.com + + Ari Medvinsky + Keen.com, Inc. + 150 Independence Drive + Menlo Park CA 94025 + Phone: +1 650 289 3134 + E-mail: ari@keen.com + + Sasha Medvinsky + Motorola + 6450 Sequence Drive + San Diego, CA 92121 + +1 858 404 2367 + E-mail: smedvinsky@gi.com + + John Wray + Iris Associates, Inc. + 5 Technology Park Dr. + Westford, MA 01886 + E-mail: John_Wray@iris.com + + Jonathan Trostle + Cisco Systems + 170 W. Tasman Dr. + San Jose, CA 95134 + E-mail: jtrostle@cisco.com diff --git a/doc/standardisation/draft-ietf-cat-kerberos-pk-init-17.txt b/doc/standardisation/draft-ietf-cat-kerberos-pk-init-17.txt index 29c4ad6b2..174d0502f 100644 --- a/doc/standardisation/draft-ietf-cat-kerberos-pk-init-17.txt +++ b/doc/standardisation/draft-ietf-cat-kerberos-pk-init-17.txt @@ -1,4 +1,3 @@ - INTERNET-DRAFT Brian Tung draft-ietf-cat-kerberos-pk-init-17.txt Clifford Neuman Updates: RFC 1510bis USC/ISI @@ -804,4 +803,3 @@ E-mail: John_Wray@iris.com Jonathan Trostle E-mail: jtrostle@world.std.com - diff --git a/doc/standardisation/draft-ietf-cat-kerberos-pk-init-20.txt b/doc/standardisation/draft-ietf-cat-kerberos-pk-init-20.txt index 3f494f27e..0504450b8 100644 --- a/doc/standardisation/draft-ietf-cat-kerberos-pk-init-20.txt +++ b/doc/standardisation/draft-ietf-cat-kerberos-pk-init-20.txt @@ -11,50 +11,35 @@ expires January 25, 2005 Matthew Hur Jonathan Trostle - Public Key Cryptography for Initial Authentication in Kerberos - 0. Status Of This Memo - -By submitting this Internet-Draft, I certify that any applicable -patent or other IPR claims of which I am aware have been disclosed, -or will be disclosed, and any of which I become aware will be -disclosed, in accordance with RFC 3668. - - This document is an Internet-Draft and is in full conformance with all provision of Section 10 of RFC 2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. - Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." - The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt - The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html - The distribution of this memo is unlimited. It is filed as draft-ietf-cat-kerberos-pk-init-20.txt and expires January 25, 2005. Please send comments to the authors. - 1. Abstract - This document describes protocol extensions (hereafter called PKINIT) to the Kerberos protocol specification ([1], hereafter called CLARIFICATIONS). These extensions provide a method for @@ -63,10 +48,8 @@ exchange, by passing digital certificates and associated authenticators in preauthentication data fields. - 2. Introduction - A client typically authenticates itself to a service in Kerberos using three distinct though related exchanges. First, the client requests a ticket-granting ticket (TGT) from the Kerberos @@ -78,7 +61,6 @@ will refer to both the AS and the TGS as the KDC.) Finally, the client uses the service ticket to authenticate itself to the service. - The advantage afforded by the TGT is that the client need explicitly request a ticket and expose his credentials only once. The TGT and its associated session key can then be used for any subsequent @@ -88,14 +70,12 @@ performed. Consequently, initial authentication provides a convenient place to integrate public-key cryptography into Kerberos authentication. - As defined, Kerberos authentication exchanges use symmetric-key cryptography, in part for performance. One cost of using symmetric-key cryptography is that the keys must be shared, so that before a client can authenticate itself, he must already be registered with the KDC. - Conversely, public-key cryptography (in conjunction with an established Public Key Infrastructure) permits authentication without prior registration with a KDC. Adding it to Kerberos allows @@ -103,7 +83,6 @@ the widespread use of Kerberized applications by clients without requiring them to register first with a KDC--a requirement that has no inherent security benefit. - As noted above, a convenient and efficient place to introduce public-key cryptography into Kerberos is in the initial authentication exchange. This document describes the methods and @@ -111,100 +90,75 @@ data formats for integrating public-key cryptography into Kerberos initial authentication. - 3. Extensions - This section describes extensions to CLARIFICATIONS for supporting the use of public-key cryptography in the initial request for a ticket. - Briefly, this document defines the following extensions to CLARIFICATIONS: - 1. The client indicates the use of public-key authentication by including a special preauthenticator in the initial request. This preauthenticator contains the client's public-key data and a signature. - 2. The KDC tests the client's request against its policy and trusted Certification Authorities (CAs). - 3. If the request passes the verification tests, the KDC replies as usual, but the reply is encrypted using either: - a. a symmetric encryption key, signed using the KDC's signature key and encrypted using the client's encryption key; or - b. a key generated through a Diffie-Hellman exchange with the client, signed using the KDC's signature key. - Any keying material required by the client to obtain the Encryption key is returned in a preauthentication field accompanying the usual reply. - 4. The client obtains the encryption key, decrypts the reply, and then proceeds as usual. - Section 3.1 of this document defines the necessary message formats. Section 3.2 describes their syntax and use in greater detail. - 3.1. Definitions - 3.1.1. Required Algorithms - All PKINIT implementations MUST support the following algorithms: - - Reply key (or DH-derived key): AES256-CTS-HMAC-SHA1-96 etype. - - Signature algorithm: SHA-1 digest and RSA. - - Reply key delivery method: ephemeral-ephemeral Diffie-Hellman with a non-zero nonce. - - Unkeyed checksum type for the paChecksum member of PKAuthenticator: SHA1 (unkeyed). - 3.1.2. Defined Message and Encryption Types - PKINIT makes use of the following new preauthentication types: - PA-PK-AS-REQ TBD PA-PK-AS-REP TBD - PKINIT also makes use of the following new authorization data type: - AD-INITIAL-VERIFIED-CAS TBD - PKINIT introduces the following new error codes: - KDC_ERR_CLIENT_NOT_TRUSTED 62 KDC_ERR_KDC_NOT_TRUSTED 63 KDC_ERR_INVALID_SIG 64 @@ -216,20 +170,16 @@ PKINIT introduces the following new error codes: KDC_ERR_REVOCATION_STATUS_UNKNOWN 73 KDC_ERR_CLIENT_NAME_MISMATCH 75 - PKINIT uses the following typed data types for errors: - TD-DH-PARAMETERS TBD TD-TRUSTED-CERTIFIERS 104 TD-CERTIFICATE-INDEX 105 - PKINIT defines the following encryption types, for use in the AS-REQ message (to indicate acceptance of the corresponding encryption OIDs in PKINIT): - dsaWithSHA1-CmsOID 9 md5WithRSAEncryption-CmsOID 10 sha1WithRSAEncryption-CmsOID 11 @@ -238,81 +188,63 @@ in PKINIT): rsaES-OAEP-EnvOID (PKCS1 v2.0) 14 des-ede3-cbc-EnvOID 15 - The above encryption types are used by the client only within the KDC-REQ-BODY to indicate which CMS [2] algorithms it supports. Their use within Kerberos EncryptedData structures is not specified by this document. - The ASN.1 module for all structures defined in this document (plus IMPORT statements for all imported structures) are given in Appendix A. All structures MUST be encoded using Distinguished Encoding Rules (DER). - 3.1.3. Algorithm Identifiers - PKINIT does not define, but does make use of, the following algorithm identifiers. - PKINIT uses the following algorithm identifier for Diffie-Hellman key agreement [9]: - dhpublicnumber - PKINIT uses the following signature algorithm identifiers [8, 12]: - sha-1WithRSAEncryption (RSA with SHA1) md5WithRSAEncryption (RSA with MD5) id-dsa-with-sha1 (DSA with SHA1) - PKINIT uses the following encryption algorithm identifiers [5] for encrypting the temporary key with a public key: - rsaEncryption (PKCS1 v1.5) id-RSAES-OAEP (PKCS1 v2.0) - PKINIT uses the following algorithm identifiers [2] for encrypting the reply key with the temporary key: - des-ede3-cbc (three-key 3DES, CBC mode) rc2-cbc (RC2, CBC mode) - Kerberos data structures require the use of integer etypes, while CMS objects use OIDs. Therefore, each cryptographic algorithm supported by PKINIT is identified both by a CMS OID and by an equivalent Kerberos etype (defined in section 3.1.2). - 3.2. PKINIT Preauthentication Syntax and Use - This section defines the syntax and use of the various preauthentication fields employed by PKINIT. - 3.2.1. Client Request - The initial authentication request (AS-REQ) is sent as per RFC 1510bis; in addition, a preauthentication field contains data signed by the client's private signature key, as follows: - PA-PK-AS-REQ ::= SEQUENCE { signedAuthPack [0] ContentInfo, -- Defined in CMS [2]. @@ -331,7 +263,6 @@ by the client's private signature key, as follows: ... } - TrustedCA ::= CHOICE { caName [0] Name, -- Fully qualified X.500 name @@ -342,7 +273,6 @@ by the client's private signature key, as follows: ... } - AuthPack ::= SEQUENCE { pkAuthenticator [0] PKAuthenticator, clientPublicValue [1] SubjectPublicKeyInfo OPTIONAL, @@ -358,7 +288,6 @@ by the client's private signature key, as follows: ... } - PKAuthenticator ::= SEQUENCE { cusec [0] INTEGER, ctime [1] KerberosTime, @@ -379,24 +308,19 @@ by the client's private signature key, as follows: ... } - The ContentInfo in the signedAuthPack is filled out as follows: - 1. The eContent field contains data of type AuthPack. It MUST contain the pkAuthenticator, and MAY also contain the client's Diffie-Hellman public value (clientPublicValue). - 2. The eContentType field MUST contain the OID value for id-pkauthdata: { iso(1) org(3) dod(6) internet(1) security(5) kerberosv5(2) pkinit(3) pkauthdata(1)} - 3. The signerInfos field MUST contain the signature over the AuthPack. - 4. The certificates field MUST contain at least a signature verification certificate chain that the KDC can use to verify the signature over the AuthPack. Additionally, the @@ -404,12 +328,10 @@ The ContentInfo in the signedAuthPack is filled out as follows: (for example) the client is not using ephemeral-ephemeral Diffie-Hellman. - 5. If a Diffie-Hellman key is being used, the parameters SHOULD be chosen from the First or Second defined Oakley Groups. (See RFC 2409 [10].) - 6. The KDC may wish to use cached Diffie-Hellman parameters. To indicate acceptance of caching, the client sends zero in the nonce field of the pkAuthenticator. Zero is not a valid @@ -419,15 +341,12 @@ The ContentInfo in the signedAuthPack is filled out as follows: nonce in the main request. - 3.2.2. Validation of Client Request - Upon receiving the client's request, the KDC validates it. This section describes the steps that the KDC MUST (unless otherwise noted) take in validating the request. - The KDC must look for a client certificate in the signedAuthPack. If it cannot find one signed by a CA it trusts, it sends back an error of type KDC_ERR_CANT_VERIFY_CERTIFICATE. The accompanying @@ -435,10 +354,8 @@ e-data for this error is a SEQUENCE OF TYPED-DATA (as defined in RFC 1510bis). For this error, the data-type is TD-TRUSTED-CERTIFIERS, and the data-value is an OCTET STRING containing the DER encoding of - TrustedCertifiers ::= SEQUENCE OF Name - If, while verifying the certificate chain, the KDC determines that the signature on one of the certificates in the signedAuthPack is invalid, it returns an error of type KDC_ERR_INVALID_CERTIFICATE. @@ -447,16 +364,13 @@ whose data-type is TD-CERTIFICATE-INDEX, and whose data-value is an OCTET STRING containing the DER encoding of the index into the CertificateSet field, ordered as sent by the client: - CertificateIndex ::= IssuerAndSerialNumber -- IssuerAndSerialNumber of -- certificate with invalid signature - If more than one certificate signature is invalid, the KDC MAY send one TYPED-DATA per invalid signature. - The KDC MAY also check whether any certificates in the client's chain have been revoked. If any of them have been revoked, the KDC MUST return an error of type KDC_ERR_REVOKED_CERTIFICATE; if the KDC @@ -465,39 +379,31 @@ it SHOULD return an error of type KDC_ERR_REVOCATION_STATUS_UNKNOWN. The certificate or certificates affected are identified exactly as for an error of type KDC_ERR_INVALID_CERTIFICATE (see above). - In addition to validating the certificate chain, the KDC MUST also check that the certificate properly maps to the client's principal name as specified in the AS-REQ as follows: - 1. If the KDC has its own mapping from the name in the certificate to a Kerberos name, it uses that Kerberos name. - 2. Otherwise, if the certificate contains a SubjectAltName extension with a Kerberos name in the otherName field, it uses that name. The otherName field (of type AnotherName) in the SubjectAltName extension MUST contain the following: - The type-id is: - krb5PrincipalName OBJECT IDENTIFIER ::= { iso (1) org (3) dod (6) internet (1) security (5) kerberosv5 (2) 2 } - The value is: - KRB5PrincipalName ::= SEQUENCE { realm [0] Realm, principalName [1] PrincipalName } - If the KDC does not have its own mapping and there is no Kerberos name present in the certificate, or if the name in the request does not match the name in the certificate (including the realm name), or @@ -505,7 +411,6 @@ if there is no name in the request, the KDC MUST return error code KDC_ERR_CLIENT_NAME_MISMATCH. There is no accompanying e-data for this error. - Even if the chain is validated, and the names in the certificate and the request match, the KDC may decide not to trust the client. For example, the certificate may include an Enxtended Key Usage (EKU) OID @@ -514,23 +419,19 @@ decide to reject requests on the basis of the absence or presence of specific EKU OIDs. In this case, the KDC MUST return error code KDC_ERR_CLIENT_NOT_TRUSTED. The PKINIT EKU OID is defined as: - { iso(1) org(3) dod(6) internet(1) security(5) kerberosv5(2) pkinit(3) pkekuoid(4) } - If the client's signature on the signedAuthPack fails to verify, the KDC MUST return error KDC_ERR_INVALID_SIG. There is no accompanying e-data for this error. - The KDC MUST check the timestamp to ensure that the request is not a replay, and that the time skew falls within acceptable limits. The recommendations clock skew times in CLARIFICATIONS apply here. If the check fails, the KDC MUSTreturn error code KRB_AP_ERR_REPEAT or KRB_AP_ERR_SKEW, respectively. - If the clientPublicValue is filled in, indicating that the client wishes to use ephemeral-ephemeral Diffie-Hellman, the KDC checks to see if the parameters satisfy its policy. If they do not, it MUST @@ -540,18 +441,15 @@ whose data-value is an OCTET STRING containing the DER encoding of a DomainParameters (see [3]), including appropriate Diffie-Hellman parameters with which to retry the request. - The KDC MUST return error code KDC_ERR_CERTIFICATE_MISMATCH if the client included a kdcCert field in the PA-PK-AS-REQ and the KDC does not have the corresponding certificate. - The KDC MUST return error code KDC_ERR_KDC_NOT_TRUSTED if the client did not include a kdcCert field, but did include a trustedCertifiers field, and the KDC does not possesses a certificate issued by one of the listed certifiers. - If there is a supportedCMSTypes field in the AuthPack, the KDC must check to see if it supports any of the listed types. If it supports more than one of the types, the KDC SHOULD use the one listed first. @@ -559,26 +457,21 @@ If it does not support any of them, it MUST return an error of type KRB5KDC_ERR_ETYPE_NOSUPP. - 3.2.3. KDC Reply - Assuming that the client's request has been properly validated, the KDC proceeds as per CLARIFICATIONS, except as follows. - The KDC MUST set the initial flag and include an authorization data of type AD-INITIAL-VERIFIED-CAS in the issued ticket. The value is an OCTET STRING containing the DER encoding of InitialVerifiedCAs: - InitialVerifiedCAs ::= SEQUENCE OF SEQUENCE { ca [0] Name, Validated [1] BOOLEAN, ... } - The KDC MAY wrap any AD-INITIAL-VERIFIED-CAS data in AD-IF-RELEVANT containers if the list of CAs satisfies the KDC's realm's policy. (This corresponds to the TRANSITED-POLICY-CHECKED ticket flag.) @@ -586,7 +479,6 @@ Furthermore, any TGS must copy such authorization data from tickets used in a PA-TGS-REQ of the TGS-REQ to the resulting ticket, including the AD-IF-RELEVANT container, if present. - Application servers that understand this authorization data type SHOULD apply local policy to determine whether a given ticket bearing such a type *not* contained within an AD-IF-RELEVANT @@ -596,7 +488,6 @@ has not been set.) If such a data type is contained within an AD-IF-RELEVANT container, AP servers MAY apply local policy to determine whether the authorization data is acceptable. - The AS-REP is otherwise unchanged from CLARIFICATIONS. The KDC encrypts the reply as usual, but not with the client's long-term key. Instead, it encrypts it with either a generated encryption @@ -604,7 +495,6 @@ key, or a key derived from a Diffie-Hellman exchange. The contents of the PA-PK-AS-REP indicate the type of encryption key that was used: - PA-PK-AS-REP ::= CHOICE { dhSignedData [0] ContentInfo, -- Type is SignedData. @@ -617,7 +507,6 @@ used: ... } - KDCDHKeyInfo ::= SEQUENCE { subjectPublicKey [0] BIT STRING, -- Equals public exponent @@ -635,23 +524,18 @@ used: ... } - The fields of the ContentInfo for dhSignedData are to be filled in as follows: - 1. The eContent field contains data of type KDCDHKeyInfo. - 2. The eContentType field contains the OID value for id-pkdhkeydata: { iso(1) org(3) dod(6) internet(1) security(5) kerberosv5(2) pkinit(3) pkdhkeydata(2) } - 3. The signerInfos field contains a single signerInfo, which is the signature of the KDCDHKeyInfo. - 4. The certificates field contains a signature verification certificate chain that the client will use to verify the KDC's signature over the KDCDHKeyInfo. This field may only @@ -659,7 +543,6 @@ as follows: the PA-PK-AS-REQ, indicating that it has the KDC's certificate. - 5. If the client and KDC agree to use cached parameters, the KDC MUST return a zero in the nonce field and include the expiration time of the cached values in the dhKeyExpiration @@ -668,7 +551,6 @@ as follows: the reply and MAY resubmit a request with a non-zero nonce, thus indicating non-acceptance of the cached parameters. - The key is derived as follows: Both the KDC and the client calculate the value g^(ab) mod p, where a and b are the client's and KDC's private exponents, respectively. They both take the first k bits of @@ -678,12 +560,10 @@ specified in [6]. The seed is then converted into a protocol key by applying to it a random-to-key function, which is also dependent on key type. - If the KDC and client are not using Diffie-Hellman, the KDC encrypts the reply with an encryption key, packed in the encKeyPack, which contains data of type ReplyKeyPack: - ReplyKeyPack ::= SEQUENCE { replyKey [0] EncryptionKey, -- Defined in CLARIFICATIONS. @@ -699,57 +579,46 @@ contains data of type ReplyKeyPack: ... } - The fields of the ContentInfo for encKeyPack MUST be filled in as follows: - 1. The content is of type SignedData. The eContent for the SignedData is of type ReplyKeyPack. - 2. The eContentType for the SignedData contains the OID value for id-pkrkeydata: { iso(1) org(3) dod(6) internet(1) security(5) kerberosv5(2) pkinit(3) pkrkeydata(3) } - 3. The signerInfos field contains a single signerInfo, which is the signature of the ReplyKeyPack. - 4. The certificates field contains a signature verification certificate chain that the client will use to verify the KDC's signature over the ReplyKeyPack. This field may only be left empty if the client included a kdcCert field in the PA-PK-AS-REQ, indicating that it has the KDC's certificate. - 5. The contentType for the EnvelopedData contains the OID value for id-signedData: { iso (1) member-body (2) us (840) rsadsi (113549) pkcs (1) pkcs7 (7) signedData (2) } - 6. The recipientInfos field is a SET which MUST contain exactly one member of type KeyTransRecipientInfo. The encryptedKey for this member contains the temporary key which is encrypted using the client's public key. - 7. The unprotectedAttrs or originatorInfo fields MAY be present. - 3.2.4. Validation of KDC Reply - Upon receipt of the KDC's reply, the client proceeds as follows. If the PA-PK-AS-REP contains a dhSignedData, the client obtains and verifies the Diffie-Hellman parameters, and obtains the shared key as described above. Otherwise, the message contains an encKeyPack, and the client decrypts and verifies the temporary encryption key. - In either case, the client MUST check to see if the included certificate contains a subjectAltName extension of type dNSName or iPAddress (if the KDC is specified by IP address instead of name). @@ -758,34 +627,27 @@ it believes it is communicating with, with matching rules specified in RFC 2459. Exception: If the client has some external information as to the identity of the KDC, this check MAY be omitted. - The client also MUST check that the KDC's certificate contains an extendedKeyUsage OID of id-pkkdcekuoid: - { iso(1) org(3) dod(6) internet(1) security(5) kerberosv5(2) pkinit(3) pkkdcekuoid(5) } - If all applicable checks are satisfied, the client then decrypts the main reply with the resulting key, and then proceeds as described in CLARIFICATIONS. - 4. Security Considerations - PKINIT raises certain security considerations beyond those that can be regulated strictly in protocol definitions. We will address them in this section. - PKINIT extends the cross-realm model to the public-key infrastructure. Users of PKINIT must understand security policies and procedures appropriate to the use of Public Key Infrastructures. - Standard Kerberos allows the possibility of interactions between cryptosystems of varying strengths; this document adds interactions with public-key cryptosystems to Kerberos. Some administrative @@ -793,12 +655,10 @@ policies may allow the use of relatively weak public keys. Using such keys to wrap data encrypted under stronger conventional cryptosystems may be inappropriate. - PKINIT requires keys for symmetric cryptosystems to be generated. Some such systems contain "weak" keys. For recommendations regarding these weak keys, see CLARIFICATIONS. - PKINIT allows the use of a zero nonce in the PKAuthenticator when cached Diffie-Hellman keys are used. In this case, message binding is performed using the nonce in the main request in the same way as @@ -809,7 +669,6 @@ cryptographically binds the PKINIT pre-authenticator to the main body of the AS Request and also provides message integrity for the full AS Request. - However, when a PKINIT pre-authenticator in the AS-REP has a zero-nonce, and an attacker has somehow recorded this pre-authenticator and discovered the corresponding Diffie-Hellman @@ -821,7 +680,6 @@ and it is therefore important for clients to check this expiration time and for the expiration time to be reasonably short, which depends on the size of the Diffie-Hellman group. - If a client also caches its Diffie-Hellman keys, then the session key could remain the same during multiple AS-REQ/AS-REP exchanges and an attacker which compromised the session key could fabricate his own @@ -830,14 +688,12 @@ client starts using a new Diffie-Hellman key pair and while the KDC pre-authenticator has not yet expired. It is therefore not recommended for KDC clients to also cache their Diffie-Hellman keys. - Care should be taken in how certificates are chosen for the purposes of authentication using PKINIT. Some local policies may require that key escrow be used for certain certificate types. Deployers of PKINIT should be aware of the implications of using certificates that have escrowed keys for the purposes of authentication. - PKINIT does not provide for a "return routability" test to prevent attackers from mounting a denial-of-service attack on the KDC by causing it to perform unnecessary and expensive public-key @@ -845,17 +701,14 @@ operations. Strictly speaking, this is also true of standard Kerberos, although the potential cost is not as great, because standard Kerberos does not make use of public-key cryptography. - The syntax for the AD-INITIAL-VERIFIED-CAS authorization data does permit empty SEQUENCEs to be encoded. Such empty sequences may only be used if the KDC itself vouches for the user's certificate. [This seems to reflect the consensus of the Kerberos working group.] - 5. Acknowledgements - Some of the ideas on which this document is based arose during discussions over several years between members of the SAAG, the IETF CAT working group, and the PSRG, regarding integration of Kerberos @@ -867,66 +720,51 @@ perspective. Lastly, comments from groups working on similar ideas in DCE have been invaluable. - 6. Expiration Date - This draft expires January 25, 2004. - 7. Bibliography - [1] RFC-Editor: To be replaced by RFC number for draft-ietf-krb-wg-kerberos-clarifications. - [2] R. Housley. Cryptographic Message Syntax., April 1999. Request For Comments 2630. - [3] W. Polk, R. Housley, and L. Bassham. Algorithms and Identifiers for the Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile, April 2002. Request For Comments 3279. - [4] R. Housley, W. Polk, W. Ford, D. Solo. Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile, April 2002. Request for Comments 3280. - [5] B. Kaliski, J. Staddon. PKCS #1: RSA Cryptography Specifications, October 1998. Request for Comments 2437. - [6] RFC-Editor: To be replaced by RFC number for draft-ietf-krb-wg-crypto. - [7] S. Blake-Wilson, M. Nystrom, D. Hopwood, J. Mikkelsen, and T. Wright. Transport Layer Security (TLS) Extensions, June 2003. Request for Comments 3546. - [8] M. Myers, R. Ankney, A. Malpani, S. Galperin, and C. Adams. Internet X.509 Public Key Infrastructure: Online Certificate Status Protocol - OCSP, June 1999. Request for Comments 2560. - [9] NIST, Guidelines for Implementing and Using the NBS Encryption Standard, April 1981. FIPS PUB 74. - [10] D. Harkins and D. Carrel. The Internet Key Exchange (IKE), November 1998. Request for Comments 2409. - 8. Authors - Brian Tung Clifford Neuman USC Information Sciences Institute @@ -935,7 +773,6 @@ Marina del Rey CA 90292-6695 Phone: +1 310 822 1511 E-mail: {brian,bcn}@isi.edu - Matthew Hur Ari Medvinsky Microsoft Corporation @@ -944,7 +781,6 @@ Redmond WA 98052 Phone: +1 425 707 3336 E-mail: matthur@microsoft.com, arimed@windows.microsoft.com - Sasha Medvinsky Motorola, Inc. 6450 Sequence Drive @@ -952,73 +788,60 @@ San Diego, CA 92121 +1 858 404 2367 E-mail: smedvinsky@motorola.com - John Wray Iris Associates, Inc. 5 Technology Park Dr. Westford, MA 01886 E-mail: John_Wray@iris.com - Jonathan Trostle E-mail: jtrostle@world.std.com - Appendix A. PKINIT ASN.1 Module - KerberosV5-PK-INIT-SPEC { iso(1) identified-organization(3) dod(6) internet(1) security(5) kerberosV5(2) modules(4) pkinit(TBD) } DEFINITIONS EXPLICIT TAGS ::= BEGIN - IMPORTS SubjectPublicKeyInfo, AlgorithmIdentifier, Name FROM PKIX1Explicit88 { iso (1) identified-organization (3) dod (6) internet (1) security (5) mechanisms (5) pkix (7) id-mod (0) id-pkix1-explicit (18) } - ContentInfo, IssuerAndSerialNumber FROM CryptographicMessageSyntax { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) modules(0) cms(1) } - KerberosTime, Checksum, TYPED-DATA, PrincipalName, Realm, EncryptionKey FROM KerberosV5Spec2 { iso(1) identified-organization(3) dod(6) internet(1) security(5) kerberosV5(2) modules(4) krb5spec2(2) } ; - id-pkinit OBJECT IDENTIFIER ::= { iso (1) org (3) dod (6) internet (1) security (5) kerberosv5 (2) pkinit (3) } - id-pkdhkeydata OBJECT IDENTIFIER ::= { id-pkinit 1 } id-pkdhkeydata OBJECT IDENTIFIER ::= { id-pkinit 2 } id-pkrkeydata OBJECT IDENTIFIER ::= { id-pkinit 3 } id-pkekuoid OBJECT IDENTIFIER ::= { id-pkinit 4 } id-pkkdcekuoid OBJECT IDENTIFIER ::= { id-pkinit 5 } - pa-pk-as-req INTEGER ::= TBD pa-pk-as-rep INTEGER ::= TBD pa-pk-ocsp-req INTEGER ::= TBD pa-pk-ocsp-rep INTEGER ::= TBD - ad-initial-verified-cas INTEGER ::= TBD - td-dh-parameters INTEGER ::= TBD td-trusted-certifiers INTEGER ::= 104 td-certificate-index INTEGER ::= 105 - PA-PK-AS-REQ ::= SEQUENCE { signedAuthPack [0] ContentInfo, trustedCertifiers [1] SEQUENCE OF TrustedCA OPTIONAL, @@ -1026,14 +849,12 @@ KerberosV5-PK-INIT-SPEC { ... } - TrustedCA ::= CHOICE { caName [0] Name, issuerAndSerial [2] IssuerAndSerialNumber, ... } - AuthPack ::= SEQUENCE { pkAuthenticator [0] PKAuthenticator, clientPublicValue [1] SubjectPublicKeyInfo OPTIONAL, @@ -1042,7 +863,6 @@ KerberosV5-PK-INIT-SPEC { ... } - PKAuthenticator ::= SEQUENCE { cusec [0] INTEGER, ctime [1] KerberosTime, @@ -1051,33 +871,27 @@ KerberosV5-PK-INIT-SPEC { ... } - TrustedCertifiers ::= SEQUENCE OF Name - CertificateIndex ::= IssuerAndSerialNumber - KRB5PrincipalName ::= SEQUENCE { realm [0] Realm, principalName [1] PrincipalName } - InitialVerifiedCAs ::= SEQUENCE OF SEQUENCE { ca [0] Name, validated [1] BOOLEAN, ... } - PA-PK-AS-REP ::= CHOICE { dhSignedData [0] ContentInfo, encKeyPack [1] ContentInfo, ... } - KDCDHKeyInfo ::= SEQUENCE { subjectPublicKey [0] BIT STRING, nonce [1] INTEGER, @@ -1085,26 +899,10 @@ KerberosV5-PK-INIT-SPEC { ... } - ReplyKeyPack ::= SEQUENCE { replyKey [0] EncryptionKey, nonce [1] INTEGER (0..4294967295), ... } - END - - -Copyright (C) The Internet Society (2004). This document is subject -to the rights, licenses and restrictions contained in BCP 78, and -except as set forth therein, the authors retain all their rights. - - -This document and the information contained herein are provided on an -"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS -OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET -ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, -INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE -INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED -WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. \ No newline at end of file diff --git a/doc/standardisation/draft-ietf-cat-kerberos-pk-init-21.txt b/doc/standardisation/draft-ietf-cat-kerberos-pk-init-21.txt index a441cfdcf..d2510b526 100644 --- a/doc/standardisation/draft-ietf-cat-kerberos-pk-init-21.txt +++ b/doc/standardisation/draft-ietf-cat-kerberos-pk-init-21.txt @@ -5,49 +5,39 @@ expires April 25, 2005 USC/ISI Motorola, Inc. - Public Key Cryptography for Initial Authentication in Kerberos - 0. Status Of This Memo - By submitting this Internet-Draft, I certify that any applicable patent or other IPR claims of which I am aware have been disclosed, or will be disclosed, and any of which I become aware will be disclosed, in accordance with RFC 3668. - Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. - Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." - The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt - The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html - The distribution of this memo is unlimited. It is filed as draft-ietf-cat-kerberos-pk-init-21.txt and expires April 25, 2005. Please send comments to the authors. - 1. Abstract - This document describes protocol extensions (hereafter called PKINIT) to the Kerberos protocol specification [1]. These extensions provide a method for integrating public key cryptography @@ -56,10 +46,8 @@ certificates and associated authenticators in preauthentication data fields. - 2. Introduction - A client typically authenticates itself to a service in Kerberos using three distinct though related exchanges. First, the client requests a ticket-granting ticket (TGT) from the Kerberos @@ -71,7 +59,6 @@ will refer to both the AS and the TGS as the KDC.) Finally, the client uses the service ticket to authenticate itself to the service. - The advantage afforded by the TGT is that the client need explicitly request a ticket and expose his credentials only once. The TGT and its associated session key can then be used for any subsequent @@ -81,14 +68,12 @@ performed. Consequently, initial authentication provides a convenient place to integrate public-key cryptography into Kerberos authentication. - As defined, Kerberos authentication exchanges use symmetric-key cryptography, in part for performance. One cost of using symmetric-key cryptography is that the keys must be shared, so that before a client can authenticate itself, he must already be registered with the KDC. - Conversely, public-key cryptography (in conjunction with an established Public Key Infrastructure) permits authentication without prior registration with a KDC. Adding it to Kerberos allows @@ -96,7 +81,6 @@ the widespread use of Kerberized applications by clients without requiring them to register first with a KDC--a requirement that has no inherent security benefit. - As noted above, a convenient and efficient place to introduce public-key cryptography into Kerberos is in the initial authentication exchange. This document describes the methods and @@ -104,105 +88,79 @@ data formats for integrating public-key cryptography into Kerberos initial authentication. - 3. Extensions - This section describes extensions to [1] for supporting the use of public-key cryptography in the initial request for a ticket. - Briefly, this document defines the following extensions to [1]: - 1. The client indicates the use of public-key authentication by including a special preauthenticator in the initial request. This preauthenticator contains the client's public-key data and a signature. - 2. The KDC tests the client's request against its policy and trusted Certification Authorities (CAs). - 3. If the request passes the verification tests, the KDC replies as usual, but the reply is encrypted using either: - a. a symmetric encryption key, signed using the KDC's signature key and encrypted using the client's encryption key; or - b. a key generated through a Diffie-Hellman exchange with the client, signed using the KDC's signature key. - Any keying material required by the client to obtain the Encryption key is returned in a preauthentication field accompanying the usual reply. - 4. The client obtains the encryption key, decrypts the reply, and then proceeds as usual. - Section 3.1 of this document defines the necessary message formats. Section 3.2 describes their syntax and use in greater detail. - 3.1. Definitions, Requirements, and Constants - The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [12]. - 3.1.1. Required Algorithms - All PKINIT implementations MUST support the following algorithms: - - Reply key (or DH-derived key): AES256-CTS-HMAC-SHA1-96 etype. - - Signature algorithm: SHA-1 digest and RSA. - - Reply key delivery method: ephemeral-ephemeral Diffie-Hellman with a non-zero nonce. - - Unkeyed checksum type for the paChecksum member of PKAuthenticator: SHA1 (unkeyed), Kerberos checksum type 14 [11]. - 3.1.2. Defined Message and Encryption Types - PKINIT makes use of the following new preauthentication types: - PA-PK-AS-REQ TBD PA-PK-AS-REP TBD - PKINIT also makes use of the following new authorization data type: - AD-INITIAL-VERIFIED-CAS TBD - PKINIT introduces the following new error codes: - KDC_ERR_CLIENT_NOT_TRUSTED 62 KDC_ERR_KDC_NOT_TRUSTED 63 KDC_ERR_INVALID_SIG 64 @@ -214,21 +172,17 @@ PKINIT introduces the following new error codes: KDC_ERR_REVOCATION_STATUS_UNKNOWN 73 KDC_ERR_CLIENT_NAME_MISMATCH 75 - PKINIT uses the following typed data types for errors: - TD-DH-PARAMETERS TBD TD-TRUSTED-CERTIFIERS 104 TD-CERTIFICATE-INDEX 105 TD-UNKEYED-CHECKSUM-INFO 109 - PKINIT defines the following encryption types, for use in the AS-REQ message (to indicate acceptance of the corresponding encryption OIDs in PKINIT): - dsaWithSHA1-CmsOID 9 md5WithRSAEncryption-CmsOID 10 sha1WithRSAEncryption-CmsOID 11 @@ -237,25 +191,21 @@ in PKINIT): rsaES-OAEP-EnvOID (PKCS1 v2.0) 14 des-ede3-cbc-EnvOID 15 - The above encryption types are used by the client only within the KDC-REQ-BODY to indicate which CMS [2] algorithms it supports. Their use within Kerberos EncryptedData structures is not specified by this document. - The ASN.1 module for all structures defined in this document (plus IMPORT statements for all imported structures) are given in Appendix A. In the event of a discrepancy between Appendix A and the portions of ASN.1 in the main text, the appendix is normative. - All structures defined in this document MUST be encoded using Distinguished Encoding Rules (DER). All imported data structures must be encoded according to the rules specified in Kerberos [1] or CMS [2] as appropriate. - Interoperability note: Some implementations may not be able to decode CMS objects encoded with BER but not DER; specifically, they may not be able to decode infinite length encodings. To maximize @@ -263,75 +213,58 @@ interoperability, implementers SHOULD encode CMS objects used in PKINIT with DER. - 3.1.3. Algorithm Identifiers - PKINIT does not define, but does make use of, the following algorithm identifiers. - PKINIT uses the following algorithm identifier for Diffie-Hellman key agreement [9]: - dhpublicnumber - PKINIT uses the following signature algorithm identifiers [8, 12]: - sha-1WithRSAEncryption (RSA with SHA1) md5WithRSAEncryption (RSA with MD5) id-dsa-with-sha1 (DSA with SHA1) - PKINIT uses the following encryption algorithm identifiers [5] for encrypting the temporary key with a public key: - rsaEncryption (PKCS1 v1.5) id-RSAES-OAEP (PKCS1 v2.0) - PKINIT uses the following algorithm identifiers [2] for encrypting the reply key with the temporary key: - des-ede3-cbc (three-key 3DES, CBC mode) rc2-cbc (RC2, CBC mode) aes256_CBC (AES-256, CBC mode) - 3.2. PKINIT Preauthentication Syntax and Use - This section defines the syntax and use of the various preauthentication fields employed by PKINIT. - 3.2.1. Client Request - The initial authentication request (AS-REQ) is sent as per [1]; in addition, a preauthentication field contains data signed by the client's private signature key, as follows: - WrapContentInfo ::= OCTET STRING (CONSTRAINED BY { -- Contains a BER encoding of -- ContentInfo }) - WrapIssuerAndSerial ::= OCTET STRING (CONSTRAINED BY { -- Contains a BER encoding of -- IssuerAndSerialNumber }) - PA-PK-AS-REQ ::= SEQUENCE { signedAuthPack [0] IMPLICIT WrapContentInfo, -- Type is SignedData. @@ -349,7 +282,6 @@ client's private signature key, as follows: ... } - TrustedCA ::= CHOICE { caName [1] Name, -- Fully qualified X.500 name @@ -360,7 +292,6 @@ client's private signature key, as follows: ... } - AuthPack ::= SEQUENCE { pkAuthenticator [0] PKAuthenticator, clientPublicValue [1] SubjectPublicKeyInfo OPTIONAL, @@ -376,7 +307,6 @@ client's private signature key, as follows: ... } - PKAuthenticator ::= SEQUENCE { cusec [0] INTEGER (0..999999), ctime [1] KerberosTime, @@ -397,36 +327,29 @@ client's private signature key, as follows: ... } - The ContentInfo in the signedAuthPack is filled out as follows: - 1. The eContent field contains data of type AuthPack. It MUST contain the pkAuthenticator, and MAY also contain the client's Diffie-Hellman public value (clientPublicValue). - 2. The eContentType field MUST contain the OID value for id-pkauthdata: { iso(1) org(3) dod(6) internet(1) security(5) kerberosv5(2) pkinit(3) pkauthdata(1)} - 3. The signerInfos field MUST contain the signature over the AuthPack. - 4. The certificates field MUST contain at least a signature verification certificate chain that the KDC can use to verify the signature over the AuthPack. The certificate chain(s) MUST NOT contain the root CA certificate. - 5. If a Diffie-Hellman key is being used, the parameters MUST be chosen from Oakley Group 2 or 14. Implementations MUST support Group 2; they are RECOMMENDED to support Group 14. (See RFC 2409 [10].) - 6. The KDC may wish to use cached Diffie-Hellman parameters. To indicate acceptance of caching, the client sends zero in the nonce field of the pkAuthenticator. Zero is not a valid @@ -436,15 +359,12 @@ The ContentInfo in the signedAuthPack is filled out as follows: nonce in the main request. - 3.2.2. Validation of Client Request - Upon receiving the client's request, the KDC validates it. This section describes the steps that the KDC MUST (unless otherwise noted) take in validating the request. - The KDC must look for a client certificate in the signedAuthPack. If it cannot find one signed by a CA it trusts, it sends back an error of type KDC_ERR_CANT_VERIFY_CERTIFICATE. The accompanying @@ -452,10 +372,8 @@ e-data for this error is a TYPED-DATA (as defined in [1]). For this error, the data-type is TD-TRUSTED-CERTIFIERS, and the data-value is the DER encoding of - TrustedCertifiers ::= SEQUENCE OF Name - If, while verifying the certificate chain, the KDC determines that the signature on one of the certificates in the signedAuthPack is invalid, it returns an error of type KDC_ERR_INVALID_CERTIFICATE. @@ -464,16 +382,13 @@ data-type is TD-CERTIFICATE-INDEX, and whose data-value is the DER encoding of the index into the CertificateSet field, ordered as sent by the client: - CertificateIndex ::= IssuerAndSerialNumber -- IssuerAndSerialNumber of -- certificate with invalid signature - If more than one certificate signature is invalid, the KDC MAY send one TYPED-DATA per invalid signature. - The KDC MAY also check whether any certificates in the client's chain have been revoked. If any of them have been revoked, the KDC MUST return an error of type KDC_ERR_REVOKED_CERTIFICATE; if the KDC @@ -482,39 +397,31 @@ it SHOULD return an error of type KDC_ERR_REVOCATION_STATUS_UNKNOWN. The certificate or certificates affected are identified exactly as for an error of type KDC_ERR_INVALID_CERTIFICATE (see above). - In addition to validating the certificate chain, the KDC MUST also check that the certificate properly maps to the client's principal name as specified in the AS-REQ as follows: - 1. If the KDC has its own mapping from the name in the certificate to a Kerberos name, it uses that Kerberos name. - 2. Otherwise, if the certificate contains a SubjectAltName extension with a Kerberos name in the otherName field, it uses that name. The otherName field (of type AnotherName) in the SubjectAltName extension MUST contain the following: - The type-id is: - krb5PrincipalName OBJECT IDENTIFIER ::= { iso (1) org (3) dod (6) internet (1) security (5) kerberosv5 (2) 2 } - The value is: - KRB5PrincipalName ::= SEQUENCE { realm [0] Realm, principalName [1] PrincipalName } - If the KDC does not have its own mapping and there is no Kerberos name present in the certificate, or if the name in the request does not match the name in the certificate (including the realm name), or @@ -522,7 +429,6 @@ if there is no name in the request, the KDC MUST return error code KDC_ERR_CLIENT_NAME_MISMATCH. There is no accompanying e-data for this error. - Even if the chain is validated, and the names in the certificate and the request match, the KDC may decide not to trust the client. For example, the certificate may include an Extended Key Usage (EKU) OID @@ -531,23 +437,19 @@ decide to reject requests on the basis of the absence or presence of specific EKU OIDs. In this case, the KDC MUST return error code KDC_ERR_CLIENT_NOT_TRUSTED. The PKINIT EKU OID is defined as: - { iso(1) org(3) dod(6) internet(1) security(5) kerberosv5(2) pkinit(3) pkekuoid(4) } - If the client's signature on the signedAuthPack fails to verify, the KDC MUST return error KDC_ERR_INVALID_SIG. There is no accompanying e-data for this error. - The KDC MUST check the timestamp to ensure that the request is not a replay, and that the time skew falls within acceptable limits. The recommendations clock skew times in [1] apply here. If the check fails, the KDC MUSTreturn error code KRB_AP_ERR_REPEAT or KRB_AP_ERR_SKEW, respectively. - If the clientPublicValue is filled in, indicating that the client wishes to use ephemeral-ephemeral Diffie-Hellman, the KDC checks to see if the parameters satisfy its policy. If they do not, it MUST @@ -557,18 +459,15 @@ data-value is the DER encoding of a DomainParameters (see [3]), including appropriate Diffie-Hellman parameters with which to retry the request. - The KDC MUST return error code KDC_ERR_CERTIFICATE_MISMATCH if the client included a kdcCert field in the PA-PK-AS-REQ and the KDC does not have the corresponding certificate. - The KDC MUST return error code KDC_ERR_KDC_NOT_TRUSTED if the client did not include a kdcCert field, but did include a trustedCertifiers field, and the KDC does not possesses a certificate issued by one of the listed certifiers. - If there is a supportedCMSTypes field in the AuthPack, the KDC must check to see if it supports any of the listed types. If it supports more than one of the types, the KDC SHOULD use the one listed first. @@ -576,26 +475,21 @@ If it does not support any of them, it MUST return an error of type KRB5KDC_ERR_ETYPE_NOSUPP. - 3.2.3. KDC Reply - Assuming that the client's request has been properly validated, the KDC proceeds as per [1], except as follows. - The KDC MUST set the initial flag and include an authorization data of type AD-INITIAL-VERIFIED-CAS in the issued ticket. The value is an OCTET STRING containing the DER encoding of InitialVerifiedCAs: - InitialVerifiedCAs ::= SEQUENCE OF SEQUENCE { ca [0] Name, Validated [1] BOOLEAN, ... } - The KDC MAY wrap any AD-INITIAL-VERIFIED-CAS data in AD-IF-RELEVANT containers if the list of CAs satisfies the KDC's realm's policy. (This corresponds to the TRANSITED-POLICY-CHECKED ticket flag.) @@ -603,7 +497,6 @@ Furthermore, any TGS must copy such authorization data from tickets used in a PA-TGS-REQ of the TGS-REQ to the resulting ticket, including the AD-IF-RELEVANT container, if present. - Application servers that understand this authorization data type SHOULD apply local policy to determine whether a given ticket bearing such a type *not* contained within an AD-IF-RELEVANT @@ -613,14 +506,12 @@ has not been set.) If such a data type is contained within an AD-IF-RELEVANT container, AP servers MAY apply local policy to determine whether the authorization data is acceptable. - The AS-REP is otherwise unchanged from [1]. The KDC encrypts the reply as usual, but not with the client's long-term key. Instead, it encrypts it with either a generated encryption key, or a key derived from a Diffie-Hellman exchange. The contents of the PA-PK-AS-REP indicate the type of encryption key that was used: - PA-PK-AS-REP ::= CHOICE { dhSignedData [0] IMPLICIT WrapContentInfo, -- Type is SignedData. @@ -633,7 +524,6 @@ PA-PK-AS-REP indicate the type of encryption key that was used: ... } - KDCDHKeyInfo ::= SEQUENCE { subjectPublicKey [0] BIT STRING, -- Equals public exponent @@ -651,23 +541,18 @@ PA-PK-AS-REP indicate the type of encryption key that was used: ... } - The fields of the ContentInfo for dhSignedData are to be filled in as follows: - 1. The eContent field contains data of type KDCDHKeyInfo. - 2. The eContentType field contains the OID value for id-pkdhkeydata: { iso(1) org(3) dod(6) internet(1) security(5) kerberosv5(2) pkinit(3) pkdhkeydata(2) } - 3. The signerInfos field contains a single signerInfo, which is the signature of the KDCDHKeyInfo. - 4. The certificates field contains a signature verification certificate chain that the client will use to verify the KDC's signature over the KDCDHKeyInfo. This field may only @@ -676,7 +561,6 @@ as follows: certificate. The certificate chain MUST NOT contain the root CA certificate. - 5. If the client and KDC agree to use cached parameters, the KDC MUST return a zero in the nonce field and include the expiration time of the cached values in the dhKeyExpiration @@ -685,31 +569,24 @@ as follows: the reply and MAY resubmit a request with a non-zero nonce, thus indicating non-acceptance of the cached parameters. - The KDC reply key is derived as follows: - 1. Both the KDC and the client calculate the shared secret value - DHKey = g^(ab) mod p - where a and b are the client's and KDC's private exponents, respectively. DHKey, padded first with leading zeros as needed to make it as long as the modulus p, is represented as a string of octets in big-endian order (such that the size of DHKey in octets is the size of the modulus p). - 2. Let K be the key-generation seed length [6] of the reply key whose enctype is selected according to [1]. - 3. Define the function octetstring2key() as follows: - octetstring2key(h, x) == random-to-key(K-truncate( h(0x00 | x) | h(0x01 | x) | @@ -717,7 +594,6 @@ The KDC reply key is derived as follows: ... )) - where x is an octet string; h:octet string -> octet string is a cryptographically strong hash function; | is the concatenation operator; 0x00, 0x01, 0x02, etc. are each @@ -727,24 +603,18 @@ The KDC reply key is derived as follows: Both K and random-to-key() are defined in the kcrypto profile [6] for the enctype of the reply key. - A good example of h() is SHA1. - 4. Define H to be a hash function based on operations of a given checksum type [6], as follows: - H(x) = get_mic(dummy-key, x) - where x is an octet string. - H() MUST be a cryptographically strong hash, in order to be suitable for use in the octetstring2key() operation above. - 5. The client specifies a checksum type to use in the paChecksum of the PKAuthenticator. If the H() operation based on this checksum is not suitable for use in @@ -755,31 +625,25 @@ The KDC reply key is derived as follows: TD-UNKEYED-CHECKSUM-INFO, and the data-value is the DER encoding of - UNKEYED-CHECKSUM-INFO ::= SEQUENCE OF SEQUENCE { cksumtype [0] Int32, ... } - This list is in the preference order (best choice first) of the KDC, and the client SHOULD retry with the first available checksum type. - 6. When cached DH parameters are used, let n_c be the clientDHNonce, and n_k be the serverDHNonce; otherwise, let both n_c and n_k be empty octet strings. The reply key k is - k = octetstring2key(H, DHKey | n_c | n_k) - where H() is the hash function based on the checksum type used in the paChecksum of the PKAuthenticator (as defined in step 4). - Both the KDC and the client calculate the value g^(ab) mod p, where a and b are the client's and KDC's private exponents, respectively. They both take the first k bits of @@ -789,12 +653,10 @@ specified in [6]. The seed is then converted into a protocol key by applying to it a random-to-key function, which is also dependent on key type. - If the KDC and client are not using Diffie-Hellman, the KDC encrypts the reply with an encryption key, packed in the encKeyPack, which contains data of type ReplyKeyPack: - ReplyKeyPack ::= SEQUENCE { replyKey [0] EncryptionKey, -- Defined in [1]. @@ -810,24 +672,19 @@ contains data of type ReplyKeyPack: ... } - The fields of the ContentInfo for encKeyPack MUST be filled in as follows: - 1. The content is of type SignedData. The eContent for the SignedData is of type ReplyKeyPack. - 2. The eContentType for the SignedData contains the OID value for id-pkrkeydata: { iso(1) org(3) dod(6) internet(1) security(5) kerberosv5(2) pkinit(3) pkrkeydata(3) } - 3. The signerInfos field contains a single signerInfo, which is the signature of the ReplyKeyPack. - 4. The certificates field contains a signature verification certificate chain that the client will use to verify the KDC's signature over the ReplyKeyPack. This field may only @@ -836,33 +693,27 @@ follows: The certificate chain MUST NOT contain the root CA certificate. - 5. The contentType for the EnvelopedData contains the OID value for id-signedData: { iso (1) member-body (2) us (840) rsadsi (113549) pkcs (1) pkcs7 (7) signedData (2) } - 6. The recipientInfos field is a SET which MUST contain exactly one member of type KeyTransRecipientInfo. The encryptedKey for this member contains the temporary key which is encrypted using the client's public key. - 7. The unprotectedAttrs or originatorInfo fields MAY be present. - 3.2.4. Validation of KDC Reply - Upon receipt of the KDC's reply, the client proceeds as follows. If the PA-PK-AS-REP contains a dhSignedData, the client obtains and verifies the Diffie-Hellman parameters, and obtains the shared key as described above. Otherwise, the message contains an encKeyPack, and the client decrypts and verifies the temporary encryption key. - In either case, the client MUST check to see if the included certificate contains a subjectAltName extension of type dNSName or iPAddress (if the KDC is specified by IP address instead of name). @@ -871,34 +722,27 @@ it believes it is communicating with, with matching rules specified in RFC 2459. Exception: If the client has some external information as to the identity of the KDC, this check MAY be omitted. - The client also MUST check that the KDC's certificate contains an extendedKeyUsage OID of id-pkkdcekuoid: - { iso(1) org(3) dod(6) internet(1) security(5) kerberosv5(2) pkinit(3) pkkdcekuoid(5) } - If all applicable checks are satisfied, the client then decrypts the main reply with the resulting key, and then proceeds as described in [1]. - 4. Security Considerations - PKINIT raises certain security considerations beyond those that can be regulated strictly in protocol definitions. We will address them in this section. - PKINIT extends the cross-realm model to the public-key infrastructure. Users of PKINIT must understand security policies and procedures appropriate to the use of Public Key Infrastructures. - Standard Kerberos allows the possibility of interactions between cryptosystems of varying strengths; this document adds interactions with public-key cryptosystems to Kerberos. Some administrative @@ -906,12 +750,10 @@ policies may allow the use of relatively weak public keys. Using such keys to wrap data encrypted under stronger conventional cryptosystems may be inappropriate. - PKINIT requires keys for symmetric cryptosystems to be generated. Some such systems contain "weak" keys. For recommendations regarding these weak keys, see [1]. - PKINIT allows the use of a zero nonce in the PKAuthenticator when cached Diffie-Hellman keys are used. In this case, message binding is performed using the nonce in the main request in the same way as @@ -922,7 +764,6 @@ cryptographically binds the PKINIT pre-authenticator to the main body of the AS Request and also provides message integrity for the full AS Request. - However, when a PKINIT pre-authenticator in the AS-REP has a zero-nonce, and an attacker has somehow recorded this pre-authenticator and discovered the corresponding Diffie-Hellman @@ -934,7 +775,6 @@ and it is therefore important for clients to check this expiration time and for the expiration time to be reasonably short, which depends on the size of the Diffie-Hellman group. - If a client also caches its Diffie-Hellman keys, then the session key could remain the same during multiple AS-REQ/AS-REP exchanges and an attacker which compromised the session key could fabricate his own @@ -943,14 +783,12 @@ client starts using a new Diffie-Hellman key pair and while the KDC pre-authenticator has not yet expired. It is therefore not recommended for KDC clients to also cache their Diffie-Hellman keys. - Care should be taken in how certificates are chosen for the purposes of authentication using PKINIT. Some local policies may require that key escrow be used for certain certificate types. Deployers of PKINIT should be aware of the implications of using certificates that have escrowed keys for the purposes of authentication. - PKINIT does not provide for a "return routability" test to prevent attackers from mounting a denial-of-service attack on the KDC by causing it to perform unnecessary and expensive public-key @@ -958,22 +796,18 @@ operations. Strictly speaking, this is also true of standard Kerberos, although the potential cost is not as great, because standard Kerberos does not make use of public-key cryptography. - The syntax for the AD-INITIAL-VERIFIED-CAS authorization data does permit empty SEQUENCEs to be encoded. Such empty sequences may only be used if the KDC itself vouches for the user's certificate. [This seems to reflect the consensus of the Kerberos working group.] - 5. Acknowledgements - The following people have made significant contributions to this draft: Ari Medvinsky, Matt Hur, John Wray, Jonathan Trostle, Nicolas Williams, Tom Yu, Sam Hartman, and Jeff Hutzelman. - Some of the ideas on which this document is based arose during discussions over several years between members of the SAAG, the IETF CAT working group, and the PSRG, regarding integration of Kerberos @@ -985,74 +819,57 @@ perspective. Lastly, comments from groups working on similar ideas in DCE have been invaluable. - 6. Expiration Date - This draft expires January 25, 2004. - 7. Bibliography - [1] RFC-Editor: To be replaced by RFC number for draft-ietf-krb-wg-kerberos-clarifications. - [2] R. Housley. Cryptographic Message Syntax. April 1999. Request For Comments 2630. - [3] W. Polk, R. Housley, and L. Bassham. Algorithms and Identifiers for the Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile, April 2002. Request For Comments 3279. - [4] R. Housley, W. Polk, W. Ford, D. Solo. Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile, April 2002. Request for Comments 3280. - [5] B. Kaliski, J. Staddon. PKCS #1: RSA Cryptography Specifications, October 1998. Request for Comments 2437. - [6] RFC-Editor: To be replaced by RFC number for draft-ietf-krb-wg-crypto. - [7] S. Blake-Wilson, M. Nystrom, D. Hopwood, J. Mikkelsen, and T. Wright. Transport Layer Security (TLS) Extensions, June 2003. Request for Comments 3546. - [8] M. Myers, R. Ankney, A. Malpani, S. Galperin, and C. Adams. Internet X.509 Public Key Infrastructure: Online Certificate Status Protocol - OCSP, June 1999. Request for Comments 2560. - [9] NIST, Guidelines for Implementing and Using the NBS Encryption Standard, April 1981. FIPS PUB 74. - [10] D. Harkins and D. Carrel. The Internet Key Exchange (IKE), November 1998. Request for Comments 2409. - [11] K. Raeburn. Unkeyed SHA-1 Checksum Specification for Kerberos 5. Internet-Draft, draft-ietf-krb-wg-sha1-00.txt. - [12] S. Bradner. Key Words for Use in RFCs to Indicate Requirement Levels. March 1997. Request for Comments 2119 (BCP 14). - 8. Authors - Brian Tung Clifford Neuman USC Information Sciences Institute @@ -1061,7 +878,6 @@ Marina del Rey CA 90292-6695 Phone: +1 310 822 1511 E-mail: {brian,bcn}@isi.edu - Matthew Hur Ari Medvinsky Microsoft Corporation @@ -1070,7 +886,6 @@ Redmond WA 98052 Phone: +1 425 707 3336 E-mail: matthur@microsoft.com, arimed@windows.microsoft.com - Sasha Medvinsky Motorola, Inc. 6450 Sequence Drive @@ -1078,85 +893,70 @@ San Diego, CA 92121 +1 858 404 2367 E-mail: smedvinsky@motorola.com - John Wray Iris Associates, Inc. 5 Technology Park Dr. Westford, MA 01886 E-mail: John_Wray@iris.com - Jonathan Trostle E-mail: jtrostle@world.std.com - Appendix A. PKINIT ASN.1 Module - KerberosV5-PK-INIT-SPEC { iso(1) identified-organization(3) dod(6) internet(1) security(5) kerberosV5(2) modules(4) pkinit(TBD) } DEFINITIONS EXPLICIT TAGS ::= BEGIN - IMPORTS SubjectPublicKeyInfo, AlgorithmIdentifier, Name FROM PKIX1Explicit88 { iso (1) identified-organization (3) dod (6) internet (1) security (5) mechanisms (5) pkix (7) id-mod (0) id-pkix1-explicit (18) } - ContentInfo, IssuerAndSerialNumber FROM CryptographicMessageSyntax { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) modules(0) cms(1) } - KerberosTime, Checksum, TYPED-DATA, PrincipalName, Realm, EncryptionKey FROM KerberosV5Spec2 { iso(1) identified-organization(3) dod(6) internet(1) security(5) kerberosV5(2) modules(4) krb5spec2(2) } ; - id-pkinit OBJECT IDENTIFIER ::= { iso (1) org (3) dod (6) internet (1) security (5) kerberosv5 (2) pkinit (3) } - id-pkdhkeydata OBJECT IDENTIFIER ::= { id-pkinit 1 } id-pkdhkeydata OBJECT IDENTIFIER ::= { id-pkinit 2 } id-pkrkeydata OBJECT IDENTIFIER ::= { id-pkinit 3 } id-pkekuoid OBJECT IDENTIFIER ::= { id-pkinit 4 } id-pkkdcekuoid OBJECT IDENTIFIER ::= { id-pkinit 5 } - pa-pk-as-req INTEGER ::= TBD pa-pk-as-rep INTEGER ::= TBD pa-pk-ocsp-req INTEGER ::= TBD pa-pk-ocsp-rep INTEGER ::= TBD - ad-initial-verified-cas INTEGER ::= TBD - td-dh-parameters INTEGER ::= TBD td-trusted-certifiers INTEGER ::= 104 td-certificate-index INTEGER ::= 105 - WrapContentInfo ::= OCTET STRING (CONSTRAINED BY { -- Contains a BER encoding of -- ContentInfo }) - WrapIssuerAndSerial ::= OCTET STRING (CONSTRAINED BY { -- Contains a BER encoding of -- IssuerAndSerialNumber }) - PA-PK-AS-REQ ::= SEQUENCE { signedAuthPack [0] IMPLICIT WrapContentInfo, trustedCertifiers [1] SEQUENCE OF TrustedCA OPTIONAL, @@ -1165,14 +965,12 @@ KerberosV5-PK-INIT-SPEC { ... } - TrustedCA ::= CHOICE { caName [1] Name, issuerAndSerial [2] IMPLICIT WrapIssuerAndSerial, ... } - AuthPack ::= SEQUENCE { pkAuthenticator [0] PKAuthenticator, clientPublicValue [1] SubjectPublicKeyInfo OPTIONAL, @@ -1181,7 +979,6 @@ KerberosV5-PK-INIT-SPEC { ... } - PKAuthenticator ::= SEQUENCE { cusec [0] INTEGER (0..999999), ctime [1] KerberosTime, @@ -1190,33 +987,27 @@ KerberosV5-PK-INIT-SPEC { ... } - TrustedCertifiers ::= SEQUENCE OF Name - CertificateIndex ::= IssuerAndSerialNumber - KRB5PrincipalName ::= SEQUENCE { realm [0] Realm, principalName [1] PrincipalName } - InitialVerifiedCAs ::= SEQUENCE OF SEQUENCE { ca [0] Name, validated [1] BOOLEAN, ... } - PA-PK-AS-REP ::= CHOICE { dhSignedData [0] IMPLICIT WrapContentInfo, encKeyPack [1] IMPLICIT WrapContentInfo, ... } - KDCDHKeyInfo ::= SEQUENCE { subjectPublicKey [0] BIT STRING, nonce [1] INTEGER (0..4294967295), @@ -1224,26 +1015,22 @@ KerberosV5-PK-INIT-SPEC { ... } - ReplyKeyPack ::= SEQUENCE { replyKey [0] EncryptionKey, nonce [1] INTEGER (0..4294967295), ... } - END - Copyright (C) The Internet Society 2004. This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. - This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED -WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. \ No newline at end of file +WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. diff --git a/doc/standardisation/draft-ietf-cat-kerberos-pk-init-22.txt b/doc/standardisation/draft-ietf-cat-kerberos-pk-init-22.txt index b1fd480e9..7f9fe5df6 100644 --- a/doc/standardisation/draft-ietf-cat-kerberos-pk-init-22.txt +++ b/doc/standardisation/draft-ietf-cat-kerberos-pk-init-22.txt @@ -1,1569 +1,1016 @@ - - -NETWORK WORKING GROUP B. Tung -Internet-Draft C. Neuman -Expires: June 6, 2005 USC Information Sciences Institute - L. Zhu - M. Hur - Microsoft Corporation - S. Medvinsky +INTERNET-DRAFT Brian Tung +draft-ietf-cat-kerberos-pk-init-22.txt Clifford Neuman +expires May 15, 2005 USC/ISI + Sasha Medvinsky Motorola, Inc. - December 6, 2004 - - - Public Key Cryptography for Initial Authentication in Kerberos - draft-ietf-cat-kerberos-pk-init - -Status of this Memo - - This document is an Internet-Draft and is subject to all provisions - of section 3 of RFC 3667. By submitting this Internet-Draft, each - author represents that any applicable patent or other IPR claims of - which he or she is aware have been or will be disclosed, and any of - which he or she become aware will be disclosed, in accordance with - RFC 3668. - - Internet-Drafts are working documents of the Internet Engineering - Task Force (IETF), its areas, and its working groups. Note that - other groups may also distribute working documents as - Internet-Drafts. - - Internet-Drafts are draft documents valid for a maximum of six months - and may be updated, replaced, or obsoleted by other documents at any - time. It is inappropriate to use Internet-Drafts as reference - material or to cite them other than as "work in progress." - - The list of current Internet-Drafts can be accessed at - http://www.ietf.org/ietf/1id-abstracts.txt. - - The list of Internet-Draft Shadow Directories can be accessed at - http://www.ietf.org/shadow.html. - - This Internet-Draft will expire on June 6, 2005. - -Copyright Notice - - Copyright (C) The Internet Society (2004). - -Abstract - - This document describes protocol extensions (hereafter called PKINIT) - to the Kerberos protocol specification. These extensions provide a - - - -Tung, et al. Expires June 6, 2005 [Page 1] - -Internet-Draft PKINIT December 2004 - - - method for integrating public key cryptography into the initial - authentication exchange, by passing digital certificates and - associated authenticators in preauthentication data fields. - -Table of Contents - - 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 - 2. Conventions Used in This Document . . . . . . . . . . . . . . 4 - 3. Extensions . . . . . . . . . . . . . . . . . . . . . . . . . . 5 - 3.1 Definitions, Requirements, and Constants . . . . . . . . . 5 - 3.1.1 Required Algorithms . . . . . . . . . . . . . . . . . 5 - 3.1.2 Defined Message and Encryption Types . . . . . . . . . 6 - 3.1.3 Algorithm Identifiers . . . . . . . . . . . . . . . . 7 - 3.2 PKINIT Preauthentication Syntax and Use . . . . . . . . . 7 - 3.2.1 Client Request . . . . . . . . . . . . . . . . . . . . 8 - 3.2.2 Validation of Client Request . . . . . . . . . . . . . 10 - 3.2.3 KDC Reply . . . . . . . . . . . . . . . . . . . . . . 12 - 3.2.4 Validation of KDC Reply . . . . . . . . . . . . . . . 17 - 3.3 KDC Indication of PKINIT Support . . . . . . . . . . . . . 17 - 4. Security Considerations . . . . . . . . . . . . . . . . . . . 19 - 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 21 - 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22 - 7. Normative References . . . . . . . . . . . . . . . . . . . . . 22 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 23 - A. PKINIT ASN.1 Module . . . . . . . . . . . . . . . . . . . . . 24 - Intellectual Property and Copyright Statements . . . . . . . . 28 - - - - - - - - - - - - - - - - - - - - - - - - - -Tung, et al. Expires June 6, 2005 [Page 2] - -Internet-Draft PKINIT December 2004 - - -1. Introduction - - A client typically authenticates itself to a service in Kerberos - using three distinct though related exchanges. First, the client - requests a ticket-granting ticket (TGT) from the Kerberos - authentication server (AS). Then, it uses the TGT to request a - service ticket from the Kerberos ticket-granting server (TGS). - Usually, the AS and TGS are integrated in a single device known as a - Kerberos Key Distribution Center, or KDC. Finally, the client uses - the service ticket to authenticate itself to the service. - - The advantage afforded by the TGT is that the client need explicitly - request a ticket and expose his credentials only once. The TGT and - its associated session key can then be used for any subsequent - requests. One result of this is that all further authentication is - independent of the method by which the initial authentication was - performed. Consequently, initial authentication provides a - convenient place to integrate public-key cryptography into Kerberos - authentication. - - As defined, Kerberos authentication exchanges use symmetric-key - cryptography, in part for performance. One cost of using - symmetric-key cryptography is that the keys must be shared, so that - before a client can authenticate itself, he must already be - registered with the KDC. - - Conversely, public-key cryptography (in conjunction with an - established Public Key Infrastructure) permits authentication without - prior registration with a KDC. Adding it to Kerberos allows the - widespread use of Kerberized applications by clients without - requiring them to register first with a KDC--a requirement that has - no inherent security benefit. - - As noted above, a convenient and efficient place to introduce - public-key cryptography into Kerberos is in the initial - authentication exchange. This document describes the methods and - data formats for integrating public-key cryptography into Kerberos - initial authentication. - - - - - - - - - - - - - -Tung, et al. Expires June 6, 2005 [Page 3] - -Internet-Draft PKINIT December 2004 - - -2. Conventions Used in This Document - - The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", - "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this - document are to be interpreted as described in [RFC2119]. - - In this document, we will refer to both the AS and the TGS as the - KDC. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Tung, et al. Expires June 6, 2005 [Page 4] - -Internet-Draft PKINIT December 2004 + Larry Zhu + Microsoft + + + Public Key Cryptography for Initial Authentication in Kerberos + + +0. Status Of This Memo + +By submitting this Internet-Draft, I certify that any applicable +patent or other IPR claims of which I am aware have been disclosed, +or will be disclosed, and any of which I become aware will be +disclosed, in accordance with RFC 3668. + +Internet-Drafts are working documents of the Internet Engineering +Task Force (IETF), its areas, and its working groups. Note that +other groups may also distribute working documents as +Internet-Drafts. + +Internet-Drafts are draft documents valid for a maximum of six +months and may be updated, replaced, or obsoleted by other documents +at any time. It is inappropriate to use Internet-Drafts as +reference material or to cite them other than as "work in progress." + +The list of current Internet-Drafts can be accessed at +http://www.ietf.org/ietf/1id-abstracts.txt + +The list of Internet-Draft Shadow Directories can be accessed at +http://www.ietf.org/shadow.html + +The distribution of this memo is unlimited. It is filed as +draft-ietf-cat-kerberos-pk-init-22.txt and expires May 15, 2005. +Please send comments to the authors. + + +1. Abstract + +This document describes protocol extensions (hereafter called +PKINIT) to the Kerberos protocol specification [1]. These +extensions provide a method for integrating public key cryptography +into the initial authentication exchange, by passing digital +certificates and associated authenticators in preauthentication data +fields. + + +2. Introduction + +A client typically authenticates itself to a service in Kerberos +using three distinct though related exchanges. First, the client +requests a ticket-granting ticket (TGT) from the Kerberos +authentication server (AS). Then, it uses the TGT to request a +service ticket from the Kerberos ticket-granting server (TGS). +Usually, the AS and TGS are integrated in a single device known as +a Kerberos Key Distribution Center, or KDC. (In this document, we +will refer to both the AS and the TGS as the KDC.) Finally, the +client uses the service ticket to authenticate itself to the +service. + +The advantage afforded by the TGT is that the client need explicitly +request a ticket and expose his credentials only once. The TGT and +its associated session key can then be used for any subsequent +requests. One result of this is that all further authentication is +independent of the method by which the initial authentication was +performed. Consequently, initial authentication provides a +convenient place to integrate public-key cryptography into Kerberos +authentication. + +As defined, Kerberos authentication exchanges use symmetric-key +cryptography, in part for performance. One cost of using +symmetric-key cryptography is that the keys must be shared, so that +before a client can authenticate itself, he must already be +registered with the KDC. + +Conversely, public-key cryptography (in conjunction with an +established Public Key Infrastructure) permits authentication +without prior registration with a KDC. Adding it to Kerberos allows +the widespread use of Kerberized applications by clients without +requiring them to register first with a KDC--a requirement that has +no inherent security benefit. + +As noted above, a convenient and efficient place to introduce +public-key cryptography into Kerberos is in the initial +authentication exchange. This document describes the methods and +data formats for integrating public-key cryptography into Kerberos +initial authentication. 3. Extensions - This section describes extensions to [CLAR] for supporting the use of - public-key cryptography in the initial request for a ticket. +This section describes extensions to [1] for supporting the use of +public-key cryptography in the initial request for a ticket. - Briefly, this document defines the following extensions to [CLAR]: +Briefly, this document defines the following extensions to [1]: - 1. The client indicates the use of public-key authentication by - including a special preauthenticator in the initial request. This - preauthenticator contains the client's public-key data and a - signature. + 1. The client indicates the use of public-key authentication by + including a special preauthenticator in the initial request. + This preauthenticator contains the client's public-key data + and a signature. - 2. The KDC tests the client's request against its policy and trusted - Certification Authorities (CAs). + 2. The KDC tests the client's request against its policy and + trusted Certification Authorities (CAs). - 3. If the request passes the verification tests, the KDC replies as - usual, but the reply is encrypted using either: + 3. If the request passes the verification tests, the KDC + replies as usual, but the reply is encrypted using either: - a. a symmetric encryption key, signed using the KDC's signature - key and encrypted using the client's encryption key; or + a. a symmetric encryption key, signed using the KDC's + signature key and encrypted using the client's encryption + key; or - b. a key generated through a Diffie-Hellman exchange with the - client, signed using the KDC's signature key. + b. a key generated through a Diffie-Hellman exchange with + the client, signed using the KDC's signature key. - Any keying material required by the client to obtain the - Encryption key is returned in a preauthentication field - accompanying the usual reply. + Any keying material required by the client to obtain the + Encryption key is returned in a preauthentication field + accompanying the usual reply. - 4. The client obtains the encryption key, decrypts the reply, and - then proceeds as usual. + 4. The client obtains the encryption key, decrypts the reply, + and then proceeds as usual. - Section 3.1 of this document defines the necessary message formats. - Section 3.2 describes their syntax and use in greater detail. +Section 3.1 of this document defines the necessary message formats. +Section 3.2 describes their syntax and use in greater detail. -3.1 Definitions, Requirements, and Constants -3.1.1 Required Algorithms +3.1. Definitions, Requirements, and Constants - All PKINIT implementations MUST support the following algorithms: - o AS reply key: AES256-CTS-HMAC-SHA1-96 etype [KCRYPTO]. +The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", +"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this +document are to be interpreted as described in RFC 2119 [12]. - o Signature algorithm: SHA-1 digest and RSA. - o Reply key delivery method: RSA or ephemeral-ephemeral - Diffie-Hellman. +3.1.1. Required Algorithms +All PKINIT implementations MUST support the following algorithms: + - Reply key (or DH-derived key): AES256-CTS-HMAC-SHA1-96 etype. + - Signature algorithm: SHA-1 digest and RSA. + - Reply key delivery method: ephemeral-ephemeral Diffie-Hellman + with a non-zero nonce. -Tung, et al. Expires June 6, 2005 [Page 5] - -Internet-Draft PKINIT December 2004 + - Unkeyed checksum type for the paChecksum member of + PKAuthenticator: SHA1 (unkeyed), Kerberos checksum type 14 + [11]. -3.1.2 Defined Message and Encryption Types +3.1.2. Defined Message and Encryption Types - PKINIT makes use of the following new preauthentication types: +PKINIT makes use of the following new preauthentication types: - PA-PK-AS-REQ 16 - PA-PK-AS-REP 17 + PA-PK-AS-REQ TBD + PA-PK-AS-REP TBD + PA-PK-AS-ERR TBD - PKINIT also makes use of the following new authorization data type: +PKINIT also makes use of the following new authorization data type: - AD-INITIAL-VERIFIED-CAS 9 + AD-INITIAL-VERIFIED-CAS TBD - PKINIT introduces the following new error codes: +PKINIT introduces the following new error codes: + KDC_ERR_CLIENT_NOT_TRUSTED 62 + KDC_ERR_KDC_NOT_TRUSTED 63 + KDC_ERR_INVALID_SIG 64 + KDC_ERR_KEY_SIZE 65 + KDC_ERR_CERTIFICATE_MISMATCH 66 + KDC_ERR_CANT_VERIFY_CERTIFICATE 70 + KDC_ERR_INVALID_CERTIFICATE 71 + KDC_ERR_REVOKED_CERTIFICATE 72 + KDC_ERR_REVOCATION_STATUS_UNKNOWN 73 + KDC_ERR_CLIENT_NAME_MISMATCH 75 - KDC_ERR_CLIENT_NOT_TRUSTED 62 - KDC_ERR_KDC_NOT_TRUSTED 63 - KDC_ERR_INVALID_SIG 64 - KDC_ERR_KEY_SIZE 65 - KDC_ERR_CERTIFICATE_MISMATCH 66 - KDC_ERR_CANT_VERIFY_CERTIFICATE 70 - KDC_ERR_INVALID_CERTIFICATE 71 - KDC_ERR_REVOKED_CERTIFICATE 72 - KDC_ERR_REVOCATION_STATUS_UNKNOWN 73 - KDC_ERR_CLIENT_NAME_MISMATCH 75 +PKINIT uses the following typed data types for errors: - PKINIT uses the following typed data types for errors: + TD-DH-PARAMETERS TBD + TD-TRUSTED-CERTIFIERS 104 + TD-CERTIFICATE-INDEX 105 + TD-UNKEYED-CHECKSUM-INFO 109 - TD-TRUSTED-CERTIFIERS 104 - TD-CERTIFICATE-INDEX 105 - TD-DH-PARAMETERS 109 +PKINIT defines the following encryption types, for use in the AS-REQ +message (to indicate acceptance of the corresponding encryption OIDs +in PKINIT): - PKINIT defines the following encryption types, for use in the - KRB_AS_REQ message (to indicate acceptance of the corresponding - encryption OIDs in PKINIT): + dsaWithSHA1-CmsOID 9 + md5WithRSAEncryption-CmsOID 10 + sha1WithRSAEncryption-CmsOID 11 + rc2CBC-EnvOID 12 + rsaEncryption-EnvOID (PKCS1 v1.5) 13 + rsaES-OAEP-EnvOID (PKCS1 v2.0) 14 + des-ede3-cbc-EnvOID 15 - dsaWithSHA1-CmsOID 9 - md5WithRSAEncryption-CmsOID 10 - sha1WithRSAEncryption-CmsOID 11 - rc2CBC-EnvOID 12 - rsaEncryption-EnvOID (PKCS1 v1.5) 13 - rsaES-OAEP-EnvOID (PKCS1 v2.0) 14 - des-ede3-cbc-EnvOID 15 +The above encryption types are used by the client only within the +KDC-REQ-BODY to indicate which CMS [14] algorithms it supports. Their +use within Kerberos EncryptedData structures is not specified by this +document. - The above encryption types are used by the client only within the - KDC-REQ-BODY to indicate which CMS [RFC2630] algorithms it supports. - Their use within Kerberos EncryptedData structures is not specified - by this document. +The ASN.1 module for all structures defined in this document (plus +IMPORT statements for all imported structures) are given in Appendix +A. In the event of a discrepancy between Appendix A and the portions +of ASN.1 in the main text, the appendix is normative. +All structures defined in this document MUST be encoded using +Distinguished Encoding Rules (DER). All imported data structures +must be encoded according to the rules specified in Kerberos [1] or +CMS [2] as appropriate. +Interoperability note: Some implementations may not be able to +decode CMS objects encoded with BER but not DER; specifically, they +may not be able to decode infinite length encodings. To maximize +interoperability, implementers SHOULD encode CMS objects used in +PKINIT with DER. -Tung, et al. Expires June 6, 2005 [Page 6] - -Internet-Draft PKINIT December 2004 +3.1.3. Algorithm Identifiers +PKINIT does not define, but does make use of, the following +algorithm identifiers. - The ASN.1 module for all structures defined in this document (plus - IMPORT statements for all imported structures) are given in Appendix - A. +PKINIT uses the following algorithm identifier for Diffie-Hellman +key agreement [9]: - All structures defined in this document MUST be encoded using - Distinguished Encoding Rules (DER) [X690]. All imported data - structures must be encoded according to the rules specified in - Kerberos [CLAR] or CMS [RFC2630] as appropriate. - - Interoperability note: Some implementations may not be able to decode - CMS objects encoded with BER but not DER; specifically, they may not - be able to decode infinite length encodings. To maximize - interoperability, implementers SHOULD encode CMS objects used in - PKINIT with DER. - -3.1.3 Algorithm Identifiers - - PKINIT does not define, but does make use of, the following algorithm - identifiers. - - PKINIT uses the following algorithm identifier for Diffie-Hellman key - agreement [FIPS74]: - - dhpublicnumber - - PKINIT uses the following signature algorithm identifiers [RFC3279]: - - sha-1WithRSAEncryption (RSA with SHA1) - md5WithRSAEncryption (RSA with MD5) - id-dsa-with-sha1 (DSA with SHA1) - - PKINIT uses the following encryption algorithm identifiers [RFC2437] - for encrypting the temporary key with a public key: - - rsaEncryption (PKCS1 v1.5) - id-RSAES-OAEP (PKCS1 v2.0) - - PKINIT uses the following algorithm identifiers [RFC2630] for - encrypting the reply key with the temporary key: - - des-ede3-cbc (three-key 3DES, CBC mode) - rc2-cbc (RC2, CBC mode) - aes256_CBC (AES-256, CBC mode) - - -3.2 PKINIT Preauthentication Syntax and Use - - This section defines the syntax and use of the various - - - -Tung, et al. Expires June 6, 2005 [Page 7] - -Internet-Draft PKINIT December 2004 - - - preauthentication fields employed by PKINIT. - -3.2.1 Client Request - - The initial authentication request (KRB_AS_REQ) is sent as per - [CLAR]; in addition, a preauthentication field contains data signed - by the client's private signature key, as follows: - - WrapContentInfo ::= OCTET STRING (CONSTRAINED BY { - -- Contains a BER encoding of ContentInfo. - }) - - - WrapIssuerAndSerial ::= OCTET STRING (CONSTRAINED BY { - -- Contains a BER encoding of IssuerAndSerialNumber. - }) - - - PA-PK-AS-REQ ::= SEQUENCE { - signedAuthPack [0] IMPLICIT WrapContentInfo, - -- Type is SignedData. - -- Content is AuthPack - -- (defined below). - trustedCertifiers [1] SEQUENCE OF TrustedCA OPTIONAL, - -- A list of CAs, trusted by - -- the client, used to certify - -- KDCs. - kdcCert [2] IMPLICIT WrapIssuerAndSerial - OPTIONAL, - -- Identifies a particular KDC - -- certificate, if the client - -- already has it. - clientDHNonce [3] DHNonce OPTIONAL, - ... - } - - - TrustedCA ::= CHOICE { - caName [1] Name, - -- Fully qualified X.500 name - -- as defined in [RFC3280]. - issuerAndSerial [2] IMPLICIT WrapIssuerAndSerial, - -- Identifies a specific CA - -- certificate. - ... - } - - - - - -Tung, et al. Expires June 6, 2005 [Page 8] - -Internet-Draft PKINIT December 2004 - - - AuthPack ::= SEQUENCE { - pkAuthenticator [0] PKAuthenticator, - clientPublicValue [1] SubjectPublicKeyInfo OPTIONAL, - -- Defined in [RFC3280]. - -- Present only if the client - -- is using ephemeral-ephemeral - -- Diffie-Hellman. - supportedCMSTypes [2] SEQUENCE OF AlgorithmIdentifier - OPTIONAL, - -- List of CMS encryption types - -- supported by client in order - -- of (decreasing) preference. - ... - } - - - PKAuthenticator ::= SEQUENCE { - cusec [0] INTEGER (0..999999), - ctime [1] KerberosTime, - -- cusec and ctime are used as - -- in [CLAR], for replay - -- prevention. - nonce [2] INTEGER (0..4294967295), - paChecksum [3] OCTET STRING, - -- Contains the SHA1 checksum, - -- performed over KDC-REQ-BODY. - ... - } - - The ContentInfo in the signedAuthPack is filled out as follows: - - 1. The eContent field contains data of type AuthPack. It MUST - contain the pkAuthenticator, and MAY also contain the client's - Diffie-Hellman public value (clientPublicValue). - - 2. The eContentType field MUST contain the OID value for - id-pkauthdata: { iso(1) org(3) dod(6) internet(1) security(5) - kerberosv5(2) pkinit(3) pkauthdata(1) }. - - 3. The signerInfos field MUST contain the signature over the - AuthPack. - - 4. The certificates field MUST contain at least a signature - verification certificate chain that the KDC can use to verify the - signature over the AuthPack. The certificate chain(s) MUST NOT - contain the root CA certificate. - - - - - -Tung, et al. Expires June 6, 2005 [Page 9] - -Internet-Draft PKINIT December 2004 - - - 5. If a Diffie-Hellman key is being used, the parameters MUST be - chosen from Oakley Group 2 or 14. Implementations MUST support - Group 2; they are RECOMMENDED to support Group 14 (See - [RFC2409]). - - 6. The client may wish to cache DH parameters or to allow the KDC to - do so. If so, then the client must include the clientDHNonce - field. The nonce string needs to be as long as the longest key - length of the symmetric key types that the client supports. The - nonce MUST be chosen randomly. - - -3.2.2 Validation of Client Request - - Upon receiving the client's request, the KDC validates it. This - section describes the steps that the KDC MUST (unless otherwise - noted) take in validating the request. - - The KDC must look for a client certificate in the signedAuthPack. If - it cannot find one signed by a CA it trusts, it sends back an error - of type KDC_ERR_CANT_VERIFY_CERTIFICATE. The accompanying e-data for - this error is a TYPED-DATA (as defined in [CLAR]). For this error, - the data-type is TD-TRUSTED-CERTIFIERS, and the data-value is the DER - encoding of - - TrustedCertifiers ::= SEQUENCE OF Name - - If, while verifying the certificate chain, the KDC determines that - the signature on one of the certificates in the signedAuthPack is - invalid, it returns an error of type KDC_ERR_INVALID_CERTIFICATE. - The accompanying e-data for this error is a TYPED-DATA, whose - data-type is TD-CERTIFICATE-INDEX, and whose data-value is the DER - encoding of the index into the CertificateSet field, ordered as sent - by the client: - - CertificateIndex ::= IssuerAndSerialNumber - -- IssuerAndSerialNumber of - -- certificate with invalid signature. - - If more than one certificate signature is invalid, the KDC MAY send - one TYPED-DATA per invalid signature. - - - The KDC MAY also check whether any certificates in the client's chain - have been revoked. If any of them have been revoked, the KDC MUST - return an error of type KDC_ERR_REVOKED_CERTIFICATE; if the KDC - attempts to determine the revocation status but is unable to do so, - it SHOULD return an error of type KDC_ERR_REVOCATION_STATUS_UNKNOWN. - - - -Tung, et al. Expires June 6, 2005 [Page 10] - -Internet-Draft PKINIT December 2004 - - - The certificate or certificates affected are identified exactly as - for an error of type KDC_ERR_INVALID_CERTIFICATE (see above). - - In addition to validating the certificate chain, the KDC MUST also - check that the certificate properly maps to the client's principal - name as specified in the KRB_AS_REQ as follows: - - 1. If the KDC has its own mapping from the name in the certificate - to a Kerberos name, it uses that Kerberos name. - - 2. Otherwise, if the certificate contains a SubjectAltName extension - with a Kerberos name in the otherName field, it uses that name. - - The otherName field (of type AnotherName) in the SubjectAltName - extension MUST contain krb5PrincipalName as defined below. - - The type-id is: - - krb5PrincipalName OBJECT IDENTIFIER ::= iso (1) org (3) dod (6) - internet (1) security (5) kerberosv5 (2) 2 - - - The value is the DER encoding of the following ASN.1 type: - - - KRB5PrincipalName ::= SEQUENCE { - realm [0] Realm, - principalName [1] PrincipalName - } - - If the KDC does not have its own mapping and there is no Kerberos - name present in the certificate, or if the name in the request does - not match the name in the certificate (including the realm name), or - if there is no name in the request, the KDC MUST return error code - KDC_ERR_CLIENT_NAME_MISMATCH. There is no accompanying e-data for - this error. - - Even if the certificate chain is validated, and the names in the - certificate and the request match, the KDC may decide to reject - requests on the basis of the absence or presence of specific EKU - OIDs. For example, the certificate may include an Extended Key Usage - (EKU) OID of id-pkekuoid in the extensions field: - - { iso(1) org(3) dod(6) internet(1) security(5) kerberosv5(2) - pkinit(3) pkekuoid(4) } - - The KDC MUST return the error code KDC_ERR_CLIENT_NOT_TRUSTED if the - client's cerficate is not accepted. - - - -Tung, et al. Expires June 6, 2005 [Page 11] - -Internet-Draft PKINIT December 2004 - - - If the client's signature on the signedAuthPack fails to verify, the - KDC MUST return error KDC_ERR_INVALID_SIG. There is no accompanying - e-data for this error. - - The KDC MUST check the timestamp to ensure that the request is not a - replay, and that the time skew falls within acceptable limits. The - recommendations clock skew times in [CLAR] apply here. If the check - fails, the KDC MUST return error code KRB_AP_ERR_REPEAT or - KRB_AP_ERR_SKEW, respectively. - - If the clientPublicValue is filled in, indicating that the client - wishes to use ephemeral-ephemeral Diffie-Hellman, the KDC checks to - see if the parameters satisfy its policy. If they do not, it MUST - return error code KDC_ERR_KEY_SIZE. The accompanying e-data is a - TYPED-DATA, whose data-type is TD-DH-PARAMETERS, and whose data-value - is the DER encoding of a DomainParameters (see [RFC3279]), including - appropriate Diffie-Hellman parameters with which to retry the - request. - - The KDC MUST return error code KDC_ERR_CERTIFICATE_MISMATCH if the - client included a kdcCert field in the PA-PK-AS-REQ and the KDC does - not have the corresponding certificate. - - The KDC MUST return error code KDC_ERR_KDC_NOT_TRUSTED if the client - did not include a kdcCert field, but did include a trustedCertifiers - field, and the KDC does not possesses a certificate issued by one of - the listed certifiers. - - If there is a supportedCMSTypes field in the AuthPack, the KDC must - check to see if it supports any of the listed types. If it supports - more than one of the types, the KDC SHOULD use the one listed first. - If it does not support any of them, it MUST return an error of type - KRB5KDC_ERR_ETYPE_NOSUPP. - -3.2.3 KDC Reply - - Assuming that the client's request has been properly validated, the - KDC proceeds as per [CLAR], except as follows. - - The KDC MUST set the initial flag and include an authorization data - of type AD-INITIAL-VERIFIED-CAS in the issued ticket. The value is - an OCTET STRING containing the DER encoding of InitialVerifiedCAs: - - InitialVerifiedCAs ::= SEQUENCE OF SEQUENCE { - ca [0] Name, - Validated [1] BOOLEAN, - ... - } - - - -Tung, et al. Expires June 6, 2005 [Page 12] - -Internet-Draft PKINIT December 2004 - - - The KDC MAY wrap any AD-INITIAL-VERIFIED-CAS data in AD-IF-RELEVANT - containers if the list of CAs satisfies the KDC's realm's policy - (this corresponds to the TRANSITED-POLICY-CHECKED ticket flag). - Furthermore, any TGS must copy such authorization data from tickets - used in a PA-TGS-REQ of the TGS-REQ to the resulting ticket, - including the AD-IF-RELEVANT container, if present. - - Application servers that understand this authorization data type - SHOULD apply local policy to determine whether a given ticket bearing - such a type *not* contained within an AD-IF-RELEVANT container is - acceptable. (This corresponds to the AP server checking the - transited field when the TRANSITED-POLICY-CHECKED flag has not been - set.) If such a data type is contained within an AD-IF-RELEVANT - container, AP servers MAY apply local policy to determine whether the - authorization data is acceptable. - - The KRB_AS_REP is otherwise unchanged from [CLAR]. The KDC encrypts - the reply as usual, but not with the client's long-term key. - Instead, it encrypts it with either a generated encryption key, or a - key derived from a Diffie-Hellman exchange. The contents of the - PA-PK-AS-REP indicate the type of encryption key that was used: - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Tung, et al. Expires June 6, 2005 [Page 13] - -Internet-Draft PKINIT December 2004 - - - PA-PK-AS-REP ::= CHOICE { - dhInfo [0] DHRepInfo, - encKeyPack [1] IMPLICIT WrapContentInfo, - -- Type is EnvelopedData. - -- Content is SignedData over - -- ReplyKeyPack (defined below). - ... - } - - DHRepInfo ::= SEQUENCE { - dhSignedData [0] ContentInfo, - -- Type is SignedData. - -- Content is KDCDHKeyInfo - -- (defined below). - serverDHNonce [1] DHNonce OPTIONAL - } - - KDCDHKeyInfo ::= SEQUENCE { - subjectPublicKey [0] BIT STRING, - -- Equals public exponent - -- (g^a mod p). - -- INTEGER encoded as payload - -- of BIT STRING. - nonce [1] INTEGER (0..4294967295), - dhKeyExpiration [2] KerberosTime OPTIONAL, - -- Expiration time for KDC's - -- cached values. If this field - -- is omitted then the - -- serverDHNonce field MUST also - -- be omitted. - ... - } - - The fields of the ContentInfo for dhSignedData are to be filled in as - follows: - - 1. The eContent field contains data of type KDCDHKeyInfo. - - 2. The eContentType field contains the OID value for id-pkdhkeydata: - { iso(1) org(3) dod(6) internet(1) security(5) kerberosv5(2) - pkinit(3) pkdhkeydata(2) }. - - 3. The signerInfos field contains a single signerInfo, which is the - signature of the KDCDHKeyInfo. - - 4. The certificates field contains a signature verification - certificate chain that the client will use to verify the KDC's - signature over the KDCDHKeyInfo. This field may only be left - - - -Tung, et al. Expires June 6, 2005 [Page 14] - -Internet-Draft PKINIT December 2004 - - - empty if the client did include a kdcCert field in the - PA-PK-AS-REQ, indicating that it has the KDC's certificate. The - certificate chain MUST NOT contain the root CA certificate. - - 5. If the client included the clientDHNonce field, then the KDC may - choose to reuse its DH parameters. If the server reuses DH - parameters then it MUST include an expiration time in the - dhKeyExperiation field. Past the point of the expiration time, - the signature of the DHRepInfo is considered invalid. When the - server reuses DH parameters then it MUST include a serverDHNonce - at least as long as the length of keys for the symmetric - encryption system used to encrypt the AS reply. Note that - including the serverDHNonce changes how the client and server - calculate the key to use to encrypt the reply; see below for - details. Clients MUST NOT reuse DH parameters unless the - response includes the serverDHNonce field. - - If the Diffie-Hellman key exchange is used, the KDC reply key [CLAR] - is derived as follows: - - 1. Both the KDC and the client calculate the shared secret value - - DHKey = g^(ab) mod p - - where a and b are the client's and KDC's private exponents, - respectively. DHKey, padded first with leading zeros as needed to - make it as long as the modulus p, is represented as a string of - octets in big-endian order (such that the size of DHKey in octets - is the size of the modulus p). - - 2. Let K be the key-generation seed length [KCRYPTO] of the reply - key whose enctype is selected according to [CLAR]. - - 3. Define the function octetstring2key() as follows: - - octetstring2key(x) == random-to-key(K-truncate( - SHA1(0x00 | x) | - SHA1(0x01 | x) | - SHA1(0x02 | x) | - ... - )) - - where x is an octet string; | is the concatenation operator; 0x00, - 0x01, 0x02, etc., are each represented as a single octet; - random-to-key() is an operation that generates a protocolkey from - a bitstring of length K; and K-truncate truncates its input to K - bits. Both K and random-to-key() are defined in the kcrypto - profile [KCRYPTO] for the enctype of the reply key. - - - -Tung, et al. Expires June 6, 2005 [Page 15] - - - 4. When cached DH parameters are used, let n_c be the clientDHNonce, - and n_k be the serverDHNonce; otherwise, let both n_c and n_k be - empty octet strings. - - 5. The KDC reply key k is: - - k = octetstring2key(DHKey | n_c | n_k) - - If the Diffie-Hellman key exchange is not used, the KDC reply key - [CLAR] is encrypted in the encKeyPack, which contains data of type - ReplyKeyPack: - - ReplyKeyPack ::= SEQUENCE { - replyKey [0] EncryptionKey, - -- Defined in [CLAR]. - -- Used to encrypt main reply. - -- MUST be at least as strong - -- as session key. (Using the - -- same enctype and a strong - -- prng should suffice, if no - -- stronger encryption system - -- is available.) - nonce [1] INTEGER (0..4294967295), - -- Contains the nonce in - -- the KDCDHKeyInfo. - ... - } - - The fields of the ContentInfo for encKeyPack MUST be filled in as - follows: - - 1. The content is of type SignedData. The eContent for the - SignedData is of type ReplyKeyPack. - - 2. The eContentType for the SignedData contains the OID value for - id-pkrkeydata: { iso(1) org(3) dod(6) internet(1) security(5) - kerberosv5(2) pkinit(3) pkrkeydata(3) }. - - 3. The signerInfos field contains a single signerInfo, which is the - signature of the ReplyKeyPack. - - 4. The certificates field contains a signature verification - certificate chain that the client will use to verify the KDC's - signature over the ReplyKeyPack. This field may only be left - empty if the client included a kdcCert field in the PA-PK-AS-REQ, - indicating that it has the KDC's certificate. The certificate - chain MUST NOT contain the root CA certificate. - - - - - - -Tung, et al. Expires June 6, 2005 [Page 16] - -Internet-Draft PKINIT December 2004 - - - 5. The contentType for the EnvelopedData contains the OID value for - id-signedData: { iso (1) member-body (2) us (840) rsadsi (113549) - pkcs (1) pkcs7 (7) signedData (2) }. - - 6. The recipientInfos field is a SET which MUST contain exactly one - member of type KeyTransRecipientInfo. The encryptedKey for this - member contains the temporary key which is encrypted using the - client's public key. - - 7. The unprotectedAttrs or originatorInfo fields MAY be present. - -3.2.4 Validation of KDC Reply - - Upon receipt of the KDC's reply, the client proceeds as follows. If - the PA-PK-AS-REP contains a dhSignedData, the client obtains and - verifies the Diffie-Hellman parameters, and obtains the shared key as - described above. Otherwise, the message contains an encKeyPack, and - the client decrypts and verifies the temporary encryption key. - - In either case, the client MUST check to see if the included - certificate contains a subjectAltName extension of type dNSName or - iPAddress (if the KDC is specified by IP address instead of name). - If it does, it MUST check to see if that extension matches the KDC it - believes it is communicating with, with matching rules specified in - RFC 2459. Exception: If the client has some external information as - to the identity of the KDC, this check MAY be omitted. - - The client also MUST check that the KDC's certificate contains an - extendedKeyUsage OID of id-pkkdcekuoid: - - { iso(1) org(3) dod(6) internet(1) security(5) kerberosv5(2) - pkinit(3) pkkdcekuoid(5) } - - If all applicable checks are satisfied, the client then decrypts the - main reply with the resulting key, and then proceeds as described in - [1]. - -3.3 KDC Indication of PKINIT Support - - If pre-authentication is required, but was not present in the - request, per [CLAR] an error message with the code - KDC_ERR_PREAUTH_FAILED is returned and a METHOD-DATA object will be - stored in the e-data field of the KRB-ERROR message to specify which - pre-authentication mechanisms are acceptable. The KDC can then - indicate the support of PKINIT by including a PA-PK-AS-REQ element in - that METHOD-DATA object. - - Otherwise if it is required by the KDC's local policy that the client - - - -Tung, et al. Expires June 6, 2005 [Page 17] - -Internet-Draft PKINIT December 2004 - - - must be pre-authenticated using the preauthentication mechanism - specified in this document, but no PKINIT pre-authentication was - present in the request, an error message with the code - KDC_ERR_PREAUTH_FAILED SHOULD be returned. - - The padata-value for the PA-PK-AS-REQ entry in the METHOD-DATA object - is an empty octet string and SHOULD be ignored otherwise. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Tung, et al. Expires June 6, 2005 [Page 18] - -Internet-Draft PKINIT December 2004 + dhpublicnumber + +PKINIT uses the following signature algorithm identifiers [8, 12]: + + sha-1WithRSAEncryption (RSA with SHA1) + md5WithRSAEncryption (RSA with MD5) + id-dsa-with-sha1 (DSA with SHA1) + +PKINIT uses the following encryption algorithm identifiers [5] for +encrypting the temporary key with a public key: + + rsaEncryption (PKCS1 v1.5) + id-RSAES-OAEP (PKCS1 v2.0) + +PKINIT uses the following algorithm identifiers [14, 8] for +encrypting the reply key with the temporary key: + + des-ede3-cbc (three-key 3DES, CBC mode) + rc2-cbc (RC2, CBC mode) + id-aes256-CBC (AES-256, CBC mode) + + +3.2. PKINIT Preauthentication Syntax and Use + +This section defines the syntax and use of the various +preauthentication fields employed by PKINIT. + + +3.2.1. Client Request + +The initial authentication request (AS-REQ) is sent as per [1]; in +addition, a preauthentication field contains data signed by the +client's private signature key, as follows: + + WrapContentInfo ::= OCTET STRING (CONSTRAINED BY { + -- Contains a BER encoding of + -- ContentInfo + }) + + WrapIssuerAndSerial ::= OCTET STRING (CONSTRAINED BY { + -- Contains a BER encoding of + -- IssuerAndSerialNumber + }) + + PA-PK-AS-REQ ::= SEQUENCE { + signedAuthPack [0] IMPLICIT WrapContentInfo, + -- Type is SignedData. + -- Content is AuthPack + -- (defined below). + trustedCertifiers [1] SEQUENCE OF TrustedCA OPTIONAL, + -- A list of CAs, trusted by + -- the client, used to certify + -- KDCs. + kdcCert [2] IMPLICIT WrapIssuerAndSerial + OPTIONAL, + -- Identifies a particular KDC + -- certificate, if the client + -- already has it. + ... + } + + TrustedCA ::= CHOICE { + caName [1] Name, + -- Fully qualified X.500 name + -- as defined in RFC 3280 [4]. + issuerAndSerial [2] IMPLICIT WrapIssuerAndSerial, + -- Identifies a specific CA + -- certificate. + ... + } + + AuthPack ::= SEQUENCE { + pkAuthenticator [0] PKAuthenticator, + clientPublicValue [1] SubjectPublicKeyInfo OPTIONAL, + -- Defined in RFC 3280 [4]. + -- Present only if the client + -- is using ephemeral-ephemeral + -- Diffie-Hellman. + supportedCMSTypes [2] SEQUENCE OF AlgorithmIdentifier + OPTIONAL, + -- List of CMS encryption types + -- supported by client in order + -- of (decreasing) preference. + ... + } + + PKAuthenticator ::= SEQUENCE { + cusec [0] INTEGER (0..999999), + ctime [1] KerberosTime, + -- cusec and ctime are used as + -- in [1], for replay + -- prevention. + nonce [2] INTEGER (0..4294967295), + -- Binds reply to request, + -- MUST be zero when client + -- will accept cached + -- Diffie-Hellman parameters + -- from KDC. MUST NOT be + -- zero otherwise. + paChecksum [3] OCTET STRING OPTIONAL, + -- Defined in [1]. + -- Performed over KDC-REQ-BODY, + -- MUST be unkeyed. + ... + } + +The ContentInfo in the signedAuthPack is filled out as follows: + + 1. The eContent field MUST contain data of type AuthPack. + The supportedCMSTypes field is filled with the algorithm + identifiers that the client supports, in order of + preference, with most preferred first. + + 2. The eContentType field MUST contain the OID value for + id-pkauthdata: { iso(1) org(3) dod(6) internet(1) + security(5) kerberosv5(2) pkinit(3) pkauthdata(1)} + + 3. The signerInfos field MUST contain the signature over the + AuthPack. + + 4. The certificates field MUST contain at least a signature + verification certificate chain that the KDC can use to + verify the signature over the AuthPack. The certificate + chain(s) MUST NOT contain the root CA certificate. + + 5. If a Diffie-Hellman key is being used, the parameters MUST + be chosen from Oakley Group 2 or 14. Implementations MUST + support Group 2; they are RECOMMENDED to support Group 14. + (See RFC 2409 [10] and RFC 3526 [13].) + + 6. The KDC may wish to use cached Diffie-Hellman parameters. + To indicate acceptance of caching, the client sends zero in + the nonce field of the pkAuthenticator. Zero is not a valid + value for this field under any other circumstances. Since + zero is used to indicate acceptance of cached parameters, + message binding in this case is performed using only the + nonce in the main request. + + +3.2.2. Validation of Client Request + +Upon receiving the client's request, the KDC validates it. This +section describes the steps that the KDC MUST (unless otherwise +noted) take in validating the request. + +The KDC must look for a client certificate in the signedAuthPack. +If it cannot find one signed by a CA it trusts, it sends back an +error of type KDC_ERR_CANT_VERIFY_CERTIFICATE. The accompanying +e-data for this error is a TYPED-DATA (as defined in [1]). For this +error, the data-type is TD-TRUSTED-CERTIFIERS, and the data-value is +the DER encoding of + + KDCTrustedCertifiers ::= SEQUENCE OF Name + +If, while verifying the certificate chain, the KDC determines that +the signature on one of the certificates in the signedAuthPack is +invalid, it returns an error of type KDC_ERR_INVALID_CERTIFICATE. +The accompanying e-data for this error is a TYPED-DATA, whose +data-type is TD-CERTIFICATE-INDEX, and whose data-value is the DER +encoding of the index into the CertificateSet field, ordered as sent +by the client: + + CertificateIndex ::= IssuerAndSerialNumber + -- IssuerAndSerialNumber of + -- certificate with invalid signature + +If more than one certificate signature is invalid, the KDC MAY send +one TYPED-DATA per invalid signature. + +The KDC MAY also check whether any certificates in the client's +chain have been revoked. If any of them have been revoked, the KDC +MUST return an error of type KDC_ERR_REVOKED_CERTIFICATE; if the KDC +attempts to determine the revocation status but is unable to do so, +it SHOULD return an error of type KDC_ERR_REVOCATION_STATUS_UNKNOWN. +The certificate or certificates affected are identified exactly as +for an error of type KDC_ERR_INVALID_CERTIFICATE (see above). + +In addition to validating the certificate chain, the KDC MUST also +check that the certificate properly maps to the client's principal name +as specified in the AS-REQ as follows: + + 1. If the KDC has its own mapping from the name in the + certificate to a Kerberos name, it uses that Kerberos + name. + + 2. Otherwise, if the certificate contains a SubjectAltName + extension with a Kerberos name in the otherName field, + it uses that name. The otherName field (of type AnotherName) + in the SubjectAltName extension MUST contain the following: + + The type-id is: + + krb5PrincipalName OBJECT IDENTIFIER ::= { + iso (1) org (3) dod (6) internet (1) security (5) + kerberosv5 (2) 2 + } + + The value is: + + KRB5PrincipalName ::= SEQUENCE { + realm [0] Realm, + principalName [1] PrincipalName + } + +If the KDC does not have its own mapping and there is no Kerberos +name present in the certificate, or if the name in the request does +not match the name in the certificate (including the realm name), or +if there is no name in the request, the KDC MUST return error code +KDC_ERR_CLIENT_NAME_MISMATCH. There is no accompanying e-data +for this error. + +Even if the chain is validated, and the names in the certificate and +the request match, the KDC may decide not to trust the client. For +example, the certificate may include an Extended Key Usage (EKU) OID +in the extensions field. As a matter of local policy, the KDC may +decide to reject requests on the basis of the absence or presence of +specific EKU OIDs. In this case, the KDC MUST return error code +KDC_ERR_CLIENT_NOT_TRUSTED. The PKINIT EKU OID is defined as: + + { iso(1) org(3) dod(6) internet(1) security(5) kerberosv5(2) + pkinit(3) pkekuoid(4) } + +If the client's signature on the signedAuthPack fails to verify, or +if there is no paChecksum field, the KDC MUST return error +KDC_ERR_INVALID_SIG. There is no accompanying e-data for this +error. + +The KDC MUST check the timestamp to ensure that the request is not +a replay, and that the time skew falls within acceptable limits. +The recommendations clock skew times in [1] apply here. If the +check fails, the KDC MUSTreturn error code KRB_AP_ERR_REPEAT or +KRB_AP_ERR_SKEW, respectively. + +If the clientPublicValue is filled in, indicating that the client +wishes to use ephemeral-ephemeral Diffie-Hellman, the KDC checks to +see if the parameters satisfy its policy. If they do not, it MUST +return error code KDC_ERR_KEY_SIZE. The accompanying e-data is a +TYPED-DATA, whose data-type is TD-DH-PARAMETERS, and whose +data-value is the DER encoding of a DomainParameters (see [3]), +including appropriate Diffie-Hellman parameters with which to retry +the request. + +The KDC MUST return error code KDC_ERR_CERTIFICATE_MISMATCH if the +client included a kdcCert field in the PA-PK-AS-REQ and the KDC does +not have the corresponding certificate. + +The KDC MUST return error code KDC_ERR_KDC_NOT_TRUSTED if the client +did not include a kdcCert field, but did include a trustedCertifiers +field, and the KDC does not possesses a certificate issued by one of +the listed certifiers. + +If there is a supportedCMSTypes field in the AuthPack, the KDC must +check to see if it supports any of the listed types. If it supports +more than one of the types, the KDC SHOULD use the one listed first. +If it does not support any of them, it MUST return an error of type +KRB5KDC_ERR_ETYPE_NOSUPP. + + +3.2.3. KDC Reply + +Assuming that the client's request has been properly validated, the +KDC proceeds as per [1], except as follows. + +The KDC MUST set the initial flag and include an authorization data +of type AD-INITIAL-VERIFIED-CAS in the issued ticket. The value is +an OCTET STRING containing the DER encoding of InitialVerifiedCAs: + + InitialVerifiedCAs ::= SEQUENCE OF SEQUENCE { + ca [0] Name, + Validated [1] BOOLEAN, + ... + } + +The KDC MAY wrap any AD-INITIAL-VERIFIED-CAS data in AD-IF-RELEVANT +containers if the list of CAs satisfies the KDC's realm's policy. +(This corresponds to the TRANSITED-POLICY-CHECKED ticket flag.) +Furthermore, any TGS must copy such authorization data from tickets +used in a PA-TGS-REQ of the TGS-REQ to the resulting ticket, +including the AD-IF-RELEVANT container, if present. + +Application servers that understand this authorization data type +SHOULD apply local policy to determine whether a given ticket +bearing such a type *not* contained within an AD-IF-RELEVANT +container is acceptable. (This corresponds to the AP server +checking the transited field when the TRANSITED-POLICY-CHECKED flag +has not been set.) If such a data type is contained within an +AD-IF-RELEVANT container, AP servers MAY apply local policy to +determine whether the authorization data is acceptable. + +The AS-REP is otherwise unchanged from [1]. The KDC encrypts the +reply as usual, but not with the client's long-term key. Instead, +it encrypts it with either a generated encryption key, or a key +derived from a Diffie-Hellman exchange. The contents of the +PA-PK-AS-REP indicate the type of encryption key that was used: + + PA-PK-AS-REP ::= CHOICE { + dhSignedData [0] IMPLICIT WrapContentInfo, + -- Type is SignedData. + -- Content is KDCDHKeyInfo + -- (defined below). + encKeyPack [1] IMPLICIT WrapContentInfo, + -- Type is EnvelopedData. + -- Encrypted using client's + -- public key certificate. + -- Content is SignedData over + -- ReplyKeyPack (defined below). + ... + } + + KDCDHKeyInfo ::= SEQUENCE { + subjectPublicKey [0] BIT STRING, + -- Equals public exponent + -- (g^a mod p). + -- INTEGER encoded as payload + -- of BIT STRING. + nonce [1] INTEGER (0..4294967295), + -- Binds reply to request. + -- Exception: A value of zero + -- indicates that the KDC is + -- using cached values. + dhKeyExpiration [2] KerberosTime OPTIONAL, + -- Expiration time for KDC's + -- cached values. + ... + } + +The fields of the ContentInfo for dhSignedData are to be filled in +as follows: + + 1. The eContent field contains data of type KDCDHKeyInfo. + + 2. The eContentType field contains the OID value for + id-pkdhkeydata: { iso(1) org(3) dod(6) internet(1) + security(5) kerberosv5(2) pkinit(3) pkdhkeydata(2) } + + 3. The signerInfos field contains a single signerInfo, which is + the signature of the KDCDHKeyInfo. + + 4. The certificates field contains a signature verification + certificate chain that the client will use to verify the + KDC's signature over the KDCDHKeyInfo. This field may only + be left empty if the client did include a kdcCert field in + the PA-PK-AS-REQ, indicating that it has the KDC's + certificate. The certificate chain MUST NOT contain the + root CA certificate. + + 5. If the client and KDC agree to use cached parameters, the + KDC MUST return a zero in the nonce field and include the + expiration time of the cached values in the dhKeyExpiration + field. If this time is exceeded, the client MUST NOT use + the reply. If the time is absent, the client MUST NOT use + the reply and MAY resubmit a request with a non-zero nonce, + thus indicating non-acceptance of the cached parameters. + +The KDC reply key is derived as follows: + + 1. Both the KDC and the client calculate the shared secret + value + + DHKey = g^(ab) mod p + + where a and b are the client's and KDC's private exponents, + respectively. DHKey, padded first with leading zeros as + needed to make it as long as the modulus p, is represented + as a string of octets in big-endian order (such that the + size of DHKey in octets is the size of the modulus p). + + 2. Let K be the key-generation seed length [6] of the reply key + whose enctype is selected according to [1]. + + 3. Define the function octetstring2key() as follows: + + octetstring2key(x) == random-to-key(K-truncate( + sha1(0x00 | x) | + sha1(0x01 | x) | + sha1(0x02 | x) | + ... + )) + + where x is an octet string; | is the concatenation operator; + 0x00, 0x01, 0x02, etc. are each represented as a single + octet; random-to-key() is an operation that generates a + protocolkey from a bitstring of length K; and K-truncate + truncates its input to K bits. Both K and random-to-key() + are defined in the kcrypto profile [6] for the enctype of + the reply key. + + 4. When cached DH parameters are used, let n_c be the + clientDHNonce, and n_k be the serverDHNonce; otherwise, let + both n_c and n_k be empty octet strings. The reply key k is + + k = octetstring2key(DHKey | n_c | n_k) + +If the KDC and client are not using Diffie-Hellman, the KDC encrypts +the reply with an encryption key, packed in the encKeyPack, which +contains data of type ReplyKeyPack: + + ReplyKeyPack ::= SEQUENCE { + replyKey [0] EncryptionKey, + -- Defined in [1]. + -- Used to encrypt main reply. + -- MUST be at least as strong + -- as session key. (Using the + -- same enctype and a strong + -- prng should suffice, if no + -- stronger encryption system + -- is available.) + nonce [1] INTEGER (0..4294967295), + -- Binds reply to request. + ... + } + +The fields of the ContentInfo for encKeyPack MUST be filled in as +follows: + + 1. The content is of type SignedData. The eContent for + the SignedData is of type ReplyKeyPack. + + 2. The eContentType for the SignedData contains the OID value + for id-pkrkeydata: { iso(1) org(3) dod(6) internet(1) + security(5) kerberosv5(2) pkinit(3) pkrkeydata(3) } + + 3. The signerInfos field contains a single signerInfo, which is + the signature of the ReplyKeyPack. + + 4. The certificates field contains a signature verification + certificate chain that the client will use to verify the + KDC's signature over the ReplyKeyPack. This field may only + be left empty if the client included a kdcCert field in the + PA-PK-AS-REQ, indicating that it has the KDC's certificate. + The certificate chain MUST NOT contain the root CA + certificate. + + 5. The contentType for the EnvelopedData contains the OID value + for id-signedData: { iso (1) member-body (2) us (840) rsadsi + (113549) pkcs (1) pkcs7 (7) signedData (2) } + + 6. The enveloped data MUST contain one KeyTransRecipientInfo, + which is targeted to the client's certificate (obtained in + the initial request). + + 7. The unprotectedAttrs or originatorInfo fields MAY be + present. + + +3.2.4. Validation of KDC Reply + +Upon receipt of the KDC's reply, the client proceeds as follows. If +the PA-PK-AS-REP contains a dhSignedData, the client obtains and +verifies the Diffie-Hellman parameters, and obtains the shared key +as described above. Otherwise, the message contains an encKeyPack, +and the client decrypts and verifies the temporary encryption key. + +In either case, the client MUST check to see if the included +certificate contains a subjectAltName extension of type dNSName or +iPAddress (if the KDC is specified by IP address instead of name). +If it does, it MUST check to see if that extension matches the KDC +it believes it is communicating with, with matching rules specified +in RFC 2459. Exception: If the client has some external information +as to the identity of the KDC, this check MAY be omitted. + +The client also MUST check that the KDC's certificate contains an +extendedKeyUsage OID of id-pkkdcekuoid: + + { iso(1) org(3) dod(6) internet(1) security(5) kerberosv5(2) + pkinit(3) pkkdcekuoid(5) } + +If all applicable checks are satisfied, the client then decrypts the +main reply with the resulting key, and then proceeds as described in +[1]. + + +3.2.5. Indicating PKINIT Support + +A KDC that supports PKINIT SHOULD indicate support for PKINIT to +clients that did not include any or acceptable pre-authentication in +their AS requests. As per [1], KDCs respond to such requests with a +KRB-ERROR with KDC_ERR_PREAUTH_REQUIRED as the error code and with a +list of pre-authentication data in the KRB-ERROR's e-data field. + +To indicate support for PKINIT, then, a KDC MUST include, in +KDC_ERR_PREAUTH_REQUIRED KRB-ERROR messages, a padata element of +type PA-PK-AS-ERR. The padata-value field of this padata element +MUST be set to the zero-length string; clients MUST ignore this and +any other value. + +A client that receives a KRB-ERROR message, bearing a PA-PK-AS-ERR +padata element, from a KDC in response to its AS-REQ should take the +message as an indication of support by the KDC for PKINIT. The +client MAY respond by attempting a new AS exchange using its +preferred pre-authentication mechanism for which the KDC has +indicated support in its error message and for which the client has +credentials, possibly including PKINIT. + +Future extensions to PKINIT may provide for the use of the value of +PA-PK-AS-ERR padata elements to indicate such details as KDCs' PKI +trust anchors, negotiation preferences, etc. 4. Security Considerations - PKINIT raises certain security considerations beyond those that can - be regulated strictly in protocol definitions. We will address them - in this section. +PKINIT raises certain security considerations beyond those that can +be regulated strictly in protocol definitions. We will address them +in this section. - PKINIT extends the cross-realm model to the public-key - infrastructure. Users of PKINIT must understand security policies - and procedures appropriate to the use of Public Key Infrastructures. +PKINIT extends the cross-realm model to the public-key +infrastructure. Users of PKINIT must understand security policies +and procedures appropriate to the use of Public Key Infrastructures. - Standard Kerberos allows the possibility of interactions between - cryptosystems of varying strengths; this document adds interactions - with public-key cryptosystems to Kerberos. Some administrative - policies may allow the use of relatively weak public keys. Using - such keys to wrap data encrypted under stronger conventional - cryptosystems may be inappropriate. +Standard Kerberos allows the possibility of interactions between +cryptosystems of varying strengths; this document adds interactions +with public-key cryptosystems to Kerberos. Some administrative +policies may allow the use of relatively weak public keys. Using +such keys to wrap data encrypted under stronger conventional +cryptosystems may be inappropriate. - PKINIT requires keys for symmetric cryptosystems to be generated. - Some such systems contain "weak" keys. For recommendations regarding - these weak keys, see [CLAR]. +PKINIT requires keys for symmetric cryptosystems to be generated. +Some such systems contain "weak" keys. For recommendations regarding +these weak keys, see [1]. - PKINIT allows the use of a zero nonce in the PKAuthenticator when - cached Diffie-Hellman keys are used. In this case, message binding - is performed using the nonce in the main request in the same way as - it is done for ordinary KRB_AS_REQs (without the PKINIT - pre-authenticator). The nonce field in the KDC request body is - signed through the checksum in the PKAuthenticator, which - cryptographically binds the PKINIT pre-authenticator to the main body - of the AS Request and also provides message integrity for the full AS - Request. +PKINIT allows the use of a zero nonce in the PKAuthenticator when +cached Diffie-Hellman keys are used. In this case, message binding +is performed using the nonce in the main request in the same way as +it is done for ordinary AS-REQs (without the PKINIT +pre-authenticator). The nonce field in the KDC request body is +signed through the checksum in the PKAuthenticator, which +cryptographically binds the PKINIT pre-authenticator to the main +body of the AS Request and also provides message integrity for the +full AS Request. - However, when a PKINIT pre-authenticator in the KRB_AS_REP has a - zero-nonce, and an attacker has somehow recorded this - pre-authenticator and discovered the corresponding Diffie-Hellman - private key (e.g., with a brute-force attack), the attacker will be - able to fabricate his own KRB_AS_REP messages that impersonate the - KDC with this same pre-authenticator. This compromised - pre-authenticator will remain valid as long as its expiration time - has not been reached and it is therefore important for clients to - check this expiration time and for the expiration time to be - reasonably short, which depends on the size of the Diffie-Hellman - group. +However, when a PKINIT pre-authenticator in the AS-REP has a +zero-nonce, and an attacker has somehow recorded this +pre-authenticator and discovered the corresponding Diffie-Hellman +private key (e.g., with a brute-force attack), the attacker will be +able to fabricate his own AS-REP messages that impersonate the KDC +with this same pre-authenticator. This compromised pre-authenticator +will remain valid as long as its expiration time has not been reached +and it is therefore important for clients to check this expiration +time and for the expiration time to be reasonably short, which +depends on the size of the Diffie-Hellman group. - Care should be taken in how certificates are chosen for the purposes - of authentication using PKINIT. Some local policies may require that - key escrow be used for certain certificate types. Deployers of - PKINIT should be aware of the implications of using certificates that - have escrowed keys for the purposes of authentication. +If a client also caches its Diffie-Hellman keys, then the session key +could remain the same during multiple AS-REQ/AS-REP exchanges and an +attacker which compromised the session key could fabricate his own +AS-REP messages with a pre-recorded pre-authenticator until the +client starts using a new Diffie-Hellman key pair and while the KDC +pre-authenticator has not yet expired. It is therefore not +recommended for KDC clients to also cache their Diffie-Hellman keys. +Care should be taken in how certificates are chosen for the purposes +of authentication using PKINIT. Some local policies may require +that key escrow be used for certain certificate types. Deployers of +PKINIT should be aware of the implications of using certificates that +have escrowed keys for the purposes of authentication. +PKINIT does not provide for a "return routability" test to prevent +attackers from mounting a denial-of-service attack on the KDC by +causing it to perform unnecessary and expensive public-key +operations. Strictly speaking, this is also true of standard +Kerberos, although the potential cost is not as great, because +standard Kerberos does not make use of public-key cryptography. -Tung, et al. Expires June 6, 2005 [Page 19] - -Internet-Draft PKINIT December 2004 - - - PKINIT does not provide for a "return routability" test to prevent - attackers from mounting a denial-of-service attack on the KDC by - causing it to perform unnecessary and expensive public-key - operations. Strictly speaking, this is also true of standard - Kerberos, although the potential cost is not as great, because - standard Kerberos does not make use of public-key cryptography. - - The syntax for the AD-INITIAL-VERIFIED-CAS authorization data does - permit empty SEQUENCEs to be encoded. Such empty sequences may only - be used if the KDC itself vouches for the user's certificate. [This - seems to reflect the consensus of the Kerberos working group.] - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Tung, et al. Expires June 6, 2005 [Page 20] - -Internet-Draft PKINIT December 2004 +The syntax for the AD-INITIAL-VERIFIED-CAS authorization data does +permit empty SEQUENCEs to be encoded. Such empty sequences may only +be used if the KDC itself vouches for the user's certificate. [This +seems to reflect the consensus of the Kerberos working group.] 5. Acknowledgements - The following people have made significant contributions to this - draft: Paul Leach, Sam Hartman, Love Hornquist Astrand, Ken Raeburn, - Nicolas Williams, John Wray, Jonathan Trostle, Tom Yu and Jeff - Hutzelman. +The following people have made significant contributions to this +draft: Ari Medvinsky, Matt Hur, John Wray, Jonathan Trostle, Nicolas +Williams, Tom Yu, Sam Hartman, and Jeff Hutzelman. - Some of the ideas on which this document is based arose during - discussions over several years between members of the SAAG, the IETF - CAT working group, and the PSRG, regarding integration of Kerberos - and SPX. Some ideas have also been drawn from the DASS system. - These changes are by no means endorsed by these groups. This is an - attempt to revive some of the goals of those groups, and this - document approaches those goals primarily from the Kerberos - perspective. Lastly, comments from groups working on similar ideas - in DCE have been invaluable. +Some of the ideas on which this document is based arose during +discussions over several years between members of the SAAG, the IETF +CAT working group, and the PSRG, regarding integration of Kerberos +and SPX. Some ideas have also been drawn from the DASS system. +These changes are by no means endorsed by these groups. This is an +attempt to revive some of the goals of those groups, and this +document approaches those goals primarily from the Kerberos +perspective. Lastly, comments from groups working on similar ideas +in DCE have been invaluable. +6. Expiration Date +This draft expires May 15, 2005. +7. Bibliography +[1] RFC-Editor: To be replaced by RFC number for +draft-ietf-krb-wg-kerberos-clarifications. +[2] R. Housley. Cryptographic Message Syntax. August 2002. Request +For Comments 3369. +[3] W. Polk, R. Housley, and L. Bassham. Algorithms and Identifiers +for the Internet X.509 Public Key Infrastructure Certificate and +Certificate Revocation List (CRL) Profile, April 2002. Request For +Comments 3279. +[4] R. Housley, W. Polk, W. Ford, D. Solo. Internet X.509 Public +Key Infrastructure Certificate and Certificate Revocation List +(CRL) Profile, April 2002. Request for Comments 3280. +[5] B. Kaliski, J. Staddon. PKCS #1: RSA Cryptography +Specifications, October 1998. Request for Comments 2437. +[6] RFC-Editor: To be replaced by RFC number for +draft-ietf-krb-wg-crypto. +[7] S. Blake-Wilson, M. Nystrom, D. Hopwood, J. Mikkelsen, and +T. Wright. Transport Layer Security (TLS) Extensions, June 2003. +Request for Comments 3546. +[8] J. Schaad. Use of the Advanced Encryption Standard (AES) +Encryption Algorithm in Cryptographic Message Syntax (CMS). July +2003. Request for Comments 3565. +[9] NIST, Guidelines for Implementing and Using the NBS Encryption +Standard, April 1981. FIPS PUB 74. +[10] D. Harkins and D. Carrel. The Internet Key Exchange (IKE), +November 1998. Request for Comments 2409. +[11] K. Raeburn. Unkeyed SHA-1 Checksum Specification for Kerberos +5. Internet-Draft, draft-ietf-krb-wg-sha1-00.txt. +[12] S. Bradner. Key Words for Use in RFCs to Indicate Requirement +Levels. March 1997. Request for Comments 2119 (BCP 14). +[13] T. Kivinen, M. Kojo. More Modular Exponential (MODP) Diffie- +Hellman Groups for Internet Key Exchange (IKE). May 2003. Request +for Comments 3526. +[14] R. Housley. Cryptographic Message Syntax (CMS) Algorithms. +August 2002. Request For Comments 3370. +8. Authors +Brian Tung +Clifford Neuman +USC Information Sciences Institute +4676 Admiralty Way Suite 1001 +Marina del Rey CA 90292-6695 +Phone: +1 310 822 1511 +E-mail: {brian,bcn}@isi.edu - - - - - - - - - - - - -Tung, et al. Expires June 6, 2005 [Page 21] - -Internet-Draft PKINIT December 2004 - - -6. IANA Considerations - - This document has no actions for IANA. - -7 Normative References - - [CLAR] Neuman, B., Yu, Y., Hartman, S. and K. Raeburn, "The - Kerberos Network Authentication Service (V5)", - draft-ietf-krb-wg-kerberos-clarifications, work in - progress. - - [FIPS74] NIST, Guidelines for Implementing and Using - the NBS Encryption Standard, April 1981. FIPS PUB 74. - - [KCRYPTO] Raeburn, K., "Encryption and Checksum Specifications for - Kerberos 5", December 2004. - - [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate - Requirement Levels", BCP 14, RFC 2119, March 1997. - - [RFC2409] Harkins, D. and D. Carrel, "The Internet Key Exchange - (IKE)", RFC 2409, November 1998. - - [RFC2437] Kaliski, B. and J. Staddon, "PKCS #1: RSA Cryptography - Specifications Version 2.0", RFC 2437, October 1998. - - [RFC2630] Housley, R., "Cryptographic Message Syntax", RFC 2630, - June 1999. - - [RFC3279] Bassham, L., Polk, W. and R. Housley, "Algorithms and - Identifiers for the Internet X.509 Public Key - Infrastructure Certificate and Certificate Revocation List - (CRL) Profile", RFC 3279, April 2002. - - [RFC3280] Housley, R., Polk, W., Ford, W. and D. Solo, "Internet - X.509 Public Key Infrastructure Certificate and - Certificate Revocation List (CRL) Profile", RFC 3280, - April 2002. - - [X690] ASN.1 encoding rules: Specification of Basic - Encoding Rules (BER), Canonical Encoding Rules (CER) and - Distinguished Encoding Rules (DER), ITU-T Recommendation - X.690 (1997) | ISO/IEC International Standard - 8825-1:1998. - - - - - - - -Tung, et al. Expires June 6, 2005 [Page 22] - -Internet-Draft PKINIT December 2004 - - -Authors' Addresses - - Brian Tung - USC Information Sciences Institute - 4676 Admiralty Way Suite 1001, Marina del Rey CA - Marina del Rey, CA 90292 - US - - EMail: brian@isi.edu - - - Clifford Neuman - USC Information Sciences Institute - 4676 Admiralty Way Suite 1001, Marina del Rey CA - Marina del Rey, CA 90292 - US - - EMail: brian@isi.edu - - - Larry Zhu - Microsoft Corporation - One Microsoft Way - Redmond, WA 98052 - US - - EMail: lzhu@microsoft.com - - - Matt Hur - Microsoft Corporation - One Microsoft Way - Redmond, WA 98052 - US - - EMail: matthur@microsoft.com - - - Sasha Medvinsky - Motorola, Inc. - 6450 Sequence Drive - San Diego, CA 92121 - US - - EMail: smedvinsky@motorola.com - - - - - - -Tung, et al. Expires June 6, 2005 [Page 23] - -Internet-Draft PKINIT December 2004 +Sasha Medvinsky +Motorola, Inc. +6450 Sequence Drive +San Diego, CA 92121 ++1 858 404 2367 +E-mail: smedvinsky@motorola.com Appendix A. PKINIT ASN.1 Module - KerberosV5-PK-INIT-SPEC { - iso(1) identified-organization(3) dod(6) internet(1) - security(5) kerberosV5(2) modules(4) pkinit(3) - } DEFINITIONS EXPLICIT TAGS ::= BEGIN - - - IMPORTS - SubjectPublicKeyInfo, AlgorithmIdentifier, Name - FROM PKIX1Explicit88 { iso (1) - identified-organization (3) dod (6) internet (1) - security (5) mechanisms (5) pkix (7) id-mod (0) - id-pkix1-explicit (18) } - - - ContentInfo, IssuerAndSerialNumber - FROM CryptographicMessageSyntax { iso(1) member-body(2) - us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) - modules(0) cms(1) } - - - KerberosTime, TYPED-DATA, PrincipalName, Realm, EncryptionKey - FROM KerberosV5Spec2 { iso(1) identified-organization(3) - dod(6) internet(1) security(5) kerberosV5(2) - modules(4) krb5spec2(2) } ; - - - id-pkinit OBJECT IDENTIFIER ::= - { iso (1) org (3) dod (6) internet (1) security (5) - kerberosv5 (2) pkinit (3) } - - id-pkdhkeydata OBJECT IDENTIFIER ::= { id-pkinit 1 } - id-pkdhkeydata OBJECT IDENTIFIER ::= { id-pkinit 2 } - id-pkrkeydata OBJECT IDENTIFIER ::= { id-pkinit 3 } - id-pkekuoid OBJECT IDENTIFIER ::= { id-pkinit 4 } - id-pkkdcekuoid OBJECT IDENTIFIER ::= { id-pkinit 5 } - - - pa-pk-as-req INTEGER ::= 16 - pa-pk-as-rep INTEGER ::= 17 - - ad-initial-verified-cas INTEGER ::= 9 - - - td-trusted-certifiers INTEGER ::= 104 - td-certificate-index INTEGER ::= 105 - td-dh-parameters INTEGER ::= 109 - - - -Tung, et al. Expires June 6, 2005 [Page 24] - -Internet-Draft PKINIT December 2004 - - - WrapContentInfo ::= OCTET STRING (CONSTRAINED BY { - -- Contains a BER encoding of ContentInfo. - }) - - - WrapIssuerAndSerial ::= OCTET STRING (CONSTRAINED BY { - -- Contains a BER encoding of IssuerAndSerialNumber. - }) - - - PA-PK-AS-REQ ::= SEQUENCE { - signedAuthPack [0] IMPLICIT WrapContentInfo, - -- Type is SignedData. - -- Content is AuthPack - -- (defined below). - trustedCertifiers [1] SEQUENCE OF TrustedCA OPTIONAL, - -- A list of CAs, trusted by - -- the client, used to certify - -- KDCs. - kdcCert [2] IMPLICIT WrapIssuerAndSerial - OPTIONAL, - -- Identifies a particular KDC - -- certificate, if the client - -- already has it. - clientDHNonce [3] DHNonce OPTIONAL, - ... - } - - - TrustedCA ::= CHOICE { - caName [1] Name, - -- Fully qualified X.500 name - -- as defined in [RFC3280]. - issuerAndSerial [2] IMPLICIT WrapIssuerAndSerial, - -- Identifies a specific CA - -- certificate. - ... - } - - - AuthPack ::= SEQUENCE { - pkAuthenticator [0] PKAuthenticator, - clientPublicValue [1] SubjectPublicKeyInfo OPTIONAL, - -- Defined in [RFC3280]. - -- Present only if the client - -- is using ephemeral-ephemeral - -- Diffie-Hellman. - supportedCMSTypes [2] SEQUENCE OF AlgorithmIdentifier - - - -Tung, et al. Expires June 6, 2005 [Page 25] - -Internet-Draft PKINIT December 2004 - - - OPTIONAL, - -- List of CMS encryption types - -- supported by client in order - -- of (decreasing) preference. - ... - } - - - PKAuthenticator ::= SEQUENCE { - cusec [0] INTEGER (0..999999), - ctime [1] KerberosTime, - -- cusec and ctime are used as - -- in [CLAR], for replay - -- prevention. - nonce [2] INTEGER (0..4294967295), - paChecksum [3] OCTET STRING, - -- Contains the SHA1 checksum, - -- performed over KDC-REQ-BODY. - ... - } - - - TrustedCertifiers ::= SEQUENCE OF Name - - - CertificateIndex ::= IssuerAndSerialNumber - - - KRB5PrincipalName ::= SEQUENCE { - realm [0] Realm, - principalName [1] PrincipalName - } - - - InitialVerifiedCAs ::= SEQUENCE OF SEQUENCE { - ca [0] Name, - Validated [1] BOOLEAN, - ... - } - - - PA-PK-AS-REP ::= CHOICE { - dhInfo [0] DHRepInfo, - encKeyPack [1] IMPLICIT WrapContentInfo, - -- Type is EnvelopedData. - -- Content is SignedData over - -- ReplyKeyPack (defined below). - ... - - - -Tung, et al. Expires June 6, 2005 [Page 26] - -Internet-Draft PKINIT December 2004 - - - } - - DHRepInfo ::= SEQUENCE { - dhSignedData [0] ContentInfo, - -- Type is SignedData. - -- Content is KDCDHKeyInfo - -- (defined below). - serverDHNonce [1] DHNonce OPTIONAL - } - - KDCDHKeyInfo ::= SEQUENCE { - subjectPublicKey [0] BIT STRING, - -- Equals public exponent - -- (g^a mod p). - -- INTEGER encoded as payload - -- of BIT STRING. - nonce [1] INTEGER (0..4294967295), - dhKeyExpiration [2] KerberosTime OPTIONAL, - -- Expiration time for KDC's - -- cached values. If this field - -- is omitted then the - -- serverDHNonce field MUST also - -- be omitted. - ... - } - - - ReplyKeyPack ::= SEQUENCE { - replyKey [0] EncryptionKey, - -- Defined in [CLAR]. - -- Used to encrypt main reply. - -- MUST be at least as strong - -- as session key. (Using the - -- same enctype and a strong - -- prng should suffice, if no - -- stronger encryption system - -- is available.) - nonce [1] INTEGER (0..4294967295), - -- Contains the nonce in - -- the KDCDHKeyInfo. - ... - } - - - END - - - - - - -Tung, et al. Expires June 6, 2005 [Page 27] - -Internet-Draft PKINIT December 2004 - - -Intellectual Property Statement - - The IETF takes no position regarding the validity or scope of any - Intellectual Property Rights or other rights that might be claimed to - pertain to the implementation or use of the technology described in - this document or the extent to which any license under such rights - might or might not be available; nor does it represent that it has - made any independent effort to identify any such rights. Information - on the procedures with respect to rights in RFC documents can be - found in BCP 78 and BCP 79. - - Copies of IPR disclosures made to the IETF Secretariat and any - assurances of licenses to be made available, or the result of an - attempt made to obtain a general license or permission for the use of - such proprietary rights by implementers or users of this - specification can be obtained from the IETF on-line IPR repository at - http://www.ietf.org/ipr. - - The IETF invites any interested party to bring to its attention any - copyrights, patents or patent applications, or other proprietary - rights that may cover technology that may be required to implement - this standard. Please address the information to the IETF at - ietf-ipr@ietf.org. - - -Disclaimer of Validity - - This document and the information contained herein are provided on an - "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS - OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET - ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, - INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE - INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED - WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. - - -Copyright Statement - - Copyright (C) The Internet Society (2004). This document is subject - to the rights, licenses and restrictions contained in BCP 78, and - except as set forth therein, the authors retain all their rights. - - -Acknowledgment - - Funding for the RFC Editor function is currently provided by the - Internet Society. - - - - -Tung, et al. Expires June 6, 2005 [Page 28] - - +KerberosV5-PK-INIT-SPEC { + iso(1) identified-organization(3) dod(6) internet(1) + security(5) kerberosV5(2) modules(4) pkinit(TBD) +} DEFINITIONS EXPLICIT TAGS ::= BEGIN + + IMPORTS + SubjectPublicKeyInfo, AlgorithmIdentifier, Name + FROM PKIX1Explicit88 { iso (1) identified-organization (3) + dod (6) internet (1) security (5) mechanisms (5) + pkix (7) id-mod (0) id-pkix1-explicit (18) } + + ContentInfo, IssuerAndSerialNumber + FROM CryptographicMessageSyntax { iso(1) member-body(2) + us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) + modules(0) cms(1) } + + KerberosTime, Checksum, TYPED-DATA, PrincipalName, Realm, EncryptionKey + FROM KerberosV5Spec2 { iso(1) identified-organization(3) + dod(6) internet(1) security(5) kerberosV5(2) modules(4) + krb5spec2(2) } ; + + id-pkinit OBJECT IDENTIFIER ::= + { iso (1) org (3) dod (6) internet (1) security (5) + kerberosv5 (2) pkinit (3) } + + id-pkdhkeydata OBJECT IDENTIFIER ::= { id-pkinit 1 } + id-pkdhkeydata OBJECT IDENTIFIER ::= { id-pkinit 2 } + id-pkrkeydata OBJECT IDENTIFIER ::= { id-pkinit 3 } + id-pkekuoid OBJECT IDENTIFIER ::= { id-pkinit 4 } + id-pkkdcekuoid OBJECT IDENTIFIER ::= { id-pkinit 5 } + + pa-pk-as-req INTEGER ::= TBD + pa-pk-as-rep INTEGER ::= TBD + pa-pk-ocsp-req INTEGER ::= TBD + pa-pk-ocsp-rep INTEGER ::= TBD + + ad-initial-verified-cas INTEGER ::= TBD + + td-dh-parameters INTEGER ::= TBD + td-trusted-certifiers INTEGER ::= 104 + td-certificate-index INTEGER ::= 105 + + WrapContentInfo ::= OCTET STRING (CONSTRAINED BY { + -- Contains a BER encoding of + -- ContentInfo + }) + + WrapIssuerAndSerial ::= OCTET STRING (CONSTRAINED BY { + -- Contains a BER encoding of + -- IssuerAndSerialNumber + }) + + PA-PK-AS-REQ ::= SEQUENCE { + signedAuthPack [0] IMPLICIT WrapContentInfo, + trustedCertifiers [1] SEQUENCE OF TrustedCA OPTIONAL, + kdcCert [2] IMPLICIT WrapIssuerAndSerial + OPTIONAL, + ... + } + + TrustedCA ::= CHOICE { + caName [1] Name, + issuerAndSerial [2] IMPLICIT WrapIssuerAndSerial, + ... + } + + AuthPack ::= SEQUENCE { + pkAuthenticator [0] PKAuthenticator, + clientPublicValue [1] SubjectPublicKeyInfo OPTIONAL, + supportedCMSTypes [2] SEQUENCE OF AlgorithmIdentifier + OPTIONAL, + ... + } + + PKAuthenticator ::= SEQUENCE { + cusec [0] INTEGER (0..999999), + ctime [1] KerberosTime, + nonce [2] INTEGER (0..4294967295), + paChecksum [3] OCTET STRING OPTIONAL, + ... + } + + KDCTrustedCertifiers ::= SEQUENCE OF Name + + CertificateIndex ::= IssuerAndSerialNumber + + KRB5PrincipalName ::= SEQUENCE { + realm [0] Realm, + principalName [1] PrincipalName + } + + InitialVerifiedCAs ::= SEQUENCE OF SEQUENCE { + ca [0] Name, + validated [1] BOOLEAN, + ... + } + + PA-PK-AS-REP ::= CHOICE { + dhSignedData [0] IMPLICIT WrapContentInfo, + encKeyPack [1] IMPLICIT WrapContentInfo, + ... + } + + KDCDHKeyInfo ::= SEQUENCE { + subjectPublicKey [0] BIT STRING, + nonce [1] INTEGER (0..4294967295), + dhKeyExpiration [2] KerberosTime OPTIONAL, + ... + } + + ReplyKeyPack ::= SEQUENCE { + replyKey [0] EncryptionKey, + nonce [1] INTEGER (0..4294967295), + ... + } + +END + +Copyright (C) The Internet Society 2004. This document is subject +to the rights, licenses and restrictions contained in BCP 78, and +except as set forth therein, the authors retain all their rights. + +This document and the information contained herein are provided on +an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE +REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE +INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR +IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF +THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED +WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. diff --git a/doc/standardisation/draft-ietf-cat-kerberos-pk-init-23.txt b/doc/standardisation/draft-ietf-cat-kerberos-pk-init-23.txt index e7928ae0c..f0cd9cac4 100644 --- a/doc/standardisation/draft-ietf-cat-kerberos-pk-init-23.txt +++ b/doc/standardisation/draft-ietf-cat-kerberos-pk-init-23.txt @@ -1,5 +1,6 @@ + NETWORK WORKING GROUP B. Tung Internet-Draft USC Information Sciences Institute Expires: August 4, 2005 L. Zhu @@ -8,7 +9,7 @@ Expires: August 4, 2005 L. Zhu Public Key Cryptography for Initial Authentication in Kerberos - draft-ietf-cat-kerberos-pk-init-23 + draft-ietf-cat-kerberos-pk-init Status of this Memo diff --git a/doc/standardisation/draft-ietf-cat-kerberos-pk-init-24.txt b/doc/standardisation/draft-ietf-cat-kerberos-pk-init-24.txt index f91300336..2aed744ce 100644 --- a/doc/standardisation/draft-ietf-cat-kerberos-pk-init-24.txt +++ b/doc/standardisation/draft-ietf-cat-kerberos-pk-init-24.txt @@ -1,13 +1,15 @@ + + NETWORK WORKING GROUP B. Tung Internet-Draft USC Information Sciences Institute -Expires: August 13, 2005 L. Zhu +Expires: August 11, 2005 L. Zhu Microsoft Corporation - February 9, 2005 + February 7, 2005 Public Key Cryptography for Initial Authentication in Kerberos - draft-ietf-cat-kerberos-pk-init-24 + draft-ietf-cat-kerberos-pk-init Status of this Memo @@ -34,7 +36,7 @@ Status of this Memo The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. - This Internet-Draft will expire on August 13, 2005. + This Internet-Draft will expire on August 11, 2005. Copyright Notice @@ -50,7 +52,7 @@ Abstract -Tung & Zhu Expires August 13, 2005 [Page 1] +Tung & Zhu Expires August 11, 2005 [Page 1] Internet-Draft PKINIT February 2005 @@ -68,18 +70,17 @@ Table of Contents 3.2.1 Generation of Client Request . . . . . . . . . . . . . 6 3.2.2 Receipt of Client Request . . . . . . . . . . . . . . 10 3.2.3 Generation of KDC Reply . . . . . . . . . . . . . . . 13 - 3.2.4 Receipt of KDC Reply . . . . . . . . . . . . . . . . . 19 - 3.3 Interoperability Requirements . . . . . . . . . . . . . . 20 - 3.4 KDC Indication of PKINIT Support . . . . . . . . . . . . . 20 - 4. Security Considerations . . . . . . . . . . . . . . . . . . . 21 - 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 22 + 3.2.4 Receipt of KDC Reply . . . . . . . . . . . . . . . . . 18 + 3.3 KDC Indication of PKINIT Support . . . . . . . . . . . . . 20 + 4. Security Considerations . . . . . . . . . . . . . . . . . . . 20 + 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 21 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22 - 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 23 - 7.1 Normative References . . . . . . . . . . . . . . . . . . . 23 - 7.2 Informative References . . . . . . . . . . . . . . . . . . 24 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 24 - A. PKINIT ASN.1 Module . . . . . . . . . . . . . . . . . . . . . 25 - Intellectual Property and Copyright Statements . . . . . . . . 30 + 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 22 + 7.1 Normative References . . . . . . . . . . . . . . . . . . . 22 + 7.2 Informative References . . . . . . . . . . . . . . . . . . 23 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 23 + A. PKINIT ASN.1 Module . . . . . . . . . . . . . . . . . . . . . 24 + Intellectual Property and Copyright Statements . . . . . . . . 29 @@ -106,7 +107,8 @@ Table of Contents -Tung & Zhu Expires August 13, 2005 [Page 2] + +Tung & Zhu Expires August 11, 2005 [Page 2] Internet-Draft PKINIT February 2005 @@ -119,8 +121,8 @@ Internet-Draft PKINIT February 2005 authentication server (AS). Then, it uses the TGT to request a service ticket from the Kerberos ticket-granting server (TGS). Usually, the AS and TGS are integrated in a single device known as a - Kerberos Key Distribution Center, or KDC. (In this document, both - the AS and the TGS are referred to as the KDC.) Finally, the client + Kerberos Key Distribution Center, or KDC. (In this document, we will + refer to both the AS and the TGS as the KDC.) Finally, the client uses the service ticket to authenticate itself to the service. The advantage afforded by the TGT is that the client exposes his @@ -156,13 +158,13 @@ Internet-Draft PKINIT February 2005 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. - In this document, the encryption key used to encrypt the enc-part - field of the KDC-REP in the AS-REP [CLAR] is referred to as the KDC - AS reply key. -Tung & Zhu Expires August 13, 2005 [Page 3] + + + +Tung & Zhu Expires August 11, 2005 [Page 3] Internet-Draft PKINIT February 2005 @@ -209,7 +211,7 @@ Internet-Draft PKINIT February 2005 All PKINIT implementations MUST support the following algorithms: - o KDC AS reply key enctype: AES256-CTS-HMAC-SHA1-96 etype [KCRYPTO]. + o AS reply key: AES256-CTS-HMAC-SHA1-96 etype [KCRYPTO]. o Signature algorithm: sha-1WithRSAEncryption [RFC3279]. @@ -218,7 +220,7 @@ Internet-Draft PKINIT February 2005 -Tung & Zhu Expires August 13, 2005 [Page 4] +Tung & Zhu Expires August 11, 2005 [Page 4] @@ -226,12 +228,12 @@ Tung & Zhu Expires August 13, 2005 [Page 4] PKINIT makes use of the following new pre-authentication types: - PA_PK_AS_REQ 16 - PA_PK_AS_REP 17 + PA_PK_AS_REQ 16 + PA_PK_AS_REP 17 PKINIT also makes use of the following new authorization data type: - AD_INITIAL_VERIFIED_CAS 9 + AD_INITIAL_VERIFIED_CAS 9 PKINIT introduces the following new error codes: @@ -247,22 +249,22 @@ Tung & Zhu Expires August 13, 2005 [Page 4] PKINIT uses the following typed data types for errors: - TD_TRUSTED_CERTIFIERS 104 - TD_INVLID_CERTIFICATES 105 - TD_DH_PARAMETERS 109 + TD_TRUSTED_CERTIFIERS 104 + TD_INVLID_CERTIFICATES 105 + TD_DH_PARAMETERS 109 PKINIT defines the following encryption types, for use in the AS-REQ message to indicate acceptance of the corresponding algorithms that can used by Cryptographic Message Syntax (CMS) [RFC3852] messages in the reply: - dsaWithSHA1-CmsOID 9 - md5WithRSAEncryption-CmsOID 10 - sha1WithRSAEncryption-CmsOID 11 - rc2CBC-EnvOID 12 - rsaEncryption-EnvOID (PKCS1 v1.5) 13 - rsaES-OAEP-EnvOID (PKCS1 v2.0) 14 - des-ede3-cbc-EnvOID 15 + dsaWithSHA1-CmsOID 9 + md5WithRSAEncryption-CmsOID 10 + sha1WithRSAEncryption-CmsOID 11 + rc2CBC-EnvOID 12 + rsaEncryption-EnvOID (PKCS1 v1.5) 13 + rsaES-OAEP-EnvOID (PKCS1 v2.0) 14 + des-ede3-cbc-EnvOID 15 The ASN.1 module for all structures defined in this document (plus IMPORT statements for all imported structures) is given in @@ -274,7 +276,7 @@ Tung & Zhu Expires August 13, 2005 [Page 4] -Tung & Zhu Expires August 13, 2005 [Page 5] +Tung & Zhu Expires August 11, 2005 [Page 5] Internet-Draft PKINIT February 2005 @@ -296,8 +298,8 @@ Internet-Draft PKINIT February 2005 PKINIT uses the following algorithm identifiers for Diffie-Hellman key agreement [RFC3279]: - dhpublicnumber (Diffie-Hellman modulo a prime p [RFC2631]) - id-ecPublicKey (Elliptic Curve Diffie-Hellman [IEEE1363]) + dhpublicnumber (Diffie-Hellman modulo a prime p [RFC2631]) + id-ecPublicKey (Elliptic Curve Diffie-Hellman [IEEE1363]) PKINIT uses the following signature algorithm identifiers [RFC3279]: @@ -312,7 +314,7 @@ Internet-Draft PKINIT February 2005 id-RSAES-OAEP (PKCS1 v2.0) PKINIT uses the following algorithm identifiers [RFC3370][RFC3565] - for encrypting the KDC AS reply key with the temporary key: + for encrypting the reply key with the temporary key: des-ede3-cbc (three-key 3DES, CBC mode) rc2-cbc (RC2, CBC mode) @@ -330,7 +332,7 @@ Internet-Draft PKINIT February 2005 -Tung & Zhu Expires August 13, 2005 [Page 6] +Tung & Zhu Expires August 11, 2005 [Page 6] Internet-Draft PKINIT February 2005 @@ -368,37 +370,29 @@ Internet-Draft PKINIT February 2005 DHNonce ::= OCTET STRING - TrustedCA ::= SEQUENCE { - caName [0] IMPLICIT OCTET STRING, + TrustedCA ::= CHOICE { + caName [1] IMPLICIT OCTET STRING, -- Contains a PKIX type Name encoded according to -- [RFC3280]. - -- Specifies the CA distinguished subject name. - certificateSerialNumber [1] INTEGER OPTIONAL, - -- Specifies the certificate serial number. - -- The defintion of the certificate serial number - -- is taken from X.509 [X.509-97]. - subjectKeyIdentifier [2] OCTET STRING OPTIONAL, - -- Identifies the CA's public key by a key - -- identifier. When an X.509 certificate is - -- referenced, this key identifier matches the X.509 - -- subjectKeyIdentifier extension value. When other - -- certificate formats are referenced, the documents - - - -Tung & Zhu Expires August 13, 2005 [Page 7] - -Internet-Draft PKINIT February 2005 - - - -- that specify the certificate format and their use - -- with the CMS must include details on matching the - -- key identifier to the appropriate certificate - -- field. + -- Identifies a CA. + -- Prefer the sid field below if that is available. + sid [2] IMPLICIT OCTET STRING, + -- Contains a CMS type SignerIdentifier encoded + -- according to [RFC3852]. + -- Identifies the trusted CA's certificate (and + -- thereby the public key). ... } AuthPack ::= SEQUENCE { + + + +Tung & Zhu Expires August 11, 2005 [Page 7] + +Internet-Draft PKINIT February 2005 + + pkAuthenticator [0] PKAuthenticator, clientPublicValue [1] SubjectPublicKeyInfo OPTIONAL, -- Defined in [RFC3280]. @@ -439,14 +433,6 @@ Internet-Draft PKINIT February 2005 (as defined in [RFC3852]), and the content field is a SignedData (as defined in [RFC3852]). - - - -Tung & Zhu Expires August 13, 2005 [Page 8] - -Internet-Draft PKINIT February 2005 - - 2. The eContentType field for the type SignedData is id-pkauthdata: { iso(1) org(3) dod(6) internet(1) security(5) kerberosv5(2) pkinit(3) pkauthdata(1) }. @@ -454,6 +440,15 @@ Internet-Draft PKINIT February 2005 3. The eContent field for the type SignedData contains the DER encoding of the type AuthPack. + + + + +Tung & Zhu Expires August 11, 2005 [Page 8] + +Internet-Draft PKINIT February 2005 + + 4. The signerInfos field of the type SignedData contains a single signerInfo, which contains the signature over the type AuthPack. @@ -463,8 +458,12 @@ Internet-Draft PKINIT February 2005 type AuthPack. For path validation, these certificates SHOULD be sufficient to construct at least one certification path from the client certificate to one trust anchor acceptable by the KDC - [CAPATH]. The certificates field MUST NOT contain "root" CA - certificates. + [CAPATH]. If the client sends all the X.509 certificates on a + certification path to a trust anchor acceptable by the KDC and + the KDC can not verify the client's public key otherwise, the KDC + MUST process path validation for the client's X.509 certificate + based on the certificates in the request. The certificates field + MUST NOT contain "root" CA certificates. 6. The client's Diffie-Hellman public value (clientPublicValue) is included if and only if the client wishes to use the @@ -494,19 +493,18 @@ Internet-Draft PKINIT February 2005 have at least twice as many bits as the symmetric keys that will be derived from them [ODL99]. - - - - -Tung & Zhu Expires August 13, 2005 [Page 9] - -Internet-Draft PKINIT February 2005 - - 7. The client may wish to reuse DH keys or to allow the KDC to do so (see Section 3.2.3.1). If so, then the client includes the clientDHNonce field. This nonce string needs to be as long as the longest key length of the symmetric key types that the client + + + +Tung & Zhu Expires August 11, 2005 [Page 9] + +Internet-Draft PKINIT February 2005 + + supports. This nonce MUST be chosen randomly. @@ -551,18 +549,18 @@ Internet-Draft PKINIT February 2005 -- IssuerAndSerialNumber encoded according to -- [RFC3852]. -- Each IssuerAndSerialNumber indentifies a - - - -Tung & Zhu Expires August 13, 2005 [Page 10] - -Internet-Draft PKINIT February 2005 - - -- certificate (sent by the client) with an invalid -- signature. If more than one X.509 certificate signature is invalid, the KDC MAY + + + +Tung & Zhu Expires August 11, 2005 [Page 10] + +Internet-Draft PKINIT February 2005 + + send one TYPED-DATA element per invalid signature. Based on local policy, the KDC may also check whether any X.509 @@ -606,20 +604,19 @@ Internet-Draft PKINIT February 2005 The value field of the type AnotherName is the DER encoding of the following ASN.1 type: - - - - -Tung & Zhu Expires August 13, 2005 [Page 11] - -Internet-Draft PKINIT February 2005 - - KRB5PrincipalName ::= SEQUENCE { realm [0] Realm, principalName [1] PrincipalName } + + + +Tung & Zhu Expires August 11, 2005 [Page 11] + +Internet-Draft PKINIT February 2005 + + If the KDC does not have its own binding and there is no KRB5PrincipalName name present in the client's X.509 certificate, and if the Kerberos name in the request does not match the @@ -663,19 +660,19 @@ Internet-Draft PKINIT February 2005 wishes to use the Diffie-Hellman key agreement method, the KDC SHOULD check to see if the key parameters satisfy its policy. If they do not, it MUST return an error message with the code - - - -Tung & Zhu Expires August 13, 2005 [Page 12] - -Internet-Draft PKINIT February 2005 - - KDC_ERR_DH_KEY_PARAMETERS_NOT_ACCEPTED. The accompanying e-data is a TYPED-DATA that contains an element whose data-type is TD_DH_PARAMETERS, and whose data-value contains the DER encoding of the type TD-DH-PARAMETERS: + + + +Tung & Zhu Expires August 11, 2005 [Page 12] + +Internet-Draft PKINIT February 2005 + + TD-DH-PARAMETERS ::= SEQUENCE OF DHDomainParameters -- Contains a list of Diffie-Hellman domain -- parameters in decreasing preference order. @@ -693,13 +690,13 @@ Internet-Draft PKINIT February 2005 client SHOULD pick one to retry the request. If the client included a kdcPkId field in the PA-PK-AS-REQ and the - KDC does not possess the corresponding key, the KDC MUST ignore the + KDC does not have the corresponding key, the KDC MUST ignore the kdcPkId field as if the client did not include one. If the client included a trustedCertifiers field, and the KDC does not possesses the private key for any one of the listed certifiers, the KDC MUST ignore the trustedCertifiers field as if the client did - not include any. + not include one. If there is a supportedCMSTypes field in the AuthPack, the KDC must check to see if it supports any of the listed types. If it supports @@ -717,39 +714,26 @@ Internet-Draft PKINIT February 2005 ticket. The ad-data [CLAR] field contains the DER encoding of the type AD-INITIAL-VERIFIED-CAS: - - - - - -Tung & Zhu Expires August 13, 2005 [Page 13] - -Internet-Draft PKINIT February 2005 - - AD-INITIAL-VERIFIED-CAS ::= SEQUENCE OF TrustedCA -- Identifies the certification path based on which -- the client certificate was validated. -- Each TrustedCA identifies a CA or a CA -- certificate (thereby its public key). - The AS wraps any AD-INITIAL-VERIFIED-CAS data in AD-IF-RELEVANT - containers if the list of CAs satisfies the AS' realm's local policy - (this corresponds to the TRANSITED-POLICY-CHECKED ticket flag - [CLAR]). Furthermore, any TGS MUST copy such authorization data from - tickets used in a PA-TGS-REQ [CLAR] of the TGS-REQ to the resulting - ticket, and it can wrap or unwrap the data into or out-of the - AD-IF-RELEVANT container, depends on if the list of CAs satisfies the - TGS' realm's local policy. + The KDC MUST wrap any AD-INITIAL-VERIFIED-CAS data in AD-IF-RELEVANT - Application servers that understand this authorization data type - SHOULD apply local policy to determine whether a given ticket bearing - such a type *not* contained within an AD-IF-RELEVANT container is - acceptable. (This corresponds to the AP server checking the - transited field when the TRANSITED-POLICY-CHECKED flag has not been - set [CLAR].) If such a data type is contained within an - AD-IF-RELEVANT container, AP servers MAY apply local policy to - determine whether the authorization data is acceptable. + + +Tung & Zhu Expires August 11, 2005 [Page 13] + +Internet-Draft PKINIT February 2005 + + + containers. Furthermore, any TGS MUST copy such authorization data + from tickets used in a PA-TGS-REQ [CLAR] of the TGS-REQ to the + resulting ticket. Upon receipt of a service ticket carrying the + AD-INITIAL-VERIFIED-CAS data, application servers MAY apply local + policy to determine whether the authorization data is acceptable. The content of the AS-REP is otherwise unchanged from [CLAR]. The KDC encrypts the reply as usual, but not with the client's long-term @@ -775,14 +759,6 @@ Internet-Draft PKINIT February 2005 -- (1.2.840.113549.1.7.3) and the eContent field -- contains the DER encoding of the type -- ReplyKeyPack. - - - -Tung & Zhu Expires August 13, 2005 [Page 14] - -Internet-Draft PKINIT February 2005 - - -- ReplyKeyPack is defined in Section 3.2.3.2. ... } @@ -801,6 +777,14 @@ Internet-Draft PKINIT February 2005 -- KDCDHKeyInfo is defined below. serverDHNonce [1] DHNonce OPTIONAL -- Present if and only if dhKeyExpiration is + + + +Tung & Zhu Expires August 11, 2005 [Page 14] + +Internet-Draft PKINIT February 2005 + + -- present in the KDCDHKeyInfo. } @@ -831,14 +815,6 @@ Internet-Draft PKINIT February 2005 1. The contentType field of the type ContentInfo is id-signedData (as defined in [RFC3852]), and the content field is a SignedData - - - -Tung & Zhu Expires August 13, 2005 [Page 15] - -Internet-Draft PKINIT February 2005 - - (as defined in [RFC3852]). 2. The eContentType field for the type SignedData is the OID value @@ -857,11 +833,24 @@ Internet-Draft PKINIT February 2005 construction, so that the client can verify the KDC's signature over the type KDCDHKeyInfo. This field may only be left empty if the KDC public key specified by the kdcPkId field in the + + + +Tung & Zhu Expires August 11, 2005 [Page 15] + +Internet-Draft PKINIT February 2005 + + PA-PK-AS-REQ was used for signing. Otherwise, for path validation, these certificates SHOULD be sufficient to construct at least one certification path from the KDC certificate to one - trust anchor acceptable by the client [CAPATH]. The certificates - field MUST NOT contain "root" CA certificates. + trust anchor acceptable by the client [CAPATH]. If the KDC sends + all the X.509 certificates on a certification path to a trust + anchor acceptable by the client and the client can not verify the + KDC's public key otherwise, the client MUST process path + validation for the KDC's X.509 certificate based on the + certificates in the reply. The certificates field MUST NOT + contain "root" CA certificates. 6. If the client included the clientDHNonce field, then the KDC may choose to reuse its DH keys (see Section 3.2.3.1). If the server @@ -876,7 +865,8 @@ Internet-Draft PKINIT February 2005 for details. The KDC SHOULD NOT reuse DH keys unless the clientDHNonce field is present in the request. - The KDC AS reply key is derived as follows: + The reply key for use to decrypt the KDC reply [CLAR] is derived as + follows: 1. Both the KDC and the client calculate the shared secret value as follows: @@ -884,17 +874,6 @@ Internet-Draft PKINIT February 2005 a) When Diffie-Hellman modulo a prime p ([RFC2631]) is used, let DHSharedSecret be the shared secret value. - - - - - - -Tung & Zhu Expires August 13, 2005 [Page 16] - -Internet-Draft PKINIT February 2005 - - b) When Elliptic Curve Diffie-Hellman (ECDH) (with each party contributing one key pair) [IEEE1363] is used, let DHSharedSecret be the x-coordinate of the shared secret value @@ -910,8 +889,16 @@ Internet-Draft PKINIT February 2005 key and yb is the KDC's public key. If both ya and yb are the same in a later exchange, the cached DHSharedSecret can be used. - 2. Let K be the key-generation seed length [KCRYPTO] of the KDC AS - reply key whose enctype is selected according to [CLAR]. + + + +Tung & Zhu Expires August 11, 2005 [Page 16] + +Internet-Draft PKINIT February 2005 + + + 2. Let K be the key-generation seed length [KCRYPTO] of the reply + key whose enctype is selected according to [CLAR]. 3. Define the function octetstring2key() as follows: @@ -927,13 +914,13 @@ Internet-Draft PKINIT February 2005 random-to-key() is an operation that generates a protocol key from a bitstring of length K; and K-truncate truncates its input to the first K bits. Both K and random-to-key() are as defined in the - kcrypto profile [KCRYPTO] for the enctype of the KDC AS reply key. + kcrypto profile [KCRYPTO] for the enctype of the reply key. 4. When DH keys are reused, let n_c be the clientDHNonce, and n_k be the serverDHNonce; otherwise, let both n_c and n_k be empty octet strings. - 5. The KDC AS reply key k is: + 5. The reply key k is: k = octetstring2key(DHSharedSecret | n_c | n_k) @@ -941,15 +928,9 @@ Internet-Draft PKINIT February 2005 3.2.3.2 Using Public Key Encryption In this case, the PA-PK-AS-REP contains a ContentInfo structure - wrapped in an OCTET STRING. The KDC AS reply key is encrypted in the - encKeyPack field, which contains data of type ReplyKeyPack: - - - -Tung & Zhu Expires August 13, 2005 [Page 17] - -Internet-Draft PKINIT February 2005 - + wrapped in an OCTET STRING. The reply key for use to decrypt the KDC + reply [CLAR] is encrypted in the encKeyPack field, which contains + data of type ReplyKeyPack: ReplyKeyPack ::= SEQUENCE { replyKey [0] EncryptionKey, @@ -964,6 +945,14 @@ Internet-Draft PKINIT February 2005 The ContentInfo [RFC3852] structure for the encKeyPack field is filled in as follows: + + + +Tung & Zhu Expires August 11, 2005 [Page 17] + +Internet-Draft PKINIT February 2005 + + 1. The contentType field of the type ContentInfo is id-envelopedData (as defined in [RFC3852]), and the content field is an EnvelopedData (as defined in [RFC3852]). @@ -992,19 +981,19 @@ Internet-Draft PKINIT February 2005 PA-PK-AS-REQ was used for signing. Otherwise, for path validation, these certificates SHOULD be sufficient to construct at least one certification path from the KDC certificate to one - trust anchor acceptable by the client [CAPATH]. The certificates - field MUST NOT contain "root" CA certificates. + trust anchor acceptable by the client [CAPATH]. If the KDC sends + all the X.509 certificates on a certification path to a trust + anchor acceptable by the client and the client can not verify the + KDC's public key otherwise, the client MUST process path + validation for the KDC's X.509 certificate based on the + certificates in the reply. The certificates field MUST NOT + contain "root" CA certificates. 7. The recipientInfos field of the type EnvelopedData is a SET which MUST contain exactly one member of type KeyTransRecipientInfo. The encryptedKey of this member contains the temporary key which is encrypted using the client's public key. - - -Tung & Zhu Expires August 13, 2005 [Page 18] - - 8. The unprotectedAttrs or originatorInfo fields of the type EnvelopedData MAY be present. @@ -1012,39 +1001,28 @@ Tung & Zhu Expires August 13, 2005 [Page 18] Upon receipt of the KDC's reply, the client proceeds as follows. If the PA-PK-AS-REP contains the dhSignedData field, the client derives - the KDC AS reply key using the same procedure used by the KDC as - defined in Section 3.2.3.1. Otherwise, the message contains the - encKeyPack field, and the client decrypts and extracts the temporary - key in the encryptedKey field of the member KeyTransRecipientInfo, - and then uses that as the KDC AS reply key. + + + +Tung & Zhu Expires August 11, 2005 [Page 18] + +Internet-Draft PKINIT February 2005 + + + the reply key using the same procedure used by the KDC as defined in + Section 3.2.3.1. Otherwise, the message contains the encKeyPack + field, and the client decrypts and extracts the temporary key in the + encryptedKey field of the member KeyTransRecipientInfo, and then uses + that as the reply key. In either case, the client MUST verify the signature in the SignedData according to [RFC3852]. Unless the client can otherwise prove that the public key used to verify the KDC's signature is bound - to the target KDC, the KDC's X.509 certificate MUST satisfy at least - one of the follow two requirements: + to the target KDC, it MUST verify the responder's identity as + follows: - 1. The certificate contains a Subject Alternative Name (SAN) - extension carrying a dNSName and that name value matches the - following name format: - - _Service._Proto.Realm - - Where the Service name is the string literal "kerberos", the - Proto can be "udp" or "tcp", and the Realm is the domain style - Kerberos realm name [CLAR] of the target KDC. This name format - is identical to the owner label format used in the DNS SRV - records for specifying the KDC location as described in [CLAR]. - For example, the X.509 certificate for the KDC of the Kerberos - realm "EXAMPLE.COM" would contain a dNSName value of - "_kerberos._tcp.EXAMPLE.COM" or "_kerberos._udp.EXAMPLE.COM". - - 2. The certificate contains the EKU KeyPurposeId [RFC3280] - id-pkkdcekuoid (defined below) and an SAN extension [RFC3280] - carrying an AnotherName whose type-id is id-pksan (as defined in - Section 3.2.2) and whose value contains a KRB5PrincipalName name, - and the realm name of that KRB5PrincipalName matches the realm - name of the target KDC. + 1. The KDC's X.509 certificate MUST contain the EKU KeyPurposeId + [RFC3280] id-pkkdcekuoid: id-pkkdcekuoid OBJECT IDENTIFIER ::= { iso(1) org(3) dod(6) internet(1) security(5) kerberosv5(2) @@ -1053,73 +1031,48 @@ Tung & Zhu Expires August 13, 2005 [Page 18] -- Key usage bits that MUST be consistent: -- digitalSignature. - If no SAN id-pksan extension is present (but the id-pkkdcekuoid - EKU is) in the KDC's X.509 certificate, and the client has a + 2. The KDC's X.509 certificate MUST contain a Subject Alternative + Name (SAN) extension [RFC3280] carrying an AnotherName whose + type-id is id-pksan (as defined in Section 3.2.2) and whose value + contains a KRB5PrincipalName name, and the realm name of that + KRB5PrincipalName matches the realm name of the target KDC. If no + such SAN extension is present in the KDC's certificate, the client + SHOULD accept the KDC's certificate as meeting this requirement if + the KDC's X.509 certificate contains an SAN extension carrying a + dNSName and that name value matches the domain style realm name + [CLAR] of the target KDC. The KDC's certificate SHOULD also be + accepted if it contains an SAN extension carrying a dNSName or an + iPAddress (if the KDC is specified by an IP address instead of a + name) and that name value matches the hostname or the IP address + of the KDC with which the client believes it is communicating. If + the KDC's hostname or IP address is used to match the dNSName + value, it MUST have been obtained securely. Matching rules used + for the dNSName value are specified in [RFC3280]. + + Implementation note: CAs issuing KDC certificates SHOULD place all + "short" and "fully-qualified" realm names of the KDC (one per SAN + id-pksan extension) into the KDC certificate to allow maximum + flexibility. + + If all applicable checks are satisfied, the client then decrypts the + enc-part of the KDC-REP in the AS-REP with the reply key, and then + proceeds as described in [CLAR]. -Tung & Zhu Expires August 13, 2005 [Page 19] +Tung & Zhu Expires August 11, 2005 [Page 19] Internet-Draft PKINIT February 2005 - priori knowledge of the KDC's hostname (or IP address), the - client SHOULD accept the KDC's X.509 certificate if that - certificate contains an SAN extension carrying a dNSName and the - dNSName value matches the hostname (or the IP address) of the KDC - with which the client believes it is communicating. - - Matching rules used for the dNSName value are specified in [RFC3280]. - - If all applicable checks are satisfied, the client then decrypts the - enc-part field of the KDC-REP in the AS-REP using the KDC AS reply - key, and then proceeds as described in [CLAR]. - - Implementation note: CAs issuing KDC certificates SHOULD place all - "short" and "fully-qualified" Kerberos realm names of the KDC (one - per SAN extension) into the KDC certificate to allow maximum - flexibility. - -3.3 Interoperability Requirements - - The client MUST be capable of sending a set of certificates - sufficient to allow the KDC to construct a certification path for the - client's certificate, if the correct set of certificates is provided - through configuration or policy. - - If the client sends all the X.509 certificates on a certification - path to a trust anchor acceptable by the KDC, and the KDC can not - verify the client's public key otherwise, the KDC MUST be able to - process path validation for the client's certificate based on the - certificates in the request. - - The KDC MUST be capable of sending a set of certificates sufficient - to allow the client to construct a certification path for the KDC's - certificate, if the correct set of certificates is provided through - configuration or policy. - - If the KDC sends all the X.509 certificates on a certification path - to a trust anchor acceptable by the client, and the client can not - verify the KDC's public key otherwise, the client MUST be able to - process path validation for the KDC's certificate based on the - certificates in the reply. - -3.4 KDC Indication of PKINIT Support +3.3 KDC Indication of PKINIT Support If pre-authentication is required, but was not present in the request, per [CLAR] an error message with the code KDC_ERR_PREAUTH_FAILED is returned and a METHOD-DATA object will be stored in the e-data field of the KRB-ERROR message to specify which pre-authentication mechanisms are acceptable. The KDC can then - - - -Tung & Zhu Expires August 13, 2005 [Page 20] - -Internet-Draft PKINIT February 2005 - - - indicate the support of PKINIT by including an empty element whose + indicate the support of PKINIT by including an element whose padata-type is PA_PK_AS_REQ in that METHOD-DATA object. Otherwise if it is required by the KDC's local policy that the client @@ -1128,8 +1081,8 @@ Internet-Draft PKINIT February 2005 present in the request, an error message with the code KDC_ERR_PREAUTH_FAILED SHOULD be returned. - KDCs MUST leave the padata-value field of the PA_PK_AS_REQ element in - the KRB-ERROR's METHOD-DATA empty (i.e., send a zero-length OCTET + KDCs MUST leave the padata-value of PA_PK_AS_REQ entry in the + KRB-ERROR's METHOD-DATA empty (i.e., send a zero-length OCTET STRING), and clients MUST ignore this and any other value. Future extensions to this protocol may specify other data to send instead of an empty OCTET STRING. @@ -1140,10 +1093,8 @@ Internet-Draft PKINIT February 2005 be regulated strictly in protocol definitions. We will address them in this section. - PKINIT extends the cross-realm model to the public-key - infrastructure. Users of PKINIT must understand security policies - and procedures appropriate to the use of Public Key Infrastructures - [RFC3280]. + Users of PKINIT must understand security policies and procedures + appropriate to the use of Public Key Infrastructures [RFC3280]. Standard Kerberos allows the possibility of interactions between cryptosystems of varying strengths; this document adds interactions @@ -1162,19 +1113,19 @@ Internet-Draft PKINIT February 2005 delivery this is avoided. Care should be taken in how certificates are chosen for the purposes + + + +Tung & Zhu Expires August 11, 2005 [Page 20] + +Internet-Draft PKINIT February 2005 + + of authentication using PKINIT. Some local policies may require that key escrow be used for certain certificate types. Deployers of PKINIT should be aware of the implications of using certificates that have escrowed keys for the purposes of authentication. Because signing only certificates are normally not escrowed, by using DH - - - -Tung & Zhu Expires August 13, 2005 [Page 21] - -Internet-Draft PKINIT February 2005 - - based key delivery this is avoided. PKINIT does not provide for a "return routability" test to prevent @@ -1217,20 +1168,19 @@ Internet-Draft PKINIT February 2005 Lastly, comments from groups working on similar ideas in DCE have been invaluable. -6. IANA Considerations - - This document has no actions for IANA. - - -Tung & Zhu Expires August 13, 2005 [Page 22] +Tung & Zhu Expires August 11, 2005 [Page 21] Internet-Draft PKINIT February 2005 +6. IANA Considerations + + This document has no actions for IANA. + 7. References 7.1 Normative References @@ -1275,23 +1225,20 @@ Internet-Draft PKINIT February 2005 Diffie-Hellman groups for Internet Key Exchange (IKE)", RFC 3526, May 2003. - [RFC3565] Schaad, J., "Use of the Advanced Encryption Standard (AES) - Encryption Algorithm in Cryptographic Message Syntax - (CMS)", RFC 3565, July 2003. - -Tung & Zhu Expires August 13, 2005 [Page 23] +Tung & Zhu Expires August 11, 2005 [Page 22] Internet-Draft PKINIT February 2005 + [RFC3565] Schaad, J., "Use of the Advanced Encryption Standard (AES) + Encryption Algorithm in Cryptographic Message Syntax + (CMS)", RFC 3565, July 2003. + [RFC3852] Housley, R., "Cryptographic Message Syntax (CMS)", RFC 3852, July 2004. - [X.509-97] ITU-T. Recommendation X.509: The Directory - Authentication - Framework. 1997. - [X690] ASN.1 encoding rules: Specification of Basic Encoding Rules (BER), Canonical Encoding Rules (CER) and Distinguished Encoding Rules (DER), ITU-T Recommendation @@ -1309,6 +1256,7 @@ Internet-Draft PKINIT February 2005 [ODL99] Odlyzko, A., "Discrete logarithms: The past and the future, Designs, Codes, and Cryptography (1999)". + Authors' Addresses Brian Tung @@ -1332,7 +1280,7 @@ Appendix A. PKINIT ASN.1 Module -Tung & Zhu Expires August 13, 2005 [Page 24] +Tung & Zhu Expires August 11, 2005 [Page 23] Internet-Draft PKINIT February 2005 @@ -1372,10 +1320,10 @@ Internet-Draft PKINIT February 2005 id-pkekuoid OBJECT IDENTIFIER ::= { id-pkinit 4 } id-pkkdcekuoid OBJECT IDENTIFIER ::= { id-pkinit 5 } - pa-pk-as-req INTEGER ::= 16 - pa-pk-as-rep INTEGER ::= 17 + pa-pk-as-req INTEGER ::= 16 + pa-pk-as-rep INTEGER ::= 17 - ad-initial-verified-cas INTEGER ::= 9 + ad-initial-verified-cas INTEGER ::= 9 td-trusted-certifiers INTEGER ::= 104 td-invalid-certificates INTEGER ::= 105 @@ -1388,7 +1336,7 @@ Internet-Draft PKINIT February 2005 -Tung & Zhu Expires August 13, 2005 [Page 25] +Tung & Zhu Expires August 11, 2005 [Page 24] Internet-Draft PKINIT February 2005 @@ -1418,37 +1366,20 @@ Internet-Draft PKINIT February 2005 DHNonce ::= OCTET STRING - TrustedCA ::= SEQUENCE { - caName [0] IMPLICIT OCTET STRING, + TrustedCA ::= CHOICE { + caName [1] IMPLICIT OCTET STRING, -- Contains a PKIX type Name encoded according to -- [RFC3280]. -- Identifies a CA. -- Prefer the sid field below if that is available. - certificateSerialNumber [1] INTEGER OPTIONAL, - -- Specifies the certificate serial number. - -- The defintion of the certificate serial number - -- is taken from X.509 [X.509-97]. - subjectKeyIdentifier [2] OCTET STRING OPTIONAL, - -- Identifies the CA's public key by a key - -- identifier. When an X.509 certificate is - -- referenced, this key identifier matches the X.509 - -- subjectKeyIdentifier extension value. When other - -- certificate formats are referenced, the documents - -- that specify the certificate format and their use - -- with the CMS must include details on matching the - -- key identifier to the appropriate certificate - -- field. + sid [2] IMPLICIT OCTET STRING, + -- Contains a CMS type SignerIdentifier encoded + -- according to [RFC3852]. + -- Identifies the trusted CA's certificate (and + -- thereby the public key). ... } - - - -Tung & Zhu Expires August 13, 2005 [Page 26] - -Internet-Draft PKINIT February 2005 - - AuthPack ::= SEQUENCE { pkAuthenticator [0] PKAuthenticator, clientPublicValue [1] SubjectPublicKeyInfo OPTIONAL, @@ -1458,6 +1389,14 @@ Internet-Draft PKINIT February 2005 -- according to [RFC3279]. -- Present only if the client wishes to use the -- Diffie-Hellman key agreement method. + + + +Tung & Zhu Expires August 11, 2005 [Page 25] + +Internet-Draft PKINIT February 2005 + + supportedCMSTypes [2] SEQUENCE OF AlgorithmIdentifier OPTIONAL, -- List of CMS encryption types supported by @@ -1497,14 +1436,6 @@ Internet-Draft PKINIT February 2005 -- signature. KRB5PrincipalName ::= SEQUENCE { - - - -Tung & Zhu Expires August 13, 2005 [Page 27] - -Internet-Draft PKINIT February 2005 - - realm [0] Realm, principalName [1] PrincipalName } @@ -1515,6 +1446,13 @@ Internet-Draft PKINIT February 2005 -- Each TrustedCA identifies a CA or a CA -- certificate (thereby its public key). + + +Tung & Zhu Expires August 11, 2005 [Page 26] + +Internet-Draft PKINIT February 2005 + + PA-PK-AS-REP ::= CHOICE { dhInfo [0] DHRepInfo, -- Selected when Diffie-Hellman key exchange is @@ -1554,13 +1492,6 @@ Internet-Draft PKINIT February 2005 -- present. } - - -Tung & Zhu Expires August 13, 2005 [Page 28] - -Internet-Draft PKINIT February 2005 - - KDCDHKeyInfo ::= SEQUENCE { subjectPublicKey [0] BIT STRING, -- KDC's DH public key. @@ -1570,6 +1501,14 @@ Internet-Draft PKINIT February 2005 -- Contains the nonce in the PKAuthenticator of the -- request if DH keys are NOT reused, -- 0 otherwise. + + + +Tung & Zhu Expires August 11, 2005 [Page 27] + +Internet-Draft PKINIT February 2005 + + dhKeyExpiration [2] KerberosTime OPTIONAL, -- Expiration time for KDC's key pair, -- present if and only if DH keys are reused. If @@ -1612,7 +1551,16 @@ Internet-Draft PKINIT February 2005 -Tung & Zhu Expires August 13, 2005 [Page 29] + + + + + + + + + +Tung & Zhu Expires August 11, 2005 [Page 28] Internet-Draft PKINIT February 2005 @@ -1668,6 +1616,6 @@ Acknowledgment -Tung & Zhu Expires August 13, 2005 [Page 30] +Tung & Zhu Expires August 11, 2005 [Page 29] diff --git a/doc/standardisation/draft-ietf-cat-kerberos-pk-init-26.txt b/doc/standardisation/draft-ietf-cat-kerberos-pk-init-26.txt index 6cfe5c9d2..049330260 100644 --- a/doc/standardisation/draft-ietf-cat-kerberos-pk-init-26.txt +++ b/doc/standardisation/draft-ietf-cat-kerberos-pk-init-26.txt @@ -1,6 +1,3 @@ - - - NETWORK WORKING GROUP B. Tung Internet-Draft USC Information Sciences Institute Expires: November 24, 2005 L. Zhu @@ -9,7 +6,7 @@ Expires: November 24, 2005 L. Zhu Public Key Cryptography for Initial Authentication in Kerberos - draft-ietf-cat-kerberos-pk-init-26 + draft-ietf-cat-kerberos-pk-init Status of this Memo diff --git a/doc/standardisation/draft-ietf-cat-kerberos-pk-init-27.txt b/doc/standardisation/draft-ietf-cat-kerberos-pk-init-27.txt index 633a3ecc2..ab4aeb58c 100644 --- a/doc/standardisation/draft-ietf-cat-kerberos-pk-init-27.txt +++ b/doc/standardisation/draft-ietf-cat-kerberos-pk-init-27.txt @@ -1,6 +1,3 @@ - - - NETWORK WORKING GROUP B. Tung Internet-Draft USC Information Sciences Institute Expires: January 20, 2006 L. Zhu diff --git a/doc/standardisation/draft-ietf-cat-kerberos-pk-init-28.txt b/doc/standardisation/draft-ietf-cat-kerberos-pk-init-28.txt new file mode 100644 index 000000000..ae76eb8d2 --- /dev/null +++ b/doc/standardisation/draft-ietf-cat-kerberos-pk-init-28.txt @@ -0,0 +1,1897 @@ +NETWORK WORKING GROUP B. Tung +Internet-Draft USC Information Sciences Institute +Expires: March 16, 2006 L. Zhu + Microsoft Corporation + September 12, 2005 + + + Public Key Cryptography for Initial Authentication in Kerberos + draft-ietf-cat-kerberos-pk-init-28 + +Status of this Memo + + By submitting this Internet-Draft, each author represents that any + applicable patent or other IPR claims of which he or she is aware + have been or will be disclosed, and any of which he or she becomes + aware will be disclosed, in accordance with Section 6 of BCP 79. + + Internet-Drafts are working documents of the Internet Engineering + Task Force (IETF), its areas, and its working groups. Note that + other groups may also distribute working documents as Internet- + Drafts. + + Internet-Drafts are draft documents valid for a maximum of six months + and may be updated, replaced, or obsoleted by other documents at any + time. It is inappropriate to use Internet-Drafts as reference + material or to cite them other than as "work in progress." + + The list of current Internet-Drafts can be accessed at + http://www.ietf.org/ietf/1id-abstracts.txt. + + The list of Internet-Draft Shadow Directories can be accessed at + http://www.ietf.org/shadow.html. + + This Internet-Draft will expire on March 16, 2006. + +Copyright Notice + + Copyright (C) The Internet Society (2005). + +Abstract + + This document describes protocol extensions (hereafter called PKINIT) + to the Kerberos protocol specification. These extensions provide a + method for integrating public key cryptography into the initial + authentication exchange, by using asymmetric-key signature and/or + encryption algorithms in pre-authentication data fields. + + + + + +Tung & Zhu Expires March 16, 2006 [Page 1] + +Internet-Draft PKINIT September 2005 + + +Table of Contents + + 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 + 2. Conventions Used in This Document . . . . . . . . . . . . . . 3 + 3. Extensions . . . . . . . . . . . . . . . . . . . . . . . . . . 4 + 3.1. Definitions, Requirements, and Constants . . . . . . . . . 4 + 3.1.1. Required Algorithms . . . . . . . . . . . . . . . . . 4 + 3.1.2. Defined Message and Encryption Types . . . . . . . . . 5 + 3.1.3. Algorithm Identifiers . . . . . . . . . . . . . . . . 6 + 3.2. PKINIT Pre-authentication Syntax and Use . . . . . . . . . 7 + 3.2.1. Generation of Client Request . . . . . . . . . . . . . 7 + 3.2.2. Receipt of Client Request . . . . . . . . . . . . . . 10 + 3.2.3. Generation of KDC Reply . . . . . . . . . . . . . . . 14 + 3.2.4. Receipt of KDC Reply . . . . . . . . . . . . . . . . . 19 + 3.3. Interoperability Requirements . . . . . . . . . . . . . . 20 + 3.4. KDC Indication of PKINIT Support . . . . . . . . . . . . . 21 + 4. Security Considerations . . . . . . . . . . . . . . . . . . . 21 + 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 23 + 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23 + 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 24 + 7.1. Normative References . . . . . . . . . . . . . . . . . . . 24 + 7.2. Informative References . . . . . . . . . . . . . . . . . . 25 + Appendix A. PKINIT ASN.1 Module . . . . . . . . . . . . . . . . . 25 + Appendix B. Test Vectors . . . . . . . . . . . . . . . . . . . . 31 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 33 + Intellectual Property and Copyright Statements . . . . . . . . . . 34 + + + + + + + + + + + + + + + + + + + + + + + + + +Tung & Zhu Expires March 16, 2006 [Page 2] + +Internet-Draft PKINIT September 2005 + + +1. Introduction + + A client typically authenticates itself to a service in Kerberos + using three distinct though related exchanges. First, the client + requests a ticket-granting ticket (TGT) from the Kerberos + authentication server (AS). Then, it uses the TGT to request a + service ticket from the Kerberos ticket-granting server (TGS). + Usually, the AS and TGS are integrated in a single device known as a + Kerberos Key Distribution Center, or KDC. Finally, the client uses + the service ticket to authenticate itself to the service. + + The advantage afforded by the TGT is that the client exposes his + long-term secrets only once. The TGT and its associated session key + can then be used for any subsequent service ticket requests. One + result of this is that all further authentication is independent of + the method by which the initial authentication was performed. + Consequently, initial authentication provides a convenient place to + integrate public-key cryptography into Kerberos authentication. + + As defined in [RFC4120], Kerberos authentication exchanges use + symmetric-key cryptography, in part for performance. One + disadvantage of using symmetric-key cryptography is that the keys + must be shared, so that before a client can authenticate itself, he + must already be registered with the KDC. + + Conversely, public-key cryptography (in conjunction with an + established Public Key Infrastructure) permits authentication without + prior registration with a KDC. Adding it to Kerberos allows the + widespread use of Kerberized applications by clients without + requiring them to register first with a KDC--a requirement that has + no inherent security benefit. + + As noted above, a convenient and efficient place to introduce public- + key cryptography into Kerberos is in the initial authentication + exchange. This document describes the methods and data formats for + integrating public-key cryptography into Kerberos initial + authentication. + + +2. Conventions Used in This Document + + The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", + "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this + document are to be interpreted as described in [RFC2119]. + + Both the AS and the TGS are referred to as the KDC. + + In this document, the encryption key used to encrypt the enc-part + + + +Tung & Zhu Expires March 16, 2006 [Page 3] + +Internet-Draft PKINIT September 2005 + + + field of the KDC-REP in the AS-REP [RFC4120] is referred to as the AS + reply key. + + +3. Extensions + + This section describes extensions to [RFC4120] for supporting the use + of public-key cryptography in the initial request for a ticket. + + Briefly, this document defines the following extensions to [RFC4120]: + + 1. The client indicates the use of public-key authentication by + including a special preauthenticator in the initial request. This + preauthenticator contains the client's public-key data and a + signature. + + 2. The KDC tests the client's request against its authentication + policy and trusted Certification Authorities (CAs). + + 3. If the request passes the verification tests, the KDC replies as + usual, but the reply is encrypted using either: + + a. a key generated through a Diffie-Hellman (DH) key exchange + [RFC2631] [IEEE1363] with the client, signed using the KDC's + signature key; or + + b. a symmetric encryption key, signed using the KDC's signature + key and encrypted using the client's public key. + + Any keying material required by the client to obtain the + encryption key for decrypting the KDC reply is returned in a pre- + authentication field accompanying the usual reply. + + 4. The client validates the KDC's signature, obtains the encryption + key, decrypts the reply, and then proceeds as usual. + + Section 3.1 of this document enumerates the required algorithms and + necessary extension message types. Section 3.2 describes the + extension messages in greater detail. + +3.1. Definitions, Requirements, and Constants + +3.1.1. Required Algorithms + + All PKINIT implementations MUST support the following algorithms: + + + + + + +Tung & Zhu Expires March 16, 2006 [Page 4] + +Internet-Draft PKINIT September 2005 + + + o AS reply key enctype: aes128-cts-hmac-sha1-96 and aes256-cts-hmac- + sha1-96 [RFC3962]. + + o Signature algorithm: sha-1WithRSAEncryption [RFC3279]. + + o AS reply key delivery method: Diffie-Hellman key exchange + [RFC2631]. + + In addition, implementations of this specification MUST be capable of + processing the Extended Key Usage (EKU) extension and the id-pksan + (as defined in Section 3.2.2) otherName of the Subject Alternative + Name (SAN) extension in X.509 certificates [RFC3280], if present. + +3.1.2. Defined Message and Encryption Types + + PKINIT makes use of the following new pre-authentication types: + + PA_PK_AS_REQ 16 + PA_PK_AS_REP 17 + + PKINIT also makes use of the following new authorization data type: + + AD_INITIAL_VERIFIED_CAS 9 + + PKINIT introduces the following new error codes: + + KDC_ERR_CLIENT_NOT_TRUSTED 62 + KDC_ERR_INVALID_SIG 64 + KDC_ERR_DH_KEY_PARAMETERS_NOT_ACCEPTED 65 + KDC_ERR_CANT_VERIFY_CERTIFICATE 70 + KDC_ERR_INVALID_CERTIFICATE 71 + KDC_ERR_REVOKED_CERTIFICATE 72 + KDC_ERR_REVOCATION_STATUS_UNKNOWN 73 + KDC_ERR_CLIENT_NAME_MISMATCH 75 + KDC_ERR_INCONSISTENT_KEY_PURPOSE 76 + + PKINIT uses the following typed data types for errors: + + TD_TRUSTED_CERTIFIERS 104 + TD_INVALID_CERTIFICATES 105 + TD_DH_PARAMETERS 109 + + PKINIT defines the following encryption types, for use in the AS-REQ + message to indicate acceptance of the corresponding algorithms that + can used by Cryptographic Message Syntax (CMS) [RFC3852] messages in + the reply: + + + + + +Tung & Zhu Expires March 16, 2006 [Page 5] + +Internet-Draft PKINIT September 2005 + + + dsaWithSHA1-CmsOID 9 + md5WithRSAEncryption-CmsOID 10 + sha1WithRSAEncryption-CmsOID 11 + rc2CBC-EnvOID 12 + rsaEncryption-EnvOID (PKCS1 v1.5) 13 + rsaES-OAEP-EnvOID (PKCS1 v2.0) 14 + des-ede3-cbc-EnvOID 15 + + The ASN.1 module for all structures defined in this document (plus + IMPORT statements for all imported structures) is given in + Appendix A. + + All structures defined in or imported into this document MUST be + encoded using Distinguished Encoding Rules (DER) [X690] (unless + otherwise noted). All data structures carried in OCTET STRINGs must + be encoded according to the rules specified in corresponding + specifications. + + Interoperability note: Some implementations may not be able to decode + wrapped CMS objects encoded with BER but not DER; specifically, they + may not be able to decode infinite length encodings. To maximize + interoperability, implementers SHOULD encode CMS objects used in + PKINIT with DER. + +3.1.3. Algorithm Identifiers + + PKINIT does not define, but does make use of, the following algorithm + identifiers. + + PKINIT uses the following algorithm identifier(s) for Diffie-Hellman + key agreement [RFC3279]: + + dhpublicnumber (Modular Exponential Diffie-Hellman [RFC2631]) + + PKINIT uses the following signature algorithm identifiers [RFC3279]: + + sha-1WithRSAEncryption (RSA with SHA1) + md5WithRSAEncryption (RSA with MD5) + id-dsa-with-sha1 (DSA with SHA1) + + PKINIT uses the following encryption algorithm identifiers [RFC3447] + for encrypting the temporary key with a public key: + + rsaEncryption (PKCS1 v1.5) + id-RSAES-OAEP (PKCS1 v2.0) + + PKINIT uses the following algorithm identifiers [RFC3370] [RFC3565] + for encrypting the AS reply key with the temporary key: + + + +Tung & Zhu Expires March 16, 2006 [Page 6] + +Internet-Draft PKINIT September 2005 + + + des-ede3-cbc (three-key 3DES, CBC mode) + rc2-cbc (RC2, CBC mode) + id-aes256-CBC (AES-256, CBC mode) + +3.2. PKINIT Pre-authentication Syntax and Use + + This section defines the syntax and use of the various pre- + authentication fields employed by PKINIT. + +3.2.1. Generation of Client Request + + The initial authentication request (AS-REQ) is sent as per [RFC4120]; + in addition, a pre-authentication data element, whose padata-type is + PA_PK_AS_REQ and whose padata-value contains the DER encoding of the + type PA-PK-AS-REQ, is included. + + PA-PK-AS-REQ ::= SEQUENCE { + signedAuthPack [0] IMPLICIT OCTET STRING, + -- Contains a CMS type ContentInfo encoded + -- according to [RFC3852]. + -- The contentType field of the type ContentInfo + -- is id-signedData (1.2.840.113549.1.7.2), + -- and the content field is a SignedData. + -- The eContentType field for the type SignedData is + -- id-pkauthdata (1.3.6.1.5.2.3.1), and the + -- eContent field contains the DER encoding of the + -- type AuthPack. + -- AuthPack is defined below. + trustedCertifiers [1] SEQUENCE OF + ExternalPrincipalIdentifier OPTIONAL, + -- A list of CAs, trusted by the client, that can + -- be used to certify the KDC. + -- Each ExternalPrincipalIdentifier identifies a CA + -- or a CA certificate (thereby its public key). + -- The information contained in the + -- trustedCertifiers SHOULD be used by the KDC as + -- hints to guide its selection of an appropriate + -- certificate chain to return to the client. + kdcPkId [2] IMPLICIT OCTET STRING + OPTIONAL, + -- Contains a CMS type SignerIdentifier encoded + -- according to [RFC3852]. + -- Identifies, if present, a particular KDC + -- public key that the client already has. + ... + } + + DHNonce ::= OCTET STRING + + + +Tung & Zhu Expires March 16, 2006 [Page 7] + +Internet-Draft PKINIT September 2005 + + + ExternalPrincipalIdentifier ::= SEQUENCE { + subjectName [0] IMPLICIT OCTET STRING OPTIONAL, + -- Contains a PKIX type Name encoded according to + -- [RFC3280]. + -- Identifies the certificate subject by the + -- distinguished subject name. + -- REQUIRED when there is a distinguished subject + -- name present in the certificate. + issuerAndSerialNumber [1] IMPLICIT OCTET STRING OPTIONAL, + -- Contains a CMS type IssuerAndSerialNumber encoded + -- according to [RFC3852]. + -- Identifies a certificate of the subject. + -- REQUIRED for TD-INVALID-CERTIFICATES and + -- TD-TRUSTED-CERTIFIERS. + subjectKeyIdentifier [2] IMPLICIT OCTET STRING OPTIONAL, + -- Identifies the subject's public key by a key + -- identifier. When an X.509 certificate is + -- referenced, this key identifier matches the X.509 + -- subjectKeyIdentifier extension value. When other + -- certificate formats are referenced, the documents + -- that specify the certificate format and their use + -- with the CMS must include details on matching the + -- key identifier to the appropriate certificate + -- field. + -- RECOMMENDED for TD-TRUSTED-CERTIFIERS. + ... + } + + AuthPack ::= SEQUENCE { + pkAuthenticator [0] PKAuthenticator, + clientPublicValue [1] SubjectPublicKeyInfo OPTIONAL, + -- Type SubjectPublicKeyInfo is defined in + -- [RFC3280]. + -- Specifies Diffie-Hellman domain parameters + -- and the client's public key value [IEEE1363]. + -- The DH public key value is encoded as a BIT + -- STRING according to [RFC3279]. + -- This field is present only if the client wishes + -- to use the Diffie-Hellman key agreement method. + supportedCMSTypes [2] SEQUENCE OF AlgorithmIdentifier + OPTIONAL, + -- Type AlgorithmIdentifier is defined in + -- [RFC3280]. + -- List of CMS encryption types supported by the + -- client in order of (decreasing) preference. + clientDHNonce [3] DHNonce OPTIONAL, + -- Present only if the client indicates that it + -- wishes to reuse DH keys or to allow the KDC to + + + +Tung & Zhu Expires March 16, 2006 [Page 8] + +Internet-Draft PKINIT September 2005 + + + -- do so (see Section 3.2.3.1). + ... + } + + PKAuthenticator ::= SEQUENCE { + cusec [0] INTEGER (0..999999), + ctime [1] KerberosTime, + -- cusec and ctime are used as in [RFC4120], for + -- replay prevention. + nonce [2] INTEGER (0..4294967295), + -- Chosen randomly; This nonce does not need to + -- match with the nonce in the KDC-REQ-BODY. + paChecksum [3] OCTET STRING, + -- Contains the SHA1 checksum, performed over + -- KDC-REQ-BODY. + ... + } + + The ContentInfo [RFC3852] structure for the signedAuthPack field is + filled out as follows: + + 1. The contentType field of the type ContentInfo is id-signedData + (as defined in [RFC3852]), and the content field is a SignedData + (as defined in [RFC3852]). + + 2. The eContentType field for the type SignedData is id-pkauthdata: + { iso(1) org(3) dod(6) internet(1) security(5) kerberosv5(2) + pkinit(3) pkauthdata(1) }. + + 3. The eContent field for the type SignedData contains the DER + encoding of the type AuthPack. + + 4. The signerInfos field of the type SignedData contains a single + signerInfo, which contains the signature over the type AuthPack. + + 5. The certificates field of the type SignedData contains + certificates intended to facilitate certification path + construction, so that the KDC can verify the signature over the + type AuthPack. For path validation, these certificates SHOULD be + sufficient to construct at least one certification path from the + client certificate to one trust anchor acceptable by the KDC + [CAPATH]. The client MUST be capable of including such a set of + certificates if configured to do so. The certificates field MUST + NOT contain "root" CA certificates. + + 6. The client's Diffie-Hellman public value (clientPublicValue) is + included if and only if the client wishes to use the Diffie- + Hellman key agreement method. The Diffie-Hellman domain + + + +Tung & Zhu Expires March 16, 2006 [Page 9] + +Internet-Draft PKINIT September 2005 + + + parameters [IEEE1363] for the client's public key are specified + in the algorithm field of the type SubjectPublicKeyInfo [RFC3279] + and the client's Diffie-Hellman public key value is mapped to a + subjectPublicKey (a BIT STRING) according to [RFC3279]. When + using the Diffie-Hellman key agreement method, implementations + MUST support Oakley 1024-bit Modular Exponential (MODP) well- + known group 2 [RFC2412] and Oakley 2048-bit MODP well-known group + 14 [RFC3526], and SHOULD support Oakley 4096-bit MODP well-known + group 16 [RFC3526]. + + The Diffie-Hellman field size should be chosen so as to provide + sufficient cryptographic security [RFC3766]. + + When MODP Diffie-Hellman is used, the exponents should have at + least twice as many bits as the symmetric keys that will be + derived from them [ODL99]. + + 7. The client may wish to reuse DH keys or to allow the KDC to do so + (see Section 3.2.3.1). If so, then the client includes the + clientDHNonce field. This nonce string needs to be as long as + the longest key length of the symmetric key types that the client + supports. This nonce MUST be chosen randomly. + + +3.2.2. Receipt of Client Request + + Upon receiving the client's request, the KDC validates it. This + section describes the steps that the KDC MUST (unless otherwise + noted) take in validating the request. + + The KDC verifies the client's signature in the signedAuthPack field + according to [RFC3852]. + + If, while validating the client's X.509 certificate [RFC3280], the + KDC cannot build a certification path to validate the client's + certificate, it sends back a KRB-ERROR [RFC4120] message with the + code KDC_ERR_CANT_VERIFY_CERTIFICATE. The accompanying e-data for + this error message is a TYPED-DATA (as defined in [RFC4120]) that + contains an element whose data-type is TD_TRUSTED_CERTIFIERS, and + whose data-value contains the DER encoding of the type TD-TRUSTED- + CERTIFIERS: + + TD-TRUSTED-CERTIFIERS ::= SEQUENCE OF + ExternalPrincipalIdentifier + -- Identifies a list of CAs trusted by the KDC. + -- Each ExternalPrincipalIdentifier identifies a CA + -- or a CA certificate (thereby its public key). + + + + +Tung & Zhu Expires March 16, 2006 [Page 10] + +Internet-Draft PKINIT September 2005 + + + Upon receiving this error message, the client SHOULD retry only if it + has a different set of certificates (from those of the previous + requests) that form a certification path (or a partial path) from one + of the trust anchors acceptable by the KDC to its own certificate. + + If, while processing the certification path, the KDC determines that + the signature on one of the certificates in the signedAuthPack field + is invalid, it returns a KRB-ERROR [RFC4120] message with the code + KDC_ERR_INVALID_CERTIFICATE. The accompanying e-data for this error + message is a TYPED-DATA that contains an element whose data-type is + TD_INVALID_CERTIFICATES, and whose data-value contains the DER + encoding of the type TD-INVALID-CERTIFICATES: + + TD-INVALID-CERTIFICATES ::= SEQUENCE OF + ExternalPrincipalIdentifier + -- Each ExternalPrincipalIdentifier identifies a + -- certificate (sent by the client) with an invalid + -- signature. + + If more than one X.509 certificate signature is invalid, the KDC MAY + include one IssuerAndSerialNumber per invalid signature within the + TD-INVALID-CERTIFICATES. + + The client's X.509 certificate is validated according to [RFC3280]. + + Based on local policy, the KDC may also check whether any X.509 + certificates in the certification path validating the client's + certificate have been revoked. If any of them have been revoked, the + KDC MUST return an error message with the code + KDC_ERR_REVOKED_CERTIFICATE; if the KDC attempts to determine the + revocation status but is unable to do so, it SHOULD return an error + message with the code KDC_ERR_REVOCATION_STATUS_UNKNOWN. The + certificate or certificates affected are identified exactly as for + the error code KDC_ERR_INVALID_CERTIFICATE (see above). + + Note that the TD_INVALID_CERTIFICATES error data is only used to + identify invalid certificates sent by the client in the request. + + The client's public key is then used to verify the signature. If the + signature fails to verify, the KDC MUST return an error message with + the code KDC_ERR_INVALID_SIG. There is no accompanying e-data for + this error message. + + In addition to validating the client's signature, the KDC MUST also + check that the client's public key used to verify the client's + signature is bound to the client's principal name as specified in the + AS-REQ as follows: + + + + +Tung & Zhu Expires March 16, 2006 [Page 11] + +Internet-Draft PKINIT September 2005 + + + 1. If the KDC has its own binding between either the client's + signature-verification public key or the client's certificate and + the client's Kerberos principal name, it uses that binding. + + 2. Otherwise, if the client's X.509 certificate contains a Subject + Alternative Name (SAN) extension carrying a KRB5PrincipalName + (defined below) in the otherName field of the type GeneralName + [RFC3280], it binds the client's X.509 certificate to that name. + + The type of the otherName field is AnotherName. The type-id field + of the type AnotherName is id-pksan: + + id-pksan OBJECT IDENTIFIER ::= + { iso(1) org(3) dod(6) internet(1) security(5) kerberosv5(2) + x509-sanan (2) } + + And the value field of the type AnotherName is a + KRB5PrincipalName. + + KRB5PrincipalName ::= SEQUENCE { + realm [0] Realm, + principalName [1] PrincipalName + } + + If the KDC does not have its own binding and there is no + KRB5PrincipalName name present in the client's X.509 certificate, or + if the Kerberos name in the request does not match the + KRB5PrincipalName in the client's X.509 certificate (including the + realm name), the KDC MUST return an error message with the code + KDC_ERR_CLIENT_NAME_MISMATCH. There is no accompanying e-data for + this error message. + + Even if the certification path is validated and the certificate is + mapped to the client's principal name, the KDC may decide not to + accept the client's certificate, depending on local policy. + + The KDC MAY require the presence of an Extended Key Usage (EKU) + KeyPurposeId [RFC3280] id-pkekuoid in the extensions field of the + client's X.509 certificate: + + id-pkekuoid OBJECT IDENTIFIER ::= + { iso(1) org(3) dod(6) internet(1) security(5) kerberosv5(2) + pkinit(3) pkekuoid(4) } + -- PKINIT client authentication. + -- Key usage bits that MUST be consistent: + -- digitalSignature. + + If this EKU KeyPurposeId is required but it is not present or if the + + + +Tung & Zhu Expires March 16, 2006 [Page 12] + +Internet-Draft PKINIT September 2005 + + + client certificate is restricted not to be used for PKINIT client + authentication per Section 4.2.1.13 of [RFC3280], the KDC MUST return + an error message of the code KDC_ERR_INCONSISTENT_KEY_PURPOSE. There + is no accompanying e-data for this error message. KDCs implementing + this requirement SHOULD also accept the EKU KeyPurposeId id-ms-sc- + logon (1.3.6.1.4.1.311.20.2.2) as meeting the requirement, as there + are a large number of X.509 client certificates deployed for use with + PKINIT which have this EKU. + + As a matter of local policy, the KDC MAY decide to reject requests on + the basis of the absence or presence of other specific EKU OID's. + + If the client's public key is not accepted, the KDC returns an error + message with the code KDC_ERR_CLIENT_NOT_TRUSTED. + + The KDC MUST check the timestamp to ensure that the request is not a + replay, and that the time skew falls within acceptable limits. The + recommendations for clock skew times in [RFC4120] apply here. If the + check fails, the KDC MUST return error code KRB_AP_ERR_REPEAT or + KRB_AP_ERR_SKEW, respectively. + + If the clientPublicValue is filled in, indicating that the client + wishes to use the Diffie-Hellman key agreement method, the KDC SHOULD + check to see if the key parameters satisfy its policy. If they do + not, it MUST return an error message with the code + KDC_ERR_DH_KEY_PARAMETERS_NOT_ACCEPTED. The accompanying e-data is a + TYPED-DATA that contains an element whose data-type is + TD_DH_PARAMETERS, and whose data-value contains the DER encoding of + the type TD-DH-PARAMETERS: + + TD-DH-PARAMETERS ::= SEQUENCE OF AlgorithmIdentifier + -- Each AlgorithmIdentifier specifies a set of + -- Diffie-Hellman domain parameters [IEEE1363]. + -- This list is in decreasing preference order. + + TD-DH-PARAMETERS contains a list of Diffie-Hellman domain parameters + that the KDC supports in decreasing preference order, from which the + client SHOULD pick one to retry the request. + + If the client included a kdcPkId field in the PA-PK-AS-REQ and the + KDC does not possess the corresponding key, the KDC MUST ignore the + kdcPkId field as if the client did not include one. + + If there is a supportedCMSTypes field in the AuthPack, the KDC must + check to see if it supports any of the listed types. If it supports + more than one of the types, the KDC SHOULD use the one listed first. + If it does not support any of them, it MUST return an error message + with the code KDC_ERR_ETYPE_NOSUPP [RFC4120]. + + + +Tung & Zhu Expires March 16, 2006 [Page 13] + +Internet-Draft PKINIT September 2005 + + +3.2.3. Generation of KDC Reply + + Assuming that the client's request has been properly validated, the + KDC proceeds as per [RFC4120], except as follows. + + The KDC MUST set the initial flag and include an authorization data + element of ad-type [RFC4120] AD_INITIAL_VERIFIED_CAS in the issued + ticket. The ad-data [RFC4120] field contains the DER encoding of the + type AD-INITIAL-VERIFIED-CAS: + + AD-INITIAL-VERIFIED-CAS ::= SEQUENCE OF + ExternalPrincipalIdentifier + -- Identifies the certification path based on which + -- the client certificate was validated. + -- Each ExternalPrincipalIdentifier identifies a CA + -- or a CA certificate (thereby its public key). + + The AS wraps any AD-INITIAL-VERIFIED-CAS data in AD-IF-RELEVANT + containers if the list of CAs satisfies the AS' realm's local policy + (this corresponds to the TRANSITED-POLICY-CHECKED ticket flag + [RFC4120]). Furthermore, any TGS MUST copy such authorization data + from tickets used within a PA-TGS-REQ of the TGS-REQ into the + resulting ticket. If the list of CAs satisfies the local KDC's + realm's policy, the TGS MAY wrap the data into the AD-IF-RELEVANT + container, otherwise it MAY unwrap the authorization data out of the + AD-IF-RELEVANT container. + + Application servers that understand this authorization data type + SHOULD apply local policy to determine whether a given ticket bearing + such a type *not* contained within an AD-IF-RELEVANT container is + acceptable. (This corresponds to the AP server checking the + transited field when the TRANSITED-POLICY-CHECKED flag has not been + set [RFC4120].) If such a data type is contained within an AD-IF- + RELEVANT container, AP servers MAY apply local policy to determine + whether the authorization data is acceptable. + + The content of the AS-REP is otherwise unchanged from [RFC4120]. The + KDC encrypts the reply as usual, but not with the client's long-term + key. Instead, it encrypts it with either a shared key derived from a + Diffie-Hellman exchange, or a generated encryption key. The contents + of the PA-PK-AS-REP indicate which key delivery method is used: + + PA-PK-AS-REP ::= CHOICE { + dhInfo [0] DHRepInfo, + -- Selected when Diffie-Hellman key exchange is + -- used. + encKeyPack [1] IMPLICIT OCTET STRING, + -- Selected when public key encryption is used. + + + +Tung & Zhu Expires March 16, 2006 [Page 14] + +Internet-Draft PKINIT September 2005 + + + -- Contains a CMS type ContentInfo encoded + -- according to [RFC3852]. + -- The contentType field of the type ContentInfo is + -- id-envelopedData (1.2.840.113549.1.7.3). + -- The content field is an EnvelopedData. + -- The contentType field for the type EnvelopedData + -- is id-signedData (1.2.840.113549.1.7.2). + -- The eContentType field for the inner type + -- SignedData (when unencrypted) is id-pkrkeydata + -- (1.2.840.113549.1.7.3) and the eContent field + -- contains the DER encoding of the type + -- ReplyKeyPack. + -- ReplyKeyPack is defined in Section 3.2.3.2. + ... + } + + DHRepInfo ::= SEQUENCE { + dhSignedData [0] IMPLICIT OCTET STRING, + -- Contains a CMS type ContentInfo encoded according + -- to [RFC3852]. + -- The contentType field of the type ContentInfo is + -- id-signedData (1.2.840.113549.1.7.2), and the + -- content field is a SignedData. + -- The eContentType field for the type SignedData is + -- id-pkdhkeydata (1.3.6.1.5.2.3.2), and the + -- eContent field contains the DER encoding of the + -- type KDCDHKeyInfo. + -- KDCDHKeyInfo is defined below. + serverDHNonce [1] DHNonce OPTIONAL + -- Present if and only if dhKeyExpiration is + -- present in the KDCDHKeyInfo. + } + + KDCDHKeyInfo ::= SEQUENCE { + subjectPublicKey [0] BIT STRING, + -- KDC's DH public key. + -- The DH public key value is encoded as a BIT + -- STRING according to [RFC3279]. + nonce [1] INTEGER (0..4294967295), + -- Contains the nonce in the PKAuthenticator of the + -- request if DH keys are NOT reused, + -- 0 otherwise. + dhKeyExpiration [2] KerberosTime OPTIONAL, + -- Expiration time for KDC's key pair, + -- present if and only if DH keys are reused. If + -- this field is omitted then the serverDHNonce + -- field MUST also be omitted. See Section 3.2.3.1. + ... + + + +Tung & Zhu Expires March 16, 2006 [Page 15] + +Internet-Draft PKINIT September 2005 + + + } + +3.2.3.1. Using Diffie-Hellman Key Exchange + + In this case, the PA-PK-AS-REP contains a DHRepInfo structure. + + The ContentInfo [RFC3852] structure for the dhSignedData field is + filled in as follows: + + 1. The contentType field of the type ContentInfo is id-signedData + (as defined in [RFC3852]), and the content field is a SignedData + (as defined in [RFC3852]). + + 2. The eContentType field for the type SignedData is the OID value + for id-pkdhkeydata: { iso(1) org(3) dod(6) internet(1) + security(5) kerberosv5(2) pkinit(3) pkdhkeydata(2) }. + + 3. The eContent field for the type SignedData contains the DER + encoding of the type KDCDHKeyInfo. + + 4. The signerInfos field of the type SignedData contains a single + signerInfo, which contains the signature over the type + KDCDHKeyInfo. + + 5. The certificates field of the type SignedData contains + certificates intended to facilitate certification path + construction, so that the client can verify the KDC's signature + over the type KDCDHKeyInfo. The information contained in the + trustedCertifiers in the request SHOULD be used by the KDC as + hints to guide its selection of an appropriate certificate chain + to return to the client. This field may only. be left empty if + the KDC public key specified by the kdcPkId field in the PA-PK- + AS-REQ was used for signing. Otherwise, for path validation, + these certificates SHOULD be sufficient to construct at least one + certification path from the KDC certificate to one trust anchor + acceptable by the client [CAPATH]. The KDC MUST be capable of + including such a set of certificates if configured to do so. The + certificates field MUST NOT contain "root" CA certificates. + + 6. If the client included the clientDHNonce field, then the KDC may + choose to reuse its DH keys (see Section 3.2.3.1). If the server + reuses DH keys then it MUST include an expiration time in the + dhKeyExpiration field. Past the point of the expiration time, + the signature over the type DHRepInfo is considered expired/ + invalid. When the server reuses DH keys then it MUST include a + serverDHNonce at least as long as the length of keys for the + symmetric encryption system used to encrypt the AS reply. Note + that including the serverDHNonce changes how the client and + + + +Tung & Zhu Expires March 16, 2006 [Page 16] + +Internet-Draft PKINIT September 2005 + + + server calculate the key to use to encrypt the reply; see below + for details. The KDC SHOULD NOT reuse DH keys unless the + clientDHNonce field is present in the request. + + The AS reply key is derived as follows: + + 1. Both the KDC and the client calculate the shared secret value as + follows: + + a) When MODP Diffie-Hellman is used, let DHSharedSecret be the + shared secret value. DHSharedSecret is the value ZZ as + described in Section 2.1.1 of [RFC2631]. + + DHSharedSecret is first padded with leading zeros such that the + size of DHSharedSecret in octets is the same as that of the + modulus, then represented as a string of octets in big-endian + order. + + Implementation note: Both the client and the KDC can cache the + triple (ya, yb, DHSharedSecret), where ya is the client's public + key and yb is the KDC's public key. If both ya and yb are the + same in a later exchange, the cached DHSharedSecret can be used. + + 2. Let K be the key-generation seed length [RFC3961] of the AS reply + key whose enctype is selected according to [RFC4120]. + + 3. Define the function octetstring2key() as follows: + + octetstring2key(x) == random-to-key(K-truncate( + SHA1(0x00 | x) | + SHA1(0x01 | x) | + SHA1(0x02 | x) | + ... + )) + + where x is an octet string; | is the concatenation operator; 0x00, + 0x01, 0x02, etc., are each represented as a single octet; random- + to-key() is an operation that generates a protocol key from a + bitstring of length K; and K-truncate truncates its input to the + first K bits. Both K and random-to-key() are as defined in the + kcrypto profile [RFC3961] for the enctype of the AS reply key. + + 4. When DH keys are reused, let n_c be the clientDHNonce, and n_k be + the serverDHNonce; otherwise, let both n_c and n_k be empty octet + strings. + + + + + + +Tung & Zhu Expires March 16, 2006 [Page 17] + +Internet-Draft PKINIT September 2005 + + + 5. The AS reply key k is: + + k = octetstring2key(DHSharedSecret | n_c | n_k) + +3.2.3.2. Using Public Key Encryption + + In this case, the PA-PK-AS-REP contains a ContentInfo structure + wrapped in an OCTET STRING. The AS reply key is encrypted in the + encKeyPack field, which contains data of type ReplyKeyPack: + + ReplyKeyPack ::= SEQUENCE { + replyKey [0] EncryptionKey, + -- Contains the session key used to encrypt the + -- enc-part field in the AS-REP. + asChecksum [1] Checksum, + -- Contains the checksum of the AS-REQ + -- corresponding to the containing AS-REP. + -- The checksum is performed over the type AS-REQ. + -- The protocol key [RFC3961] of the checksum is the + -- replyKey and the key usage number is 6. + -- If the replyKey's enctype is "newer" [RFC4120] + -- [RFC4121], the checksum is the required + -- checksum operation [RFC3961] for that enctype. + -- The client MUST verify this checksum upon receipt + -- of the AS-REP. + ... + } + + The ContentInfo [RFC3852] structure for the encKeyPack field is + filled in as follows: + + 1. The contentType field of the type ContentInfo is id-envelopedData + (as defined in [RFC3852]), and the content field is an + EnvelopedData (as defined in [RFC3852]). + + 2. The contentType field for the type EnvelopedData is id- + signedData: { iso (1) member-body (2) us (840) rsadsi (113549) + pkcs (1) pkcs7 (7) signedData (2) }. + + 3. The eContentType field for the inner type SignedData (when + decrypted from the encryptedContent field for the type + EnvelopedData) is id-pkrkeydata: { iso(1) org(3) dod(6) + internet(1) security(5) kerberosv5(2) pkinit(3) pkrkeydata(3) }. + + 4. The eContent field for the inner type SignedData contains the DER + encoding of the type ReplyKeyPack. + + + + + +Tung & Zhu Expires March 16, 2006 [Page 18] + +Internet-Draft PKINIT September 2005 + + + 5. The signerInfos field of the inner type SignedData contains a + single signerInfo, which contains the signature over the type + ReplyKeyPack. + + 6. The certificates field of the inner type SignedData contains + certificates intended to facilitate certification path + construction, so that the client can verify the KDC's signature + over the type ReplyKeyPack. The information contained in the + trustedCertifiers in the request SHOULD be used by the KDC as + hints to guide its selection of an appropriate certificate chain + to return to the client. This field may only be left empty if + the KDC public key specified by the kdcPkId field in the PA-PK- + AS-REQ was used for signing. Otherwise, for path validation, + these certificates SHOULD be sufficient to construct at least one + certification path from the KDC certificate to one trust anchor + acceptable by the client [CAPATH]. The KDC MUST be capable of + including such a set of certificates if configured to do so. The + certificates field MUST NOT contain "root" CA certificates. + + 7. The recipientInfos field of the type EnvelopedData is a SET which + MUST contain exactly one member of type KeyTransRecipientInfo. + The encryptedKey of this member contains the temporary key which + is encrypted using the client's public key. + + 8. The unprotectedAttrs or originatorInfo fields of the type + EnvelopedData MAY be present. + + Implementations of this RSA encryption key delivery method are + RECOMMENDED to support for RSA keys at least 2048 bits in size. + +3.2.4. Receipt of KDC Reply + + Upon receipt of the KDC's reply, the client proceeds as follows. If + the PA-PK-AS-REP contains the dhSignedData field, the client derives + the AS reply key using the same procedure used by the KDC as defined + in Section 3.2.3.1. Otherwise, the message contains the encKeyPack + field, and the client decrypts and extracts the temporary key in the + encryptedKey field of the member KeyTransRecipientInfo, and then uses + that as the AS reply key. + + If the public key encrytion method is used, the client MUST verify + the asChecksum contained in the ReplyKeyPack. + + In either case, the client MUST verify the signature in the + SignedData according to [RFC3852]. The KDC's X.509 certificate MUST + be validated according to [RFC3280]. In addition, unless the client + can otherwise verify that the public key used to verify the KDC's + signature is bound to the KDC of the target realm, the KDC's X.509 + + + +Tung & Zhu Expires March 16, 2006 [Page 19] + +Internet-Draft PKINIT September 2005 + + + certificate MUST contain a Subject Alternative Name extension + [RFC3280] carrying an AnotherName whose type-id is id-pksan (as + defined in Section 3.2.2) and whose value is a KRB5PrincipalName that + matches the name of the TGS of the target realm (as defined in + Section 7.3 of [RFC4120]). + + Unless the client knows by some other means that the KDC certificate + is intended for a Kerberos KDC, the client MUST require that the KDC + certificate contains the EKU KeyPurposeId [RFC3280] id-pkkdcekuoid: + + id-pkkdcekuoid OBJECT IDENTIFIER ::= + { iso(1) org(3) dod(6) internet(1) security(5) kerberosv5(2) + pkinit(3) pkkdcekuoid(5) } + -- Signing KDC responses. + -- Key usage bits that MUST be consistent: + -- digitalSignature. + + If the KDC certificate contains the Kerberos TGS name encoded as an + id-pksan SAN, this certificate is certified by the issuing CA as a + KDC certificate, therefore the id-pkkdcekuoid EKU is not required. + + If all applicable checks are satisfied, the client then decrypts the + enc-part field of the KDC-REP in the AS-REP using the AS reply key, + and then proceeds as described in [RFC4120]. + + Implementation note: CAs issuing KDC certificates SHOULD place all + "short" and "fully-qualified" Kerberos realm names of the KDC (one + per GeneralName [RFC3280]) into the KDC certificate to allow maximum + flexibility. + +3.3. Interoperability Requirements + + The client MUST be capable of sending a set of certificates + sufficient to allow the KDC to construct a certification path for the + client's certificate, if the correct set of certificates is provided + through configuration or policy. + + If the client sends all the X.509 certificates on a certification + path to a trust anchor acceptable by the KDC, and the KDC can not + verify the client's public key otherwise, the KDC MUST be able to + process path validation for the client's certificate based on the + certificates in the request. + + The KDC MUST be capable of sending a set of certificates sufficient + to allow the client to construct a certification path for the KDC's + certificate, if the correct set of certificates is provided through + configuration or policy. + + + + +Tung & Zhu Expires March 16, 2006 [Page 20] + +Internet-Draft PKINIT September 2005 + + + If the KDC sends all the X.509 certificates on a certification path + to a trust anchor acceptable by the client, and the client can not + verify the KDC's public key otherwise, the client MUST be able to + process path validation for the KDC's certificate based on the + certificates in the reply. + +3.4. KDC Indication of PKINIT Support + + If pre-authentication is required, but was not present in the + request, per [RFC4120] an error message with the code + KDC_ERR_PREAUTH_FAILED is returned and a METHOD-DATA object will be + stored in the e-data field of the KRB-ERROR message to specify which + pre-authentication mechanisms are acceptable. The KDC can then + indicate the support of PKINIT by including an empty element whose + padata-type is PA_PK_AS_REQ in that METHOD-DATA object. + + Otherwise if it is required by the KDC's local policy that the client + must be pre-authenticated using the pre-authentication mechanism + specified in this document, but no PKINIT pre-authentication was + present in the request, an error message with the code + KDC_ERR_PREAUTH_FAILED SHOULD be returned. + + KDCs MUST leave the padata-value field of the PA_PK_AS_REQ element in + the KRB-ERROR's METHOD-DATA empty (i.e., send a zero-length OCTET + STRING), and clients MUST ignore this and any other value. Future + extensions to this protocol may specify other data to send instead of + an empty OCTET STRING. + + +4. Security Considerations + + The symmetric reply key size and Diffie-Hellman field size or RSA + modulus size should be chosen so as to provide sufficient + cryptographic security [RFC3766]. + + When MODP Diffie-Hellman is used, the exponents should have at least + twice as many bits as the symmetric keys that will be derived from + them [ODL99]. + + PKINIT raises certain security considerations beyond those that can + be regulated strictly in protocol definitions. We will address them + in this section. + + PKINIT extends the cross-realm model to the public-key + infrastructure. Users of PKINIT must understand security policies + and procedures appropriate to the use of Public Key Infrastructures + [RFC3280]. + + + + +Tung & Zhu Expires March 16, 2006 [Page 21] + +Internet-Draft PKINIT September 2005 + + + In order to trust a KDC certificate that is certified by a CA as a + KDC certificate for a target realm (for example, by asserting the TGS + name of that Kerberos realm as an id-pksan SAN and/or restricting the + certificate usage by using the id-pkkdcekuoid EKU, as described in + Section 3.2.4), the client MUST verify that the KDC certificate's + issuing CA is authorized to issue KDC certificates for that target + realm. Otherwise, the binding between the KDC certificate and the + KDC of the target realm is not established. + + How to validate this authorization is a matter of local policy. A + way to achieve this is the configuration of specific sets of + intermediary CAs and trust anchors, one of which must be on the KDC + certificate's certification path [RFC3280]; and for each CA or trust + anchor the realms for which it is allowed to issue certificates. + + In addition, if any CA is trusted to issue KDC certificates can also + issue other kinds of certificates, then local policy must be able to + distinguish between them: for example, it could require that KDC + certificates contain the id-pkkdcekuoid EKU or that the realm be + specified with the id-pksan SAN. + + It is the responsibility of the PKI administrators for an + organization to ensure that KDC certificates are only issued to KDCs, + and that clients can ascertain this using their local policy. + + Standard Kerberos allows the possibility of interactions between + cryptosystems of varying strengths; this document adds interactions + with public-key cryptosystems to Kerberos. Some administrative + policies may allow the use of relatively weak public keys. Using + such keys to wrap data encrypted under stronger conventional + cryptosystems may be inappropriate. + + PKINIT requires keys for symmetric cryptosystems to be generated. + Some such systems contain "weak" keys. For recommendations regarding + these weak keys, see [RFC4120]. + + PKINIT allows the use of the same RSA key pair for encryption and + signing when doing RSA encryption based key delivery. This is not + recommended usage of RSA keys [RFC3447], by using DH based key + delivery this is avoided. + + Care should be taken in how certificates are chosen for the purposes + of authentication using PKINIT. Some local policies may require that + key escrow be used for certain certificate types. Deployers of + PKINIT should be aware of the implications of using certificates that + have escrowed keys for the purposes of authentication. Because + signing only certificates are normally not escrowed, by using DH + based key delivery this is avoided. + + + +Tung & Zhu Expires March 16, 2006 [Page 22] + +Internet-Draft PKINIT September 2005 + + + PKINIT does not provide for a "return routability" test to prevent + attackers from mounting a denial-of-service attack on the KDC by + causing it to perform unnecessary and expensive public-key + operations. Strictly speaking, this is also true of standard + Kerberos, although the potential cost is not as great, because + standard Kerberos does not make use of public-key cryptography. By + using DH based key delivery and reusing DH keys, the necessary crypto + processing cost per request can be minimized. + + The syntax for the AD-INITIAL-VERIFIED-CAS authorization data does + permit empty SEQUENCEs to be encoded. Such empty sequences may only + be used if the KDC itself vouches for the user's certificate. + + +5. Acknowledgements + + The following people have made significant contributions to this + draft: Paul Leach, Kristin Lauter, Sam Hartman, Love Hornquist + Astrand, Ken Raeburn, Nicolas Williams, John Wray, Jonathan Trostle, + Tom Yu, Jeffrey Hutzelman, David Cross, Dan Simon, Karthik + Jaganathan, Chaskiel M Grundman, Stefan Santesson, Andre Scedrov and + Aaron D. Jaggard. + + Special thanks to Clifford Neuman, Matthew Hur, Sasha Medvinsky and + Jonathan Trostle who wrote earlier versions of this document. + + The authors are indebted to the Kerberos working group chair Jeffrey + Hutzelman who kept track of various issues and was enormously helpful + during the creation of this document. + + Some of the ideas on which this document is based arose during + discussions over several years between members of the SAAG, the IETF + CAT working group, and the PSRG, regarding integration of Kerberos + and SPX. Some ideas have also been drawn from the DASS system. + These changes are by no means endorsed by these groups. This is an + attempt to revive some of the goals of those groups, and this + document approaches those goals primarily from the Kerberos + perspective. + + Lastly, comments from groups working on similar ideas in DCE have + been invaluable. + + +6. IANA Considerations + + This document has no actions for IANA. + + + + + +Tung & Zhu Expires March 16, 2006 [Page 23] + +Internet-Draft PKINIT September 2005 + + +7. References + +7.1. Normative References + + [IEEE1363] + IEEE, "Standard Specifications for Public Key + Cryptography", IEEE 1363, 2000. + + [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, March 1997. + + [RFC2412] Orman, H., "The OAKLEY Key Determination Protocol", + RFC 2412, November 1998. + + [RFC2631] Rescorla, E., "Diffie-Hellman Key Agreement Method", + RFC 2631, June 1999. + + [RFC3279] Bassham, L., Polk, W., and R. Housley, "Algorithms and + Identifiers for the Internet X.509 Public Key + Infrastructure Certificate and Certificate Revocation List + (CRL) Profile", RFC 3279, April 2002. + + [RFC3280] Housley, R., Polk, W., Ford, W., and D. Solo, "Internet + X.509 Public Key Infrastructure Certificate and + Certificate Revocation List (CRL) Profile", RFC 3280, + April 2002. + + [RFC3370] Housley, R., "Cryptographic Message Syntax (CMS) + Algorithms", RFC 3370, August 2002. + + [RFC3447] Jonsson, J. and B. Kaliski, "Public-Key Cryptography + Standards (PKCS) #1: RSA Cryptography Specifications + Version 2.1", RFC 3447, February 2003. + + [RFC3526] Kivinen, T. and M. Kojo, "More Modular Exponential (MODP) + Diffie-Hellman groups for Internet Key Exchange (IKE)", + RFC 3526, May 2003. + + [RFC3565] Schaad, J., "Use of the Advanced Encryption Standard (AES) + Encryption Algorithm in Cryptographic Message Syntax + (CMS)", RFC 3565, July 2003. + + [RFC3766] Orman, H. and P. Hoffman, "Determining Strengths For + Public Keys Used For Exchanging Symmetric Keys", BCP 86, + RFC 3766, April 2004. + + [RFC3852] Housley, R., "Cryptographic Message Syntax (CMS)", + RFC 3852, July 2004. + + + +Tung & Zhu Expires March 16, 2006 [Page 24] + +Internet-Draft PKINIT September 2005 + + + [RFC3961] Raeburn, K., "Encryption and Checksum Specifications for + Kerberos 5", RFC 3961, February 2005. + + [RFC3962] Raeburn, K., "Advanced Encryption Standard (AES) + Encryption for Kerberos 5", RFC 3962, February 2005. + + [RFC4120] Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The + Kerberos Network Authentication Service (V5)", RFC 4120, + July 2005. + + [RFC4121] Zhu, L., Jaganathan, K., and S. Hartman, "The Kerberos + Version 5 Generic Security Service Application Program + Interface (GSS-API) Mechanism: Version 2", RFC 4121, + July 2005. + + [X.509-97] ITU-T. Recommendation X.509: The Directory - Authentication + Framework. 1997. + + [X690] ASN.1 encoding rules: Specification of Basic Encoding + Rules (BER), Canonical Encoding Rules (CER) and + Distinguished Encoding Rules (DER), ITU-T Recommendation + X.690 (1997) | ISO/IEC International Standard + 8825-1:1998. + +7.2. Informative References + + [CAPATH] RFC-Editor: To be replaced by RFC number for draft-ietf- + pkix-certpathbuild. Work in Progress. + + [LENSTRA] Lenstra, A. and E. Verheul, "Selecting Cryptographic Key + Sizes", Journal of Cryptology 14 (2001) 255-293. + + [ODL99] Odlyzko, A., "Discrete logarithms: The past and the + future, Designs, Codes, and Cryptography (1999)". + +Appendix A. PKINIT ASN.1 Module + + KerberosV5-PK-INIT-SPEC { + iso(1) identified-organization(3) dod(6) internet(1) + security(5) kerberosV5(2) modules(4) pkinit(5) + } DEFINITIONS EXPLICIT TAGS ::= BEGIN + + IMPORTS + + + +Tung & Zhu Expires March 16, 2006 [Page 25] + +Internet-Draft PKINIT September 2005 + + + SubjectPublicKeyInfo, AlgorithmIdentifier + FROM PKIX1Explicit88 { iso (1) + identified-organization (3) dod (6) internet (1) + security (5) mechanisms (5) pkix (7) id-mod (0) + id-pkix1-explicit (18) } + -- As defined in RFC 3280. + + KerberosTime, PrincipalName, Realm, EncryptionKey + FROM KerberosV5Spec2 { iso(1) identified-organization(3) + dod(6) internet(1) security(5) kerberosV5(2) + modules(4) krb5spec2(2) } ; + + id-pkinit OBJECT IDENTIFIER ::= + { iso (1) org (3) dod (6) internet (1) security (5) + kerberosv5 (2) pkinit (3) } + + id-pkauthdata OBJECT IDENTIFIER ::= { id-pkinit 1 } + id-pkdhkeydata OBJECT IDENTIFIER ::= { id-pkinit 2 } + id-pkrkeydata OBJECT IDENTIFIER ::= { id-pkinit 3 } + id-pkekuoid OBJECT IDENTIFIER ::= { id-pkinit 4 } + id-pkkdcekuoid OBJECT IDENTIFIER ::= { id-pkinit 5 } + + id-pksan OBJECT IDENTIFIER ::= + { iso(1) org(3) dod(6) internet(1) security(5) kerberosv5(2) + x509-sanan (2) } + + pa-pk-as-req INTEGER ::= 16 + pa-pk-as-rep INTEGER ::= 17 + + ad-initial-verified-cas INTEGER ::= 9 + + td-trusted-certifiers INTEGER ::= 104 + td-invalid-certificates INTEGER ::= 105 + td-dh-parameters INTEGER ::= 109 + + PA-PK-AS-REQ ::= SEQUENCE { + signedAuthPack [0] IMPLICIT OCTET STRING, + -- Contains a CMS type ContentInfo encoded + -- according to [RFC3852]. + -- The contentType field of the type ContentInfo + -- is id-signedData (1.2.840.113549.1.7.2), + -- and the content field is a SignedData. + -- The eContentType field for the type SignedData is + -- id-pkauthdata (1.3.6.1.5.2.3.1), and the + -- eContent field contains the DER encoding of the + -- type AuthPack. + -- AuthPack is defined below. + trustedCertifiers [1] SEQUENCE OF + + + +Tung & Zhu Expires March 16, 2006 [Page 26] + +Internet-Draft PKINIT September 2005 + + + ExternalPrincipalIdentifier OPTIONAL, + -- A list of CAs, trusted by the client, that can + -- be used to certify the KDC. + -- Each ExternalPrincipalIdentifier identifies a CA + -- or a CA certificate (thereby its public key). + -- The information contained in the + -- trustedCertifiers SHOULD be used by the KDC as + -- hints to guide its selection of an appropriate + -- certificate chain to return to the client. + kdcPkId [2] IMPLICIT OCTET STRING + OPTIONAL, + -- Contains a CMS type SignerIdentifier encoded + -- according to [RFC3852]. + -- Identifies, if present, a particular KDC + -- public key that the client already has. + ... + } + + DHNonce ::= OCTET STRING + + ExternalPrincipalIdentifier ::= SEQUENCE { + subjectName [0] IMPLICIT OCTET STRING OPTIONAL, + -- Contains a PKIX type Name encoded according to + -- [RFC3280]. + -- Identifies the certificate subject by the + -- distinguished subject name. + -- REQUIRED when there is a distinguished subject + -- name present in the certificate. + issuerAndSerialNumber [1] IMPLICIT OCTET STRING OPTIONAL, + -- Contains a CMS type IssuerAndSerialNumber encoded + -- according to [RFC3852]. + -- Identifies a certificate of the subject. + -- REQUIRED for TD-INVALID-CERTIFICATES and + -- TD-TRUSTED-CERTIFIERS. + subjectKeyIdentifier [2] IMPLICIT OCTET STRING OPTIONAL, + -- Identifies the subject's public key by a key + -- identifier. When an X.509 certificate is + -- referenced, this key identifier matches the X.509 + -- subjectKeyIdentifier extension value. When other + -- certificate formats are referenced, the documents + -- that specify the certificate format and their use + -- with the CMS must include details on matching the + -- key identifier to the appropriate certificate + -- field. + -- RECOMMENDED for TD-TRUSTED-CERTIFIERS. + ... + } + + + + +Tung & Zhu Expires March 16, 2006 [Page 27] + +Internet-Draft PKINIT September 2005 + + + AuthPack ::= SEQUENCE { + pkAuthenticator [0] PKAuthenticator, + clientPublicValue [1] SubjectPublicKeyInfo OPTIONAL, + -- Type SubjectPublicKeyInfo is defined in + -- [RFC3280]. + -- Specifies Diffie-Hellman domain parameters + -- and the client's public key value [IEEE1363]. + -- The DH public key value is encoded as a BIT + -- STRING according to [RFC3279]. + -- This field is present only if the client wishes + -- to use the Diffie-Hellman key agreement method. + supportedCMSTypes [2] SEQUENCE OF AlgorithmIdentifier + OPTIONAL, + -- Type AlgorithmIdentifier is defined in + -- [RFC3280]. + -- List of CMS encryption types supported by the + -- client in order of (decreasing) preference. + clientDHNonce [3] DHNonce OPTIONAL, + -- Present only if the client indicates that it + -- wishes to reuse DH keys or to allow the KDC to + -- do so. + ... + } + + PKAuthenticator ::= SEQUENCE { + cusec [0] INTEGER (0..999999), + ctime [1] KerberosTime, + -- cusec and ctime are used as in [RFC4120], for + -- replay prevention. + nonce [2] INTEGER (0..4294967295), + -- Chosen randomly; This nonce does not need to + -- match with the nonce in the KDC-REQ-BODY. + paChecksum [3] OCTET STRING, + -- Contains the SHA1 checksum, performed over + -- KDC-REQ-BODY. + ... + } + + TD-TRUSTED-CERTIFIERS ::= SEQUENCE OF + ExternalPrincipalIdentifier + -- Identifies a list of CAs trusted by the KDC. + -- Each ExternalPrincipalIdentifier identifies a CA + -- or a CA certificate (thereby its public key). + + TD-INVALID-CERTIFICATES ::= SEQUENCE OF + ExternalPrincipalIdentifier + -- Each ExternalPrincipalIdentifier identifies a + -- certificate (sent by the client) with an invalid + + + +Tung & Zhu Expires March 16, 2006 [Page 28] + +Internet-Draft PKINIT September 2005 + + + -- signature. + + KRB5PrincipalName ::= SEQUENCE { + realm [0] Realm, + principalName [1] PrincipalName + } + + AD-INITIAL-VERIFIED-CAS ::= SEQUENCE OF + ExternalPrincipalIdentifier + -- Identifies the certification path based on which + -- the client certificate was validated. + -- Each ExternalPrincipalIdentifier identifies a CA + -- or a CA certificate (thereby its public key). + + PA-PK-AS-REP ::= CHOICE { + dhInfo [0] DHRepInfo, + -- Selected when Diffie-Hellman key exchange is + -- used. + encKeyPack [1] IMPLICIT OCTET STRING, + -- Selected when public key encryption is used. + -- Contains a CMS type ContentInfo encoded + -- according to [RFC3852]. + -- The contentType field of the type ContentInfo is + -- id-envelopedData (1.2.840.113549.1.7.3). + -- The content field is an EnvelopedData. + -- The contentType field for the type EnvelopedData + -- is id-signedData (1.2.840.113549.1.7.2). + -- The eContentType field for the inner type + -- SignedData (when unencrypted) is id-pkrkeydata + -- (1.2.840.113549.1.7.3) and the eContent field + -- contains the DER encoding of the type + -- ReplyKeyPack. + -- ReplyKeyPack is defined below. + ... + } + + DHRepInfo ::= SEQUENCE { + dhSignedData [0] IMPLICIT OCTET STRING, + -- Contains a CMS type ContentInfo encoded according + -- to [RFC3852]. + -- The contentType field of the type ContentInfo is + -- id-signedData (1.2.840.113549.1.7.2), and the + -- content field is a SignedData. + -- The eContentType field for the type SignedData is + -- id-pkdhkeydata (1.3.6.1.5.2.3.2), and the + -- eContent field contains the DER encoding of the + -- type KDCDHKeyInfo. + -- KDCDHKeyInfo is defined below. + + + +Tung & Zhu Expires March 16, 2006 [Page 29] + +Internet-Draft PKINIT September 2005 + + + serverDHNonce [1] DHNonce OPTIONAL + -- Present if and only if dhKeyExpiration is + -- present. + } + + KDCDHKeyInfo ::= SEQUENCE { + subjectPublicKey [0] BIT STRING, + -- KDC's DH public key. + -- The DH public key value is encoded as a BIT + -- STRING according to [RFC3279]. + nonce [1] INTEGER (0..4294967295), + -- Contains the nonce in the PKAuthenticator of the + -- request if DH keys are NOT reused, + -- 0 otherwise. + dhKeyExpiration [2] KerberosTime OPTIONAL, + -- Expiration time for KDC's key pair, + -- present if and only if DH keys are reused. If + -- this field is omitted then the serverDHNonce + -- field MUST also be omitted. + ... + } + + ReplyKeyPack ::= SEQUENCE { + replyKey [0] EncryptionKey, + -- Contains the session key used to encrypt the + -- enc-part field in the AS-REP. + asChecksum [1] Checksum, + -- Contains the checksum of the AS-REQ + -- corresponding to the containing AS-REP. + -- The checksum is performed over the type AS-REQ. + -- The protocol key [RFC3961] of the checksum is the + -- replyKey and the key usage number is 6. + -- If the replyKey's enctype is "newer" [RFC4120] + -- [RFC4121], the checksum is the required + -- checksum operation [RFC3961] for that enctype. + -- The client MUST verify this checksum upon receipt + -- of the AS-REP. + ... + } + + TD-DH-PARAMETERS ::= SEQUENCE OF AlgorithmIdentifier + -- Each AlgorithmIdentifier specifies a set of + -- Diffie-Hellman domain parameters [IEEE1363]. + -- This list is in decreasing preference order. + END + + + + + + +Tung & Zhu Expires March 16, 2006 [Page 30] + +Internet-Draft PKINIT September 2005 + + +Appendix B. Test Vectors + + Function octetstring2key() is defined in Section 3.2.3.1. This + section describes a few sets of test vectors that would be useful for + implementers of octetstring2key(). + + + Set 1 + ===== + Input octet string x is: + + 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 + 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 + 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 + 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 + 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 + 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 + 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 + 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 + 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 + 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 + 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 + 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 + 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 + 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 + 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 + 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 + + Output of K-truncate() when the key size is 32 octets: + + 5e e5 0d 67 5c 80 9f e5 9e 4a 77 62 c5 4b 65 83 + 75 47 ea fb 15 9b d8 cd c7 5f fc a5 91 1e 4c 41 + + + Set 2: + ===== + Input octet string x is: + + 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 + 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 + 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 + 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 + 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 + 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 + 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 + 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 + + Output of K-truncate() when the key size is 32 octets: + + + +Tung & Zhu Expires March 16, 2006 [Page 31] + +Internet-Draft PKINIT September 2005 + + + ac f7 70 7c 08 97 3d df db 27 cd 36 14 42 cc fb + a3 55 c8 88 4c b4 72 f3 7d a6 36 d0 7d 56 78 7e + + + Set 3: + ====== + Input octet string x is: + + 00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f + 10 00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e + 0f 10 00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d + 0e 0f 10 00 01 02 03 04 05 06 07 08 09 0a 0b 0c + 0d 0e 0f 10 00 01 02 03 04 05 06 07 08 09 0a 0b + 0c 0d 0e 0f 10 00 01 02 03 04 05 06 07 08 09 0a + 0b 0c 0d 0e 0f 10 00 01 02 03 04 05 06 07 08 09 + 0a 0b 0c 0d 0e 0f 10 00 01 02 03 04 05 06 07 08 + + Output of K-truncate() when the key size is 32 octets: + + c4 42 da 58 5f cb 80 e4 3b 47 94 6f 25 40 93 e3 + 73 29 d9 90 01 38 0d b7 83 71 db 3a cf 5c 79 7e + + + Set 4: + ===== + Input octet string x is: + + 00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f + 10 00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e + 0f 10 00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d + 0e 0f 10 00 01 02 03 04 05 06 07 08 09 0a 0b 0c + 0d 0e 0f 10 00 01 02 03 04 05 06 07 08 + + Output of K-truncate() when the key size is 32 octets: + + 00 53 95 3b 84 c8 96 f4 eb 38 5c 3f 2e 75 1c 4a + 59 0e d6 ff ad ca 6f f6 4f 47 eb eb 8d 78 0f fc + + + + + + + + + + + + + + +Tung & Zhu Expires March 16, 2006 [Page 32] + +Internet-Draft PKINIT September 2005 + + +Authors' Addresses + + Brian Tung + USC Information Sciences Institute + 4676 Admiralty Way Suite 1001, Marina del Rey CA + Marina del Rey, CA 90292 + US + + Email: brian@isi.edu + + + Larry Zhu + Microsoft Corporation + One Microsoft Way + Redmond, WA 98052 + US + + Email: lzhu@microsoft.com + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Tung & Zhu Expires March 16, 2006 [Page 33] + +Internet-Draft PKINIT September 2005 + + +Intellectual Property Statement + + The IETF takes no position regarding the validity or scope of any + Intellectual Property Rights or other rights that might be claimed to + pertain to the implementation or use of the technology described in + this document or the extent to which any license under such rights + might or might not be available; nor does it represent that it has + made any independent effort to identify any such rights. Information + on the procedures with respect to rights in RFC documents can be + found in BCP 78 and BCP 79. + + Copies of IPR disclosures made to the IETF Secretariat and any + assurances of licenses to be made available, or the result of an + attempt made to obtain a general license or permission for the use of + such proprietary rights by implementers or users of this + specification can be obtained from the IETF on-line IPR repository at + http://www.ietf.org/ipr. + + The IETF invites any interested party to bring to its attention any + copyrights, patents or patent applications, or other proprietary + rights that may cover technology that may be required to implement + this standard. Please address the information to the IETF at + ietf-ipr@ietf.org. + + +Disclaimer of Validity + + This document and the information contained herein are provided on an + "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS + OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET + ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, + INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE + INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED + WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. + + +Copyright Statement + + Copyright (C) The Internet Society (2005). This document is subject + to the rights, licenses and restrictions contained in BCP 78, and + except as set forth therein, the authors retain all their rights. + + +Acknowledgment + + Funding for the RFC Editor function is currently provided by the + Internet Society. + + + + +Tung & Zhu Expires March 16, 2006 [Page 34] + + diff --git a/doc/standardisation/draft-ietf-cat-kerberos-pk-init-29.txt b/doc/standardisation/draft-ietf-cat-kerberos-pk-init-29.txt index 71a26c3eb..1c70b1804 100644 --- a/doc/standardisation/draft-ietf-cat-kerberos-pk-init-29.txt +++ b/doc/standardisation/draft-ietf-cat-kerberos-pk-init-29.txt @@ -1,6 +1,3 @@ - - - NETWORK WORKING GROUP B. Tung Internet-Draft USC Information Sciences Institute Expires: April 22, 2006 L. Zhu diff --git a/doc/standardisation/draft-ietf-cat-kerberos-pk-init-30.txt b/doc/standardisation/draft-ietf-cat-kerberos-pk-init-30.txt new file mode 100644 index 000000000..ca5205a65 --- /dev/null +++ b/doc/standardisation/draft-ietf-cat-kerberos-pk-init-30.txt @@ -0,0 +1,2183 @@ +NETWORK WORKING GROUP L. Zhu +Internet-Draft Microsoft Corporation +Expires: June 2, 2006 B. Tung + USC Information Sciences Institute + November 29, 2005 + + + Public Key Cryptography for Initial Authentication in Kerberos + draft-ietf-cat-kerberos-pk-init-30 + +Status of this Memo + + By submitting this Internet-Draft, each author represents that any + applicable patent or other IPR claims of which he or she is aware + have been or will be disclosed, and any of which he or she becomes + aware will be disclosed, in accordance with Section 6 of BCP 79. + + Internet-Drafts are working documents of the Internet Engineering + Task Force (IETF), its areas, and its working groups. Note that + other groups may also distribute working documents as Internet- + Drafts. + + Internet-Drafts are draft documents valid for a maximum of six months + and may be updated, replaced, or obsoleted by other documents at any + time. It is inappropriate to use Internet-Drafts as reference + material or to cite them other than as "work in progress." + + The list of current Internet-Drafts can be accessed at + http://www.ietf.org/ietf/1id-abstracts.txt. + + The list of Internet-Draft Shadow Directories can be accessed at + http://www.ietf.org/shadow.html. + + This Internet-Draft will expire on June 2, 2006. + +Copyright Notice + + Copyright (C) The Internet Society (2005). + +Abstract + + This document describes protocol extensions (hereafter called PKINIT) + to the Kerberos protocol specification. These extensions provide a + method for integrating public key cryptography into the initial + authentication exchange, by using asymmetric-key signature and/or + encryption algorithms in pre-authentication data fields. + + + + + +Zhu & Tung Expires June 2, 2006 [Page 1] + +Internet-Draft PKINIT November 2005 + + +Table of Contents + + 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 + 2. Conventions Used in This Document . . . . . . . . . . . . . . 3 + 3. Extensions . . . . . . . . . . . . . . . . . . . . . . . . . . 4 + 3.1. Definitions, Requirements, and Constants . . . . . . . . . 5 + 3.1.1. Required Algorithms . . . . . . . . . . . . . . . . . 5 + 3.1.2. Defined Message and Encryption Types . . . . . . . . . 5 + 3.1.3. Algorithm Identifiers . . . . . . . . . . . . . . . . 6 + 3.2. PKINIT Pre-authentication Syntax and Use . . . . . . . . . 7 + 3.2.1. Generation of Client Request . . . . . . . . . . . . . 7 + 3.2.2. Receipt of Client Request . . . . . . . . . . . . . . 12 + 3.2.3. Generation of KDC Reply . . . . . . . . . . . . . . . 16 + 3.2.4. Receipt of KDC Reply . . . . . . . . . . . . . . . . . 22 + 3.3. Interoperability Requirements . . . . . . . . . . . . . . 24 + 3.4. KDC Indication of PKINIT Support . . . . . . . . . . . . . 24 + 4. Security Considerations . . . . . . . . . . . . . . . . . . . 25 + 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 27 + 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27 + 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 28 + 7.1. Normative References . . . . . . . . . . . . . . . . . . . 28 + 7.2. Informative References . . . . . . . . . . . . . . . . . . 29 + Appendix A. PKINIT ASN.1 Module . . . . . . . . . . . . . . . . . 29 + Appendix B. Test Vectors . . . . . . . . . . . . . . . . . . . . 35 + Appendix C. Miscellaneous Information about Microsoft Windows + PKINIT Implementations . . . . . . . . . . . . . . . 36 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 38 + Intellectual Property and Copyright Statements . . . . . . . . . . 39 + + + + + + + + + + + + + + + + + + + + + + + +Zhu & Tung Expires June 2, 2006 [Page 2] + +Internet-Draft PKINIT November 2005 + + +1. Introduction + + A client typically authenticates itself to a service in Kerberos + using three distinct though related exchanges. First, the client + requests a ticket-granting ticket (TGT) from the Kerberos + authentication server (AS). Then, it uses the TGT to request a + service ticket from the Kerberos ticket-granting server (TGS). + Usually, the AS and TGS are integrated in a single device known as a + Kerberos Key Distribution Center, or KDC. Finally, the client uses + the service ticket to authenticate itself to the service. + + The advantage afforded by the TGT is that the client exposes his + long-term secrets only once. The TGT and its associated session key + can then be used for any subsequent service ticket requests. One + result of this is that all further authentication is independent of + the method by which the initial authentication was performed. + Consequently, initial authentication provides a convenient place to + integrate public-key cryptography into Kerberos authentication. + + As defined in [RFC4120], Kerberos authentication exchanges use + symmetric-key cryptography, in part for performance. One + disadvantage of using symmetric-key cryptography is that the keys + must be shared, so that before a client can authenticate itself, he + must already be registered with the KDC. + + Conversely, public-key cryptography (in conjunction with an + established Public Key Infrastructure) permits authentication without + prior registration with a KDC. Adding it to Kerberos allows the + widespread use of Kerberized applications by clients without + requiring them to register first with a KDC--a requirement that has + no inherent security benefit. + + As noted above, a convenient and efficient place to introduce public- + key cryptography into Kerberos is in the initial authentication + exchange. This document describes the methods and data formats for + integrating public-key cryptography into Kerberos initial + authentication. + + +2. Conventions Used in This Document + + The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", + "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this + document are to be interpreted as described in [RFC2119]. + + Both the AS and the TGS are referred to as the KDC. + + In this document, the encryption key used to encrypt the enc-part + + + +Zhu & Tung Expires June 2, 2006 [Page 3] + +Internet-Draft PKINIT November 2005 + + + field of the KDC-REP in the AS-REP [RFC4120] is referred to as the AS + reply key. + + In this document, an empty sequence in an optional field can be + either included or omitted: both encodings are permitted and + considered equivalent. + + In this document, the term "Modular Exponential Diffie-Hellman" is + used to refer to the Diffie-Hellman key exchange as described in + [RFC2631], in order to differentiate it from other equivalent + representations of the same key agreement algorithm. + + +3. Extensions + + This section describes extensions to [RFC4120] for supporting the use + of public-key cryptography in the initial request for a ticket. + + Briefly, this document defines the following extensions to [RFC4120]: + + 1. The client indicates the use of public-key authentication by + including a special preauthenticator in the initial request. This + preauthenticator contains the client's public-key data and a + signature. + + 2. The KDC tests the client's request against its authentication + policy and trusted Certification Authorities (CAs). + + 3. If the request passes the verification tests, the KDC replies as + usual, but the reply is encrypted using either: + + a. a key generated through a Diffie-Hellman (DH) key exchange + [RFC2631] [IEEE1363] with the client, signed using the KDC's + signature key; or + + b. a symmetric encryption key, signed using the KDC's signature + key and encrypted using the client's public key. + + Any keying material required by the client to obtain the + encryption key for decrypting the KDC reply is returned in a pre- + authentication field accompanying the usual reply. + + 4. The client validates the KDC's signature, obtains the encryption + key, decrypts the reply, and then proceeds as usual. + + Section 3.1 of this document enumerates the required algorithms and + necessary extension message types. Section 3.2 describes the + extension messages in greater detail. + + + +Zhu & Tung Expires June 2, 2006 [Page 4] + +Internet-Draft PKINIT November 2005 + + +3.1. Definitions, Requirements, and Constants + +3.1.1. Required Algorithms + + All PKINIT implementations MUST support the following algorithms: + + o AS reply key enctype: aes128-cts-hmac-sha1-96 and aes256-cts-hmac- + sha1-96 [RFC3962]. + + o Signature algorithm: sha-1WithRSAEncryption [RFC3279]. + + o AS reply key delivery method: Diffie-Hellman key exchange + [RFC2631]. + + In addition, implementations of this specification MUST be capable of + processing the Extended Key Usage (EKU) extension and the id-pkinit- + san (as defined in Section 3.2.2) otherName of the Subject + Alternative Name (SAN) extension in X.509 certificates [RFC3280], if + present. + +3.1.2. Defined Message and Encryption Types + + PKINIT makes use of the following new pre-authentication types: + + PA_PK_AS_REQ 16 + PA_PK_AS_REP 17 + + PKINIT also makes use of the following new authorization data type: + + AD_INITIAL_VERIFIED_CAS 9 + + PKINIT introduces the following new error codes: + + KDC_ERR_CLIENT_NOT_TRUSTED 62 + KDC_ERR_INVALID_SIG 64 + KDC_ERR_DH_KEY_PARAMETERS_NOT_ACCEPTED 65 + KDC_ERR_CANT_VERIFY_CERTIFICATE 70 + KDC_ERR_INVALID_CERTIFICATE 71 + KDC_ERR_REVOKED_CERTIFICATE 72 + KDC_ERR_REVOCATION_STATUS_UNKNOWN 73 + KDC_ERR_CLIENT_NAME_MISMATCH 75 + KDC_ERR_INCONSISTENT_KEY_PURPOSE 76 + KDC_ERR_DIGEST_IN_CERT_NOT_ACCEPTED 77 + KDC_ERR_HASH_IN_KDF_NOT_ACCEPTED 78 + KDC_ERR_DIGEST_IN_SIGNED_DATA_NOT_ACCEPTED 79 + + PKINIT uses the following typed data types for errors: + + + + +Zhu & Tung Expires June 2, 2006 [Page 5] + +Internet-Draft PKINIT November 2005 + + + TD_TRUSTED_CERTIFIERS 104 + TD_INVALID_CERTIFICATES 105 + TD_DH_PARAMETERS 109 + + The ASN.1 module for all structures defined in this document (plus + IMPORT statements for all imported structures) is given in + Appendix A. + + All structures defined in or imported into this document MUST be + encoded using Distinguished Encoding Rules (DER) [X680] [X690] + (unless otherwise noted). All data structures carried in OCTET + STRINGs must be encoded according to the rules specified in + corresponding specifications. + + Interoperability note: Some implementations may not be able to decode + wrapped CMS objects encoded with BER but not DER; specifically, they + may not be able to decode indefinite length encodings. To maximize + interoperability, implementers SHOULD encode CMS objects used in + PKINIT with DER. + +3.1.3. Algorithm Identifiers + + PKINIT does not define, but does make use of, the following algorithm + identifiers. + + PKINIT uses the following algorithm identifier(s) for Modular + Exponential Diffie-Hellman key agreement [RFC2631] [RFC3279]: + + dhpublicnumber (as described in [RFC3279]) + + PKINIT uses the following signature algorithm identifiers as defined + in [RFC3279]: + + sha-1WithRSAEncryption (RSA with SHA1) + md5WithRSAEncryption (RSA with MD5) + id-dsa-with-sha1 (DSA with SHA1) + + PKINIT uses the following encryption algorithm identifiers as defined + in [RFC3447] for encrypting the temporary key with a public key: + + rsaEncryption + id-RSAES-OAEP + + PKINIT uses the following algorithm identifiers [RFC3370] [RFC3565] + for encrypting the AS reply key with the temporary key: + + des-ede3-cbc (three-key 3DES, CBC mode, as defined in [RFC3370]) + rc2-cbc (RC2, CBC mode, as defined in [RFC3370]) + + + +Zhu & Tung Expires June 2, 2006 [Page 6] + +Internet-Draft PKINIT November 2005 + + + id-aes256-CBC (AES-256, CBC mode, as defined in [RFC3565]) + + PKINIT defines the following encryption types, for use in the etype + field of the AS-REQ [RFC4120] message to indicate acceptance of the + corresponding algorithms that can used by Cryptographic Message + Syntax (CMS) [RFC3852] messages in the reply: + + id-dsa-with-sha1-CmsOID 9 + -- Indicates that the client supports id-dsa-with-sha1. + md5WithRSAEncryption-CmsOID 10 + -- Indicates that the client supports md5WithRSAEncryption. + sha-1WithRSAEncryption-CmsOID 11 + -- Indicates that the client supports sha-1WithRSAEncryption. + rc2-cbc-EnvOID 12 + -- Indicates that the client supports rc2-cbc. + rsaEncryption-EnvOID 13 + -- Indicates that the client supports rsaEncryption. + id-RSAES-OAEP-EnvOID 14 + -- Indicates that the client supports id-RSAES-OAEP. + des-ede3-cbc-EnvOID 15 + -- Indicates that the client supports des-ede3-cbc. + +3.2. PKINIT Pre-authentication Syntax and Use + + This section defines the syntax and use of the various pre- + authentication fields employed by PKINIT. + +3.2.1. Generation of Client Request + + The initial authentication request (AS-REQ) is sent as per [RFC4120]; + in addition, a pre-authentication data element, whose padata-type is + PA_PK_AS_REQ and whose padata-value contains the DER encoding of the + type PA-PK-AS-REQ, is included. + + PA-PK-AS-REQ ::= SEQUENCE { + signedAuthPack [0] IMPLICIT OCTET STRING, + -- Contains a CMS type ContentInfo encoded + -- according to [RFC3852]. + -- The contentType field of the type ContentInfo + -- is id-signedData (1.2.840.113549.1.7.2), + -- and the content field is a SignedData. + -- The eContentType field for the type SignedData is + -- id-pkinit-authData (1.3.6.1.5.2.3.1), and the + -- eContent field contains the DER encoding of the + -- type AuthPack. + -- AuthPack is defined below. + trustedCertifiers [1] SEQUENCE OF + ExternalPrincipalIdentifier OPTIONAL, + + + +Zhu & Tung Expires June 2, 2006 [Page 7] + +Internet-Draft PKINIT November 2005 + + + -- Contains a list of CAs, trusted by the client, + -- that can be used to certify the KDC. + -- Each ExternalPrincipalIdentifier identifies a CA + -- or a CA certificate (thereby its public key). + -- The information contained in the + -- trustedCertifiers SHOULD be used by the KDC as + -- hints to guide its selection of an appropriate + -- certificate chain to return to the client. + kdcPkId [2] IMPLICIT OCTET STRING + OPTIONAL, + -- Contains a CMS type SignerIdentifier encoded + -- according to [RFC3852]. + -- Identifies, if present, a particular KDC + -- public key that the client already has. + ... + } + + DHNonce ::= OCTET STRING + + ExternalPrincipalIdentifier ::= SEQUENCE { + subjectName [0] IMPLICIT OCTET STRING OPTIONAL, + -- Contains a PKIX type Name encoded according to + -- [RFC3280]. + -- Identifies the certificate subject by the + -- distinguished subject name. + -- REQUIRED when there is a distinguished subject + -- name present in the certificate. + issuerAndSerialNumber [1] IMPLICIT OCTET STRING OPTIONAL, + -- Contains a CMS type IssuerAndSerialNumber encoded + -- according to [RFC3852]. + -- Identifies a certificate of the subject. + -- REQUIRED for TD-INVALID-CERTIFICATES and + -- TD-TRUSTED-CERTIFIERS. + subjectKeyIdentifier [2] IMPLICIT OCTET STRING OPTIONAL, + -- Identifies the subject's public key by a key + -- identifier. When an X.509 certificate is + -- referenced, this key identifier matches the X.509 + -- subjectKeyIdentifier extension value. When other + -- certificate formats are referenced, the documents + -- that specify the certificate format and their use + -- with the CMS must include details on matching the + -- key identifier to the appropriate certificate + -- field. + -- RECOMMENDED for TD-TRUSTED-CERTIFIERS. + ... + } + + AuthPack ::= SEQUENCE { + + + +Zhu & Tung Expires June 2, 2006 [Page 8] + +Internet-Draft PKINIT November 2005 + + + pkAuthenticator [0] PKAuthenticator, + clientPublicValue [1] SubjectPublicKeyInfo OPTIONAL, + -- Type SubjectPublicKeyInfo is defined in + -- [RFC3280]. + -- Specifies Diffie-Hellman domain parameters + -- and the client's public key value [IEEE1363]. + -- The DH public key value is encoded as a BIT + -- STRING according to [RFC3279]. + -- This field is present only if the client wishes + -- to use the Diffie-Hellman key agreement method. + supportedCMSTypes [2] SEQUENCE OF AlgorithmIdentifier + OPTIONAL, + -- Type AlgorithmIdentifier is defined in + -- [RFC3280]. + -- List of CMS encryption types supported by the + -- client in order of (decreasing) preference. + clientDHNonce [3] DHNonce OPTIONAL, + -- Present only if the client indicates that it + -- wishes to reuse DH keys or to allow the KDC to + -- do so (see Section 3.2.3.1). + ... + } + + PKAuthenticator ::= SEQUENCE { + cusec [0] INTEGER (0..999999), + ctime [1] KerberosTime, + -- cusec and ctime are used as in [RFC4120], for + -- replay prevention. + nonce [2] INTEGER (0..4294967295), + -- Chosen randomly; This nonce does not need to + -- match with the nonce in the KDC-REQ-BODY. + paChecksum [3] OCTET STRING, + -- Contains the SHA1 checksum, performed over + -- KDC-REQ-BODY. + ... + } + + The ContentInfo [RFC3852] structure contained in the signedAuthPack + field of the type PA-PK-AS-REQ is encoded according to [RFC3852] and + is filled out as follows: + + 1. The contentType field of the type ContentInfo is id-signedData + (as defined in [RFC3852]), and the content field is a SignedData + (as defined in [RFC3852]). + + 2. The eContentType field for the type SignedData is id-pkinit- + authData: { iso(1) org(3) dod(6) internet(1) security(5) + kerberosv5(2) pkinit(3) authData(1) }. Notes to CMS + + + +Zhu & Tung Expires June 2, 2006 [Page 9] + +Internet-Draft PKINIT November 2005 + + + implementers: the signed attribute content-type MUST be present + in this SignedData instance and its value is id-pkinit-authData + according to [RFC3852]. + + 3. The eContent field for the type SignedData contains the DER + encoding of the type AuthPack. + + 4. The signerInfos field of the type SignedData contains a single + signerInfo, which contains the signature over the type AuthPack. + + 5. The AuthPack structure contains a PKAuthenticator, the client + public key information, the CMS encryption types supported by the + client and a DHNonce. The pkAuthenticator field certifies to the + KDC that the client has recent knowledge of the signing key that + authenticates the client. The clientPublicValue field specifies + Diffie-Hellman domain parameters and the client's public key + value. The DH public key value is encoded as a BIT STRING + according to [RFC3279]. The clientPublicValue field is present + only if the client wishes to use the Diffie-Hellman key agreement + method. The supportedCMSTypes field specifies the list of CMS + encryption types supported by the client in order of (decreasing) + preference. The clientDHNonce field is described later in this + section. + + 6. The ctime field in the PKAuthenticator structure contains the + current time on the client's host, and the cusec field contains + the microsecond part of the client's timestamp. The ctime and + cusec fields are used together to specify a reasonably accurate + timestamp [RFC4120]. The nonce field is chosen randomly. The + paChecksum field contains a SHA1 checksum that is performed over + the KDC-REQ-BODY [RFC4120]. + + 7. The certificates field of the type SignedData contains + certificates intended to facilitate certification path + construction, so that the KDC can verify the signature over the + type AuthPack. For path validation, these certificates SHOULD be + sufficient to construct at least one certification path from the + client certificate to one trust anchor acceptable by the KDC + [RFC4158]. The client MUST be capable of including such a set of + certificates if configured to do so. The certificates field MUST + NOT contain "root" CA certificates. + + 8. The client's Diffie-Hellman public value (clientPublicValue) is + included if and only if the client wishes to use the Diffie- + Hellman key agreement method. The Diffie-Hellman domain + parameters [IEEE1363] for the client's public key are specified + in the algorithm field of the type SubjectPublicKeyInfo [RFC3279] + and the client's Diffie-Hellman public key value is mapped to a + + + +Zhu & Tung Expires June 2, 2006 [Page 10] + +Internet-Draft PKINIT November 2005 + + + subjectPublicKey (a BIT STRING) according to [RFC3279]. When + using the Diffie-Hellman key agreement method, implementations + MUST support Oakley 1024-bit Modular Exponential (MODP) well- + known group 2 [RFC2412] and Oakley 2048-bit MODP well-known group + 14 [RFC3526], and SHOULD support Oakley 4096-bit MODP well-known + group 16 [RFC3526]. + + The Diffie-Hellman field size should be chosen so as to provide + sufficient cryptographic security [RFC3766]. + + When MODP Diffie-Hellman is used, the exponents should have at + least twice as many bits as the symmetric keys that will be + derived from them [ODL99]. + + 9. The client may wish to reuse DH keys or to allow the KDC to do so + (see Section 3.2.3.1). If so, then the client includes the + clientDHNonce field. This nonce string MUST be as long as the + longest key length of the symmetric key types that the client + supports. This nonce MUST be chosen randomly. + + The ExternalPrincipalIdentifier structure is used in this document to + identify the subject's public key thereby the subject principal. + This structure is filled out as follows: + + 1. The subjectName field contains a PKIX type Name encoded according + to [RFC3280]. This field identifies the certificate subject by + the distinguished subject name. This field is REQUIRED when + there is a distinguished subject name present in the certificate + being used. + + 2. The issuerAndSerialNumber field contains a CMS type + IssuerAndSerialNumber encoded according to [RFC3852]. This field + identifies a certificate of the subject. This field is REQUIRED + for TD-INVALID-CERTIFICATES and TD-TRUSTED-CERTIFIERS (both + structures are defined in Section 3.2.2). + + 3. The subjectKeyIdentifier [RFC3852] field identifies the subject's + public key by a key identifier. When an X.509 certificate is + referenced, this key identifier matches the X.509 + subjectKeyIdentifier extension value. When other certificate + formats are referenced, the documents that specify the + certificate format and their use with the CMS must include + details on matching the key identifier to the appropriate + certificate field. This field is RECOMMENDED for TD-TRUSTED- + CERTIFIERS (as defined in Section 3.2.2). + + The trustedCertifiers field of the type PA-PK-AS-REQ contains a list + of CAs, trusted by the client, that can be used to certify the KDC. + + + +Zhu & Tung Expires June 2, 2006 [Page 11] + +Internet-Draft PKINIT November 2005 + + + Each ExternalPrincipalIdentifier identifies a CA or a CA certificate + (thereby its public key). + + The kdcPkId field of the type PA-PK-AS-REQ contains a CMS type + SignerIdentifier encoded according to [RFC3852]. This field + identifies, if present, a particular KDC public key that the client + already has. + +3.2.2. Receipt of Client Request + + Upon receiving the client's request, the KDC validates it. This + section describes the steps that the KDC MUST (unless otherwise + noted) take in validating the request. + + The KDC verifies the client's signature in the signedAuthPack field + according to [RFC3852]. + + If, while validating the client's X.509 certificate [RFC3280], the + KDC cannot build a certification path to validate the client's + certificate, it sends back a KRB-ERROR [RFC4120] message with the + code KDC_ERR_CANT_VERIFY_CERTIFICATE. The accompanying e-data for + this error message is a TYPED-DATA (as defined in [RFC4120]) that + contains an element whose data-type is TD_TRUSTED_CERTIFIERS, and + whose data-value contains the DER encoding of the type TD-TRUSTED- + CERTIFIERS: + + TD-TRUSTED-CERTIFIERS ::= SEQUENCE OF + ExternalPrincipalIdentifier + -- Identifies a list of CAs trusted by the KDC. + -- Each ExternalPrincipalIdentifier identifies a CA + -- or a CA certificate (thereby its public key). + + Each ExternalPrincipalIdentifier (as defined in Section 3.2.1) in the + TD-TRUSTED-CERTIFIERS structure identifies a CA or a CA certificate + (thereby its public key) trusted by the KDC. + + Upon receiving this error message, the client SHOULD retry only if it + has a different set of certificates (from those of the previous + requests) that form a certification path (or a partial path) from one + of the trust anchors acceptable by the KDC to its own certificate. + + If, while processing the certification path, the KDC determines that + the signature on one of the certificates in the signedAuthPack field + is invalid, it returns a KRB-ERROR [RFC4120] message with the code + KDC_ERR_INVALID_CERTIFICATE. The accompanying e-data for this error + message is a TYPED-DATA that contains an element whose data-type is + TD_INVALID_CERTIFICATES, and whose data-value contains the DER + encoding of the type TD-INVALID-CERTIFICATES: + + + +Zhu & Tung Expires June 2, 2006 [Page 12] + +Internet-Draft PKINIT November 2005 + + + TD-INVALID-CERTIFICATES ::= SEQUENCE OF + ExternalPrincipalIdentifier + -- Each ExternalPrincipalIdentifier identifies a + -- certificate (sent by the client) with an invalid + -- signature. + + Each ExternalPrincipalIdentifier (as defined in Section 3.2.1) in the + TD-INVALID-CERTIFICATES structure identifies a certificate (that was + sent by the client) with an invalid signature. + + If more than one X.509 certificate signature is invalid, the KDC MAY + include one IssuerAndSerialNumber per invalid signature within the + TD-INVALID-CERTIFICATES. + + The client's X.509 certificate is validated according to [RFC3280]. + + Based on local policy, the KDC may also check whether any X.509 + certificates in the certification path validating the client's + certificate have been revoked. If any of them have been revoked, the + KDC MUST return an error message with the code + KDC_ERR_REVOKED_CERTIFICATE; if the KDC attempts to determine the + revocation status but is unable to do so, it SHOULD return an error + message with the code KDC_ERR_REVOCATION_STATUS_UNKNOWN. The + certificate or certificates affected are identified exactly as for + the error code KDC_ERR_INVALID_CERTIFICATE (see above). + + Note that the TD_INVALID_CERTIFICATES error data is only used to + identify invalid certificates sent by the client in the request. + + The client's public key is then used to verify the signature. If the + signature fails to verify, the KDC MUST return an error message with + the code KDC_ERR_INVALID_SIG. There is no accompanying e-data for + this error message. + + In addition to validating the client's signature, the KDC MUST also + check that the client's public key used to verify the client's + signature is bound to the client's principal name as specified in the + AS-REQ as follows: + + 1. If the KDC has its own binding between either the client's + signature-verification public key or the client's certificate and + the client's Kerberos principal name, it uses that binding. + + 2. Otherwise, if the client's X.509 certificate contains a Subject + Alternative Name (SAN) extension carrying a KRB5PrincipalName + (defined below) in the otherName field of the type GeneralName + [RFC3280], it binds the client's X.509 certificate to that name. + + + + +Zhu & Tung Expires June 2, 2006 [Page 13] + +Internet-Draft PKINIT November 2005 + + + The type of the otherName field is AnotherName. The type-id field + of the type AnotherName is id-pkinit-san: + + id-pkinit-san OBJECT IDENTIFIER ::= + { iso(1) org(3) dod(6) internet(1) security(5) kerberosv5(2) + x509SanAN (2) } + + And the value field of the type AnotherName is a + KRB5PrincipalName. + + KRB5PrincipalName ::= SEQUENCE { + realm [0] Realm, + principalName [1] PrincipalName + } + + If the KDC does not have its own binding and there is no + KRB5PrincipalName name present in the client's X.509 certificate, or + if the Kerberos name in the request does not match the + KRB5PrincipalName in the client's X.509 certificate (including the + realm name), the KDC MUST return an error message with the code + KDC_ERR_CLIENT_NAME_MISMATCH. There is no accompanying e-data for + this error message. + + Even if the certification path is validated and the certificate is + mapped to the client's principal name, the KDC may decide not to + accept the client's certificate, depending on local policy. + + The KDC MAY require the presence of an Extended Key Usage (EKU) + KeyPurposeId [RFC3280] id-pkinit-KPClientAuth in the extensions field + of the client's X.509 certificate: + + id-pkinit-KPClientAuth OBJECT IDENTIFIER ::= + { iso(1) org(3) dod(6) internet(1) security(5) kerberosv5(2) + pkinit(3) keyPurposeClientAuth(4) } + -- PKINIT client authentication. + -- Key usage bits that MUST be consistent: + -- digitalSignature. + + The digitalSignature key usage bit MUST be asserted when the intended + purpose of the client certificate is restricted with the id-pkinit- + KPClientAuth EKU. + + If this EKU KeyPurposeId is required but it is not present or if the + client certificate is restricted not to be used for PKINIT client + authentication per Section 4.2.1.13 of [RFC3280], the KDC MUST return + an error message of the code KDC_ERR_INCONSISTENT_KEY_PURPOSE. There + is no accompanying e-data for this error message. KDCs implementing + this requirement SHOULD also accept the EKU KeyPurposeId id-ms-kp-sc- + + + +Zhu & Tung Expires June 2, 2006 [Page 14] + +Internet-Draft PKINIT November 2005 + + + logon (1.3.6.1.4.1.311.20.2.2) as meeting the requirement, as there + are a large number of X.509 client certificates deployed for use with + PKINIT which have this EKU. + + As a matter of local policy, the KDC MAY decide to reject requests on + the basis of the absence or presence of other specific EKU OID's. + + If the digest algorithm used in generating the CA signature for the + public key in any certificate of the request is not acceptable by the + KDC, the KDC MUST return a KRB-ERROR [RFC4120] message with the code + KDC_ERR_DIGEST_IN_CERT_NOT_ACCEPTED. The accompanying e-data MUST be + encoded in TYPED-DATA although none is defined at this point. + + If the client's public key is not accepted with reasons other than + what were specified above, the KDC returns a KRB-ERROR [RFC4120] + message with the code KDC_ERR_CLIENT_NOT_TRUSTED. There is no + accompanying e-data currently defined for this error message. + + The KDC MUST check the timestamp to ensure that the request is not a + replay, and that the time skew falls within acceptable limits. The + recommendations for clock skew times in [RFC4120] apply here. If the + check fails, the KDC MUST return error code KRB_AP_ERR_REPEAT or + KRB_AP_ERR_SKEW, respectively. + + If the clientPublicValue is filled in, indicating that the client + wishes to use the Diffie-Hellman key agreement method, the KDC SHOULD + check to see if the key parameters satisfy its policy. If they do + not, it MUST return an error message with the code + KDC_ERR_DH_KEY_PARAMETERS_NOT_ACCEPTED. The accompanying e-data is a + TYPED-DATA that contains an element whose data-type is + TD_DH_PARAMETERS, and whose data-value contains the DER encoding of + the type TD-DH-PARAMETERS: + + TD-DH-PARAMETERS ::= SEQUENCE OF AlgorithmIdentifier + -- Each AlgorithmIdentifier specifies a set of + -- Diffie-Hellman domain parameters [IEEE1363]. + -- This list is in decreasing preference order. + + TD-DH-PARAMETERS contains a list of Diffie-Hellman domain parameters + that the KDC supports in decreasing preference order, from which the + client SHOULD pick one to retry the request. + + The AlgorithmIdentifier structure is defined in [RFC3280] and is + filled in according to [RFC3279]. More specifically Section 2.3.3 of + [RFC3279] describes how to fill in the AlgorithmIdentifier structure + in the case where MODP Diffie-Hellman key exchange is used. + + If the client included a kdcPkId field in the PA-PK-AS-REQ and the + + + +Zhu & Tung Expires June 2, 2006 [Page 15] + +Internet-Draft PKINIT November 2005 + + + KDC does not possess the corresponding key, the KDC MUST ignore the + kdcPkId field as if the client did not include one. + + If the digest algorithm used by the id-pkinit-authData is not + acceptable by the KDC, the KDC MUST return a KRB-ERROR [RFC4120] + message with the code KDC_ERR_DIGEST_IN_SIGNED_DATA_NOT_ACCEPTED. + The accompanying e-data MUST be encoded in TYPED-DATA although none + is defined at this point. + +3.2.3. Generation of KDC Reply + + Assuming that the client's request has been properly validated, the + KDC proceeds as per [RFC4120], except as follows. + + The KDC MUST set the initial flag and include an authorization data + element of ad-type [RFC4120] AD_INITIAL_VERIFIED_CAS in the issued + ticket. The ad-data [RFC4120] field contains the DER encoding of the + type AD-INITIAL-VERIFIED-CAS: + + AD-INITIAL-VERIFIED-CAS ::= SEQUENCE OF + ExternalPrincipalIdentifier + -- Identifies the certification path based on which + -- the client certificate was validated. + -- Each ExternalPrincipalIdentifier identifies a CA + -- or a CA certificate (thereby its public key). + + The AD-INITIAL-VERIFIED-CAS structure identifies the certification + path based on which the client certificate was validated. Each + ExternalPrincipalIdentifier (as defined in Section 3.2.1) in the AD- + INITIAL-VERIFIED-CAS structure identifies a CA or a CA certificate + (thereby its public key). + + The AS wraps any AD-INITIAL-VERIFIED-CAS data in AD-IF-RELEVANT + containers if the list of CAs satisfies the AS' realm's local policy + (this corresponds to the TRANSITED-POLICY-CHECKED ticket flag + [RFC4120]). Furthermore, any TGS MUST copy such authorization data + from tickets used within a PA-TGS-REQ of the TGS-REQ into the + resulting ticket. If the list of CAs satisfies the local KDC's + realm's policy, the TGS MAY wrap the data into the AD-IF-RELEVANT + container, otherwise it MAY unwrap the authorization data out of the + AD-IF-RELEVANT container. + + Application servers that understand this authorization data type + SHOULD apply local policy to determine whether a given ticket bearing + such a type *not* contained within an AD-IF-RELEVANT container is + acceptable. (This corresponds to the AP server checking the + transited field when the TRANSITED-POLICY-CHECKED flag has not been + set [RFC4120].) If such a data type is contained within an AD-IF- + + + +Zhu & Tung Expires June 2, 2006 [Page 16] + +Internet-Draft PKINIT November 2005 + + + RELEVANT container, AP servers MAY apply local policy to determine + whether the authorization data is acceptable. + + A pre-authentication data element, whose padata-type is PA_PK_AS_REP + and whose padata-value contains the DER encoding of the type PA-PK- + AS-REP (defined below), is included in the AS-REP [RFC4120]. + + PA-PK-AS-REP ::= CHOICE { + dhInfo [0] DHRepInfo, + -- Selected when Diffie-Hellman key exchange is + -- used. + encKeyPack [1] IMPLICIT OCTET STRING, + -- Selected when public key encryption is used. + -- Contains a CMS type ContentInfo encoded + -- according to [RFC3852]. + -- The contentType field of the type ContentInfo is + -- id-envelopedData (1.2.840.113549.1.7.3). + -- The content field is an EnvelopedData. + -- The contentType field for the type EnvelopedData + -- is id-signedData (1.2.840.113549.1.7.2). + -- The eContentType field for the inner type + -- SignedData (when unencrypted) is + -- id-pkinit-rkeyData (1.3.6.1.5.2.3.3) and the + -- eContent field contains the DER encoding of the + -- type ReplyKeyPack. + -- ReplyKeyPack is defined in Section 3.2.3.2. + ... + } + + DHRepInfo ::= SEQUENCE { + dhSignedData [0] IMPLICIT OCTET STRING, + -- Contains a CMS type ContentInfo encoded according + -- to [RFC3852]. + -- The contentType field of the type ContentInfo is + -- id-signedData (1.2.840.113549.1.7.2), and the + -- content field is a SignedData. + -- The eContentType field for the type SignedData is + -- id-pkinit-DHKeyData (1.3.6.1.5.2.3.2), and the + -- eContent field contains the DER encoding of the + -- type KDCDHKeyInfo. + -- KDCDHKeyInfo is defined below. + serverDHNonce [1] DHNonce OPTIONAL + -- Present if and only if dhKeyExpiration is + -- present in the KDCDHKeyInfo. + } + + KDCDHKeyInfo ::= SEQUENCE { + subjectPublicKey [0] BIT STRING, + + + +Zhu & Tung Expires June 2, 2006 [Page 17] + +Internet-Draft PKINIT November 2005 + + + -- The KDC's DH public key. + -- The DH public key value is encoded as a BIT + -- STRING according to [RFC3279]. + nonce [1] INTEGER (0..4294967295), + -- Contains the nonce in the pkAuthenticator field + -- in the request if the DH keys are NOT reused, + -- 0 otherwise. + dhKeyExpiration [2] KerberosTime OPTIONAL, + -- Expiration time for KDC's key pair, + -- present if and only if the DH keys are reused. + -- If present, the KDC's DH public key MUST not be + -- used past the point of this expiration time. + -- If this field is omitted then the serverDHNonce + -- field MUST also be omitted. + ... + } + + The content of the AS-REP is otherwise unchanged from [RFC4120]. The + KDC encrypts the reply as usual, but not with the client's long-term + key. Instead, it encrypts it with either a shared key derived from a + Diffie-Hellman exchange, or a generated encryption key. The contents + of the PA-PK-AS-REP indicate which key delivery method is used. + + In addition, the lifetime of the ticket returned by the KDC MUST NOT + exceed that of the client's public-private key pair. The ticket + lifetime, however, can be shorter than that of the client's public- + private key pair. For the implementations of this specification, the + lifetime of the client's public-private key pair is the validity + period in X.509 certificates [RFC3280], unless configured otherwise. + +3.2.3.1. Using Diffie-Hellman Key Exchange + + In this case, the PA-PK-AS-REP contains a DHRepInfo structure. + + The ContentInfo [RFC3852] structure for the dhSignedData field is + filled in as follows: + + 1. The contentType field of the type ContentInfo is id-signedData + (as defined in [RFC3852]), and the content field is a SignedData + (as defined in [RFC3852]). + + 2. The eContentType field for the type SignedData is the OID value + for id-pkinit-DHKeyData: { iso(1) org(3) dod(6) internet(1) + security(5) kerberosv5(2) pkinit(3) DHKeyData(2) }. Notes to CMS + implementers: the signed attribute content-type MUST be present + in this SignedData instance and its value is id-pkinit-DHKeyData + according to [RFC3852]. + + + + +Zhu & Tung Expires June 2, 2006 [Page 18] + +Internet-Draft PKINIT November 2005 + + + 3. The eContent field for the type SignedData contains the DER + encoding of the type KDCDHKeyInfo. + + 4. The KDCDHKeyInfo structure contains the KDC's public key, a nonce + and optionally the expiration time of the KDC's DH key being + reused. The subjectPublicKey field of the type KDCDHKeyInfo + field identifies KDC's DH public key. This DH public key value + is encoded as a BIT STRING according to [RFC3279]. The nonce + field contains the nonce in the pkAuthenticator field in the + request if the DH keys are NOT reused. The value of this nonce + field is 0 if the DH keys are reused. The dhKeyExpiration field + is present if and only if the DH keys are reused. If the + dhKeyExpiration field is present, the KDC's public key in this + KDCDHKeyInfo structure MUST NOT be used past the point of this + expiration time. If this field is omitted then the serverDHNonce + field MUST also be omitted. + + 5. The signerInfos field of the type SignedData contains a single + signerInfo, which contains the signature over the type + KDCDHKeyInfo. + + 6. The certificates field of the type SignedData contains + certificates intended to facilitate certification path + construction, so that the client can verify the KDC's signature + over the type KDCDHKeyInfo. The information contained in the + trustedCertifiers in the request SHOULD be used by the KDC as + hints to guide its selection of an appropriate certificate chain + to return to the client. This field may be left empty if the KDC + public key specified by the kdcPkId field in the PA-PK-AS-REQ was + used for signing. Otherwise, for path validation, these + certificates SHOULD be sufficient to construct at least one + certification path from the KDC certificate to one trust anchor + acceptable by the client [RFC4158]. The KDC MUST be capable of + including such a set of certificates if configured to do so. The + certificates field MUST NOT contain "root" CA certificates. + + 7. If the client included the clientDHNonce field, then the KDC may + choose to reuse its DH keys (see Section 3.2.3.1). If the server + reuses DH keys then it MUST include an expiration time in the + dhKeyExpiration field. Past the point of the expiration time, + the signature over the type DHRepInfo is considered expired/ + invalid. When the server reuses DH keys then it MUST include a + serverDHNonce at least as long as the length of keys for the + symmetric encryption system used to encrypt the AS reply. Note + that including the serverDHNonce changes how the client and + server calculate the key to use to encrypt the reply; see below + for details. The KDC SHOULD NOT reuse DH keys unless the + clientDHNonce field is present in the request. + + + +Zhu & Tung Expires June 2, 2006 [Page 19] + +Internet-Draft PKINIT November 2005 + + + The AS reply key is derived as follows: + + 1. Both the KDC and the client calculate the shared secret value as + follows: + + a) When MODP Diffie-Hellman is used, let DHSharedSecret be the + shared secret value. DHSharedSecret is the value ZZ as + described in Section 2.1.1 of [RFC2631]. + + DHSharedSecret is first padded with leading zeros such that the + size of DHSharedSecret in octets is the same as that of the + modulus, then represented as a string of octets in big-endian + order. + + Implementation note: Both the client and the KDC can cache the + triple (ya, yb, DHSharedSecret), where ya is the client's public + key and yb is the KDC's public key. If both ya and yb are the + same in a later exchange, the cached DHSharedSecret can be used. + + 2. Let K be the key-generation seed length [RFC3961] of the AS reply + key whose enctype is selected according to [RFC4120]. + + 3. Define the function octetstring2key() as follows: + + octetstring2key(x) == random-to-key(K-truncate( + SHA1(0x00 | x) | + SHA1(0x01 | x) | + SHA1(0x02 | x) | + ... + )) + + where x is an octet string; | is the concatenation operator; 0x00, + 0x01, 0x02, etc., are each represented as a single octet; random- + to-key() is an operation that generates a protocol key from a + bitstring of length K; and K-truncate truncates its input to the + first K bits. Both K and random-to-key() are as defined in the + kcrypto profile [RFC3961] for the enctype of the AS reply key. + + 4. When DH keys are reused, let n_c be the clientDHNonce, and n_k be + the serverDHNonce; otherwise, let both n_c and n_k be empty octet + strings. + + 5. The AS reply key k is: + + k = octetstring2key(DHSharedSecret | n_c | n_k) + + If the hash algorithm used in the key derivation function (currently + only octetstring2key() is defined) is not acceptable by the KDC, the + + + +Zhu & Tung Expires June 2, 2006 [Page 20] + +Internet-Draft PKINIT November 2005 + + + KDC MUST return a KRB-ERROR [RFC4120] message with the code + KDC_ERR_HASH_IN_KDF_NOT_ACCEPTED. The accompanying e-data MUST be + encoded in TYPED-DATA although none is defined at this point. + +3.2.3.2. Using Public Key Encryption + + In this case, the PA-PK-AS-REP contains an encKeyPack structure where + the AS reply key is encrypted. + + The ContentInfo [RFC3852] structure for the encKeyPack field is + filled in as follows: + + 1. The contentType field of the type ContentInfo is id-envelopedData + (as defined in [RFC3852]), and the content field is an + EnvelopedData (as defined in [RFC3852]). + + 2. The contentType field for the type EnvelopedData is id- + signedData: { iso (1) member-body (2) us (840) rsadsi (113549) + pkcs (1) pkcs7 (7) signedData (2) }. + + 3. The eContentType field for the inner type SignedData (when + decrypted from the encryptedContent field for the type + EnvelopedData) is id-pkinit-rkeyData: { iso(1) org(3) dod(6) + internet(1) security(5) kerberosv5(2) pkinit(3) rkeyData(3) }. + Notes to CMS implementers: the signed attribute content-type MUST + be present in this SignedData instance and its value is id- + pkinit-rkeyData according to [RFC3852]. + + 4. The eContent field for the inner type SignedData contains the DER + encoding of the type ReplyKeyPack (as described below). + + 5. The signerInfos field of the inner type SignedData contains a + single signerInfo, which contains the signature for the type + ReplyKeyPack. + + 6. The certificates field of the inner type SignedData contains + certificates intended to facilitate certification path + construction, so that the client can verify the KDC's signature + for the type ReplyKeyPack. The information contained in the + trustedCertifiers in the request SHOULD be used by the KDC as + hints to guide its selection of an appropriate certificate chain + to return to the client. This field may be left empty if the KDC + public key specified by the kdcPkId field in the PA-PK-AS-REQ was + used for signing. Otherwise, for path validation, these + certificates SHOULD be sufficient to construct at least one + certification path from the KDC certificate to one trust anchor + acceptable by the client [RFC4158]. The KDC MUST be capable of + including such a set of certificates if configured to do so. The + + + +Zhu & Tung Expires June 2, 2006 [Page 21] + +Internet-Draft PKINIT November 2005 + + + certificates field MUST NOT contain "root" CA certificates. + + 7. The recipientInfos field of the type EnvelopedData is a SET which + MUST contain exactly one member of type KeyTransRecipientInfo. + The encryptedKey of this member contains the temporary key which + is encrypted using the client's public key. + + 8. The unprotectedAttrs or originatorInfo fields of the type + EnvelopedData MAY be present. + + If there is a supportedCMSTypes field in the AuthPack, the KDC must + check to see if it supports any of the listed types. If it supports + more than one of the types, the KDC SHOULD use the one listed first. + If it does not support any of them, it MUST return an error message + with the code KDC_ERR_ETYPE_NOSUPP [RFC4120]. + + Furthermore the KDC computes the checksum of the AS-REQ in the client + request. This checksum is performed over the type AS-REQ and the + protocol key [RFC3961] of the checksum operation is the replyKey and + the key usage number is 6. If the replyKey's enctype is "newer" + [RFC4120] [RFC4121], the checksum operation is the required checksum + operation [RFC3961] of that enctype. + + ReplyKeyPack ::= SEQUENCE { + replyKey [0] EncryptionKey, + -- Contains the session key used to encrypt the + -- enc-part field in the AS-REP, i.e. the + -- AS reply key. + asChecksum [1] Checksum, + -- Contains the checksum of the AS-REQ + -- corresponding to the containing AS-REP. + -- The checksum is performed over the type AS-REQ. + -- The protocol key [RFC3961] of the checksum is the + -- replyKey and the key usage number is 6. + -- If the replyKey's enctype is "newer" [RFC4120] + -- [RFC4121], the checksum is the required + -- checksum operation [RFC3961] for that enctype. + -- The client MUST verify this checksum upon receipt + -- of the AS-REP. + ... + } + + Implementations of this RSA encryption key delivery method are + RECOMMENDED to support RSA keys at least 2048 bits in size. + +3.2.4. Receipt of KDC Reply + + Upon receipt of the KDC's reply, the client proceeds as follows. If + + + +Zhu & Tung Expires June 2, 2006 [Page 22] + +Internet-Draft PKINIT November 2005 + + + the PA-PK-AS-REP contains the dhSignedData field, the client derives + the AS reply key using the same procedure used by the KDC as defined + in Section 3.2.3.1. Otherwise, the message contains the encKeyPack + field, and the client decrypts and extracts the temporary key in the + encryptedKey field of the member KeyTransRecipientInfo, and then uses + that as the AS reply key. + + If the public key encryption method is used, the client MUST verify + the asChecksum contained in the ReplyKeyPack. + + In either case, the client MUST verify the signature in the + SignedData according to [RFC3852]. The KDC's X.509 certificate MUST + be validated according to [RFC3280]. In addition, unless the client + can otherwise verify that the public key used to verify the KDC's + signature is bound to the KDC of the target realm, the KDC's X.509 + certificate MUST contain a Subject Alternative Name extension + [RFC3280] carrying an AnotherName whose type-id is id-pkinit-san (as + defined in Section 3.2.2) and whose value is a KRB5PrincipalName that + matches the name of the TGS of the target realm (as defined in + Section 7.3 of [RFC4120]). + + Unless the client knows by some other means that the KDC certificate + is intended for a Kerberos KDC, the client MUST require that the KDC + certificate contains the EKU KeyPurposeId [RFC3280] id-pkinit-KPKdc: + + id-pkinit-KPKdc OBJECT IDENTIFIER ::= + { iso(1) org(3) dod(6) internet(1) security(5) kerberosv5(2) + pkinit(3) keyPurposeKdc(5) } + -- Signing KDC responses. + -- Key usage bits that MUST be consistent: + -- digitalSignature. + + The digitalSignature key usage bit MUST be asserted when the intended + purpose of KDC certificate is restricted with the id-pkinit-KPKdc + EKU. + + If the KDC certificate contains the Kerberos TGS name encoded as an + id-pkinit-san SAN, this certificate is certified by the issuing CA as + a KDC certificate, therefore the id-pkinit-KPKdc EKU is not required. + + If all applicable checks are satisfied, the client then decrypts the + enc-part field of the KDC-REP in the AS-REP using the AS reply key, + and then proceeds as described in [RFC4120]. + + Implementation note: CAs issuing KDC certificates SHOULD place all + "short" and "fully-qualified" Kerberos realm names of the KDC (one + per GeneralName [RFC3280]) into the KDC certificate to allow maximum + flexibility. + + + +Zhu & Tung Expires June 2, 2006 [Page 23] + +Internet-Draft PKINIT November 2005 + + +3.3. Interoperability Requirements + + The client MUST be capable of sending a set of certificates + sufficient to allow the KDC to construct a certification path for the + client's certificate, if the correct set of certificates is provided + through configuration or policy. + + If the client sends all the X.509 certificates on a certification + path to a trust anchor acceptable by the KDC, and the KDC can not + verify the client's public key otherwise, the KDC MUST be able to + process path validation for the client's certificate based on the + certificates in the request. + + The KDC MUST be capable of sending a set of certificates sufficient + to allow the client to construct a certification path for the KDC's + certificate, if the correct set of certificates is provided through + configuration or policy. + + If the KDC sends all the X.509 certificates on a certification path + to a trust anchor acceptable by the client, and the client can not + verify the KDC's public key otherwise, the client MUST be able to + process path validation for the KDC's certificate based on the + certificates in the reply. + +3.4. KDC Indication of PKINIT Support + + If pre-authentication is required, but was not present in the + request, per [RFC4120] an error message with the code + KDC_ERR_PREAUTH_FAILED is returned and a METHOD-DATA object will be + stored in the e-data field of the KRB-ERROR message to specify which + pre-authentication mechanisms are acceptable. The KDC can then + indicate the support of PKINIT by including an empty element whose + padata-type is PA_PK_AS_REQ in that METHOD-DATA object. + + Otherwise if it is required by the KDC's local policy that the client + must be pre-authenticated using the pre-authentication mechanism + specified in this document, but no PKINIT pre-authentication was + present in the request, an error message with the code + KDC_ERR_PREAUTH_FAILED SHOULD be returned. + + KDCs MUST leave the padata-value field of the PA_PK_AS_REQ element in + the KRB-ERROR's METHOD-DATA empty (i.e., send a zero-length OCTET + STRING), and clients MUST ignore this and any other value. Future + extensions to this protocol may specify other data to send instead of + an empty OCTET STRING. + + + + + + +Zhu & Tung Expires June 2, 2006 [Page 24] + +Internet-Draft PKINIT November 2005 + + +4. Security Considerations + + Kerberos error messages are not integrity protected, as a result, the + domain parameters sent by the KDC as TD-DH-PARAMETERS can be tampered + with by an attacker so that the set of domain parameters selected + could be either weaker or not mutually preferred. Local policy can + configure sets of domain parameters acceptable locally, or disallow + the negotiation of DH domain parameters. + + The symmetric reply key size and Diffie-Hellman field size or RSA + modulus size should be chosen so as to provide sufficient + cryptographic security [RFC3766]. + + When MODP Diffie-Hellman is used, the exponents should have at least + twice as many bits as the symmetric keys that will be derived from + them [ODL99]. + + PKINIT raises certain security considerations beyond those that can + be regulated strictly in protocol definitions. We will address them + in this section. + + PKINIT extends the cross-realm model to the public-key + infrastructure. Users of PKINIT must understand security policies + and procedures appropriate to the use of Public Key Infrastructures + [RFC3280]. + + In order to trust a KDC certificate that is certified by a CA as a + KDC certificate for a target realm (for example, by asserting the TGS + name of that Kerberos realm as an id-pkinit-san SAN and/or + restricting the certificate usage by using the id-pkinit-KPKdc EKU, + as described in Section 3.2.4), the client MUST verify that the KDC + certificate's issuing CA is authorized to issue KDC certificates for + that target realm. Otherwise, the binding between the KDC + certificate and the KDC of the target realm is not established. + + How to validate this authorization is a matter of local policy. A + way to achieve this is the configuration of specific sets of + intermediary CAs and trust anchors, one of which must be on the KDC + certificate's certification path [RFC3280]; and for each CA or trust + anchor the realms for which it is allowed to issue certificates. + + In addition, if any CA is trusted to issue KDC certificates can also + issue other kinds of certificates, then local policy must be able to + distinguish between them: for example, it could require that KDC + certificates contain the id-pkinit-KPKdc EKU or that the realm be + specified with the id-pkinit-san SAN. + + It is the responsibility of the PKI administrators for an + + + +Zhu & Tung Expires June 2, 2006 [Page 25] + +Internet-Draft PKINIT November 2005 + + + organization to ensure that KDC certificates are only issued to KDCs, + and that clients can ascertain this using their local policy. + + Standard Kerberos allows the possibility of interactions between + cryptosystems of varying strengths; this document adds interactions + with public-key cryptosystems to Kerberos. Some administrative + policies may allow the use of relatively weak public keys. Using + such keys to wrap data encrypted under stronger conventional + cryptosystems may be inappropriate. + + PKINIT requires keys for symmetric cryptosystems to be generated. + Some such systems contain "weak" keys. For recommendations regarding + these weak keys, see [RFC4120]. + + PKINIT allows the use of the same RSA key pair for encryption and + signing when doing RSA encryption based key delivery. This is not + recommended usage of RSA keys [RFC3447], by using DH based key + delivery this is avoided. + + Care should be taken in how certificates are chosen for the purposes + of authentication using PKINIT. Some local policies may require that + key escrow be used for certain certificate types. Deployers of + PKINIT should be aware of the implications of using certificates that + have escrowed keys for the purposes of authentication. Because + signing only certificates are normally not escrowed, by using DH + based key delivery this is avoided. + + PKINIT does not provide for a "return routability" test to prevent + attackers from mounting a denial-of-service attack on the KDC by + causing it to perform unnecessary and expensive public-key + operations. Strictly speaking, this is also true of standard + Kerberos, although the potential cost is not as great, because + standard Kerberos does not make use of public-key cryptography. By + using DH based key delivery and reusing DH keys, the necessary crypto + processing cost per request can be minimized. + + The syntax for the AD-INITIAL-VERIFIED-CAS authorization data does + permit empty SEQUENCEs to be encoded. Such empty sequences may only + be used if the KDC itself vouches for the user's certificate. + + When the Diffie-Hellman key exchange method is used, additional pre- + authentication data [RFC4120] (in addition to the PA_PK_AS_REQ as + defined in this specification) is not bound to the AS_REQ by the + mechanisms discussed in this specification (meaning it may be dropped + or added by attackers without being detected by either the client or + the KDC). Designers of additional pre-authentication data should + take that into consideration if such additional pre-authentication + data can be used in conjunction with the PA_PK_AS_REQ. The future + + + +Zhu & Tung Expires June 2, 2006 [Page 26] + +Internet-Draft PKINIT November 2005 + + + work of the Kerberos working group is expected to update the hash + algorithms specified in this document and provide a generic mechanism + to bind additional pre-authentication data with the accompanying + AS_REQ. + + +5. Acknowledgements + + The following people have made significant contributions to this + draft: Paul Leach, Stefan Santesson, Sam Hartman, Love Hornquist + Astrand, Ken Raeburn, Nicolas Williams, John Wray, Tom Yu, Jeffrey + Hutzelman, David Cross, Dan Simon, Karthik Jaganathan, Chaskiel M + Grundman and Jeffrey Altman. + + Andre Scedrov, Aaron D. Jaggard, Iliano Cervesato, Joe-Kai Tsay and + Chris Walstad discovered a binding issue between the AS-REQ and AS- + REP in draft -26, the asChecksum field was added as the result. + + Special thanks to Clifford Neuman, Matthew Hur, Sasha Medvinsky and + Jonathan Trostle who wrote earlier versions of this document. + + The authors are indebted to the Kerberos working group chair Jeffrey + Hutzelman who kept track of various issues and was enormously helpful + during the creation of this document. + + Some of the ideas on which this document is based arose during + discussions over several years between members of the SAAG, the IETF + CAT working group, and the PSRG, regarding integration of Kerberos + and SPX. Some ideas have also been drawn from the DASS system. + These changes are by no means endorsed by these groups. This is an + attempt to revive some of the goals of those groups, and this + document approaches those goals primarily from the Kerberos + perspective. + + Lastly, comments from groups working on similar ideas in DCE have + been invaluable. + + +6. IANA Considerations + + This document has no actions for IANA. + + +7. References + + + + + + + +Zhu & Tung Expires June 2, 2006 [Page 27] + +Internet-Draft PKINIT November 2005 + + +7.1. Normative References + + [IEEE1363] + IEEE, "Standard Specifications for Public Key + Cryptography", IEEE 1363, 2000. + + [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, March 1997. + + [RFC2412] Orman, H., "The OAKLEY Key Determination Protocol", + RFC 2412, November 1998. + + [RFC2631] Rescorla, E., "Diffie-Hellman Key Agreement Method", + RFC 2631, June 1999. + + [RFC3279] Bassham, L., Polk, W., and R. Housley, "Algorithms and + Identifiers for the Internet X.509 Public Key + Infrastructure Certificate and Certificate Revocation List + (CRL) Profile", RFC 3279, April 2002. + + [RFC3280] Housley, R., Polk, W., Ford, W., and D. Solo, "Internet + X.509 Public Key Infrastructure Certificate and + Certificate Revocation List (CRL) Profile", RFC 3280, + April 2002. + + [RFC3370] Housley, R., "Cryptographic Message Syntax (CMS) + Algorithms", RFC 3370, August 2002. + + [RFC3447] Jonsson, J. and B. Kaliski, "Public-Key Cryptography + Standards (PKCS) #1: RSA Cryptography Specifications + Version 2.1", RFC 3447, February 2003. + + [RFC3526] Kivinen, T. and M. Kojo, "More Modular Exponential (MODP) + Diffie-Hellman groups for Internet Key Exchange (IKE)", + RFC 3526, May 2003. + + [RFC3565] Schaad, J., "Use of the Advanced Encryption Standard (AES) + Encryption Algorithm in Cryptographic Message Syntax + (CMS)", RFC 3565, July 2003. + + [RFC3766] Orman, H. and P. Hoffman, "Determining Strengths For + Public Keys Used For Exchanging Symmetric Keys", BCP 86, + RFC 3766, April 2004. + + [RFC3852] Housley, R., "Cryptographic Message Syntax (CMS)", + RFC 3852, July 2004. + + [RFC3961] Raeburn, K., "Encryption and Checksum Specifications for + + + +Zhu & Tung Expires June 2, 2006 [Page 28] + +Internet-Draft PKINIT November 2005 + + + Kerberos 5", RFC 3961, February 2005. + + [RFC3962] Raeburn, K., "Advanced Encryption Standard (AES) + Encryption for Kerberos 5", RFC 3962, February 2005. + + [RFC4120] Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The + Kerberos Network Authentication Service (V5)", RFC 4120, + July 2005. + + [RFC4121] Zhu, L., Jaganathan, K., and S. Hartman, "The Kerberos + Version 5 Generic Security Service Application Program + Interface (GSS-API) Mechanism: Version 2", RFC 4121, + July 2005. + + [X680] ITU-T Recommendation X.680 (2002) | ISO/IEC 8824-1:2002, + Information technology - Abstract Syntax Notation One + (ASN.1): Specification of basic notation. + + [X690] ITU-T Recommendation X.690 (2002) | ISO/IEC 8825-1:2002, + Information technology - ASN.1 encoding Rules: Specification + of Basic Encoding Rules (BER), Canonical Encoding Rules + (CER) and Distinguished Encoding Rules (DER). + +7.2. Informative References + + [LENSTRA] Lenstra, A. and E. Verheul, "Selecting Cryptographic Key + Sizes", Journal of Cryptology 14 (2001) 255-293. + + [ODL99] Odlyzko, A., "Discrete logarithms: The past and the + future, Designs, Codes, and Cryptography (1999)". + + +Zhu & Tung Expires June 1, 2006 [Page 27] + +Internet-Draft PKINIT November 2005 + + + [RFC4158] Cooper, M., Dzambasow, Y., Hesse, P., Joseph, S., and R. + Nicholas, "Internet X.509 Public Key Infrastructure: + Certification Path Building", RFC 4158, September 2005. + + +Appendix A. PKINIT ASN.1 Module + + KerberosV5-PK-INIT-SPEC { + iso(1) identified-organization(3) dod(6) internet(1) + security(5) kerberosV5(2) modules(4) pkinit(5) + } DEFINITIONS EXPLICIT TAGS ::= BEGIN + + IMPORTS + SubjectPublicKeyInfo, AlgorithmIdentifier + + + +Zhu & Tung Expires June 2, 2006 [Page 29] + +Internet-Draft PKINIT November 2005 + + + FROM PKIX1Explicit88 { iso (1) + identified-organization (3) dod (6) internet (1) + security (5) mechanisms (5) pkix (7) id-mod (0) + id-pkix1-explicit (18) } + -- As defined in RFC 3280. + + KerberosTime, PrincipalName, Realm, EncryptionKey + FROM KerberosV5Spec2 { iso(1) identified-organization(3) + dod(6) internet(1) security(5) kerberosV5(2) + modules(4) krb5spec2(2) } ; + + id-pkinit OBJECT IDENTIFIER ::= + { iso (1) org (3) dod (6) internet (1) security (5) + kerberosv5 (2) pkinit (3) } + + id-pkinit-authData OBJECT IDENTIFIER ::= { id-pkinit 1 } + id-pkinit-DHKeyData OBJECT IDENTIFIER ::= { id-pkinit 2 } + id-pkinit-rkeyData OBJECT IDENTIFIER ::= { id-pkinit 3 } + id-pkinit-KPClientAuth OBJECT IDENTIFIER ::= { id-pkinit 4 } + id-pkinit-KPKdc OBJECT IDENTIFIER ::= { id-pkinit 5 } + + id-pkinit-san OBJECT IDENTIFIER ::= + { iso(1) org(3) dod(6) internet(1) security(5) kerberosv5(2) + x509SanAN (2) } + + pa-pk-as-req INTEGER ::= 16 + pa-pk-as-rep INTEGER ::= 17 + + ad-initial-verified-cas INTEGER ::= 9 + + td-trusted-certifiers INTEGER ::= 104 + td-invalid-certificates INTEGER ::= 105 + td-dh-parameters INTEGER ::= 109 + + PA-PK-AS-REQ ::= SEQUENCE { + signedAuthPack [0] IMPLICIT OCTET STRING, + -- Contains a CMS type ContentInfo encoded + -- according to [RFC3852]. + -- The contentType field of the type ContentInfo + -- is id-signedData (1.2.840.113549.1.7.2), + -- and the content field is a SignedData. + -- The eContentType field for the type SignedData is + -- id-pkinit-authData (1.3.6.1.5.2.3.1), and the + -- eContent field contains the DER encoding of the + -- type AuthPack. + -- AuthPack is defined below. + trustedCertifiers [1] SEQUENCE OF + ExternalPrincipalIdentifier OPTIONAL, + + + +Zhu & Tung Expires June 2, 2006 [Page 30] + +Internet-Draft PKINIT November 2005 + + + -- Contains a list of CAs, trusted by the client, + -- that can be used to certify the KDC. + -- Each ExternalPrincipalIdentifier identifies a CA + -- or a CA certificate (thereby its public key). + -- The information contained in the + -- trustedCertifiers SHOULD be used by the KDC as + -- hints to guide its selection of an appropriate + -- certificate chain to return to the client. + kdcPkId [2] IMPLICIT OCTET STRING + OPTIONAL, + -- Contains a CMS type SignerIdentifier encoded + -- according to [RFC3852]. + -- Identifies, if present, a particular KDC + -- public key that the client already has. + ... + } + + DHNonce ::= OCTET STRING + + ExternalPrincipalIdentifier ::= SEQUENCE { + subjectName [0] IMPLICIT OCTET STRING OPTIONAL, + -- Contains a PKIX type Name encoded according to + -- [RFC3280]. + -- Identifies the certificate subject by the + -- distinguished subject name. + -- REQUIRED when there is a distinguished subject + -- name present in the certificate. + issuerAndSerialNumber [1] IMPLICIT OCTET STRING OPTIONAL, + -- Contains a CMS type IssuerAndSerialNumber encoded + -- according to [RFC3852]. + -- Identifies a certificate of the subject. + -- REQUIRED for TD-INVALID-CERTIFICATES and + -- TD-TRUSTED-CERTIFIERS. + subjectKeyIdentifier [2] IMPLICIT OCTET STRING OPTIONAL, + -- Identifies the subject's public key by a key + -- identifier. When an X.509 certificate is + -- referenced, this key identifier matches the X.509 + -- subjectKeyIdentifier extension value. When other + -- certificate formats are referenced, the documents + -- that specify the certificate format and their use + -- with the CMS must include details on matching the + -- key identifier to the appropriate certificate + -- field. + -- RECOMMENDED for TD-TRUSTED-CERTIFIERS. + ... + } + + AuthPack ::= SEQUENCE { + + + +Zhu & Tung Expires June 2, 2006 [Page 31] + +Internet-Draft PKINIT November 2005 + + + pkAuthenticator [0] PKAuthenticator, + clientPublicValue [1] SubjectPublicKeyInfo OPTIONAL, + -- Type SubjectPublicKeyInfo is defined in + -- [RFC3280]. + -- Specifies Diffie-Hellman domain parameters + -- and the client's public key value [IEEE1363]. + -- The DH public key value is encoded as a BIT + -- STRING according to [RFC3279]. + -- This field is present only if the client wishes + -- to use the Diffie-Hellman key agreement method. + supportedCMSTypes [2] SEQUENCE OF AlgorithmIdentifier + OPTIONAL, + -- Type AlgorithmIdentifier is defined in + -- [RFC3280]. + -- List of CMS encryption types supported by the + -- client in order of (decreasing) preference. + clientDHNonce [3] DHNonce OPTIONAL, + -- Present only if the client indicates that it + -- wishes to reuse DH keys or to allow the KDC to + -- do so. + ... + } + + PKAuthenticator ::= SEQUENCE { + cusec [0] INTEGER (0..999999), + ctime [1] KerberosTime, + -- cusec and ctime are used as in [RFC4120], for + -- replay prevention. + nonce [2] INTEGER (0..4294967295), + -- Chosen randomly; This nonce does not need to + -- match with the nonce in the KDC-REQ-BODY. + paChecksum [3] OCTET STRING, + -- Contains the SHA1 checksum, performed over + -- KDC-REQ-BODY. + ... + } + + TD-TRUSTED-CERTIFIERS ::= SEQUENCE OF + ExternalPrincipalIdentifier + -- Identifies a list of CAs trusted by the KDC. + -- Each ExternalPrincipalIdentifier identifies a CA + -- or a CA certificate (thereby its public key). + + TD-INVALID-CERTIFICATES ::= SEQUENCE OF + ExternalPrincipalIdentifier + -- Each ExternalPrincipalIdentifier identifies a + -- certificate (sent by the client) with an invalid + -- signature. + + + +Zhu & Tung Expires June 2, 2006 [Page 32] + +Internet-Draft PKINIT November 2005 + + + KRB5PrincipalName ::= SEQUENCE { + realm [0] Realm, + principalName [1] PrincipalName + } + + AD-INITIAL-VERIFIED-CAS ::= SEQUENCE OF + ExternalPrincipalIdentifier + -- Identifies the certification path based on which + -- the client certificate was validated. + -- Each ExternalPrincipalIdentifier identifies a CA + -- or a CA certificate (thereby its public key). + + PA-PK-AS-REP ::= CHOICE { + dhInfo [0] DHRepInfo, + -- Selected when Diffie-Hellman key exchange is + -- used. + encKeyPack [1] IMPLICIT OCTET STRING, + -- Selected when public key encryption is used. + -- Contains a CMS type ContentInfo encoded + -- according to [RFC3852]. + -- The contentType field of the type ContentInfo is + -- id-envelopedData (1.2.840.113549.1.7.3). + -- The content field is an EnvelopedData. + -- The contentType field for the type EnvelopedData + -- is id-signedData (1.2.840.113549.1.7.2). + -- The eContentType field for the inner type + -- SignedData (when unencrypted) is + -- id-pkinit-rkeyData (1.3.6.1.5.2.3.3) and the + -- eContent field contains the DER encoding of the + -- type ReplyKeyPack. + -- ReplyKeyPack is defined below. + ... + } + + DHRepInfo ::= SEQUENCE { + dhSignedData [0] IMPLICIT OCTET STRING, + -- Contains a CMS type ContentInfo encoded according + -- to [RFC3852]. + -- The contentType field of the type ContentInfo is + -- id-signedData (1.2.840.113549.1.7.2), and the + -- content field is a SignedData. + -- The eContentType field for the type SignedData is + -- id-pkinit-DHKeyData (1.3.6.1.5.2.3.2), and the + -- eContent field contains the DER encoding of the + -- type KDCDHKeyInfo. + -- KDCDHKeyInfo is defined below. + serverDHNonce [1] DHNonce OPTIONAL + -- Present if and only if dhKeyExpiration is + + + +Zhu & Tung Expires June 2, 2006 [Page 33] + +Internet-Draft PKINIT November 2005 + + + -- present. + } + + KDCDHKeyInfo ::= SEQUENCE { + subjectPublicKey [0] BIT STRING, + -- The KDC's DH public key. + -- The DH public key value is encoded as a BIT + -- STRING according to [RFC3279]. + nonce [1] INTEGER (0..4294967295), + -- Contains the nonce in the pkAuthenticator field + -- in the request if the DH keys are NOT reused, + -- 0 otherwise. + dhKeyExpiration [2] KerberosTime OPTIONAL, + -- Expiration time for KDC's key pair, + -- present if and only if the DH keys are reused. + -- If present, the KDC's DH public key MUST not be + -- used past the point of this expiration time. + -- If this field is omitted then the serverDHNonce + -- field MUST also be omitted. + ... + } + + ReplyKeyPack ::= SEQUENCE { + replyKey [0] EncryptionKey, + -- Contains the session key used to encrypt the + -- enc-part field in the AS-REP, i.e. the + -- AS reply key. + asChecksum [1] Checksum, + -- Contains the checksum of the AS-REQ + -- corresponding to the containing AS-REP. + -- The checksum is performed over the type AS-REQ. + -- The protocol key [RFC3961] of the checksum is the + -- replyKey and the key usage number is 6. + -- If the replyKey's enctype is "newer" [RFC4120] + -- [RFC4121], the checksum is the required + -- checksum operation [RFC3961] for that enctype. + -- The client MUST verify this checksum upon receipt + -- of the AS-REP. + ... + } + + TD-DH-PARAMETERS ::= SEQUENCE OF AlgorithmIdentifier + -- Each AlgorithmIdentifier specifies a set of + -- Diffie-Hellman domain parameters [IEEE1363]. + -- This list is in decreasing preference order. + END + + + + + +Zhu & Tung Expires June 2, 2006 [Page 34] + +Internet-Draft PKINIT November 2005 + + +Appendix B. Test Vectors + + Function octetstring2key() is defined in Section 3.2.3.1. This + section describes a few sets of test vectors that would be useful for + implementers of octetstring2key(). + + + Set 1 + ===== + Input octet string x is: + + 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 + 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 + 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 + 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 + 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 + 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 + 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 + 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 + 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 + 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 + 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 + 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 + 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 + 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 + 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 + 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 + + Output of K-truncate() when the key size is 32 octets: + + 5e e5 0d 67 5c 80 9f e5 9e 4a 77 62 c5 4b 65 83 + 75 47 ea fb 15 9b d8 cd c7 5f fc a5 91 1e 4c 41 + + + Set 2: + ===== + Input octet string x is: + + 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 + 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 + 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 + 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 + 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 + 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 + 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 + 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 + + Output of K-truncate() when the key size is 32 octets: + + + +Zhu & Tung Expires June 2, 2006 [Page 35] + +Internet-Draft PKINIT November 2005 + + + ac f7 70 7c 08 97 3d df db 27 cd 36 14 42 cc fb + a3 55 c8 88 4c b4 72 f3 7d a6 36 d0 7d 56 78 7e + + + Set 3: + ====== + Input octet string x is: + + 00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f + 10 00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e + 0f 10 00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d + 0e 0f 10 00 01 02 03 04 05 06 07 08 09 0a 0b 0c + 0d 0e 0f 10 00 01 02 03 04 05 06 07 08 09 0a 0b + 0c 0d 0e 0f 10 00 01 02 03 04 05 06 07 08 09 0a + 0b 0c 0d 0e 0f 10 00 01 02 03 04 05 06 07 08 09 + 0a 0b 0c 0d 0e 0f 10 00 01 02 03 04 05 06 07 08 + + Output of K-truncate() when the key size is 32 octets: + + c4 42 da 58 5f cb 80 e4 3b 47 94 6f 25 40 93 e3 + 73 29 d9 90 01 38 0d b7 83 71 db 3a cf 5c 79 7e + + + Set 4: + ===== + Input octet string x is: + + 00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f + 10 00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e + 0f 10 00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d + 0e 0f 10 00 01 02 03 04 05 06 07 08 09 0a 0b 0c + 0d 0e 0f 10 00 01 02 03 04 05 06 07 08 + + Output of K-truncate() when the key size is 32 octets: + + 00 53 95 3b 84 c8 96 f4 eb 38 5c 3f 2e 75 1c 4a + 59 0e d6 ff ad ca 6f f6 4f 47 eb eb 8d 78 0f fc + + +Appendix C. Miscellaneous Information about Microsoft Windows PKINIT + Implementations + + Earlier revisions of the PKINIT I-D were implemented in various + releases of Microsoft Windows and deployed in fairly large numbers. + To enable the community to better interoperate with systems running + those releases, the following information may be useful. + + KDC certificates issued by Windows 2000 Enterprise CAs contain a + + + +Zhu & Tung Expires June 2, 2006 [Page 36] + +Internet-Draft PKINIT November 2005 + + + dNSName SAN with the DNS name of the host running the KDC, and the + id-kp-serverAuth EKU [RFC3280]. + + KDC certificates issued by Windows 2003 Enterprise CAs contain a + dNSName SAN with the DNS name of the host running the KDC, the id-kp- + serverAuth EKU and the id-ms-kp-sc-logon EKU. + + It is anticipated that the next release of Windows is already too far + along to allow it to support the issuing KDC certificates with id- + pkinit-san SAN as specified in this RFC. Instead, they will have a + dNSName SAN containing the domain name of the KDC and the intended + purpose of these KDC certificates be restricted by the presence of + the id-pkinit-KPKdc EKU and id-kp-serverAuth EKU. + + In addition to checking that the above are present in a KDC + certificate, Windows clients verify that the issuer of the KDC + certificate is one of a set of allowed issuers of such certificates, + so those wishing to issue KDC certificates need to configure their + Windows clients appropriately. + + Client certificates accepted by Windows 2000 and Windows 2003 Server + KDCs must contain an id-ms-san-sc-logon-upn (1.3.6.1.4.1.311.20.2.3) + SAN and the id-ms-kp-sc-logon EKU. The id-ms-san-sc-logon-upn SAN + contains a UTF8 encoded string whose value is that of the Directory + Service attribute UserPrincipalName of the client account object, and + the purpose of including the id-ms-san-sc-logon-upn SAN in the client + certificate is to validate the client mapping (in other words, the + client's public key is bound to the account that has this + UserPrincipalName value). + + It should be noted that all Microsoft Kerberos realm names are domain + style realm names and strictly in upper case. In addition, the + UserPrincipalName attribute is globally unique in Windows 2000 and + Windows 2003. + + + + + + + + + + + + + + + + + +Zhu & Tung Expires June 2, 2006 [Page 37] + +Internet-Draft PKINIT November 2005 + + +Authors' Addresses + + Larry Zhu + Microsoft Corporation + One Microsoft Way + Redmond, WA 98052 + US + + Email: lzhu@microsoft.com + + + Brian Tung + USC Information Sciences Institute + 4676 Admiralty Way Suite 1001 + Marina del Rey, CA 90292 + US + + Email: brian@isi.edu + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Zhu & Tung Expires June 2, 2006 [Page 38] + +Internet-Draft PKINIT November 2005 + + +Intellectual Property Statement + + The IETF takes no position regarding the validity or scope of any + Intellectual Property Rights or other rights that might be claimed to + pertain to the implementation or use of the technology described in + this document or the extent to which any license under such rights + might or might not be available; nor does it represent that it has + made any independent effort to identify any such rights. Information + on the procedures with respect to rights in RFC documents can be + found in BCP 78 and BCP 79. + + Copies of IPR disclosures made to the IETF Secretariat and any + assurances of licenses to be made available, or the result of an + attempt made to obtain a general license or permission for the use of + such proprietary rights by implementers or users of this + specification can be obtained from the IETF on-line IPR repository at + http://www.ietf.org/ipr. + + The IETF invites any interested party to bring to its attention any + copyrights, patents or patent applications, or other proprietary + rights that may cover technology that may be required to implement + this standard. Please address the information to the IETF at + ietf-ipr@ietf.org. + + +Disclaimer of Validity + + This document and the information contained herein are provided on an + "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS + OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET + ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, + INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE + INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED + WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. + + +Copyright Statement + + Copyright (C) The Internet Society (2005). This document is subject + to the rights, licenses and restrictions contained in BCP 78, and + except as set forth therein, the authors retain all their rights. + + +Acknowledgment + + Funding for the RFC Editor function is currently provided by the + Internet Society. + + + + +Zhu & Tung Expires June 2, 2006 [Page 39] diff --git a/doc/standardisation/draft-ietf-cat-kerberos-pk-init-31.txt b/doc/standardisation/draft-ietf-cat-kerberos-pk-init-31.txt index 713ea0259..5a0799144 100644 --- a/doc/standardisation/draft-ietf-cat-kerberos-pk-init-31.txt +++ b/doc/standardisation/draft-ietf-cat-kerberos-pk-init-31.txt @@ -3,9 +3,9 @@ NETWORK WORKING GROUP L. Zhu Internet-Draft Microsoft Corporation -Expires: June 24, 2006 B. Tung +Expires: June 15, 2006 B. Tung USC Information Sciences Institute - December 21, 2005 + December 12, 2005 Public Key Cryptography for Initial Authentication in Kerberos @@ -34,7 +34,7 @@ Status of this Memo The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. - This Internet-Draft will expire on June 24, 2006. + This Internet-Draft will expire on June 15, 2006. Copyright Notice @@ -52,7 +52,7 @@ Abstract -Zhu & Tung Expires June 24, 2006 [Page 1] +Zhu & Tung Expires June 15, 2006 [Page 1] Internet-Draft PKINIT December 2005 @@ -60,31 +60,31 @@ Internet-Draft PKINIT December 2005 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 - 2. Conventions Used in This Document . . . . . . . . . . . . . . 5 - 3. Extensions . . . . . . . . . . . . . . . . . . . . . . . . . . 5 - 3.1. Definitions, Requirements, and Constants . . . . . . . . . 6 - 3.1.1. Required Algorithms . . . . . . . . . . . . . . . . . 6 - 3.1.2. Defined Message and Encryption Types . . . . . . . . . 6 - 3.1.3. Algorithm Identifiers . . . . . . . . . . . . . . . . 7 - 3.2. PKINIT Pre-authentication Syntax and Use . . . . . . . . . 9 - 3.2.1. Generation of Client Request . . . . . . . . . . . . . 9 - 3.2.2. Receipt of Client Request . . . . . . . . . . . . . . 13 - 3.2.3. Generation of KDC Reply . . . . . . . . . . . . . . . 17 - 3.2.4. Receipt of KDC Reply . . . . . . . . . . . . . . . . . 24 - 3.3. Interoperability Requirements . . . . . . . . . . . . . . 25 - 3.4. KDC Indication of PKINIT Support . . . . . . . . . . . . . 26 - 4. Security Considerations . . . . . . . . . . . . . . . . . . . 26 - 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 28 - 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 29 - 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 29 - 7.1. Normative References . . . . . . . . . . . . . . . . . . . 29 - 7.2. Informative References . . . . . . . . . . . . . . . . . . 31 - Appendix A. PKINIT ASN.1 Module . . . . . . . . . . . . . . . . . 31 - Appendix B. Test Vectors . . . . . . . . . . . . . . . . . . . . 36 + 2. Conventions Used in This Document . . . . . . . . . . . . . . 3 + 3. Extensions . . . . . . . . . . . . . . . . . . . . . . . . . . 4 + 3.1. Definitions, Requirements, and Constants . . . . . . . . . 5 + 3.1.1. Required Algorithms . . . . . . . . . . . . . . . . . 5 + 3.1.2. Defined Message and Encryption Types . . . . . . . . . 5 + 3.1.3. Algorithm Identifiers . . . . . . . . . . . . . . . . 6 + 3.2. PKINIT Pre-authentication Syntax and Use . . . . . . . . . 7 + 3.2.1. Generation of Client Request . . . . . . . . . . . . . 7 + 3.2.2. Receipt of Client Request . . . . . . . . . . . . . . 12 + 3.2.3. Generation of KDC Reply . . . . . . . . . . . . . . . 16 + 3.2.4. Receipt of KDC Reply . . . . . . . . . . . . . . . . . 23 + 3.3. Interoperability Requirements . . . . . . . . . . . . . . 24 + 3.4. KDC Indication of PKINIT Support . . . . . . . . . . . . . 25 + 4. Security Considerations . . . . . . . . . . . . . . . . . . . 25 + 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 27 + 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 28 + 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 28 + 7.1. Normative References . . . . . . . . . . . . . . . . . . . 28 + 7.2. Informative References . . . . . . . . . . . . . . . . . . 30 + Appendix A. PKINIT ASN.1 Module . . . . . . . . . . . . . . . . . 30 + Appendix B. Test Vectors . . . . . . . . . . . . . . . . . . . . 35 Appendix C. Miscellaneous Information about Microsoft Windows - PKINIT Implementations . . . . . . . . . . . . . . . 38 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 40 - Intellectual Property and Copyright Statements . . . . . . . . . . 41 + PKINIT Implementations . . . . . . . . . . . . . . . 37 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 39 + Intellectual Property and Copyright Statements . . . . . . . . . . 40 @@ -108,132 +108,49 @@ Table of Contents -Zhu & Tung Expires June 24, 2006 [Page 2] +Zhu & Tung Expires June 15, 2006 [Page 2] Internet-Draft PKINIT December 2005 1. Introduction - The Kerberos V5 protocol [RFC4120] involves use of a trusted third - party known as the Key Distribution Center (KDC) to negotiate shared - session keys between clients and services and provide mutual - authentication between them. + A client typically authenticates itself to a service in Kerberos + using three distinct though related exchanges. First, the client + requests a ticket-granting ticket (TGT) from the Kerberos + authentication server (AS). Then, it uses the TGT to request a + service ticket from the Kerberos ticket-granting server (TGS). + Usually, the AS and TGS are integrated in a single device known as a + Kerberos Key Distribution Center, or KDC. Finally, the client uses + the service ticket to authenticate itself to the service. - The corner-stone of Kerberos V5 is the Ticket and the Authenticator. - A Ticket encapsulates a symmetric key (the ticket session key) in an - envelope (a public message) intended for a specific service. The - contents of the Ticket are encrypted with a symmetric key shared - between the service principal and the issuing KDC. The encrypted - part of the Ticket contains the client principal name, amongst other - items. An Authenticator is a record that can be shown to have been - recently generated using the ticket session key in the associated - Ticket. The ticket session key is known by the client who requested - the ticket. The contents of the Authenticator are encrypted with the - associated ticket session key. The encrypted part of an - Authenticator contains a timestamp and the client principal name, - amongst other items. - - As shown in Figure 1 below, the Kerberos V5 protocol consists of the - following message exchanges between the client and the KDC, and the - client and the application service: - - - The Authentication Service (AS) Exchange - - The client obtains an "initial" ticket from the Kerberos - authentication server (AS), typically a Ticket Granting Ticket - (TGT). The AS-REQ message and the AS-REP message are the request - and the reply message respectively between the client and the AS. - - - The Ticket Granting Service (TGS) Exchange - - The client subsequently uses the TGT to authenticate and request a - service ticket for a particular service, from the Kerberos ticket- - granting server (TGS). The TGS-REQ message and the TGS-REP - message are the request and the reply message respectively between - the client and the TGS. - - - The Client/Server Authentication Protocol (AP) Exchange - - The client then makes a request with an AP-REQ message, consisting - of a service ticket and an authenticator that certifies the - client's possession of the ticket session key. The server may - optionally reply with an AP-REP message. AP exchanges typically - negotiate session specific symmetric keys. - - - - -Zhu & Tung Expires June 24, 2006 [Page 3] - -Internet-Draft PKINIT December 2005 - - - Usually, the AS and TGS are integrated in a single device also known - as the KDC. - - Figure 1: The Message Exchanges in the Kerberos V5 Protocol - - +--------------+ - +--------->| KDC | - AS-REQ / +-------| | - / / +--------------+ - / / ^ | - / |AS-REP / | - | | / TGS-REQ + TGS-REP - | | / / - | | / / - | | / +---------+ - | | / / - | | / / - | | / / - | v / v - ++-------+------+ +-----------------+ - | Client +------------>| Application | - | | AP-REQ | Server | - | |<------------| | - +---------------+ AP-REP +-----------------+ - - In the AS exchange, the KDC reply contains the ticket session key, - amongst other items, that is encrypted using a key (the AS reply key) - shared between the client and the KDC. The AS reply key is typically - derived from the client's password for human users. Therefore for - human users the attack resistance strength of the Kerberos protocol - is no stronger than the strength of their passwords. - - The use of asymmetric cryptography in the form of X.509 certificates - [RFC3280] is popular for facilitating non-repudiation and perfect - secrecy. An established Public Key Infrastructure (PKI) provides key - management and key distribution mechanisms that can be used to - establish authentication and secure communication. Adding public-key - cryptography to Kerberos provides a nice congruence to public-key - protocols, obviates the human users' burden to manage strong - passwords, and allows Kerberized applications to take advantage of - existing key services and identity management. - - The advantage afforded by the Kerberos TGT is that the client exposes - his long-term secrets only once. The TGT and its associated session - key can then be used for any subsequent service ticket requests. One + The advantage afforded by the TGT is that the client exposes his + long-term secrets only once. The TGT and its associated session key + can then be used for any subsequent service ticket requests. One result of this is that all further authentication is independent of the method by which the initial authentication was performed. Consequently, initial authentication provides a convenient place to + integrate public-key cryptography into Kerberos authentication. + As defined in [RFC4120], Kerberos authentication exchanges use + symmetric-key cryptography, in part for performance. One + disadvantage of using symmetric-key cryptography is that the keys + must be shared, so that before a client can authenticate itself, he + must already be registered with the KDC. + Conversely, an established Public Key Infrastructure (PKI) already + provides key management and key distribution mechanisms that are + sufficient to establish authentication and secure communication. + Adding public-key cryptography to Kerberos allows Kerberized + applications to leverage these existing services. In addition, human + users can avoid the inconvenience of managing strong passwords, by + using randomly generated strong public and private key pairs. -Zhu & Tung Expires June 24, 2006 [Page 4] - -Internet-Draft PKINIT December 2005 - - - integrate public-key cryptography into Kerberos authentication. In - addition, the use of symmetric cryptography after the initial - exchange is preferred for performance. - - This document describes the methods and data formats using which the - client and the KDC can use public and private key pairs to mutually - authenticate in the AS exchange and negotiate the AS reply key, known - only by the client and the KDC, to encrypt the AS-REP sent by the - KDC. + As noted above, a convenient and efficient place to introduce public- + key cryptography into Kerberos is in the initial authentication + exchange. This document describes the methods and data formats for + integrating public-key cryptography into Kerberos initial + authentication. 2. Conventions Used in This Document @@ -242,21 +159,35 @@ Internet-Draft PKINIT December 2005 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. + Both the AS and the TGS are referred to as the KDC. + + + + +Zhu & Tung Expires June 15, 2006 [Page 3] + +Internet-Draft PKINIT December 2005 + + In this protocol, both the client and the KDC have a public-private key pair in order to prove their identities to each other over the - open network. The term "signature key" is used to refer to the + open network. The client's key pair is used to authenticate the + client to the KDC, and the KDC's key pair is used to authenticate the + KDC to the client. The term "signature key" is used to refer to the private key of the key pair being used. - The encryption key used to encrypt the enc-part field of the KDC-REP - in the AS-REP [RFC4120] is referred to as the AS reply key. + In this document, the encryption key used to encrypt the enc-part + field of the KDC-REP in the AS-REP [RFC4120] is referred to as the AS + reply key. - An empty sequence in an optional field can be either included or - omitted: both encodings are permitted and considered equivalent. + In this document, an empty sequence in an optional field can be + either included or omitted: both encodings are permitted and + considered equivalent. - The term "Modular Exponential Diffie-Hellman" is used to refer to the - Diffie-Hellman key exchange as described in [RFC2631], in order to - differentiate it from other equivalent representations of the same - key agreement algorithm. + In this document, the term "Modular Exponential Diffie-Hellman" is + used to refer to the Diffie-Hellman key exchange as described in + [RFC2631], in order to differentiate it from other equivalent + representations of the same key agreement algorithm. 3. Extensions @@ -271,16 +202,6 @@ Internet-Draft PKINIT December 2005 preauthenticator contains the client's public-key data and a signature. - - - - - -Zhu & Tung Expires June 24, 2006 [Page 5] - -Internet-Draft PKINIT December 2005 - - 2. The KDC tests the client's request against its authentication policy and trusted Certification Authorities (CAs). @@ -294,6 +215,16 @@ Internet-Draft PKINIT December 2005 b. a symmetric encryption key, signed using the KDC's signature key and encrypted using the client's public key. + + + + + +Zhu & Tung Expires June 15, 2006 [Page 4] + +Internet-Draft PKINIT December 2005 + + Any keying material required by the client to obtain the encryption key for decrypting the KDC reply is returned in a pre- authentication field accompanying the usual reply. @@ -329,14 +260,6 @@ Internet-Draft PKINIT December 2005 PKINIT makes use of the following new pre-authentication types: - - - -Zhu & Tung Expires June 24, 2006 [Page 6] - -Internet-Draft PKINIT December 2005 - - PA_PK_AS_REQ 16 PA_PK_AS_REP 17 @@ -346,6 +269,18 @@ Internet-Draft PKINIT December 2005 PKINIT introduces the following new error codes: + + + + + + + +Zhu & Tung Expires June 15, 2006 [Page 5] + +Internet-Draft PKINIT December 2005 + + KDC_ERR_CLIENT_NOT_TRUSTED 62 KDC_ERR_INVALID_SIG 64 KDC_ERR_DH_KEY_PARAMETERS_NOT_ACCEPTED 65 @@ -354,10 +289,10 @@ Internet-Draft PKINIT December 2005 KDC_ERR_REVOKED_CERTIFICATE 72 KDC_ERR_REVOCATION_STATUS_UNKNOWN 73 KDC_ERR_CLIENT_NAME_MISMATCH 75 - KDC_ERR_INCONSISTENT_KEY_PURPOSE 77 - KDC_ERR_DIGEST_IN_CERT_NOT_ACCEPTED 78 - KDC_ERR_HASH_IN_KDF_NOT_ACCEPTED 79 - KDC_ERR_DIGEST_IN_SIGNED_DATA_NOT_ACCEPTED 80 + KDC_ERR_INCONSISTENT_KEY_PURPOSE 76 + KDC_ERR_DIGEST_IN_CERT_NOT_ACCEPTED 77 + KDC_ERR_HASH_IN_KDF_NOT_ACCEPTED 78 + KDC_ERR_DIGEST_IN_SIGNED_DATA_NOT_ACCEPTED 79 PKINIT uses the following typed data types for errors: @@ -386,13 +321,6 @@ Internet-Draft PKINIT December 2005 PKINIT does not define, but does make use of, the following algorithm identifiers. - - -Zhu & Tung Expires June 24, 2006 [Page 7] - -Internet-Draft PKINIT December 2005 - - PKINIT uses the following algorithm identifier(s) for Modular Exponential Diffie-Hellman key agreement [RFC2631] [RFC3279]: @@ -401,6 +329,14 @@ Internet-Draft PKINIT December 2005 PKINIT uses the following signature algorithm identifiers as defined in [RFC3279]: + + + +Zhu & Tung Expires June 15, 2006 [Page 6] + +Internet-Draft PKINIT December 2005 + + sha-1WithRSAEncryption (RSA with SHA1) md5WithRSAEncryption (RSA with MD5) id-dsa-with-sha1 (DSA with SHA1) @@ -438,17 +374,6 @@ Internet-Draft PKINIT December 2005 des-ede3-cbc-EnvOID 15 -- Indicates that the client supports des-ede3-cbc. - - - - - - -Zhu & Tung Expires June 24, 2006 [Page 8] - -Internet-Draft PKINIT December 2005 - - 3.2. PKINIT Pre-authentication Syntax and Use This section defines the syntax and use of the various pre- @@ -461,6 +386,13 @@ Internet-Draft PKINIT December 2005 PA_PK_AS_REQ and whose padata-value contains the DER encoding of the type PA-PK-AS-REQ, is included. + + +Zhu & Tung Expires June 15, 2006 [Page 7] + +Internet-Draft PKINIT December 2005 + + PA-PK-AS-REQ ::= SEQUENCE { signedAuthPack [0] IMPLICIT OCTET STRING, -- Contains a CMS type ContentInfo encoded @@ -497,14 +429,6 @@ Internet-Draft PKINIT December 2005 ExternalPrincipalIdentifier ::= SEQUENCE { subjectName [0] IMPLICIT OCTET STRING OPTIONAL, -- Contains a PKIX type Name encoded according to - - - -Zhu & Tung Expires June 24, 2006 [Page 9] - -Internet-Draft PKINIT December 2005 - - -- [RFC3280]. -- Identifies the certificate subject by the -- distinguished subject name. @@ -517,6 +441,14 @@ Internet-Draft PKINIT December 2005 -- REQUIRED for TD-INVALID-CERTIFICATES and -- TD-TRUSTED-CERTIFIERS. subjectKeyIdentifier [2] IMPLICIT OCTET STRING OPTIONAL, + + + +Zhu & Tung Expires June 15, 2006 [Page 8] + +Internet-Draft PKINIT December 2005 + + -- Identifies the subject's public key by a key -- identifier. When an X.509 certificate is -- referenced, this key identifier matches the X.509 @@ -554,13 +486,6 @@ Internet-Draft PKINIT December 2005 ... } - - -Zhu & Tung Expires June 24, 2006 [Page 10] - -Internet-Draft PKINIT December 2005 - - PKAuthenticator ::= SEQUENCE { cusec [0] INTEGER (0..999999), ctime [1] KerberosTime, @@ -572,6 +497,14 @@ Internet-Draft PKINIT December 2005 paChecksum [3] OCTET STRING, -- Contains the SHA1 checksum, performed over -- KDC-REQ-BODY. + + + +Zhu & Tung Expires June 15, 2006 [Page 9] + +Internet-Draft PKINIT December 2005 + + ... } @@ -610,13 +543,6 @@ Internet-Draft PKINIT December 2005 preference. The clientDHNonce field is described later in this section. - - -Zhu & Tung Expires June 24, 2006 [Page 11] - -Internet-Draft PKINIT December 2005 - - 6. The ctime field in the PKAuthenticator structure contains the current time on the client's host, and the cusec field contains the microsecond part of the client's timestamp. The ctime and @@ -625,6 +551,16 @@ Internet-Draft PKINIT December 2005 paChecksum field contains a SHA1 checksum that is performed over the KDC-REQ-BODY [RFC4120]. + + + + + +Zhu & Tung Expires June 15, 2006 [Page 10] + +Internet-Draft PKINIT December 2005 + + 7. The certificates field of the type SignedData contains certificates intended to facilitate certification path construction, so that the KDC can verify the signature over the @@ -665,20 +601,22 @@ Internet-Draft PKINIT December 2005 identify the subject's public key thereby the subject principal. This structure is filled out as follows: - - - -Zhu & Tung Expires June 24, 2006 [Page 12] - -Internet-Draft PKINIT December 2005 - - 1. The subjectName field contains a PKIX type Name encoded according to [RFC3280]. This field identifies the certificate subject by the distinguished subject name. This field is REQUIRED when there is a distinguished subject name present in the certificate being used. + + + + + +Zhu & Tung Expires June 15, 2006 [Page 11] + +Internet-Draft PKINIT December 2005 + + 2. The issuerAndSerialNumber field contains a CMS type IssuerAndSerialNumber encoded according to [RFC3852]. This field identifies a certificate of the subject. This field is REQUIRED @@ -721,20 +659,20 @@ Internet-Draft PKINIT December 2005 this error message is a TYPED-DATA (as defined in [RFC4120]) that contains an element whose data-type is TD_TRUSTED_CERTIFIERS, and whose data-value contains the DER encoding of the type TD-TRUSTED- - - - -Zhu & Tung Expires June 24, 2006 [Page 13] - -Internet-Draft PKINIT December 2005 - - CERTIFIERS: TD-TRUSTED-CERTIFIERS ::= SEQUENCE OF ExternalPrincipalIdentifier -- Identifies a list of CAs trusted by the KDC. -- Each ExternalPrincipalIdentifier identifies a CA + + + +Zhu & Tung Expires June 15, 2006 [Page 12] + +Internet-Draft PKINIT December 2005 + + -- or a CA certificate (thereby its public key). Each ExternalPrincipalIdentifier (as defined in Section 3.2.1) in the @@ -777,20 +715,20 @@ Internet-Draft PKINIT December 2005 KDC_ERR_REVOKED_CERTIFICATE; if the KDC attempts to determine the revocation status but is unable to do so, it SHOULD return an error message with the code KDC_ERR_REVOCATION_STATUS_UNKNOWN. The - - - -Zhu & Tung Expires June 24, 2006 [Page 14] - -Internet-Draft PKINIT December 2005 - - certificate or certificates affected are identified exactly as for the error code KDC_ERR_INVALID_CERTIFICATE (see above). Note that the TD_INVALID_CERTIFICATES error data is only used to identify invalid certificates sent by the client in the request. + + + +Zhu & Tung Expires June 15, 2006 [Page 13] + +Internet-Draft PKINIT December 2005 + + The client's public key is then used to verify the signature. If the signature fails to verify, the KDC MUST return an error message with the code KDC_ERR_INVALID_SIG. There is no accompanying e-data for @@ -833,20 +771,20 @@ Internet-Draft PKINIT December 2005 KDC_ERR_CLIENT_NAME_MISMATCH. There is no accompanying e-data for this error message. - - - -Zhu & Tung Expires June 24, 2006 [Page 15] - -Internet-Draft PKINIT December 2005 - - Even if the certification path is validated and the certificate is mapped to the client's principal name, the KDC may decide not to accept the client's certificate, depending on local policy. The KDC MAY require the presence of an Extended Key Usage (EKU) KeyPurposeId [RFC3280] id-pkinit-KPClientAuth in the extensions field + + + +Zhu & Tung Expires June 15, 2006 [Page 14] + +Internet-Draft PKINIT December 2005 + + of the client's X.509 certificate: id-pkinit-KPClientAuth OBJECT IDENTIFIER ::= @@ -890,18 +828,19 @@ Internet-Draft PKINIT December 2005 check fails, the KDC MUST return error code KRB_AP_ERR_REPEAT or KRB_AP_ERR_SKEW, respectively. - - -Zhu & Tung Expires June 24, 2006 [Page 16] - -Internet-Draft PKINIT December 2005 - - If the clientPublicValue is filled in, indicating that the client wishes to use the Diffie-Hellman key agreement method, the KDC SHOULD check to see if the key parameters satisfy its policy. If they do not, it MUST return an error message with the code KDC_ERR_DH_KEY_PARAMETERS_NOT_ACCEPTED. The accompanying e-data is a + + + +Zhu & Tung Expires June 15, 2006 [Page 15] + +Internet-Draft PKINIT December 2005 + + TYPED-DATA that contains an element whose data-type is TD_DH_PARAMETERS, and whose data-value contains the DER encoding of the type TD-DH-PARAMETERS: @@ -945,19 +884,19 @@ Internet-Draft PKINIT December 2005 -- Identifies the certification path based on which -- the client certificate was validated. -- Each ExternalPrincipalIdentifier identifies a CA - - - -Zhu & Tung Expires June 24, 2006 [Page 17] - -Internet-Draft PKINIT December 2005 - - -- or a CA certificate (thereby its public key). The AD-INITIAL-VERIFIED-CAS structure identifies the certification path based on which the client certificate was validated. Each ExternalPrincipalIdentifier (as defined in Section 3.2.1) in the AD- + + + +Zhu & Tung Expires June 15, 2006 [Page 16] + +Internet-Draft PKINIT December 2005 + + INITIAL-VERIFIED-CAS structure identifies a CA or a CA certificate (thereby its public key). @@ -1001,19 +940,19 @@ Internet-Draft PKINIT December 2005 -- SignedData (when unencrypted) is -- id-pkinit-rkeyData (1.3.6.1.5.2.3.3) and the -- eContent field contains the DER encoding of the - - - -Zhu & Tung Expires June 24, 2006 [Page 18] - -Internet-Draft PKINIT December 2005 - - -- type ReplyKeyPack. -- ReplyKeyPack is defined in Section 3.2.3.2. ... } + + + +Zhu & Tung Expires June 15, 2006 [Page 17] + +Internet-Draft PKINIT December 2005 + + DHRepInfo ::= SEQUENCE { dhSignedData [0] IMPLICIT OCTET STRING, -- Contains a CMS type ContentInfo encoded according @@ -1057,19 +996,19 @@ Internet-Draft PKINIT December 2005 Diffie-Hellman exchange, or a generated encryption key. The contents of the PA-PK-AS-REP indicate which key delivery method is used. - - - -Zhu & Tung Expires June 24, 2006 [Page 19] - -Internet-Draft PKINIT December 2005 - - In addition, the lifetime of the ticket returned by the KDC MUST NOT exceed that of the client's public-private key pair. The ticket lifetime, however, can be shorter than that of the client's public- private key pair. For the implementations of this specification, the lifetime of the client's public-private key pair is the validity + + + +Zhu & Tung Expires June 15, 2006 [Page 18] + +Internet-Draft PKINIT December 2005 + + period in X.509 certificates [RFC3280], unless configured otherwise. 3.2.3.1. Using Diffie-Hellman Key Exchange @@ -1111,16 +1050,6 @@ Internet-Draft PKINIT December 2005 signerInfo, which contains the signature over the type KDCDHKeyInfo. - - - - - -Zhu & Tung Expires June 24, 2006 [Page 20] - -Internet-Draft PKINIT December 2005 - - 6. The certificates field of the type SignedData contains certificates intended to facilitate certification path construction, so that the client can verify the KDC's signature @@ -1128,6 +1057,14 @@ Internet-Draft PKINIT December 2005 trustedCertifiers in the request SHOULD be used by the KDC as hints to guide its selection of an appropriate certificate chain to return to the client. This field may be left empty if the KDC + + + +Zhu & Tung Expires June 15, 2006 [Page 19] + +Internet-Draft PKINIT December 2005 + + public key specified by the kdcPkId field in the PA-PK-AS-REQ was used for signing. Otherwise, for path validation, these certificates SHOULD be sufficient to construct at least one @@ -1168,20 +1105,22 @@ Internet-Draft PKINIT December 2005 key and yb is the KDC's public key. If both ya and yb are the same in a later exchange, the cached DHSharedSecret can be used. - - - - -Zhu & Tung Expires June 24, 2006 [Page 21] - -Internet-Draft PKINIT December 2005 - - 2. Let K be the key-generation seed length [RFC3961] of the AS reply key whose enctype is selected according to [RFC4120]. 3. Define the function octetstring2key() as follows: + + + + + + +Zhu & Tung Expires June 15, 2006 [Page 20] + +Internet-Draft PKINIT December 2005 + + octetstring2key(x) == random-to-key(K-truncate( SHA1(0x00 | x) | SHA1(0x01 | x) | @@ -1226,17 +1165,18 @@ Internet-Draft PKINIT December 2005 signedData: { iso (1) member-body (2) us (840) rsadsi (113549) pkcs (1) pkcs7 (7) signedData (2) }. - - -Zhu & Tung Expires June 24, 2006 [Page 22] - -Internet-Draft PKINIT December 2005 - - 3. The eContentType field for the inner type SignedData (when decrypted from the encryptedContent field for the type EnvelopedData) is id-pkinit-rkeyData: { iso(1) org(3) dod(6) internet(1) security(5) kerberosv5(2) pkinit(3) rkeyData(3) }. + + + +Zhu & Tung Expires June 15, 2006 [Page 21] + +Internet-Draft PKINIT December 2005 + + Notes to CMS implementers: the signed attribute content-type MUST be present in this SignedData instance and its value is id- pkinit-rkeyData according to [RFC3852]. @@ -1281,17 +1221,18 @@ Internet-Draft PKINIT December 2005 request. This checksum is performed over the type AS-REQ and the protocol key [RFC3961] of the checksum operation is the replyKey and the key usage number is 6. If the replyKey's enctype is "newer" + [RFC4120] [RFC4121], the checksum operation is the required checksum + operation [RFC3961] of that enctype. -Zhu & Tung Expires June 24, 2006 [Page 23] + + +Zhu & Tung Expires June 15, 2006 [Page 22] Internet-Draft PKINIT December 2005 - [RFC4120] [RFC4121], the checksum operation is the required checksum - operation [RFC3961] of that enctype. - ReplyKeyPack ::= SEQUENCE { replyKey [0] EncryptionKey, -- Contains the session key used to encrypt the @@ -1338,15 +1279,16 @@ Internet-Draft PKINIT December 2005 matches the name of the TGS of the target realm (as defined in Section 7.3 of [RFC4120]). + Unless the client knows by some other means that the KDC certificate + is intended for a Kerberos KDC, the client MUST require that the KDC -Zhu & Tung Expires June 24, 2006 [Page 24] + +Zhu & Tung Expires June 15, 2006 [Page 23] Internet-Draft PKINIT December 2005 - Unless the client knows by some other means that the KDC certificate - is intended for a Kerberos KDC, the client MUST require that the KDC certificate contains the EKU KeyPurposeId [RFC3280] id-pkinit-KPKdc: id-pkinit-KPKdc OBJECT IDENTIFIER ::= @@ -1393,16 +1335,16 @@ Internet-Draft PKINIT December 2005 If the KDC sends all the X.509 certificates on a certification path to a trust anchor acceptable by the client, and the client can not + verify the KDC's public key otherwise, the client MUST be able to + process path validation for the KDC's certificate based on the -Zhu & Tung Expires June 24, 2006 [Page 25] +Zhu & Tung Expires June 15, 2006 [Page 24] Internet-Draft PKINIT December 2005 - verify the KDC's public key otherwise, the client MUST be able to - process path validation for the KDC's certificate based on the certificates in the reply. 3.4. KDC Indication of PKINIT Support @@ -1449,16 +1391,16 @@ Internet-Draft PKINIT December 2005 be regulated strictly in protocol definitions. We will address them in this section. + PKINIT extends the cross-realm model to the public-key + infrastructure. Users of PKINIT must understand security policies -Zhu & Tung Expires June 24, 2006 [Page 26] +Zhu & Tung Expires June 15, 2006 [Page 25] Internet-Draft PKINIT December 2005 - PKINIT extends the cross-realm model to the public-key - infrastructure. Users of PKINIT must understand security policies and procedures appropriate to the use of Public Key Infrastructures [RFC3280]. @@ -1505,16 +1447,16 @@ Internet-Draft PKINIT December 2005 Care should be taken in how certificates are chosen for the purposes of authentication using PKINIT. Some local policies may require that + key escrow be used for certain certificate types. Deployers of + PKINIT should be aware of the implications of using certificates that -Zhu & Tung Expires June 24, 2006 [Page 27] +Zhu & Tung Expires June 15, 2006 [Page 26] Internet-Draft PKINIT December 2005 - key escrow be used for certain certificate types. Deployers of - PKINIT should be aware of the implications of using certificates that have escrowed keys for the purposes of authentication. Because signing only certificates are normally not escrowed, by using DH based key delivery this is avoided. @@ -1561,16 +1503,16 @@ Internet-Draft PKINIT December 2005 Special thanks to Clifford Neuman, Matthew Hur, Sasha Medvinsky and Jonathan Trostle who wrote earlier versions of this document. + The authors are indebted to the Kerberos working group chair Jeffrey + Hutzelman who kept track of various issues and was enormously helpful -Zhu & Tung Expires June 24, 2006 [Page 28] +Zhu & Tung Expires June 15, 2006 [Page 27] Internet-Draft PKINIT December 2005 - The authors are indebted to the Kerberos working group chair Jeffrey - Hutzelman who kept track of various issues and was enormously helpful during the creation of this document. Some of the ideas on which this document is based arose during @@ -1618,14 +1560,15 @@ Internet-Draft PKINIT December 2005 Certificate Revocation List (CRL) Profile", RFC 3280, April 2002. + [RFC3370] Housley, R., "Cryptographic Message Syntax (CMS) -Zhu & Tung Expires June 24, 2006 [Page 29] + +Zhu & Tung Expires June 15, 2006 [Page 28] Internet-Draft PKINIT December 2005 - [RFC3370] Housley, R., "Cryptographic Message Syntax (CMS) Algorithms", RFC 3370, August 2002. [RFC3447] Jonsson, J. and B. Kaliski, "Public-Key Cryptography @@ -1675,8 +1618,7 @@ Internet-Draft PKINIT December 2005 - -Zhu & Tung Expires June 24, 2006 [Page 30] +Zhu & Tung Expires June 15, 2006 [Page 29] Internet-Draft PKINIT December 2005 @@ -1688,7 +1630,7 @@ Internet-Draft PKINIT December 2005 [ODL99] Odlyzko, A., "Discrete logarithms: The past and the future, Designs, Codes, and Cryptography (1999)". - + [RFC4158] Cooper, M., Dzambasow, Y., Hesse, P., Joseph, S., and R. Nicholas, "Internet X.509 Public Key Infrastructure: Certification Path Building", RFC 4158, September 2005. @@ -1730,7 +1672,7 @@ Appendix A. PKINIT ASN.1 Module -Zhu & Tung Expires June 24, 2006 [Page 31] +Zhu & Tung Expires June 15, 2006 [Page 30] Internet-Draft PKINIT December 2005 @@ -1786,7 +1728,7 @@ Internet-Draft PKINIT December 2005 -Zhu & Tung Expires June 24, 2006 [Page 32] +Zhu & Tung Expires June 15, 2006 [Page 31] Internet-Draft PKINIT December 2005 @@ -1842,7 +1784,7 @@ Internet-Draft PKINIT December 2005 -Zhu & Tung Expires June 24, 2006 [Page 33] +Zhu & Tung Expires June 15, 2006 [Page 32] Internet-Draft PKINIT December 2005 @@ -1898,7 +1840,7 @@ Internet-Draft PKINIT December 2005 -Zhu & Tung Expires June 24, 2006 [Page 34] +Zhu & Tung Expires June 15, 2006 [Page 33] Internet-Draft PKINIT December 2005 @@ -1954,7 +1896,7 @@ Internet-Draft PKINIT December 2005 -Zhu & Tung Expires June 24, 2006 [Page 35] +Zhu & Tung Expires June 15, 2006 [Page 34] Internet-Draft PKINIT December 2005 @@ -2010,7 +1952,7 @@ Appendix B. Test Vectors -Zhu & Tung Expires June 24, 2006 [Page 36] +Zhu & Tung Expires June 15, 2006 [Page 35] Internet-Draft PKINIT December 2005 @@ -2066,7 +2008,7 @@ Internet-Draft PKINIT December 2005 -Zhu & Tung Expires June 24, 2006 [Page 37] +Zhu & Tung Expires June 15, 2006 [Page 36] Internet-Draft PKINIT December 2005 @@ -2122,7 +2064,7 @@ Appendix C. Miscellaneous Information about Microsoft Windows PKINIT -Zhu & Tung Expires June 24, 2006 [Page 38] +Zhu & Tung Expires June 15, 2006 [Page 37] Internet-Draft PKINIT December 2005 @@ -2178,7 +2120,7 @@ Internet-Draft PKINIT December 2005 -Zhu & Tung Expires June 24, 2006 [Page 39] +Zhu & Tung Expires June 15, 2006 [Page 38] Internet-Draft PKINIT December 2005 @@ -2234,7 +2176,7 @@ Authors' Addresses -Zhu & Tung Expires June 24, 2006 [Page 40] +Zhu & Tung Expires June 15, 2006 [Page 39] Internet-Draft PKINIT December 2005 @@ -2290,6 +2232,6 @@ Acknowledgment -Zhu & Tung Expires June 24, 2006 [Page 41] +Zhu & Tung Expires June 15, 2006 [Page 40] diff --git a/doc/standardisation/draft-ietf-cat-kerberos-pk-init-32.txt b/doc/standardisation/draft-ietf-cat-kerberos-pk-init-32.txt index c72a33a6f..b575aaaed 100644 --- a/doc/standardisation/draft-ietf-cat-kerberos-pk-init-32.txt +++ b/doc/standardisation/draft-ietf-cat-kerberos-pk-init-32.txt @@ -1,6 +1,3 @@ - - - NETWORK WORKING GROUP L. Zhu Internet-Draft Microsoft Corporation Expires: July 15, 2006 B. Tung @@ -2289,5 +2286,3 @@ Acknowledgment Zhu & Tung Expires July 15, 2006 [Page 41] - - diff --git a/doc/standardisation/draft-ietf-cat-kerberos-pk-init-33.txt b/doc/standardisation/draft-ietf-cat-kerberos-pk-init-33.txt index 0cefad7de..6f84c1a71 100644 --- a/doc/standardisation/draft-ietf-cat-kerberos-pk-init-33.txt +++ b/doc/standardisation/draft-ietf-cat-kerberos-pk-init-33.txt @@ -1,6 +1,3 @@ - - - NETWORK WORKING GROUP L. Zhu Internet-Draft Microsoft Corporation Expires: July 28, 2006 B. Tung @@ -426,7 +423,7 @@ Internet-Draft PKINIT January 2006 Kerberos Encryption Type Name Num Corresponding Algorithm OID ============================== === =============================== - id-dsa-with-sha1-CmsOID 9 id-dsa-with-sha1 [RFC3279] + id-dsa-with-sha1-CmsOID 9 id-dsa-with-sha1 [RFC3279] md5WithRSAEncryption-CmsOID 10 md5WithRSAEncryption [RFC3279] sha-1WithRSAEncryption-CmsOID 11 sha-1WithRSAEncryption [RFC3279] rc2-cbc-EnvOID 12 rc2-cbc [RFC3370] @@ -455,8 +452,8 @@ Internet-Draft PKINIT January 2006 For maximum interoperability, however, PKINIT clients wishing to indicate to the KDC the support for one or more of the algorithms - listed above SHOULD include the corresponding encryption type - number(s) in the etype field of the AS-REQ. + listed above SHOULD include the corresponding encryption type numbers + in the etype field of the AS-REQ. 3.2. PKINIT Pre-authentication Syntax and Use @@ -2336,5 +2333,3 @@ Acknowledgment Zhu & Tung Expires July 28, 2006 [Page 42] - - diff --git a/doc/standardisation/draft-ietf-cat-kerberos-pk-init-34.txt b/doc/standardisation/draft-ietf-cat-kerberos-pk-init-34.txt index f56238325..af84a08ff 100644 --- a/doc/standardisation/draft-ietf-cat-kerberos-pk-init-34.txt +++ b/doc/standardisation/draft-ietf-cat-kerberos-pk-init-34.txt @@ -1,6 +1,3 @@ - - - NETWORK WORKING GROUP L. Zhu Internet-Draft Microsoft Corporation Expires: August 11, 2006 B. Tung @@ -2347,5 +2344,3 @@ Acknowledgment Zhu & Tung Expires August 11, 2006 [Page 42] - -