+++ /dev/null
-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:
-
- <nametype> + ":" + <string>
-
- 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
git.samba.org / samba.git / blobdiff