2.7.1 Interim Meeting - Kerberos WG (krb-wg)

NOTE: This charter is a snapshot of the 64th IETF Meeting in Vancouver, British Columbia Canada. It may now be out-of-date.
In addition to this official charter maintained by the IETF Secretariat, there is additional information about this working group on the Web at:

       Additional KRB-WG Web Page

Last Modified: 2005-10-03


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 2005  Consensus on direction for Change/Set password
Apr 2005  Last Call on PKINIT
May 2005  Enctype Negotiation to IESG
Jun 2005  Major issues resolved on Extensions
Aug 2005  Last Call on Extensions
Aug 2005  Last Call on Referrals
Sep 2005  Last Call on Change/Set password
Sep 2005  Charter Review, update of milestones and refinement of goals.


  • draft-ietf-cat-kerberos-pk-init-29.txt
  • draft-ietf-krb-wg-kerberos-referrals-06.txt
  • draft-ietf-krb-wg-kerberos-set-passwd-04.txt
  • draft-ietf-krb-wg-ocsp-for-pkinit-06.txt
  • draft-zhu-kerb-enctype-nego-04.txt
  • draft-ietf-krb-wg-rfc1510ter-02.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

    Interim Meeting Report

    Kerberos Working Group - September, 2005 Interim Meeting - Minutes

    Kerberos Working Group
    September, 2005 Interim Meeting


    Please note: These minutes are preliminary. Please send comments and corrections to Jeffrey Hutzlemna, <jhutz@cmu.edu>

    Chair Jeffrey Hutzelman
    ScribesJeffrey Altman, Dave Christiansen, Shawn Emery, Douglas Engert

    Note: due to the nature of the work being performed, large portions of this meeting were not logged in point-by-point detail, but were instead recorded in the form of spreadsheets representing feature matrices developed in the course of the meeting. While some were more active than others, everyone present at the meeting contributed at least once to that work.

    Day 1 - Morning

    • Blue sheets were passed around, albeit on green paper. (These were passed around at various points as people came in and out over the course of the 2-day session. A complete list of attendees is available in the online proceedings archive.)

    • The chair asked for scribes. Jeffrey Altman volunteered to scribe to Jabber for the first session, but indicated he was not willing to be the sole scribe for the 2-day meeting. Much of the contents of these minutes came from the logs of Jeff's Jabber scribing.

    • Some welcoming remarks were given by Klaus Schutz, Director of Development for Windows Security Access Control at Microsoft. Klaus gave us a brief presentation on Microsoft's position and future directions with respect to Kerberos.

    • There was a brief update on outstanding issues with PKINIT. There was no actual discussion of these issues, as PKINIT was not on the agenda for the interim meeting.

    • The agenda was bashed. Conclusion was that we would begin with a review of process requirements and other materials related to advancing specs through the standards process, then move on to spend the bulk of the meeting time on actually defining what data would need to be collected.

    --- Break ---

    • Sam Hartman gave an overview of what needed to be accomplished from a process point of view in order to advance a specification. Several conditions must be met:

      • Six months since RFC publication
      • Normative references must be at the same or higher level
      • Need to identify all of the features in the protocol, and show that for each mandatory and optional feature there are two interoperable implementations.

      Interoperability reports that have been filed for other protocols can be found at http://www.ietf.org/IESG/implementation.html. They vary quite widely in how detailed they are. One example of a protocol with a simple report is OTP. At the other end of the spectrum, draft-ietf-idr-bgp-implementation-02.txt is very complex.

      Other points:

      • We are not required to write new code to generate invalid input.
      • We are not validating compliance.
      • We are demonstrating interoperability between correct implementations.
    • There was general discussion over what level of detail would be needed in terms of protocol features.

      • Sam is concerned that people will go overboard in listing separate features for each individual protocol field.
      • For example, there should not be more than one feature for proxy tickets.
      • Nico asked where there were actually any uses of proxy tickets. We need to find some implementations or drop the feature before advancing.
      • It is unclear how to specify features for kcrypto. Do we list operations or enctypes? The matrix of both is too complex.
      • Jeffrey Hutzelman proposed that for the RFC3961 framework, it is sufficient to show that for each operation, there is some enctype for which there are interoperable implementations.
      • [someone] proposed that we not test interop of DES enctypes. Nico wanted to know if that would mean dropping them; jhutz thought yes. Sam proposed doing high-level testing of DES, and more detailed per-operation testing of RC4 and AES.
      • [someone] The Kerberos protocol alone is insufficient to demonstrate interop for RFC3961, because it does not use all the operations.
      • Ken Raeburn believes that some mixture of unit tests and protocol tests will be required.
      • Sam wonders if it is necessary to have two implementations which interoperate for all of the required features. It may be that we need to show two interoperable implementations for each feature, but that they don't have to be the _same_ implementations. We should write up holes, but their existence doesn't mean we cannot progress.
    • There was discussion on what process to use in constructing the list of features.

      • Jeffrey Hutzelman proposed listing all of the things which people think are features, and then reviewing the list to remove or combine items which are too fine-grained.
      • Sam suggested that we make sure we know what software can be used to test the proposed feature. If there is no software that can be used to perform a test, maybe it is not a feature. Or, maybe it is a feature that is unimplemented and we need to come up with an implemntation or drop the feature from the protocol.
    • Work proceeded on defining a feature matrix for RFC3961 and RFC3962, the Kerberos cryptographic framework and additional AES enctypes. The detailed discussion which went on during this process was not recorded, but its outcome was, in the form of a spreadsheet. The complete feature matrix spreadsheet is available in the online proceedings.

    Day 1 - Afternoon

    • As part of our implementation report for RFC3961, we need to note that rsa-md4-des-k, des-mac, and des-mac-k are considered HISTORIC and are documented for informational purposes only. So, we don't care if there are interoperable implementations for the purpose of progressing RFC3961 to Draft Standard.

    • After lunch, work proceeded on defining a feature matrix for RFC4120, the core Kerberos specification. As before, the detailed discussion was not recorded, but the results were. The second page of the feature matrix spreadsheet documents features for RFC4120.

    --- Break ---

    • Although server-side rejection of unrecognized authorization data is an implementation detail rather than a proper protocol feature, we are including itin the feature matrix because there are serious security issues if this is not done correctly.

    • There was some discussion about how to identify features for RFC4121. Sam proposes essentially going over all of the messages, examining the options for each message, and then considering corner cases.

    Day 2 - Morning

    • We started off by doing additional passes over RFC4120, doing things like looking for all occurrances of RFC2119 keywords in the document, to determine if they pertained to protocol features we missed. Mostly we found text describing features we already knew about, or behaviors that did not correspond to protocol features. However, we did find a few additional features, which were added to the spreadsheet.

    --- Break ---

    • After the morning break, we completed the work on developing a feature matrix for RFC4120. In total we identified at least 52 distinct features in the core Kerberos protocol.

    • David Christiansen gave a presentation on gssMonger, a tool for automating interoperability testing of Kerberos and GSS-API.

    Day 2 - Afternoon

    • The afternoon began with developing a feature matrix for RFC4121, the Kerberos GSS-API mechanism. Again, while the detailed discussion was not recorded directly, the work done was recorded in the form of a spreadsheet containing the feature matrix. The complete spreadsheet documenting the feature matrices for all three protocols is available in the proceedings.

    --- Break ---

    • With work on feature matrices complete, the remainder of the afternoon was spent discussing open issues on kerberos-extensions, also known as RFC1510ter. The majority of the discussion focused on the longstanding and contentious issue of exactly what form the ASN.1 definitions of the protocol messages should take.

    • More details to be filled in later; see the jabber logs.

    • David Christiansen produced a table documenting the positive and negative points raised for each of the possibile approaches. This table is available in the proceedings as a spreadsheet.

    Comments to <jhutz@cmu.edu> -- Last updated: 22-Oct-2005

    Kerberos Working Group
    September, 2005 Interim Meeting

    Attendee List

    • Jeffrey Altman, Secure Endpoints Inc.
    • Chris Crall, Microsoft
    • Iliano Cervesato
    • Ron Durbin, EMC
    • David Lawler Christiansen, Microsoft
    • Shawn M Emery, Sun Microsystems
    • Douglas E. Engert, Argonne National Laboratory
    • Mark Hanson, Microsoft
    • Sam Hartman, MIT
    • Love Hörnquist Åstrand, Stockholm University
    • Jeffrey Hutzelman, Carnegie Mellon University
    • Cristian Ilac, Microsoft
    • JK Jaganathan, Microsoft
    • Gopinathan Kannan, Microsoft
    • Tarek Kamel, Microsoft
    • Seema Malkani, Sun Microsystems
    • Liam Price, Microsoft
    • Ken Raeburn, MIT
    • Venkat Raghavan, Novell
    • Joe Salowey, Cisco
    • Klaus Shutz, Microsoft
    • Tom Yu, MIT
    • Larry Zhu, Microsoft

    Comments to <jhutz@cmu.edu> -- Last updated: 20-Sep-2005


    Introduction and Welcome
    Feature Matrix
    ASN.1 Type Syntax Evaluation