Public Key Cryptography for Initial Authentication in Kerberos (PKINIT)
updated by
Extracted elements (31)
DH-based key delivery is preferred over RSA encryption-based delivery because it avoids using the same RSA key pair for both encryption and signing (discouraged per RFC 3447) and avoids key escrow concerns — signing-only certificates are normally not escrowed, so DH-based delivery is safer for authentication.
Initial authentication (the AS exchange) is the appropriate integration point for public-key cryptography in Kerberos because the client exposes long-term secrets only once; subsequent service ticket requests use the TGT and symmetric session key, preserving performance while enabling PKI-based bootstrapping.
Kerberos encryption type numbers 9-15 are defined to indicate support for CMS algorithms in the etype field of AS-REQ; this practice is deprecated and new numbers should not be assigned. The supportedCMSTypes field in AuthPack is the preferred mechanism, and its preference order overrides the etype field order.
Some implementations cannot decode CMS objects encoded with BER, specifically indefinite-length encodings. To maximize interoperability, implementers SHOULD encode CMS objects used in PKINIT with DER rather than BER.
All PKINIT implementations MUST support aes128-cts-hmac-sha1-96 and aes256-cts-hmac-sha1-96 as AS reply key enctypes, sha-1WithRSAEncryption as the signature algorithm, and the Diffie-Hellman key delivery method. Implementations MUST also process the EKU extension and the id-pkinit-san otherName in X.509 certificates.
All PKINIT implementations SHOULD support the public key encryption key delivery method. When supported, rsaEncryption (RSAES-PKCS1-v1_5) MUST be supported for key transport and des-ede3-cbc MUST be supported for content encryption.
All structures defined in or imported into this document MUST be encoded using Distinguished Encoding Rules (DER); all data structures carried in OCTET STRINGs MUST be encoded according to the rules specified in the specifications defining each data structure.
If a revoked certificate is detected, the KDC MUST return KDC_ERR_REVOKED_CERTIFICATE; if revocation status cannot be determined, it SHOULD return KDC_ERR_REVOCATION_STATUS_UNKNOWN. The invalid/revoked certificates are identified using TD_INVALID_CERTIFICATES typed data.
The client MUST be capable of sending certificates sufficient for the KDC to construct a certification path for the client's certificate. The KDC MUST be capable of sending certificates sufficient for the client to construct a certification path for the KDC's certificate. Neither MUST include 'root' CA certificates.
The KDC MAY require the id-pkinit-KPClientAuth EKU in client certificates; the digitalSignature key usage bit MUST be asserted when this EKU is present. If required but absent or inconsistent, return KDC_ERR_INCONSISTENT_KEY_PURPOSE. KDCs SHOULD also accept id-ms-kp-sc-logon (1.3.6.1.4.1.311.20.2.2) for compatibility with deployed certificates.
The KDC MUST set the initial flag and include an AD_INITIAL_VERIFIED_CAS authorization data element in the issued ticket; AD-INITIAL-VERIFIED-CAS is a SEQUENCE OF ExternalPrincipalIdentifier identifying the certification path used to validate the client certificate.
The KDC MUST verify the client's signature in the signedAuthPack per RFC 3852, validate the client's X.509 certificate per RFC 3280, and check that the public key is bound to the client principal name in the AS-REQ; mismatch returns KDC_ERR_CLIENT_NAME_MISMATCH.
The lifetime of the ticket returned by the KDC MUST NOT exceed that of the client's public-private key pair. For X.509 certificates, this is the certificate validity period unless configured otherwise.
The paChecksum field in PKAuthenticator MUST be present and contains the SHA1 checksum performed over KDC-REQ-BODY. If absent, the KDC MUST return KDC_ERR_PA_CHECKSUM_MUST_BE_INCLUDED, allowing a new client to retry with SHA1 if permitted by local policy.
Upon receipt of the KDC reply, the client MUST verify the KDC's signature per RFC 3852 and validate the KDC's X.509 certificate per RFC 3280. The KDC certificate MUST contain an id-pkinit-san SAN matching the TGS name of the target realm or the client MUST require the id-pkinit-KPKdc EKU.
When the KDC reuses DH keys, it MUST include an expiration time in dhKeyExpiration and a serverDHNonce at least as long as the symmetric encryption key. The KDC SHOULD NOT reuse DH keys unless clientDHNonce is present in the request.
When using DH key agreement, implementations MUST support Oakley 1024-bit MODP group 2 (RFC 2412) and 2048-bit MODP group 14 (RFC 3526), and SHOULD support 4096-bit MODP group 16. DH exponents should have at least twice as many bits as the symmetric keys derived from them.
The AS reply key for DH exchange is derived as k = octetstring2key(DHSharedSecret | n_c | n_k), where octetstring2key applies K-truncate(SHA1(0x00|x) | SHA1(0x01|x) | ...) then random-to-key(). When DH keys are reused, clientDHNonce (n_c) and serverDHNonce (n_k) are mixed in; otherwise both are empty.
The id-pkinit-san OID ({iso(1) org(3) dod(6) internet(1) security(5) kerberosv5(2) x509SanAN(2)}) is used in the Subject Alternative Name extension to carry a KRB5PrincipalName (SEQUENCE of Realm and PrincipalName) binding a certificate to a Kerberos principal.
The KDC indicates PKINIT support by including an empty PA_PK_AS_REQ element (zero-length OCTET STRING padata-value) in the METHOD-DATA of a KRB-ERROR response. KDCs MUST leave this field empty and clients MUST ignore any value present.
PKINIT defines new Kerberos pre-authentication types PA_PK_AS_REQ (16) and PA_PK_AS_REP (17), authorization data type AD_INITIAL_VERIFIED_CAS (9), error codes KDC_ERR_CLIENT_NOT_TRUSTED (62) through KDC_ERR_PUBLIC_KEY_ENCRYPTION_NOT_SUPPORTED (81), and typed data types TD_TRUSTED_CERTIFIERS (104), TD_INVALID_CERTIFICATES (105), and TD_DH_PARAMETERS (109).
Kerberos error messages are not integrity protected, so TD-DH-PARAMETERS sent by the KDC can be tampered by an attacker to cause selection of weaker or non-mutually-preferred DH domain parameters. Local policy should configure acceptable parameters or disallow negotiation.
PKINIT does not provide a 'return routability' test, leaving the KDC exposed to DoS attacks via expensive public-key operations. DH key reuse (via clientDHNonce and serverDHNonce) minimizes per-request crypto cost and mitigates this risk.
The client MUST verify that the KDC certificate's issuing CA is authorized to issue KDC certificates for the target realm; failure to do so means the binding between the KDC certificate and the target realm's KDC is not established, enabling impersonation.
When DH key exchange is used, additional pre-authentication data beyond PA_PK_AS_REQ is not bound to the AS-REQ; attackers can drop or add such data without detection by either client or KDC. Designers of additional pre-authentication mechanisms must account for this.
AuthPack is a SEQUENCE containing: pkAuthenticator [0] PKAuthenticator, clientPublicValue [1] SubjectPublicKeyInfo OPTIONAL (DH domain parameters and client public key, BIT STRING per RFC 3279), supportedCMSTypes [2] SEQUENCE OF AlgorithmIdentifier OPTIONAL, and clientDHNonce [3] DHNonce OPTIONAL.
KDCDHKeyInfo is a SEQUENCE containing: subjectPublicKey [0] BIT STRING (KDC's DH public key encoded per RFC 3279), nonce [1] INTEGER (0..4294967295) (request nonce, or 0 if DH keys reused), and dhKeyExpiration [2] KerberosTime OPTIONAL (present iff DH keys reused; KDC's key MUST NOT be used past this time).
PA-PK-AS-REP is a CHOICE: dhInfo [0] DHRepInfo (used for DH key exchange, contains dhSignedData over KDCDHKeyInfo and optional serverDHNonce) or encKeyPack [1] IMPLICIT OCTET STRING (CMS EnvelopedData wrapping SignedData over ReplyKeyPack for public key encryption).
PA-PK-AS-REQ is a SEQUENCE containing: signedAuthPack [0] IMPLICIT OCTET STRING (CMS ContentInfo/SignedData over AuthPack, eContentType id-pkinit-authData), trustedCertifiers [1] SEQUENCE OF ExternalPrincipalIdentifier OPTIONAL, and kdcPkId [2] IMPLICIT OCTET STRING OPTIONAL (CMS SignerIdentifier).
PKAuthenticator is a SEQUENCE containing: cusec [0] INTEGER (0..999999), ctime [1] KerberosTime (for replay prevention), nonce [2] INTEGER (0..4294967295) (randomly chosen, need not match KDC-REQ-BODY nonce), and paChecksum [3] OCTET STRING OPTIONAL (MUST be present; SHA1 over KDC-REQ-BODY).
ReplyKeyPack is a SEQUENCE containing: replyKey [0] EncryptionKey (the AS reply key encrypting enc-part of AS-REP) and asChecksum [1] Checksum (keyed checksum over AS-REQ using replyKey with key usage 6; client MUST verify upon receipt).