71st IETF - Kitten Working Group Minutes ======================================== Location: Philadelphia, PA, USA - Marriot Downtown Philadelphia Time: 3/11/08 at 18:50-19:50 EDT Co-Chairs: Alexey Melnikov Shawn Emery Scribe: Jeffrey Hutzelman Security Area Director: Tim Polk (exiting Sam Hartman) Action Items: ============ Co-Chairs: Revise milestones to push back dates. Co-Chairs: Revise charter to remove C-# bindings work item. Co-Chairs: Submit WGLC for channel bindings draft. Jeffrey Hutzelman: Review IANA-extensions draft and possibly take over as editor. Nicolas Williams: Update channel bindings draft to include new sections. Leif Johansson: Start editing naming extensions draft. Conference Session: ================== Slides for this session are available at https://datatracker.ietf.org/public/meeting_materials.cgi?meeting_num=71#wg-kitten domain-based names - sent today approved; announcment sent today, that is shawn: any volunteers to review iana considerations? alexey - volunteer Sam now that he's available. But we need more. I volunteer. Nico and I have an exchange, whose result appears to be that I may end up taking over as editor. Sam says he won't have much time before June, but will have lots after that. Will be on leave april 18 through the end of may shawn: OK to last call channel bindings draft today? extended mech inquiry... naming extensions... leif has volunteered to take over editing from nico what about kerberos u2u (given that it has been used for years in Microsoft W2K...) nico: pku2u sounds like user-to-user, but really isn't. this was more targetting the multiple mech interfaces/extenstion mrex: krb5 u2u will need its own mech OID Microsofts kerberos u2u uses a seperate mechanism OID as will IAKERB and each of those mechs will have a set of mech attributes that's different from each other and krb5 nico: extended mech inq is pretty close nico: alexey had some comments a while back; issues I'll fix nico: someone asked whether we want attribute to mention expected # of round trips, etc. I guess we could do that. nico: ... but we'll have an IANA registry! nico: We'll probably have a place to keep the set of attribute OID's for a mechanism. even if a mechanism could provide an attribute, its unclear at what point a particular implementation will offer it I slightly worried about the level of expectation that will result -- with the effect that applications may fail if their expectations are not met It would be preferable if such extensions are mainly considered "nice to have" rather than a prerequisite for interoperability Well, not, it's really not about "nice to have". The idea is that if you need a feature, you ask for applications that have that feature. Rather, you ask for mechanisms that have it. you can rev specs as often as you want, this will not affect the installed base And you don't try mechanisms that don't have the attribute that identifies the feature you need. But you can't ever depend on the _absence_ of an attribute meaning that the feature _isn't_ available. As martin and others point out, defining a new attribute and revving the spec doesn't change the installed base. nico: nothing says we can't add a way to tell what attributes are even known to the framework and to the mechs. sam: you can have "yes", "no", and "I don't know" as possible answers. nico: yes; that's good; I will make that change. It would be clearer if we create a GSS-API v3 with specific additional requirements than defining extensions to GSS-API v2 that applications or scenarios make a prerequisite -- it would be clearer for consumers of the technology Martin, I thought this was explicitly part of gss-api v3 not v2 it would, but it wouldn't be extensible that is, over time, we may identify new properties that some applications need mechanisms to have. nico: I think long ago we decided we were going to have extensions, and bundle them into something we'd call gssapiv3, but not change the symbol name prefixes, etc and as we identify those, we can define new attributes for them and have applications be able to query for them as needed. rev'ving GSS-AP base spec took years the last time(s), so no one likes to go down that road ... since we do not know all the possible applications and mechanisms, we can't know what the required feature set should be. and, we may not want to require all mechanisms to support the union of the needs of all applications. In fact, I bet such a requirement would make your customers unhappy, since I bet many of their mechanisms do not need features that are needed by some newer applications today but not by your application (prf?) (though that is perhaps a poor example) milestones... shawn: IANA... push that out... some changes nico: guidance to iana is mostly there. I need someone with more iana experience to review and tell me what's missing. nico: plus I need to build the initial tables wrt iana, nico will prepare examples for each registry by may. naming extensions... publish new version with leif as editor, by may store cred... nico can unexpire in april alexey: what issues? nico: one of the inputs/outputs turns out not to be ???. But we've shipped it s/???/necessary 2853bis... unexpire, I like that :) shawn: does anyone object to mving 2853bis to april or may? meting a milestone early is just fine ============ Session Over