INTERNET-DRAFT Brian Tungdraft-ietf-cat-kerberos-pk-init-07.txtdraft-ietf-cat-kerberos-pk-init-08.txt Clifford Neuman Updates: RFC 1510 ISI expiresMay 15,November 12, 1999John Wray Digital EquipmentMatthew Hur CyberSafe Corporation Ari MedvinskyMatthew HurExcite Sasha MedvinskyCyberSafe CorporationGeneral 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 anInternet-Draft.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 asdraft-ietf-cat-kerberos-pk-init-07.txt,draft-ietf-cat-kerberos-pk-init-09.txt, and expiresMay 15,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.One of the guiding principlesPKINIT utilizes Diffie-Hellman keys in combination with digital signature keys as thedesignprimary, required mechanism. It also allows for the use ofPKINIT isRSA keys. Note thatchanges should be as minimal as possible. As a result,PKINIT supports thebasic mechanismuse 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 certificateaccompaniesand a signature accompany the initialrequest,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 encryptedinutilizing either arandomly-generated key, instead ofDiffie-Hellman derived key or the user'slong-term key (which is derived from a password).public key. Thisrandom keymessage isin turn encrypted usingauthenticated utilizing the public keyfrom 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 digitalsignaturekeys to authenticate using those keys, and for users to store and retrieve private keys onof 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,Thethe 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 overSSLTLS [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 followingchangeschange to RFC 1510areis 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 presentThe user presents a public keycertificates, or they may generate their own session key, signed by their digital signature key. In either case, the end result is that the usercertificate 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.2and 3.3 describedescribes the extensions for thetwoinitial authenticationmethods. 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.method. 3.1. Definitions The extensions involve new preauthentication fields; wepropose the addition ofintroduce the following preauthentication types: PA-PK-AS-REQ 14 PA-PK-AS-REP 15PA-PK-AS-SIGN 16PA-PK-KEY-REQ17 PA-PK-KEY-REP18 PA-PK-KEY-REP 19 The extensions also involve new error types; wepropose the addition ofintroduce 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).(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 toNT-X500-PRINCIPAL.KRB_NT-X500-PRINCIPAL. This new name type is defined as:#define CSFC5c_NT_X500_PRINCIPALKRB_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.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 datastructure: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:rsaEncryption ALGORITHM PARAMETER NULLid-RSAES-OAEP OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-1(1)rsaEncryption(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.StandardPublic 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 useSignedData --the public key from this -- particular certificate chain to -- verify the signaturedefined in CMS [11] -- AuthPack (below) defines the data --requestthat is signed trustedCertifiers[2][1] SEQUENCE OF PrincipalName OPTIONAL, -- CAs that the client trustsserialNumber [3] CertificateSerialNumberkdcCert [2] IssuerAndSerialNumber OPTIONAL --specifyingas defined in CMS [11] -- specifies a particular KDC -- certificate if the client -- already has it; -- must be accompanied by -- a single trustedCertifier }CertificateSerialNumber ::= INTEGER -- asUsage of SignedData: The SignedData data type is specifiedby PKCS #6 [15] SignedAuthPack ::= SEQUENCE { authPack [0] AuthPack, authPackSig [1] Signature, --in the Cryptographic Message Syntax, a product ofauthPack -- using user's privatethe 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 }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]CertificateAlgorithmIdentifier ::= 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 certificatealgorithm ALGORITHM.&id, parameters ALGORITHM.&type } --type determinedas specified bycertType }the X.509 recommendation [10] If the client passesa certificatean 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 andresponse, and to optionally pass the client's Diffie-Hellman public value (i.e. for using DSA in combination with Diffie-Hellman).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). TheuserCert 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. ThetrustedCertifiers 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 typeKDC_ERR_CERTIFICATE_MISMATCH.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. IftrustedCertifiers 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. Ifa 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 allowablewindow.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 ::=SEQUENCECHOICE { -- PA TYPE 15 dhSignedData [0] SignedData, -- Defined in CMS and used only with -- Diffie-Helman key exchange encKeyPack [1]EnvelopedKeyPack,EnvelopedData, -- Defined in CMS -- The temporary key is encrypted -- usingeitherthe client public-- key or the Diffie-Hellmankey --specified by SignedKDCPublicValue.key -- SignedReplyKeyPack, encrypted -- with the temporary key, is also -- included.signedKDCPublicValue [2] SignedKDCPublicValue OPTIONAL, -- if one was passed} Usage of SignedData: If the Diffie-Hellman option is used, dhSignedData in PA-PK-AS-REP provides authenticated Diffie-Hellman parameters of therequest kdcCert [3] SEQUENCE OF Certificate OPTIONAL --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 certificatechain }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: TheEnvelopedKeyPackEnvelopedData data typebelowis specified in the Cryptographic Message Syntax, a product of the S/MIME working group of the IETF. It contains anencryptedtemporary key(eitherencrypted with the PKINIT client's publickey or with a symmetric key, resulting from the Diffie-Hellman exchange).key. It also contains a signed and encrypted reply key.This data structure- The originatorInfo field issimilar to EnvelopedData, definednot required, since that information may be presented inCMS [11] and PKCS #7 [12]. EnvelopedKeyPack ::= SEQUENCE { version Version, -- Always set to 0.the signedData structure that is encrypted within the encryptedContentInfo field. - The optional unprotectedAttrs field is not required for PKINIT. - The recipientInfosRecipientInfos, -- Thisfield is aSET,SET which must contain--exactly onemember. Contains a -- temporary key, encrypted withmember of the-- client'sKeyTransRecipientInfo type for encryption with an RSA public key.This --- The encryptedKey field (in KeyTransRecipientInfo) contains the temporary key which isused to encrypt --encrypted with thereplyPKINIT client's public key. - The encryptedContentInfoEncryptedContentInfo --field contains the signed and encrypted--replykey } Version ::= INTEGER RecipientInfos ::= SET OF RecipientInfo RecipientInfo ::= SEQUENCE { version Version, --key. - The contentType field shallbe 0 rid RecipientIdentifier, -- Since this is an optional field, -- it supports both CMS and PKCS #7 keyEncryptionAlgorithm KeyEncryptionAlgorithmIdentifier, EncryptedKey OCTET STRING --contain thetemporary key,OID value for id-signedData: iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs7(7) signedData(2) - The encryptedContent field is encryptedwith -- the PKINIT client's public key } KeyEncryptionAlgorithmIdentifier ::= AlgorithmIdentifier RecipientIdentifier ::= IssuerAndSerialNumber -- Corresponds todata of theX.509 V3 extension -- SubjectKeyIdentifier. IssuerAndSerialNumber ::= SEQUENCE { issuer Name, -- a distinguished name,CMS type signedData asdefined -- by X.509 serialNumber CertificateSerialNumber } CertificateSerialNumber ::= INTEGER EncryptedContentInfo ::= SEQUENCE { contentType ContentType, --specified below. - The encapContentInfo field must contains the ReplyKeyPack. - The eContentType field shallbe: --contain the OID value for id-data: 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 --data(1) - Theencrypted dataeContent field is data of the type-- SignedReplyKeyPack. } ContentType ::= OBJECT IDENTIFIER ContentEncryptionAlgorithmIdentifier ::= AlgorithmIdentifier SignedReplyKeyPackReplyKeyPack (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 {replyKeyPack-- used only when utilizing Diffie-Hellman nonce [0]ReplyKeyPack, replyKeyPackSig [1] Signature,INTEGER, -- binds responce to the request subjectPublicKey [2] BIT STRING -- Equals public exponent (g^a mod p) -- INTEGER encoded as payload ofreplyKeyPack--using KDC's private keyBIT STRING } ReplyKeyPack ::= SEQUENCE { -- not used for Diffie-Hellman replyKey [0] EncryptionKey, -- used to encrypt main reply --of sameENCTYPE is at least as strong as -- ENCTYPE of session key nonce [1]INTEGERINTEGER, -- 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 certifiershallmust 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 Algorithmsand Data FormatsNot 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 requiredalgorithms and data formats:algorithms: - 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 keys3.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 KeyAuthentication or Public Key Authentication with a Digital Signature.Authentication. However, if these users are registered with the KDC, it is recommended that the database record for these users be modified toinclude threean additionalflagsflag in the attributesfield. 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, indicatesfield to indicate that the user should authenticate usingdigital 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.PKINIT. Ifthe firstthis flag isset, then it sends back an error of type KDC_ERR_PREAUTH_REQUIRED indicating thatset and apreauthentication 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, thenrequest message does not contain theKDC sends back an error of type KDC_ERR_PREAUTH_REQUIRED indicating that aPKINIT preauthenticationfield 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,field, then the KDC sends backanas error of type KDC_ERR_PREAUTH_REQUIRED indicating that a preauthentication field of typePA-PK-KEY-REQPA-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.5.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.6.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]Alan O. Freier, Philip Karlton and PaulT. Dierks, C.Kocher.Allen. TheSSLTLS Protocol, Version3.0 - IETF Draft.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.Hously.Housley. Cryptographic Message Syntax.draft-ietf-smime-cms-04.txt, Marchdraft-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]RonR. Rivest, MIT Laboratory for Computer Science and RSA Data Security, Inc. A Description of the RC2(r) EncryptionAlgorithm, November 1997.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] 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 expiresMay 15,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.eduJohn 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 MedvinskyMatthew HurSasha MedvinskyCyberSafe Corporation 1605 NW Sammamish RoadSuite 310Issaquah WA 98027-5378 Phone: +1206425 391 6000 E-mail:{ari.medvinsky, matt.hur, sasha.medvinsky}@cybersafe.commatt.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