WDIFF

draft-ietf-cat-kerberos-pk-init-15.txt --> draft-ietf-cat-kerberos-pk-init-18.txt

draft-ietf-cat-kerberos-pk-init-15.txt
draft-ietf-cat-kerberos-pk-init-18.txt Clifford Neuman
Updates: RFC 1510bis USC/ISI
expires May 25, 2002 August 20, 2004 Matthew Hur
Cisco
Ari Medvinsky
Keen.com, Inc.
Microsoft Corporation
Sasha Medvinsky
Motorola
Motorola, Inc.
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 provision 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).
http://www.ietf.org/shadow.html

The distribution of this memo is unlimited. It is filed as
draft-ietf-cat-kerberos-pk-init-15.txt,
draft-ietf-cat-kerberos-pk-init-18.txt and expires May 25, 2002. August 20, 2004.
Please send comments to the authors.

1. Abstract

This document defines draft describes protocol extensions (PKINIT) (hereafter called PKINIT)
to the Kerberos protocol specification (RFC 1510bis [1]) to [1]). These
extensions provide a method for using integrating public key cryptography during initial authentication. The methods
defined specify
into the ways initial authentication exchange, by passing cryptographic
certificates and associated authenticators in which preauthentication data fields and
error data fields in Kerberos messages are to be used to transport
public key data.
fields.

2. Introduction

The popularity of public key cryptography has produced

A client typically authenticates itself to a desire for
its support service in Kerberos [2]. The advantages provided by public key
cryptography include simplified key management (from
using three distinct though related exchanges. First, the client
requests a ticket-granting ticket (TGT) from the Kerberos
perspective) and
authentication server (AS). Then, it uses the ability TGT to leverage existing request a
service ticket from the Kerberos ticket-granting server (TGS).
Usually, the AS and developing
public key certification infrastructures.

Public key cryptography can be TGS are integrated into Kerberos in a number
of ways. One is single device known as
a Kerberos Key Distribution Center, or KDC. (In this draft, we will
refer to both the AS and the TGS as the KDC.) Finally, the client
uses the service ticket to associate authenticate itself to the service.

The advantage afforded by the TGT is that the user need only
explicitly request a ticket and expose his credentials once. The
TGT and its associated session key pair with each realm, which can then be used to facilitate cross-realm authentication; for any
subsequent requests. One implication of this is the
topic of another draft proposal. Another way that all further
authentication is independent of the method by which the initial
authentication was performed. Consequently, initial authentication
provides a convenient place to allow users with
public key certificates to integrate public-key cryptography
into Kerberos authentication.

As defined, Kerberos authentication exchanges use them symmetric-key
cryptography, in initial authentication. This part for performance. (Symmetric-key cryptography
is typically 10-100 times faster than public-key cryptography,
depending on the concern public-key operations. [cite]) One cost of using
symmetric-key cryptography is that the current document.

PKINIT utilizes ephemeral-ephemeral Diffie-Hellman keys in
combination with DSA keys as the primary, required mechanism. Note must be shared, so that PKINIT supports
before a user can authentication himself, he must already be
registered with the KDC.

Conversely, public-key cryptography--in conjunction with an
established certification infrastructure--permits authentication
without prior registration. Adding it to Kerberos allows the
widespread use of separate signature Kerberized applications by users without requiring
them to register first--a requirement that has no inherent security
benefit.

As noted above, a convenient and encryption
keys.

PKINIT enables access efficient place to Kerberos-secured services based on introduce
public-key cryptography into Kerberos is in the initial
authentication utilizing public key cryptography. PKINIT utilizes
standard public key signature exchange. This document describes the methods and encryption
data formats within the
standard for integrating public-key cryptography into Kerberos messages. The basic mechanism is as follows: The
user sends an AS-REQ message
initial authentication. Another document (PKCROSS) describes a
similar protocol for Kerberos cross-realm authentication.

3. Extensions

This section describes extensions to RFC 1510bis for supporting the KDC as before, except that if that
user is to
use public key of 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 for a ticket
granting ticket
(TGT) as before, except that (TGT).

Briefly, the encPart from following changes to RFC 1510bis are proposed:

1. If public-key authentication is indicated, the AS-REP message
carrying client sends
the TGT is now encrypted utilizing either user's public-key data and an authenticator in a Diffie-Hellman
derived key or
preauthentication field accompanying the user's public key. usual request.
This message authenticator is authenticated
utilizing signed by the public key user's private
signature of key.

2. The KDC verifies the KDC.

Note that PKINIT does not require client's request against its own
policy and certification authorities.

3. If the use of certificates. A KDC
may store request passes the public key of a principal as part of that principal's
record. In this scenario, verification tests, the KDC
replies as usual, but the reply is encrypted using either:

