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