--- /dev/null
+INTERNET-DRAFT Brian Tung
+draft-ietf-cat-kerberos-pk-init-09.txt Clifford Neuman
+Updates: RFC 1510 ISI
+expires December 1, 1999 Matthew Hur
+ CyberSafe Corporation
+ Ari Medvinsky
+ Excite
+ Sasha Medvinsky
+ General Instrument
+ John Wray
+ Iris Associates, Inc.
+ Jonathan Trostle
+ Cisco
+
+ Public Key Cryptography for Initial Authentication in Kerberos
+
+0. Status Of This Memo
+
+ This document is an Internet-Draft and is in full conformance with
+ all provisions of Section 10 of RFC 2026. Internet-Drafts are
+ working documents of the Internet Engineering Task Force (IETF),
+ its areas, and its working groups. Note that other groups may also
+ distribute working documents as Internet-Drafts.
+
+ Internet-Drafts are draft documents valid for a maximum of six
+ months and may be updated, replaced, or obsoleted by other
+ documents at any time. It is inappropriate to use Internet-Drafts
+ as reference material or to cite them other than as "work in
+ progress."
+
+
+ The list of current Internet-Drafts can be accessed at
+ http://www.ietf.org/ietf/1id-abstracts.txt
+
+ The list of Internet-Draft Shadow Directories can be accessed at
+ http://www.ietf.org/shadow.html.
+
+ To learn the current status of any Internet-Draft, please check
+ the "1id-abstracts.txt" listing contained in the Internet-Drafts
+ Shadow Directories on ftp.ietf.org (US East Coast),
+ nic.nordu.net (Europe), ftp.isi.edu (US West Coast), or
+ munnari.oz.au (Pacific Rim).
+
+ The distribution of this memo is unlimited. It is filed as
+ draft-ietf-cat-kerberos-pk-init-09.txt, and expires December 1,
+ 1999. Please send comments to the authors.
+
+1. Abstract
+
+ This document defines extensions (PKINIT) to the Kerberos protocol
+ specification (RFC 1510 [1]) to provide a method for using public
+ key cryptography during initial authentication. The methods
+ defined specify the ways in which preauthentication data fields and
+ error data fields in Kerberos messages are to be used to transport
+ public key data.
+
+2. Introduction
+
+ The popularity of public key cryptography has produced a desire for
+ its support in Kerberos [2]. The advantages provided by public key
+ cryptography include simplified key management (from the Kerberos
+ perspective) and the ability to leverage existing and developing
+ public key certification infrastructures.
+
+ Public key cryptography can be integrated into Kerberos in a number
+ of ways. One is to associate a key pair with each realm, which can
+ then be used to facilitate cross-realm authentication; this is the
+ topic of another draft proposal. Another way is to allow users with
+ public key certificates to use them in initial authentication. This
+ is the concern of the current document.
+
+ PKINIT utilizes Diffie-Hellman keys in combination with digital
+ signature keys as the primary, required mechanism. It also allows
+ for the use of RSA keys. Note that PKINIT supports the use of
+ separate signature and encryption keys.
+
+ PKINIT enables access to Kerberos-secured services based on initial
+ authentication utilizing public key cryptography. PKINIT utilizes
+ standard public key signature and encryption data formats within the
+ standard Kerberos messages. The basic mechanism is as follows: The
+ user sends a request to the KDC as before, except that if that user
+ is to use public key cryptography in the initial authentication
+ step, his certificate and a signature accompany the initial request
+ in the preauthentication fields. Upon receipt of this request, the
+ KDC verifies the certificate and issues a ticket granting ticket
+ (TGT) as before, except that the encPart from the AS-REP message
+ carrying the TGT is now encrypted utilizing either a Diffie-Hellman
+ derived key or the user's public key. This message is authenticated
+ utilizing the public key signature of the KDC.
+
+ The PKINIT specification may also be used as a building block for
+ other specifications. PKCROSS [3] utilizes PKINIT for establishing
+ the inter-realm key and associated inter-realm policy to be applied
+ in issuing cross realm service tickets. As specified in [4],
+ anonymous Kerberos tickets can be issued by applying a NULL
+ signature in combination with Diffie-Hellman in the PKINIT exchange.
+ Additionally, the PKINIT specification may be used for direct peer
+ to peer authentication without contacting a central KDC. This
+ application of PKINIT is described in PKTAPP [5] and is based on
+ concepts introduced in [6, 7]. For direct client-to-server
+ authentication, the client uses PKINIT to authenticate to the end
+ server (instead of a central KDC), which then issues a ticket for
+ itself. This approach has an advantage over TLS [8] in that the
+ server does not need to save state (cache session keys).
+ Furthermore, an additional benefit is that Kerberos tickets can
+ facilitate delegation (see [9]).
+
+3. Proposed Extensions
+
+ This section describes extensions to RFC 1510 for supporting the
+ use of public key cryptography in the initial request for a ticket
+ granting ticket (TGT).
+
+ In summary, the following change to RFC 1510 is proposed:
+
+ * Users may authenticate using either a public key pair or a
+ conventional (symmetric) key. If public key cryptography is
+ used, public key data is transported in preauthentication
+ data fields to help establish identity. The user presents
+ a public key certificate and obtains an ordinary TGT that may
+ be used for subsequent authentication, with such
+ authentication using only conventional cryptography.
+
+ Section 3.1 provides definitions to help specify message formats.
+ Section 3.2 describes the extensions for the initial authentication
+ method.
+
+3.1. Definitions
+
+ The extensions involve new preauthentication fields; we introduce
+ the following preauthentication types:
+
+ PA-PK-AS-REQ 14
+ PA-PK-AS-REP 15
+
+ The extensions also involve new error types; we introduce the
+ following types:
+
+ KDC_ERR_CLIENT_NOT_TRUSTED 62
+ KDC_ERR_KDC_NOT_TRUSTED 63
+ KDC_ERR_INVALID_SIG 64
+ KDC_ERR_KEY_TOO_WEAK 65
+ KDC_ERR_CERTIFICATE_MISMATCH 66
+ KDC_ERR_CANT_VERIFY_CERTIFICATE 70
+ KDC_ERR_INVALID_CERTIFICATE 71
+ KDC_ERR_REVOKED_CERTIFICATE 72
+ KDC_ERR_REVOCATION_STATUS_UNKNOWN 73
+ KDC_ERR_REVOCATION_STATUS_UNAVAILABLE 74
+ KDC_ERR_CLIENT_NAME_MISMATCH 75
+ KDC_ERR_KDC_NAME_MISMATCH 76
+
+ We utilize the following typed data for errors:
+
+ TD-PKINIT-CMS-CERTIFICATES 101
+ TD-KRB-PRINCIPAL 102
+ TD-KRB-REALM 103
+ TD-TRUSTED-CERTIFIERS 104
+ TD-CERTIFICATE-INDEX 105
+
+ We utilize the following encryption types (which map directly to
+ OIDs):
+
+ dsaWithSHA1-CmsOID 9
+ md5WithRSAEncryption-CmsOID 10
+ sha1WithRSAEncryption-CmsOID 11
+ rc2CBC-EnvOID 12
+ rsaEncryption-EnvOID (PKCS#1 v1.5) 13
+ rsaES-OAEP-ENV-OID (PKCS#1 v2.0) 14
+ des-ede3-cbc-Env-OID 15
+
+ These mappings are provided so that a client may send the
+ appropriate enctypes in the AS-REQ message in order to indicate
+ support for the corresponding OIDs (for performing PKINIT).
+
+ In many cases, PKINIT requires the encoding of an X.500 name as a
+ Realm. In these cases, the realm will be represented using a
+ different style, specified in RFC 1510 with the following example:
+
+ NAMETYPE:rest/of.name=without-restrictions
+
+ For a realm derived from an X.500 name, NAMETYPE will have the value
+ X500-RFC2253. The full realm name will appear as follows:
+
+ X500-RFC2253:RFC2253Encode(DistinguishedName)
+
+ where DistinguishedName is an X.500 name, and RFC2253Encode is a
+ readable UTF encoding of an X.500 name, as defined by
+ RFC 2253 [14] (part of LDAPv3).
+
+ To ensure that this encoding is unique, we add the following rule
+ to those specified by RFC 2253:
+
+ The order in which the attributes appear in the RFC 2253
+ encoding must be the reverse of the order in the ASN.1
+ encoding of the X.500 name that appears in the public key
+ certificate. The order of the relative distinguished names
+ (RDNs), as well as the order of the AttributeTypeAndValues
+ within each RDN, will be reversed. (This is despite the fact
+ that an RDN is defined as a SET of AttributeTypeAndValues, where
+ an order is normally not important.)
+
+ Similarly, PKINIT may require the encoding of an X.500 name as a
+ PrincipalName. In these cases, the name-type of the principal name
+ shall be set to KRB_NT-X500-PRINCIPAL. This new name type is
+ defined as:
+
+ KRB_NT_X500_PRINCIPAL 6
+
+ The name-string shall be set as follows:
+
+ RFC2253Encode(DistinguishedName)
+
+ as described above.
+
+ RFC 1510 specifies the ASN.1 structure for PrincipalName as follows:
+
+ PrincipalName ::= SEQUENCE {
+ name-type[0] INTEGER,
+ name-string[1] SEQUENCE OF GeneralString
+ }
+
+ For the purposes of encoding an X.500 name within this structure,
+ the name-string shall be encoded as a single GeneralString.
+
+ Note that name mapping may be required or optional based on
+ policy.
+
+3.1.1. Encryption and Key Formats
+
+ In the exposition below, we use the terms public key and private
+ key generically. It should be understood that the term "public
+ key" may be used to refer to either a public encryption key or a
+ signature verification key, and that the term "private key" may be
+ used to refer to either a private decryption key or a signature
+ generation key. The fact that these are logically distinct does
+ not preclude the assignment of bitwise identical keys.
+
+ In the case of Diffie-Hellman, the key shall be produced from the
+ agreed bit string as follows:
+
+ * Truncate the bit string to the appropriate length.
+ * Rectify parity in each byte (if necessary) to obtain the key.
+
+ For instance, in the case of a DES key, we take the first eight
+ bytes of the bit stream, and then adjust the least significant bit
+ of each byte to ensure that each byte has odd parity.
+
+3.1.2. Algorithm Identifiers
+
+ PKINIT does not define, but does permit, the algorithm identifiers
+ listed below.
+
+3.1.2.1. Signature Algorithm Identifiers
+
+ The following signature algorithm identifiers specified in [11] and
+ in [15] shall be used with PKINIT:
+
+ id-dsa-with-sha1 (DSA with SHA1)
+ md5WithRSAEncryption (RSA with MD5)
+ sha-1WithRSAEncryption (RSA with SHA1)
+
+3.1.2.2 Diffie-Hellman Key Agreement Algorithm Identifier
+
+ The following algorithm identifier shall be used within the
+ SubjectPublicKeyInfo data structure: dhpublicnumber
+
+ This identifier and the associated algorithm parameters are
+ specified in RFC 2459 [15].
+
+3.1.2.3. Algorithm Identifiers for RSA Encryption
+
+ These algorithm identifiers are used inside the EnvelopedData data
+ structure, for encrypting the temporary key with a public key:
+
+ rsaEncryption (RSA encryption, PKCS#1 v1.5)
+ id-RSAES-OAEP (RSA encryption, PKCS#1 v2.0)
+
+ Both of the above RSA encryption schemes are specified in [16].
+ Currently, only PKCS#1 v1.5 is specified by CMS [11], although the
+ CMS specification says that it will likely include PKCS#1 v2.0 in
+ the future. (PKCS#1 v2.0 addresses adaptive chosen ciphertext
+ vulnerability discovered in PKCS#1 v1.5.)
+
+3.1.2.4. Algorithm Identifiers for Encryption with Secret Keys
+
+ These algorithm identifiers are used inside the EnvelopedData data
+ structure in the PKINIT Reply, for encrypting the reply key with the
+ temporary key:
+ des-ede3-cbc (3-key 3-DES, CBC mode)
+ rc2-cbc (RC2, CBC mode)
+
+ The full definition of the above algorithm identifiers and their
+ corresponding parameters (an IV for block chaining) is provided in
+ the CMS specification [11].
+
+3.2. Public Key Authentication
+
+ Implementation of the changes in this section is REQUIRED for
+ compliance with PKINIT.
+
+ It is assumed that all public keys are signed by some certification
+ authority (CA). The initial authentication request is sent as per
+ RFC 1510, except that a preauthentication field containing data
+ signed by the user's private key accompanies the request:
+
+ PA-PK-AS-REQ ::= SEQUENCE {
+ -- PA TYPE 14
+ signedAuthPack [0] SignedData
+ -- defined in CMS [11]
+ -- AuthPack (below) defines the data
+ -- that is signed
+ trustedCertifiers [1] SEQUENCE OF TrustedCas OPTIONAL,
+ -- CAs that the client trusts
+ kdcCert [2] IssuerAndSerialNumber OPTIONAL
+ -- as defined in CMS [11]
+ -- specifies a particular KDC
+ -- certificate if the client
+ -- already has it;
+ -- must be accompanied by
+ -- a single trustedCertifier
+ encryptionCert [3] IssuerAndSerialNumber OPTIONAL
+ -- For example, this may be the
+ -- client's Diffie-Hellman
+ -- certificate, or it may be the
+ -- client's RSA encryption
+ -- certificate.
+ }
+
+ TrustedCas ::= CHOICE {
+ principalName [0] KerberosName,
+ -- as defined below
+ caName [1] Name
+ -- fully qualified X.500 name
+ -- as defined by X.509
+ issuerAndSerial [2] IssuerAndSerialNumber OPTIONAL
+ -- Since a CA may have a number of
+ -- certificates, only one of which
+ -- a client trusts
+ }
+
+ Usage of SignedData:
+ The SignedData data type is specified in the Cryptographic
+ Message Syntax, a product of the S/MIME working group of the IETF.
+ - The encapContentInfo field must contain the PKAuthenticator
+ and, optionally, the client's Diffie Hellman public value.
+ - The eContentType field shall contain the OID value for
+ id-data: iso(1) member-body(2) us(840) rsadsi(113549)
+ pkcs(1) pkcs7(7) data(1)
+ - The eContent field is data of the type AuthPack (below).
+ - The signerInfos field contains the signature of AuthPack.
+ - The Certificates field, when non-empty, contains the client's
+ certificate chain. If present, the KDC uses the public key from
+ the client's certificate to verify the signature in the request.
+ Note that the client may pass different certificates that are used
+ for signing or for encrypting. Thus, the KDC may utilize a
+ different client certificate for signature verification than the
+ one it uses to encrypt the reply to the client. For example, the
+ client may place a Diffie-Hellman certificate in this field in
+ order to convey its static Diffie Hellman certificate to the KDC
+ enable static-ephemeral Diffie-Hellman mode for the reply. As
+ another example, the client may place an RSA encryption
+ certificate in this field.
+
+ AuthPack ::= SEQUENCE {
+ pkAuthenticator [0] PKAuthenticator,
+ clientPublicValue [1] SubjectPublicKeyInfo OPTIONAL
+ -- if client is using Diffie-Hellman
+ }
+
+ PKAuthenticator ::= SEQUENCE {
+ kdcName [0] PrincipalName,
+ kdcRealm [1] Realm,
+ cusec [2] INTEGER,
+ -- for replay prevention
+ ctime [3] KerberosTime,
+ -- for replay prevention
+ nonce [4] INTEGER
+ }
+
+ SubjectPublicKeyInfo ::= SEQUENCE {
+ algorithm AlgorithmIdentifier,
+ -- dhKeyAgreement
+ subjectPublicKey BIT STRING
+ -- for DH, equals
+ -- public exponent (INTEGER encoded
+ -- as payload of BIT STRING)
+ } -- as specified by the X.509 recommendation [10]
+
+ AlgorithmIdentifier ::= SEQUENCE {
+ algorithm ALGORITHM.&id,
+ parameters ALGORITHM.&type
+ } -- as specified by the X.509 recommendation [10]
+
+ If the client passes an issuer and serial number in the request,
+ the KDC is requested to use the referred-to certificate. If none
+ exists, then the KDC returns an error of type
+ KDC_ERR_CERTIFICATE_MISMATCH. It also returns this error if, on the
+ other hand, the client does not pass any trustedCertifiers,
+ believing that it has the KDC's certificate, but the KDC has more
+ than one certificate. The KDC should include information in the
+ KRB-ERROR message that indicates the KDC certificate(s) that a
+ client may utilize. This data is specified in the e-data, which
+ is defined in RFC 1510 revisions as a SEQUENCE of TypedData:
+
+ TypedData ::= SEQUENCE {
+ data-type [0] INTEGER,
+ data-value [1] OCTET STRING,
+ } -- per Kerberos RFC 1510 revisions
+
+ where:
+ data-type = TD-PKINIT-CMS-CERTIFICATES = 101
+ data-value = CertificateSet // as specified by CMS [11]
+
+ The PKAuthenticator carries information to foil replay attacks,
+ to bind the request and response. The PKAuthenticator is signed
+ with the private key corresponding to the public key in the
+ certificate found in userCert (or cached by the KDC).
+
+ The trustedCertifiers field contains a list of certification
+ authorities trusted by the client, in the case that the client does
+ not possess the KDC's public key certificate. If the KDC has no
+ certificate signed by any of the trustedCertifiers, then it returns
+ an error of type KDC_ERR_KDC_NOT_TRUSTED.
+
+ KDCs should try to (in order of preference):
+ 1. Use the KDC certificate identified by the serialNumber included
+ in the client's request.
+ 2. Use a certificate issued to the KDC by the client's CA (if in the
+ middle of a CA key roll-over, use the KDC cert issued under same
+ CA key as user cert used to verify request).
+ 3. Use a certificate issued to the KDC by one of the client's
+ trustedCertifier(s);
+ If the KDC is unable to comply with any of these options, then the
+ KDC returns an error message of type KDC_ERR_KDC_NOT_TRUSTED to the
+ client.
+
+ Upon receipt of the AS_REQ with PA-PK-AS-REQ pre-authentication
+ type, the KDC attempts to verify the user's certificate chain
+ (userCert), if one is provided in the request. This is done by
+ verifying the certification path against the KDC's policy of
+ legitimate certifiers. This may be based on a certification
+ hierarchy, or it may be simply a list of recognized certifiers in a
+ system like PGP.
+
+ If the client's certificate chain contains no certificate signed by
+ a CA trusted by the KDC, then the KDC sends back an error message
+ of type KDC_ERR_CANT_VERIFY_CERTIFICATE. The accompanying e-data
+ is a SEQUENCE of one TypedData (with type TD-TRUSTED-CERTIFIERS=104)
+ whose data-value is an OCTET STRING which is the DER encoding of
+
+ TrustedCertifiers ::= SEQUENCE OF PrincipalName
+ -- X.500 name encoded as a principal name
+ -- see Section 3.1
+
+ If the signature on one of the certificates in the client's chain
+ fails verification, then the KDC returns an error of type
+ KDC_ERR_INVALID_CERTIFICATE. The accompanying e-data is a SEQUENCE
+ of one TypedData (with type TD-CERTIFICATE-INDEX=105) whose
+ data-value is an OCTET STRING which is the DER encoding of
+
+ CertificateIndex ::= INTEGER
+ -- 0 = 1st certificate,
+ -- (in order of encoding)
+ -- 1 = 2nd certificate, etc
+
+ The KDC may also check whether any of the certificates in the
+ client's chain has been revoked. If one of the certificates has
+ been revoked, then the KDC returns an error of type
+ KDC_ERR_REVOKED_CERTIFICATE; if such a query reveals that the
+ certificate's revocation status is unknown, the KDC returns an
+ error of type KDC_ERR_REVOCATION_STATUS_UNKNOWN; if the revocation
+ status is unavailable, the KDC returns an error of type
+ KDC_ERR_REVOCATION_STATUS_UNAVAILABLE. In any of these three
+ cases, the affected certificate is identified by the accompanying
+ e-data, which contains a CertificateIndex as described for
+ KDC_ERR_INVALID_CERTIFICATE.
+
+ If the certificate chain can be verified, but the name of the
+ client in the certificate does not match the client's name in the
+ request, then the KDC returns an error of type
+ KDC_ERR_CLIENT_NAME_MISMATCH. There is no accompanying e-data
+ field in this case.
+
+ Finally, if the certificate chain is verified, but the KDC's name
+ or realm as given in the PKAuthenticator does not match the KDC's
+ actual principal name, then the KDC returns an error of type
+ KDC_ERR_KDC_NAME_MISMATCH. The accompanying e-data field is again
+ a SEQUENCE of one TypedData (with type TD-KRB-PRINCIPAL=102 or
+ TD-KRB-REALM=103 as appropriate) whose data-value is an OCTET
+ STRING whose data-value is the DER encoding of a PrincipalName or
+ Realm as defined in RFC 1510 revisions.
+
+ Even if all succeeds, the KDC may--for policy reasons--decide not
+ to trust the client. In this case, the KDC returns an error message
+ of type KDC_ERR_CLIENT_NOT_TRUSTED.
+
+ If a trust relationship exists, the KDC then verifies the client's
+ signature on AuthPack. If that fails, the KDC returns an error
+ message of type KDC_ERR_INVALID_SIG. Otherwise, the KDC uses the
+ timestamp (ctime and cusec) in the PKAuthenticator to assure that
+ the request is not a replay. The KDC also verifies that its name
+ is specified in the PKAuthenticator.
+
+ If the clientPublicValue field is filled in, indicating that the
+ client wishes to use Diffie-Hellman key agreement, then the KDC
+ checks to see that the parameters satisfy its policy. If they do
+ not (e.g., the prime size is insufficient for the expected
+ encryption type), then the KDC sends back an error message of type
+ KDC_ERR_KEY_TOO_WEAK. Otherwise, it generates its own public and
+ private values for the response.
+
+ The KDC also checks that the timestamp in the PKAuthenticator is
+ within the allowable window and that the principal name and realm
+ are correct. If the local (server) time and the client time in the
+ authenticator differ by more than the allowable clock skew, then the
+ KDC returns an error message of type KRB_AP_ERR_SKEW.
+
+ Assuming no errors, the KDC replies as per RFC 1510, except as
+ follows. The user's name in the ticket is determined by the
+ following decision algorithm:
+
+ 1. If the KDC has a mapping from the name in the certificate
+ to a Kerberos name, then use that name.
+ Else
+ 2. If the certificate contains a Kerberos name in an extension
+ field, and local KDC policy allows, then use that name.
+ Else
+ 3. Use the name as represented in the certificate, mapping
+ as necessary (e.g., as per RFC 2253 for X.500 names). In
+ this case the realm in the ticket shall be the name of the
+ certification authority that issued the user's certificate.
+
+ The KDC encrypts the reply not with the user's long-term key, but
+ with a random key generated only for this particular response. This
+ random key is sealed in the preauthentication field:
+
+ PA-PK-AS-REP ::= CHOICE {
+ -- PA TYPE 15
+ dhSignedData [0] SignedData,
+ -- Defined in CMS and used only with
+ -- Diffie-Helman key exchange
+ -- This choice MUST be supported
+ -- by compliant implementations.
+ encKeyPack [1] EnvelopedData,
+ -- Defined in CMS
+ -- The temporary key is encrypted
+ -- using the client public key
+ -- key
+ -- SignedReplyKeyPack, encrypted
+ -- with the temporary key, is also
+ -- included.
+ }
+
+ Usage of SignedData:
+ If the Diffie-Hellman option is used, dhSignedData in PA-PK-AS-REP
+ provides authenticated Diffie-Hellman parameters of the KDC. The
+ reply key used to encrypt part of the KDC reply message is derived
+ from the Diffie-Hellman exchange:
+ - Both the KDC and the client calculate a secret value (g^ab mod p),
+ where a is the client's private exponent and b is the KDC's
+ private exponent.
+ - Both the KDC and the client take the first N bits of this secret
+ value and convert it into a reply key. N depends on the reply key
+ type.
+ - If the reply key is DES, N=64 bits, where some of the bits are
+ replaced with parity bits, according to FIPS PUB 74.
+ - If the reply key is (3-key) 3-DES, N=192 bits, where some of the
+ bits are replaced with parity bits, according to FIPS PUB 74.
+ - The encapContentInfo field must contain the KdcDHKeyInfo as
+ defined below.
+ - The eContentType field shall contain the OID value for
+ id-data: iso(1) member-body(2) us(840) rsadsi(113549)
+ pkcs(1) pkcs7(7) data(1)
+ - The certificates field must contain the certificates necessary
+ for the client to establish trust in the KDC's certificate
+ based on the list of trusted certifiers sent by the client in
+ the PA-PK-AS-REQ. This field may be empty if the client did
+ not send to the KDC a list of trusted certifiers (the
+ trustedCertifiers field was empty, meaning that the client
+ already possesses the KDC's certificate).
+ - The signerInfos field is a SET that must contain at least one
+ member, since it contains the actual signature.
+
+ Usage of EnvelopedData:
+ The EnvelopedData data type is specified in the Cryptographic
+ Message Syntax, a product of the S/MIME working group of the IETF.
+ It contains an temporary key encrypted with the PKINIT
+ client's public key. It also contains a signed and encrypted
+ reply key.
+ - The originatorInfo field is not required, since that information
+ may be presented in the signedData structure that is encrypted
+ within the encryptedContentInfo field.
+ - The optional unprotectedAttrs field is not required for PKINIT.
+ - The recipientInfos field is a SET which must contain exactly one
+ member of the KeyTransRecipientInfo type for encryption
+ with an RSA public key.
+ - The encryptedKey field (in KeyTransRecipientInfo) contains
+ the temporary key which is encrypted with the PKINIT client's
+ public key.
+ - The encryptedContentInfo field contains the signed and encrypted
+ reply key.
+ - The contentType field shall contain the OID value for
+ id-signedData: iso(1) member-body(2) us(840) rsadsi(113549)
+ pkcs(1) pkcs7(7) signedData(2)
+ - The encryptedContent field is encrypted data of the CMS type
+ signedData as specified below.
+ - The encapContentInfo field must contains the ReplyKeyPack.
+ - The eContentType field shall contain the OID value for
+ id-data: iso(1) member-body(2) us(840) rsadsi(113549)
+ pkcs(1) pkcs7(7) data(1)
+ - The eContent field is data of the type ReplyKeyPack (below).
+ - The certificates field must contain the certificates necessary
+ for the client to establish trust in the KDC's certificate
+ based on the list of trusted certifiers sent by the client in
+ the PA-PK-AS-REQ. This field may be empty if the client did
+ not send to the KDC a list of trusted certifiers (the
+ trustedCertifiers field was empty, meaning that the client
+ already possesses the KDC's certificate).
+ - The signerInfos field is a SET that must contain at least one
+ member, since it contains the actual signature.
+
+ KdcDHKeyInfo ::= SEQUENCE {
+ -- used only when utilizing Diffie-Hellman
+ nonce [0] INTEGER,
+ -- binds responce to the request
+ subjectPublicKey [2] BIT STRING
+ -- Equals public exponent (g^a mod p)
+ -- INTEGER encoded as payload of
+ -- BIT STRING
+ }
+
+ ReplyKeyPack ::= SEQUENCE {
+ -- not used for Diffie-Hellman
+ replyKey [0] EncryptionKey,
+ -- used to encrypt main reply
+ -- ENCTYPE is at least as strong as
+ -- ENCTYPE of session key
+ nonce [1] INTEGER,
+ -- binds response to the request
+ -- must be same as the nonce
+ -- passed in the PKAuthenticator
+ }
+
+
+ Since each certifier in the certification path of a user's
+ certificate is essentially a separate realm, the name of each
+ certifier must be added to the transited field of the ticket. The
+ format of these realm names is defined in Section 3.1 of this
+ document. If applicable, the transit-policy-checked flag should be
+ set in the issued ticket.
+
+ The KDC's certificate must bind the public key to a name derivable
+ from the name of the realm for that KDC. X.509 certificates shall
+ contain the principal name of the KDC as the SubjectAltName version
+ 3 extension. Below is the definition of this version 3 extension, as
+ specified by the X.509 standard:
+
+ subjectAltName EXTENSION ::= {
+ SYNTAX GeneralNames
+ IDENTIFIED BY id-ce-subjectAltName
+ }
+
+ GeneralNames ::= SEQUENCE SIZE(1..MAX) OF GeneralName
+
+ GeneralName ::= CHOICE {
+ otherName [0] INSTANCE OF OTHER-NAME,
+ ...
+ }
+
+ OTHER-NAME ::= TYPE-IDENTIFIER
+
+ In this definition, otherName is a name of any form defined as an
+ instance of the OTHER-NAME information object class. For the purpose
+ of specifying a Kerberos principal name, INSTANCE OF OTHER-NAME will
+ be chosen and replaced by the type KerberosName:
+
+ KerberosName ::= SEQUENCE {
+ realm [0] Realm,
+ -- as define in RFC 1510
+ principalName [1] PrincipalName,
+ -- as define in RFC 1510
+ }
+
+ This specific syntax is identified within subjectAltName by setting
+ the OID id-ce-subjectAltName to krb5PrincipalName, where (from the
+ Kerberos specification) we have
+
+ krb5 OBJECT IDENTIFIER ::= { iso (1)
+ org (3)
+ dod (6)
+ internet (1)
+ security (5)
+ kerberosv5 (2) }
+
+ krb5PrincipalName OBJECT IDENTIFIER ::= { krb5 2 }
+
+ This specification may also be used to specify a Kerberos name
+ within the user's certificate.
+
+ If a non-KDC X.509 certificate contains the principal name within
+ the subjectAltName version 3 extension , that name may utilize
+ KerberosName as defined below, or, in the case of an S/MIME
+ certificate [17], may utilize the email address. If the KDC
+ is presented with as S/MIME certificate, then the email address
+ within subjectAltName will be interpreted as a principal and realm
+ separated by the "@" sign, or as a name that needs to be
+ canonicalized. If the resulting name does not correspond to a
+ registered principal name, then the principal name is formed as
+ defined in section 3.1.
+
+ The client then extracts the random key used to encrypt the main
+ reply. This random key (in encPaReply) is encrypted with either the
+ client's public key or with a key derived from the DH values
+ exchanged between the client and the KDC.
+
+3.2.2. Required Algorithms
+
+ Not all of the algorithms in the PKINIT protocol specification have
+ to be implemented in order to comply with the proposed standard.
+ Below is a list of the required algorithms:
+
+ - Diffie-Hellman public/private key pairs
+ - utilizing Diffie-Hellman ephemeral-ephemeral mode
+ - SHA1 digest and DSA for signatures
+ - 3-key triple DES keys derived from the Diffie-Hellman Exchange
+ - 3-key triple DES Temporary and Reply keys
+
+4. Logistics and Policy
+
+ This section describes a way to define the policy on the use of
+ PKINIT for each principal and request.
+
+ The KDC is not required to contain a database record for users
+ who use public key authentication. However, if these users are
+ registered with the KDC, it is recommended that the database record
+ for these users be modified to an additional flag in the attributes
+ field to indicate that the user should authenticate using PKINIT.
+ If this flag is set and a request message does not contain the
+ PKINIT preauthentication field, then the KDC sends back as error of
+ type KDC_ERR_PREAUTH_REQUIRED indicating that a preauthentication
+ field of type PA-PK-AS-REQ must be included in the request.
+
+5. Security Considerations
+
+ PKINIT raises a few security considerations, which we will address
+ in this section.
+
+ First of all, PKINIT introduces a new trust model, where KDCs do not
+ (necessarily) certify the identity of those for whom they issue
+ tickets. PKINIT does allow KDCs to act as their own CAs, in order
+ to simplify key management, but one of the additional benefits is to
+ align Kerberos authentication with a global public key
+ infrastructure. Anyone using PKINIT in this way must be aware of
+ how the certification infrastructure they are linking to works.
+
+ Secondly, PKINIT also introduces the possibility of interactions
+ between different cryptosystems, which may be of widely varying
+ strengths. Many systems, for instance, allow the use of 512-bit
+ public keys. Using such keys to wrap data encrypted under strong
+ conventional cryptosystems, such as triple-DES, is inappropriate;
+ it adds a weak link to a strong one at extra cost. Implementors
+ and administrators should take care to avoid such wasteful and
+ deceptive interactions.
+
+ Lastly, PKINIT calls for randomly generated keys for conventional
+ cryptosystems. Many such systems contain systematically "weak"
+ keys. PKINIT implementations MUST avoid use of these keys, either
+ by discarding those keys when they are generated, or by fixing them
+ in some way (e.g., by XORing them with a given mask). These
+ precautions vary from system to system; it is not our intention to
+ give an explicit recipe for them here.
+
+6. Transport Issues
+
+ Certificate chains can potentially grow quite large and span several
+ UDP packets; this in turn increases the probability that a Kerberos
+ message involving PKINIT extensions will be broken in transit. In
+ light of the possibility that the Kerberos specification will
+ require KDCs to accept requests using TCP as a transport mechanism,
+ we make the same recommendation with respect to the PKINIT
+ extensions as well.
+
+7. Bibliography
+
+ [1] J. Kohl, C. Neuman. The Kerberos Network Authentication Service
+ (V5). Request for Comments 1510.
+
+ [2] B.C. Neuman, Theodore Ts'o. Kerberos: An Authentication Service
+ for Computer Networks, IEEE Communications, 32(9):33-38. September
+ 1994.
+
+ [3] B. Tung, T. Ryutov, C. Neuman, G. Tsudik, B. Sommerfeld,
+ A. Medvinsky, M. Hur. Public Key Cryptography for Cross-Realm
+ Authentication in Kerberos.
+ draft-ietf-cat-kerberos-pk-cross-04.txt
+
+ [4] A. Medvinsky, J. Cargille, M. Hur. Anonymous Credentials in
+ Kerberos.
+ draft-ietf-cat-kerberos-anoncred-00.txt
+
+ [5] A. Medvinsky, M. Hur, B. Clifford Neuman. Public Key Utilizing
+ Tickets for Application Servers (PKTAPP).
+ draft-ietf-cat-pktapp-00.txt
+
+ [6] M. Sirbu, J. Chuang. Distributed Authentication in Kerberos
+ Using Public Key Cryptography. Symposium On Network and Distributed
+ System Security, 1997.
+
+ [7] B. Cox, J.D. Tygar, M. Sirbu. NetBill Security and Transaction
+ Protocol. In Proceedings of the USENIX Workshop on Electronic
+ Commerce, July 1995.
+
+ [8] T. Dierks, C. Allen. The TLS Protocol, Version 1.0
+ Request for Comments 2246, January 1999.
+
+ [9] B.C. Neuman, Proxy-Based Authorization and Accounting for
+ Distributed Systems. In Proceedings of the 13th International
+ Conference on Distributed Computing Systems, May 1993.
+
+ [10] ITU-T (formerly CCITT) Information technology - Open Systems
+ Interconnection - The Directory: Authentication Framework
+ Recommendation X.509 ISO/IEC 9594-8
+
+ [11] R. Housley. Cryptographic Message Syntax.
+ draft-ietf-smime-cms-13.txt, April 1999.
+
+ [12] PKCS #7: Cryptographic Message Syntax Standard,
+ An RSA Laboratories Technical Note Version 1.5
+ Revised November 1, 1993
+
+ [13] R. Rivest, MIT Laboratory for Computer Science and RSA Data
+ Security, Inc. A Description of the RC2(r) Encryption Algorithm
+ March 1998.
+ Request for Comments 2268.
+
+ [14] M. Wahl, S. Kille, T. Howes. Lightweight Directory Access
+ Protocol (v3): UTF-8 String Representation of Distinguished Names.
+ Request for Comments 2253.
+
+ [15] R. Housley, W. Ford, W. Polk, D. Solo. Internet X.509 Public
+ Key Infrastructure, Certificate and CRL Profile, January 1999.
+ Request for Comments 2459.
+
+ [16] B. Kaliski, J. Staddon. PKCS #1: RSA Cryptography
+ Specifications, October 1998.
+ Request for Comments 2437.
+
+ [17] S. Dusse, P. Hoffman, B. Ramsdell, J. Weinstein.
+ S/MIME Version 2 Certificate Handling, March 1998.
+ Request for Comments 2312
+
+8. Acknowledgements
+
+ Some of the ideas on which this proposal is based arose during
+ discussions over several years between members of the SAAG, the IETF
+ CAT working group, and the PSRG, regarding integration of Kerberos
+ and SPX. Some ideas have also been drawn from the DASS system.
+ These changes are by no means endorsed by these groups. This is an
+ attempt to revive some of the goals of those groups, and this
+ proposal approaches those goals primarily from the Kerberos
+ perspective. Lastly, comments from groups working on similar ideas
+ in DCE have been invaluable.
+
+9. Expiration Date
+
+ This draft expires December 1, 1999.
+
+10. Authors
+
+ Brian Tung
+ Clifford Neuman
+ USC Information Sciences Institute
+ 4676 Admiralty Way Suite 1001
+ Marina del Rey CA 90292-6695
+ Phone: +1 310 822 1511
+ E-mail: {brian, bcn}@isi.edu
+
+ Matthew Hur
+ CyberSafe Corporation
+ 1605 NW Sammamish Road
+ Issaquah WA 98027-5378
+ Phone: +1 425 391 6000
+ E-mail: matt.hur@cybersafe.com
+
+ Ari Medvinsky
+ Excite
+ 555 Broadway
+ Redwood City, CA 94063
+ Phone +1 650 569 2119
+ E-mail: amedvins@excitecorp.com
+
+ Sasha Medvinsky
+ General Instrument
+ 6450 Sequence Drive
+ San Diego, CA 92121
+ Phone +1 619 404 2825
+ E-mail: smedvinsky@gi.com
+
+ John Wray
+ Iris Associates, Inc.
+ 5 Technology Park Dr.
+ Westford, MA 01886
+ E-mail: John_Wray@iris.com
+
+ Jonathan Trostle
+ 170 W. Tasman Dr.
+ San Jose, CA 95134
+ E-mail: jtrostle@cisco.com
--- /dev/null
+
+
+
+
+
+
+Network Working Group L. Zhu
+Request for Comments: 4557 K. Jaganathan
+Category: Standards Track Microsoft Corporation
+ N. Williams
+ Sun Microsystems
+ June 2006
+
+
+ Online Certificate Status Protocol (OCSP) Support for
+ Public Key Cryptography for
+ Initial Authentication in Kerberos (PKINIT)
+
+Status of This Memo
+
+ This document specifies an Internet standards track protocol for the
+ Internet community, and requests discussion and suggestions for
+ improvements. Please refer to the current edition of the "Internet
+ Official Protocol Standards" (STD 1) for the standardization state
+ and status of this protocol. Distribution of this memo is unlimited.
+
+Copyright Notice
+
+ Copyright (C) The Internet Society (2006).
+
+Abstract
+
+ This document defines a mechanism to enable in-band transmission of
+ Online Certificate Status Protocol (OCSP) responses in the Kerberos
+ network authentication protocol. These responses are used to verify
+ the validity of the certificates used in Public Key Cryptography for
+ Initial Authentication in Kerberos (PKINIT), which is the Kerberos
+ Version 5 extension that provides for the use of public key
+ cryptography.
+
+Table of Contents
+
+ 1. Introduction ....................................................2
+ 2. Conventions Used in This Document ...............................2
+ 3. Message Definition ..............................................2
+ 4. Security Considerations .........................................3
+ 5. Acknowledgements ................................................4
+ 6. References ......................................................4
+ 6.1. Normative References .......................................4
+ 6.2. Informative References .....................................4
+
+
+
+
+
+
+
+Zhu, et al. Standards Track [Page 1]
+\f
+RFC 4557 OCSP Support for PKINIT June 2006
+
+
+1. Introduction
+
+ Online Certificate Status Protocol (OCSP) [RFC2560] enables
+ applications to obtain timely information regarding the revocation
+ status of a certificate. Because OCSP responses are well bounded and
+ small in size, constrained clients may wish to use OCSP to check the
+ validity of the certificates for Kerberos Key Distribution Center
+ (KDC) in order to avoid transmission of large Certificate Revocation
+ Lists (CRLs) and therefore save bandwidth on constrained networks
+ [OCSP-PROFILE].
+
+ This document defines a pre-authentication type [RFC4120], where the
+ client and the KDC MAY piggyback OCSP responses for certificates used
+ in authentication exchanges, as defined in [RFC4556].
+
+ By using this OPTIONAL extension, PKINIT clients and the KDC can
+ maximize the reuse of cached OCSP responses.
+
+2. Conventions Used in This Document
+
+ In this document, the key words "MUST", "MUST NOT", "REQUIRED",
+ "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY",
+ and "OPTIONAL" are to be interpreted as described in [RFC2119].
+
+3. Message Definition
+
+ A pre-authentication type identifier is defined for this mechanism:
+
+ PA-PK-OCSP-RESPONSE 18
+
+ The corresponding padata-value field [RFC4120] contains the DER [X60]
+ encoding of the following ASN.1 type:
+
+ PKOcspData ::= SEQUENCE OF OcspResponse
+ -- If more than one OcspResponse is
+ -- included, the first OcspResponse
+ -- MUST contain the OCSP response
+ -- for the signer's certificate.
+ -- The signer refers to the client for
+ -- AS-REQ, and the KDC for the AS-REP,
+ -- respectively.
+
+ OcspResponse ::= OCTET STRING
+ -- Contains a complete OCSP response,
+ -- as defined in [RFC2560].
+
+ The client MAY send OCSP responses for certificates used in PA-PK-
+ AS-REQ [RFC4556] via a PA-PK-OCSP-RESPONSE.
+
+
+
+Zhu, et al. Standards Track [Page 2]
+\f
+RFC 4557 OCSP Support for PKINIT June 2006
+
+
+ The KDC that receives a PA-PK-OCSP-RESPONSE SHOULD send a PA-PK-
+ OCSP-RESPONSE containing OCSP responses for certificates used in the
+ KDC's PA-PK-AS-REP. The client can request a PA-PK-OCSP-RESPONSE by
+ using a PKOcspData containing an empty sequence.
+
+ The KDC MAY send a PA-PK-OCSP-RESPONSE when it does not receive a
+ PA-PK-OCSP-RESPONSE from the client.
+
+ The PA-PK-OCSP-RESPONSE sent by the KDC contains OCSP responses for
+ certificates used in PA-PK-AS-REP [RFC4556].
+
+ Note the lack of integrity protection for the empty or missing OCSP
+ response; lack of an expected OCSP response from the KDC for the
+ KDC's certificates SHOULD be treated as an error by the client,
+ unless it is configured otherwise.
+
+ When using OCSP, the response is signed by the OCSP server, which is
+ trusted by the receiver. Depending on local policy, further
+ verification of the validity of the OCSP servers may be needed
+
+ The client and the KDC SHOULD ignore invalid OCSP responses received
+ via this mechanism, and they MAY implement CRL processing logic as a
+ fall-back position, if the OCSP responses received via this mechanism
+ alone are not sufficient for the verification of certificate
+ validity. The client and/or the KDC MAY ignore a valid OCSP response
+ and perform its own revocation status verification independently.
+
+4. Security Considerations
+
+ The pre-authentication data in this document do not actually
+ authenticate any principals, but are designed to be used in
+ conjunction with PKINIT.
+
+ There is no binding between PA-PK-OCSP-RESPONSE pre-authentication
+ data and PKINIT pre-authentication data other than a given OCSP
+ response corresponding to a certificate used in a PKINIT pre-
+ authentication data element. Attacks involving removal or
+ replacement of PA-PK-OCSP-RESPONSE pre-authentication data elements
+ are, at worst, downgrade attacks, where a PKINIT client or KDC would
+ proceed without use of CRLs or OCSP for certificate validation, or
+ denial-of-service attacks, where a PKINIT client or KDC that cannot
+ validate the other's certificate without an accompanying OCSP
+ response might reject the AS exchange or might have to download very
+ large CRLs in order to continue. Kerberos V does not protect against
+ denial-of-service attacks; therefore, the denial-of-service aspect of
+ these attacks is acceptable.
+
+
+
+
+
+Zhu, et al. Standards Track [Page 3]
+\f
+RFC 4557 OCSP Support for PKINIT June 2006
+
+
+ If a PKINIT client or KDC cannot validate certificates without the
+ aid of a valid PA-PK-OCSP-RESPONSE, then it SHOULD fail the AS
+ exchange, possibly according to local configuration.
+
+5. Acknowledgements
+
+ This document was based on conversations among the authors, Jeffrey
+ Altman, Sam Hartman, Martin Rex, and other members of the Kerberos
+ working group.
+
+6. References
+
+6.1. Normative References
+
+ [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
+ Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+ [RFC2560] Myers, M., Ankney, R., Malpani, A., Galperin, S., and
+ C. Adams, "X.509 Internet Public Key Infrastructure
+ Online Certificate Status Protocol - OCSP", RFC 2560,
+ June 1999.
+
+ [RFC4120] Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The
+ Kerberos Network Authentication Service (V5)", RFC
+ 4120, July 2005.
+
+ [RFC4556] Zhu, L. and B. Tung, "Public Key Cryptography for
+ Initial Authentication in Kerberos (PKINIT)", RFC
+ 4556, June 2006.
+
+ [X690] ASN.1 encoding rules: Specification of Basic Encoding
+ Rules (BER), Canonical Encoding Rules (CER) and
+ Distinguished Encoding Rules (DER), ITU-T
+ Recommendation X.690 (1997) | ISO/IEC International
+ Standard 8825-1:1998.
+
+6.2. Informative References
+
+ [OCSP-PROFILE] Deacon, A. and R. Hurst, "Lightweight OCSP Profile for
+ High Volume Environments", Work in Progress, May 2006.
+
+
+
+
+
+
+
+
+
+
+
+Zhu, et al. Standards Track [Page 4]
+\f
+RFC 4557 OCSP Support for PKINIT June 2006
+
+
+Authors' Addresses
+
+ Larry Zhu
+ Microsoft Corporation
+ One Microsoft Way
+ Redmond, WA 98052
+ US
+
+ EMail: lzhu@microsoft.com
+
+
+ Karthik Jaganathan
+ Microsoft Corporation
+ One Microsoft Way
+ Redmond, WA 98052
+ US
+
+ EMail: karthikj@microsoft.com
+
+
+ Nicolas Williams
+ Sun Microsystems
+ 5300 Riata Trace Ct
+ Austin, TX 78727
+ US
+
+ EMail: Nicolas.Williams@sun.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Zhu, et al. Standards Track [Page 5]
+\f
+RFC 4557 OCSP Support for PKINIT June 2006
+
+
+Full Copyright Statement
+
+ Copyright (C) The Internet Society (2006).
+
+ This document is subject to the rights, licenses and restrictions
+ contained in BCP 78, and except as set forth therein, the authors
+ retain all their rights.
+
+ This document and the information contained herein are provided on an
+ "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
+ OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
+ ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
+ INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
+ INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
+ WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+Intellectual Property
+
+ The IETF takes no position regarding the validity or scope of any
+ Intellectual Property Rights or other rights that might be claimed to
+ pertain to the implementation or use of the technology described in
+ this document or the extent to which any license under such rights
+ might or might not be available; nor does it represent that it has
+ made any independent effort to identify any such rights. Information
+ on the procedures with respect to rights in RFC documents can be
+ found in BCP 78 and BCP 79.
+
+ Copies of IPR disclosures made to the IETF Secretariat and any
+ assurances of licenses to be made available, or the result of an
+ attempt made to obtain a general license or permission for the use of
+ such proprietary rights by implementers or users of this
+ specification can be obtained from the IETF on-line IPR repository at
+ http://www.ietf.org/ipr.
+
+ The IETF invites any interested party to bring to its attention any
+ copyrights, patents or patent applications, or other proprietary
+ rights that may cover technology that may be required to implement
+ this standard. Please address the information to the IETF at
+ ietf-ipr@ietf.org.
+
+Acknowledgement
+
+ Funding for the RFC Editor function is provided by the IETF
+ Administrative Support Activity (IASA).
+
+
+
+
+
+
+
+Zhu, et al. Standards Track [Page 6]
+\f
projects / krb5.git / commitdiff