a. a randomly generated key, signed using the trusted party that vouches
for KDC's
signature key and encrypted using the principal (as in user's encryption
key; or

b. 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 key generated through a building block for
other specifications. PKINIT may be utilized to establish
inter-realm keys for Diffie-Hellman exchange with
the purposes of issuing cross-realm service
tickets. It may also be used to issue anonymous Kerberos tickets client, signed 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, KDC's signature key.

Any key data required by 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, obtain 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 encryption
key data is transported returned in a preauthentication
data fields to help establish identity. field accompanying
the usual reply.

4. The user presents
a public key certificate and client obtains an ordinary TGT that may
be used for subsequent authentication, with such
authentication using only conventional cryptography. the encryption key, decrypts the reply,
and then proceeds as usual.

Section 3.1 provides definitions to help specify of this document defines the necessary message formats.
Section 3.2 describes the extensions their syntax and use in greater detail.
Implementation of all specified formats and uses in these sections
is REQUIRED for the initial authentication
method. compliance with PKINIT.

3.1. Definitions

The extensions involve new preauthentication fields; we introduce

3.1.1. Required Algorithms

At minimum, PKINIT must be able to use the following algorithms:

Reply key (or DH-derived key): AES256-CTS-HMAC-SHA1-96 etype
(as required by clarifications).
Signature algorithm: SHA-1 digest and RSA.
Reply key delivery method: ephemeral-ephemeral Diffie-Hellman
with a non-zero nonce.
Unkeyed checksum type for the paChecksum member of
PKAuthenticator: SHA1 (unkeyed).

3.1.2. Defined Message and Encryption Types

PKINIT makes use of the following new preauthentication types:

PA-PK-AS-REQ 14 TBD
PA-PK-AS-REP 15

The extensions TBD
PA-PK-OCSP-REQ TBD
PA-PK-OCSP-REP TBD

PKINIT also involve makes use of the following new error types; we introduce authorization data type:

AD-INITIAL-VERIFIED-CAS TBD

PKINIT introduces the following new error 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

PKINIT uses the following typed data types for errors:

TD-PKINIT-CMS-CERTIFICATES 101
TD-KRB-PRINCIPAL

TD-DH-PARAMETERS 102
TD-KRB-REALM 103
TD-TRUSTED-CERTIFIERS 104
TD-CERTIFICATE-INDEX 105

We utilize

PKINIT defines the following encryption types (which map directly to
OIDs): types, for use in the AS-REQ
message (to indicate acceptance of the corresponding encryption OIDs
in PKINIT):

dsaWithSHA1-CmsOID 9
md5WithRSAEncryption-CmsOID 10
sha1WithRSAEncryption-CmsOID 11
rc2CBC-EnvOID 12
rsaEncryption-EnvOID (PKCS#1 (PKCS1 v1.5) 13
rsaES-OAEP-ENV-OID (PKCS#1 (PKCS1 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).

The above encryption types are utilized used (in PKINIT) only within CMS [8]
structures within the PKINIT preauthentication fields. Their use
within
the Kerberos EncryptedData structure structures is unspecified.

In many cases,

3.1.3. Algorithm Identifiers

PKINIT requires the encoding of the X.500 name of a
certificate authority as a Realm. When such a name appears as
a realm it will be represented using the "Other" form of the realm
name as specified in the naming constraints section of RFC 1510bis.
For a realm derived from an X.500 name, NAMETYPE will have the value
X500-RFC2253. The full realm name will appear as follows:

where nametype is "X500-RFC2253" and string is the result of doing
an RFC2253 encoding of the distinguished name, i.e.

"X500-RFC2253:" + RFC2253Encode(DistinguishedName)

where DistinguishedName is an X.500 name, and RFC2253Encode is a
function returing a readable UTF encoding of an X.500 name, as
defined by RFC 2253 [11] (part of LDAPv3 [15]).

Each component of a DistinguishedName is called a
RelativeDistinguishedName, where a RelativeDistinguishedName is a
SET OF AttributeTypeAndValue. RFC 2253 does not specify the order
in which to encode define, but does make use of, the elements of following
algorithm identifiers.

PKINIT uses the RelativeDistinguishedName and
so to ensure that this encoding is unique, we add following algorithm identifier for Diffie-Hellman
key agreement [11]:

dhpublicnumber

PKINIT uses the following rule
to those specified by RFC 2253:

When converting a multi-valued RelativeDistinguishedName
to a string, the output consists of the string encodings
of each AttributeTypeAndValue, in the same order as
specified by the DER encoding.

Similarly, in cases where the KDC does not provide a specific
policy-based mapping from the X.500 name or X.509 Version 3
SubjectAltName extension in the user's certificate to a Kerberos
principal name, PKINIT requires the direct encoding of the X.500
name as a PrincipalName. In this case, the name-type of the
principal name MUST be set to KRB_NT-X500-PRINCIPAL. This new
name type is defined in RFC 1510bis as:

KRB_NT_X500_PRINCIPAL 6

For this type, the name-string MUST be set as follows:

RFC2253Encode(DistinguishedName)

as described above. When this name type is used, the principal's
realm MUST be set to the certificate authority's distinguished
name using the X500-RFC2253 realm name format described earlier in
this section.

Note that the same string may be represented using several different
ASN.1 data types. As the result, the reverse conversion from an
RFC2253-encoded principal name back to an X.500 name may not be
unique and may result in an X.500 name that is not the same as the
original X.500 name found in the client certificate.

RFC 1510bis describes an alternate encoding of an X.500 name into a
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:

PrincipalName ::= SEQUENCE {
name-type[0] INTEGER,
name-string[1] SEQUENCE OF GeneralString
}

The following rules relate to the the matching of PrincipalNames
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
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
depends on the type of the realm:

a. If the realm contains a colon (':') before any equal
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
the format of DNS names, it is considered a realm name of
type Domain. The constraint may be given as a realm
name 'FOO.BAR', which matches any PrincipalName within
the realm 'FOO.BAR' but not those in subrealms such as
'CAR.FOO.BAR'. A constraint of the form '.FOO.BAR'
matches PrincipalNames in subrealms of the form
'CAR.FOO.BAR' but not the realm 'FOO.BAR' itself.

c. Otherwise, the realm name is invalid and does not match
under any conditions.

3.1.1. Encryption and Key Formats

In the exposition below, we use the terms public key and private
key generically. It should be understood that the term "public
key" may be used to refer to either a public encryption key or a
signature verification key, and that the term "private key" may be
used to refer to either a private decryption key or a signature
generation key. The fact that these are logically distinct does
not preclude the assignment of bitwise identical keys for RSA
keys.

In the case of Diffie-Hellman, the key is produced from the agreed
bit string as follows:

* Truncate the bit string to the required length.
* Apply the specific cryptosystem's random-to-key function.

Appropriate key constraints for each valid cryptosystem are given
in RFC 1510bis.

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 [8] and
in [12] are 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 [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)
id-RSAES-OAEP (RSA encryption, PKCS#1 v2.0)

Both of the above RSA encryption schemes are specified in [13].
Currently, only PKCS#1 v1.5 is specified by CMS [8], 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 [8].

3.2. Public Key Authentication

Implementation of the changes in this section is REQUIRED for
compliance with PKINIT.

3.2.1. Client Request

Public keys may be signed by some certification authority (CA), or
they may be maintained by the KDC in which case the KDC is the
trusted authority. Note that the latter mode does not require the
use of certificates.

The initial authentication request is sent as per RFC 1510bis, 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] ContentInfo,
-- Defined in CMS [8];
-- SignedData OID is {pkcs7 2}
-- AuthPack (below) defines the
-- data that is signed.
trustedCertifiers [1] SEQUENCE OF TrustedCas OPTIONAL,
-- This is a list of CAs that the
-- client trusts and that certify
-- KDCs.
kdcCert [2] IssuerAndSerialNumber OPTIONAL
-- As defined in CMS [8];
-- specifies a particular KDC
-- certificate if the client
-- already has it.
encryptionCert [3] IssuerAndSerialNumber OPTIONAL
-- For example, this may be the
-- client's Diffie-Hellman
-- certificate, or it may be the
-- client's RSA encryption
-- certificate.
}

TrustedCas ::= CHOICE {
principalName [0] KerberosName,
-- as defined below
caName [1] Name
-- fully qualified X.500 name
-- as defined by X.509
issuerAndSerial [2] IssuerAndSerialNumber
-- Since a CA may have a number of
-- certificates, only one of which
-- a client trusts
}

The type of the ContentInfo in the signedAuthPack is SignedData.
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 algorithm identifiers [8, 12]:

sha-1WithRSAEncryption (RSA with SHA1)
md5WithRSAEncryption (RSA with MD5)
id-dsa-with-sha1 (DSA with SHA1)

PKINIT 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 following encryption algorithm identifiers [12] for
encrypting 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 temporary key is being used, the public exponent is provided
in the subjectPublicKey field of the SubjectPublicKeyInfo and
the DH parameters are supplied as a DHParameter 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 and the e_data will contain a
DHParameter with appropriate 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 public key:

rsaEncryption (PKCS1 v1.5)
id-RSAES-OAEP (PKCS1 v2.0)

These OIDs are used, not to be confused with the client and encryption types listed
above.

PKINIT uses the KDC MUST perform following algorithm identifiers [8] for encrypting
the reply key derivation (for with the appropriate cryptosystem) on temporary key:

des-ede3-cbc (three-key 3DES, CBC mode)
rc2-cbc (RC2, CBC mode)

Again, these OIDs are not to be confused with the
resulting encryption key, types
listed above.

3.2. PKINIT Preauthentication Syntax and Use

In this section, we describe the syntax and use of the various
preauthentication fields employed to implement PKINIT.

3.2.1. Client Request

The initial authentication request (AS-REQ) is sent as specified in per RFC 1510bis. (With
1510bis, except that a zero nonce, message binding is performed using preauthentication field containing data
signed by the nonce
in user's private signature key accompanies the main request, which must be encrypted using the
encapsulated reply key.)

AuthPack
as follows:

PA-PK-AS-REQ ::= SEQUENCE {
pkAuthenticator
-- PAType TBD
signedAuthPack [0] PKAuthenticator,
clientPublicValue [1] SubjectPublicKeyInfo OPTIONAL ContentInfo,
-- if client Defined in CMS.
-- Type is using Diffie-Hellman SignedData.
-- (ephemeral-ephemeral only)
}

PKAuthenticator ::= SEQUENCE {
cusec [0] INTEGER, Content is AuthPack
-- for replay prevention as in RFC 1510bis
ctime (defined below).
trustedCertifiers [1] KerberosTime, SEQUENCE OF TrustedCAs OPTIONAL,
-- for replay prevention as in RFC 1510bis
nonce A list of CAs, trusted by
-- the client, used to certify
-- KDCs.
kdcCert [2] INTEGER, IssuerAndSerialNumber OPTIONAL,
-- zero only Defined in CMS.
-- Identifies a particular KDC
-- certificate, if the client will accept
-- cached DH parameters from KDC;
-- must be non-zero otherwise
pachecksum already has it.
encryptionCert [3] Checksum IssuerAndSerialNumber OPTIONAL,
-- Checksum over KDC-REQ-BODY May identify the user's
-- Defined by Kerberos spec; Diffie-Hellman certificate,
-- must be unkeyed, e.g. sha1 or rsa-md5 an RSA encryption key
-- certificate.
...
}

SubjectPublicKeyInfo

TrustedCAs ::= SEQUENCE CHOICE {
algorithm AlgorithmIdentifier,
-- dhKeyAgreement
subjectPublicKey BIT STRING
caName [0] Name,
-- for DH, equals Fully qualified X.500 name
-- public exponent (INTEGER encoded as defined in X.509 [11].
issuerAndSerial [1] IssuerAndSerialNumber,
-- as payload of BIT STRING)
} Identifies a specific CA
-- as specified by certificate, if the X.509 recommendation [7]

AlgorithmIdentifier client
-- only trusts one.
...
}

AuthPack ::= SEQUENCE {
algorithm OBJECT IDENTIFIER,
-- for dhKeyAgreement, this is
pkAuthenticator [0] PKAuthenticator,
clientPublicValue [1] SubjectPublicKeyInfo OPTIONAL
-- { iso (1) member-body (2) US (840) Defined in X.509,
-- rsadsi (113459) pkcs (1) 3 1 } reproduced below.
-- from PKCS #3 [17]
parameters ANY DEFINED by algorithm OPTIONAL Present only if the client
-- for dhKeyAgreement, this is using ephemeral-ephemeral
-- DHParameter Diffie-Hellman.
} -- as specified by the X.509 recommendation [7]

DHParameter

PKAuthenticator ::= SEQUENCE {
prime
cusec [0] INTEGER,
ctime [1] KerberosTime,
-- p
base INTEGER, cusec and ctime are used as
-- g
privateValueLength INTEGER OPTIONAL in RFC 1510bis, for replay
-- l
} prevention.
nonce [2] INTEGER,
-- as defined in PKCS #3 [17]

If the client passes an issuer and serial number in the Binds reply to request,
the KDC
-- except 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 zero when 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
-- will accept cached
-- Diffie-Hellman parameters
-- from KDC certificate(s) that a
client may utilize. This data is specified in the e-data, which
is defined and MUST NOT be
-- zero otherwise.
-- MUST be < 2^32.
paChecksum [3] Checksum,
-- Defined in RFC 1510bis revisions as a SEQUENCE of TypedData:

TypedData ::= SEQUENCE {
data-type [0] INTEGER,
data-value [1] OCTET STRING, [15].
-- Performed over KDC-REQ-BODY,
-- must be unkeyed.
...
}

IMPORTS
-- per Kerberos RFC 1510bis

where:
data-type = TD-PKINIT-CMS-CERTIFICATES = 101
data-value = CertificateSet // as specified by CMS [8] from X.509
SubjectPublicKeyInfo, AlgorithmIdentifier, DomainParameters,
ValidationParms
FROM PKIX1Explicit88 { iso (1) identified-organization (3)
dod (6) internet (1) security (5) mechanisms (5)
pkix (7) id-mod (0) id-pkix1-explicit-88 (1) }

The PKAuthenticator carries information to foil replay attacks, to
bind ContentInfo in the pre-authentication signedAuthPack is filled out as follows:

1. The eContent field contains data to of type AuthPack. It MUST
contain the KDC-REQ-BODY, pkAuthenticator, and to bind MAY also contain the
request and response.
user's Diffie-Hellman public value (clientPublicValue).

2. The PKAuthenticator is signed with 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)}

