Last Modified: 2003-05-30
| 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 WG (krb-wg) Tuesday, July 15, 2003 1700-1800 Afternoon Sessions IV ====================================================== Acting CHAIR: Ken Hornstein (Doug Engert can not attend) Scribe: Luke Howard AGENDA: Introduction, agenda bashing --------------------------------------- ----------------------- Ken introduced himself. No comments on the agenda. Living life in a Post-Clarifications World --------------------------------------- ----------------------- Noted that documents have gone to last call; believe that all comments were syntax or wording issues that can be fixed by the author re-edits. No further comments. Extra TGT draft --------------------------------------- ----------------------- Background: The extra TGT draft is designed to use the host key to give you stronger preauthentication to avoid exposure to weak passwords that Kerberos has always has. The major problem has always been how it combined keys and used Kerberos cryptography. The crypto framework now has the necessary primitives for doing this in a clean way, although without a combine keys function. Sam noted that he has done the work on a combine keys function that is sufficiently obvious and has sought review, and will supply the necessary text to Jonathan Trostle for inclusion. Suggest that it could last call by Minneapolis. There was another proposal from Jacques re: anonymous DH for pre-authentication, no response from Jacques regarding its status. PKINIT, PKCROSS --------------------------------------- ----------------------- Packet Cable have expressed (privately) interest in this. Noted that PKCROSS was deferred due to its dependence on ticket extensions. Both drafts have expired to Ken's knowledge. At the last IETF there was a large discussion about mapping realms (in?) certificates to Kerberos names; questions about clarity. The technical issues that remain are "fairly simple" (Sam's words), but someone needs to discuss with Tom Yu the encoding of distinguished names in Kerberos principals. This needs to be investigated. Similarly the X.509 to Kerberos name mapping has some outstanding issues (not subjectAltName). The assumption that any published standard will be compatible with deployed implementations (eg. Windows 2000) may unfortunately be incorrect. Some discussion on whether we need new editors for the document; depends on the degree of interest from the working group. Comments from Jean-Francois Mule, Director of PacketCable Architecture: Cable Television Laboratories (CableLabs) is an organisation that manages specifications along with vendors. It does not create specs on its own. They are definitely interested in both PKINIT and PKCROSS. Understanding is that they are not that far from the current drafts and are willing to commit resources to moving these things forward. Moved to discuss this after meeting. Sam: it might be possible for PC to do an informational RFC describing what they have done (notwithstanding the need for a standards track RFC); noted, again, that PKCROSS is blocked on Kerberos extensions. Working group is likely to object to any standards track document that describes doing things that are a violation of the Kerberos specification as it stands and would lead to interoperability problems. Ken: background regarding extending ASN.1 types in an interoperable manner. Extensions are the next major work item but no timeline, "active participants want it to see it progress rapidly". Jean-Francois: concern is that they do not wish to promulgate non-standard implementations but timelines may force otherwise. ITU-T study group 9 has a specification that has been consented but cannot progress to the next step until it can normatively reference an information track (?) RFC. Jeffrey: noted that PacketCable require an extension that would break backwards compatability, and that this is a difficult situation with respect to timelines; conversely, doesn't see that there is a lot that can be done to make this happen faster. Jean-Francois: not asking for faster as much as a timeline, so that vendors and service providers can be provided with an answer. Sam: PacketCable has the opportunity to deploy an implementation that long-term is interoperable with existing (non-standard) and future (extensions) clients. Issues are: encoding of extensions and writing texts, so it is reasonable to expect that within a year they may be sent to the IESG (assuming the current degree of focus within the working group is maintained). Proposed timeline: end of July 2004 for IESG. It was noted that only PKCROSS was being held up by the extensions document; all PKINIT needed was an editor willing to do the work. Jean-Francois said that CableLabs was willing to provide resources to make PKINIT happen. Jean-Francois suggested they would be willing to host an interim meeting. Some discussion regarding interim meeting ensued. Question from Jean-Francois: what's the likelihood of the IESG accepting an information draft describing their existing use. Steve noted that the IESG will not accept an individual submission that looks like an "end-run" around the working group; the working group has veto power over individual drafts in its space, and the working group would be likely to approve this given the acknowledged issues re: extensions. Steve noted that it would "take a good description, possibily in the document or in a submission from me to say why this is being done this way... eg. 'we will issue a standards track document when it is possible'". Jean-Francois noted two separate issues: - documenting what they are doing - request for I-D to reference in ITU-T; hence informational RFC would be useful Much discussion on whether an information RFC would actually be useful or not. Question on whether it would be possible to advance PKCROSS without extensions. Working group has decided against this because of the present lack of extensibility mechanisms in the Kerberos protocol. Some discussion on whether an issue tracking system would be useful. Password change protocol --------------------------------------- ----------------------- Much discussion recently on this document; sounds like that it is "progressing quite nicely". Kerberos/GSSAPI authentication in SAML --------------------------------------- ----------------------- Tim Alsop of Cybersafe UK. Wanted to gauge interest in SAML working with Kerberos. SAML is a standard that is part of the many web services standards, and there is some discussion on how it may be used with Kerberos. Luke: does this interact with WS-Security? Agreed that WS-Security is hopelessly underspecified particularly with respect to Kerberos. Bob Morgan: noted his involvement with SAML, OASIS. WS-Security is "almost done" (did I understand that correctly?) and specifies interaction with X.509 and Kerberos. Some people have been discussing how SAML assertions might be used in a SASL context. Tim noted that there are multiple ways in which SAML could be used. Some question on whether OASIS or this working group was the appropriate forum. IETF might be, but not this working group. Bob noted some movement regarding SASL referencing SAML, out of scope for krb-wg. Head nodding from Jeff Hodges. Wyllys Ingersoll: question about cat-wg. Defer to list. draft-ietf-krb-wg-hw-auth-02.txt --------------------------------------- ----------------------- Matt Crawford cannot be here; skipped due to time constraints. Kerberos KDC LDAP schema --------------------------------------- ----------------------- Focus has changed to using LDAP as an admin protocol rather than storing Kerberos keys in LDAP. Leif Johannson noted that the current issue is describing the information model; the schema will come later. There will be a meeting after this meeting. Extensions --------------------------------------- ----------------------- Many things (like ticket extensions) were deferred until extensions. The next thing to do is: "charge ahead". No-one disagreed. Do we need an interim meeting? --------------------------------------- ----------------------- Resounding consensus is that we do need an interim meeting; when/where should be deferred to the mailing list. Open discussion --------------------------------------- ----------------------- |