Last Modified: 2005-02-07
| Nov 04 | First Meeting | |
| Mar 05 | First drafts of either 'Clarifications to GSSAPIv2' as Informational ORsubmit 'Generic Security Service Application Program Interface Version 2, Update 2' and 'Generic Security Service API Version 2, Update 2 : C-bindings' to the IESG as Proposed Standard | |
| Jul 05 | Submit either 'Clarifications to GSSAPIv2' as Informational OR submit 'Generic Security Service Application Program Interface Version 2, Update 2' and 'Generic Security Service API Version 2, Update 2 : C-bindings' to the IESG as Proposed Standard | |
| Jul 05 | Submit 'The Channel Conjunction Mechanism (CCM) for the GSSAPI' to the IESG as Proposed Standard | |
| Jul 05 | Submit 'On the Use of Channel Bindings to Secure Channels' to the IESG as Proposed Standard | |
| Jul 05 | Submit 'The Simple and Protected GSS-API Negotiation Mechanism (Revised)' to the IESG as Proposed Standard | |
| Nov 05 | Submit 'GSSAPI Mechanisms without a Unique Canonical Name' to the IESG as Proposed Standard | |
| Jul 06 | Submit 'Generic Security Service Application Program Interface Version 3' to the IESG as Proposed Standard | |
| Jul 06 | Submit 'Generic Security Service API Version 3 : C-bindings' to the IESG as Proposed Standard | |
| Jul 06 | Submit 'Generic Security Service API Version 3 : Java and C# bindings' to the IESG as Proposed Standard | |
| Nov 06 | Charter Review |
|
IETF62 Minutes for Kitten Working Group
======================================= Wednesday, March 9 2005 1:00-3:00 Central Standard Time. Chairperson: Jeffrey Altman Thanks to Jeffrey Hutzelman and Nico Williams for Jabber Scribing Thanks to Love Hörnquist Åstrand for taking notes. agenda bashing: no comments Larry Zhu updates on SPNEGO: - sent to IESG, Last Call ends March 22. - implementations include Longhorn beta 1, Heimdal, and a future update to solaris 10 - there is no open issues; please read draft - no questions - first document from kitten, beats the milestone. - a big thanks to Larry Nico Williams update on several documents: - PRF extentions * edits from last meeting folded into -01 * PRF_READY added in -02 * ready for last call (draft-ietf-kitten-gssapi-prf-02.txt) - Kerberos side of PRF, same comments * edits from last meeting folded into -01 * No PRF_READY * don't use PROT_READY * can call PRF as soon as you want. if the PRF isn't ready, the function will return gss_not_avaible. * ready for last call (draft-ietf-kitten-krb5-gssapi-prf-02.txt) - GSS Domain based names * folded in edits from last meeting * Seems to be ready for last call, less review then the PRF documents. should wait if there are some comments. - Kerberos domain names * folded in edits from last meeting * realm derivation changed - realm is derived from the domain part of the domain-based name, not the host part * Seems to be ready for last call, less review then the PRF documents. should wait if there are some comments. - Stackable pseudeo mech and extended mech inquiry APIs * originally a single documetn individual submission draft-williams-gssapi-stackable-pseudo-mechs-00.txt now split into to two: draft-ietf-kitten-extended-mech-inquiry-00.txt draft-ietf-kitten-stackable-pseudo-mechs-00.txt * Both drafts needs review. Esp with the some issues from the document split. * Stackable mechs very simple concept. - Guide to the GSS-APIv3 * Not many changes; just naming draft. - IANA registry draft * currently only has text about what submissions look like. no rules, no initial content. * talked to IANA - they would like to see a section with allocation rules, and an appendix with initial content. * overloading all the information into a single registry may or may not be the right way to do it; I don't know. * like to get some feedback on document * Nico will work with the chair to work out IANA details - Channel bindings draft from NFSv4 WG * for ipsec, we still need to decide what channel bindings are going to be. draft in kitten tells you. this needs some review. * draft not ready for last call * lots of discussion about where the definition of protocol specific bindings belong + hartmans: defining protocol specific channel bindings not in the charter for Kitten or BTNS; and Russ has objected. IPSec is not accepting new work. I think it should be done as ain individual submission. nico: OK, but not what we discussed before. - Comments for Nico: * channel bindings + Love: how can a protocol running on top of gss do channel bindings to gss? + Nico reply: its there in the NFSv4 draft, but could be done better. * IANA + hartmans: uneasy about having to register every gss_ symbol with iana + Chair: this topic needs to go to list, not enough people have read the draft + Matt Peterson: what was IANA's response to being asked to do api registry + Nico: IANA doesn't care about what being registered, then just want to be told how to do it. + Chair: The question is "what do we want to have done by standards actions?" One benefit of registries is having a place people can look + Nico: part of this discussion is to allow for vendor-specific extensions Sam Hartman updates GSS Naming: - draft-ietf-kitten-gss-naming-01.txt - the goal is to be a direction statement to describe the problems we're trying to solve, and approaches we're considering - received a lot of comments from nico - hoping to get comments from Martin Rex, but so far he has never actually responded directly to this draft - I think -02 will be ready for last call. There is one issue I'd like to get some discussion on today. * currrently today, names are atoms - indivisible strings with no structure * one proposal is to turn them into sets and/or sequences + <missed discussion> + nico & I think we'll probably need to do that anyway * another proposal... allow us to choose the initiator name based on what target we're talking to. can't currently do that. there is some desire in kerberos to be able to do that * another issue that came up, which we have no closure on yet... + mechanisms that can assert multiple identities + example - X.509 mech, you may have multiple subjectAltName you may want to say which of these names you want to claim for a given context for pure (GSSAPI) v3 mechanisms being used by V3 apps (understand composite names), you probably don't need it do we want something like this for v2 applications + I believe if we can solve that issue, we can last call -02 + nico: how to do that is easy. whether we want to do that is another story I believe spkm had a thing where you could assert a Name in its tokens from a v3 POV, that's irrelevant + unless someone comes forward and says they want to do that,we're not going to. If you care, you need to speak up by end of WGLC. + nico: your draft is informational... + at this time, it doesn't make sense for me to be editor of a document...maybe if my day job had less management work...do we want to poll the room, see people interested in being doc editors? Nico would do a good job, but have lots of docs on your plate + jaltman: I as chair would be more comfortable with load spread out. + matt peterson volunteering someone from his organization + jaltman: no other volunteers Update java and C# bindings - neither of the authors were able to come to this ietf - two new documents: * draft-ietf-kitten-gssapi-rfc2853-update-for-csharp-00.txt * draft-ietf-kitten-rfc2853bis-00.txt - c# - submitted from novell, new editor * describes how to morph 2853 java bindings for c# * very little discussion of this doc. novell is in the process of implementing; if others are interested, we'd love to hear your opinions - second doc (RFC2853bis) describes what things in RFC2853 were implemented differently in the Java Class Libraries from what's in the spec. - the document is in good shape. - next step is to merge the two drafts. - nico: do you have an editor for that? - yes; one from Sun (Seema Malkani), one from Novell (Juan Carlos Luciani) - hartmans: a little concerned about style/format of these docs I don't think IETF spec by diff works - the next step is to merge these and rfc2853 into a new doc that would obsolete the old one Open mike: [Editor's note - This discussion did not belong in Kitten] [The contents of this section are stolen from the Jabber logs] joe salowey: the topics that have been coming up lately. ISM WG, enhancements to EAP, EAP has been held to be not applicable we're looking to see if the GSS-API is applicable this is a heads up about interest in this also I'm looking at a number of IETF auth frameworks (SASL, GSS, EAP...), at some point we should look at merging these things some of the GSS v3 enhancements could help (PRF, Naming, ...) sam hartman: so we seem to have some time left joe brought up some interesting points this is very much half-baked, joe's the primary instigator we have a miserable situation in the IETF w/ sec mechs (long list of technologies) and one-off mechs too you know, hash stuff and SSH! and so there's a kind of matrix: if I pick this protocol, what auth techs can I use some are very limited (HTTP has ...) blah, blah and really, the way I want the matrix to look is: regardless of what protocol I pick I can use any mech I want because if I do that I only have to get security right once in my organization so, to get folks thinking about this all these mechs do roughly the same thing you're stopped by small problems of standardization and programming we can do the standardization here so I'm going to compare everything to GSS cause we're here now EAP is like GSS but the server send first token no wrap/unwrap the mechs folks use today have a "key fallout" two keys, actually EAP has a better developed sense of .... naming/channel binding their concept of channel binding may map onto our concept of naming their client ID is weaker than our names but more useful there are stackable pseudo-mechs for EAP and when you do that you need channel bindings between layers they call that cryptographic binding they have a description language for the sec properties of their mechs SASL is like GSS but lacks the PRF, its concept of naming is not as well developed, except when doing GSS it has this funky thing called an authorization ID SASL supports either the client or server as initiators of the exchange this depends on the protocol and the mechanism I think this is even as bad as implementation dependent GSS is a lot like GSS (laughter) For EAP the negotiation model is that the server decides what mech to use for SASL the client generally picks from a list offered by the server w/o downgrade attack ("bidding down") you can abort in the middle of auth for GSS we have SPENGO SPNEGO if you don't know how it works, now's the time to find out! SSH I like the client and server shout at each other offers the client picks one and the server rejects or the key exchange fails the client loses the key exchange ends in two things: a key and an exchange hash and ssh authenticates the server to the client this protocol doesn't have a good concept of naming pubkeys are not named then there's the ssh user authentication protocol this has something like the SASL authz IDthe client tries one mech then the server tells whether we can do this or are done or how to continue the client needs to know what it's tried so it doesn't try again Jeffrey Hutzelman: this is all implementation dependent the client has to keep trying until it can't go on or succeeds Sam: TLS supports pubkey certs, PSK and it supports Kerberos, sortof (details) are there any other actual authentication frameworks in IETF...? MIKEY has some authentication goop Uri Blumenthal: MIKEY is good, but it's multicast specific it's auth deals in multicast key distribution -- Kerberos, EAP, etc...wouldn't be aplicable [details lost] Sam: consider using certs to get access to the multicast stream and consider that MMUSIC uses MIKEY to configure unicast streams if I was an admin I'd be annoyed if MIKEY didn't support the mechanism I wanted [details lost] Sam: I want to be able to use any mechanism in any app Jeffrey Hutzelman: so you want developers to be able to pick the most applicable framework for their protocol, but be able to use any mech Sam: exactly jhutz: so mech gateways Sam: that's one way I want a solution, but I'm not particularly interested in any one of them Joe: I'd rather see these mechs (new mechs) developed together for all frameworks rather than rely on 'gateways' ... Sam: long term I'd like to live in a world where ppl know about gateways and new mechs will work through them all but basically I agree with you that if the gateways are not easily workable, then it might not fly so my assumption is that we can get the gateways to get to the point where they'll meet most folks' needs and then look at mechs-all-at-once Joe: it would be more efficient to design the mechs with these different frameworks in mind Mark: I don't necessarily want to know what mechs I'll be using, I need to know what capabilities I need and what caps each mech offers nico's draft may be a start point it goes a bit deeper than that we need to be able to plug-in mechs the framework implementations have to be pluggable I'm wondering if the WG can do anything about this and refining the semantics of the default mech (GSS_C_NULL_OID) Sam and Mark argue about sysadmin vs. app policy Sam: I think this is moving into a different topic I'm happy to do that, but... Chair: Joe, any more questions? Joe: I'd like to explore the idea of developing mechs in parallel. Sam: want to be able to reuse as much of the mech spec and implementation as possible don't want to have case statements in spec Uri: it would be good if mechs would just perform a few extra tasks export identities, exact crypto protections it uses, key material this is why people are looking at eap Sam: we think we have the generic keying material in the GSS PRF we'd like your review Uri: already sent some comments Nico: quick response to uri for some mechs, we won't know in advance what it uses. e.g. kerberos for others, we know up front what it will use current gssapi qop concept is badly broken Uri: in some protocols, access control is based on identity, accessed object, and under what sort of protection Nico: wow, this is an interesting meeting! Chair: what I was hearing is there's a desire to define a base set of operations on which things can be built is that right? if so, where? not in kitten's charter Bob Morgan: another distinguishing factor is integration model one of sasl's successes is it makes it clear how to integrate into app proto gssapi - not sure what integration model is Sam: gss is clearly a lot of rope all of these frameworks meet different app domains it's interesting that the mechs are very similar, even though the frameworks are very different Bob Morgan: maybe different frameworks come from different needed integration models Sam: if you want an easy integration model, use sasl if you understand your needs really well and have complex requirements, use gss Nico: matt, the default mech/mech set don't have to be global config file as in Solaris the right default is "whatever mechs you have credentials for" the right default mech is "the first one for which you have credentials" Matt Peterson: what if you have creds for more than one mech Nico: either it's nondeterministic or its the first one I know you want this to be app-specific config, but I don't feel not sympathetic - you can make app provide the right oid Matt: ... Nico: what I hear you saying is you want pluggable mechanisms we can't tell people to do that. there are monolithic and pluggable multi-mech implementations, and ther eare single-mech implementations Chair: do you have specific platforms in mind? Matt: for example, aix or some mobile thing, where I want to port my app Chair: you're always going to have something older that doesn't have the functionality Milestones (Chair): - we're not making the milestone on GSS-API _v2_ clarifications * hartmans: as an individual, it's not clear we want to do v2 clarifications * is it worth reviewing and clarifying GSS-APIv2 update 1 * wyllys: It seems like an extra step and maybe not necessary. * jhutz: are you asking if GSS-APIv2 update 2 is worth doing? * no, the clarifications would be for inclusion into the v3 document * wyllys: oh, thats a little different. * all the various little issues that we talked about on the list * we need someone to volunteer to go through the CAT and KRB mailing lists and collect all of the details from the discussions which lead to the formation of this working group * Matt Peterson will assign one of Vintela's people to go over the archive and compile the complaints. * Update this milestone to May 2005. - No need to revise the other milestones since we are making good progress. Done. |