3. The signerInfos field MUST contain the client's signature key.

3.2.2. KDC Response

Upon receipt of the AS_REQ with PA-PK-AS-REQ pre-authentication
type,
AuthPack.

4. The certificates field MUST contain at least a signature
verification certificate chain that the KDC attempts can use to
verify the user's signature on the AuthPack. Additionally, the
client may also insert an encryption certificate chain
(userCert), chain, if one
(for example) the client is provided not using ephemeral-ephemeral
Diffie-Hellman.

5. If a Diffie-Hellman key is being used, the parameters SHOULD
be chosen from the First or Second defined Oakley Groups.
(See RFC 2409 [c].)

6. The KDC may wish to use cached Diffie-Hellman parameters.
To indicate acceptance of caching, the client sends zero in
the request. This nonce field of the pkAuthenticator. Zero is done by
verifying not a valid
value for this field under any other circumstances. Since
zero is used to indicate acceptance of cached parameters,
message binding in this case is performed instead using the certification path against
nonce in the KDC's policy main request.

3.2.2. Validation of
legitimate certifiers.

If Client Request

Upon receiving the client's certificate chain contains no certificate signed by
a CA trusted by request, the KDC, then KDC validates it. This
section describes the steps that the KDC MUST (unless otherwise
noted) take in validating the request.

