RFC 6251

RFC 6251: Using Kerberos Version 5 over the Transport Layer Security (TLS) Protocol 🎀

Okay bestie, this is RFC 6251 💖 It was written by S. Josefsson from SJD AB, it's Category: Informational (so it's here to share info, not a Standards Track thing 🌸), and it dropped in May 2011. Its ISSN is 2070-1721. The header doesn't list anything it obsoletes or updates 🦋

Abstract ✨

This doc is all about how Kerberos V5 can be carried over Transport Layer Security (TLS) so you get extra security features 🔐

Status of This Memo 📜

This is not an Internet Standards Track spec. It's published purely for informational purposes 💅

It's a product of the Internet Engineering Task Force (IETF) 🌈 It reflects what the IETF community agreed on, got public review, and was approved for publication by the Internet Engineering Steering Group (IESG) ✨ Not every IESG-approved doc is a candidate for any level of Internet Standard, so check Section 2 of RFC 5741 if you're curious 🙈

For the current status, any errata, and how to give feedback, go to http://www.rfc-editor.org/info/rfc6251 🔗

Copyright Notice ©️

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

This doc is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) as they were in effect on the day it was published. Please read these carefully, because they spell out your rights and restrictions for this document 📖 Code Components pulled out of this document must include the Simplified BSD License text, as described in Section 4.e of the Trust Legal Provisions, and they come with no warranty, as the Simplified BSD License describes 🫶

This doc might contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008 🕰️ The people who control the copyright in some of that material might not have given the IETF Trust permission to allow modifications outside the IETF Standards Process. So unless you get an adequate license from those copyright holders, this document can't be modified outside the IETF Standards Process, and derivative works can't be made outside it either. The one exceptions are formatting it for publication as an RFC or translating it into languages other than English 🌍

Table of Contents 🗂️

1. Introduction and Background .....................................2
2. Kerberos V5 STARTTLS Extension ..................................3
3. Examples ........................................................4
4. STARTTLS-Aware KDC Discovery ....................................5
5. Server Certificates .............................................6
6. IANA Considerations .............................................7
7. Acknowledgements ................................................7
8. Security Considerations .........................................7
9. References ......................................................8
   9.1. Normative References .......................................8
   9.2. Informative References .....................................8

1. Introduction and Background 🌸

This doc explains how a Kerberos V5 [RFC4120] implementation can upgrade communication between clients and Key Distribution Centers (KDCs) to use the Transport Layer Security (TLS) [RFC5246] protocol 🦋

TLS gives you integrity- and privacy-protected exchanges that can be authenticated with X.509 certificates, OpenPGP keys [RFC6091], and usernames and passwords via Secure Remote Password (SRP) [RFC5054] 🔐

So why bother running Kerberos V5 over TLS? There are a few really good reasons 👑

• It prevents downgrade attacks that could mess with things like encryption types and pre-auth data negotiation 💀 The encryption type field in KDC-REQ, and the METHOD-DATA field carrying the requested pre-auth types from the server in KDC_ERR_PREAUTH_REQUIRED errors in KDC-REP, get sent without integrity or privacy protection in Kerberos V5. That means an active attacker could swap the encryption type for a compromised one, like 56-bit DES, or ask clients to use a broken pre-auth type 😭

Clients usually can't know which encryption types other servers support, or which pre-auth types servers prefer or require. So it's really hard for a client to tell whether there's a man in the middle, or whether the remote server just didn't support a stronger encryption type or preferred a different pre-auth type 🙈

• Kerberos exchanges get privacy protection 🫣 Parts of lots of Kerberos packets get sent without privacy protection (meaning no encryption). That stuff includes things like the client principal name, the server principal name, the encryption types the client supports, the lifetime of tickets, and more ✨ In some threat models, revealing that info is considered a problem 💅
• It gives extra authentication against the KDC 🧚 In some situations, users have smart cards with an RSA authentication key. In others, users have an OpenPGP client on their desktop, with a public OpenPGP key the server knows 🍓
• It gives explicit server authentication of the KDC to the client 💖 In traditional Kerberos V5, the KDC's authentication is proved as a side effect of the KDC knowing your encryption key (aka your password). Main-character energy for explicit auth, honestly 👑

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 RFC 2119 [RFC2119] 🎀

2. Kerberos V5 STARTTLS Extension 🦋

The STARTTLS extension uses the Kerberos V5 TCP extension mechanism [RFC5021] 💅 It uses bit 0 in the extension bitmask 🔥

Here's how it goes. The client asks for the extension by setting the STARTTLS bit in the TCP extension mechanism bitmask 🙌 (How to handle extension negotiation failures at this point is described in [RFC5021], so go check there, bestie 📖) Once the server sends the 4-octet value 0x00000000 to say it supports this extension, the stream is controlled by the TLS protocol and its framing 🌈 The client is the one who starts the TLS protocol 🚀

Usually, the client kicks off the TLS handshake by sending a client hello ✨ The server responds, and the handshake keeps going until it either succeeds or fails 🫶

If the handshake fails for any reason, the STARTTLS protocol fails too, and the TLS error is used as the error indication 💀 When that happens, no more messages can be exchanged over that same TCP session 😭

If the handshake succeeds, the Kerberos V5 authentication protocol runs inside the protected TLS channel, just like a normal TCP Kerberos V5 exchange 🔐 That means every Kerberos V5 packet gets prefixed by a 4-octet length field that tells you how long the Kerberos V5 packet is 🧚

