The Unencrypted Form of Kerberos 5 KRB-CRED Message
Extracted elements (11)
Kerberos Encryption Type 0 is an invalid value (per RFC 3961) and will never designate a real encryption system; its use as a sentinel in the KRB-CRED etype field was chosen because existing MIT, Heimdal, and Microsoft implementations already used this convention for unencrypted KRB-CRED messages in the GSS-API context.
The primary motivating use case for the unencrypted KRB-CRED form is the SAML V2.0 Kerberos Attribute Profile, where an Identity Provider transfers a Kerberos service ticket to a Service Provider inside an encrypted and signed SAML attribute statement, eliminating the need for pre-shared Kerberos keys between the two parties.
RFC 4120 acknowledges the non-standard legacy use of unencrypted KRB-CRED messages in the MIT, Heimdal, and Microsoft Kerberos GSS-API implementations; this document formalizes that behavior to enable its continued use in new applications without breaking existing deployments.
The optional key version number (kvno) SHOULD NOT be present in the unencrypted KRB-CRED message, and MUST be ignored by the recipient if it is present.
The unencrypted form of the KRB-CRED message MAY be used when the credentials are transferred over a transport that provides confidentiality and integrity.
When using the unencrypted form of the KRB-CRED message, the encryption type (etype) field MUST be set to 0 to signal that the message is not encrypted.
The ciphertext (cipher) field in the unencrypted KRB-CRED message carries a cleartext copy of EncKrbCredPart, as defined in Section 5.8.1 of RFC 4120, rather than any encrypted payload.
The IANA Kerberos Encryption Type registry entry for type 0 has been updated to reference RFC 6448, formally documenting its use as the sentinel value indicating an unencrypted KRB-CRED message.
Acceptable secure transports for carrying an unencrypted KRB-CRED message include TLS (RFC 5246) with mutual authentication established, or embedding the KRB-CRED within an encrypted and signed SAML 2.0 statement.
The KRB-CRED message contains highly sensitive data including secret session keys, client and server principal names, and validity periods; possession of this information with the ticket allows an attacker to impersonate the named client, and modification of the message enables credential substitution, so the message must be carefully safeguarded.
The unencrypted KRB-CRED message contains an EncryptedData structure (per RFC 4120 Section 5.2.9) with etype=0, an absent or ignored kvno, and the ciphertext field holding a cleartext copy of EncKrbCredPart as defined in RFC 4120 Section 5.8.1.