The KDC must look for a user certificate in the signedAuthPack.
If it cannot find one signed by a CA it trusts, it sends back an
error message of type KDC_ERR_CANT_VERIFY_CERTIFICATE. The accompanying
e-data for this error is a SEQUENCE of one OF TypedData:

TypedData (with type TD-TRUSTED-CERTIFIERS=104)
whose ::= SEQUENCE {
-- As defined in RFC 1510bis.
data-type [0] INTEGER,
data-value [1] OCTET STRING
}

For this error, the data-type is TD-TRUSTED-CERTIFIERS, and the
data-value is an OCTET STRING which is containing the DER encoding of

TrustedCertifiers ::= SEQUENCE OF PrincipalName
-- X.500 name encoded as a principal name
-- see Section 3.1

If Name

If, while verifying a the certificate chain chain, the KDC determines that
the signature on one of the certificates in the CertificateSet from
the signedAuthPack fails verification, then the KDC is
invalid, it returns an error of type KDC_ERR_INVALID_CERTIFICATE.
The accompanying e-data for this error is a SEQUENCE of one TypedData (with type
TD-CERTIFICATE-INDEX=105) OF TypedData,
whose data-type is TD-CERTIFICATE-INDEX, and whose data-value is an
OCTET STRING
which is containing the DER encoding of the index into the
CertificateSet field, ordered as sent by the client. client:

CertificateIndex ::= INTEGER
-- 0 = 1st certificate,
-- first certificate (in
-- order of encoding) encoding),
-- 1 = 2nd second certificate, etc etc.

If more than one signature is invalid, the KDC sends one TypedData
per invalid signature.

The KDC may MAY also check whether any of the certificates in the
client's user's
chain has have been revoked. If one any of the certificates has them have been revoked, then the KDC
returns an error of type KDC_ERR_REVOKED_CERTIFICATE; if such a query reveals that the certificate's KDC
attempts to determine the revocation status but is unknown or not
available, then if required by policy, the KDC returns the
appropriate unable to do so,
it SHOULD return an error of type KDC_ERR_REVOCATION_STATUS_UNKNOWN KDC_ERR_REVOCATION_STATUS_UNKNOWN.
The certificate or
KDC_ERR_REVOCATION_STATUS_UNAVAILABLE. In any of these three
cases, the certificates affected certificate is are identified by the accompanying
e-data, which contains a CertificateIndex exactly as described
for
KDC_ERR_INVALID_CERTIFICATE. an error of type KDC_ERR_INVALID_CERTIFICATE (see above).

If the certificate chain can be verified, is successfully validated, but the name of the
client in the user's
certificate does is not match authorized to the client's principal name in the
request, then
AS-REQ (when present), the KDC returns MUST return an error of type
KDC_ERR_CLIENT_NAME_MISMATCH. There is no accompanying e-data
field in for
this case. error.

Even if all succeeds, the chain is validated, and the names in the certificate and
the request match, the KDC may--for policy reasons--decide may decide not to trust the client. For
example, the certificate may include (or not include) an Enhanced
Key Usage (EKU) OID in the extensions field. As a matter of local
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 message of type KDC_ERR_CLIENT_NOT_TRUSTED. One specific case of this is
the presence or absence of an Enhanced Key Usage (EKU) OID within
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, implementors, we define a PKINIT EKU OID as the following: follows:
{ iso (1) org (3) dod (6) internet (1) security (5) kerberosv5 (2)
pkinit (3) pkekuoid (2). (4) }.

If a trust relationship exists, the KDC then verifies certificate chain and usage check out, but the client's
signature on AuthPack. If that fails, the signedAuthPack fails to verify, the KDC returns an
error
message of type KDC_ERR_INVALID_SIG. Otherwise, the There is no accompanying e-data
for this error.

The KDC uses must check the timestamp (ctime and cusec) in the PKAuthenticator to assure ensure that the request is not
a replay. The KDC also verifies replay, and that its name
is specified in the PKAuthenticator. time skew falls within acceptable limits.
The recommendations for ordinary (that is, non-PKINIT) skew times
apply here. If the check fails, the KDC returns an error of type
KRB_AP_ERR_REPEAT or KRB_AP_ERR_SKEW, respectively.

