2.6.7 Kerberos WG (krb-wg)

NOTE: This charter is a snapshot of the 63rd IETF Meeting in Paris, France. It may now be out-of-date.

Last Modified: 2005-07-08


Jeffrey Hutzelman <jhutz@cmu.edu>

Security Area Director(s):

Russ Housley <housley@vigilsec.com>
Sam Hartman <hartmans-ietf@mit.edu>

Security Area Advisor:

Sam Hartman <hartmans-ietf@mit.edu>

Mailing Lists:

General Discussion: ietf-krb-wg@anl.gov
To Subscribe: majordomo@anl.gov
In Body: subscribe ietf-krb-wg your_email_address
Archive: ftp://ftp.ietf.org/ietf-mail-archive/krb-wg/

Description of Working Group:

Kerberos over the years has been ported to virtually every operating
system. There are at least two open source versions, with numerous
commercial versions based on these and other proprietary
implementations. Kerberos evolution has continued over the years, and
interoperability has been problematic.  A number of draft proposals
have been issued concerning aspects of new or extended functionality.

The group will strive to improve the interoperability of these
systems while improving security.

Specifically, the Working Group will:

* Clarify and amplify the Kerberos specification (RFC 1510) to make
  interoperability problems encountered in the past that occurred
  because of unclear specifications do not happen again.  The output of
  this process should be suitable for Draft Standard status.

* Select from existing proposals on new or extended functionality those
  that will add significant value while improving interoperability and
  security, and publish these as one or more Proposed Standards.

Goals and Milestones:

