[13:08:13] metricamerica joins the room [13:13:49] jhutz@jis.mit.edu/owl joins the room [13:17:06] tlyu joins the room [13:17:15] David Cooper joins the room [13:17:49] good morning [13:18:33] Is there someone in the room who wants to help me measure audio latency? tom? [13:18:36] hello [13:19:01] test audio [13:19:16] damn; I wasn't looking [13:19:18] semery joins the room [13:19:22] Simon Josefsson joins the room [13:19:23] do it aagain? [13:19:27] test audio [13:19:37] Looks like about 5 seconds [13:20:01] jimsch joins the room [13:20:45] kdz joins the room [13:21:02] kdz leaves the room [13:21:15] cyrus joins the room [13:21:17] kdz joins the room [13:21:34] Well, then someone will just have to channel us [13:21:39] stpeter joins the room [13:21:56] mattiasa@su.se joins the room [13:24:25] I'll be scribing [13:24:31] agenda bashing [13:24:39] document status [13:25:36] I don't see Nico in here [13:26:00] nico joins the room [13:26:02] draft-ietf-sasl-gs2, draft-ietf-sasl-scram, draft-ietf-sasl-4422bis, draft-ietf-sasl-channel-bindings [13:26:10] hi [13:26:22] -gs2 and -scram are in WGLC [13:26:31] yes, they are [13:26:47] it seems that we have mostly editorial comments at this point (says Tom) [13:26:52] When's the party? [13:27:10] 4422bis -- not much progress [13:27:15] Alexey to the mic [13:27:31] Kurt is fixing some references etc. [13:28:03] "CB" (channel bindings) has undergone numerous revisions [13:28:14] Right, just editorial changes in 4422bis. [13:28:25] sorry, I don't have audio yet [13:28:29] don't ask [13:28:38] Chris Newman to the mic [13:28:47] any questions for me please send them to jabber [13:28:52] please use the mic (couldn't hear Chris). [13:28:56] nico: are you listening to the audio? [13:29:03] Chris never quite got to the mic :) [13:29:08] no [13:29:17] assume I've no audio [13:29:26] nico: OK [13:29:57] who was speaking 5 seconds ago? [13:30:02] jhutz: I don't know [13:30:04] me [13:30:18] we need SASL auth to use the mics :) [13:30:28] i thought i announce my name ;) [13:30:40] Let's get people to _use_ the mics first, then we can worry about authenticating them. [13:30:53] You did; I just missed it and didn't recognize your voice [13:31:25] Alexey says there are some missing comments and examples [13:31:26] ietfdbh joins the room [13:31:33] Simon at the Mic [13:31:37] lha joins the room [13:33:22] I missed - what was removed? [13:33:29] Alexey: best to take this issue to the list (ed: whatever this issue is, I missed the original point that Alexey made) [13:33:31] Chris Newman joins the room [13:33:39] jhutz: I missed it to [13:33:59] ok, i have audio now [13:34:06] ietfdbh leaves the room [13:34:09] on the server side when the server acquires credentials, what name to use, how to persist them -- this text was removed in GS2 [13:34:24] ok, technical discussion? [13:34:33] GS2... [13:34:40] Simon at the mic [13:34:44] Hm? In nearly all cases, the server should not use any particular name to acquire credentials. [13:34:44] oh, hi [13:34:51] sorry, chatting w multiple ppl [13:34:53] version -14 in WGLC [13:35:07] oh, I'm supposed to look at that? [13:35:08] :) [13:35:10] URL? [13:35:11] Simon says, please review, especially for consistency with SCRAM [13:35:40] Joe Hildebrand joins the room [13:35:46] nico: do you mean http://tools.ietf.org/html/draft-ietf-sasl-gs2-14 ? [13:35:55] simon wants to know why the text went away [13:35:59] Alexey says he has a pure SCRAM implementation, not a GS2 impl [13:36:11] Simon is working on a GS2 impl [13:36:18] jhutz: correct [13:36:21] no, slides [13:36:38] nico: http://www.ietf.org/proceedings/75/agenda/sasl.txt is all I have [13:36:53] ok [13:37:16] Simon is working on a public demo IMAP server [13:37:38] http://feed.verilan.com:8000/stream04 [13:37:43] Wrong URI [13:37:59] https://datatracker.ietf.org/meeting/75/materials.html [13:38:19] only the GS2 slide is there [13:38:25] https://datatracker.ietf.org/meeting/75/materials.html#wg-sasl [13:38:26] Alexey to present [13:38:38] talking about SCRAM [13:38:41] he has no slides [13:38:42] And no, the agenda and GS2 slides are there [13:38:47] I will scribe as best I can [13:39:11] ABNF bug about the AuthMessage [13:40:19] s/client-first-message/client-first-message-bare/ [13:41:21] strike "or specified with an empty value" for definition of a value [13:42:53] Alexey described issue about selecting -PLUS or not [13:43:00] Chris Newman at the mic [13:43:09] point about IANA considerations [13:43:33] right now, SCRAM-* mechanisms to be reviewed on the list [13:43:36] I don't think we do. If that list goes away, the IESG can designate something else. [13:44:12] guidance is good [13:44:15] Chris: might want to say why we would reject some members of the family [13:44:23] Chris: hopefully the family will be small [13:45:06] Well, I think Chris's point is that growth should be slow. [13:45:17] jhutz: so it seems [13:45:46] I think that language is a little too strong. I should be able to register SCRAM-SHA3 _before_ SHA-1 is too weak to use [13:46:56] WG mailing lists can exist long after the WG concludes. [13:47:01] But overall I agree the growth rate should be slow [13:47:21] Correct. There are good examples of that, too, like ietf-ssh [13:47:38] And I think there's even one that's been used for review like this [13:48:59] reviewing milestones [13:49:10] SCRAM and GS2 in progress [13:49:22] decide about CRAM-MD5 [13:49:38] might take on Kurt's document about problems in CRAM (to historic) [13:49:51] suggestions about a timeline for 4422bis? [13:50:15] 4422 is proposed [13:50:23] 4422bis: no rush. Need SASLprep bis first. [13:50:27] to advance to Draft, need implementation report(s) [13:51:09] Joe Hildebrand leaves the room: Disconnected. [13:51:54] kdz: I noted that in the physical room [13:52:28] I'm currently drafting a revision of stringprep. And updating saslprep. [13:52:35] kdz == kurt [13:53:23] we can downref saslprep [13:54:02] kdz: so you assert :) [13:54:05] Pasi at the mic [13:54:10] the saslprep reference is in the procedures for profiles, not part of the "technical specification" part of 4422. [13:54:25] so downref is sensible. [13:54:47] Simon: possible to remove SASLprep? [13:54:59] Pasi: that would introduce incompatibilities [13:55:39] Simon: the reference could be removed with a statement that mechanism specifications deal with the issue on their own. [13:55:52] Pasi: but the downref could be acceptable because -prep is something that each mechanism uses [13:56:26] Tom: is October realistic? [13:56:34] (for 4422bis) [13:56:55] October realistic, I think. [13:57:20] question to the group from Alexey: are there other issues we need or want to revisit in the core spec? [13:57:23] For the 4013 reference, I recommend using the downref procedure. But we can discuss removing the recommendation on the list. [13:57:56] Nonsense! Alexey certainly qualifies; he's a major implementor [13:59:04] Simon: no major concerns [13:59:16] Simon: my only concern would be related to channel bindings [13:59:28] Simon: what about EXTERNAL? [14:00:45] Let's drop EXTERNAL from the new doc; 4422 is good enough. [14:00:55] We don't actually want to keep specifying ordinary EXERNAL, right? [14:01:14] Why separate? [14:01:47] It's already _in_ 4422. just drop it from 4422bis. All it requires is a few judicious 'dd' commands [14:01:55] kdz: cleanliness -- we moved 3 of 4, why not remove the last one? [14:02:26] Re: Are we taking on the external doc? Is that in our charter? I do think we should adopt it. [14:02:46] But Simon's I-D is another story (regarding charter). [14:03:10] jhutz: Tom notes that splitting EXTERNAL from 4422bis into a separate document would probably not require a charter revision [14:03:49] Chris: would prefer EXTERNAL in a separate document [14:04:02] (mostly for consistency) [14:04:17] Alexey at the mic [14:04:31] It strikes me that the difference between a WG document and an individual document that is worked on by WG members and discussed on the WG list is almost nonexistent. It's just applying individual-doc process to what is really a WG doc. [14:04:32] Alexey: is EXTERNAL-TLS wire-compatible with EXTERNAL? [14:04:42] jhutz: nod [14:04:53] no, it has a different name [14:04:55] that's all [14:04:56] I'm not talking about EXTERNAL. I'm talking about Alexey's EXTERNAL-* doc [14:05:09] EXTERNAL-TLS differs from EXTERNAL only in name [14:05:16] right [14:05:21] Depends on what the EXTERNAL implementation does. [14:05:33] +1 on EXTERNAL-* [14:05:38] Tom asks: who thinks we should work on EXTERNAL-*? [14:05:42] there was a question of having it name a specific TLS channel, in cases where many are nested [14:06:06] but, frankly, I _still_ don't see the point of EXTERNAL-* [14:06:08] I'm not sure we should work on EXTERNAL-*. [14:06:17] http://tools.ietf.org/id/draft-josefsson-sasl-external-channel-04.txt [14:06:22] EXTERNAL should mean "highest-layer, end2end channel" [14:06:28] but if we do want to work on it, we should update our charter. [14:06:44] and I don't see how making it mean that could break interop given current deployments [14:06:51] Really, I think applying the "individual" process to what is effectively a WG doc is inappropriate. [14:06:53] I agree with Nico. [14:07:23] w/ regard to "highest-layer, end2end channel". [14:07:24] any other topics? [14:07:26] nico, that's not what EXTERNAL means. EXTERNAL means "some external authentication, and the parties have to agree a priori what it is" and not all implementations of EXTERNAL today are TLS. [14:07:30] (for milestone revisions) [14:07:38] open mic [14:07:42] The point of EXTERNAL-* is to be specific enough about it to allow interop. [14:07:52] Leif at the mic [14:08:06] SASL mechanism for SAML? [14:08:09] Nico, we _know_ there are existing deployments of EXTERNAL that do not mean EXTERNAL-TLS. [14:08:54] jhutz: yes, but would the above change break them? [14:09:09] those deployments don't use TLS, right? [14:09:11] yes there are some efforts about SAML-SASL [14:09:35] Simon: OpenID too? [14:09:42] What OpenLDAP uses is "EXTERNAL pulls up the identity from the highest channel THAT provided an identity". [14:10:28] Cyrus... [14:10:35] SCRAM for HTTP Auth? [14:10:54] Alexey: it's on my list [14:10:54] but no one has more than one channel in practice today (not more than one end2end channel, anyways) [14:11:12] not necessarily. [14:11:29] Cyrus: well, that's a large topic [14:11:35] Joe Hildebrand joins the room [14:11:41] that'd be the first question [14:11:46] Nico: our software does support TLS over IPC, though it's not clear why anyone would want to use it. [14:12:07] there was talk of adding channel binding to DIGEST-MD5 [14:12:07] Think of an implementation which supports TLS, but for which EXTERNAL means something like looking at the client credentials of a UNIX-domain socket connection or something. The point is, a server might offer EXTERNAL, and it might not mean what the client thinks it means, and then using it might fail. [14:12:18] Love at the mic :) [14:12:23] MSFT is deploying HTTP/Negotiate2 with channel binding [14:12:28] Why are we talking about HTTP authentication in SASL? [14:12:38] kdz: interesting [14:12:47] jhutz: we've used the MSISDN from the cell phone network for external. [14:12:49] jhutz: we seem to be talking about s/DIGEST/SCRAM/ for HTTP [14:12:53] Jhutz, that's the greater problem I think... agreement on which identity is being used [14:13:23] I'd be happy with EXTERNAL meaning "highest-layer end2end channel that provided a client ID" [14:13:32] Joe, that's an excellent example. You support TLS, right, but EXTERNAL doesn't ever mean TLS client certs? [14:13:33] Love: replace or do something more [14:13:35] +? [14:13:56] yes, HTTP/Negotiate2 with CB and SCRAM-the-GSS-API mechanism shou;d be good enough [14:13:59] Cyrus: is "negotiate" too heavy? [14:14:30] nico, that doesn't help. If Joe's server offers EXTERNAL, then a client that thinks EXTERNAL means EXTERNAL-TLS _will not work_ no matter what you define EXTERNAL to mean. TLS is the higher layer, but it's not the one Joe's server wants to use [14:14:53] Better to just be explicit about it. Note we already had this discussion about CB and came to that conclusion. [14:14:55] I think what will matter here is whether any of the big players (MSFT, Mozilla, Apache, ...) add support for HTTP/Negotiate with CB and SCRAM [14:15:02] SASL mechanisms don't use security layers; they provide them. [14:15:19] jhutz: oh, alright [14:15:29] GSSAPI security layers do get used. [14:15:34] jhutz: correct [14:15:42] jhutz: it sometimes means TLS, sometimes means MSISDN. Doesn't matter to either side for interoperability. [14:15:43] sm joins the room [14:15:59] what's MSISDN? [14:16:04] phone number. [14:16:09] GSSAPI doesn't have "security layers". It has optional per-message integrity and confidentiality services, which you can use on a message-by-message basis. [14:16:19] The server only offers EXTERNAL if it's willing to accept it. [14:16:37] It matters if the client wants one but the server thinks it means the other. No? [14:16:42] jhutz: I was referring to the SASL "GSSAPI" mechanism. [14:16:55] Oh, I see. [14:17:00] sorry, do what? [14:17:02] Kurt, what uses that? [14:17:08] In practice [14:17:18] I know stanford uses them in their deployment. [14:17:26] of OpenLDAP. [14:17:30] are we talking about SCRAM sec layers? [14:17:34] Chris: I will never implement security layers, but I don't care enough to remove security layer -- perhaps to a non-normative appendix would be fine [14:17:37] nico: yes [14:17:39] or GS2 sec layers? [14:17:50] I thought the question was about SASL SL in general. [14:17:57] I agree that LDAP implementations tend to use them [14:18:04] Tony Hansen: I did not implement security layers either [14:18:11] Yes, I think the question was about SASL in general. [14:18:15] for example, the libldap on Solaris doesn't support StartTLS, much less CB [14:18:17] Tony: not sure about channel bindings [14:18:26] Chris: I will attempt channel bindings [14:18:29] but IMO that's the right approach (do TLS and CB) [14:18:37] so I'd say: forget sec layers [14:18:46] nico: +1 [14:18:54] > forget sec layers I think I can live with that. [14:19:01] Chris: I'm a bit concerned about negotiating channel bindings when the only one I care about is TLS [14:19:33] forget engotiation of channel binding types for now -- that's not specified [14:20:15] chris: the current spec says nothing about channel binding negotiation -- it makes it possible to add that in later [14:20:27] No, most of what we've been discussing in jabber isn't intended to be channeled to the meeting [14:20:49] jimsch leaves the room [14:21:00] too bad it's too early in the morning for the stanford people to comment on their use of security layers, if any. [14:22:05] Simon: I've seen some concerns that SCRAM might not provide the same security properties as SRP [14:22:12] Simon: does it make sense to revive the old SRP work? [14:22:31] well, you could make an SRP GSS mechanism that fits GS2 [14:22:33] Chris: I see SRP as more of a niche usage [14:22:38] and then you'd have an SRP SASL mech [14:23:02] > make an SRP GSS mechanism that fits GS2 sounds like a good idea [14:23:08] Chris: SRP brings a lot of complexity that I have no interest in adding to my product [14:23:21] You know, the point of GS2 is that Chris's users can use mechanisms that he has no interest in putting in his product. [14:24:13] Alexey: I would be interested in this, but it's quite far down my list [14:25:08] I haven't a problem with a SRP mechanism being pursued outside the WG. [14:25:08] Chris Newman leaves the room [14:25:38] David Cooper leaves the room [14:25:47] kdz: I haven't a problem with it being pursued in the WG [14:25:56] provided there's enough interest [14:26:11] Joe Hildebrand leaves the room: Disconnected. [14:26:23] kdz leaves the room [14:26:27] semery leaves the room [14:26:39] but then, the policy over at KITTEN WG is that it does not do work on mechanisms, that mehs are developed as individual submissions [14:26:42] nico leaves the room [14:26:50] metricamerica leaves the room [14:26:52] Joe Hildebrand joins the room [14:27:25] The policy here in SASL is supposed to be that we don't do work on mechanisms, except for the mechanisms we're working on. :-) [14:27:27] lha leaves the room [14:28:20] meeting adjourned IRL, in case you hadn't noticed :) [14:28:35] I noticed. [14:28:45] ok [14:28:46] Joe Hildebrand leaves the room: Disconnected. [14:28:51] thanks for joining via Jabber :) [14:29:10] sm leaves the room [14:29:14] hopefully I accurately channeled your comments [14:29:22] Yeah; I'd rather have been there in person, but I can't be away this week. [14:29:27] mattiasa@su.se leaves the room [14:29:37] nod [14:29:44] ok, thanks folks! [14:29:48] logging off.... [14:29:59] stpeter leaves the room: Disconnected: connection closed [14:30:05] Stockholm is a nice city to visit. BTW, you should definitely go to the social even if you haven't seent he museum before. [14:40:58] tlyu leaves the room [14:52:11] Simon Josefsson leaves the room [14:52:11] jhutz@jis.mit.edu/owl leaves the room [14:53:00] cyrus leaves the room [16:13:02] Simon Josefsson joins the room [16:30:45] Simon Josefsson leaves the room [19:36:32] KaiFischer joins the room [19:37:09] KaiFischer leaves the room [23:27:30] Joe Hildebrand joins the room [23:27:51] Joe Hildebrand leaves the room