Finally, if the clientPublicValue field is filled in, indicating that the
client wishes to use Diffie-Hellman key agreement, then ephemeral-ephemeral Diffie-Hellman, the KDC
checks to see that if 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 not,
it returns an error message of type
KDC_ERR_KEY_TOO_WEAK, with an KDC_ERR_KEY_TOO_WEAK. The accompanying
e-data containing is a structure of
type DHParameter with appropriate DH 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 SEQUENCE OF TypedData, whose data-type is
within the allowable window and that the principal name and realm
are correct. If the local (server) time
TD-DH-PARAMETERS, and the client time in the
authenticator differ by more than the allowable clock skew, then the
KDC returns an error message of type KRB_AP_ERR_SKEW as defined in
RFC 1510bis.

Assuming no errors, the KDC replies as per RFC 1510bis, except as
follows. The user's name in the ticket whose data-value is determined by the
following decision algorithm:

1. If an OCTET STRING containing
the KDC has DER encoding of a mapping from the name in the certificate DomainParameters (see above), including
appropriate Diffie-Hellman parameters with which to a Kerberos name, then use that name.
Else
2. If retry the certificate contains
request.

In order to establish authenticity of the SubjectAltName extention
and reply, the local KDC policy defines a mapping from will sign
some key data (either the
SubjectAltName random key used to a Kerberos name, then use that name.
Else
3. Use encrypt the name as represented reply 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 a KDCDHKeyInfo, or the
certifier that issued Diffie-Hellman parameters used to
generate the user's certificate.

Note that a principal name may be carried reply-encrypting key in the subjectAltName
field case of a certificate. This name may ReplyKeyPack).
The signature certificate to be mapped used is to be selected as follows:

1. If the client included a principal
record kdcCert field in a security database based on local policy, for example the subjectAltName may be kerberos/principal@realm format. In
this case PA-PK-AS-REQ,
use the realm name is not that referred-to certificate, if the KDC has it. If it
does not, the KDC returns an error of type
KDC_ERR_CERTIFICATE_MISMATCH.

2. Otherwise, if the CA client did not include a kdcCert field,
but did include a trustedCertifiers field, and the KDC
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.

3. Otherwise, if the
local realm doing client included neither a kdcCert field
nor a trustedCertifiers field, and the mapping (or some realm name chosen by KDC has only one
signature certificate, use that
realm). certificate. If a non-KDC X.509 certificate contains it has
more than one certificate, it returns an error of type
KDC_ERR_CERTIFICATE_MISMATCH.

3.2.3. KDC Reply

Assuming that the principal name within client's request has been properly validated, the subjectAltName version 3 extension, that
KDC proceeds as per RFC 1510bis, except as follows.

The user's name may utilize
KerberosName as defined below, or, represented in the case of an S/MIME AS-REP must be derived from
the certificate [14], may utilize provided in the email address. client's request. If the KDC
is presented with an S/MIME certificate, then the email address
within subjectAltName will be interpreted as a principal and realm
separated by has
its own mapping from the "@" sign, or as a name that needs to be mapped
according to local policy. If in the resulting name does not correspond certificate to a registered principal Kerberos name, then
it uses that Kerberos name.

Otherwise, if the principal name is formed as
defined in section 3.1.

The trustedCertifiers field certificate contains a list of certification
authorities trusted by the client, SubjectAltName extension
with a KerberosName in the case otherName field, it uses that name.

AnotherName ::= SEQUENCE {
-- Defined in [11].
type-id OBJECT IDENTIFIER,
value [0] EXPLICIT ANY DEFINED BY type-id
}

KerberosName ::= SEQUENCE {
realm [0] Realm,
principalName [1] PrincipalName
}

with OID

krb5 OBJECT IDENTIFIER ::= { iso (1) org (3) dod (6) internet (1)
security (5) kerberosv5 (2) }

krb5PrincipalName OBJECT IDENTIFIER ::= { krb5 2 }

In this case, the client does
not possess realm in the KDC's public key certificate. If ticket is that of the KDC has no
certificate signed local realm (or
some other realm name chosen by any of that realm). Otherwise, the trustedCertifiers, then it KDC
returns an error of type KDC_ERR_KDC_NOT_TRUSTED.

KDCs should try to (in order of preference):
1. Use KDC_ERR_CLIENT_NAME_MISMATCH.

In addition, the KDC certificate identified by MUST set the serialNumber included initial flag in the issued TGT
*and* add an authorization data of type AD-INITIAL-VERIFIED-CAS to
the TGT. The value is an OCTET STRING containing the DER encoding
of InitialVerifiedCAs:

InitialVerifiedCAs ::= SEQUENCE OF SEQUENCE {
ca [0] Name,
ocspValidated [1] BOOLEAN,
...
}

The KDC MAY wrap any AD-INITIAL-VERIFIED-CAS data in AD-IF-RELEVANT
containers if the list of CAs satisfies the client's request.
2. Use a certificate issued KDC's realm's policy.
(This corresponds to the KDC by one TRANSITED-POLICY-CHECKED ticket flag.)
Furthermore, any TGS must copy such authorization data from tickets
used in a PA-TGS-REQ of the client's
trustedCertifier(s);
If TGS-REQ to the KDC resulting ticket,
including the AD-IF-RELEVANT container, if present.

AP servers that understand this authorization data type SHOULD apply
local policy to determine whether a given ticket bearing such a type
(not contained within an AD-IF-RELEVANT container) is unable acceptable.
(This corresponds to comply with any of these options, then the
KDC returns an error message of AP server checking the transited field when
the TRANSITED-POLICY-CHECKED flag has not been set.) If such a data
type KDC_ERR_KDC_NOT_TRUSTED *is* contained within an AD-IF-RELEVANT container, AP servers
still MAY apply local policy to determine whether the
client. authorization
data is acceptable.

The AS-REP is otherwise unchanged from RFC 1510bis. The KDC then
encrypts the reply as usual, but not with the user's long-term key, but key.
Instead, it encrypts it with the Diffie Hellman derived key or either a random encryption key, or a
key generated
for this particular response which derived from a Diffie-Hellman exchange. Which is carried in the padata field case is
indicated by the contents of the TGS-REP message. PA-PK-AS-REP (note tags):

