2.6.7 Kerberos WG (krb-wg)

NOTE: This charter is a snapshot of the 62nd IETF Meeting in Minneapolis, MN USA. It may now be out-of-date.

Last Modified: 2005-02-07


Jeffrey Hutzelman <jhutz@cmu.edu>

Security Area Director(s):

Russell 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
Nov 04  Last Call on OCSP for PKINIT
Nov 04  Last Call on PKINIT
Feb 05  Consensus on direction for Change/Set password
Mar 05  Major issues resolved on Extensions
Jun 05  Last Call on Extensions
Jun 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-25.txt
  • draft-ietf-krb-wg-kerberos-referrals-05.txt
  • draft-ietf-krb-wg-kerberos-clarifications-07.txt
  • draft-ietf-krb-wg-kerberos-set-passwd-03.txt
  • draft-ietf-krb-wg-gssapi-cfx-07.txt
  • draft-ietf-krb-wg-preauth-framework-02.txt
  • draft-ietf-krb-wg-ocsp-for-pkinit-04.txt
  • draft-ietf-krb-wg-sha1-00.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

    Current Meeting Report

    DRAFT Minutes for krb-wg at IETF62

    ** IETF 62 - Minneapolis, MN
    ** Kerberos Working Group
    ** Thu, March 10 - 09:00-11:30
    Chair: Jeffrey Hutzelman
    Scribe: Jeffrey Altman
    Jabber: Jeffrey Schiller, Sam Hartman, Brian Tung
    * Agenda:
      + Preliminaries - Jeffrey Hutzelman (5 min)
      + Document Status - Jeffrey Hutzelman (10 min)
      + Extensions - Tom Yu (15-60 min)
      + Referrals - Larry Zhu (10 min)
      + Enctype Negotiation - Larry Zhu (10 min)
      + Set/Change Password - Nico Williams (10 min)
      + Update Milestones - Chair and Participants (10 min)
    * Preliminaries - Jeffrey Hutzelman (5 min)
    reviewed agenda.
    * Document Status - Jeffrey Hutzelman (10 min)
    clarifications is still in the rfc editor queue
    just passed iana review stage.  iana now understands
    we are not creating registries yet.
    crypto 3961, aes 3962 published.
    much time spent reworking text.
    thank you Ken.
    cfx still in rfc editor queue
    ocsp draft is done.  is waiting for balloting of
    pkinit is still not done.
    no list of open issues to present.  the chair is
    tired of working on this draft.  chair will meet
    with lzhu later in the week to go over them
    russ says "just get it done!!!!" in a loud booming
    * Extensions - Tom Yu (15-60 min)
    Typed Hole Assignments.  Question:  Do we want to use
    relative or absolute OIDs?  absolute OIDs allow orgs
    to self assign.
    Nico asks: do we care about size?
    Sam says: make sure SMNP wants self assign.  We should
    also decide whether or not self assignment should be allowed.
    If we required standards action, there is no reason to allow
    Tom: is authorizationData special with regards to type numbers?
    Cliff: AuthData should not be special.  Private uses should
    not be allowed.
    Sam: Constraint restrictions which have conflicts in AuthData might be dangerous.
    Tom: are there any registries we want to maintain outside of IANA?
    Kurt: you must use IANA for registry data so they can be used for lookups.
    Tom: do the Application Tags need to be registered?
    Sam, Nico: No.
    Tom: Transited realms in tickets have open questions.  We could delay standards action on this item to delay addressing them.
    Tom:  Do we want to put requirements on the use of String Types in new PDUs?
    TicketExt and other new extensions ...
    jaltman: yes, it would be a good idea to use UTF8 only in new types (if possible)
    Sam: not worth doing if it is going to make the ASN.1 more complicated
    Tom: readability issues:
    do we want to use a common string type for both 1510 style and extension
    do we want to have constraints in text or asn.1?
    Love: don't like when there are constraints in the ASN.1 which are not enforceable are useless if they don't help the human.
    Tom: we need to think about a good middleground.  more time necessary
    Sam: do we have timelines?
    Chair: later
    Tom: do we want to drop "advisory parameters"?  they are for human parsing but do not affect machine parsing.  They tie various ASN.1 PDUs
    together.  1510 there are no parameters but we must remember to be
    explicit in text about how the
    Nico: we can also put the details into the ASN.1 module as comments
    instead of syntax the parser will process and then ignore.  I would
    like there to be something in the module.
    Sam: EncryptedData is one of the best uses of Parameterized Data we
    have.  Helped debugging broken implementations.
    Tom: "Signed" parameterized type is crucial.
    Nico: if we are going to have any parameterized types, keep using parameters with EncryptedData
    Tom:  discusses differences between old and new formats
    Some people say it is difficult to read.  Changed String types
    into parameterized types.  This allows the use of simply CHOICE.
    Another alternative is to not use derived types for the two ticket formats.  There is a risk of deviation (human error) between the two types.
    Russ: believes the derived version will lead to less human error and
    the other version is more readable for asn.1 and kerberos novices
    Sam: Boulder consensus says we must have a version of this which does
    not use any of the complex asn.1 type extensions.  we must be able to
    strip out to ASN.1 with CHOICE.  SignedType is a parameterized type
    which will require stripping.
    Bill: both have human errors.  there are more implementors than designers.
    Nico: Shared encoders/decoders produce fewer errors.
    Tom: Do we have consensus on the use of shared code paths?  Unknown.
    Tom: I'm not familiar with asn.1 toolkits which will produced shared
    code paths from derived types.  does anyone have experience?
    Russ: PKIX/SMIME decided to stick to a subset of ASN.1 available in
    publicly available tools.  This has caused problems with ITU.T since
    we are stuck using a deprecated syntax.  All of the base X.509 types
    had to expand all of the macros because the tools did not handle them.
    I check every draft with gnu asnpp.  Drafts which do not pass will be
    sent back.  I recommend restricting to the use of ASN.1 for which free
    tools are available.
    Tom: to improve readablity we can decrease the inlining the invocations
    of parameterized types.  There is some desire to do this by the meeting
    Sam: the parameters could be stripped to make the code more readable
    for those who wish without affecting the validity of the asn.1.
    Tom: need to clarify capability negotiation; resolve iana policies; and
    continue working on the asn.1 modules
    Nico: Transitive Encoding.  This is a hard problem.  What was the
    resolution?  Do we want to stop the compression thing and how do we
    deal with intermediate realms which do not process UTF-8?
    Tom: tentative conclusion if we require realm administrators be aware
    of and configure into their KDCs which realms support extensions.
    Nico: this is already done.  In order to issue the cross realm principal
    you must know that the service supports extensions or not.  The question is whether we want to allow ext->ext->1510 if there are utf8 in the name?
    jaltman: I would like to speak with Ken H. and Doug about deployment issues.  I am concerned about upgrade paths.
    Nico: ext->ext->1510 should be ok provided the path can be represented in 1510
    jaltman: there may be other paths to deal with
    Chair:  would like to come out of this discussion with some decisions.
    Tom: there is a desire for human readability
    Chair: Lets produce a set of tickets in RT for Extensions related issues
    Sam: please set timelines for major issues such as the ASN.1 Feature Set issue.
    Chair: we will defer discussing milestones until the end of the meeting
    Sam: There is a IAB expired draft discussing "vendor extensions".  The SIP community feels they got pretty burned and don't want "vendor extensions".  They want "standards action".  I think we are pretty similar to SIP but we want to be open.
    Chair: I believe there is a distinction between "vendor" and "site specific" extensions.
    Sam: Checksum -138 for example.
    Chair: DHCP site local options have also been abused.  There are multiple questions here.  AuthData types cannot be negative.  There are
    no private use extensions.  Do we want to continue this?  Do we want to
    add private use extensions (neg numbers) to newly typed holes?
    Chair: Does the use of private use numbers depend on the assignment policy for non-private numbers?
    Sam (no AD):
    Chair: How many people think we need to address the assignment policy issue before the private use policy?
       3 not dependent; 3 dependent
    jis: questions are linked but the order is not specific
    Chair: can we acheive consensus on this here?
       doesn't look like there is; taking it to the mailing list
    Luke (via Jabber): what is the existing policy regarding the use of positive numbers for pre-auth types.
    Chair: talk to Cliff; he coordinates the issuing of the numbers.
    for negative numbers, no auth data and for other stuff use them only
    within your site.
    Chair: RFC 3961 specifies IANA registration for its types
    Tom: there is a good general direction in the form of the ASN.1 but
    we need a bit more discussion for fine tuning.
    Chair: Tom will produce a list of issues
    Chair: Next is Larry on Referrals (no slides)
    * Referrals - Larry Zhu (10 min)
    Larry: No updates since the last meeting on the Referrals draft.
    The draft must be updated to include the Microsoft UPN use in
    Smart Cards.  This text was originally proposed for PKINIT and
    pulled out.
    Chair: Next is Larry on his proposal for Enctype Negotiation.
    Please hold questions until the end.
    * Enctype Negotiation - Larry Zhu (10 min)
    Larry: new draft-zhu-kerb-enctype-nego-00
    Allow client and server to negotiate enctypes without using the
    KDC.  It has been implemented and shipped in Longhorn Beta 1.
    Luke Howard implemented a version for Heimdal / XAD
    Larry: in the u2u scenario the server principal can move from machine
    to machine with different enctypes.  Updating the AD entry with the
    current support is too expensive.
    L: Client will send an ordered list of enctypes in the authorization-data in the AP-REQ: AD-ETYPE-NEGOTIATION.  This would be marked IF-RELEVANT.
    L: The server would select an enctype supported by the client and the server.  The chosen enctype is then sent in the subkey field of the AP-REP.
    L: Questions?
    Sam: only use this in protocol environments in which server subkey wins
    such as GSS CFX.  you might want to give a bit more non-normative advice
    on how the key is generated.  doing so might waste a lot of time since it is non-normative.
    L: will recommend that the entropy in the session key be taken advantage of.
    Nico: we all agree this doesn't break anything.  Its not bad.  If it is
    only going to be useful to GSS CFX how it is going to be accessed?  Will
    this be exposed though GSS QoP?  Will this use be determined by client side policy?
    Sam: Always use it if you are CFX and the client supports it, use it. Some people might complain if you send an AES key protected by a DES key.  However, similar complaints are implementation policy not user
    Sam: negotiating AES will affect the token type used by CFX.
    Chair: negotiation is safe to use in any situation in which server asserted subkeys will win.  This is true for GSS CFX and perhaps other
    application protocols.
    L: I will work on some text.  Do we want this to be a working group item?
    Chair: asking the question. personal opinion this is little reason not to.
    Sam: who would find this useful?
    Chair: 12 hours before the first posting to the list in a private conversation we came to the conclusion that this functionality is required.
       useful: 1/3,  harmful: none. don't care: some
    Matt Peterson: is there a reply attack possible by resending IF-RELEVANT
    L: if you don't have a replay cache, you have a more serious problem then a downgrade attack.
    Chair: this is auth-data in an AP-REQ.  It is encrypted and integrity protected.  Therefore, you can reply an authenticator but not simply the auth-data field.  There is no problem.
    Sam: make sure it fits the charter.  if so, yes it should be a standards track item.
    Chair: do people think for this work to proceed along the standards track?
       yes: many   no: none
    Chair: do we want this to be a working group item?
       yes: some   no: none
    Chair: no new draft name required.  Next is Nico
    * Set/Change Password - Nico Williams (10 min)
    There was a milestone a few weeks back to determine if we are going in the right direction.
    Chair: How many have read the document in the last six months?
        9 (2 via jabber)
    Chair: How many think we are going in the right direction?
        yes: 6    no: 0
    Chair: seems like yes
    Luke (via Jabber): it seems quite complicated
    Nico: I need more specific suggestions.  I believe errors handling is complicated.
    Leif: localization is too hard.
    Nico: In order to extend password policies we need to be able to extend
    error strings so the human can see what needs to be changed.  The server
    is the only entity that can do this.
    Sam: Human readable strings are required for password setting errors.
    JHutz: I want to be able to set a local policy and be able to tell the
    users why my local policy failed.
    L: microsoft will have a hard time implementing this protocol because
    the windows has a fixed string catalog.  is this the direction of the
    IETF in the future?
    Sam: rephrasing "Kerberos error codes are not currently meant for users therefore they are not shown to the user and local interpretation is performed.  This will require changes to the error handling system?"
    L: I am against server side localization
    Sam: we could send multiple error codes to the clients.  The client might only know a general
       password rejected
       password rejected for policy reason
    this requires the distribution of org modified versions to understand local policy errors; instead of using server side localized strings
    jaltman: I object strongly to anything that encourages locally modified
    versions of my kerberos distribution by organizations.
    Sam: I believe the ordered error code approach could meet the needs
    of 90%
    Leif: as an operator of a semi-large site.  middleware diagnostics.
    help desks need to strip data from syslogs to help users.  this is
    a drop in the bucket.
    jaltman: we want users to change passwords, we need to make it easy
    for them.  calling help desks are not always possible.
    jhutz: we could use parameterized error codes
    ???: this would be the worst of both worlds
    L: two other comments
    there is both a protocol version and an extensibility marker.
    can there be a per message version number instead of a protocol
    version number?  This would allow backporting of one specific
    feature instead of backporting the entire set of updates to the
    Nico: it is possible to say my version is Y but these features
    are not supported.
    L: it is not clear that the protocol is not easy to implement
    because the password server must be tracked by the server.
    Nico: the principal name is the handle.  In a delayed commitment,
    the state is stored on the server.  If a delayed commit is in
    progress the server can report "delayed commit in progress"
    for the purpose of avoiding race conditions.
    Jhutz:  describes race conditions with multiple clients.
    no worse then multiple clients changing passwords without delayed
    L: is there an implicit assumption that all keys with have the
    same kvno?
    Can the client set keys for different enctypes?
    jhutz: you must set all of the enctypes for a principal at once.
    L: could you put back the ASCII art?  I find this helpful.
    Nico: this brings us back to the questions of framing and port
    Nico: a single principal is supported across an entire cluster
    with failover.
    Jhutz: think the zephyr service key
    Leif: this must happen for multiple clients at once?
    jhutz: we must be able to generate a key, distribute the key to all
    of the service's servers and only then allow the key to be used.
    Chair: Time to discuss Milestones
    * Update Milestones - Chair and Participants (10 min)
    November deadlines OCSP and PKINIT were missed.
    Larry: can we shoot for a WGLC in a month?
    We lack opinions because people have stopped reading the draft.
    Chair: two concerns.  (1) editors have made changes without there
    being consensus reached on the list; (2) creeping featurism.
    If we want to last call the document, it has to stand still for
    a while
    Love: There is signs of optimism.  There is a need for change
    to the protocol to fix things which are broken.
    jaltman: give people time after proposing things in order to
    allow people time to catch up.
    Chair: there is a controvertial issue related to the mechanism
    by which a certificate can be determined to actually be from
    the KDC.
    L: we will have a proposal sent to the mailing list within a week.
    Chair: suggesting April 05
    Sam: remember SASL will be reviewed at that time
    Chair: April 05 for Last Call on PKINIT
    March 05 for Consensus direction of Change/Set Password
    June 05 for resolving Major Issues; August for Last call of Extensions
    Last Call for Referrals in August 05
    Add milestone for Larry's EncNegot draft: to IESG in May 05
    Leaving Change/Set Password Last Call in Sept 05


    Update on Kerberos Extensibility