Current Meeting Report

2.5.5 Kerberos WG (krb-wg)

NOTE: This charter is a snapshot of the 52nd IETF Meeting in Salt Lake City, Utah USA. It may now be out-of-date. Last Modified: 24-Oct-01
Douglas Engert <>
Security Area Director(s):
Jeffrey Schiller <>
Marcus Leech <>
Security Area Advisor:
Jeffrey Schiller <>
Mailing Lists:
To Subscribe:
In Body: subscribe ietf-krb-wg your_email_address
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 sure 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.
No Request For Comments

Current Meeting Report

Notes for Kerberos WG meeting for IETF 52 on 12/13/01

(Submitted by Doug Engert chairman, with Ken Hornstein as scribe)

Chair Doug Engert starts out the session with traditional agenda bashing, and emphasizes the number one WG item is to get out kerberos-revisions. The desire is to get out the revisions document by March, and that may require an interim meeting between now and March (possibly at MIT).

Cliff Neuman starts first agenda item by restating the issues with the current revisions document.

Current issues:

- Remaining issues regarding Section 5 & 6
- Changes pending regarding authorization data.
- UTF-8 still very contentious.
- Other document changes depending on output of Section 5 & 6

Authorization data:

- Criticality - should default case for unknown AD elements be deny or ignore?
Almost have consensus on this issue.

Cliff suggests the following things to make progress:

- Have a discussion to settle extensibility
- Resolve UTF-8
- Break out section 6 into it's own document

The comment was made from the audience that interoperability was a concern; Cliff deferred that to the section 5 discussion.

Ken Raeburn took the floor about section 6. Ken's points were that it's not quite related to the protocol document, it's relatively modular, and it can possibly move faster and be reviewed easier. The only open issue left in section 6 left is related to how to mix encryption keys coming from pre authentication mechanisms.

John Brezak asks how will mandatory-to-implement be defined if Section 6 is split out. Ken & Cliff say that the list of mandatory-to-implement algorithms should stay in revisions (Ken also points out that other things in Section 6 like key usage numbers also are going to be split out). Consensus of the room is that it's okay to split out the document.

New text will also be added to section 6 explaining what is required for new crypt systems, and also the parts of the Kerberos cryptosystems that should be used by applications.

Ken said that modulo a few issues, AES may be done early enough that it may be folded into section 6 (but no guarantees).

Another outstanding issue is specification of string2key algorithms. A change will be required to the string2key specification to allow the addition of an argument that the KDC can return to via a preauth mechanism with allows the addition of an iteration count for PKCS #5, or other such things.

John Brezak asked if it's worth keeping around the older DES enctypes and maybe it was worth it to put them in a separate document. Jeff Huztlmen points out that these are still required for interoperability, and you could split them out, but they would still have to advance with the original.

Nico Williams asked about encoding pass phrases; Ken pointed out that these are still tied up in string2key issues and unresolved UTF-8 issues; the real problem lies in that the encoding of the string has to be consistent independent of the encryption type. Further discussion was deferred until after the main UTF-8 discussion.

Sam Hartman was up next leading the extensibility discussion. In London the proposal was floated to use ASN.1 extensibility markers in Kerberos messages. Sufficient interest was expressed, so that was explored since then.

Arguments for extensibility were presented: Vendors require extensibility because they need to extend the protocol to match their schedules. But the extensions need to be interoperable between vendors.

Protocols also need to be extensible within the IETF; history has shown that protocols need to evolve over time.

Two mechanisms are needed to support extensibility: the ability to add fields to core protocol messages, and the ability to do a phased upgrade that do not break older implement ions.

So how does Kerberos 5 do with extensibility? A number of proposals have been suggested:

- Crypto negotiation. Now mostly works reasonably well.
- All others - none work in an interoperable manner!

Common problems with extensions:

- Most proposals misuse ASN.1. It's not possible to simply add fields to ASN.1 messages without breaking older implementations.
- A lot of time was spent trying to avoid negotiation. Because of this, clients cannot tell what extensions they want to use are supported.
- Extensions have been considered one-at-a-time; didn't take advantage of common elements.

So why was negotiation avoided?

- Adds complexity
- Adds round trips
- Harder in Kerberos than other protocols: KDC has to know the capabilities of the server.

So, what do we do for a solution?

- Storing a single bit of state on the KDC to facilitate general negotiation is reasonable (even if a bit for every option is not)
- Spend more time reviewing ASN.1
- Abstract out common elements (cleartext authentication)

Goals of our solution:

- Provide IETF with a mechanism for protocol evolution.
- Provide vendors with hooks to extend the protocol in interoperable ways
- Solve authenticated cleartext.

Add ASN.1 extensions markers to most Kerberos messages:

- Will allow implementations to drop fields they don't understand

Use Typed Holes for Vendor Extensions

- typed holes are sub-strings in the message along with an octet that define how the string is interpreted.

Protect cleartext with signed type.

- Messages containing cleartext fields have been wrapped in types containing keyed checksums.
- Guidelines clearly specify where to use them.

Obey the Golden Rule: Be liberal in what you accept and conservative in what you send. ONLY send messages to servers that you know accept it.

- If you've received a new-format message then you can send new-format messages.

- The ticket type can tell the client about server capabilities.

- For bootstrapping, a new AS-REQ can be included in an old AS-REQ.

Ken Hornstein points out that pre configuration might be useful; Sam replies that pre configuration isn't encouraged, but should be allowed by the current specification.

John Brezak points out that it's possible to come up with a scheme where if preauth is required, one of the preauth types can be "send me new messages".

Doug asked about cross-realm and transitive; Sam said that cross-realm just falls out because the TGS is just another service. transitive is harder and still needs some work.

Nico Williams asked about using UTF-8 and old servers/new clients and vice versa. Sam asked to defer that discussion, but pointed out the thrust of the proposal is to make sure everything you're doing now still works.

John Brezak expresses concerns about the economic impact of implementing what is essentially a new protocol. Jeff Hutzlman replied that we're trying to solve the problem we had with Kerberos 4.

The general consensus of the room is that extensibility is a must; a majority of people felt that the proposed extensibility is heading in the right direction; a few people expressed concerns about the extensibility, and Sam asked them to present their concerns ASAP.

Cliff said that authorization-data had been adequately covered in extensibility, so he felt it was important to move the discussion to UTF-8.

Jeff Altman led the UTF-8 discussion.

Short background - at the Pittsburgh IETF we discovered that strings are encoded in ASN.1 GeneralString, which are restricted to a subset of code pages in ISO-2022 (G0 code page). When ISO-2022 escapes are NOT used, the character sets are restricted to IA5. But generally GeneralString is treated as an octet string and the local character set is just copied into the GeneralString, which leads to interoperability problems.

With the current plan, there will be three versions of Kerberos floating around:

- RFC 1510
- Revsions-based Kerberos (extensibility)
- IDN Unicode encoded as UTF8, which is not compatible with anything currently being used.

Is interoperability between different versions important? If so, some character set tagging will likely be required.

Possible solutions:

- Put in multiple encodings into messages
- Do additional round trips for negotiation.

John Brezak points out that we've been focused on principal names, but strings are littered all over the protocol and we need to be careful with how we deal with I18N issues for those other fields.

Jeff Hutzelman points out that it's very important to use the same normalization rules as used for DNS for realms and principals, because those are used for entries in the KDC, and you'll likely lose if they don't match. The same goes for all usernames as well; a uniform normalization rule is required across all clients.

John Brezak spoke up and said that he can't see people using ISO-2022 escapes in GeneralString, and we should go to UTF-8 regardless of DNS stuff. Jeff Altman points out that his proposal is to use the CHOICE tag for new messages specifying different string types, and try to guess for RFC1510 clients.

Brian Tung was up next regarding PKINIT.

Quick run-through on changes for v15:

- Defined DER-based order for RDNs in X.500-to-principal name conversion (conversion is non-invertible)
- Explained why RFC1510bis style X.500 realm names aren't used.
- Removed reference to RFC1510bis w.r.t. KerberosName
- Clarified that pachecksum is not keyed (specified type)
- Corrected former inconsistency with DH param encoding.
- Trimmed Security Issues to PKINIT-specific issues only.

Remaining Issues:

- Add RSA (both client & server MUST)
- Francios Lecerc pointed out that RSA is no longer encumbered.
- DSA has some theoretical vulnerabilities
- Proposed change: Add to Section 3.2.4.
- Also proposed DSA changed to server MUST, client MAY

Consensus of the group is to change require algorithm from DSA to RSA

Mike Thomas pointed out that Kerberos lacks a return routability test, and can force a KDC to do a bunch of unnecessary public key operations. No one has a solution, though. Text will be added to security considerations pointing this out.

Pat Moore was up next talking about GSS U2U.

This was to cover a draft that has been around for a while for doing U2U within the context of the GSSAPI to support talking to back-end supercomputer resources.

The draft was originally written by Mike Swift, and Pat Moore & John Brezak revived it after it expired. This is the basis for the Microsoft implementation.

The Swift draft introduced two new message types - KRB_TGT_REQ, and KRB_TGT_REP (which are NOT Kerberos messages). It also introduced a few new error message (see presentation).

The Sandia implementation allows for a new error message: KDC_ERR_MUST_USE_USER2USER. This tells a client that only user2user can be used for this principal. This generated a fair amount of controversy; discussion likely to continue on the list.

John Brezak spoke briefly about the Referrals draft; just asked for comments on it.

Matt Crawford spoke briefly about the passwordless authentication draft; said it was basically ready for last-call, but others wanted to get it deferred until after revisions; consensus was to delay last-call on that document.

Leif (?) had spoke to Donna Skibbie about the KDC-schema draft; she planned on revising it. Doug suggested talking to her and seeing what her current status was of the document.

Doug Engert then closed the meeting.


User to User Authentication in GSSAPI
Kerberos Revisions
Extensibility in the Kerberos Protocol