PA-PK-AS-REP ::= CHOICE {
-- PA TYPE 15 PAType YY (TBD)
dhSignedData [0] ContentInfo,
-- Defined in CMS [8] and used only with
-- Diffie-Hellman key exchange (if the
-- client public value was present in the
-- request).
-- SignedData OID Type is {pkcs7 2} SignedData.
-- This choice MUST be supported Content is KDCDHKeyInfo
-- by compliant implementations. (defined below).
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 ContentInfo,
-- included.
}

The type of the ContentInfo in the dhSignedData is SignedData.
Its usage is as follows:

When 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 Type is derived from the Diffie-Hellman exchange:

1. Both the KDC and the client calculate a secret value
(g^ab mod p), where a EnvelopedData.
-- Content is the client's private exponent and
b ReplyKeyPack
-- (defined below).
...
}

Note that PA-PK-AS-REP is the KDC's private exponent.

2. Both the KDC and the client take the first N bits a CHOICE: either a dhSignedData, or an
encKeyPack, but not both. The former contains data of this
secret value type
KDCDHKeyInfo, and convert it into a reply key. N depends on
the reply key type.

a. For example, if is used only when the reply key is DES, N=64 bits, where
some encrypted using a
Diffie-Hellman derived key:

KDCDHKeyInfo ::= SEQUENCE {
subjectPublicKey [0] BIT STRING,
-- Equals public exponent
-- (g^a mod p).
-- INTEGER encoded as payload
-- of the bits are replaced with parity bits, according BIT STRING.
nonce [1] INTEGER,
-- Binds reply to FIPS PUB 74.

b. As another example, if request.
-- Exception: A value of zero
-- indicates that the reply key KDC is (3-key) 3-DES,
N=192 bits, where some
-- using cached values.
dhKeyExpiration [2] KerberosTime OPTIONAL,
-- Expiration time for KDC's
-- cached values.
...
}

The fields of the bits ContentInfo for dhSignedData are replaced with
parity bits, according to FIPS PUB 74.

3. be filled in
as follows:

1. The encapContentInfo eContent field MUST contain the KdcDHKeyInfo as
defined below.

a. contains data of type KDCDHKeyInfo.

2. The eContentType field MUST contain contains the OID value for
pkdhkeydata: { iso (1) org (3) dod (6) internet (1)
security (5) kerberosv5 (2) pkinit (3) pkdhkeydata (2)

b. }

3. The eContent signerInfos field contains a single signerInfo, which is data
the signature of the type KdcDHKeyInfo
(below). KDCDHKeyInfo.

4. The certificates field MUST contain the certificates
necessary for contains a signature verification
certificate chain that the client may use to establish trust in verify the
KDC's
certificate based on the list of trusted certifiers sent by
the client in signature over the PA-PK-AS-REQ. This field KDCDHKeyInfo.) It may only be left
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).

5. The signerInfos field is include a SET trustedCertifiers
field in the PA-PK-AS-REQ, indicating that MUST contain at least
one member, since it contains has the actual signature.

6. KDC's
certificate.

5. If the client indicated acceptance of cached Diffie-Hellman
parameters from the KDC, and the KDC supports such an option
(for performance reasons), agree to use cached parameters, the
KDC should SHOULD return a zero in the nonce field and include the
expiration time of the
parameters 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 nonce,
thus indicating non-acceptance of the cached Diffie-Hellman parameters). As
indicated above in Section 3.2.1, Client Request, when parameters.

The key is derived as follows: Both the KDC uses cached parameters, and the client calculate
the value g^(ab) mod p, where a and b are the client's and KDC's
private exponents, respectively. They both take the first k bits of
this secret value as a key generation seed, where the parameter k
(the size of the seed) is dependent on the selected key type, as
specified in the Kerberos crypto draft [15]. The seed is then
converted into a protocol key by applying to it a random-to-key
function, which is also dependent on key type.

The protocol key is used to derive the integrity key Ki and the
encryption key Ke according to [15]. Ke and Ki are used to generate
the encrypted part of the AS-REP.

1. For example, if the encryption type is DES with MD4, k = 64
bits and the random-to-key function consists of replacing
some of the bits with parity bits, according to FIPS PUB 74
[cite]. In this case, the KDC MUST
perform key derivation (for function for Ke is
the identity function, and Ki is not needed because the
checksum in the EncryptedData is not keyed.

2. If the encryption type is three-key 3DES with HMAC-SHA1,
k = 168 bits and the random-to-key function is
DES3random-to-key as defined in [15]. This function inserts
parity bits to create a 192-bit 3DES protocol key that is
compliant with FIPS PUB 74 [cite]. Ke and Ki are derived
from this protocol key according to [15] with the key usage
number set to 3 (AS-REP encrypted part).

If the KDC and client are not using Diffie-Hellman, the appropriate cryptosystem)
on KDC encrypts
the resulting reply with an encryption key, as specified packed in RFC 1510bis.

KdcDHKeyInfo the encKeyPack, which
contains data of type ReplyKeyPack:

ReplyKeyPack ::= SEQUENCE {
-- used only when utilizing Diffie-Hellman
subjectPublicKey
replyKey [0] BIT STRING, EncryptionKey,
-- Equals public exponent (g^a mod p) Defined in RFC 1510bis.
-- INTEGER encoded Used to encrypt main reply.
-- MUST be at least as payload of large
-- BIT STRING as session key.
nonce [1] INTEGER,
-- Binds response to the request
-- Exception: Set reply to zero when KDC
-- is using a cached DH value
dhKeyExpiration [2] KerberosTime OPTIONAL
-- Expiration time for KDC's cached request.
-- DH value MUST be < 2^32.
...
}

The type fields of the ContentInfo in the for encKeyPack is EnvelopedData. Its
usage is MUST be filled in as
follows:

The EnvelopedData data type is specified in the Cryptographic
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
PKINIT.

3. The recipientInfos field innermost data is a SET which MUST contain exactly
one member of the KeyTransRecipientInfo type for encryption
with a public key.

a. The encryptedKey field (in KeyTransRecipientInfo)
contains the temporary key which is encrypted with the
PKINIT client's public key.

4. The encryptedContentInfo field contains the signed and
encrypted reply key.

a. SignedData. The contentType field MUST contain the OID value eContent for
id-signedData: iso (1) member-body (2) us (840)
rsadsi (113549) pkcs (1) pkcs7 (7) signedData (2)

b. The encryptedContent field is encrypted
this data is of the CMS
type signedData as specified below.

