diff --git a/doc/standardisation/draft-ietf-cat-kerberos-pk-init-03.txt b/doc/standardisation/draft-ietf-cat-kerberos-pk-init-03.txt deleted file mode 100644 index d91c087dd..000000000 --- a/doc/standardisation/draft-ietf-cat-kerberos-pk-init-03.txt +++ /dev/null @@ -1,589 +0,0 @@ - -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-10.txt b/doc/standardisation/draft-ietf-cat-kerberos-pk-init-10.txt new file mode 100644 index 000000000..a1327fc5b --- /dev/null +++ b/doc/standardisation/draft-ietf-cat-kerberos-pk-init-10.txt @@ -0,0 +1,958 @@ +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 +