74th IETF - Kitten Working Group Minutes ======================================== Location: San Francisco, CA USA - Hilton San Francisco Time: 3/24/09 at 17:10-18:10 Local time Co-Chairs: Alexey Melnikov Shawn Emery Scribe: Larry Zhu Security Area Director: Tim Polk Action Items: ============= gssapi-extensions-iana ---------------------------- Nico Williams: Needs cleanup of idnits before PROTO-writeup. Co-chairs: Send to AD (Tim Polk) after Nico's updates. Note: Initial registry will be populated during IANA review (during RFC publishing). gssapi-channel-bindings ------------------------------ Should be complete. extended-mech-inquiry ----------------------------- Nico: Add text in respect to memory management concerns with buffers and oid sets. Co-charis: Send to AD (Tim Polk) after Nico's updates. gssapi-store-cred --------------------- Should be complete. rfc2853bis ------------- Should be complete. gssapi-naming-exts ------------------------ Leif Johansson: Post question to list on whether to use OIDs or char * for attribute naming. Note: WGLC gssapi-naming-exts 05/09 (Orig 11/07) draft-lha-gssapi-delegate-policy --------------------------------------- Should be complete. Note: IANA registry will occur for this draft during the IANA review of IANA registry. Charter/Milestones ------------------------ Co-chairs: Need volunteers/momentum behind: Updates to v2 RFCs: Guidance for mechanism and application protocol designers. Thread safety. C-binding clarifications (types, name space, etc.). Co-chairs: Still need to remove C# binding work item. Conference Session: =================== Slides: http://www3.ietf.org/proceedings/09mar/slides/kitten-0.pdf Administrivia. No one bashes the agenda. Working Group Items: -------------------- shawn emery: 6 active drafts gssapi-extensions-iana ---------------------- shawn: needs cleanup of idnits before PROTO-writeup. nico williams: will clean up the nits shawn: will publish the initial registry values to iana shawn: including the delegate if policy permits draft gssapi-channel-bindings ----------------------- shawn: outlined the issues: clarifications and ASN.1 corrections tim polk: will be on April 9th agenda for telechat tim: was asked to proxy the telechat tim: it maybe on 23rd tim: though it will happen in April alexey melnikov: I think leaving the document on April 9th IESG telechat is fine extended-mech-inquiry --------------------- shawn: some comments on memory management issues with buffers and OID sets, but with no response tom yu: memory management issues, will look into in details tom: need furthur investigation/reading alexey: chairs would really like for you to answer Love's question on memory management in this draft ken raeburn: http://www.ietf.org/mail-archive/web/kitten/current/msg01502.html "Memory management is undefined and can be implemented differntly." (Love) ken: Subject: Re: WGLC on draft-ietf-kitten-extended-mech-inquiry-04 ken: posted on 11/16/08 nico: last I recall there are no memory management issues nico: it's all OIDs nico: the API deals in gss_OID and gss_OID_set nico: the memory management for those is defined nico: you never release OIDs because they're always effectively constant (unless you have an implementation that still has gss_str_to_oid()) nico: you do release OID sets martin rex: in GSS-API all OIDs are static, all OID_sets are dynamic nico: if you do have gss_str_to_oid() (like we do) then it's your problem nico: if you have gss_str_to_oid() you need to remember which OIDs were made by calling gss_str_to_oid() nico: you might want to just leak them martin: GSS_Inquire_attrs_for_mech() has 3 output params of type OctetString, these are to be release with gss_release_buffer, I assume nico: no, those are buffers nico: buffers need to be released alexey: adding a couple of sentences won't hurt 0:35:58] so, I see no memory management issues -- though one might want to say that those buffers need to be release nico: RFC2744 says to do that for gss_display_status() results love astrand: should the OID pointers be consts? nico: they are const in RFC2744 ken: for inputs probably yes. nico: and in this I-D for inputs ken: yeah, looking at the c bindings, const is already there, looks okay to me jeff hutzelman: if we are talking about OIDs, effectively consts, I argue the output should be pointers to conts nico: let me check if RFC2744 does that for outputs ken: rfc2744 botches use of const; don't assume it's a good guideline. love: check for implemententations, they are not consts for output? martin: the const were never added back into the rfc2744 sample header file of the C-Bindings nico: not const in the RFC tom: conts GSS OID is a pointer type tom: so CONTS GSS OID is not releveant nico: for outputs our implementation doesn't use const tom: it is not a pointer to CONSTS ken: also gss_OID_set is a pointer type, so again const is irrelevant. love: fine to add pointers to consts nico: true, we should have a gss_const_OID martin: for quite some time the gss_oid_to_str set of conversion functions were in the GSS-APIv2 spec -- we removed them after realizing the memory management problems jeff: recommend to hand offline chairs: agreed ken: uses "const gss_OID_set", and _set is a pointer typedef. so it means "gss_OID_set_desc *const" -- it's irrelevant there. nico: yes, the GSS OID sets returned by the EMI functions are also effectively constant chairs: add one sentense to free buffer tom: inappropriate use of const in the specs has led to implementation problems. chairs: good for last call nico: the GSS OID sets used as inputs are the caller's problem martin: all gss_OID_sets in GSS-API are dynamic and need to be released via gss_release_oid_set (that is the gss_OID_set output parameters, of course) chairs: ready for proto write-up jeff: does "const gss_OID_set foo" mean: "const struct gss_OID_set_desc_struct *foo" or "struct gss_OID_set_desc_struct *const foo" ? jeff: I'm pretty sure whoever wrote the prototype for gss_acquire_cred meant the former nico: yes, there's a bug in the spec using const , it should be const_<...> tom: jhutz, yes, whoever wrote it made the common mistake of assuming that typedefs are equivalent to textual substitution. gssapi-store-cred ----------------- tim: did not have time to read before the meeting tim: go to IETF last call quickly rfc2853bis ---------- tim: same state tim: include summary of changes since 2853 shawn: bis already has these in a separate section ken: section 12 has changes (looking at it now) gssapi-naming-exts ------------------ chairs: need to conclude consensus on flags and oid vs strings for naming-exts chairs: leif will present on proposed updates to gssapi-naming Slides: http://www3.ietf.org/proceedings/09mar/slides/kitten-1.pdf leif: 3 issues: mapped flag: tell attributes authorative and primary vs derived leif: relying parties will have understanding anyway, so it is useless leif: negative flag: nico argued the negative is not well defined leif: should be complete flag, that says the attributes are fully authoritative leif: the attribute values are fully specified, e.g. group memberships nico: it should be "complete" as in "this set of attrs is the full set of attrs you (the relying party) need in order to evaluate DENY ACL entries with groups as the subject" leif: complete flag says there is no other group membership leif: the third issue: OID vis strings as attribute names, OID is unnecessary leif: although it is typically used in GSS leif: we want to interface to name extensions, attributes are not OIDs leif: such as OPEN ID 2.0 attrbutes that are not OIDs leif: should remove "mapped" flag nico: I agree, drop mapped leif: asked the chairs chair: consensus call at the end leif: next slide: negative: change to complete leif: complete works on non-federated deployments nico: well, no, it does work in a federated environment, but with a strong limitation leif: OID vs strings: we should do const char* nico: you must not have DENY ACEs with foreign groups as subjects chair: consensus call starts 1) remove "mapped"? in favor: 3 nico: jhutz: I had hoped that authz attr mapping could be done in the API; now I believe it best belongs above the API nico: jhutz: thus there's no need for mapped unless others disagree (but I think implementors will generally agree) martin: not yet leif: no way to do authz leif: should poll the list chair: continue to poll 2) change 'negative" to complete ken: agree negative->complete ken: also agree oid->string nico: I agree on both questions jeff: nico, I agree I don't see a particular need for mapped, which is why I'm not saying "keep it". But I also don't see a problem with having mapped attributes, which is why I'm also not saying "get rid of it". I'm ambvialent. chair: oid vs strings nico: should we switch to strings to for the extended mech inquiry if we do for this too? martin: as soon as you go printable, the i18n guys come after you nico: I'd like consistency martin: acutally the l10n nico: mrex: these are effectively constant ken: yeah, i was wondering about i18n... leif: i found it difficult nico: leif: can we take this off-line? leif: what made people like OID vs strings chair: maybe OIDs have better context? nico: I like OIDs because the API already uses them, but not because I like OIDs -- as far as I'm concerned OIDs are referred to by symbolic constant names chair: suggest to bring it to list, running out of time chair: give two weeks, then just do it nico: given symbolic constant names I don't really care what the underlying type is nico: therefore I care here only to the extent that I also want consistency leif: interface cannot impose what the mechanism uses leif: take saml, it uses human readable names leif: using OIDs add unnecessary complexity martin: pro-OID: they're unique aka collision-free -- without a registry, contra-OID: hostile to humans, you may end up with several OIDs with almost the same meaning. Since no-one must go to a registry, one might start shipping implementations before talking to others and coming up with a common "spec" or "notion" nico: ideally we'd never use OIDs without symbolic names assigned to them nico: mrex: thus they're not human unfriendly -- but it does turn out to be pointless to have used OIDs for anything other than mechs and name types chair: is there a registry for this? leif: without OIDs, we get away from having a registry nico: I think that extended mech inquiry should switch to whatever naming attrs switches to, if it switches leif: adding attributes without recompiling the code love: other parts use strings, buffer_t etc., inconsistency elsewhere nico: well, in practice there will be no need for any apps other than observability apps to list all attributes without knowing all of them a priori nico: but observability apps matter; so we need at least an API to list the known attributes leif: that is how claimed attributes are developed, not up to the API designers, owned by the community leif: have to be able to use attributes at configuration time leif: strings, don't require creation of another reigstry, but can use existing registries nico: think SSHv2 extension_name@domainname martin: I don't like the idea of guessing how to parse an attribute nico: no, that's what a display function is for nico: we're only talking about what the attribute name itself is jeff: creates interop problems leif: no common attribute registry leif: not getting worse nico: which means I still prefer OIDs by default martin: there's one existing place where GSS-API involves security-relevant printables, and that is "printable names". When those are used, one ought to supply a nametype OID with it in order for the gssapi mechanism to know how to parse it jeff: I don't think EMI should switch; I think the situation is different. EMI properties are fixed for each mechanism, so they're effectively constants in the mechanism code, and it seems like attributes are not. And, they're not going to be defined by other people, only by mechanism designers. nico: jhutz: I think that applies to naming extensions also jeff: I think OID's are a better choice for EMI, even if strings are a better choice for attributes nico: an app will not be doing authorization based on authz attrs it did not know when the app was built jeff: No, I think the idea is that attributes may come from elsewhere entirely, e.g. a SAML attribute certificate jeff: No, but it might be doing authorization based on authz attrs not known when the _mechanism_ was built. nico: well, the mechanism may return blobs, like the Windwos PAC nico: the mech need not know what those are jeff: And actually, yes, it might be doing authz based on attrs not known when it was built; leif was making the argument that attributes might well be mentioned in configuration nico: if you need to interpret an unknown atuhz attr's value... then how do you do that? I can't see the app not caring jeff: I totally can. Authorization is a policy matter. nico: but I see the point now: the authz attr name might exist quite independently of the GSS-API OID namespaces martin: I would assume that GSS-API would only be used to "get access to" _complex_ authorizations in a standardized fashion, and the actual parsing/interpretation would be up to some other middleware or the app -- in which case, the authorization data should be clearly tagged (and otherwise opaque to gssapi) nico: yes, basically nico: jhutz convinced me, for naming we want something other than OIDs chair: leif will post the question on the list and ask for a consensus call draft-lha-gssapi-delegate-policy -------------------------------- chair: delegation if policy permits by love, currently in AD evaluation tim: not in the tracker, will look into this Charter/Milestones ------------------ shawn: on charter items shawn: need volunteers/momentum behind: Updates to v2 RFCs: Guidance for mechanism and application protocol designers. Thread safety. C-binding clarifications (types, name space, etc.). ken: I can think about thread safety and c-binding ones, if there's really interest; don't remember specifically what we were going to say though shawn: still need to remove C# binding as work item shawn: on to milestones: shawn: naming-exts: working group last call, first week of may? leif: if reviewed and no new issues, yes Open mic: ========= No open questions. Session Over =============