i. The encapContentInfo field MUST contains the type ReplyKeyPack.

2. The eContentType field MUST contain for this data contains the OID value for
pkrkeydata: { iso (1) org (3) dod (6) internet (1)
security (5) kerberosv5 (2) pkinit (3) pkrkeydata (3)

* }

3. The eContent signerInfos field contains a single signerInfo, which is data
the signature of the type ReplyKeyPack
(below).

ii. ReplyKeyPack.

4. The certificates field MUST contain the certificates
necessary for contains a signature verification
certificate chain, which the client may use to establish trust in verify the
KDC's certificate based on the list of trusted
certifiers sent by the client in signature over the PA-PK-AS-REQ.
This field ReplyKeyPack.) It may only be left
empty if the client did not send
to the KDC include a list of trusted certifiers (the trustedCertifiers
field was empty, meaning that in the
client already possesses PA-PK-AS-REQ, indicating that it has the KDC's certificate).

iii.
certificate.

5. The signerInfos outer data is of type EnvelopedData. The
encryptedContent for this data is the SignedData described
in items 1 through 4, above.

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) }

7. The recipientInfos field is a SET that which MUST contain at
least exactly
one member, since it member of type KeyTransRecipientInfo. The encryptedKey
for this member contains the actual
signature.

ReplyKeyPack ::= SEQUENCE {
-- not used for Diffie-Hellman
replyKey [0] EncryptionKey,
-- from RFC 1510bis
-- used to encrypt main reply
-- ENCTYPE is at least as strong as
-- ENCTYPE of session temporary key
nonce [1] INTEGER,
-- binds response to the request
-- must be same as the nonce
-- passed in the PKAuthenticator
}

3.2.2.1. Use of transited Field

Since each certifier in the certification path of a user's
certificate which is equivalent to a separate Kerberos realm, the name
of each certifier in
encrypted using the certificate chain MUST be added to client's public key.

8. Neither the
transited unprotectedAttrs field of nor the ticket. The format of these realm names originatorInfo
field is
defined in Section 3.1 of this document. If applicable, the
transit-policy-checked flag should be set in required for PKINIT.

3.2.4. Validation of KDC Reply

Upon receipt of the issued ticket.

3.2.2.2. Kerberos Names in Certificates

The KDC's certificate(s) MUST bind reply, the public key(s) of client proceeds as follows. If
the KDC to PA-PK-AS-REP contains a name derivable from the name of dhSignedData, the realm for that KDC. X.509
certificates MUST contain client obtains and
verifies the principal name of Diffie-Hellman parameters, and obtains the KDC (defined in
RFC 1510bis) shared key
as described above. Otherwise, the SubjectAltName version 3 extension. Below is message contains an encKeyPack,
and the definition of this version 3 extension, as specified by client decrypts and verifies 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 temporary encryption key.
In either case, the purpose of specifying a Kerberos principal name, client then decrypts 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 main reply with the type-id
resulting key, and then proceeds as described in OtherName 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 RFC 1510bis.

3.2.5. Support for OCSP

OCSP (Online Certificate Status Protocol) [cite] allows the user's certificate.) The KDC's certificate may be signed
directly by use of
on-line requests for a CA, client or there may be intermediaries if the server resides
within to determine the validity of
each other's certificates. It is particularly useful for clients
authenticating each other across a large organization, or it may be unsigned if constrained network. These
clients will not have to download the client
indicates possession (and trust) entire CRL to check for the
validity of the KDC's certificate.

Note that

In these cases, the KDC's principal name KDC generally has the instance equal better connectivity to the
realm,
OCSP server, and those fields should be appropriately set in it therefore processes the realm OCSP request and principalName fields of
response and sends the KerberosName. This is results to the case
even when obtaining a cross-realm ticket using PKINIT.

3.2.3. Client Extraction of Reply client. The changes proposed
in this section allow a client then extracts the random key used to encrypt request an OCSP response from the main
reply.
KDC when using PKINIT. This random key (in encPaReply) is encrypted with either similar to the
client's public key or with way that OCSP is
handled in [cite].

OCSP support is provided in PKINIT through the use of additional
preauthentication data. The following new preauthentication types
are defined:

PA-PK-OCSP-REQ ::= SEQUENCE {
-- PAType TBD
responderIDList [0] SEQUENCE of ResponderID OPTIONAL,
-- ResponderID is a key derived DER-encoded
-- ASN.1 type defined in [cite]
requestExtensions [1] Extensions OPTIONAL
-- Extensions is a DER-encoded
-- ASN.1 type defined in [cite]
}

PA-PK-OCSP-REP ::= SEQUENCE of OCSPResponse
-- OCSPResponse is a DER-encoded
-- ASN.1 type defined in [cite]

A KDC that receives a PA-PK-OCSP-REQ MAY send a PA-PK-OCSP-REP.
KDCs MUST NOT send a PA-PK-OCSP-REP if they do not first receive a
PA-PK-OCSP-REQ from the DH values
exchanged between the client and the KDC. client. The client uses this
random key KDC may either send a cached
OCSP response or send an on-line request to decrypt the main reply, and subsequently proceeds as
described in RFC 1510bis.

3.2.4. Required Algorithms

Not all OCSP server.

When using OCSP, the response is signed by the OCSP server, which is
trusted by the client. Depending on local policy, further
verification of the algorithms in validity of the PKINIT protocol specification have OCSP server may need to be implemented done.

4. Security Considerations

PKINIT raises certain security considerations beyond those that can
be regulated strictly 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
* SHA1 digest for protocol definitions. We will address them
in this section.

PKINIT extends the Checksum in cross-realm model to the PKAuthenticator
* public-key
infrastructure. Anyone using Kerberos checksum type 'sha1'
* 3-key triple DES keys derived from PKINIT must be aware of how the Diffie-Hellman Exchange
* 3-key triple DES Temporary and Reply keys

4. Logistics and Policy

This section describes a way
certification infrastructure they are linking to define works.

Also, as in standard Kerberos, PKINIT presents the policy on possibility of
interactions between cryptosystems of varying strengths, and this
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.

PKINIT calls for each principal and request.

The KDC is not required to contain a database record randomly generated keys for users
who use public key authentication. However, if conventional
cryptosystems. Many such systems contain systematically "weak"
keys. For recommendations regarding these users are
registered with the KDC, it is recommended that weak keys, see RFC
1510bis.

