[08:22:50] --- SimonJosefsson has joined [10:01:34] --- kdz has joined [10:01:35] --- tlyu has joined [10:04:30] --- hartmans@jis.mit.edu/owl has joined [10:07:47] --- cyrus has joined [10:08:16] --- ietf-meeting has joined [10:10:00] Cyrus will jabber. [10:10:19] As long as the servers stay up. [10:10:45] Agenda bash - any changes? [10:10:58] Document status: [10:11:05] crammd5 expired [10:11:16] gs2 issues remain [10:11:22] 2831bis to historic [10:11:29] password-auth - expired [10:11:37] hexa merged with scram [10:11:54] scram - talk on in a minute [10:12:04] yap - independent submission [10:12:22] On cram : last called a year ago. Chairs owe a response. [10:12:33] Chairs will get to this soon. [10:13:08] Document will need refresh. [10:13:54] --- jhutz has joined [10:14:13] Charter update: [10:14:14] --- nico has joined [10:14:18] Issues to address: [10:14:23] --- semery has joined [10:14:34] Milestones are already late. Need to be adjusted. [10:14:35] Slides available on the IETF web site at https://datatracker.ietf.org/meeting/71/materials.html#wg-sasl [10:14:45] Also via anonymous VNC to ietf-vnc.central.org:0 [10:14:50] Push back existing ones by 3 - 4 months [10:15:13] Other issue: questions on what was the impact of replacing digest-md5 [10:15:42] Need to show IESG that WG understands the problem that it is trying to solve. [10:16:24] Need more discussion about Chris N's properties on new mechanism. [10:17:54] Talking about Chris' email to list today. [10:18:53] Thanks cyrus [10:19:23] Comments on this email please... [10:19:34] Is this a good summary for the WG? [10:20:04] Alexey agrees - some minor comments about priority. [10:20:11] Are the chair mics on? [10:20:59] Kurt - mostly agrees. Might want to debate some of the realm stuff. [10:21:48] No objections for adopting this in the room. [10:22:23] Too long for the charter though. So need to wordsmith some sentences for the charter. [10:22:58] Anyone actually want it verbatim in the charter? [10:23:32] Kurt prefers shorter version. [10:24:34] Tim (AD) - probably don't want this in the charter as-is. Should come up with a couple of sentences summarizing this. [10:25:23] Drop in a few "buzz words" from Chris' list. [10:26:02] Some comments along the line of "resistant to X, Y, Z" are needed. [10:26:34] --- kmurchison has joined [10:26:46] Text should describe how the WG wants to improve on current mechanism. [10:28:01] Technical discussion. [10:28:10] Have we agreed on SCRAM as Digest replacement? [10:28:16] Have we consider all the options? [10:28:41] Kurt - need to know whether Simon wants to continue with his work. [10:29:33] Nico - if we do SCRAM or YAP etc - can see why we might do a GSS mechanism that does the same thing. Doesn't see why we would do it in GS2. [10:29:59] Why have SCARM available in two different ways in SASL. [10:30:25] Jeff: either we do pure SASL, or we do something for SASL or GSSAPI. [10:30:49] If we do the later then we want SASL mech and GS2 mech to be the same over the wire. [10:31:26] We need something like this in GSS (e.f. for NFSv4 etc ) [10:31:53] Simon's mechanism will work with GS2 no matter what. [10:32:09] If we also do our own we have two ways - will lead to confusion. [10:32:51] Figure out a way to do one mech with either framework. [10:33:09] Nico - abandon the channel binding with have in GS2. [10:33:19] I don't follow Nico's point here [10:33:43] Sam - does not see why that is so [10:33:48] Me either [10:33:49] cyrus: that's not quite what I said [10:34:35] Nico - rationale is - if GSS only channel bindings - then can use those in GS2 - but need the same in SCRAM so ity is effectively a GS2 mech. [10:35:02] Sam - still can't see how this is related. [10:35:40] Chris: if we have two mechanisms - one GS one not - its not the end of the world so long as the server does the same thing on the backend. [10:36:14] If SCRAM happens, as a native SASL mechanism, I don't think anyone will use a password-based GSS-API mechanism via GS2 in SASL [10:36:25] Question is whether its more complicated than binary goo in the mech name. [10:36:35] If it is, that would not be good. [10:38:16] Jeff - having two names for the same is bad - having two separate mechanisms is worse. [10:39:27] A special name in GS2 requires all clients/servers to understand the name mapping . [10:40:19] Nico - prefers GSSAPI to return a SASL "friendly" name. [10:40:35] This is currently outside of SASL and Kitten right now. [10:42:05] Spending two much time on what the name(s) are going to be. Spend mor time on the mechanism itself. [10:43:12] Nico - GS2 now is "frozen" for Kerberos. Do simple GS2 later once SCRAM is doen. [10:44:26] Sam - discussing the wrong issue here. Should be talking about Simon's mechanism vs SCRAM as the basis for our work. [10:45:34] Nico - want to offer a way forward to do GS2 and SASL without the complexity of the current GS2 (channel binding semantic) [10:46:20] Chris - GS2 is too complicated with a simple password mechansim. [10:48:05] Sam - wants people who believe GS2 is too complicated to raise real technical objections. [10:49:32] Chris - as an implementer does not want to get mixed up with GSSAPI stacks. Could live with some simple binary goo - but ASN.1 is bad. [10:50:18] Chris - wants to see what GS2 looks like over the wire. [10:50:50] The on-wire complexity in GS2 is due to security layers [10:51:09] Nico - GS2 just like regular digest exchange but you need the session key as well. [10:51:47] Wrap token should be simple to generate (addition HMAC etc). [10:53:25] Jeff - do we have the problem even if it is not GS2? [10:54:00] Chris - underlying concern is deployability. The more complex it is on the wire the harder it will be for implementers to get right. Digest vs Cram is an example of this. [10:54:40] How much additional goo beyond an ascii hex encoded will we have? [10:55:38] Nico - extra complexity is in GS2. [10:56:23] Sam - someone should write up what a packet would look like in GS2 case. [10:56:54] Sam - If we avoid optional roundtrips in GS2, the packets are not complicated. [10:57:19] You talked about "you need to derive a key" and "you need a wrap token". But a wrap token here is just a hash, and we're hashing the channel bindings, so it's a hash of channel bindings that would need to be there even in a pure-SASL mech, if it's going to support channel bindings. [10:57:36] And if that hash needs to use a derived key, then that was true even for a pure SASL mechanism. [10:57:38] RFC 2743 section 3.1 is the GSS-API token format, and it is only required for exactly one message: the initial token. [10:58:30] Sam - small tweak to GS2 could avoid the optional features, add fixed packets lengths etc [10:59:10] Nico - happy with that, except that if we have SCRAM used in GS2 as well there will be some extra complexity in SCRAM as a result. [10:59:31] The difference between the GS2 mechanism and the pure SASL mechanism, _for SASL implementors_, is that in the GS2 mechanism the first token must include a binary blob at the front which corresponds to the GSS-API context token framing, because GSS-API requires that for standards track mechanisms. [10:59:36] Kurt - wants a simple mechanism described in ABNF... [11:00:21] GSS looks like ASN.1 - but it is not really ASN.1 - does not need to understand DER. [11:01:45] Now, for GSS-API implementors (not SASL implementors, and not people using GS2 with this mech), the mechanism probably needs to provide wrap and MIC tokens, channel bindings, and so on, to make it useful to GSS-API callers other than GS2. But that doesn't impact SASL. [11:01:46] Kurt - wants someone to write email to describe the over the wire packets. [11:01:59] Sam - will do that but would like a volunteer to help. [11:02:06] Nico - will help. [11:02:15] Kurt as well. [11:02:29] I can help with that. It is quite easy to do so [11:03:19] Can we make the decision on password vs SCRAM? [11:03:24] now. [11:05:20] I offered the draft to the WG a long time ago [11:05:45] Would Simon be willing to server as editor for a WG document? [11:05:47] --- Chris Newman has joined [11:06:15] Yes [11:06:48] I think Chris Newman's comments are very good though, and that we need to explain things better. It probably requires help from others [11:06:51] (there seems to be quite some lag) [11:07:33] Need to look at the complexity trade-offs first before we can make the Simon mechanism vs SCRAM decision. [11:08:57] It may be possible to write a GSS-API profile of SCRAM. Then we have the simplicity of SCRAM and the functionality of a GSS-API mechanism and everyone is happy [11:09:17] Chris - there will be pressure to align the two - would be better to ask which editors are going to have enough time to work on this. [11:10:06] Jeff - we should nominate a small group (Simon + one SCRAM author + one other) to write up a comparison between the two specs. [11:11:16] Alexey - volunteers to heklp co-edit SCRAM. [11:11:29] I looked at the SCRAM document more now, and I think it is in better shape than mine. [11:13:33] Sam & Nico will try and explain how to turn "pure" SASL mechanism into GS2 SASL mechanism. [11:14:28] If we form such a group as I describe, Simon, would you be able to be part of that, and help produce a comparison in, say, 1 month? [11:14:57] Can the authors actually merge the two documents? [11:15:26] Simon? [11:15:32] I think so, yes. [11:15:32] ... or to produce a merged document? [11:15:41] (note the proposed timeframe is mine, not the room's) [11:15:48] Merging the document seems like a good idea [11:16:19] Alexey volunteers from the SCRAM camp. [11:16:25] Chris will also help out. [11:17:25] So: Alexey, Simon and Chris will be tasked to produce a document that matches Chris' points based on the two existing docs. [11:17:39] end of april would work for me [11:17:55] The question has been asked, in what timeframe (to -00 ID or equiv) [11:18:07] May 1 [11:18:10] Chairs choose May 1st. [11:18:26] Is this OK with everyone? [11:18:43] sounds fine! [11:18:45] No objections heard or typed. [11:19:46] It has to be in solid state? An on-disk copy isn't good enough? [11:20:09] Digest-to-historic - Kurt would like a normative reference to "new" SCRAM and let it sit until the new doc is done. [11:22:37] SACRED uses digest-md5 in a mandatory to implement fashion [11:23:21] Moving SASL digest-md5 to historic has no impact on http-digest which is actively used in the SIP community [11:23:22] however, i'm not aware of significant sacred deployment. and there are digest-md5 interop problems [11:26:27] Cyrus - what about HTTP AUTH? [11:26:35] Why isn't HTTP digest going to historic? [11:26:42] Can we adapt SCRAM to HTTP AUTH? [11:27:03] Chris - yes should be applicable to HTTP AUTH but not in this WG. [11:27:39] i'm not sure HTTP AUTH compatibility should be a requirement for us. I'm not familiar with http authentication discussions, so we would need input from them [11:28:09] Answers - http-digest to historic is not this WG's call [11:28:26] (them = http auth people) [11:28:37] Alexey - Frank's comments may be included in the doc. [11:28:46] we will not be doing http auth in this WG; it's out of scope for us. [11:29:05] Our document should give example of problem areas but does not need to be complete. [11:29:08] If SCRAM is to have a chance of viability it has to be available in CalDAV and CardDAV. Since we're moving away from the "SL" part of "SASL", doing an "SA" binding into the HTTP authentication framework becomes straightforward and would suffice. [11:29:41] But that's something for the HTTP community to decide rather than this group. [11:29:42] Well, the thing is it's not just "SA", it's "SACB". [11:29:56] Alexey will review Frank's comments to see what if anything should be included in our document. [11:30:22] As long as we get sufficient review from people who want this to be used in http, that's fine. [11:30:25] Right -- it's up to the http community to decide what to do, and I think they are leaning in a direction that would make SCRAM "just work" for http by virtue of its being a SASL and GSS mech (I don't know which matters) [11:30:52] Moving on... [11:31:11] Hold GS2 for SCRAM? [11:31:15] BTW, I do not think the viability of a SASL mechanism depends on the availability of a similar mechanism for non-SASL applications. [11:31:32] I would be concerned if we need to delay scram because we have to wait for http people to decide how next generation http authentication is going to work [11:31:49] I don't see any reason why we should delay scram for that. [11:32:01] Great [11:32:10] Sam - question: if basing a mechanism off GS2 might be good to hold GS2 until that is done once so we know it will work and can do any needed changes to GS2. [11:32:27] Sam - recommends holding GS2 for now. [11:33:05] Sam - objections were that that might hold up GS2 implementations. [11:33:23] Comments anyone? [11:33:42] i don't care strongly either way. i will not implement gs2 until it is in the rfc editor's queue [11:34:18] Alexey - would prefer to see another GS2 mechanism as an example. [11:35:15] there is also my suggestion to publish gs2 only for kerberos now to gain implementation feedback [11:35:20] i would implement gs2-for-kerberos [11:36:10] Another option would be to publish GS2 as experimental now. [11:36:20] Some people think this would be worse. [11:37:31] Kurt - lets wait until Dublin as we will have a better feel for how long scram etc will take. [11:38:09] the experiment could be to see if it works with non-kerberos mechanisms [11:39:25] to clarify: determine by Dublin whether how, if at all, SCAM will impact GS2 and make a decision at then on how much longer to hold GS2. [11:39:27] Jeff - does not like the idea of publishing as an experiment where the intent is to re-publish. [11:39:43] That's not exactly what I said [11:39:43] i don't understand the objection against publishing gs2 for kerberos only? [11:39:55] I don't like publishing as experimental when there isn't any real experiment. [11:41:47] Sam - objects to GS2 only for Kerberos - as we might end up with three things to implement or have to special case. [11:42:09] i don't understand sam's objection. either gs2-for-kerberos is perfect, and we're done, or we need to revise it anyway [11:43:53] Chris - there are already three deployed ways to do Kerberos. [11:45:29] we need special-casing anyway, because of the "GSSAPI" SASL mechanism [11:46:18] Nico - revising position to hold it for now. [11:46:26] No, because no one's suggesting not using GS2 with Kerberos [11:46:41] The intent is that we _will_ use GS2 with kerberos, and deprecate "GSSAPI". [11:46:50] We don't want to do that, and then do it again when we publish GS3. [11:46:58] we don't want to multiply special cases either [11:47:13] We also don't want to publish GS2-for-kerberos, and then say "don't use GS3 with kerberos", requiring everyone to special-case kerberos wrt GS3. [11:47:32] Kurt - seems like there is rough consensus to hold. Will propose that to the mailing list. [11:47:35] And we _also_ don't want to have GS2-kerberos and GS3-kerberos and everyone has to implement both because someone might only implement one. [11:47:51] i don't think we can just forget about GSSAPI. it is deployed. so all future sasl-gssapi bridges need to mention it [11:47:59] Is anyone using the VNC? [11:49:20] Moving item... [11:49:38] 4422bis - no work has been done. Kurt will publish a new id shortly. [11:49:58] Interop report: very little work done. Hopefully get to that before Dublin. [11:50:06] On to milestones: [11:51:52] Will add 4 months to everything and adjust as per items today and post to mailing list for discussion. [11:52:14] Any other issues? [11:53:09] Netconf is working on a SASL profile - they need help. [11:57:15] i'm interested in remote interop testing [11:58:10] --- kdz has left [11:59:13] --- tlyu has left [12:00:12] All done... [12:00:21] --- nico has left [12:00:26] --- cyrus has left [12:01:52] --- SimonJosefsson has left [12:02:36] --- ietf-meeting has left [12:03:06] --- semery has left [12:05:35] --- jhutz has left [12:06:47] --- Chris Newman has left [12:19:59] --- Chris Newman has joined [12:22:38] --- Chris Newman has left: Replaced by new connection [12:58:37] --- Chris Newman has joined [13:07:00] --- Chris Newman has left