RFC 6448

The Unencrypted Form of Kerberos 5 KRB-CRED Message

📅 published November 2011, from ietf

RFC 6448: The Unencrypted Form of Kerberos 5 KRB-CRED Message 🎀

okay bestie, let's start with the title block 💅 This is RFC 6448, published by the Internet Engineering Task Force (IETF) in November 2011. Russell J. Yount wrote it while at Carnegie Mellon University. It's a Standards Track document, so it's an official Internet Standard in the making 👑 The ISSN is 2070-1721. The title block doesn't list anything it obsoletes or updates, so no drama there 🙈

Abstract ✨

okay so the Kerberos 5 KRB-CRED message is what apps use to pass Kerberos credentials to each other 🦋 When it travels over a secure transport, the unencrypted form of KRB-CRED might be what you want. This doc describes that unencrypted form 💖

Status of This Memo

This is an Internet Standards Track document 🎀

This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It went through public review and got approved for publication by the Internet Engineering Steering Group (IESG). For more on Internet Standards, check Section 2 of RFC 5741 🌸

For the current status of this document, any errata, and how to send feedback, go to http://www.rfc-editor.org/info/rfc6448 ✨

Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved. 💜

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please read these carefully, because they spell out your rights and restrictions for this document 🙈 Code Components pulled from this document must include Simplified BSD License text, as described in Section 4.e of the Trust Legal Provisions, and they come without warranty, as described in the Simplified BSD License 📜

1. Introduction ✨

okay so there are apps that need to pass Kerberos credentials between each other without already having shared Kerberos keys 🦋 When it goes over a transport that provides confidentiality and integrity, the unencrypted form of the KRB-CRED message MAY be used 🫶 One app that does this is the Kerberos attribute transport mechanism, described in Section 2.7 of the Security Assertion Markup Language (SAML) V2.0 Kerberos Attribute Profile [SAMLv2-KRB-ATTRIB] 💅

In the SAML setup, the Identity Provider (IdP) somehow gets a Kerberos service ticket from the Kerberos Key Distribution Center (KDC) whenever the SAML system needs one. Then it hands that credential to a Service Provider (SP) inside an attribute statement. The SP can use the credential to reach a Kerberos protected service 🧚

The Kerberos 5 specification in [RFC4120] mentions that the MIT, Heimdal, and Microsoft Kerberos implementations have a non-standard, legacy habit of using unencrypted KRB-CRED messages with the Generic Security Service Application Program Interface (GSS-API) [RFC1964] 🙈 This document gives a formal spec for the unencrypted form of KRB-CRED so it can keep being used in new apps 🎀

2. Requirements Notation

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119] 📜

3. The Unencrypted Form of the KRB-CRED Message

okay so the unencrypted form of KRB-CRED contains EncryptedData, as defined in Section 5.2.9 of [RFC4120] 🍓 The encryption type (etype) MUST be specified as 0. The optional key version number (kvno) SHOULD NOT be present, and MUST be ignored by the recipient if it is present 🫶 The ciphertext (cipher) is a copy of the EncKrbCredPart, which is in cleartext, as defined in Section 5.8.1 of [RFC4120] 🌸

4. Kerberos Encryption Type 0 Is Not an Encryption System

lowkey the most iconic part of this whole doc 😭 The Kerberos Encryption Type 0 is an invalid value [RFC3961]. That means no encryption type with value 0 will ever be defined, and no encryption or key management operation will use it 🔥 Layers above the encryption layer often pass encryption types around as integer values. Those layers are free to use a 0 in an encryption type integer as a flag or sentinel value, or for other context-specific purposes 🧚 For example, Section 3 of this specification defines what a 0 means in the KRB-CRED message's encryption type field. There, it's a message-specific indicator that the message is not encrypted 💖 This approach was chosen because of existing Kerberos implementations that conform to this specification 👑

5. Security Considerations

ngl this section is serious, so read it fr fr 💀 The KRB-CRED message contains sensitive info about the Kerberos credentials being transferred, like their secret session keys, client and server principal names, and validity period. If an attacker had that info along with the ticket itself, they could impersonate the client named in the ticket 😭 If the KRB-CRED message can be modified, the attacker can swap in different credentials. That can make the recipient use the credentials of a client that was never meant to be used. So the KRB-CRED message must be carefully safeguarded 🔒

The unencrypted form of the KRB-CRED message MUST only be used with a transport where sender and recipient identities can be established to be known to each other. The transport MUST also provide confidentiality, integrity, and mutual authentication.

Examples of transports that MAY be securely used to carry an unencrypted KRB-CRED message include Transport Layer Security (TLS) [RFC5246], where mutual authentication has been established, or messages where the KRB-CRED is encoded within an encrypted and signed SAML 2.0 [OASIS-SAMLv2] statement 🛡️

6. Acknowledgements

The following individuals contributed to the development of this specification 🫶

  • Thomas Hardjono, Massachusetts Institute of Technology 🎓
  • Josh Howlett, Individual 🌸
  • Jeffrey Hutzelman, Carnegie Mellon University 💜

7. IANA Considerations

The reference for Kerberos Encryption Type 0 has been updated to point to this document ✨

8. References

8.1. Normative References

  • [OASIS-SAMLv2] Cantor, S., Ed., Kemp, J., Ed., Philpott, R., Ed., and E. Maler, Ed., "Assertions and Protocol for the OASIS Security Assertion Markup Language (SAML) V2.0", OASIS Standard saml-core-2.0-os, March 2005. 📚
  • [RFC1964] Linn, J., "The Kerberos Version 5 GSS-API Mechanism", RFC 1964, June 1996. 📚
  • [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. 📚
  • [RFC4120] Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The Kerberos Network Authentication Service (V5)", RFC 4120, July 2005. 📚
  • [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, August 2008. 📚

8.2. Informative References

  • [RFC3961] Raeburn, K., "Encryption and Checksum Specifications for Kerberos 5", RFC 3961, February 2005. 📖
  • [SAMLv2-KRB-ATTRIB] Howlett, J., Ed., and T. Hardjono, Ed., "SAML V2.0 Kerberos Attribute Profile Version 1.0", sstc-saml-attribute-kerberos.odt, August 2011. 📖

Author's Address

Russell J. Yount
Carnegie Mellon University
5000 Forbes Avenue
Pittsburgh, Pennsylvania  15213
US

Phone: +1 412 268 8391
EMail: rjy@cmu.edu
📦 where this page comes from