PKINIT allows the database record
for these users be modified to an additional flag use of a zero nonce in the attributes
field to indicate that the user should authenticate using PKINIT.
If PKAuthenticator when
cached Diffie-Hellman parameters are used. In this flag is set and a request case, message does not contain
binding is performed using the
PKINIT preauthentication field, then nonce in the KDC sends back main request in the same
way as error of
type KDC_ERR_PREAUTH_REQUIRED indicating that a preauthentication it is done for ordinary (that is, non-PKINIT) AS-REQs. The
nonce 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 KDC request body is signed through the checksum
in this section.

First of all, PKINIT extends the cross-realm model to PKAuthenticator, and it therefore cryptographically binds the
AS-REQ with the AS-REP. If cached parameters are also used on the
client side, the public generated session key infrastructure. Anyone using PKINIT must will be aware of how the
certification infrastructure they are linking same, and a
compromised session key could lead to works.

Also, as in standard Kerberos, PKINIT presents the possibility of
interactions between different cryptosystems compromise of varying strengths,
and this now includes public-key cryptosystems. Many systems, for
instance, allow future
cached exchanges. It is desirable to limit the use of 512-bit public keys. Using such keys cached
parameters to wrap data encrypted under strong conventional cryptosystems,
such as triple-DES, may be inappropriate. just the KDC, in order to eliminate this exposure.

Care should be taken in how certificates are choosen chosen for the purposes
of authentication using PKINIT. Some local policies may require
that key escrow be applied for certain certificate types. People
deploying PKINIT should be aware of the implications of using
certificates that have escrowed keys for the purposes of
authentication.

As described in Section 3.2,

PKINIT allows does not provide for the caching of the
Diffie-Hellman parameters a "return routability" test to prevent
attackers from mounting a denial-of-service attack on the KDC side, for performance reasons.
For similar reasons, the signed data in by
causing it to perform unnecessary and expensive public-key
operations. Strictly speaking, this case is also true of standard
Kerberos, although the potential cost is not as great, because
standard Kerberos does not vary from
message make use of public-key cryptography.
It might be possible to message, until address this using a preauthentication field
as part of the cached parameters expire. Because proposed Kerberos preauthenticatino framework.

5. Acknowledgements

Some of the persistence ideas on which this proposal is based arose during
discussions over several years between members of these parameters, the client and SAAG, the KDC are to
use IETF
CAT working group, and the appropriate key derivation measures (as described in RFC
1510bis) when using cached DH parameters.

Lastly, PKINIT calls for randomly generated keys for conventional
cryptosystems. Many such systems contain systematically "weak"
keys. For recommendations 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 weak keys, see RFC
1510bis.

6. Transport Issues

Certificate chains can potentially grow quite large groups. This is an
attempt to revive some of the goals of those groups, and span several
UDP packets; this in turn increases
proposal approaches those goals primarily from the probability that a Kerberos
message involving PKINIT extensions will be broken
perspective. Lastly, comments from groups working on similar ideas
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. DCE have been invaluable.

6. Expiration Date

This draft expires August 20, 2004.

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] 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 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, Standard. An RSA
Laboratories Technical Note Version 1.5 1.5. Revised November 1, 1993

[10] R. Rivest, MIT Laboratory for Computer Science and RSA Data
Security, Inc. A Description of the RC2(r) Encryption Algorithm Algorithm.
March 1998. Request for Comments 2268.

[11] M. Wahl, S. Kille, T. Howes. Lightweight Directory Access
Protocol (v3): UTF-8 String Representation of Distinguished Names.
Request for Comments 2253.

[12] R. Housley, W. Ford, W. Polk, D. Solo. Internet X.509 Public
Key Infrastructure, Certificate and CRL Profile, January 1999. April 2002.
Request for Comments 2459.

[13] 3280.

[12] B. Kaliski, J. Staddon. PKCS #1: RSA Cryptography
Specifications, October 1998. Request for Comments 2437.

[14] S. Dusse, P. Hoffman, B. Ramsdell, J. Weinstein. S/MIME
Version 2 Certificate Handling, March 1998. Request for
Comments 2312.

[15] M. Wahl, T. Howes, S. Kille. Lightweight Directory Access
Protocol (v3), December 1997. Request for Comments 2251.

[16]

[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

[17] 8824-1.

[14] PKCS #3: Diffie-Hellman Key-Agreement Standard, An RSA
Laboratories Technical Note, Version 1.4, Revised November 1, 1993.

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,

[15] K. Raeburn. Encryption and the PSRG, regarding integration of Checksum Specifications for
Kerberos 5, October 2003. draft-ietf-krb-wg-crypto-06.txt.

[16] S. Blake-Wilson, M. Nystrom, D. Hopwood, J. Mikkelsen, 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,
T. Wright. Transport Layer Security (TLS) Extensions, June 2003.
Request for Comments 3546.

[17] M. Myers, R. Ankney, A. Malpani, S. Galperin, 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 May 25, 2002.

10. C. Adams.
Internet X.509 Public Key Infrastructure: Online Certificate Status
Protocol - OCSP, June 1999. Request for Comments 2560.

8. 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 {brian,bcn}@isi.edu

Matthew Hur
Cisco Systems
2901 Third Avenue
Seattle WA 98121
Phone: (206) 256-3197
E-Mail: mhur@cisco.com
Ari Medvinsky
Keen.com, Inc.
150 Independence Drive
Menlo Park CA 94025
Microsoft Corporation
One Microsoft Way
Redmond WA 98052
Phone: +1 650 289 3134 425 707 3336
E-mail: ari@keen.com matthur@microsoft.com, arimed@windows.microsoft.com

Sasha Medvinsky
Motorola
Motorola, Inc.
6450 Sequence Drive
San Diego, CA 92121
+1 858 404 2367
E-mail: smedvinsky@gi.com smedvinsky@motorola.com

John Wray
Iris Associates, Inc.
5 Technology Park Dr.
Westford, MA 01886
E-mail: John_Wray@iris.com

Jonathan Trostle
Cisco Systems
170 W. Tasman Dr.
San Jose, CA 95134
E-mail: jtrostle@cisco.com jtrostle@world.std.com
----