Using Kerberos Version 5 over the Transport Layer Security (TLS) Protocol
draft-josefsson-kerberos5-starttls-09

[Ballot comment]
Per discussion with the author on the krb-wg list, the responsible AD shall add an RFC Editor note changing this existing text:

  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.

to this agreed-upon modification:

  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.

NOTE: per further discussion to harmonize the proposed text with suggested text from Magnus Nystrom, the text will be changed to:

  Since many client environments do not have access to long-term
  storage, or to long-term storage that is sufficiently secure to
  enable validation of server certificates, the Kerberos V5
  STARTTLS protocol does not require clients to verify server
  certificates.

[Ballot comment]
Per discussion with the author on the krb-wg list, the responsible AD shall add an RFC Editor note changing this existing text:

  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.

to this agreed-upon modification:

  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.

[Ballot discuss]
Taking over Jari's DISCUSS.

I do appreciate that we're trying to improve a bad situation here. However, it seems that we're not implementing best security practices in this specification. In particular, version -08 says:

  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.

We could make the same argument about clients for all application protocols (HTTP, IMAP, SIP, XMPP, etc.). Why is Kerberos unique in this regard? Is there something special about Kerberos clients that I'm missing? Does the difference hinge on the phrase "secure long-term storage" (and how is that defined)?

I suggest reviewing draft-saintandre-tls-id-check (version -04 to be released 2010-04-30) on best practices for secure authentication in the context of TLS, then clarifying why Kerberos clients need to follow different certificate validation rules from most other application protocols.

[Ballot discuss]
This is an excellent document, and I wanted to vote Yes on it. However,
there is one small but important issue that I wanted to discuss before
doing so. The document says:

  To validate a server certificate, the client MAY use local
  configuration (e.g., a list that maps the Kerberos realm to a copy of
  the server's certificate) and compare that with the authentication
  information provided from the server via TLS.  For illustration, the
  server certificate could be a X.509 certificate or an OpenPGP key.
  In this mode, the client need no processing related to id-
  krb5starttls-san.

  When the server presents a X.509 server certificate, clients MAY use
  "Certification Path Validation" as described in [RFC5280] to validate
  the KDC server certificate.  In addition, 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.

In other words, local validation is a MAY, certification path validation
is a MAY, and the only thing that is a MUST is checking that the server
claims to represent the intended Kerberos realm. Is there something
that prevents the server from lying in the SAN? Wouldn't it be proper
to require that either local validation or certification path validation
is a MUST?

[Ballot discuss]
I like the document and would vote No Objections once my issue is discussed:

4.  STARTTLS aware KDC Discovery

  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.

We need to discuss how introduction of "_tls" affects DNS SRV registry reorganization.

[Ballot comment]
Does this need to be mentioned in the IANA Considerations:

5.  Server Certificates

  When clients have the ability, they MUST validate the server
  certificate.  For this reason, if a KDC presents a X.509 server
  certificate over TLS, it MUST contain an otherName Subject
  Alternative Name (SAN) identified using a type-id of id-krb5starttls-
  san.  The intention is to bind the server certificate to the Kerberos
  realm for the purpose of using 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) }

?

[Ballot discuss]
I like the document and would vote No Objections once my issue is discussed:

4.  STARTTLS aware KDC Discovery

  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.

We need to discuss how introduction of "_tls" affects DNS SRV registry reorganization.

IANA comments:

Upon approval of this document, IANA will make the following
assignments in the "Kerberos TCP Extensions" registry at
http://www.iana.org/assignments/kerberos-parameters/kerberos-parameters.xhtml

Value Description Reference
----- ----------- ---------
TBD Krb5 over TLS [RFC-josefsson-kerberos5-starttls-07]

We understand the above to be the only IANA Action for this document.

This is a request to the IESG to approve publication of "Using Kerberos
V5 over the Transport Layer Security (TLS) protocol",
draft-josefsson-kerberos5-starttls-07.txt, as an Informational RFC.
This document is a product of the Kerberos Working Group.

