[Ietf-krb-wg] Document Action: 'Using Kerberos V5 over the Transport Layer Security (TLS) protocol' to Informational RFC (draft-josefsson-kerberos5-starttls-09.txt)

[The IESG <[e-mail]>]

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-krb-wg mailing list
[e-mail]
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg