Current Meeting Report

2.5.4 Kerberos WG (krb-wg)

NOTE: This charter is a snapshot of the 53rd IETF Meeting in Minneapolis, MN USA. It may now be out-of-date. Last Modified: 30-Jan-02
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

Kerberos WG (krb-wg) 53rd IETF, 3/19/02

Doug Engert opened the meeting with a review of the agenda. There where about 116 people attending.

Ken Hornstein volunteered to take note. [These minutes are substantial his notes. Thanks Ken.]

First item up is Jeff Hutzelman's report of the Kerberos interim WG meeting.
Meeting was Feb 12-13th, had 10 attendees.

Discussions at interim meeting:

- Many desired changes (some conflicting)

Essential items for the next document:

- RFC1510 compatibility (didn't want a new protocol)
- Clarifications to RFC 1510 (name types, KDC replay cache, implementation notes)
- Modern crypto architecture, developed by Ken Raeburn.
- How to find a KDC (important, not covered in RFC 1510)
- New network address types
- TCP exchanged with KDC

The basic problem: Conflicting requirements

- Clarifications to RFC 1510 badly needed
- WG wanted extensibility
- IESG mandate for internationalization
- WG wanted various new features

Solutions: Two documents (_neither_ named revisions)

- Kerberos clarifications
Clarify and cleanup RFC1510
a few new critical features
minimal impact on implementors

- Kerberos extensions
Complete Extensibility

Kerberos Clarifications

- Goals:
Must be compatible with RFC 1510 and existing implementations
Minimize implementation & testing cost

- Document cleanup
Section with combined ASN.1 encoding
KDB description dropped (not appropriate for specification)
Pseudo-code dropped (implementation specific, did not match spec)

- Clarifications
Name types are _advisory_
KDC replay cache behavior - need to clarify exactly when same text was to be returned and when to return error.
Implementation notes (document "weird" behavior)
Others (such as criticality of PA data)

New items -- many from previous kerberos-revisions
- Modern crypto (will remain separate document)
- How to find a KDC (will remain separate document)
- TCP support (who needs to do what, when)
- Network address types (IPv6, any others?)
- Dealing with client time skew
- Kept transited-check and ok-as-delegate ticket flags

- Update the MUST-implement requirements

-- Kerberos Extensions

(Still) must be compatible with RFC 1510
Usage similar (but doesn't have to be the same) message formats as RFC1510

IESG mandate for I18N.
IESG mandate for UTF-8 encoding as a minimum.
Support for UTF-8 in principals, realms, passwords.
Migration for old just-send-8

Future enhancements:
Ability to enhance/evolve protocol (experience shows that protocols are rarely static)
Support for adding IETF and vendor extensions.
Ticket Extensions
Make PK* and other WG items possible.
Enabling tying tickets to hosts/location/whatever.

New Items:
AES (should it remain separate document or get folded into the crypto document)
Request for new name types (SMTP name type)
Remove address dependencies
Cross-realm referrals a good idea.
Client name canonicalization is also a good idea.
Fix EDATA brokenness (field contains different things depending on what the error is)
Name space restrictions (Microsoft)

Update MUST-implement requirements

Authenticated cleartext? (Not yet achieved consensus on this issue).

-- Additional Work Not Appropriate for Revisions (most are enabled by extensibility document)

- Protect AS_REQ exchange against weak passwords.

- PFS for KDC exchanges

- PFS for application exchanges

- Minor error codes (better error text?)

- Key exchange without authentication (how did it relate to anonymous?)

- Timestamp-independence (right now we have places where time stamps are in the protocol that makes things not work if clocks are skewed; should that be fixed?)


Cliff Neuman was up next with a status report of new documents:

- Decided to separate issues into clarifications & extensions documents (See above)

- Goal is to settle clarifications quickly and to move in parallel on extensions (will _not_ stop at clarifications).


- New draft announced & discussed on list; several changes already been suggested.
- Significant changes
- Section 4 - GONE!
- Section 6 details moved to separate document
- Pseudocode deleted
- Appendix A replaced with single ASN.1 code module.
- Appendix B, Authorization data now scaled back
- Appendix C, ticket extensions not in clarifications

- Sections needing more significant work:
- Section 3 needs some update to match new ASN.1 module.
- Section 5 needs rewrite to bring in line with ASN.1 module.

Clarifications to be made (1)

- I18N text on character sets
- Move tables for assigned numbers
- Implementation notes - behavior of different implementations
- Clarify how enc-tkt-in-skey (explain how u-to-u works).
- Constraints on integers used as types

Clarifications to be made (2)

- Implementation note about typed data in krb-error
- Update _musts_ (encryption, checksums, deprecate things)
- krb-cred without encryption (implementation note - HartmanS)
- security considerations added about end-to-end, especially naming (lot of confusion there).
- Recommendations on reducing address dependence
- Changes since 1510 (bcn)

Larry Greenfield brought up the issue about the text in clarifications regarding canonicalization of host-based service names; he basically asked that text be added overriding the gss-krb5 mechanism document regarding how to canonicalize service names. Doug suggested that Larry send some text for discussion.

Major extension issues (1)

- Extensibility by vendors and IETF using typed holes
- Strong words on not-violating interoperability
- Strong words not to use Kerberos as application transport

- Extensibility markers (but these are for working group use only)

- Address inadvertent use with old clients (transition path)

- I18N
- Full Unicode for names & passwords

- Reducing of dependence on addresses
- Explain what this means for forwarding & proxies
- Use krb_priv/krb_safe with direction bit instead of explicit address

- Desired extensions should be supportable
- Either by using typed holes (preferred)
- Enable tying tickets to host / location /whatever (auth data)
- Encrypted exchanges with KDC for user privacy and reduction of offline vulnerabilities
- Or by explicit support in extensions
- E.g, anonymous flag

- A reasonable migration path from old to new

Moving Forward

- Completed the listed items for clarifications
- Address comments and suggestion for clarifications submitted on the mailing list.
- Last call on clarifications (lets target for 45 days from now, or sooner)
- Continue work on extensions in parallel.

Cliff finished with no further questions from WG.

Next up was Donna Skibbie from IBM, discussing the draft defining the LDAP Schema for KDC information. Was presented last year, work has been done, presenting current status.


- Standard KDC administration API (note: key information is now in a separate draft, due to security concerns)
- Leverage existing LDAP tools.
- Single view of user data

Donna explained the flow of data (from KDC->LDAP API->LDAP server->backend database), and pointed out that the security critical section was the LDAP API-> LDAP server connection (about 40K lines of critical code)

Sam Hartman asked if instead of the KDC being an LDAP client, could it store it in a traditional Kerberos database and instead use LDAP as the administration to that database. Donna said, Yes, this was certainly possible.

Attributes defined in KDC LDAP Schema:
- Realm attributes
- Principal attributes

But for more information: contact Donna Skibbie (

It was brought up that without the key definition, the draft isn't complete, but Jeff H. pointed out that there are two consumers of this draft; people who want to use LDAP as a KDC backend, and people who want to use LDAP as a KDC admin interface. The possibility of two docuemnts was discussed, with all key related issues in one. Further discussion to list.

Jacques Vidrine was up next giving a talk about Kerberos weak password protection.

There are three opportunities for capturing ciphertext:

- AS-REP (sniff it or ask for it)
- PA-ENC-TIMESTAMP (sniff it)
- TGS-REP (ask for it)

Usefulness of ciphertext

- ASN.1 encoding results in a regular structure to plaintext, which makes checking easy (check for valid ASN.1 structure).

Operations for password guessing:

- Run through string-to-key
- Decrypt first block (past confounder)
- Check for validity

Possible solutions?

- DCE RFC 26.0-like (use host-configured key)
- SSL/TLS using KDC public key
- LEAF (being looked at by Ken R/John Brezak)

Password Derived Moduli (PDM):

- SACRED WG dropped PDM in favor of SRP
- IP Storage seems to favor SRP (presently being debated)
- IPR Statement on file for SRP but may infringe on patents.

Various other ideas were proposed, based on other SACRED proposals, possible PDM or SRP derivatives.

Ken Raeburn brings up various points:

- IPR issues was the cause of SACRED dropping PDM
- Ken's straw man proposal for SRP used a cookie in the protocol instead of requiring the KDC to keep state.

Charlie Perkins spoke up about IPR issues:

- Patent space is very ugly
- PDM was conceived to not be covered by any patents ... but that means that no one is willing to hire a lawyer to defend yourself.
- SRP might have similar issues (patent holders might go after SRP implementors)

- Steve Bellovin noted the irony that EKE was invented to solve this exact problem with Kerberos.
- Steve also suggested to iSCSI that they do CHAP under an anonymous DH-exchange.

Sam Hartman asked if people believed that anonymous-DH plus PA-ENC-TIMESTAMP would be good for unkeyed hosts; jhutz points out also that just specifying SRP is good enough and concerned people can license it.

Because Jeff Altman couldn't be here, jhutz is presenting the UTF-8 string prep profile document. Lots of various issues regarding UTF-8 normalization (see presentation).

Jeff Schiller brought up some issues with the kerberos passwords document that was submitted to the IESG; some revision may be necessary.

Doug Engert asked for a show of hands to get a count of people who would be able to attend in Yokahama. Not many hands were raised. A definite decision had not been made as to whether or not this WG will meet in Japan.

Doug Engert then closed the meeting.


Clarifications and Extensions
Interim Meeting Report (krb-wg)
Kerberos and Weak Passwords
UTF-8 Stringprep Profile