(1.a)  Who is the Document Shepherd for this document?  Has the
      Document Shepherd personally reviewed this version of the
      document and, in particular, does he or she believe this
      version is ready for forwarding to the IESG for publication?

      >> The Document Shepherd for this document is Jeffrey Hutzelman,
      >> .  I have reviewed this document, and I believe
      >> it is ready for IETF-wide review and publication as a
      >> Proposed Standard.

(1.b)  Has the document had adequate review both from key WG members
      and from key non-WG members?  Does the Document Shepherd have
      any concerns about the depth or breadth of the reviews that
      have been performed?

      >> This document has received review both within the working group
      >> and from key experts outside the working group.  Any issues raised
      >> have been resolved.

(1.c)  Does the Document Shepherd have concerns that the document
      needs more review from a particular or broader perspective,
      e.g., security, operational complexity, someone familiar with
      AAA, internationalization or XML?

      >> This document defines the use of TLS to protect exchanges
      >> between a Kerberos client and Key Distribution Center (KDC).
      >> As such, it depends on the security properties of TLS in
      >> ways that may warrant further review from subject-matter
      >> experts.  To date, no such review has been solicited or
      >> received.
      >>
      >> In addition, as described below, there is an issue which may
      >> benefit from input from PKIX experts.

(1.d)  Does the Document Shepherd have any specific concerns or
      issues with this document that the Responsible Area Director
      and/or the IESG should be aware of?  For example, perhaps he
      or she is uncomfortable with certain parts of the document, or
      has concerns whether there really is a need for it.  In any
      event, if the WG has discussed those issues and has indicated
      that it still wishes to advance the document, detail those
      concerns here.  Has an IPR disclosure related to this document
      been filed?  If so, please include a reference to the
      disclosure and summarize the WG discussion and conclusion on
      this issue.

      >> This document allows for two methods for Kerberos clients to
      >> verify the certificate of a KDC: preshared certificates and
      >> RFC5280 path validation.  For the later case, a new type is
      >> defined for the otherName field, containing the name of the
      >> Kerberos realm for which the certificate subject acts as KDC;
      >> the presence of a name of this type is taken to mean that the
      >> certificate may be used with this protocol.  No extended key
      >> purpose is defined for this protocol.
      >>
      >> Several concerns about this approach have been raised by some
      >> working group participants, including myself.  Particularly,
      >> it would seem appropriate to reuse the method used by PKINIT
      >> (RFC4556), which identifies a realm's KDC's using a particular
      >> value in the KRB5PrincipalName type defined in that document
      >> (see section 3.2.4), rather than defining a new name type.
      >> More importantly, the failure to define an extended key purpose
      >> means it would be impossible to issue a certificate which
      >> restricted to use only with this protocol, or with this
      >> protocol in combination with some other specific set of
      >> protocols, such as PKINIT.
      >>
      >> PKINIT defines a key purpose for use in certificates issued
      >> to KDC's, and requires its presence except in certificates
      >> which are identified as belonging to KDC's by use of the
      >> KRB5PrincipalName type with an appropriate value.  However, it
      >> does not waive RFC5280's requirement that a certificate which
      >> contains the extendedKeyUsage extension be used only for the
      >> specific purposes identified there.  We believe this approach
      >> to also be appropriate for the present document.
      >>
      >> The working group was unable to reach a consensus on this
      >> question, but there was a strong consensus that it would be
      >> preferable to move forward with the document rather than delay
      >> indefinitely attempting to come to a resolution.  Therefore,
      >> it was agreed that the document be submitted in its present
      >> form, with this issue called out and described in the writeup,
      >> and that participants who felt strongly about this issue would
      >> have the opportunity to re-raise it during IETF Last Call.
      >>
      >> This consensus and agreement to move forward was supported by
      >> all of those who participated in discussion of this issue,
      >> including myself.  Therefore, I expect no appeals or similar
      >> problems as a result.  However, I feel that additional input
      >> from PKIX experts may be helpful, and I do expect this issue
      >> to be raised during IETF Last Call.
      >>
      >> No IPR disclosures related to this document have been filed.

