-- id-pkinit-rkeyData (1.3.6.1.5.2.3.3) and the
-- eContent field contains the DER encoding of the
-- type ReplyKeyPack.
-- ReplyKeyPack is defined in Section 3.2.3.2.
...
}
DHRepInfo ::= SEQUENCE {
dhSignedData [0] IMPLICIT OCTET STRING,
-- Contains a CMS type ContentInfo encoded according
-- to [RFC3852].
-- The contentType field of the type ContentInfo is
-- id-signedData (1.2.840.113549.1.7.2), and the
-- content field is a SignedData.
-- The eContentType field for the type SignedData is
-- id-pkinit-DHKeyData (1.3.6.1.5.2.3.2), and the
-- eContent field contains the DER encoding of the
-- type KDCDHKeyInfo.
-- KDCDHKeyInfo is defined below.
serverDHNonce [1] DHNonce OPTIONAL,
-- Present if and only if dhKeyExpiration is
-- present in the KDCDHKeyInfo.
...
}
KDCDHKeyInfo ::= SEQUENCE {
subjectPublicKey [0] BIT STRING,
-- The KDC’s DH public key.
-- The DH public key value is encoded as a BIT
-- STRING according to [RFC3279].
nonce [1] INTEGER (0..4294967295),
-- Contains the nonce in the pkAuthenticator field
-- in the request if the DH keys are NOT reused,
-- 0 otherwise.
dhKeyExpiration [2] KerberosTime OPTIONAL,
-- Expiration time for KDC’s key pair,
-- present if and only if the DH keys are reused.
-- If present, the KDC’s DH public key MUST not be
-- used past the point of this expiration time.
-- If this field is omitted then the serverDHNonce
-- field MUST also be omitted.
...
}
The content of the AS-REP is otherwise unchanged from [RFC4120]. The
KDC encrypts the reply as usual, but not with the client’s long-term
key. Instead, it encrypts it with either a shared key derived from a
Diffie-Hellman exchange or a generated encryption key. The contents
of the PA-PK-AS-REP indicate which key delivery method is used.
If the client does not wish to use the Diffie-Hellman key delivery
method (the clientPublicValue field is not present in the request)
and the KDC does not support the public key encryption key delivery
method, the KDC MUST return an error message with the code
KDC_ERR_PUBLIC_KEY_ENCRYPTION_NOT_SUPPORTED. There is no
accompanying e-data for this error message.
In addition, the lifetime of the ticket returned by the KDC MUST NOT
exceed that of the client’s public-private key pair. The ticket
lifetime, however, can be shorter than that of the client’s public-
private key pair. For the implementations of this specification, the
lifetime of the client’s public-private key pair is the validity
period in X.509 certificates [RFC3280], unless configured otherwise.
3.2.3.1. Using Diffie-Hellman Key Exchange
In this case, the PA-PK-AS-REP contains a DHRepInfo structure.
The ContentInfo [RFC3852] structure for the dhSignedData field is
filled in 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 the OID value
for id-pkinit-DHKeyData: { iso(1) org(3) dod(6) internet(1)
security(5) kerberosv5(2) pkinit(3) DHKeyData(2) }. Notes to CMS
implementers: the signed attribute content-type MUST be present
in this SignedData instance, and its value is id-pkinit-DHKeyData
according to [RFC3852].
3. The eContent field for the type SignedData contains the DER
encoding of the type KDCDHKeyInfo.
4. The KDCDHKeyInfo structure contains the KDC’s public key, a
nonce, and, optionally, the expiration time of the KDC’s DH key
being reused. The subjectPublicKey field of the type
KDCDHKeyInfo field identifies KDC’s DH public key. This DH
public key value is encoded as a BIT STRING according to
[RFC3279]. The nonce field contains the nonce in the
pkAuthenticator field in the request if the DH keys are NOT
reused. The value of this nonce field is 0 if the DH keys are
reused. The dhKeyExpiration field is present if and only if the
DH keys are reused. If the dhKeyExpiration field is present, the
KDC’s public key in this KDCDHKeyInfo structure MUST NOT be used
past the point of this expiration time. If this field is
omitted, then the serverDHNonce field MUST also be omitted.
5. The signerInfos field of the type SignedData contains a single
signerInfo, which contains the signature over the type
KDCDHKeyInfo.
6. The certificates field of the type SignedData contains
certificates intended to facilitate certification path
construction, so that the client can verify the KDC’s signature
over the type KDCDHKeyInfo. The information contained in the
trustedCertifiers in the request SHOULD be used by the KDC as
hints to guide its selection of an appropriate certificate chain
to return to the client. This field may be left empty if the KDC
public key specified by the kdcPkId field in the PA-PK-AS-REQ was
used for signing. Otherwise, for path validation, these
certificates SHOULD be sufficient to construct at least one
certification path from the KDC certificate to one trust anchor
acceptable by the client [RFC4158]. The KDC MUST be capable of
including such a set of certificates if configured to do so. The
certificates field MUST NOT contain "root" CA certificates.
7. If the client included the clientDHNonce field, then the KDC may
choose to reuse its DH keys. If the server reuses DH keys, then
it MUST include an expiration time in the dhKeyExpiration field.
Past the point of the expiration time, the signature over the
type DHRepInfo is considered expired/invalid. When the server
reuses DH keys then, it MUST include a serverDHNonce at least as
long as the length of keys for the symmetric encryption system
used to encrypt the AS reply. Note that including the
serverDHNonce changes how the client and server calculate the key
to use to encrypt the reply; see below for details. The KDC
SHOULD NOT reuse DH keys unless the clientDHNonce field is
present in the request.
The AS reply key is derived as follows:
1. Both the KDC and the client calculate the shared secret value as
follows:
a) When MODP Diffie-Hellman is used, let DHSharedSecret be the
shared secret value. DHSharedSecret is the value ZZ, as
described in Section 2.1.1 of [RFC2631].
DHSharedSecret is first padded with leading zeros such that the
size of DHSharedSecret in octets is the same as that of the
modulus, then represented as a string of octets in big-endian
order.
Implementation note: Both the client and the KDC can cache the
triple (ya, yb, DHSharedSecret), where ya is the client’s public
key and yb is the KDC’s public key. If both ya and yb are the
same in a later exchange, the cached DHSharedSecret can be used.
2. Let K be the key-generation seed length [RFC3961] of the AS reply
key whose enctype is selected according to [RFC4120].
3. Define the function octetstring2key() as follows:
octetstring2key(x) == random-to-key(K-truncate(
SHA1(0x00 | x) |
SHA1(0x01 | x) |
SHA1(0x02 | x) |
...
))
where x is an octet string; | is the concatenation operator; 0x00,
0x01, 0x02, etc. are each represented as a single octet; random-
to-key() is an operation that generates a protocol key from a
bitstring of length K; and K-truncate truncates its input to the
first K bits. Both K and random-to-key() are as defined in the
kcrypto profile [RFC3961] for the enctype of the AS reply key.
4. When DH keys are reused, let n_c be the clientDHNonce and n_k be
the serverDHNonce; otherwise, let both n_c and n_k be empty octet
strings.
5. The AS reply key k is:
k = octetstring2key(DHSharedSecret | n_c | n_k)
3.2.3.2. Using Public Key Encryption
In this case, the PA-PK-AS-REP contains the encKeyPack field where
the AS reply key is encrypted.
The ContentInfo [RFC3852] structure for the encKeyPack field is
filled in as follows:
1. The contentType field of the type ContentInfo is id-envelopedData
(as defined in [RFC3852]), and the content field is an
EnvelopedData (as defined in [RFC3852]).
2. The contentType field for the type EnvelopedData is id-
signedData: { iso (1) member-body (2) us (840) rsadsi (113549)
pkcs (1) pkcs7 (7) signedData (2) }.
3. The eContentType field for the inner type SignedData (when
decrypted from the encryptedContent field for the type
EnvelopedData) is id-pkinit-rkeyData: { iso(1) org(3) dod(6)
internet(1) security(5) kerberosv5(2) pkinit(3) rkeyData(3) }.
Notes to CMS implementers: the signed attribute content-type MUST
be present in this SignedData instance, and its value is id-
pkinit-rkeyData according to [RFC3852].
4. The eContent field for the inner type SignedData contains the DER
encoding of the type ReplyKeyPack (as described below).
5. The signerInfos field of the inner type SignedData contains a
single signerInfo, which contains the signature for the type
ReplyKeyPack.
6. The certificates field of the inner type SignedData contains
certificates intended to facilitate certification path
construction, so that the client can verify the KDC’s signature
for the type ReplyKeyPack. The information contained in the
trustedCertifiers in the request SHOULD be used by the KDC as
hints to guide its selection of an appropriate certificate chain
to return to the client. This field may be left empty if the KDC
public key specified by the kdcPkId field in the PA-PK-AS-REQ was
used for signing. Otherwise, for path validation, these
certificates SHOULD be sufficient to construct at least one
certification path from the KDC certificate to one trust anchor
acceptable by the client [RFC4158]. The KDC MUST be capable of
including such a set of certificates if configured to do so. The
certificates field MUST NOT contain "root" CA certificates.
7. The recipientInfos field of the type EnvelopedData is a SET that
MUST contain exactly one member of type KeyTransRecipientInfo.
The encryptedKey of this member contains the temporary key that
is encrypted using the client’s public key.
8. The unprotectedAttrs or originatorInfo fields of the type
EnvelopedData MAY be present.
If there is a supportedCMSTypes field in the AuthPack, the KDC must
check to see if it supports any of the listed types. If it supports
more than one of the types, the KDC SHOULD use the one listed first.
If it does not support any of them, it MUST return an error message
with the code KDC_ERR_ETYPE_NOSUPP [RFC4120].
Furthermore, the KDC computes the checksum of the AS-REQ in the
client request. This checksum is performed over the type AS-REQ, and
the protocol key [RFC3961] of the checksum operation is the replyKey,
and the key usage number is 6. If the replyKey’s enctype is "newer"
[RFC4120] [RFC4121], the checksum operation is the required checksum
operation [RFC3961] of that enctype.
ReplyKeyPack ::= SEQUENCE {
replyKey [0] EncryptionKey,
-- Contains the session key used to encrypt the
-- enc-part field in the AS-REP, i.e., the
-- AS reply key.
asChecksum [1] Checksum,
-- Contains the checksum of the AS-REQ
-- corresponding to the containing AS-REP.
-- The checksum is performed over the type AS-REQ.
-- The protocol key [RFC3961] of the checksum is the
-- replyKey and the key usage number is 6.
-- If the replyKey’s enctype is "newer" [RFC4120]
-- [RFC4121], the checksum is the required
-- checksum operation [RFC3961] for that enctype.
-- The client MUST verify this checksum upon receipt
-- of the AS-REP.
...
}
Implementations of this RSA encryption key delivery method are
RECOMMENDED to support RSA keys at least 2048 bits in size.
3.2.4. Receipt of KDC Reply
Upon receipt of the KDC’s reply, the client proceeds as follows. If
the PA-PK-AS-REP contains the dhSignedData field, the client derives
the AS reply key using the same procedure used by the KDC, as defined
in Section 3.2.3.1. Otherwise, the message contains the encKeyPack
field, and the client decrypts and extracts the temporary key in the
encryptedKey field of the member KeyTransRecipientInfo and then uses
that as the AS reply key.
If the public key encryption method is used, the client MUST verify
the asChecksum contained in the ReplyKeyPack.
In either case, the client MUST verify the signature in the
SignedData according to [RFC3852]. The KDC’s X.509 certificate MUST
be validated according to [RFC3280]. In addition, unless the client
can otherwise verify that the public key used to verify the KDC’s
signature is bound to the KDC of the target realm, the KDC’s X.509
certificate MUST contain a Subject Alternative Name extension
[RFC3280] carrying an AnotherName whose type-id is id-pkinit-san (as
defined in Section 3.2.2) and whose value is a KRB5PrincipalName that
matches the name of the TGS of the target realm (as defined in
Section 7.3 of [RFC4120]).
Unless the client knows by some other means that the KDC certificate
is intended for a Kerberos KDC, the client MUST require that the KDC
certificate contains the EKU KeyPurposeId [RFC3280] id-pkinit-KPKdc:
id-pkinit-KPKdc OBJECT IDENTIFIER ::=
{ iso(1) org(3) dod(6) internet(1) security(5) kerberosv5(2)
pkinit(3) keyPurposeKdc(5) }
-- Signing KDC responses.
-- Key usage bits that MUST be consistent:
-- digitalSignature.
The digitalSignature key usage bit [RFC3280] MUST be asserted when
the intended purpose of the KDC’s X.509 certificate is restricted
with the id-pkinit-KPKdc EKU.
If the KDC certificate contains the Kerberos TGS name encoded as an
id-pkinit-san SAN, this certificate is certified by the issuing CA as
a KDC certificate, therefore the id-pkinit-KPKdc EKU is not required.
If all applicable checks are satisfied, the client then decrypts the
enc-part field of the KDC-REP in the AS-REP, using the AS reply key,
and then proceeds as described in [RFC4120].
3.3. Interoperability Requirements
The client MUST be capable of sending a set of certificates
sufficient to allow the KDC to construct a certification path for the
client’s certificate, if the correct set of certificates is provided
through configuration or policy.
If the client sends all the X.509 certificates on a certification
path to a trust anchor acceptable by the KDC, and if the KDC cannot
verify the client’s public key otherwise, the KDC MUST be able to
process path validation for the client’s certificate based on the
certificates in the request.
The KDC MUST be capable of sending a set of certificates sufficient
to allow the client to construct a certification path for the KDC’s
certificate, if the correct set of certificates is provided through
configuration or policy.
If the KDC sends all the X.509 certificates on a certification path
to a trust anchor acceptable by the client, and the client can not
verify the KDC’s public key otherwise, the client MUST be able to
process path validation for the KDC’s certificate based on the
certificates in the reply.
3.4. KDC Indication of PKINIT Support
If pre-authentication is required but was not present in the request,
per [RFC4120] an error message with the code KDC_ERR_PREAUTH_FAILED
is returned, and a METHOD-DATA object will be stored in the e-data
field of the KRB-ERROR message to specify which pre-authentication
mechanisms are acceptable. The KDC can then indicate the support of
PKINIT by including an empty element whose padata-type is
PA_PK_AS_REQ in that METHOD-DATA object.
Otherwise if it is required by the KDC’s local policy that the client
must be pre-authenticated using the pre-authentication mechanism
specified in this document, but no PKINIT pre-authentication was
present in the request, an error message with the code
KDC_ERR_PREAUTH_FAILED SHOULD be returned.
KDCs MUST leave the padata-value field of the PA_PK_AS_REQ element in
the KRB-ERROR’s METHOD-DATA empty (i.e., send a zero-length OCTET
STRING), and clients MUST ignore this and any other value. Future
extensions to this protocol may specify other data to send instead of
an empty OCTET STRING.
4. Security Considerations
The security of cryptographic algorithms is dependent on generating
secret quantities [RFC4086]. The number of truly random bits is
extremely important in determining the attack resistance strength of
the cryptosystem; for example, the secret Diffie-Hellman exponents
must be chosen based on n truly random bits (where n is the system
security requirement). The security of the overall system is
significantly weakened by using insufficient random inputs: a
sophisticated attacker may find it easier to reproduce the
environment that produced the secret quantities and to search the
resulting small set of possibilities than to locate the quantities in
the whole of the potential number space.
Kerberos error messages are not integrity protected; as a result, the
domain parameters sent by the KDC as TD-DH-PARAMETERS can be tampered
with by an attacker so that the set of domain parameters selected
could be either weaker or not mutually preferred. Local policy can
configure sets of domain parameters acceptable locally, or disallow
the negotiation of DH domain parameters.
The symmetric reply key size and Diffie-Hellman field size or RSA
modulus 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].
PKINIT raises certain security considerations beyond those that can
be regulated strictly in protocol definitions. We will address them
in this section.
PKINIT extends the cross-realm model to the public-key
infrastructure. Users of PKINIT must understand security policies
and procedures appropriate to the use of Public Key Infrastructures
[RFC3280].
In order to trust a KDC certificate that is certified by a CA as a
KDC certificate for a target realm (for example, by asserting the TGS
name of that Kerberos realm as an id-pkinit-san SAN and/or
restricting the certificate usage by using the id-pkinit-KPKdc EKU,
as described in Section 3.2.4), the client MUST verify that the KDC
certificate’s issuing CA is authorized to issue KDC certificates for
that target realm. Otherwise, the binding between the KDC
certificate and the KDC of the target realm is not established.
How to validate this authorization is a matter of local policy. A
way to achieve this is the configuration of specific sets of
intermediary CAs and trust anchors, one of which must be on the KDC
certificate’s certification path [RFC3280], and, for each CA or trust
anchor, the realms for which it is allowed to issue certificates.
In addition, if any CA that is trusted to issue KDC certificates can
also issue other kinds of certificates, then local policy must be
able to distinguish between them; for example, it could require that
KDC certificates contain the id-pkinit-KPKdc EKU or that the realm be
specified with the id-pkinit-san SAN.
It is the responsibility of the PKI administrators for an
organization to ensure that KDC certificates are only issued to KDCs,
and that clients can ascertain this using their local policy.
Standard Kerberos allows the possibility of interactions between
cryptosystems of varying strengths; this document adds interactions
with public-key cryptosystems to Kerberos. Some administrative
policies may allow the use of relatively weak public keys. When
using such weak asymmetric keys to protect/exchange stronger
symmetric Keys, the attack resistant strength of the overall system
is no better than that of these weak keys [RFC3766].
PKINIT requires that keys for symmetric cryptosystems be generated.
Some such systems contain "weak" keys. For recommendations regarding
these weak keys, see [RFC4120].
PKINIT allows the use of the same RSA key pair for encryption and
signing when doing RSA encryption-based key delivery. This is not
recommended usage of RSA keys [RFC3447]; by using DH-based key
delivery, this is avoided.
Care should be taken in how certificates are chosen for the purposes
of authentication using PKINIT. Some local policies may require that
key escrow be used for certain certificate types. Deployers of
PKINIT should be aware of the implications of using certificates that