IETF 77 - Kitten Working Group Minutes ====================================== Location: Anaheim, CA - Hilton Anaheim Time: 3/24/10 at 10:30 - 11:30 PDT (Morning Session II) Co-Chairs: Tom Yu Shawn Emery Scribe: Larry Zhu Security Area Director: Tim Polk Slides for this meeting can be found here: http://datatracker.ietf.org/meeting/77/materials.html#wg-kitten Action Items: ============= Co-chairs: Create RFC editor note for the delegate-policy draft to change the text once the IANA-extensions draft becomes Standard. Co-chairs: Start WGLC on naming-exts draft if there are no objection from the list to include a normative reference of a 3rd party standards document. Co-chairs: Poll the list to determine which registry type the IANA-extensions draft should specify. Add an example registry entry in the draft, possibly from the delegate-policy draft. Co-chairs: Propose the idea of merging the KITTEN and SASL WGs to the list. If accepted then develop a new charter. Nicolas Williams: Propose an interface to provide asynchronous calls. Co-chairs will look for author/editor to develop the specification. Session Summary =============== Review of active items: [draft-ietf-kitten-gssapi-extensions-iana] ------------------------------------------ IANA has replied that they want the draft to pick one of the registry types left as a choice in the current version of the draft: single GSS-API name-space registry separate registry - symbolic and constant registries registry per programming language multiple registries No response during the session on which registry is preferred, will take the question to the list. [draft-ietf-kitten-gssapi-naming-exts] -------------------------------------- Makes a normative reference to a 3rd party (OpenGridForum) standards document - GFD.024. Requested approval to the list. Awaiting a one-week timer before submitting a WGLC, pending any objections. [draft-lha-gssapi-delegate-policy] ---------------------------------- Approval announcement made. Issue was raised given that the I-D makes a normative reference to the IANA-extensions draft. Decision was to create an RFC editor note to replace text once the IANA-extensions I-D is approved. Future WG items --------------- We discussed requested new work items that are of particular interest: credential management asynchronous calls Subsequent discussion followed asynchronous calls. Nico Williams had volunteered to provide what the interfaces may look like. Requested editors/authors of any subsequent draft. None had volunteered. New Proposal ------------ The merger of the KITTEN and SASL WGs was proposed. There were no comments for or against the merger. Will take this to the list Session Transcription ===================== Agenda: bashing? None. Feed-back from IANA: IANA-extensions draft must choose which registry it creates: Single GSS-API name space registry Registry per programming language Registry for symbol and constants names Multiple registries Leif: gss-api naming, align with implementation done by Luke Howard for MIT. Leif: Ready for last call, has implementation impact. Leif: gss_buffer_set reference issue. Last call next week. Love: GGF document dead Leif: maybe the IETF version of GGF is dead. Leif: gss_buffer_set is orthogonal, can be useful for others. Love: reference the original document Nico: copying the document from GGF Love: other things in GGF we want to have Love: gss_import_cred/gss_export_cred Leif: pull stuff as needed. Leif: should be in a copy or separate document. Shawn: other things to grab from GGF Leif: remove Grid specific stuff from GGF, it is not limited to gss_buffer_set reference Shawn: need to talk with Tim Leif: one author is active in the field. Von? Leif: someone could take the ownership or publish it. Leif: as it cleans up, last call it. Next: gss_api-delegate: Shawn: Correct typos and clarifications, has dependency on iana-extensions. Future wg items: Tom created item list: Credential management: Asynchronous calls: blocking non-blocking, event base. Tom: to avoid conventional mutexs around the GSS-API calls. Jhutz: desirable to avoid mutuex, to prevent shared out. Tom: avoid event driven application model. Jhutz: possible not require, interface to fast, not to prevent from empty fast Love: api does not need to expose the thread stuff. Henry: what are the issues related to multi-threading. Nico: no concurrent access to the same object. Sam: need concurrent access to credentials. Nico: not allow concurrent access to objects. Sam: disallow access would have perf penalty. Tom: reasonable/unavoidable mutex, posix file locking is one, it is per file, not per thread. Tom: alternative proposal, for high performance, do not use file system based credential store. Tom: why would want to non-thread safe library. Shawn: cannot depend on thread blocking, had to use event based library, constraints need to find generic way to provide asynchronous calls, without the assumption of thread blocking. Sam: why thread safety and asynchronous call are tied together. Love: I do not want a libevent. Nico: asynchronous, using callback. Tom: do we think if it is possible to specify abstract interface through third party event loop. Nico: could use libevent, or something else. Shawn: draft the interface. Nico: two different ways to implement asynchronous calls. Shawn: besides handles, what will be marshaled? Shawn: would Nico volunteer to write the document? Nico: can sketch the API, but cannot write documents. Shawn: take credential management to the list. Next: Sam BOF for Thursdsay, federated authentication Use case: federated authentication 1) outsourced IT 2) beyond the web 3) high performance computing 4) meta data to maintain Sam: radius most successful federation. EAP has most of the credential type used, GSS-API has excellent app integration. The proposal is to use gss-api EAP method. A: new gss-api mechanism. B: use case paper. C: radisu and saml binding. Henry: document locations. Eap as fast preauth: Issues - not enabled. Similar, assuming using IAKERB, not exposing KDC. New proposal: Merge Kitten and sasl WG Share core contributors/expertise Shepherd any new SASL mechanisms. Volunteer to write new charter text. Leif: is it just merging of two charter texts? Shawn: add new stuff, such as SAML Jhutz: specific ones better than broad charter The question whether to work on the charter is broader than the workgroup, therefore the charter should be specific. Sam: no more new sasl mechanism, only new GSS mechanisms. Scott Cantor: interested in submitting SAML, if moonshot does not have enough support. Add GSS mech. Session Over ===========