70th IETF - Kitten Working Group Minutes =============================== Location: Vancouver, BC, Canada - Westin Bayshore Resort and Marina - Cypress Time: 8/4/07 at 1:00pm Chairs: Alexey Melnikov Shawn Emery Scribe: Leif Johansson Security Area Director: Sam Hartman Action Items: ========== Find other editors besides Nico for drafts: chairs Update domain-based drafts with ABNF references: Nico Flesh out IANA-registry draft: preferably IANA experts Update Charter (remove pseudo-mechs, add IANA draft to Milestones, and remove C# bindings as a Charter item): chairs Action items from last IETF: Review draft-ietf-kitten-extended-mech-inquiry-02: Larry Zhu, Ken Raeburn, Jeffrey Hutzelman, and Sam Hartman Submit an informational draft to cover export partially-complete contexts: Leif Johanssen People that would review said document: Sam Hartman, Ken Raeburn, Nicolas Williams, Philip, and Alexey Melnikov Conference Session: ============== Agenda was presented with no bashing. Active Work Items ------------------------ Refer to slides. In regards to draft-ietf-kitten-gssapi-domain-based-names-04: ------------------------------------------------------------- Nicolas Williams (nico): I didn't take the full set of DISCUSSes into account when I submitted -04 nico: I really wanted to get the I18N updates in it might have been better to not submit one at all until I had the time to update it for all DISCUSSes. Shawn Emery (shawn): Discussion about the reference to RFC2743. nico: Yes, use of domain-based names requires updates to application protocols this registry, the one for name types, the IANA registry doc is for all the other things we want a registry for (symbol names, type names, constants). nico: I'd love to hear from Sam about the I18N updates since those are the ones I'm most likely to get wrong. Alexey Melnikov (alexey): Suggested to use ABNF to specify slot names (ref: http://www1.ietf.org/mail-archive/web/kitten/current/msg01405.html) nico: I had agreed to use ABNF, and since Alexey sent the necessary text I'll fold it in. nico: Going forward it's likely that we'll try to have the service name match IANA port number names. There was consensus in the room for Alexey's proposal. In regards to draft-ietf-kitten-rfc2853bis-03: ---------------------------------------------- shawn: -03 contains updates based on review comments, such as included just the differences between RFCs in an appendix and some clarification changes. In regards to draft-ietf-kitten-gssapi-channel-bindings-02: ----------------------------------------------------------- shawn: Needs to be aligned with RFC5056 and draft-altman-tls-channel-bindings. In regards to draft-ietf-kitten-stackable-pseudo-mechs-02: ---------------------------------------------------------- shawn: Dropping from Milestones for now based on that applications (ssh, SASL, etc.) do a better job in negotiating mechanisms than negotiating mechanisms. In regards to dratf-ietf-kitten-extended-mech-inqury-02: -------------------------------------------------------- shawn: Is there a need to remove the mech inquiry for pseudo mechs is pseudo mechs is not relevant at this time. nico: No need to remove pseudo-mech attrs from the extended inquiry APIs. shawn: Consensus is that pseudo-mech attrs stay. In regards to draft-ietf-kitten-gssapi-naming-exts-02: ------------------------------------------------------ shawn: Lots of TBDs. The PKIX sections needs to be moved into a separate draft. In regards to draft-ietf-kitten-gssapi-extensions-iana-01: ---------------------------------------------------------- nico: The IANA doc should be our highest priority after domain-based names, probably. co-chairs: Is there an IANA expert to take-over/help the draft? People are hiding under their chairs to avoid beeing stuck with iana registry doc. Nico: I'll edit it. I may need a volunteer to populate it, but IIRC we can submit initial contents separately in which case I can probably get it done very quickly. Sam Hartman (sam): Suggess that we find a non-nico author for iana, in order to generate more involvement. nico: If we put the initial registry contents in a separate doc for IANA then we can get this done very quickly -- all we need, if I won't edit it, is someone who's written I-Ds in xml2rfc format before. In regards to charter/milestones items: --------------------------------------- nico: I want the IANA doc moved up (from April), as stated on the mic I want to move extended mech inquiry down to at least February (from January), perhaps even March. In regards to an nfsv4-wg heads-up: ----------------------------------- jhutz: NFS needs a mandatory security mech that's good enough and meets their performance needs. Since they're trying to avoid copies and such, this more or less means secure authentication plus channel bindings to something like ipsec plus making gss_wrap itself a noop (essentially, ccm). nico: The kitten channel binding I-D is an abstract version of the channel bindings text in RFC2744, we don't need that for NFSv4 to use it. If the NFSv4 WG prefers to extend RPCSEC_GSS then there's no need for CCM, pseudo-stackable mechs and we need only review what they do. I think extending RPCSEC_GSS will turn out to be preferable. In regards to open mic: ----------------------- Marc Crispin (marc): Wants to distinguish between when the user has credentials and when they don't. nico: The problem that Marc describes is particularly annoying in SSHv2. nico: We've discussed this in the past, but anything along the lines of what Marc is describing requires changes to the app protocols (and/or SASL, in the case of SASL apps) nico: We've talked in the past about "federation negotiation" and we've talked about a GSS-API pseudo-mech or extensions to SPNEGO to do that, but if you are using non-GSS-API mechanisms then this is insufficient. nico: The general problem of mechanism+federation negotiation though is a very interesting one. ------------------------- Session over.