(1.e)  How solid is the WG consensus behind this document?  Does it
      represent the strong concurrence of a few individuals, with
      others being silent, or does the WG as a whole understand and
      agree with it?

      >> This is solid consensus within the working group to publish
      >> this document.  It is worth noting that a partial overlap
      >> exists between the functionality of this document and of the
      >> FAST preauthentication mechanism described in section 6.4 of
      >> draft-ietf-krb-wg-preauth-framework-15.txt, which provides
      >> an encrypted tunnel to protect exchange of preauthentication
      >> data between a client and a KDC.  The intended status of the
      >> latter document is standards track, and there exists a rough
      >> consensus to require implementation of the FAST mechanism
      >> in Kerberos implementations which conform to the framework
      >> defined in that document.  Therefore, we are requesting the
      >> publication of the present document as an Informational RFC,
      >> and may request that it be upgraded to Proposed Standard at
      >> a later time.

(1.f)  Has anyone threatened an appeal or otherwise indicated extreme
      discontent?  If so, please summarise the areas of conflict in
      separate email messages to the Responsible Area Director.  (It
      should be in a separate email because this questionnaire is
      entered into the ID Tracker.)

      >> There have been no threats of appeal or other expressions of
      >> of discontent as a result of publication of this document.
      >> There is some dismay at the length of time it has taken to
      >> progress this document, as both the author and working group
      >> believed the technical aspects of the document were ready
      >> well over a year ago.  Unfortunately, this document has been
      >> through multiple cycles of long silence followed by a new
      >> issue surfacing just as the chair was about to move forward
      >> on it.

(1.g)  Has the Document Shepherd personally verified that the
      document satisfies all ID nits?  (See
      http://www.ietf.org/ID-Checklist.html and
      http://tools.ietf.org/tools/idnits/).  Boilerplate checks are
      not enough; this check needs to be thorough.  Has the document
      met all formal review criteria it needs to, such as the MIB
      Doctor, media type and URI type reviews?

      >> This document has been run through the idnits tool, and was
      >> reviewed manually for compliance with requirements not checked
      >> by the automatic tool.  No additional formal review criteria
      >> apply to this document.

(1.h)  Has the document split its references into normative and
      informative?  Are there normative references to documents that
      are not ready for advancement or are otherwise in an unclear
      state?  If such normative references exist, what is the
      strategy for their completion?  Are there normative references
      that are downward references, as described in [RFC3967]?  If
      so, list these downward references to support the Area
      Director in the Last Call procedure for them [RFC3967].

      >> References have been split appropriately.  All references
      >> are to published RFC's, and all normative references are
      >> to BCP or standards-track documents.

(1.i)  Has the Document Shepherd verified that the document IANA
      consideration section exists and is consistent with the body
      of the document?  If the document specifies protocol
      extensions, are reservations requested in appropriate IANA
      registries?  Are the IANA registries clearly identified?  If
      the document creates a new registry, does it define the
      proposed initial contents of the registry and an allocation
      procedure for future registrations?  Does it suggest a
      reasonable name for the new registry?  See [RFC2434].  If the
      document describes an Expert Review process has Shepherd
      conferred with the Responsible Area Director so that the IESG
      can appoint the needed Expert during the IESG Evaluation?

      >> The IANA considerations section correctly reflects the one
      >> action required of IANA, which is to assign a Kerberos TCP
      >> extension number.
      >>
      >> This document also requires the assignment of a Kerberos
      >> Preauthentication Data Type number; however, that registry
      >> is currently controlled by the Kerberos working group and
      >> an appropriate number will be assigned before the document
      >> is published.  We hope soon to begin preparing a document
      >> which will turn this and several other Kerberos registries
      >> over to IANA.

(1.j)  Has the Document Shepherd verified that sections of the
      document that are written in a formal language, such as XML
      code, BNF rules, MIB definitions, etc., validate correctly in
      an automated checker?

      >> No part of this document is written in a formal language
      >> requiring such verification.  It does contain an ASN.1
      >> sequence definition which appears normatively in RFC4120
      >> and is copied in this document for clarity.

(1.k)  The IESG approval announcement includes a Document
      Announcement Write-Up.  Please provide such a Document
      Announcement Write-Up?  Recent examples can be found in the
      "Action" announcements for approved documents.  The approval
      announcement contains the following sections:


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.