-- Type SubjectPublicKeyInfo is defined in
-- [RFC3280].
-- Specifies Diffie-Hellman domain parameters
-- and the client’s public key value [IEEE1363].
-- The DH public key value is encoded as a BIT
-- STRING according to [RFC3279].
-- This field is present only if the client wishes
-- to use the Diffie-Hellman key agreement method.
supportedCMSTypes [2] SEQUENCE OF AlgorithmIdentifier
OPTIONAL,
-- Type AlgorithmIdentifier is defined in
-- [RFC3280].
-- List of CMS algorithm [RFC3370] identifiers
-- that identify key transport algorithms, or
-- content encryption algorithms, or signature
-- algorithms supported by the client in order of
-- (decreasing) preference.
clientDHNonce [3] DHNonce OPTIONAL,
-- Present only if the client indicates that it
-- wishes to reuse DH keys or to allow the KDC to
-- do so (see Section 3.2.3.1).
...
}
PKAuthenticator ::= SEQUENCE {
cusec [0] INTEGER (0..999999),
ctime [1] KerberosTime,
-- cusec and ctime are used as in [RFC4120], for
-- replay prevention.
nonce [2] INTEGER (0..4294967295),
-- Chosen randomly; this nonce does not need to
-- match with the nonce in the KDC-REQ-BODY.
paChecksum [3] OCTET STRING OPTIONAL,
-- MUST be present.
-- Contains the SHA1 checksum, performed over
-- KDC-REQ-BODY.
...
}
The ContentInfo [RFC3852] structure contained in the signedAuthPack
field of the type PA-PK-AS-REQ is encoded according to [RFC3852] and
is filled out as follows:
1. The contentType field of the type ContentInfo is id-signedData
(as defined in [RFC3852]), and the content field is a SignedData
(as defined in [RFC3852]).
2. The eContentType field for the type SignedData is id-pkinit-
authData: { iso(1) org(3) dod(6) internet(1) security(5)
kerberosv5(2) pkinit(3) authData(1) }. Notes to CMS
implementers: the signed attribute content-type MUST be present
in this SignedData instance, and its value is id-pkinit-authData
according to [RFC3852].
3. The eContent field for the type SignedData contains the DER
encoding of the type AuthPack.
4. The signerInfos field of the type SignedData contains a single
signerInfo, which contains the signature over the type AuthPack.
5. The AuthPack structure contains a PKAuthenticator, the client
public key information, the CMS encryption types supported by the
client, and a DHNonce. The pkAuthenticator field certifies to
the KDC that the client has recent knowledge of the signing key
that authenticates the client. The clientPublicValue field
specifies Diffie-Hellman domain parameters and the client’s
public key value. The DH public key value is encoded as a BIT
STRING according to [RFC3279]. The clientPublicValue field is
present only if the client wishes to use the Diffie-Hellman key
agreement method. The supportedCMSTypes field specifies the list
of CMS algorithm identifiers that are supported by the client in
order of (decreasing) preference, and can be used to identify a
signature algorithm or a key transport algorithm [RFC3370] in the
keyEncryptionAlgorithm field of the type KeyTransRecipientInfo,
or a content encryption algorithm [RFC3370] in the
contentEncryptionAlgorithm field of the type EncryptedContentInfo
[RFC3852] when encrypting the AS reply key as described in
Section 3.2.3.2. However, there is no significance in the
relative order between any two of different types of algorithms:
key transport algorithms, content encryption algorithms, and
signature algorithms. The clientDHNonce field is described later
in this section.
6. The ctime field in the PKAuthenticator structure contains the
current time on the client’s host, and the cusec field contains
the microsecond part of the client’s timestamp. The ctime and
cusec fields are used together to specify a reasonably accurate
timestamp [RFC4120]. The nonce field is chosen randomly. The
paChecksum field MUST be present and it contains a SHA1 checksum
that is performed over the KDC-REQ-BODY [RFC4120]. In order to
ease future migration from the use of SHA1, the paChecksum field
is made optional syntactically: when the request is extended to
negotiate hash algorithms, the new client wishing not to use SHA1
will send the request in the extended message syntax without the
paChecksum field. The KDC conforming to this specification MUST
return a KRB-ERROR [RFC4120] message with the code
KDC_ERR_PA_CHECKSUM_MUST_BE_INCLUDED (see Section 3.2.3). That
will allow a new client to retry with SHA1 if allowed by the
local policy.
7. The certificates field of the type SignedData contains
certificates intended to facilitate certification path
construction, so that the KDC can verify the signature over the
type AuthPack. For path validation, these certificates SHOULD be
sufficient to construct at least one certification path from the
client certificate to one trust anchor acceptable by the KDC
[RFC4158]. The client MUST be capable of including such a set of
certificates if configured to do so. The certificates field MUST
NOT contain "root" CA certificates.
8. The client’s Diffie-Hellman public value (clientPublicValue) is
included if and only if the client wishes to use the Diffie-
Hellman key agreement method. The Diffie-Hellman domain
parameters [IEEE1363] for the client’s public key are specified
in the algorithm field of the type SubjectPublicKeyInfo
[RFC3279], and the client’s Diffie-Hellman public key value is
mapped to a subjectPublicKey (a BIT STRING) according to
[RFC3279]. When using the Diffie-Hellman key agreement method,
implementations MUST support Oakley 1024-bit Modular Exponential
(MODP) well-known group 2 [RFC2412] and Oakley 2048-bit MODP
well-known group 14 [RFC3526] and SHOULD support Oakley 4096-bit
MODP well-known group 16 [RFC3526].
The Diffie-Hellman field size should be chosen so as to provide
sufficient cryptographic security [RFC3766].
When MODP Diffie-Hellman is used, the exponents should have at
least twice as many bits as the symmetric keys that will be
derived from them [ODL99].
9. The client may wish to reuse DH keys or to allow the KDC to do so
(see Section 3.2.3.1). If so, then the client includes the
clientDHNonce field. This nonce string MUST be as long as the
longest key length of the symmetric key types that the client
supports. This nonce MUST be chosen randomly.
The ExternalPrincipalIdentifier structure is used in this document to
identify the subject’s public key thereby the subject principal.
This structure is filled out as follows:
1. The subjectName field contains a PKIX type Name encoded according
to [RFC3280]. This field identifies the certificate subject by
the distinguished subject name. This field is REQUIRED when
there is a distinguished subject name present in the certificate
being used.
2. The issuerAndSerialNumber field contains a CMS type
IssuerAndSerialNumber encoded according to [RFC3852]. This field
identifies a certificate of the subject. This field is REQUIRED
for TD-INVALID-CERTIFICATES and TD-TRUSTED-CERTIFIERS (both
structures are defined in Section 3.2.2).
3. The subjectKeyIdentifier [RFC3852] field identifies the subject’s
public key by a key identifier. When an X.509 certificate is
referenced, this key identifier matches the X.509
subjectKeyIdentifier extension value. When other certificate
formats are referenced, the documents that specify the
certificate format and their use with the CMS must include
details on matching the key identifier to the appropriate
certificate field. This field is RECOMMENDED for TD-TRUSTED-
CERTIFIERS (as defined in Section 3.2.2).
The trustedCertifiers field of the type PA-PK-AS-REQ contains a list
of CAs, trusted by the client, that can be used to certify the KDC.
Each ExternalPrincipalIdentifier identifies a CA or a CA certificate
(thereby its public key).
The kdcPkId field of the type PA-PK-AS-REQ contains a CMS type
SignerIdentifier encoded according to [RFC3852]. This field
identifies, if present, a particular KDC public key that the client
already has.
3.2.2. Receipt of Client Request
Upon receiving the client’s request, the KDC validates it. This
section describes the steps that the KDC MUST (unless otherwise
noted) take in validating the request.
The KDC verifies the client’s signature in the signedAuthPack field
according to [RFC3852].
If, while validating the client’s X.509 certificate [RFC3280], the
KDC cannot build a certification path to validate the client’s
certificate, it sends back a KRB-ERROR [RFC4120] message with the
code KDC_ERR_CANT_VERIFY_CERTIFICATE. The accompanying e-data for
this error message is a TYPED-DATA (as defined in [RFC4120]) that
contains an element whose data-type is TD_TRUSTED_CERTIFIERS, and
whose data-value contains the DER encoding of the type TD-TRUSTED-
CERTIFIERS:
TD-TRUSTED-CERTIFIERS ::= SEQUENCE OF
ExternalPrincipalIdentifier
-- Identifies a list of CAs trusted by the KDC.
-- Each ExternalPrincipalIdentifier identifies a CA
-- or a CA certificate (thereby its public key).
Each ExternalPrincipalIdentifier (as defined in Section 3.2.1) in the
TD-TRUSTED-CERTIFIERS structure identifies a CA or a CA certificate
(thereby its public key) trusted by the KDC.
Upon receiving this error message, the client SHOULD retry only if it
has a different set of certificates (from those of the previous
requests) that form a certification path (or a partial path) from one
of the trust anchors acceptable by the KDC to its own certificate.
If, while processing the certification path, the KDC determines that
the signature on one of the certificates in the signedAuthPack field
is invalid, it returns a KRB-ERROR [RFC4120] message with the code
KDC_ERR_INVALID_CERTIFICATE. The accompanying e-data for this error
message is a TYPED-DATA that contains an element whose data-type is
TD_INVALID_CERTIFICATES, and whose data-value contains the DER
encoding of the type TD-INVALID-CERTIFICATES:
TD-INVALID-CERTIFICATES ::= SEQUENCE OF
ExternalPrincipalIdentifier
-- Each ExternalPrincipalIdentifier identifies a
-- certificate (sent by the client) with an invalid
-- signature.
Each ExternalPrincipalIdentifier (as defined in Section 3.2.1) in the
TD-INVALID-CERTIFICATES structure identifies a certificate (that was
sent by the client) with an invalid signature.
If more than one X.509 certificate signature is invalid, the KDC MAY
include one IssuerAndSerialNumber per invalid signature within the
TD-INVALID-CERTIFICATES.
The client’s X.509 certificate is validated according to [RFC3280].
Depending on local policy, the KDC may also check whether any X.509
certificates in the certification path validating the client’s
certificate have been revoked. If any of them have been revoked, the
KDC MUST return an error message with the code
KDC_ERR_REVOKED_CERTIFICATE; if the KDC attempts to determine the
revocation status but is unable to do so, it SHOULD return an error
message with the code KDC_ERR_REVOCATION_STATUS_UNKNOWN. The
certificate or certificates affected are identified exactly as for
the error code KDC_ERR_INVALID_CERTIFICATE (see above).
Note that the TD_INVALID_CERTIFICATES error data is only used to
identify invalid certificates sent by the client in the request.
The client’s public key is then used to verify the signature. If the
signature fails to verify, the KDC MUST return an error message with
the code KDC_ERR_INVALID_SIG. There is no accompanying e-data for
this error message.
In addition to validating the client’s signature, the KDC MUST also
check that the client’s public key used to verify the client’s
signature is bound to the client principal name specified in the AS-
REQ as follows:
1. If the KDC has its own binding between either the client’s
signature-verification public key or the client’s certificate and
the client’s Kerberos principal name, it uses that binding.
2. Otherwise, if the client’s X.509 certificate contains a Subject
Alternative Name (SAN) extension carrying a KRB5PrincipalName
(defined below) in the otherName field of the type GeneralName
[RFC3280], it binds the client’s X.509 certificate to that name.
The type of the otherName field is AnotherName. The type-id field
of the type AnotherName is id-pkinit-san:
id-pkinit-san OBJECT IDENTIFIER ::=
{ iso(1) org(3) dod(6) internet(1) security(5) kerberosv5(2)
x509SanAN (2) }
And the value field of the type AnotherName is a
KRB5PrincipalName.
KRB5PrincipalName ::= SEQUENCE {
realm [0] Realm,
principalName [1] PrincipalName
}
If the Kerberos client name in the AS-REQ does not match a name bound
by the KDC (the binding can be in the certificate, for example, as
described above), or if there is no binding found by the KDC, the KDC
MUST return an error message with the code
KDC_ERR_CLIENT_NAME_MISMATCH. There is no accompanying e-data for
this error message.
Even if the certification path is validated and the certificate is
mapped to the client’s principal name, the KDC may decide not to
accept the client’s certificate, depending on local policy.
The KDC MAY require the presence of an Extended Key Usage (EKU)
KeyPurposeId [RFC3280] id-pkinit-KPClientAuth in the extensions field
of the client’s X.509 certificate:
id-pkinit-KPClientAuth OBJECT IDENTIFIER ::=
{ iso(1) org(3) dod(6) internet(1) security(5) kerberosv5(2)
pkinit(3) keyPurposeClientAuth(4) }
-- PKINIT client authentication.
-- Key usage bits that MUST be consistent:
-- digitalSignature.
The digitalSignature key usage bit [RFC3280] MUST be asserted when
the intended purpose of the client’s X.509 certificate is restricted
with the id-pkinit-KPClientAuth EKU.
If this EKU KeyPurposeId is required but it is not present, or if the
client certificate is restricted not to be used for PKINIT client
authentication per Section 4.2.1.13 of [RFC3280], the KDC MUST return
an error message of the code KDC_ERR_INCONSISTENT_KEY_PURPOSE. There
is no accompanying e-data for this error message. KDCs implementing
this requirement SHOULD also accept the EKU KeyPurposeId
id-ms-kp-sc-logon (1.3.6.1.4.1.311.20.2.2) as meeting the
requirement, as there are a large number of X.509 client certificates
deployed for use with PKINIT that have this EKU.
As a matter of local policy, the KDC MAY decide to reject requests on
the basis of the absence or presence of other specific EKU OIDs.
If the digest algorithm used in generating the CA signature for the
public key in any certificate of the request is not acceptable by the
KDC, the KDC MUST return a KRB-ERROR [RFC4120] message with the code
KDC_ERR_DIGEST_IN_CERT_NOT_ACCEPTED. The accompanying e-data MUST be
encoded in TYPED-DATA, although none is defined at this point.
If the client’s public key is not accepted with reasons other than
those specified above, the KDC returns a KRB-ERROR [RFC4120] message
with the code KDC_ERR_CLIENT_NOT_TRUSTED. There is no accompanying
e-data currently defined for this error message.
The KDC MUST check the timestamp to ensure that the request is not a
replay, and that the time skew falls within acceptable limits. The
recommendations for clock skew times in [RFC4120] apply here. If the
check fails, the KDC MUST return error code KRB_AP_ERR_REPEAT or
KRB_AP_ERR_SKEW, respectively.
If the clientPublicValue is filled in, indicating that the client
wishes to use the Diffie-Hellman key agreement method, the KDC SHOULD
check to see if the key parameters satisfy its policy. If they do
not, it MUST return an error message with the code
KDC_ERR_DH_KEY_PARAMETERS_NOT_ACCEPTED. The accompanying e-data is a
TYPED-DATA that contains an element whose data-type is
TD_DH_PARAMETERS, and whose data-value contains the DER encoding of
the type TD-DH-PARAMETERS:
TD-DH-PARAMETERS ::= SEQUENCE OF AlgorithmIdentifier
-- Each AlgorithmIdentifier specifies a set of
-- Diffie-Hellman domain parameters [IEEE1363].
-- This list is in decreasing preference order.
TD-DH-PARAMETERS contains a list of Diffie-Hellman domain parameters
that the KDC supports in decreasing preference order, from which the
client SHOULD pick one to retry the request.
The AlgorithmIdentifier structure is defined in [RFC3280] and is
filled in according to [RFC3279]. More specifically, Section 2.3.3
of [RFC3279] describes how to fill in the AlgorithmIdentifier
structure in the case where MODP Diffie-Hellman key exchange is used.
If the client included a kdcPkId field in the PA-PK-AS-REQ and the
KDC does not possess the corresponding key, the KDC MUST ignore the
kdcPkId field as if the client did not include one.
If the digest algorithm used by the id-pkinit-authData is not
acceptable by the KDC, the KDC MUST return a KRB-ERROR [RFC4120]
message with the code KDC_ERR_DIGEST_IN_SIGNED_DATA_NOT_ACCEPTED.
The accompanying e-data MUST be encoded in TYPED-DATA, although none
is defined at this point.
3.2.3. Generation of KDC Reply
If the paChecksum filed in the request is not present, the KDC
conforming to this specification MUST return a KRB-ERROR [RFC4120]
message with the code KDC_ERR_PA_CHECKSUM_MUST_BE_INCLUDED. The
accompanying e-data MUST be encoded in TYPED-DATA (no error data is
defined by this specification).
Assuming that the client’s request has been properly validated, the
KDC proceeds as per [RFC4120], except as follows.
The KDC MUST set the initial flag and include an authorization data
element of ad-type [RFC4120] AD_INITIAL_VERIFIED_CAS in the issued
ticket. The ad-data [RFC4120] field contains the DER encoding of the
type AD-INITIAL-VERIFIED-CAS:
AD-INITIAL-VERIFIED-CAS ::= SEQUENCE OF
ExternalPrincipalIdentifier
-- Identifies the certification path with which
-- the client certificate was validated.
-- Each ExternalPrincipalIdentifier identifies a CA
-- or a CA certificate (thereby its public key).
The AD-INITIAL-VERIFIED-CAS structure identifies the certification
path with which the client certificate was validated. Each
ExternalPrincipalIdentifier (as defined in Section 3.2.1) in the AD-
INITIAL-VERIFIED-CAS structure identifies a CA or a CA certificate
(thereby its public key).
Note that the syntax for the AD-INITIAL-VERIFIED-CAS authorization
data does permit empty SEQUENCEs to be encoded. Such empty sequences
may only be used if the KDC itself vouches for the user’s
certificate.
The AS wraps any AD-INITIAL-VERIFIED-CAS data in AD-IF-RELEVANT
containers if the list of CAs satisfies the AS’ realm’s local policy
(this corresponds to the TRANSITED-POLICY-CHECKED ticket flag
[RFC4120]). Furthermore, any TGS MUST copy such authorization data
from tickets used within a PA-TGS-REQ of the TGS-REQ into the
resulting ticket. If the list of CAs satisfies the local KDC’s
realm’s policy, the TGS MAY wrap the data into the AD-IF-RELEVANT
container; otherwise, it MAY unwrap the authorization data out of the
AD-IF-RELEVANT container.
Application 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
acceptable. (This corresponds to the AP server’s checking the
transited field when the TRANSITED-POLICY-CHECKED flag has not been
set [RFC4120].) If such a data type is contained within an AD-IF-
RELEVANT container, AP servers MAY apply local policy to determine
whether the authorization data is acceptable.
A pre-authentication data element, whose padata-type is PA_PK_AS_REP
and whose padata-value contains the DER encoding of the type PA-PK-
AS-REP (defined below), is included in the AS-REP [RFC4120].
PA-PK-AS-REP ::= CHOICE {
dhInfo [0] DHRepInfo,
-- Selected when Diffie-Hellman key exchange is
-- used.
encKeyPack [1] IMPLICIT OCTET STRING,
-- Selected when public key encryption is used.
-- Contains a CMS type ContentInfo encoded
-- according to [RFC3852].
-- The contentType field of the type ContentInfo is
-- id-envelopedData (1.2.840.113549.1.7.3).
-- The content field is an EnvelopedData.
-- The contentType field for the type EnvelopedData
-- is id-signedData (1.2.840.113549.1.7.2).
-- The eContentType field for the inner type
-- SignedData (when unencrypted) is