| Chairs | Jeffrey Hutzelman, Larry Zhu | |
|---|---|---|
| Scribes | Shawn Emery, Derek Atkins |
Introduction
Blue sheets were passed, the agenda was bashed, and generally a good time was had by all (Note: Due to shortness of time for preparing minutes, the preceding quip was copied verbatim from the minutes for the last meeting.) Shawn Emery agreed to scribe for the first session, and Derek Atkins for the second.
Remote Participation
Various people listened to the audio stream and/or participated via the Jabber chat room, which was displayed on a second screen to one side. Thanks to the IETF Secretariat and especially to Marcia Beaulieu and Amy Vezza for helping to make this continuing experiment possible.
Sam Hartman and Tom Yu gave a presentation on a proposal they are putting forward, along with Larry Zhu and Nicolas Williams, for a new direction for the next revsion of the Kerberos spec (which will end up being Kerberos version 5 specification 3). The new proposal involves using FAST to create a secure tunnel between a client and the KDC, over which an AS exchange can be conducted. The presence of the tunnel indicates that both ends support new protocol messages. The presentation included details on when new messages can be used in other Kerberos exchanges, how internationalization would work, and how some of the other goals for the next specification would be met under this proposal.
The presentation was followed by discussion on some of the details of this proposal and its merits relative to those of the approach taken by draft-ietf-krb-wg-rfc1510ter-04.txt. Included below is an excerpt from notes taken by Shawn Emery during this discussion.
sam: first topic for the floor? Is this the direction we should take? Jhutz: ask the question in a half hour, move in the direction or continue with 1510ter. Leif: any work done to compare to alternatives? Sam: yes, completely reuse decoders. Decoder for UTF8 and general strings sam: this is the advantage of FAST sam: more complex if fields are need sam: 1510ter allows more complete extensibility sam: though, 1510ter more complex, no id priv, no off-line dict prot sam: could combine 1510ter and FAST, but duplicate effort in parts sam: simple, but not as it looks, i18n is hard leif: is in 1510ter is unfeasible? Sam: FAST does have extensibility for all messages sam: no OID typed holes sam: 1510ter protects a few more messages leif: any compelling reasons for sticking to 1510ter? tom: more robustness, decoding PDUs we know early as possible nico: AP-exchange not covered in FAST sam: 1510ter has been more studied nico: we are not dumping it, we just allow more protection w/FAST stefan: avoid UTF8 in protocol elements jhutz: ascii or non-ascii prot elements jhutz: princ and host names work the same way nico: certificates don't have to worry about encoding sam: impl complexity with punicode jhutz: UTF8 prot elements are high bar to visit jhutz: do we think we want to take this direction? Leif: scrap for generality, solve specific problems? Sam: no blocking comment love: lacking type holes in serveral places, revisit some time soon when more exts are needed sam: modification question, with typed holes nico: we are prob going to modify some PDUs and might add typed holes sam: ticket extensions impl can be used in other places tom: be careful how many PDUs change, less robust the product will be sam: is this discussion is critical to decide to proceed? Love: general string vs UTF8 is down-played nico: typed hole, border-line issue sam: we should add extension markers love: we should have typed holes nico: type holes, easier to test nico: easier to implement nico: if ext markers then we should add typed holes sam: ext markers, we need them jhutz: no relevance to 1510ter or FAST proposal love: both will be difficult simon: would like to see negotiation in draft form sam: is 1510ter negotiation sufficient for Simon? Sam: not for sure how to head this off. Jhutz: has Raeburn heard enough to make up his mind? Love: are we going to implement this? Jhutz: three-prong question? ...also neither polk: hasn't been implemented after 5 years, is this a workable solution love: should you being this? FAST? Nico: anyone going to work on the ter spec? What could any 3rd alternative look like? Sam: as an impl: can find resources for FAST as opposed to 1510ter sam: who would be willing to write drafts? Jhutz: show of hands to contribute to drafts? 2 hands (Tom and Nico) zhu: combine documents? Jhutz: no jhutz: people who would review? 7 hands jhutz: would impl FAST? 1510Ter? Love: FAST, what is it? Preauth? Krb ext? For example, TLS. Jhutz: FAST as one item and krb5 spec 3. Not START TLS. jhutz: would impl FAST? 1510Ter? Nico: Are separating i18n? Are we adding new PDUs? Do we reject PDUs? Jhutz: we haven't rejected 1510ter sam: can easily commit resources tom: minimal PDU, wrap old PDU with new nico: we rejected that, we first broached this subject in 2001 jhutz: consensus on something out of this zhu: FAST is better, no impl have committed to 1510ter love: 6 years, Larry is right. If they liked it, we would have an implementation jhutz: 6 years ago, split doc in two branches 4120 and things not included nico: other groups have bake-a-thons, no spec before testing. People could have been implementing jhutz: all our time is spent on other things? Sam: market level dictates, true for larry sam: FAST may be a simpler implementation jhutz: three categories: ext 1510ter 4120 jhutz: no one seems to opposed to FAST, no one seems interested in 1510ter polk: 1510ter does not seem to be a winning strategy, charter is broken sam: charter is not broken polk: what is the info you would need to impl FAST? Love: others doing the same? Sam: who are the implem? Nico: I do want to have FAST, do we choose 1510ter approach for PDUs? Nico: we have to change the PDUS, which approach do we take? Sam: FAST, but resources zhu: FAST in-line with customers love: wants to be able to use his name sam: what about Simon? Simon: my focus is to solve i18n, doesn't care about FAST vs 1510ter nico: He may not care about back-wards compat. Jhutz: yes. Simon: non-ascii is not conforming jhutz: Are people ok with the FAST approach? Yes: 8 no: 0 don't care: 4 need more info: 0 simon: don't care or need-more-info sam: pre-auth, IANA, neg and new PDUs, mixed mode i18n
PKINIT ECC (draft-zhu-pkinit-ecc-03.txt)
This document has completed WG last call and is ready to go to the IESG. However, it has been targeted as standards track during most of its life, but has a normative reference to RFC 3278, which is an informational document specifying how to use ECC with CMS.
The referenced document is informational because of IPR issues with ECC, and the working group needs to decide whether we want to publish ECC-for-PKINIT as informational, or attempt to place it on the standards track despite the IPR issues and normative downreference. This question has been open on the mailing list for a while, and folks seem to be leaning in the direction of macking it informational. Anyone with an opinion should speak up.
Set/Change PW (draft-ietf-krb-wg-kerberos-set-passwd-06.txt)
This has completed WG last call, and is awaiting a PROTO writeup before it can be sent to the IESG. The version currently in the internet-drafts repository is corrupted; Nico was planning on sending an updated one, but that didn't happen due to a communication failure between Nico and the chair. This will go to the IESG soon.
Naming (draft-ietf-krb-wg-naming-03.txt)
This document passed working group last call, and is ready to go to the IESG. It's currently being held to go forward at the same time as anonymous, which depends on it.
Anonymous (draft-ietf-krb-wg-anon-04.txt)
Larry (as author) believes this is ready for a WG last call. Jeff (as chair) will start the last call soon after IETF.
Shawn Emery said he sent in comments about this document a week after the Prague IETF meeting and had not seen any reply. When asked, he said he was not sure if they had been addressed in the most recent version of the document [Shawn later told me his comments had been addressed --jhutz]. Larry said he would look for the comments.
GSS Hash Agility (draft-ietf-krb-wg-gss-cb-hash-agility-01.txt)
The author believes this document is ready to go. Larry had a few minor issues and editorial changes, which don't necessarily require a new document before last call. Larry will start a last call shortly after the meeting.
PKINIT Hash Agility (draft-ietf-krb-wg-pkinit-alg-agility-03.txt)
Love had previously reported there were no known problems with this document, but that he wanted to try implementing it before moving forward. He reported that having attempted an implementation, he discovered that test vectors were missing. Love will add the needed test vectors, and Larry will verify them.
The chairs asked that people review these documents and, for those who are implementors, try to implement them.
Referrals (draft-ietf-krb-wg-kerberos-referrals-09.txt)
This document is not yet ready for last call. Ken says there are one or two issues that have been brought up but haven't had much discussion, and he had not yet followed up.
StartTLS (draft-josefsson-kerberos5-starttls-02.txt)
This document is basically done but needs review and input from the WG, as it was mostly developed outside the WG by its author. Before we can move it forward, we need to decide what its intended status is, and that is blocking on the outcome of the FAST work.
Data Model and Admin Protocol (draft-johansson-kerberos-model-03.txt)
Leif Johansson gave us an update on the KDC data model document, and raised a few open issues on which he wanted input from the working group.
The first question was regarding whether the data model document should use a formal language or whether plain English is sufficient.
Kurt Zeilenga suggested that for the data model itself, English is sufficient, but you'd need a formal language for a schema. He said you could describe the data model using LDAP's formalities, but that might not be sufficient.
Sam Hartman (as individual) said he'd prefer to see English used for the data model, and appropriate formal languages used for and LDAP schema, MIB, or whatever else.
Kurt commented that one advantage of using ASN.1 is that we're famliar with it; Jeffrey Hutzelman said he thought that was the first time someone had used that argument in favor of ASN.1 in this WG. Tom Yu said part of the problem with using ASN.1 for 1510ter is that we're trying to preserve the use of notation from the existing specs.
The chair asked the question, whether the data model document (not any later schema document) should use English or a formal language. Kurt said his answer depended on which formal langauge. Tom said using English is sufficient if the data model is simple enough; Leif believes it is.
Leif and the chairs believe they have the feedback needed for now, and a decision did not need to be reached on this point yet. There will be time for more comment after the next version is published.
Leif's second open question was about whether we want to think about including in the data model things that would not be part of an LDAP schema.
Jeffrey Hutzelman commented that if folks from the operations and management community were in the room, they'd probably be saying we should write a KDC MIB. Sam Hartman said that more recently they've been backing off on that, not trying to force people to write MIB's or use SNMP as long as protocols are suitably manageable.
Jeff asked whether we expect the LDAP schema to be the complete management solution for Kerberos. If there's data worth managing that won't be in LDAP, then it should probably still be in the data model.
Nico gave some examples of data that wouldn't be in LDAP: KDC configuration, password protocols, statistics; jhutz added enctypes. Leif said that basically sounds like we should be prepared with this model to be able to make a MIB.
Nico commented that it would be good to make sure the data model and set/change password are in line with each other, which would require that he submit an updated version of the latter.
Simon Josefsson said he prefers the data model be separate from LDAP [Not really what we were asking --jhutz], because he is not planning on implemeting the latter. Martin Rex asked about the distribution of keys to services. Leif said that problem is not solved by LDAP. Nico adds that is what set/change password is for, and notes that the data model should model not only what data is stored but what operations can be done.
Martin also asked about distribution of Kerberos configuration to clients. It's not clear whather that is in scope here; Leif said it helps ot not get too far from the goal of describing the KDC's data model.
(there was more discussion, but it's not clear about what)
Leif will submit an updated document based on feedback received.
Preauthentication Framework / FAST / STARTTLS (draft-ietf-krb-wg-preauth-framework-06.txt, draft-josefsson-kerberos5-starttls-02.txt)
Sam and Larry gave an update on the preauth framework document. They reviewed the resolution of several previously-open issues, and discussed some on which input was still needed.
One major issue Sam brought up was with section 6.4, which deals with preauthentication sets. The request he's getting from people designing the UI is that a client be able to tell from the first message what are all the things it might have to ask the user for. Nico pointed out that this is a problem SSH also has.
Love pointed out that you might have multiple alternatives; Sam replied that that's what the section in question is about. Nico noted that the set of alternatives might depend on the principal; Jeff pointed out that by the time it generates the first message, the KDC should know the principal name.
Sam said that we're basically talking about committing never to standardize something like SSH's "keyboard-interactive". Nico said he doesn't want to standardize that, but also doesn't want to commit to never doing so. Sam said he needed to assume in the client that we'd never have something like that, because otherwise the UI design is too hard. Love said he doesn't really have an issue on the UI issue. He doesn't think there will ever be enough PA types that you can't do an exhaustive search.
Nico brought up cases like password expiration or OTP resets, in which something unexpected happens. Sam believe's it's OK to have some cases where you have to pop up a dialog, but repeatedly doing so a la keyboard-interactive is not OK. Sam also said it would be fine to know all the possible prompts in advance, but not which ones would actually be needed.
Sam's second point was about confusion caused when a preauth mechanism is listed as part of a preauthentication set, indicating that it must be used in combination with some other mechanism, but must also be listed outside the paset, in order to include challenge data. After some discussion, it was decided that the PA-AUTHENTICATION-SET-ELEM type should be extended so that challenge data could be provided within a paset. This allows a preauth mech that must be used in combination with others to be listed only inside a paset.
Sam and Larry will update the document to reflect issues that have been resolved. After that, they believe the document will be nearly ready for last call, except that it will probably require if the proposal from the previous day is adopted.
Cross-Realm Problem Statement (draft-sakane-krb-cross-problem-statement-05.txt)
Shoichi Sakane gave an overview of the cross-realm problems document, and asked for input from the WG on whether we agree that all of the listed items are in fact problems which should be discussed here. The sense of the room was that all six items listed are indeed problems, and that they should be included in the document regardless of whether the working group intends to find solutions for them.
There was some discussion of milestones for upcoming work, mostly between the chairs and responsible AD. The following milestones were adopted:
| Date | Item |
|---|---|
| AUG 2007 | Anonymity to IESG |
| AUG 2007 | Hash agility for GSS-KRB5 to IESG |
| AUG 2007 | Hash agility for PKINIT to IESG |
| TBD | WGLC on STARTTLS |
| TBD | WGLC on Referrals |
| AUG 2007 | Choose direction for Kerberos v5.3 |
| SEP 2007 | WGLC on preauth framework |
| NOV 2007 | WGLC on OTP |
| NOV 2007 | WGLC on hardware preauth |
| DEC 2007 | WGLC on cross-realm issues |
| DEC 2007 | WGLC on data model |
| MAR 2008 | WGLC on Kerberos v5.3 |
| MAR 2008 | WGLC on IAKERB |
| MAR 2008 | WGLC on LDAP schema |