Done  First meeting
Done  Submit the Kerberos Extensions document to the IESG for consideration as a Proposed standard.
Done  Complete first draft of Pre-auth Framework
Done  Complete first draft of Extensions
Done  Submit K5-GSS-V2 document to IESG for consideration as a Proposed Standard
Done  Last Call on OCSP for PKINIT
Mar 05  Consensus on direction for Change/Set password
Apr 05  Last Call on PKINIT
May 05  Enctype Negotiation to IESG
Jun 05  Major issues resolved on Extensions
Aug 05  Last Call on Extensions
Aug 05  Last Call on Referrals
Sep 05  Last Call on Change/Set password
Sep 05  Charter Review, update of milestones and refinement of goals.


  • draft-ietf-cat-kerberos-pk-init-27.txt
  • draft-ietf-krb-wg-kerberos-referrals-06.txt
  • draft-ietf-krb-wg-kerberos-set-passwd-03.txt
  • draft-ietf-krb-wg-ocsp-for-pkinit-06.txt
  • draft-zhu-kerb-enctype-nego-03.txt
  • draft-ietf-krb-wg-rfc1510ter-00.txt

    Request For Comments:

    RFC3961 Standard Encryption and Checksum Specifications for Kerberos 5
    RFC3962 Standard AES Encryption for Kerberos 5
    RFC4120 Standard The Kerberos Network Authentication Service (V5)
    RFC4121 Standard The Kerberos Version 5 Generic Security Service Application Program Interface (GSS-API) Mechanism: Version 2

    Current Meeting Report

    Kerberos Working Group - IETF 63 meeting summary
    • Agenda bashing - the KDC certificate naming issue was moved to the start of the agenda at the request of Russ Housley, so he could participate in that discussion and them move on to another meeting.

    • The chairs gave an update of the status of documents which have been sent to the IESG, and of ongoing work:
    • + Kerberos clarifications - published as RFC4120
      + The GSSAPI-CFX document - published as RFC4121
      + PKINIT - close to done; 2 issues will be discussed today
      + OCSP-for-PKINIT - done; will be ballotted with PKINIT
      + RFC1510ter - not much progress
      + Referrals - authors think it is nearly ready for WGLC
      + Enctype-Nego - needs updates from last call comments
      + Set/Change PW - author thinks last issue is resolved
    • There was a long discussion on ticket #837, related to identifying KDC certificates. We began with a review of the chair's message of July 18, 2005, which attempted to summarize the problem (Message-ID <Pine.LNX.4.33L.0507180825150.31583-100000@minbar.fac.cs.cmu.edu>)
    • >> Two questions to be answered.
      >> 1) Is cert appropriate for use by pkinit kdc?
      >> 2) Does the cert refer to the kdc for the realm we're talking to?
      >> Hum. This is the correct way to break down?
      >> many yes, none no.
      >> Required to implement means "every client must accept a certificate that
      >> contains the required mechanism".
      The sense of the room was that the email message correctly summarized the problem, and also correctly described what appears in pkinit-26 and -27.

      The current document specifies the use of the KerberosPrincipalName SAN with the principal name of the TGS (krbtgt/REALM@REALM) to identify a certificate for use with PKINIT and belonging to a particluar realm's KDC(s). The sense of the room was to keep this method and to keep it as the REQUIRED method for both usage and naming.

      The sense of the room was that no other naming methods needed to be specified, but that clients should be permitted to accept certificates with other names based on local policy (also permitted by -27).
      >> Russ Housley: how does the CA become authoritative about which entity
      >> is authoritative to act as the KDC?
      >> Take all of the IE browser trust anchors, if any of the trust anchors
      >> can be used to verify, then there is a problem.
      >> Stefan, Microsoft: Believes the Security Considerations text should be
      >> sufficient to deal with the problem.
      >> Russ agrees provided that the Security Considerations text specifies
      >> what happens if you get things wrong.
      >> We still don't know where the name is going to appear.
      >> There is no fundamental issue
      There was much contention on the issue of whether an EKU should be required when certificates are associated with a KDC by means of local policy, and, if not, whether it should be specified at all; this question remained unresolved.
      >> May the cert be used for pkinit, does it have the pksan, or the eku,
      >> or local policy?
      >> can we deploy with subjectAltName? If so, we don't need DNS name for
      >> validating KDC.
      >> Sam: many sites want to store hash or serial of client certs instead
      >> of subjectAltName.
      >> Karthik Jaganathan (JK): says Microsoft wants to be able to use hash
      >> or serial number but this is covered by the local policy statement.
      >> Typically not the case that the KDC CA is signed by a public CA.
      >> Jeffrey Hutzelman: how difficult is it for non-MS CAs to add obscure
      >> v3 extensions?
      >> Russ: all CAs have a mechanism. the worst one is pass in a hex string
      >> representing the extension. this is fine or one or two certs, it is
      >> really hard for client certs.
      >> Larry Zhu: its not clear what direction is.
      >> jhutz: the current document does not specify the use of dns name. I
      >> want to confirm whether we have consensus.
      >> jhutz; a client must determine that the cert is allowed to be used for
      >> a KDC, and that the cert belongs to the KDC.
      >> Sam: if there is going to be an EKU, implementation must be required.
      >> <scribe missed much of the discussion while fixing laptop>
      >> Sam: The DS bit does not distinguish whether the cert is allowed to be
      >> used for a web server or a kdc.
      >> Requiring the EKU is silly if it is not a required test. The required
      >> test is subjectAltName, then the EKU makes no sense.
      >> A specific EKU must be specified which we have not done.
      >> Stefan: you check to see if the EKU value is valid for a particular
      >> application. Hence "any" versus a specific oid.
      >> A SubjectAltName form that is specific to KDCs removes the need for an
      >> EKU.
      >> <not taking minutes of miscommunication about which certs we are
      >> discussing>
      >> Sam: RFC 3280 Section says that an application to require an
      >> EKU. Want the model Stefan is proposing.
      >> jhutz: There is a proposal to drop the EKU specification ...
      >> Nicolas Williams; (without mic) do we have consensus that the
      >> Stefan: if you have an EKU, ...
      >> jhutz: let's defer
      >> JK: is it any easier to implement the EKU than to implement the
      >> subjectAltName?
      >> Russ: no. if the eku is not known, the entire eku block must be
      >> manually encoded.
      >> Stefan: every service should have an EKU, but no one should be
      >> required to implement it
      >> Sam: its really bad to define an EKU and not mandate implementing it.
      >> you get into a situation where some clients that do not implement
      >> support get a bad
      >> Russ: support dropping eku. if subjectAltName is required to
      >> implement and must be the only one present. you only get into trouble
      >> if more than one name is present.
      >> if the cert with local policy allows acceptance of other names, then
      >> you must have an eku or something else to remove the ambiguity.
      >> Stefan: scratch previous comment. drop the eku
      >> Sam: propose require "subjectAltName id-pksan OR local policy plus
      >> EDU".
      >> Sam: What will microsoft support?
      >> JK: we are in favor of dropping the eku and adding appropriate
      >> security text.
      >> Sam: russ has convinced me that if there is going to be local policy
      >> then there must be something like an eku to remove ambiguity.
      >> Stefan: we cannot change the eku processing behavior described in
      >> 3280.
      >> Russ: objects to acceptance of "ANY". There is no way with "ANY" to
      >> determine whether or not the CA meant for the use of the cert with a
      >> KDC.
      >> We have rat-holed on this. Back to the list.
    • Andre Scedrov (UPenn) and Aaron Jaggard (Tulane) have been doing formal analysis of Kerberos protocols...
    • >> Formal verification of Kerberos basic and cross-realm pass validation.
      >> Great works guys!!!
      ... and gave a presentation on a problem they found in PKINIT in RSA mode. They described two approaches which they believe would fix the problem. One involves having the KDC sign the AS-REQ; the other involves having it sign the client's identity. The former approach is essentially what Larry has proposed in pkinit-27, and they believe that will fix the problem.

      After some discussion, there was general agreement that the approach taken by pkinit-27 was acceptable, and to a certain extent even preferred.
      >> Sam; authenticated clear-text. Its time for us to solve the
      >> authenticated clear-text problem.
      Love Hörnquist-Åstrand objected to the use of a keyed checksum which was sitting right along side its key (both in a structure signed by the KDC); Sam pointed out that the use of a keyed checksum allowed us to use RFC3961 cksumtypes, which essentially come only in keyed variants.

      It was pointed out that ASN.1 comments are not the best place to have the only copy of a normative requirement (wrt the client. The editor will fix this.
      >> Andrei: more wording needs to be added to -27 stating that the
      >> client MUST verify the checksum
    • Sam Hartman gave some brief comments on some assumptions currently made in Kerberos which he would like to see go away. Unfortunately, there was not time for significant discussion; we will likely see the full version of this presentation in Vancouver.
    • >> Sam: I think Kerberos is broken
      >> ... three assumptions may be wrong:
      >> whether this single principal identifier that never changes is what we
      >> want?
      >> if we add SAML, can principal name go away?
      >> destination's KDC is not involved in cross-realm, this has policy
      >> issues
      >> all of this is Extensions scoped work.
    • There will be an interim meeting September 19,20 at Microsoft for the purpose of doing work needed to advance RFC's 3961, 3962, and 4121 to draft standard. Further information is available online at http://dl.central.org/dl/ietf-krb-wg/200509/


    Unbinding AS-REP from AS-REQ in PKINIT
    PKINIT and Referrals
    Questioning Kerberos Assumptions