72nd IETF - Kitten Working Group Minutes ======================================== Location: Dublin, Ireland - Citywest Hotel Time: 7/30/08 at 17:40-18:40 Local time Co-Chairs: Alexey Melnikov Shawn Emery Scribe: Jeffrey Hutzelman Security Area Director: Tim Polk Action Items: ============= Co-chairs: Send notice for WGLC on draft-ietf-kitten-gssapi-extensions-iana Co-chairs: Send notice for WGLC on draft-ietf-kitten-extended-mech-inquiry on 8/20/08 Co-chairs: PROTO write-up for draft-ietf-kitten-gssapi-channel-bindings Co-chairs: Resolve 2853bis exclusion of Subject API(s). Leif Johansson: Send to list for discussion on naming extensions draft for the following questions: Should we keep the mapping flag? Is there a need for a negative attribute? How we should register OIDs? Conference Session: =================== Slides for this session are available at https://datatracker.ietf.org/meeting/72/materials.html#wg-kitten Comments begin with '//' // draft updates // gssapi-extensions-iana jhutz: nico, want to talk about IANA extensions? nico: yes, I want to get it done jhutz: what needs to get done in that doc? nico: last submitted on Mar 25, no I don't have updates, and there have been no comments jhutz: do you need re-review from iana experts? nico: no, I need review from the wg jhutz: tim says, sounds like it's ready for WGLC // extended-mech-inquiry jhutz: any updates on extended mech inq? is it ready for WGLC? nico: IIRC I updated those jhutz: yes. so, is it ready? nico: yes, it should be ready jhutz: chair: will wglc that, too // java-bindings jhutz: WGLC ended today on java bindings shawn: There was a question on the alias on why the API does not support access to Subject objects. nico: IIRC jaltman got an agreement that the IETF would own this, this was something like two years ago. The liason used to be, informally, Seema Malkani jhutz: leifj: there is no formal liason listed on the liason page leifj: https://datatracker.ietf.org/liaison/managers jhutz: shawn: we'll hold up on the proto writeup for now, until those issues are resolved // naming-extensions jhutz: next, naming extensions nico: BTW, the latest version of PKU2U should be read by anyone interested in leif: presented update on naming extensions nico: I think the idea was to move PKI parts into their own doc leif: questions on naming extensions: Are the criticality and mapping flags needed? Are negative attributes needed? Should we use OIDs, if so then how are they managed? leif: in regards to criticality, user has previously authenticated, so criticality has already been made as a pre-requisite. nico: interesting; good point about criticality // naming-extensions on mapping jhutz: hartmans: mapping seems like a useful feature; why do you not want it? jhutz: hartmans: what are primary sources and what are derived data? In some cases I only want to look at the former. jhutz: leif: If I wire up my GSS stack so it grabs attributes from the directory, it'll have no way of knowing the displayName is mapped. jhutz: hartmans: I'd say all attributes from the directory are mapped; they don't come from the authentication mech jhutz: hartmans: yes, it's a simplified concept; there are more complex ideas behind it. jhutz: hartmans: we're trying to simplify jhutz: leifj: I've never seen an example of an attribute consumer that cares. mrex: Thinking about it, I'm not very happy about the term "naming extensions". The authentication of the peer is done by the existing gssapi services, and populating (name-based) ACLs is possible without an authentication mrex: inquiring attributes connected to the identity that pop up along with an authentication are OK, but something entirely different jhutz: leifj: I agree the authenticated/asserted bit is something you want; this is different. jhutz: hartmans: I understand the difference nico: sam: if the directory and the credential issuer are the same nico: then the mapped flag has little value nico: if they are not, then it does jhutz: leifj: I still think this is too simplistic nico: there will be symbolic names for all OIDs jhutz: hartmans: I don't buy "too simplistic" as an argument for removing something jhutz: leifj: I'd like to have an example where it's useful. jhutz: hartmans: One case is for debugging; I want to be able to print what I got from the auth mech separate from what the platform has added jhutz: hartmans: If the platform has decomposed a PAC or come up with a set of UNIX groups based on other sources, I'd like to be able to separate that out and tell what's actually from the auth mech. jhutz: leifj: The things that the auth mech provides you will be asserted. jhutz: hartmans: No, that's not what asserted meant. Asserted is things the other party provided that were not verified by the auth mech. jhutz: hartmans: A PAC is not asserted; it is authenticated. nico: asserted means provided by the issuer jhutz: hartmans: For example, a PAC would be authenticated, but the set of group memberships your platform decomposed it into is mapped. nico: provided by the app nico: authenticated meant provided by the issuer shawn: take mapping flag question to the list nico: ok, on the list // naming-extensions on OIDs nico: OIDs should never be seen by the apps nico: the OIDs will have symbolic names mrex: whether you call it "group membership", "attribute" or "attribute oid" doesn't really matter nico: leifj: the OID issue is a non-issue mrex: OIDs can easily be stuffed into X.509 certs and they're already available as datatype at the GSS-API. mrex: At the UI, however, naked OIDs are fairly evil to humans to OID's mrex: A PAC from a Microsoft Kerberos KDC will likely contain SIDS (128-bit values) rather than OIDs nico: BTW, my platform now uses SIDs, and will use SIDs more extensibly in the future, so I may not need mapped attributes :) nico: mrex: yes, no OIDs in the UI nico: OIDs need human-readable names nico: and symbolic names for developers nico: I had lzily re-used the existing GSS-API type for this nico: lazily, even nico: if only there was an OID resolution protocol... nico: (we could use DNS for that, I suppose...) jhutz: we're not doing that tlyu: http://www.ops.ietf.org/lists/namedroppers/namedroppers.2000/msg00574.html nico: well, as I recall we had solutions for the UI issues, personally, I don't care, I'll be happy either way mrex: OIDs have low probability of collision (unless someone goes out kidnapping OID arcs of others). There is a better chance of finding the originator for an unrecognized through the OID arc structure, and the (emergency) fallback on the naked OID may help transition mrex: but are OIDs sufficient as binary values (present/absent) rather than attribute-value-assertion type of authorizations? // naming-extension on negative attributes jhutz: nico, any objections to removing negative attrs? nico: what were they>? nico: were they DENY ACE related? jhutz: apparently no one knows what negative attributes are mrex: having the negative-entries on ACLs might be sufficient to represent DENY ACEs, that doesn't require negative attribute values nico: mrex: I was wondering if they were attributes usable ONLY for DENY ACEs // Extended Mechanism Negotiation larry: presented Extended Mechanism Negotiation hartmans: O, cool, Nico here are your federation selectors etc. nico: yes nico: we all have the same problems, don't we larry: difficulties encountered with trying to use pku2u under spnego, and related things such as wanting to use certificates as decision criteria for choosing a mechanism...] mrex: what kind of meta-data? A Bag of ASN.1-OID tagged "ANY defined by" blobs? nico: mrex: one interesting one is "name of federation" hartmans: For PkU2U, the set of trust anchors. jhutz: (I'd answer, but I haven't read it yet, so I don't know either) hartmans: Um, I'm not sure why you want RFC3961 not gss_getmic jhutz: Depends on where you are. If you've negotiated a shared secret, you want 3961. If you're still depending on the lower mech, you want gss_getmic. I suspect negoex wants the latter. Ken Raeburn: how does a gss mech "support rfc3961"? nico: yes, RFC3961 is krb5-specific -- it could be re-used, but I'd rather re-use RFC4121 constructs jhutz: No. Not 4121. GSS-API mrex: the data formats for metadata in draft-zhu-negoex-01 look _quite_ complicated to me. mrex: the reason why prot_ready is not offered because many mechanisms do not have shared keying material that early in the handshake nico: GSS_Pseudo_random() mrex: What about independent GSS-API mechanisms that want to send/include competing meta-data? nico: no mrex: by NOT making the meta-data mechanism dependent, there should be value in sharing meta-data ====================== Session Over