When no more Kerberos V5 messages need to go over the TLS session, the TLS session MUST be shut down properly using the close_notify alert 🛑 Once the TLS session is shut down, the TCP connection can't be reused to send any more data, so it MUST be closed 💜

5. Server Certificates ✨

okay so TLS can run in a mode where the server proves who it is using stuff like X.509 and OpenPGP 🔐 bestie, this is giving security realness 💅

here's the vibe. the goal is for this protocol to be as easy to implement and deploy on clients as plain UDP/TCP support is 🦋 and a lot of client environments don't have long-term storage, or they only have storage that isn't secure enough to validate server certificates 😭 so the Kerberos V5 STARTTLS protocol does not make clients verify server certificates. if it did, those constrained clients would have to turn TLS off entirely, and ngl that would be even worse than TLS without certificate validation 💀 because TLS still protects against some attacks that Kerberos V5 over UDP/TCP doesn't. for example, even without certificate validation, TLS protects against passive network sniffing that's trying to track which Kerberos services a given client uses 🙈

BUT. note that using TLS without server certificate verification opens the door to a whole range of active attacks, like man in the middle 😱🚨 bestie be careful.

when clients can validate the server certificate, they MUST do it 🫶 that's why, if a KDC presents an X.509 server certificate over TLS, it MUST contain an otherName Subject Alternative Name (SAN) with a type-id of id-krb5starttls-san 🎀 the whole point is to bind the server certificate to the Kerberos realm so it's only used for Kerberos V5 STARTTLS 🌸 the value field of the otherName should contain the realm as the "Realm" ASN.1 type.

id-krb5starttls-san OBJECT IDENTIFIER ::=
  { iso(1) identified-organization(3) dod(6) internet(1)
    private(4) enterprise(1) gnu(11591)
    shishi(6) krb5starttls-san(1) }

to validate a server certificate, the client MAY use local configuration (for example, a list that maps the Kerberos realm to a copy of the server's certificate) and compare that with the authentication info the server gave over TLS 🧚 for illustration, the server certificate could be an X.509 certificate or an OpenPGP key. in this mode the client doesn't need to do any processing related to id-krb5starttls-san ✨

when the server presents an X.509 server certificate, clients MAY use "Certification Path Validation" as described in [RFC5280] to validate the KDC server certificate 💜 and unless the client can otherwise verify that the server certificate is bound to the KDC of the target realm, the client MUST verify that the server certificate contains the id-krb5starttls-san SAN and that the value is identical to the intended Kerberos realm 👑

6. IANA Considerations 🌈

per [RFC5021], IANA has allocated a bit (value 0) in the "Kerberos TCP Extensions" registry for Krb5 over TLS, the extension described in this doc 🍓

7. Acknowledgements 🫶

Miguel A. Garcia, Sam Hartman, Jeffrey Hutzelman, Magnus Nystroem, and Peter Saint-Andre (in alphabetical order) gave comments that made the protocol and document better 💖 literally the squad ✨

8. Security Considerations 🔥

this section is serious, bestie, read it twice 😭🚨

the security considerations in Kerberos V5, TLS, and the Kerberos V5 TCP extension mechanism are inherited 🔐

note that TLS does not protect against man-in-the-middle attacks unless clients verify the KDC's credentials (X.509 certificate, OpenPGP key, etc.) correctly 💀 certificate validation adds an extra layer of protection, but it's not considered strictly necessary to improve the security profile of Kerberos V5 as outlined in this document 🦋

if server authentication is used, some info about the server (such as its name) is visible to passive attackers 👀

to protect against the inherent downgrade attack in the extension framework, implementations SHOULD offer a policy mode that requires this extension to always be successfully negotiated, for a particular realm, or generally 🛡️ for interoperability with implementations that don't support this extension, the policy mode SHOULD be disabled by default 🎀

9. References 📚

9.1. Normative References

[RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
           Requirement Levels", BCP 14, RFC 2119, March 1997.

[RFC2782]  Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for
           specifying the location of services (DNS SRV)", RFC 2782,
           February 2000.

[RFC4120]  Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The
           Kerberos Network Authentication Service (V5)", RFC 4120,
           July 2005.

[RFC5021]  Josefsson, S., "Extended Kerberos Version 5 Key
           Distribution Center (KDC) Exchanges over TCP", RFC 5021,
           August 2007.

[RFC5246]  Dierks, T. and E. Rescorla, "The Transport Layer Security
           (TLS) Protocol Version 1.2", RFC 5246, August 2008.

[RFC5280]  Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
           Housley, R., and W. Polk, "Internet X.509 Public Key
           Infrastructure Certificate and Certificate Revocation List
           (CRL) Profile", RFC 5280, May 2008.

9.2. Informative References

[RFC5054]  Taylor, D., Wu, T., Mavrogiannopoulos, N., and T. Perrin,
           "Using the Secure Remote Password (SRP) Protocol for TLS
           Authentication", RFC 5054, November 2007.

[RFC6091]  Mavrogiannopoulos, N. and D. Gillmor, "Using OpenPGP Keys
           for Transport Layer Security (TLS) Authentication",
           RFC 6091, February 2011.

Author's Address 🖊️

Simon Josefsson
Simon Josefsson Datakonsult AB
Hagagatan 24
Stockholm  113 47
Sweden

EMail: simon@josefsson.org
URI:   http://josefsson.org/