The IESG has approved the following document: - 'Using Kerberos V5 over the Transport Layer Security (TLS) protocol' (draft-josefsson-kerberos5-starttls-09.txt) as an Informational RFC This document is the product of the Kerberos Working Group. The IESG contact persons are Tim Polk and Sean Turner. A URL of this Internet Draft is: http://datatracker.ietf.org/doc/draft-josefsson-kerberos5-starttls/ Technical Summary This document specify how the Kerberos V5 protocol can be transported over the Transport Layer Security (TLS) protocol, to provide additional security features. Working Group Summary This technical specification represents the consensus of the Kerberos Working Group. However, the working group is also working on an alternate solution to an overlapping problem. It is not yet clear whether either or both specifications will win in the marketplace or whether either will become mandatory in a future version of the base Kerberos specification. However, we feel it is important to publish these specifications to gain implemention and deployment experience. Therefore, we are requesting publication of this document as an Informational RFC, and may request that it be upgraded to Proposed Standard at a later time. Document Quality At least one implementor has indicated an intention to support the extension described in this document. Personnel The Document Shepherd for this document is Jeffrey Hutzelman. The responsible Area Director is Tim Polk. RFC Editor Note In Section 4, change: OLD: Section 7.2.3 of Kerberos V5 [RFC4120] describe how Domain Name System (DNS) SRV records [RFC2782] can be used to find the address of an KDC. We define a new Proto of "tls" to indicate that the particular KDC is intended to support this STARTTLS extension. The Service, Realm, TTL, Class, SRV, Priority, Weight, Port and Target have the same meaning as in RFC 4120. For example: _kerberos._tls.EXAMPLE.COM. IN SRV 0 0 88 kdc1.example.com. _kerberos._tls.EXAMPLE.COM. IN SRV 1 0 88 kdc2.example.com. NEW: Section 7.2.3 of Kerberos V5 [RFC4120] describe how Domain Name System (DNS) SRV records [RFC2782] can be used to find the address of an KDC. We define a new Service of "kerberos-tls" to indicate that the particular KDC is intended to support this STARTTLS extension. The Proto (tcp), Realm, TTL, Class, SRV, Priority, Weight, Port and Target have the same meaning as in RFC 4120. For example: _kerberos-tls._tcp.EXAMPLE.COM. IN SRV 0 0 88 kdc1.example.com. _kerberos-tls._tcp.EXAMPLE.COM. IN SRV 1 0 88 kdc2.example.com. In Section 5, please make the following substitution: OLD The Kerberos V5 STARTTLS protocol do not require clients to verify the server certificate. The goal is that support for TLS in Kerberos V5 clients should be as easy to implement and deploy as support for UDP/TCP. Use of TLS, even without server certificate validation, protects against some attacks that Kerberos V5 over UDP/TCP do not. (For example, passive network sniffing between the user and the KDC to track which Kerberos services are used by the user.) To require server certificates to be validated at all times would lead to disabling of TLS when clients are unable to validate server certificates, and this may have worse security properties than using TLS and not validate the server certificate would have. Many client environments do not have secure long-term storage, which is required to validate certificates. This makes it impossible to use server certificate validation on a large number of client systems. NEW A goal for the protocol described in this memo is that it should be as easy to implement and deploy on clients as support for UDP/TCP. Since many client environments do not have secure long-term storage (and server certificate validation requires some form of long-term storage), the Kerberos V5 STARTTLS protocol does not require clients to verify server certificates. If server certification had been required, then environments with constrained clients such as those mentioned would be forced to disable TLS; this would arguably be worse than TLS without server certificate validation as use of TLS, even without server certificate validation, protects against some attacks that Kerberos V5 over UDP/TCP do not. For example, even without server certificate validation, TLS does protect against passive network sniffing aimed at tracking Kerberos service usage by a given client. Note however that use of TLS without server certificate verification opens up for a range of active attacks such as man-in-the-middle. In order to safely validate certificates, a client needs access to secure long-term storage. However, many client environments do not provide secure long-term storage (e.g., because the machine has been compromised). This makes it impossible to use server certificate validation on a large number of client systems. _______________________________________________ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
