Last Modified: 2003-10-20
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.
| 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. |
Kerberos Working Group - IETF 58 Minutes (draft 0.2)WEDNESDAY, November 12, 2003
Agenda BashingSlides: #0 - krb-proceedings.txt
Milestones and WG PrioritiesSlides: #1 - milestones.doc Doug Engert presented a list of the group's current work items and some proposed milestones, with an eye toward establishing realistic goals for upcoming work and updating the list of milestones on the WG web page.
Doug asked Russ whether the AD's were OK with this list. Russ answered yes. Pre-Authentication Framework - Sam HartmanSlides: #2 - hartmans-preauth.pdf Sam Hartman presented a proposal for a generic framework to describe preauthentication mechanisms and how they interact. Ken Hornstein asked whether changes to existing preauth methods would be required. Sam indicated that the specs for such methods should probably be updated mainly because we need to do a security analysis, but that likely no on-the-wire changes would be needed. Ken indicated that he cared mostly about on-the-wire changes. Love Hörnquist-Åstrand indicated support. Doug Engert asked whether the KDC would need to keep state. Sam responded that it's a design requirement that the KDC not need to keep state. Nicolas Williams expressed support. The chairs took a poll to gauge whether there was support to continue this work as a work item of the Kerberos working group. There was a strong concensus in the room that this was valuable work and should be adopted as a work item. PKINIT - Brian TungSlides: #3 - pkinit.ppt Brian Tung gave an overview of the status of the PKINIT draft. Contributors and chairs met earlier in the week to hash out the work schedule. Protocol details were _not_ decided at that meeting; they are what was agreed upon at the September interim meeting in Boulder. Sam Hartman said something about making some minor changes to PKINIT to allow it to be used to provide anonymous DH and signing of KDC replies. It was pointed out that this could not usefully be done to support anonymous DH, because an extra round trip would be required. Love Hörnquist-Åstrand says he's implemented PKINIT for heimdal, and experienced some problems in the process. He dislikes pulling in CMS and X.509, because of the increased complixity required in the ASN.1 parser if those modules are to be used. He'd like instead to see the X.509 encapsulated in a string [XXX OCTET-STRING? -jhutz]. Sam Hartman said he agreed in principle, but it may be too large a change for some implementors, particularly CableLabs. Brian indicates we are already making backward-incompatible changes which are flagged by a new preauth type. Sam pointed out that in Boulder, the PacketCable folks made it clear they would be unhappy with "unnecessary" changes that would require a major implementation change. Love: "not as big of changes" [XXX which is not as big?] Jeffrey Hutzelman pointed out that the main likely opponent to such a change was not present at the WG meeting, and asked that the issue be taken to the mailing list. Kerberos-Clarifications and Kerberos-Extensions Status - Cliff NeumanSlides: #5 - msp03-krb-bcn.ppt Cliff Neuman gave us an update on the status of kerberos-clarifications and kerberos-extensions. The kerberos-clarifications draft has been sent to the IESG, and some comments have been received. There are some minor changes that need to be made, mostly editorial. Russ told us the draft was on the IESG telechat agenda for the week after the IETF meeting; he agreed to move it two weeks later in order to give Cliff time to produce a new version of the document. Sam Hartman pointed out (again) the issue of a protocol field which may have inadvertently been made OPTIONAL in kerberos-clarifications. Jeff Hutzelman agreed on behalf of the chairs to check into this. Work on the kerberos-extensions document is proceeding. A list of open issues was identified at the interim meeting in Boulder. Referrals and Canonicalization - JK JaganathanSlides: #6 - referrals.ppt JK gave a presentation on referrals and client name canonicalization. The current schedule is to publish an updated draft in December. Sam Hartman asked whether canonicalization and referrals needed to be tied together; he indicated he believed this is an editorial question, not a technical one. Someone [XXX who?] asked how we should move forward from here. Sam pointed out the decision as to whether to incorporate this work had been made at the first interim meeting [and validated on the WG mailing list -jhutz]. Nicolas Williams asked whether we are talking about RFC1510/clarifications or extensions. The answer given was that we're talking about extensions. Nico then asked whether this should be folded into extensions, or done as a separate document. Sam said it's an optional mechanism, and does not need to be in the core document. Before moving on to the question of whether this work should be folded into kerberos-extensions, the chairs asked whether there was any objection to continuing the work at all; none was voiced. Next, a poll was taken as to whether this should be done in kerberos-extensions or as a separate document; on this issue, the room was divided. Nico raised an issue with regard to normative references, and whether it was wise to leave this as a separate document. Sam pointed out that even if it's a separate document, the group can always pick it up if the current authors stop maintaining it. Sam suggested leaving this issue undecided for now, and revisiting it once the updated document had been published. We can always roll it into kerberos-extensions later. Next, we returned to the question of whether referrals and canonicalization belonged in the same document or in separate documents. Someone [XXX who?] asked whether service name canonicalization was under discussion; the answer was no. Ken Raeburn asked about the "gnuftp.raeburn.org" problem, and whether it was resolved. The gist of the problem is handling the case where one organization defines in its namespace an alias for a service provided by another organization (e.g. gnuftp.raeburn.org is an alias for ftp.gnu.org). In such a case, a DNS alias is insufficient; you also need a cross-realm referral with a service name change. Sam Hartman said he believed we already had closure on this issue and shouldn't need to revisit it. Sam said that if a client is going to implement canonicalization and referrals, it needs to implement ALL of it. Someone then suggested separating out the issue of canonicalization and referrals as they affect AS requests versions as they affect TGS requests. The chairs took a poll, and the sense of the room was that these should continue to be addressed in the same document. JK asked whether we want canonicalization at all. Sam said yes. The chairs took a poll as to whether canonicalization and referrals should be handled in the same document; the sense of the room was yes. Ken Raeburn said we should figure out the solution to the "gnuftp" problem, and then figure out how to break down the components. InternationalizationSlides: #7 - jaltman-idn.pdf Jeffrey Altman proposed that we solve all of our internationaliztion problems by eliminating all use of ASCII; the room was amused. Jeff then went on to give us a presentation on the internationalization proposal for kerberos-extensions. Russ Housley raised some concerns about the backward-compatibility of replacing GeneralString with a CHOICE. Kurt Zeilenga noted there are a lot of hand-coded ASN.1 decoders out there. Sam Hartman said he believes this is not going to be a problem. Love Hörnquist-Åstrand asked how this interacts with user-to-user authentication. Sam responded that this is an open issue; we don't know yet whether it will be a problem. Nicolas Williams suggested that X.500 names be removed from the [PrincipalName?] CHOICE. There was some argument about this, after which the chairs declared the issue to be a rathole and asked that the discussion be moved to the mailing list. Jeff Altman brought the open issue of whether SASLprep (and thus Kerberos) should fold Unicode full-stop characters (particularly, IDEOGRAPHIC FULL STOP) to the ASCII period. Kurt Zeilenga indicated that a related issue was whether to permit private-use area characters; Jeff indicated that there may be other related issues as well. It was suggested that the full-stop and private-use issues are basically the same for Kerberos as they are for SASL, and that the issue should be deferred to the SASL working group, where the SASLprep document lives. The chairs took a poll, and there was strong support in the room for deferring to SASL on these issues. Tom Patrik expressed some concern over the SASL WG's ability to resolve these issues, based on the discussion he had seen earlier in the week. It was pointed out that many of Kerberos WG members who were interested in this issue were also active in the SASL WG, and they felt the issue was under control. The chairs asked that the SASL WG chairs (Kurt Zeilenga and Sam Hartman, both of whom were in the room) continue to keep the Kerberos WG apprised of the status of the SASLprep document. GSSAPI-CFX - Larry ZhuSlides: #8 - gssapi-cfx.ppt Larry Zhu updated us on the status of the GSSAPI-CFX document. The one major remaining open issue is whether new-style message tokens should use the generic GSSAPI token framing. This has been the subject of heated debate on the list between a small number of individuals, who seem unable to reach agreement. The chairs took a poll to try to determine the sense of the room on the token framing issue. The response was weak, but clearly against using generic framing on new-style per-message tokens. The chairs noted that the major proponent was unable to be present at the meeting, and indicated they would make a determination and announce it on the list. [Doug Engert later announced to the list a determination that there was rough concensus in the working group not to use GSSAPI generic token framing on new-style per-message tokens. Set/Change Password - Nicolas WilliamsSlides: #9 - draft-set-pw2.pdf Nico Williams gave an overview of the status of the set/change password draft. There were tow major open issues. The first open issue was whether the new protocol should continue to support UDP transport. The chairs took a poll, and the sense of the room was that UDP support should be dropped. The second open issue was whether the new protocol should continue to use the same message framing used by the previous version of the set/change password protocol. It was pointed out that this issue is tied to whether we use the same port -- if the same port is used, the existing framing must be retained; if a new port is assigned, then we are free to adopt new framing. Someone [XXX who?] asked what the new framing would look like, if the group decided to drop the old framing. Nico gave a brief description. Sam Hartman disliked the proposal and proposed XXX what?. Russ Housley said that if new framing was adopted, a protocol version number should be included to avoid having to make a similar change again. The chairs took a poll on this issue, and saw no clear concensus. Further discussion was deferred to the mailing list. DECISIONS and ACTION ITEMS
|