2.6.3 Kerberos WG (krb-wg)

Last Modified: 2003-05-30

Douglas Engert <deengert@anl.gov>
Security Area Director(s):
Russell Housley <housley@vigilsec.com>
Steven Bellovin <smb@research.att.com>
Security Area Advisor:
Russell Housley <housley@vigilsec.com>
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
Dec 00  Submit the Kerberos Extensions document to the IESG for consideration as a Proposed standard.
Dec 00  Charter Review, update of milestones and refinement of goals.
Jan 01  Submit the PKINIT document to the IESG for consideration as a Proposed Standard.
Mar 01  Charter Review, update of milestones and refinement of goals.
  • - draft-ietf-cat-iakerb-09.txt
  • - draft-ietf-cat-kerberos-set-passwd-06.txt
  • - draft-ietf-krb-wg-hw-auth-02.txt
  • - draft-ietf-krb-wg-crypto-05.txt
  • - draft-ietf-krb-wg-kerberos-clarifications-04.txt
  • - draft-ietf-krb-wg-utf8-profile-01.txt
  • - draft-ietf-krb-wg-kerberos-sam-01.txt
  • - draft-ietf-krb-wg-kerberos-set-passwd-00.txt
  • - draft-ietf-krb-wg-gss-crypto-00.txt
  • No Request For Comments

    Current Meeting Report

    Kerberos WG  (krb-wg) 
    Tuesday,  July 15, 2003
    1700-1800 Afternoon Sessions IV
    Acting CHAIR: Ken Hornstein  (Doug Engert can not attend) 
    Scribe: Luke Howard
      Introduction, agenda bashing
    Ken introduced himself. No comments on the agenda.
      Living life in a Post-Clarifications World
    Noted that documents have gone to last call; believe that all comments were 
    syntax or wording issues that can be fixed by the author re-edits. No 
    further comments.
      Extra TGT draft
    The extra TGT draft is designed to use the host key to give you 
    stronger preauthentication to avoid exposure to weak passwords that 
    Kerberos has always has. The major problem has always been how it 
    combined keys and used Kerberos cryptography. The crypto framework now has 
    the necessary primitives for doing this in a clean way, although without a 
    combine keys function. Sam noted that he has done the work on a combine 
    keys function that is sufficiently obvious and has sought review, and will 
    supply the necessary text to Jonathan Trostle for inclusion. Suggest that it 
    could last call by Minneapolis.
    There was another proposal from Jacques re: anonymous DH for 
    pre-authentication, no response from Jacques regarding its status.
    Packet Cable have expressed (privately) interest in this. Noted that 
    PKCROSS was deferred due to its dependence on ticket extensions. Both 
    drafts have expired to Ken's knowledge.
    At the last IETF there was a large discussion about mapping realms (in?) 
    certificates to Kerberos names; questions about clarity. The technical 
    issues that remain are "fairly simple" (Sam's words), but someone needs to 
    discuss with Tom Yu the encoding of distinguished names in Kerberos 
    principals. This needs to be investigated. Similarly the X.509 to 
    Kerberos name mapping has some outstanding issues (not 
    The assumption that any published standard will be compatible with 
    deployed implementations (eg. Windows 2000) may unfortunately be 
    Some discussion on whether we need new editors for the document; depends on 
    the degree of interest from the working group.
    Comments from Jean-Francois Mule, Director of PacketCable 
    Cable Television Laboratories (CableLabs) is an organisation that 
    manages specifications along with vendors. It does not create specs on its 
    own. They are definitely interested in both PKINIT and PKCROSS. 
    Understanding is that they are not that far from the current drafts and are 
    willing to commit resources to moving these things forward. Moved to 
    discuss this after meeting.
    Sam: it might be possible for PC to do an informational RFC 
    describing what they have done (notwithstanding the need for a 
    standards track RFC); noted, again, that PKCROSS is blocked on Kerberos 
    extensions. Working group is likely to object to any standards track 
    document that describes doing things that are a violation of the 
    Kerberos specification as it stands and would lead to 
    interoperability problems. 
    Ken: background regarding extending ASN.1 types in an 
    interoperable manner. Extensions are the next major work item but no 
    timeline, "active participants want it to see it progress rapidly".
    Jean-Francois: concern is that they do not wish to promulgate 
    non-standard implementations but timelines may force otherwise. ITU-T 
    study group 9 has a specification that has been consented but cannot 
    progress to the next step until it can normatively reference an 
    information track (?) RFC.
    Jeffrey: noted that PacketCable require an extension that would break 
    backwards compatability, and that this is a difficult situation with 
    respect to timelines; conversely, doesn't see that there is a lot that can be 
    done to make this happen faster.
    Jean-Francois: not asking for faster as much as a timeline, so that 
    vendors and service providers can be provided with an answer.
    Sam: PacketCable has the opportunity to deploy an implementation that 
    long-term is interoperable with existing (non-standard) and future 
    (extensions) clients. Issues are: encoding of extensions and writing 
    texts, so it is reasonable to expect that within a year they may be sent to 
    the IESG (assuming the current degree of focus within the working group is 
    Proposed timeline: end of July 2004 for IESG. 
    It was noted that only PKCROSS was being held up by the extensions 
    document; all PKINIT needed was an editor willing to do the work. 
    Jean-Francois said that CableLabs was willing to provide resources to make 
    PKINIT happen.
    Jean-Francois suggested they would be willing to host an interim 
    meeting.  Some discussion regarding interim meeting ensued.
    Question from Jean-Francois: what's the likelihood of the IESG 
    accepting an information draft describing their existing use. Steve noted 
    that the IESG will not accept an individual submission that looks like an 
    "end-run" around the working group; the working group has veto power over 
    individual drafts in its space, and the working group would be likely to 
    approve this given the acknowledged issues re: extensions. Steve noted that 
    it would "take a good description, possibily in the document or in a 
    submission from me to say why this is being done this way... eg. 'we will 
    issue a standards track document when it is possible'".
    Jean-Francois noted two separate issues:
            - documenting what they are doing
            - request for I-D to reference in ITU-T; hence 
    informational RFC would be useful
    Much discussion on whether an information RFC would actually be useful or 
    Question on whether it would be possible to advance PKCROSS without 
    extensions. Working group has decided against this because of the 
    present lack of extensibility mechanisms in the Kerberos protocol.
    Some discussion on whether an issue tracking system would be useful.
      Password change protocol
    Much discussion recently on this document; sounds like that it is 
    "progressing quite nicely".
      Kerberos/GSSAPI authentication in SAML
    Tim Alsop of Cybersafe UK. 
    Wanted to gauge interest in SAML working with Kerberos. SAML is a 
    standard that is part of the many web services standards, and there is some 
    discussion on how it may be used with Kerberos.
    Luke: does this interact with WS-Security? Agreed that WS-Security is 
    hopelessly underspecified particularly with respect to Kerberos.
    Bob Morgan: noted his involvement with SAML, OASIS. WS-Security is 
    "almost done" (did I understand that correctly?) and specifies 
    interaction with X.509 and Kerberos. Some people have been discussing how 
    SAML assertions might be used in a SASL context.
    Tim noted that there are multiple ways in which SAML could be used. Some 
    question on whether OASIS or this working group was the appropriate 
    forum. IETF might be, but not this working group.
    Bob noted some movement regarding SASL referencing SAML, out of scope for 
    krb-wg. Head nodding from Jeff Hodges.
    Wyllys Ingersoll: question about cat-wg. Defer to list.
    Matt Crawford cannot be here; skipped due to time constraints.
      Kerberos KDC LDAP schema
    Focus has changed to using LDAP as an admin protocol rather than storing 
    Kerberos keys in LDAP. Leif Johannson noted that the current issue is 
    describing the information model; the schema will come later. There will be a 
    meeting after this meeting.
    Many things (like ticket extensions) were deferred until extensions.
    The next thing to do is: "charge ahead". No-one disagreed.
      Do we need an interim meeting?
    Resounding consensus is that we do need an interim meeting; 
    when/where should be deferred to the mailing list.
      Open discussion


    None received.