< draft-ietf-cat-kerberos-pk-init-16.txt   draft-ietf-cat-kerberos-pk-init-17.txt >
INTERNET-DRAFT Brian Tung INTERNET-DRAFT Brian Tung
draft-ietf-cat-kerberos-pk-init-16.txt Clifford Neuman draft-ietf-cat-kerberos-pk-init-17.txt Clifford Neuman
Updates: RFC 1510bis USC/ISI Updates: RFC 1510bis USC/ISI
expires March 12, 2002 Matthew Hur expires May 31, 2004 Matthew Hur
Microsoft Corporation
Ari Medvinsky Ari Medvinsky
Liberate Technologies Microsoft Corporation
Sasha Medvinsky Sasha Medvinsky
Motorola, Inc. Motorola, Inc.
John Wray John Wray
Iris Associates, Inc. Iris Associates, Inc.
Jonathan Trostle Jonathan Trostle
Public Key Cryptography for Initial Authentication in Kerberos Public Key Cryptography for Initial Authentication in Kerberos
0. Status Of This Memo 0. Status Of This Memo
This document is an Internet-Draft and is in full conformance with This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC 2026. Internet-Drafts are all provision of Section 10 of RFC 2026. Internet-Drafts are
working documents of the Internet Engineering Task Force (IETF), working documents of the Internet Engineering Task Force (IETF), its
its areas, and its working groups. Note that other groups may also areas, and its working groups. Note that other groups may also
distribute working documents as Internet-Drafts. 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 Internet-Drafts are draft documents valid for a maximum of six
http://www.ietf.org/ietf/1id-abstracts.txt 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 Internet-Draft Shadow Directories can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/ietf/1id-abstracts.txt
To learn the current status of any Internet-Draft, please check The list of Internet-Draft Shadow Directories can be accessed at
the "1id-abstracts.txt" listing contained in the Internet-Drafts http://www.ietf.org/shadow.html
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 The distribution of this memo is unlimited. It is filed as
draft-ietf-cat-kerberos-pk-init-16.txt, and expires March 12, draft-ietf-cat-kerberos-pk-init-17.txt and expires May 31, 2004.
2002. Please send comments to the authors. Please send comments to the authors.
1. Abstract 1. Abstract
This document defines extensions (PKINIT) to the Kerberos protocol This draft describes protocol extensions (hereafter called PKINIT)
specification (RFC 1510bis [1]) to provide a method for using public to the Kerberos protocol specification (RFC 1510bis [1]). These
key cryptography during initial authentication. The methods extensions provide a method for integrating public key cryptography
defined specify the ways in which preauthentication data fields and into the initial authentication exchange, by passing cryptographic
error data fields in Kerberos messages are to be used to transport certificates and associated authenticators in preauthentication data
public key data. fields.
2. Introduction 2. Introduction
The popularity of public key cryptography has produced a desire for A client typically authenticates itself to a service in Kerberos
its support in Kerberos [2]. The advantages provided by public key using three distinct though related exchanges. First, the client
cryptography include simplified key management (from the Kerberos requests a ticket-granting ticket (TGT) from the Kerberos
perspective) and the ability to leverage existing and developing authentication server (AS). Then, it uses the TGT to request a
public key certification infrastructures. service ticket from the Kerberos ticket-granting server (TGS).
Usually, the AS and TGS are integrated in a single device known as
Public key cryptography can be integrated into Kerberos in a number a Kerberos Key Distribution Center, or KDC. (In this draft, we will
of ways. One is to associate a key pair with each realm, which can refer to both the AS and the TGS as the KDC.) Finally, the client
then be used to facilitate cross-realm authentication; this is the uses the service ticket to authenticate itself to the service.
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 RSA keys as the primary, required mechanism. Note
that PKINIT supports the use of separate signature and encryption
keys.
PKINIT enables access to Kerberos-secured services based on initial
authentication utilizing public key cryptography. PKINIT utilizes
standard public key signature and encryption data formats within the
standard Kerberos messages. The basic mechanism is as follows: The
user sends an AS-REQ message to the KDC as before, except that if that
user is to use public key cryptography in the initial authentication
step, his certificate and a signature accompany the initial request
in the preauthentication fields. Upon receipt of this request, the
KDC verifies the certificate and issues a ticket granting ticket
(TGT) as before, except that the encPart from the AS-REP message
carrying the TGT is now encrypted utilizing either a Diffie-Hellman
derived key or the user's public key. This message is authenticated
utilizing the public key signature of the KDC.
Note that PKINIT does not require the use of certificates. A KDC
may store the public key of a principal as part of that principal's
record. In this scenario, the KDC is the trusted party that vouches
for the principal (as in a standard, non-cross realm, Kerberos
environment). Thus, for any principal, the KDC may maintain a
symmetric key, a public key, or both.
The PKINIT specification may also be used as a building block for
other specifications. PKINIT may be utilized to establish
inter-realm keys for the purposes of issuing cross-realm service
tickets. It may also be used to issue anonymous Kerberos tickets
using the Diffie-Hellman option. Efforts are under way to draft
specifications for these two application protocols.
Additionally, the PKINIT specification may be used for direct peer
to peer authentication without contacting a central KDC. This
application of PKINIT is based on concepts introduced in [6, 7].
For direct client-to-server authentication, the client uses PKINIT
to authenticate to the end server (instead of a central KDC), which
then issues a ticket for itself. This approach has an advantage
over TLS [5] in that the server does not need to save state (cache
session keys). Furthermore, an additional benefit is that Kerberos
tickets can facilitate delegation (see [6]).
3. Proposed Extensions
This section describes extensions to RFC 1510bis for supporting the
use of public key cryptography in the initial request for a ticket
granting ticket (TGT).
In summary, the following change to RFC 1510bis is proposed:
* Users may authenticate using either a public key pair or a
conventional (symmetric) key. If public key cryptography is
used, public key data is transported in preauthentication
data fields to help establish identity. The user presents
a public key certificate and obtains an ordinary TGT that may
be used for subsequent authentication, with such
authentication using only conventional cryptography.
Section 3.1 provides definitions to help specify message formats.
Section 3.2 describes the extensions for the initial authentication
method.
3.1. Definitions
The extensions involve new preauthentication fields; we introduce
the following preauthentication types:
PA-PK-AS-REQ 14
PA-PK-AS-REP 15
The extensions also involve new error types; we introduce the
following types:
KDC_ERR_CLIENT_NOT_TRUSTED 62
KDC_ERR_KDC_NOT_TRUSTED 63
KDC_ERR_INVALID_SIG 64
KDC_ERR_KEY_TOO_WEAK 65
KDC_ERR_CERTIFICATE_MISMATCH 66
KDC_ERR_CANT_VERIFY_CERTIFICATE 70
KDC_ERR_INVALID_CERTIFICATE 71
KDC_ERR_REVOKED_CERTIFICATE 72
KDC_ERR_REVOCATION_STATUS_UNKNOWN 73
KDC_ERR_REVOCATION_STATUS_UNAVAILABLE 74
KDC_ERR_CLIENT_NAME_MISMATCH 75
KDC_ERR_KDC_NAME_MISMATCH 76
We utilize the following typed data for errors:
TD-PKINIT-CMS-CERTIFICATES 101
TD-DH-PARAMETERS 102
TD-TRUSTED-CERTIFIERS 104
TD-CERTIFICATE-INDEX 105
We utilize the following encryption types (which map directly to
OIDs):
dsaWithSHA1-CmsOID 9 The advantage afforded by the TGT is that the user need only
md5WithRSAEncryption-CmsOID 10 explicitly request a ticket and expose his credentials once. The
sha1WithRSAEncryption-CmsOID 11 TGT and its associated session key can then be used for any
rc2CBC-EnvOID 12 subsequent requests. One implication of this is that all further
rsaEncryption-EnvOID (PKCS#1 v1.5) 13 authentication is independent of the method by which the initial
rsaES-OAEP-ENV-OID (PKCS#1 v2.0) 14 authentication was performed. Consequently, initial authentication
des-ede3-cbc-Env-OID 15 provides a convenient place to integrate public-key cryptography
into Kerberos authentication.
These mappings are provided so that a client may send the As defined, Kerberos authentication exchanges use symmetric-key
appropriate enctypes in the AS-REQ message in order to indicate cryptography, in part for performance. (Symmetric-key cryptography
support for the corresponding OIDs (for performing PKINIT). The is typically 10-100 times faster than public-key cryptography,
above encryption types are utilized only within CMS structures depending on the public-key operations. [c]) One cost of using
within the PKINIT preauthentication fields. Their use within symmetric-key cryptography is that the keys must be shared, so that
the Kerberos EncryptedData structure is unspecified. before a user can authentication himself, he must already be
registered with the KDC.
In many cases, PKINIT requires the encoding of the X.500 name of a Conversely, public-key cryptography--in conjunction with an
certificate authority as a Realm. When such a name appears as established certification infrastructure--permits authentication
a realm it will be represented using the "Other" form of the realm without prior registration. Adding it to Kerberos allows the
name as specified in the naming constraints section of RFC 1510bis. widespread use of Kerberized applications by users without requiring
For a realm derived from an X.500 name, NAMETYPE will have the value them to register first--a requirement that has no inherent security
X500-RFC2253. The full realm name will appear as follows: benefit.
<nametype> + ":" + <string> As noted above, a convenient and efficient place to introduce
public-key cryptography into Kerberos is in the initial
authentication exchange. This document describes the methods and
data formats for integrating public-key cryptography into Kerberos
initial authentication. Another document (PKCROSS) describes a
similar protocol for Kerberos cross-realm authentication.
where nametype is "X500-RFC2253" and string is the result of doing 3. Extensions
an RFC2253 encoding of the distinguished name, i.e.
"X500-RFC2253:" + RFC2253Encode(DistinguishedName) This section describes extensions to RFC 1510bis for supporting the
use of public-key cryptography in the initial request for a ticket
granting ticket (TGT).
where DistinguishedName is an X.500 name, and RFC2253Encode is a Briefly, the following changes to RFC 1510bis are proposed:
function returing a readable UTF encoding of an X.500 name, as
defined by RFC 2253 [11] (part of LDAPv3 [15]).
Each component of a DistinguishedName is called a 1. If public-key authentication is indicated, the client sends
RelativeDistinguishedName, where a RelativeDistinguishedName is a the user's public-key data and an authenticator in a
SET OF AttributeTypeAndValue. RFC 2253 does not specify the order preauthentication field accompanying the usual request.
in which to encode the elements of the RelativeDistinguishedName and This authenticator is signed by the user's private
so to ensure that this encoding is unique, we add the following rule signature key.
to those specified by RFC 2253:
When converting a multi-valued RelativeDistinguishedName 2. The KDC verifies the client's request against its own
to a string, the output consists of the string encodings policy and certification authorities.
of each AttributeTypeAndValue, in the same order as
specified by the DER encoding.
Similarly, in cases where the KDC does not provide a specific 3. If the request passes the verification tests, the KDC
policy-based mapping from the X.500 name or X.509 Version 3 replies as usual, but the reply is encrypted using either:
SubjectAltName extension in the user's certificate to a Kerberos
principal name, PKINIT requires the direct encoding of the X.500
name as a PrincipalName. In this case, the name-type of the
principal name MUST be set to KRB_NT-X500-PRINCIPAL. This new
name type is defined in RFC 1510bis as:
KRB_NT_X500_PRINCIPAL 6 a. a randomly generated key, signed using the KDC's
signature key and encrypted using the user's encryption
key; or
For this type, the name-string MUST be set as follows: b. a key generated through a Diffie-Hellman exchange with
the client, signed using the KDC's signature key.
RFC2253Encode(DistinguishedName) Any key data required by the client to obtain the encryption
key is returned in a preauthentication field accompanying
the usual reply.
as described above. When this name type is used, the principal's 4. The client obtains the encryption key, decrypts the reply,
realm MUST be set to the certificate authority's distinguished and then proceeds as usual.
name using the X500-RFC2253 realm name format described earlier in
this section.
Note that the same string may be represented using several different Section 3.1 of this document defines the necessary message formats.
ASN.1 data types. As the result, the reverse conversion from an Section 3.2 describes their syntax and use in greater detail.
RFC2253-encoded principal name back to an X.500 name may not be Implementation of all specified formats and uses in these sections
unique and may result in an X.500 name that is not the same as the is REQUIRED for compliance with PKINIT.
original X.500 name found in the client certificate.
RFC 1510bis describes an alternate encoding of an X.500 name into a 3.1. Definitions
realm name. However, as described in RFC 1510bis, the alternate
encoding does not guarantee a unique mapping from a
DistinguishedName inside a certificate into a realm name and
similarly cannot be used to produce a unique principal name. PKINIT
therefore uses an RFC 2253-based name mapping approach, as specified
above.
RFC 1510bis specifies the ASN.1 structure for PrincipalName as follows: 3.1.1. Required Algorithms
PrincipalName ::= SEQUENCE { [What is the current list of required algorithm? --brian]
name-type[0] INTEGER,
name-string[1] SEQUENCE OF GeneralString
}
The following rules relate to the the matching of PrincipalNames 3.1.2. Defined Message and Encryption Types
with regard to the PKI name constraints for CAs as laid out in RFC
2459 [12]. In order to be regarded as a match (for permitted and
excluded name trees), the following MUST be satisfied.
1. If the constraint is given as a user plus realm name, or PKINIT makes use of the following new preauthentication types:
as a client principal name plus realm name (as specified in
RFC 1510bis), the realm name MUST be valid (see 2.a-d below)
and the match MUST be exact, byte for byte.
2. If the constraint is given only as a realm name, matching PA-PK-AS-REQ TBD
depends on the type of the realm: PA-PK-AS-REP TBD
a. If the realm contains a colon (':') before any equal PKINIT introduces the following new error types:
sign ('='), it is treated as a realm of type Other,
and MUST match exactly, byte for byte.
b. Otherwise, if the realm name conforms to rules regarding KDC_ERR_CLIENT_NOT_TRUSTED 62
the format of DNS names, it is considered a realm name of KDC_ERR_KDC_NOT_TRUSTED 63
type Domain. The constraint may be given as a realm KDC_ERR_INVALID_SIG 64
name 'FOO.BAR', which matches any PrincipalName within KDC_ERR_KEY_TOO_WEAK 65
the realm 'FOO.BAR' but not those in subrealms such as KDC_ERR_CERTIFICATE_MISMATCH 66
'CAR.FOO.BAR'. A constraint of the form '.FOO.BAR' KDC_ERR_CANT_VERIFY_CERTIFICATE 70
matches PrincipalNames in subrealms of the form KDC_ERR_INVALID_CERTIFICATE 71
'CAR.FOO.BAR' but not the realm 'FOO.BAR' itself. KDC_ERR_REVOKED_CERTIFICATE 72
KDC_ERR_REVOCATION_STATUS_UNKNOWN 73
KDC_ERR_CLIENT_NAME_MISMATCH 75
c. Otherwise, the realm name is invalid and does not match PKINIT uses the following typed data types for errors:
under any conditions.
3.1.1. Encryption and Key Formats TD-DH-PARAMETERS 102
TD-TRUSTED-CERTIFIERS 104
TD-CERTIFICATE-INDEX 105
In the exposition below, we use the terms public key and private PKINIT defines the following encryption types, for use in the AS-REQ
key generically. It should be understood that the term "public message (to indicate acceptance of the corresponding encryption OIDs
key" may be used to refer to either a public encryption key or a in PKINIT):
signature verification key, and that the term "private key" may be
used to refer to either a private decryption key or a signature
generation key. The fact that these are logically distinct does
not preclude the assignment of bitwise identical keys for RSA
keys.
In the case of Diffie-Hellman, the key is produced from the agreed dsaWithSHA1-CmsOID 9
bit string as follows: md5WithRSAEncryption-CmsOID 10
sha1WithRSAEncryption-CmsOID 11
rc2CBC-EnvOID 12
rsaEncryption-EnvOID (PKCS1 v1.5) 13
rsaES-OAEP-ENV-OID (PKCS1 v2.0) 14
des-ede3-cbc-Env-OID 15
* Truncate the bit string to the required length. The above encryption types are used (in PKINIT) only within CMS [8]
* Apply the specific cryptosystem's random-to-key function. structures within the PKINIT preauthentication fields. Their use
within Kerberos EncryptedData structures is unspecified.
Appropriate key constraints for each valid cryptosystem are given 3.1.3. Algorithm Identifiers
in RFC 1510bis.
3.1.2. Algorithm Identifiers PKINIT does not define, but does make use of, the following
algorithm identifiers.
PKINIT does not define, but does permit, the algorithm identifiers PKINIT uses the following algorithm identifier for Diffie-Hellman
listed below. key agreement [11]:
3.1.2.1. Signature Algorithm Identifiers dhpublicnumber
The following signature algorithm identifiers specified in [8] and PKINIT uses the following signature algorithm identifiers [8, 12]:
in [12] are used with PKINIT:
sha-1WithRSAEncryption (RSA with SHA1) sha-1WithRSAEncryption (RSA with SHA1)
md5WithRSAEncryption (RSA with MD5) md5WithRSAEncryption (RSA with MD5)
id-dsa-with-sha1 (DSA with SHA1) id-dsa-with-sha1 (DSA with SHA1)
3.1.2.2 Diffie-Hellman Key Agreement Algorithm Identifier PKINIT uses the following encryption algorithm identifiers [12] for
encrypting the temporary key with a public key:
The following algorithm identifier shall be used within the
SubjectPublicKeyInfo data structure: dhpublicnumber
This identifier and the associated algorithm parameters are
specified in RFC 2459 [12].
3.1.2.3. Algorithm Identifiers for RSA Encryption
These algorithm identifiers are used inside the EnvelopedData data
structure, for encrypting the temporary key with a public key:
rsaEncryption (RSA encryption, PKCS#1 v1.5) rsaEncryption (PKCS1 v1.5)
id-RSAES-OAEP (RSA encryption, PKCS#1 v2.0) id-RSAES-OAEP (PKCS1 v2.0)
Both of the above RSA encryption schemes are specified in [13]. These OIDs are not to be confused with the encryption types listed
Currently, only PKCS#1 v1.5 is specified by CMS [8], although the above.
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 PKINIT uses the following algorithm identifiers [8] for encrypting
the reply key with the temporary key:
These algorithm identifiers are used inside the EnvelopedData data des-ede3-cbc (three-key 3DES, CBC mode)
structure in the PKINIT Reply, for encrypting the reply key with the rc2-cbc (RC2, CBC mode)
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 Again, these OIDs are not to be confused with the encryption types
corresponding parameters (an IV for block chaining) is provided in listed above.
the CMS specification [8].
3.2. Public Key Authentication 3.2. PKINIT Preauthentication Syntax and Use
Implementation of the changes in this section is REQUIRED for In this section, we describe the syntax and use of the various
compliance with PKINIT. preauthentication fields employed to implement PKINIT.
3.2.1. Client Request 3.2.1. Client Request
Public keys may be signed by some certification authority (CA), or The initial authentication request (AS-REQ) is sent as per RFC
they may be maintained by the KDC in which case the KDC is the 1510bis, except that a preauthentication field containing data
trusted authority. Note that the latter mode does not require the signed by the user's private signature key accompanies the request,
use of certificates. as follows:
The initial authentication request is sent as per RFC 1510bis, except
that a preauthentication field containing data signed by the user's
private key accompanies the request:
PA-PK-AS-REQ ::= SEQUENCE { PA-PK-AS-REQ ::= SEQUENCE {
-- PA TYPE 14 -- PAType TBD
signedAuthPack [0] ContentInfo, signedAuthPack [0] ContentInfo,
-- Defined in CMS [8]; -- Defined in CMS.
-- SignedData OID is {pkcs7 2} -- Type is SignedData.
-- AuthPack (below) defines the -- Content is AuthPack
-- data that is signed. -- (defined below).
trustedCertifiers [1] SEQUENCE OF TrustedCas OPTIONAL, trustedCertifiers [1] SEQUENCE OF TrustedCAs OPTIONAL,
-- This is a list of CAs that the -- A list of CAs, trusted by
-- client trusts and that certify -- the client, used to certify
-- KDCs. -- KDCs.
kdcCert [2] IssuerAndSerialNumber OPTIONAL kdcCert [2] IssuerAndSerialNumber OPTIONAL,
-- As defined in CMS [8]; -- Defined in CMS.
-- specifies a particular KDC -- Identifies a particular KDC
-- certificate if the client -- certificate, if the client
-- already has it. -- already has it.
encryptionCert [3] IssuerAndSerialNumber OPTIONAL encryptionCert [3] IssuerAndSerialNumber OPTIONAL,
-- For example, this may be the -- May identify the user's
-- client's Diffie-Hellman -- Diffie-Hellman certificate,
-- certificate, or it may be the -- or an RSA encryption key
-- client's RSA encryption
-- certificate. -- certificate.
...
} }
TrustedCas ::= CHOICE { TrustedCAs ::= CHOICE {
principalName [0] KerberosName, caName [0] Name,
-- as defined below -- Fully qualified X.500 name
caName [1] Name -- as defined in X.509 [11].
-- fully qualified X.500 name issuerAndSerial [1] IssuerAndSerialNumber,
-- as defined by X.509 -- Identifies a specific CA
issuerAndSerial [2] IssuerAndSerialNumber -- certificate, if the client
-- Since a CA may have a number of -- only trusts one.
-- certificates, only one of which ...
-- a client trusts
} }
The type of the ContentInfo in the signedAuthPack is SignedData. [Should we even allow principalName as a choice? --brian]
Its usage is as follows:
The SignedData data type is specified in the Cryptographic
Message Syntax, a product of the S/MIME working group of the
IETF. The following describes how to fill in the fields of
this data:
1. The encapContentInfo field MUST contain the PKAuthenticator
and, optionally, the client's Diffie Hellman public value.
a. The eContentType field MUST contain the OID value for
pkauthdata: iso (1) org (3) dod (6) internet (1)
security (5) kerberosv5 (2) pkinit (3) pkauthdata (1)
b. The eContent field is data of the type AuthPack (below).
2. The signerInfos field contains the signature of AuthPack.
3. The Certificates field, when non-empty, contains the client's
certificate chain. If present, the KDC uses the public key
from the client's certificate to verify the signature in the
request. Note that the client may pass different certificate
chains that are used for signing or for encrypting. Thus,
the KDC may utilize a different client certificate for
signature verification than the one it uses to encrypt the
reply to the client. For example, the client may place a
Diffie-Hellman certificate in this field in order to convey
its static Diffie Hellman certificate to the KDC to enable
static-ephemeral Diffie-Hellman mode for the reply; in this
case, the client does NOT place its public value in the
AuthPack (defined below). As another example, the client may
place an RSA encryption certificate in this field. However,
there MUST always be (at least) a signature certificate.
4. When a DH key is being used, the public exponent is provided
in the subjectPublicKey field of the SubjectPublicKeyInfo and
the DH parameters are supplied as a DomainParameters in the
AlgorithmIdentitfier parameters. The DH paramters SHOULD be
chosen from the First and Second defined Oakley Groups [The
Internet Key Exchange (IKE) RFC-2409], if a server will not
accept either of these groups, it will respond with a krb-
error of KDC_ERR_KEY_TOO_WEAK. The accompanying e-data is
a SEQUENCE of TypedData that includes type
TD-DH-PARAMETERS (102) whose data-value is DomainParameters
with appropriate Diffie-Hellman parameters for the client to
use.
5. The KDC may wish to use cached Diffie-Hellman parameters
(see Section 3.2.2, KDC Response). To indicate acceptance
of cached parameters, the client sends zero in the nonce
field of the PKAuthenticator. Zero is not a valid value
for this field under any other circumstances. If cached
parameters are used, the client and the KDC MUST perform
key derivation (for the appropriate cryptosystem) on the
resulting encryption key, as specified in RFC 1510bis. (With
a zero nonce, message binding is performed using the nonce
in the main request, which must be encrypted using the
encapsulated reply key.)
AuthPack ::= SEQUENCE { AuthPack ::= SEQUENCE {
pkAuthenticator [0] PKAuthenticator, pkAuthenticator [0] PKAuthenticator,
clientPublicValue [1] SubjectPublicKeyInfo OPTIONAL clientPublicValue [1] SubjectPublicKeyInfo OPTIONAL
-- if client is using Diffie-Hellman -- Defined in X.509,
-- (ephemeral-ephemeral only) -- reproduced below.
-- Present only if the client
-- is using ephemeral-ephemeral
-- Diffie-Hellman.
} }
PKAuthenticator ::= SEQUENCE { PKAuthenticator ::= SEQUENCE {
cusec [0] INTEGER, cusec [0] INTEGER,
-- for replay prevention as in RFC 1510bis
ctime [1] KerberosTime, ctime [1] KerberosTime,
-- for replay prevention as in RFC 1510bis -- cusec and ctime are used as
-- in RFC 1510bis, for replay
-- prevention.
nonce [2] INTEGER, nonce [2] INTEGER,
-- zero only if client will accept -- Binds reply to request,
-- cached DH parameters from KDC; -- except is zero when client
-- must be non-zero otherwise -- will accept cached
pachecksum [3] Checksum -- Diffie-Hellman parameters
-- Checksum over KDC-REQ-BODY -- from KDC and MUST NOT be
-- Defined by Kerberos spec; -- zero otherwise.
-- must be unkeyed, e.g. sha1 or rsa-md5 paChecksum [3] Checksum,
-- Defined in RFC 1510bis.
-- Performed over KDC-REQ-BODY,
-- must be unkeyed.
...
} }
SubjectPublicKeyInfo ::= SEQUENCE { SubjectPublicKeyInfo ::= SEQUENCE {
-- As defined in X.509.
algorithm AlgorithmIdentifier, algorithm AlgorithmIdentifier,
-- dhPublicNumber -- Equals dhpublicnumber (see
-- AlgorithmIdentifier, below)
-- for PKINIT.
subjectPublicKey BIT STRING subjectPublicKey BIT STRING
-- for DH, equals -- Equals public exponent
-- public exponent (INTEGER encoded -- (INTEGER encoded as payload
-- as payload of BIT STRING) -- of BIT STRING) for PKINIT.
} -- as specified by the X.509 recommendation [7] }
AlgorithmIdentifier ::= SEQUENCE { AlgorithmIdentifier ::= SEQUENCE {
-- As defined in X.509.
algorithm OBJECT IDENTIFIER, algorithm OBJECT IDENTIFIER,
-- for dhPublicNumber, this is -- dhpublicnumber is
-- { iso (1) member-body (2) US (840) -- { iso (1) member-body (2)
-- ansi-x942(10046) number-type(2) 1 } -- US (840) ansi-x942 (10046)
-- from RFC 2459 [12] -- number-type (2) 1 }
parameters ANY DEFINED by algorithm OPTIONAL -- From RFC 2459 [11].
-- for dhPublicNumber, this is parameters ANY DEFINED BY algorithm OPTIONAL
-- DomainParameters -- Content is DomainParameters
} -- as specified by the X.509 recommendation [7] -- (see below) for PKINIT.
}
DomainParameters ::= SEQUENCE { DomainParameters ::= SEQUENCE {
p INTEGER, -- odd prime, p=jq +1 -- As defined in RFC 2459.
g INTEGER, -- generator, g p INTEGER,
q INTEGER, -- factor of p-1 -- p is the odd prime, equals
j INTEGER OPTIONAL, -- subgroup factor -- jq+1.
g INTEGER,
-- Generator.
q INTEGER,
-- Divides p-1.
j INTEGER OPTIONAL,
-- Subgroup factor.
validationParms ValidationParms OPTIONAL validationParms ValidationParms OPTIONAL
} -- as defined in RFC 2459 [12] }
ValidationParms ::= SEQUENCE { ValidationParms ::= SEQUENCE {
-- As defined in RFC 2459.
seed BIT STRING, seed BIT STRING,
-- seed for the system parameter -- Seed for the system parameter
-- generation process -- generation process.
pgenCounter INTEGER pgenCounter INTEGER
-- integer value output as part -- Integer value output as part
-- of the of the system parameter -- of the system parameter
-- prime generation process -- generation process.
} -- as defined in RFC 2459 [12] }
If the client passes an issuer and serial number in the request,
the KDC is requested to use the referred-to certificate. If none
exists, then the KDC returns an error of type
KDC_ERR_CERTIFICATE_MISMATCH. It also returns this error if, on the
other hand, the client does not pass any trustedCertifiers,
believing that it has the KDC's certificate, but the KDC has more
than one certificate. The KDC should include information in the
KRB-ERROR message that indicates the KDC certificate(s) that a
client may utilize. This data is specified in the e-data, which
is defined in RFC 1510bis revisions as a SEQUENCE of TypedData:
TypedData ::= SEQUENCE {
data-type [0] INTEGER,
data-value [1] OCTET STRING,
} -- per Kerberos RFC 1510bis
where one of the TypedData elements is: The ContentInfo in the signedAuthPack is filled out as follows:
data-type = TD-PKINIT-CMS-CERTIFICATES = 101
data-value = CertificateSet // as specified by CMS [8]
The PKAuthenticator carries information to foil replay attacks, to 1. The eContent field contains data of type AuthPack. It MUST
bind the pre-authentication data to the KDC-REQ-BODY, and to bind the contain the pkAuthenticator, and MAY also contain the
request and response. The PKAuthenticator is signed with the client's user's Diffie-Hellman public value (clientPublicValue).
signature key.
3.2.2. KDC Response 2. The eContentType field MUST contain the OID value for
pkauthdata: { iso (1) org (3) dod (6) internet (1)
security (5) kerberosv5 (2) pkinit (3) pkauthdata (1)}
Upon receipt of the AS_REQ with PA-PK-AS-REQ pre-authentication 3. The signerInfos field MUST contain the signature of the
type, the KDC attempts to verify the client's certificate chain, if AuthPack.
one is provided in the request. This is done by verifying the
certification path against the KDC's policy of legitimate
certifiers.
If the KDC cannot find a trusted client certificate chain within 4. The certificates field MUST contain at least a signature
the PA-PK-AS-REQ, then the KDC sends back an error message of type verification certificate chain that the KDC can use to
KDC_ERR_CANT_VERIFY_CERTIFICATE. Certificate chain validation is verify the signature on the AuthPack. Additionally, the
defined in RFC 2459 [12]. The accompanying e-data for this error client may also insert an encryption certificate chain, if
code is a SEQUENCE of TypedData that includes type (for example) the client is not using ephemeral-ephemeral
TD-TRUSTED-CERTIFIERS (104) whose data-value is an OCTET STRING Diffie-Hellman.
which is the DER encoding of
TrustedCertifiers ::= SEQUENCE OF PrincipalName 5. If a Diffie-Hellman key is being used, the parameters SHOULD
-- X.500 name encoded as a principal name be chosen from the First or Second defined Oakley Groups.
-- see Section 3.1 (See RFC 2409 [c].)
If while verifying a certificate chain the KDC determines that the 6. The KDC may wish to use cached Diffie-Hellman parameters.
signature on one of the certificates in the CertificateSet from To indicate acceptance of caching, the client sends zero in
the signedAuthPack fails verification, then the KDC returns an the nonce field of the pkAuthenticator. Zero is not a valid
error of type KDC_ERR_INVALID_CERTIFICATE. The accompanying value for this field under any other circumstances. Since
e-data is a SEQUENCE of TypedData that includes type zero is used to indicate acceptance of cached parameters,
TD-CERTIFICATE-INDEX (105) whose data-value is an OCTET STRING message binding in this case is performed instead using the
which is the DER encoding of the index into the CertificateSet nonce in the main request.
ordered as sent by the client.
CertificateIndex ::= INTEGER 3.2.2. Validation of Client Request
-- 0 = 1st certificate,
-- (in order of encoding)
-- 1 = 2nd certificate, etc
The KDC may also check whether any of the certificates in the Upon receiving the client's request, the KDC validates it. This
client's chain has been revoked. If one of the certificates has section describes the steps that the KDC MUST (unless otherwise
been revoked, then the KDC returns an error of type noted) take in validating the request.
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 The KDC must look for a user certificate in the signedAuthPack.
client in the certificate does not match the client's name in the If it cannot find one signed by a CA it trusts, it sends back an
request, then the KDC returns an error of type error of type KDC_ERR_CANT_VERIFY_CERTIFICATE. The accompanying
KDC_ERR_CLIENT_NAME_MISMATCH. There is no accompanying e-data e-data for this error is a SEQUENCE OF TypedData:
field in this case.
Even if all succeeds, the KDC may--for policy reasons--decide not TypedData ::= SEQUENCE {
to trust the client. In this case, the KDC returns an error message -- As defined in RFC 1510bis.
of type KDC_ERR_CLIENT_NOT_TRUSTED. One specific case of this is data-type [0] INTEGER,
the presence or absence of an Enhanced Key Usage (EKU) OID within data-value [1] OCTET STRING
the certificate extensions. The rules regarding acceptability of }
an EKU sequence (or the absence of any sequence) are a matter of
local policy. For the benefit of implementers, we define a PKINIT
EKU OID as the following: iso (1) org (3) dod (6) internet (1)
security (5) kerberosv5 (2) pkinit (3) pkekuoid (2).
If a trust relationship exists, the KDC then verifies the client's For this error, the data-type is TD-TRUSTED-CERTIFIERS, and the
signature on AuthPack. If that fails, the KDC returns an error data-value is an OCTET STRING containing the DER encoding of
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 TrustedCertifiers ::= SEQUENCE OF Name
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. The accompanying e-data is a SEQUENCE of
TypedData that includes type TD-DH-PARAMETERS (102) whose data-value
is DomainParameters with appropriate Diffie-Hellman parameters for
the client to retry the request. Otherwise, it generates its own
public and private values for the response.
The KDC also checks that the timestamp in the PKAuthenticator is If, while verifying the certificate chain, the KDC determines that
within the allowable window and that the principal name and realm the signature on one of the certificates in the signedAuthPack is
are correct. If the local (server) time and the client time in the invalid, it returns an error of type KDC_ERR_INVALID_CERTIFICATE.
authenticator differ by more than the allowable clock skew, then the The accompanying e-data for this error is a SEQUENCE OF TypedData,
KDC returns an error message of type KRB_AP_ERR_SKEW as defined in whose data-type is TD-CERTIFICATE-INDEX, and whose data-value is an
RFC 1510bis. OCTET STRING containing the DER encoding of the index into the
CertificateSet field, ordered as sent by the client:
Assuming no errors, the KDC replies as per RFC 1510bis, except as CertificateIndex ::= INTEGER
follows. The user's name in the ticket is determined by the -- 0 = first certificate (in
following decision algorithm: -- order of encoding),
-- 1 = second certificate, etc.
1. If the KDC has a mapping from the name in the certificate If more than one signature is invalid, the KDC sends one TypedData
to a Kerberos name, then use that name. per invalid signature.
Else
2. If the certificate contains the SubjectAltName extention
and the local KDC policy defines a mapping from the
SubjectAltName to a Kerberos name, then use that name.
Else
3. Use the name as represented in the certificate, mapping
as necessary (e.g., as per RFC 2253 for X.500 names). In
this case the realm in the ticket MUST be the name of the
certifier that issued the user's certificate.
Note that a principal name may be carried in the subjectAltName The KDC MAY also check whether any of the certificates in the user's
field of a certificate. This name may be mapped to a principal chain have been revoked. If any of them have been revoked, the KDC
record in a security database based on local policy, for example returns an error of type KDC_ERR_REVOKED_CERTIFICATE; if the KDC
the subjectAltName may be kerberos/principal@realm format. In attempts to determine the revocation status but is unable to do so,
this case the realm name is not that of the CA but that of the it returns an error of type KDC_ERR_REVOCATION_STATUS_UNKNOWN. In
local realm doing the mapping (or some realm name chosen by that either case, the certificate or certificates affected are identified
realm). exactly as for an error of type KDC_ERR_INVALID_CERTIFICATE (see
above).
If a non-KDC X.509 certificate contains the principal name within If the certificate chain is successfully validated, but the name in
the subjectAltName version 3 extension, that name may utilize the user's certificate does not match the name given in the request,
KerberosName as defined below, or, in the case of an S/MIME the KDC returns an error of type KDC_ERR_CLIENT_NAME_MISMATCH. There
certificate [14], may utilize the email address. If the KDC is no accompanying e-data for this error.
is presented with an S/MIME certificate, then the email address
within subjectAltName will be interpreted as a principal and realm
separated by the "@" sign, or as a name that needs to be mapped
according to local policy. If the resulting name does not correspond
to a registered principal name, then the principal name is formed as
defined in section 3.1.
The trustedCertifiers field contains a list of certification Even if the chain is validated, and the names in the certificate and
authorities trusted by the client, in the case that the client does the request match, the KDC may decide not to trust the client. For
not possess the KDC's public key certificate. If the KDC has no example, the certificate may include (or not include) an Enhanced
certificate signed by any of the trustedCertifiers, then it returns Key Usage (EKU) OID in the extensions field. As a matter of local
an error of type KDC_ERR_KDC_NOT_TRUSTED. policy, the KDC may decide to reject requests on the basis of the
absence or presence of specific EKU OIDs. In this case, the KDC
returns an error of type KDC_ERR_CLIENT_NOT_TRUSTED. For the
benefit of implementors, we define a PKINIT EKU OID as follows:
{ iso (1) org (3) dod (6) internet (1) security (5) kerberosv5 (2)
pkinit (3) pkekuoid (2) }.
KDCs should try to (in order of preference): If the certificate chain and usage check out, but the client's
1. Use the KDC certificate identified by the serialNumber included signature on the signedAuthPack fails to verify, the KDC returns an
in the client's request. error of type KDC_ERR_INVALID_SIG. There is no accompanying e-data
2. Use a certificate issued to the KDC by one of the client's for this error.
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 [What about the case when all this checks out but one or more
with the Diffie Hellman derived key or a random key generated certificates is rejected for other reasons? For example, perhaps
for this particular response which is carried in the padata field of the key is too short for local policy. --DRE]
the TGS-REP message.
PA-PK-AS-REP ::= CHOICE { The KDC must check the timestamp to ensure that the request is not
-- PA TYPE 15 a replay, and that the time skew falls within acceptable limits. If
dhSignedData [0] ContentInfo, the check fails, the KDC returns an error of type KRB_AP_ERR_REPEAT
-- Defined in CMS [8] and used only with or KRB_AP_ERR_SKEW, respectively.
-- Diffie-Hellman key exchange (if the
-- client public value was present in the
-- request).
-- SignedData OID is {pkcs7 2}
-- This choice MUST be supported
-- by compliant implementations.
encKeyPack [1] ContentInfo
-- Defined in CMS [8].
-- The temporary key is encrypted
-- using the client public key
-- key.
-- EnvelopedData OID is {pkcs7 3}
-- SignedReplyKeyPack, encrypted
-- with the temporary key, is also
-- included.
}
The type of the ContentInfo in the dhSignedData is SignedData. Finally, if the clientPublicValue is filled in, indicating that the
Its usage is as follows: client wishes to use ephemeral-ephemeral Diffie-Hellman, the KDC
checks to see if the parameters satisfy its policy. If they do not,
it returns an error of type KDC_ERR_KEY_TOO_WEAK. The accompanying
e-data is a SEQUENCE OF TypedData, whose data-type is
TD-DH-PARAMETERS, and whose data-value is an OCTET STRING containing
the DER encoding of a DomainParameters (see above), including
appropriate Diffie-Hellman parameters with which to retry the
request.
When the Diffie-Hellman option is used, dhSignedData in [This makes no sense. For example, maybe the key is too strong for
PA-PK-AS-REP provides authenticated Diffie-Hellman parameters local policy. --DRE]
of the KDC. The reply key used to encrypt part of the KDC reply
message is derived from the Diffie-Hellman exchange:
1. Both the KDC and the client calculate a secret value In order to establish authenticity of the reply, the KDC will sign
(g^ab mod p), where a is the client's private exponent and some key data (either the random key used to encrypt the reply in
b is the KDC's private exponent. the case of a KDCDHKeyInfo, or the Diffie-Hellman parameters used to
generate the reply-encrypting key in the case of a ReplyKeyPack).
The signature certificate to be used is to be selected as follows:
2. Both the KDC and the client take the first N bits of this 1. If the client included a kdcCert field in the PA-PK-AS-REQ,
secret value and convert it into a reply key. N depends on use the referred-to certificate, if the KDC has it. If it
the reply key type. does not, the KDC returns an error of type
KDC_ERR_CERTIFICATE_MISMATCH.
a. For example, if the reply key is DES, N=64 bits, where 2. Otherwise, if the client did not include a kdcCert field,
some of the bits are replaced with parity bits, according but did include a trustedCertifiers field, and the KDC
to FIPS PUB 74. possesses a certificate issued by one of the listed
certifiers, use that certificate. if it does not possess
one, it returns an error of type KDC_ERR_KDC_NOT_TRUSTED.
b. As another example, if the reply key is (3-key) 3-DES, 3. Otherwise, if the client included neither a kdcCert field
N=192 bits, where some of the bits are replaced with nor a trustedCertifiers field, and the KDC has only one
parity bits, according to FIPS PUB 74. signature certificate, use that certificate. If it has
more than one certificate, it returns an error of type
KDC_ERR_CERTIFICATE_MISMATCH.
3. The encapContentInfo field MUST contain the KdcDHKeyInfo as 3.2.3. KDC Reply
defined below.
a. The eContentType field MUST contain the OID value for Assuming that the client's request has been properly validated, the
pkdhkeydata: iso (1) org (3) dod (6) internet (1) KDC proceeds as per RFC 1510bis, except as follows.
security (5) kerberosv5 (2) pkinit (3) pkdhkeydata (2)
b. The eContent field is data of the type KdcDHKeyInfo The user's name as represented in the AS-REP must be derived from
(below). the certificate provided in the client's request. If the KDC has
its own mapping from the name in the certificate to a Kerberos name,
it uses that Kerberos name.
4. The certificates field MUST contain the certificates Otherwise, if the certificate contains a subjectAltName extension
necessary for the client to establish trust in the KDC's with PrincipalName, it uses that name. In this case, the realm in
certificate based on the list of trusted certifiers sent by the ticket is that of the local realm (or some other realm name
the client in the PA-PK-AS-REQ. This field may be empty if chosen by that realm). (OID and syntax for this extension to be
the client did not send to the KDC a list of trusted specified here.) Otherwise, the KDC returns an error of type
certifiers (the trustedCertifiers field was empty, meaning KDC_ERR_CLIENT_NAME_MISMATCH.
that the client already possesses the KDC's certificate).
5. The signerInfos field is a SET that MUST contain at least In addition, the certifiers in the certification path of the user's
one member, since it contains the actual signature. certificate MUST be added to an authdata (to be specified at a later
time).
6. If the client indicated acceptance of cached Diffie-Hellman The AS-REP is otherwise unchanged from RFC 1510bis. The KDC then
parameters from the KDC, and the KDC supports such an option encrypts the reply as usual, but not with the user's long-term key.
(for performance reasons), the KDC should return a zero in Instead, it encrypts it with either a random encryption key, or a
the nonce field and include the expiration time of the key derived through a Diffie-Hellman exchange. Which is the case is
parameters in the dhKeyExpiration field. If this time is indicated by the contents of the PA-PK-AS-REP (note tags):
exceeded, the client SHOULD NOT use the reply. If the time
is absent, the client SHOULD NOT use the reply and MAY
resubmit a request with a non-zero nonce (thus indicating
non-acceptance of cached Diffie-Hellman parameters). As
indicated above in Section 3.2.1, Client Request, when the
KDC uses cached parameters, the client and the KDC MUST
perform key derivation (for the appropriate cryptosystem)
on the resulting encryption key, as specified in RFC 1510bis.
KdcDHKeyInfo ::= SEQUENCE { PA-PK-AS-REP ::= CHOICE {
-- used only when utilizing Diffie-Hellman -- PAType YY (TBD)
subjectPublicKey [0] BIT STRING, dhSignedData [0] ContentInfo,
-- Equals public exponent (g^a mod p) -- Type is SignedData.
-- INTEGER encoded as payload of -- Content is KDCDHKeyInfo
-- BIT STRING -- (defined below).
nonce [1] INTEGER, encKeyPack [1] ContentInfo,
-- Binds response to the request -- Type is EnvelopedData.
-- Exception: Set to zero when KDC -- Content is ReplyKeyPack
-- is using a cached DH value -- (defined below).
dhKeyExpiration [2] KerberosTime OPTIONAL ...
-- Expiration time for KDC's cached
-- DH value
} }
The type of the ContentInfo in the encKeyPack is EnvelopedData. Its Note that PA-PK-AS-REP is a CHOICE: either a dhSignedData, or an
usage is as follows: encKeyPack, but not both. The former contains data of type
KDCDHKeyInfo, and is used only when the reply is encrypted using a
The EnvelopedData data type is specified in the Cryptographic Diffie-Hellman derived key:
Message Syntax, a product of the S/MIME working group of the
IETF. It contains a temporary key encrypted with the PKINIT
client's public key. It also contains a signed and encrypted
reply key.
1. The originatorInfo field is not required, since that
information may be presented in the signedData structure
that is encrypted within the encryptedContentInfo field.
2. The optional unprotectedAttrs field is not required for KDCDHKeyInfo ::= SEQUENCE {
PKINIT. subjectPublicKey [0] BIT STRING,
-- Equals public exponent
-- (g^a mod p).
-- INTEGER encoded as payload
-- of BIT STRING.
nonce [1] INTEGER,
-- Binds reply to request.
-- Exception: A value of zero
-- indicates that the KDC is
-- using cached values.
dhKeyExpiration [2] KerberosTime OPTIONAL,
-- Expiration time for KDC's
-- cached values.
...
}
3. The recipientInfos field is a SET which MUST contain exactly The fields of the ContentInfo for dhSignedData are to be filled in
one member of the KeyTransRecipientInfo type for encryption as follows:
with a public key.
a. The encryptedKey field (in KeyTransRecipientInfo) 1. The eContent field contains data of type KDCDHKeyInfo.
contains the temporary key which is encrypted with the
PKINIT client's public key.
4. The encryptedContentInfo field contains the signed and 2. The eContentType field contains the OID value for
encrypted reply key. pkdhkeydata: { iso (1) org (3) dod (6) internet (1)
security (5) kerberosv5 (2) pkinit (3) pkdhkeydata (2) }
a. The contentType field MUST contain the OID value for 3. The signerInfos field contains a single signerInfo, which is
id-signedData: iso (1) member-body (2) us (840) the signature of the KDCDHKeyInfo.
rsadsi (113549) pkcs (1) pkcs7 (7) signedData (2)
b. The encryptedContent field is encrypted data of the CMS 4. The certificates field contains a signature verification
type signedData as specified below. certificate chain that the client may use to verify the
KDC's signature over the KDCDHKeyInfo.) It may only be left
empty if the client did not include a trustedCertifiers
field in the PA-PK-AS-REQ, indicating that it has the KDC's
certificate.
i. The encapContentInfo field MUST contains the 5. If the client and KDC agree to use cached parameters, the
ReplyKeyPack. KDC SHOULD return a zero in the nonce field and include the
expiration time of the cached values in the dhKeyExpiration
field. If this time is exceeded, the client SHOULD NOT use
the reply. If the time is absent, the client SHOULD NOT use
the reply and MAY resubmit a request with a non-zero nonce,
thus indicating non-acceptance of the cached parameters.
* The eContentType field MUST contain the OID value The key is derived as follows: Both the KDC and the client calculate
for pkrkeydata: iso (1) org (3) dod (6) internet (1) the value g^(ab) mod p, where a and b are the client and KDC's
security (5) kerberosv5 (2) pkinit (3) pkrkeydata (3) private exponents, respectively. They both take the first N bits of
this secret value and convert it into a reply key, where N depends
on the key type.
* The eContent field is data of the type ReplyKeyPack 1. For example, if the key type is DES, N = 64 bits, where some
(below). of the bits are replaced with parity bits, according to FIPS
PUB 74 [c].
ii. The certificates field MUST contain the certificates 2. If the key type is (three-key) 3DES, N = 192 bits, where
necessary for the client to establish trust in the some of the bits are replaced with parity bits, again
KDC's certificate based on the list of trusted according to FIPS PUB 74.
certifiers sent by the client in the PA-PK-AS-REQ.
This field may be empty if the client did not send
to the KDC a list of trusted certifiers (the
trustedCertifiers field was empty, meaning that the
client already possesses the KDC's certificate).
iii. The signerInfos field is a SET that MUST contain at If the KDC and client are not using Diffie-Hellman, the KDC encrypts
least one member, since it contains the actual the reply with an encryption key, packed in the encKeyPack, which
signature. contains data of type ReplyKeyPack:
ReplyKeyPack ::= SEQUENCE { ReplyKeyPack ::= SEQUENCE {
-- not used for Diffie-Hellman replyKey [0] EncryptionKey,
replyKey [0] EncryptionKey, -- Defined in RFC 1510bis.
-- from RFC 1510bis -- Used to encrypt main reply.
-- used to encrypt main reply -- MUST be at least as strong as
-- ENCTYPE is at least as strong as -- enctype of session key.
-- ENCTYPE of session key nonce [1] INTEGER,
nonce [1] INTEGER, -- Binds reply to request.
-- binds response to the request ...
-- must be same as the nonce
-- passed in the PKAuthenticator
} }
3.2.2.1. Use of transited Field [What exactly does "at least as strong" mean? --DRE]
Since each certifier in the certification path of a user's
certificate is equivalent to a separate Kerberos realm, the name
of each certifier in the certificate chain MUST be added to the
transited field of the ticket. The format of these realm names is
defined in Section 3.1 of this document. If applicable, the
transit-policy-checked flag should be set in the issued ticket.
3.2.2.2. Kerberos Names in Certificates
The KDC's certificate(s) MUST bind the public key(s) of the KDC to
a name derivable from the name of the realm for that KDC. X.509
certificates MUST contain the principal name of the KDC (defined in
RFC 1510bis) as the SubjectAltName version 3 extension. Below is
the definition of this version 3 extension, as specified by the
X.509 standard:
subjectAltName EXTENSION ::= {
SYNTAX GeneralNames
IDENTIFIED BY id-ce-subjectAltName
}
GeneralNames ::= SEQUENCE SIZE(1..MAX) OF GeneralName
GeneralName ::= CHOICE {
otherName [0] OtherName,
...
}
OtherName ::= SEQUENCE {
type-id OBJECT IDENTIFIER,
value [0] EXPLICIT ANY DEFINED BY type-id
}
For the purpose of specifying a Kerberos principal name, the value
in OtherName MUST be a KerberosName, defined as follows:
KerberosName ::= SEQUENCE {
realm [0] Realm,
principalName [1] PrincipalName
}
This specific syntax is identified within subjectAltName by setting
the type-id in OtherName to krb5PrincipalName, where (from the
Kerberos specification) we have
krb5 OBJECT IDENTIFIER ::= { iso (1) The fields of the ContentInfo for encKeyPack MUST be filled in as
org (3) follows:
dod (6)
internet (1)
security (5)
kerberosv5 (2) }
krb5PrincipalName OBJECT IDENTIFIER ::= { krb5 2 } 1. The innermost data is of type SignedData. The eContent for
this data is of type ReplyKeyPack.
(This specification may also be used to specify a Kerberos name 2. The eContentType for this data contains the OID value for
within the user's certificate.) The KDC's certificate may be signed pkrkeydata: { iso (1) org (3) dod (6) internet (1)
directly by a CA, or there may be intermediaries if the server resides security (5) kerberosv5 (2) pkinit (3) pkrkeydata (3) }
within a large organization, or it may be unsigned if the client
indicates possession (and trust) of the KDC's certificate.
Note that the KDC's principal name has the instance equal to the 3. The signerInfos field contains a single signerInfo, which is
realm, and those fields should be appropriately set in the realm the signature of the ReplyKeyPack.
and principalName fields of the KerberosName. This is the case
even when obtaining a cross-realm ticket using PKINIT.
3.2.3. Client Extraction of Reply 4. The certificates field contains a signature verification
certificate chain, which the client may use to verify the
KDC's signature over the ReplyKeyPack.) It may only be left
empty if the client did not include a trustedCertifiers
field in the PA-PK-AS-REQ, indicating that it has the KDC's
certificate.
The client then extracts the random key used to encrypt the main 5. The outer data is of type EnvelopedData. The
reply. This random key (in encPaReply) is encrypted with either the encryptedContent for this data is the SignedData described
client's public key or with a key derived from the DH values in items 1 through 4, above.
exchanged between the client and the KDC. The client uses this
random key to decrypt the main reply, and subsequently proceeds as
described in RFC 1510bis.
3.2.4. Required Algorithms 6. The encryptedContentType for this data contains the OID
value for id-signedData: { iso (1) member-body (2) us (840)
rsadsi (113549) pkcs (1) pkcs7 (7) signedData (2) }
Not all of the algorithms in the PKINIT protocol specification have 7. The recipientInfos field is a SET which MUST contain exactly
to be implemented in order to comply with the proposed standard. one member of type KeyTransRecipientInfo. The encryptedKey
Below is a list of the required algorithms: for this member contains the temporary key which is
encrypted using the client's public key.
* Diffie-Hellman public/private key pairs 8. Neither the unprotectedAttrs field nor the originatorInfo
* utilizing Diffie-Hellman ephemeral-ephemeral mode field is required for PKINIT.
* SHA1 digest and RSA for signatures
* SHA1 digest for the Checksum in the PKAuthenticator
* using Kerberos checksum type 'sha1'
* 3-key triple DES keys derived from the Diffie-Hellman Exchange
* 3-key triple DES Temporary and Reply keys
4. Logistics and Policy 3.2.4. Validation of KDC Reply
This section describes a way to define the policy on the use of Upon receipt of the KDC's reply, the client proceeds as follows. If
PKINIT for each principal and request. the PA-PK-AS-REP contains a dhSignedData, the client obtains and
verifies the Diffie-Hellman parameters, and obtains the shared key
as described above. Otherwise, the message contains an encKeyPack,
and the client decrypts and verifies the temporary encryption key.
In either case, the client then decrypts the main reply with the
resulting key, and then proceeds as described in RFC 1510bis.
The KDC is not required to contain a database record for users 4. Security Considerations
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 certain security considerations beyond those that can
be regulated strictly in protocol definitions. We will address them
in this section.
PKINIT raises a few security considerations, which we will address PKINIT extends the cross-realm model to the public-key
in this section. infrastructure. Anyone using PKINIT must be aware of how the
certification infrastructure they are linking to works.
First of all, PKINIT extends the cross-realm model to the public Also, as in standard Kerberos, PKINIT presents the possibility of
key infrastructure. Anyone using PKINIT must be aware of how the interactions between cryptosystems of varying strengths, and this
certification infrastructure they are linking to works. now includes public-key cryptosystems. Many systems, for example,
allow the use of 512-bit public keys. Using such keys to wrap data
encrypted under strong conventional cryptosystems, such as 3DES, may
be inappropriate.
Also, as in standard Kerberos, PKINIT presents the possibility of PKINIT calls for randomly generated keys for conventional
interactions between different cryptosystems of varying strengths, cryptosystems. Many such systems contain systematically "weak"
and this now includes public-key cryptosystems. Many systems, for keys. For recommendations regarding these weak keys, see RFC
instance, allow the use of 512-bit public keys. Using such keys 1510bis.
to wrap data encrypted under strong conventional cryptosystems,
such as triple-DES, may be inappropriate.
Care should be taken in how certificates are choosen for the purposes Care should be taken in how certificates are chosen for the purposes
of authentication using PKINIT. Some local policies require that key of authentication using PKINIT. Some local policies may require
escrow be applied for certain certificate types. People deploying that key escrow be applied for certain certificate types. People
PKINIT should be aware of the implications of using certificates that deploying PKINIT should be aware of the implications of using
have escrowed keys for the purposes of authentication. certificates that have escrowed keys for the purposes of
authentication.
As described in Section 3.2, PKINIT allows for the caching of the PKINIT does not provide for a "return routability" test to prevent
Diffie-Hellman parameters on the KDC side, for performance reasons. attackers from mounting a denial-of-service attack on the KDC by
For similar reasons, the signed data in this case does not vary from causing it to perform unnecessary and expensive public-key
message to message, until the cached parameters expire. Because of operations. Strictly speaking, this is also true of standard
the persistence of these parameters, the client and the KDC are to Kerberos, although the potential cost is not as great, because
use the appropriate key derivation measures (as described in RFC standard Kerberos does not make use of public-key cryptography.
1510bis) when using cached DH parameters.
PKINIT does not provide for a "return routability test" to prevent 5. Acknowledgements
attackers from mounting a denial of service attack on the KDC by
causing it to perform needless expensive cryptographic operations.
Strictly speaking, this is also true of base Kerberos, although the
potential cost is not as great in base Kerberos, because it does
not make use of public key cryptography.
Lastly, PKINIT calls for randomly generated keys for conventional Some of the ideas on which this proposal is based arose during
cryptosystems. Many such systems contain systematically "weak" discussions over several years between members of the SAAG, the IETF
keys. For recommendations regarding these weak keys, see RFC CAT working group, and the PSRG, regarding integration of Kerberos
1510bis. 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.
6. Transport Issues 6. Expiration Date
Certificate chains can potentially grow quite large and span several This draft expires May 31, 2004.
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 7. Bibliography
[1] J. Kohl, C. Neuman. The Kerberos Network Authentication Service [1] J. Kohl, C. Neuman. The Kerberos Network Authentication Service
(V5). Request for Comments 1510. (V5). Request for Comments 1510.
[2] B.C. Neuman, Theodore Ts'o. Kerberos: An Authentication Service
for Computer Networks, IEEE Communications, 32(9):33-38. September
1994.
[3] M. Sirbu, J. Chuang. Distributed Authentication in Kerberos
Using Public Key Cryptography. Symposium On Network and Distributed
System Security, 1997.
[4] B. Cox, J.D. Tygar, M. Sirbu. NetBill Security and Transaction
Protocol. In Proceedings of the USENIX Workshop on Electronic
Commerce, July 1995.
[5] T. Dierks, C. Allen. The TLS Protocol, Version 1.0
Request for Comments 2246, January 1999.
[6] B.C. Neuman, Proxy-Based Authorization and Accounting for
Distributed Systems. In Proceedings of the 13th International
Conference on Distributed Computing Systems, May 1993.
[7] ITU-T (formerly CCITT) Information technology - Open Systems
Interconnection - The Directory: Authentication Framework
Recommendation X.509 ISO/IEC 9594-8
[8] R. Housley. Cryptographic Message Syntax.
draft-ietf-smime-cms-13.txt, April 1999, approved for publication
as RFC.
[9] PKCS #7: Cryptographic Message Syntax Standard,
An RSA Laboratories Technical Note Version 1.5
Revised November 1, 1993
[10] R. Rivest, MIT Laboratory for Computer Science and RSA Data [2] B.C. Neuman, Theodore Ts'o. Kerberos: An Authentication Service
Security, Inc. A Description of the RC2(r) Encryption Algorithm for Computer Networks, IEEE Communications, 32(9):33-38. September
March 1998. 1994.
Request for Comments 2268.
[11] M. Wahl, S. Kille, T. Howes. Lightweight Directory Access [3] M. Sirbu, J. Chuang. Distributed Authentication in Kerberos
Protocol (v3): UTF-8 String Representation of Distinguished Names. Using Public Key Cryptography. Symposium On Network and Distributed
Request for Comments 2253. System Security, 1997.
[12] R. Housley, W. Ford, W. Polk, D. Solo. Internet X.509 Public [4] B. Cox, J.D. Tygar, M. Sirbu. NetBill Security and Transaction
Key Infrastructure, Certificate and CRL Profile, January 1999. Protocol. In Proceedings of the USENIX Workshop on Electronic
Request for Comments 2459. Commerce, July 1995.
[13] B. Kaliski, J. Staddon. PKCS #1: RSA Cryptography [5] T. Dierks, C. Allen. The TLS Protocol, Version 1.0. Request
Specifications, October 1998. Request for Comments 2437. for Comments 2246, January 1999.
[14] S. Dusse, P. Hoffman, B. Ramsdell, J. Weinstein. S/MIME [6] B.C. Neuman, Proxy-Based Authorization and Accounting for
Version 2 Certificate Handling, March 1998. Request for Distributed Systems. In Proceedings of the 13th International
Comments 2312. Conference on Distributed Computing Systems, May 1993.
[15] M. Wahl, T. Howes, S. Kille. Lightweight Directory Access [7] ITU-T (formerly CCITT) Information technology - Open Systems
Protocol (v3), December 1997. Request for Comments 2251. Interconnection - The Directory: Authentication Framework
Recommendation X.509 ISO/IEC 9594-8
[16] ITU-T (formerly CCITT) Information Processing Systems - Open [8] R. Housley. Cryptographic Message Syntax.
Systems Interconnection - Specification of Abstract Syntax Notation draft-ietf-smime-cms-13.txt, April 1999, approved for publication as
One (ASN.1) Rec. X.680 ISO/IEC 8824-1 RFC.
[17] PKCS #3: Diffie-Hellman Key-Agreement Standard, An RSA [9] PKCS #7: Cryptographic Message Syntax Standard. An RSA
Laboratories Technical Note, Version 1.4, Revised November 1, 1993. Laboratories Technical Note Version 1.5. Revised November 1, 1993
8. Acknowledgements [10] R. Rivest, MIT Laboratory for Computer Science and RSA Data
Security, Inc. A Description of the RC2(r) Encryption Algorithm.
March 1998. Request for Comments 2268.
Some of the ideas on which this proposal is based arose during [11] R. Housley, W. Ford, W. Polk, D. Solo. Internet X.509 Public
discussions over several years between members of the SAAG, the IETF Key Infrastructure, Certificate and CRL Profile, January 1999.
CAT working group, and the PSRG, regarding integration of Kerberos Request for Comments 2459.
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 [12] B. Kaliski, J. Staddon. PKCS #1: RSA Cryptography
Specifications, October 1998. Request for Comments 2437.
This draft expires March 12, 2002. [13] ITU-T (formerly CCITT) Information Processing Systems - Open
Systems Interconnection - Specification of Abstract Syntax Notation
One (ASN.1) Rec. X.680 ISO/IEC 8824-1
10. Authors [14] PKCS #3: Diffie-Hellman Key-Agreement Standard, An RSA
Laboratories Technical Note, Version 1.4, Revised November 1, 1993.
Brian Tung 8. Authors
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 Brian Tung
Microsoft Corporation Clifford Neuman
One Microsoft Way USC Information Sciences Institute
Redmond WA 98052 4676 Admiralty Way Suite 1001
Phone: +1 425 707 3336 Marina del Rey CA 90292-6695
E-mail: matthur@microsoft.com Phone: +1 310 822 1511
E-mail: {brian,bcn}@isi.edu
Ari Medvinsky Matthew Hur
Liberate Technologies Ari Medvinsky
2 Circle Star Way Microsoft Corporation
San Carlos CA 94070 One Microsoft Way
E-mail: ari@liberate.com Redmond WA 98052
Phone: +1 425 707 3336
E-mail: matthur@microsoft.com, arimed@windows.microsoft.com
Sasha Medvinsky Sasha Medvinsky
Motorola, Inc. Motorola, Inc.
6450 Sequence Drive 6450 Sequence Drive
San Diego, CA 92121 San Diego, CA 92121
+1 858 404 2367 +1 858 404 2367
E-mail: smedvinsky@gi.com E-mail: smedvinsky@motorola.com
John Wray John Wray
Iris Associates, Inc. Iris Associates, Inc.
5 Technology Park Dr. 5 Technology Park Dr.
Westford, MA 01886 Westford, MA 01886
E-mail: John_Wray@iris.com E-mail: John_Wray@iris.com
Jonathan Trostle Jonathan Trostle
E-mail: jtrostle@world.std.com E-mail: jtrostle@world.std.com
 End of changes. 164 change blocks. 
925 lines changed or deleted 584 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/