[09:53:47] Simon Josefsson joins the room [10:39:28] Simon Josefsson leaves the room [11:07:30] Simon Josefsson joins the room [14:32:02] JYS5044300A0E89238 joins the room [14:48:08] nico joins the room [14:48:19] did I miss the whole meeting? [14:48:46] JYS5044300A0E89238 leaves the room [14:48:56] JYS5044300A0E89238 joins the room [14:49:01] JYS5044300A0E89238 leaves the room [14:49:56] what's the audio channel? The ietf streaming audio page doesn't say [14:50:22] JYS5044300A0E89238 joins the room [14:50:43] JYS5044300A0E89238 leaves the room [14:51:36] duh, wrong time zone [14:51:41] Shirley.M.Huang joins the room [15:07:26] Shirley.M.Huang joins the room [15:08:26] adams@jabber.isoc.org joins the room [15:36:13] stefan.santesson joins the room [15:37:14] adams@jabber.isoc.org leaves the room [15:38:37] stefan.santesson leaves the room [15:40:27] kdz joins the room [15:48:32] ietf-meeting joins the room [15:53:14] ietf-meeting leaves the room [15:53:17] ietf-meeting joins the room [15:53:43] ietf-meeting leaves the room [15:53:46] ietf-meeting joins the room [15:53:48] cyrus joins the room [15:53:50] ietf-meeting leaves the room [15:53:54] ietf-meeting joins the room [15:54:22] ietf-meeting leaves the room [15:54:24] ietf-meeting joins the room [15:55:14] ietf-meeting leaves the room [15:55:16] ietf-meeting joins the room [15:55:23] ietf-meeting leaves the room: Disconnected [15:55:34] Dave Cridland joins the room [15:55:39] ietf-meeting joins the room [15:56:32] Dave Cridland leaves the room: offline [15:56:36] Dave Cridland joins the room [15:57:06] audio dead? [15:57:14] kdz leaves the room [15:57:21] jhutz@jis.mit.edu/owl joins the room [15:57:43] Probably not up yet, but the meeting also hasn't started yet. [15:57:53] dwd joins the room [15:58:25] thanks [15:58:46] Dave Cridland leaves the room: offline [15:58:53] Audio tech is sitting in the corner playing with hardware... [15:58:56] dwd is now known as Dave Cridland [15:59:25] sm joins the room [15:59:49] Oh, bizarre audio. [15:59:55] tlyu joins the room [16:00:04] It's coming out at the wrong bitrate, which is impressively amusing. [16:01:25] badra joins the room [16:01:46] Chris Newman joins the room [16:02:25] Chris Newman: Enjoying your retirement? [16:03:31] I'm not officially retired until Wednesday, but yes ;-) [16:03:40] mrex joins the room [16:05:33] we're going to start shortly. we're waiting for updated slides. [16:06:07] Can anyone confirm that Audio is working? [16:06:42] Given that people are still sitting in front of the room working on the audio, I assume it's not working yet. [16:06:46] tonyhansen joins the room [16:06:53] semery joins the room [16:06:55] mrex: I can confirm it sounds really weird and squeeky, then cuts out. [16:07:15] I only hear Mickey Mouse [16:07:22] it is working at wrong bitrate [16:07:30] still [16:07:51] Audio tech is aware of the problem and working on it. [16:08:03] Yeah, if everyone could speak *really* slowly, it'd help a lot. [16:08:06] hartmans@jis.mit.edu/owl joins the room [16:11:07] alexey.melnikov joins the room [16:11:47] Hello [16:12:46] nico joins the room [16:13:14] Audio better now? [16:13:19] let me try [16:13:24] Oh. [16:13:30] That sounds promising. Somebody speak. [16:13:37] yes [16:13:39] Yup, that's better. [16:13:39] it works better [16:13:45] 6? [16:13:57] 15 seconds? [16:13:59] about a 90 seconds [16:14:22] Tue Mar 24 11:13:28 CDT 2009 [16:14:29] yes,it is better now [16:14:42] epeat my timestamp when I paste it next [16:15:05] Tue Mar 24 11:14:12 CDT 2009 [16:15:16] Tue Mar 24 11:14:12 CDT 2009 [16:15:28] About three seconds for me. [16:16:17] yeah, very few seconds [16:16:29] nico: Way better than the appsarea yesterday. [16:16:32] this is the best that IETF streaming audio latency has ever ben [16:16:47] I wasn't at appsarea [16:16:51] audio just started (correct bitrate), I just don't know whether its live [16:16:58] I gather it was interesting [16:17:11] mrex: seems to be only a few seconds behind [16:19:07] Scribing... [16:19:11] Chairs starting up [16:19:22] Agenda bash - anything else to add? [16:20:03] Main topics: GS2, SCARM and perhaps CRAM. [16:20:17] not CRAM [16:20:56] Document status: [16:21:05] 4422bis - missing in action.... [16:21:48] needs work with saslprep [16:22:00] SCRAM - close to consensus - and GS2 too. [16:22:57] digest-to-historic - expired - please refresh - it will go to IESG at the same time as SCRAM. [16:24:28] scram-ldap - individual submission will wait for SCRAM itself. Has been updated - Alexey thinks it is done. [16:24:57] New topic: SCRAM [16:25:52] Status: nearly ready - need to decide between pure-SCRAM and SCRAM-as-GS2 [16:26:13] Some implementations done... [16:26:52] Issues: [16:27:11] Min/recommended iteration count - is 128 enough? [16:27:48] You only need to do those 4096 once. [16:28:01] (Thanks Alexey, you prempted me there) [16:29:06] Simon based his recommendation on hashes per second. [16:29:39] pkcs5 suggested 1000 ten years ago - adjust for those 10 years to get a current number. Battery on mobile devices is not a big concern. [16:31:32] 4096 is fine by me. "openssl speed" tells us quite a bit. [16:31:44] extend the protocol and make it server configurable (make the iteration number part of the challenge) [16:31:45] And that's how Simon pulled the figure out of his arse. [16:32:01] Lets ask an expert and run performance numbers on implementations. [16:32:05] no value that is good today will be good tomorrow [16:32:07] The number is tunable, what we're specifying is the lower bound for the number. [16:32:51] take a fast computer, pick a number such that you can only do N SCRAM exchanges per-second on that computer [16:33:40] what amount of CPU cycles for what kind of CPU horsepower are you looking for? [16:33:57] Are you looking for 0.1 Seconds or 1 Second or 10 Seconds [16:34:21] Doing sha1 for 3s on 64 size blocks: 1986686 sha1's in 3.00s [16:34:26] mrex: it's important that the server not be able to reduce the count too much, otherwise an attacker could say "1" and have a much shorter off-line attack [16:34:47] Measure how many iterations it takes to use up 1/2 sec on iPhone. [16:35:23] Next issue: key derivation [16:36:06] ClientKey and ServerKey use slightly different functions - h vs HMAC. Should they both be HMAC? [16:36:09] It sounds reasonable to me. [16:36:26] No objections to making this change. [16:36:41] Next issue: service name/URI in scram [16:37:19] Digest included the uri - has been the source of a number of interop problems. [16:37:30] That top bullet - I don't see how that's possible without sharing the authentication database, or knowing the password and picking a salt/iteration to match the "other server". [16:38:10] The "bad server" acts as a proxy to the "good server", proxies salt/iteration count, and gets access to the "good server". [16:38:32] Chris Newman: Right, but how does it manage this without also having the password? [16:38:56] The "bad server" has tricked the client to talk to it. [16:39:16] I agree that a version that authenticates the server name would be good [16:39:22] Channel binding is better - uri is a weak form of that. [16:39:33] I believe that Chris is correct that the current version is easier to deploy [16:39:45] Chris Newman: Oh, "bad server" can pass the auth through without channel binding, yes. [16:39:48] if you want server authentication, use Kerberos V [16:40:21] Chris Newman: But if you do have channel binding, then this won't happen. [16:40:44] Correct. Channel binding prevents the attack completely. [16:40:54] not necessarily [16:41:06] if you've been redirected to the wrong server... [16:41:17] and you're not authenticating the server in TLS... [16:42:00] nico leaves the room [16:42:02] nico joins the room [16:42:04] if the scram authentication includes the entire URL, then every little request might incur the overhead of a full scram authentication [16:42:36] mrex: cell phones won't be authenticating to many servers [16:43:10] Does the URL include the full path as per http://example.com/xyz/abc? [http://example.com/xyz/abc?] [16:44:17] How to deal with CNAMEs etc for hostnames.... [16:44:46] The digest URI stuff just came up recently on the XMPP lists, too. Much discussion about what it ought to be. [16:45:25] so make it part of the challenge [16:46:21] [16:46:33] is this a redirection attack? [16:47:14] if the "service" that is used is stateless (like HTTP/HTML transports), then you probably want some level of "replayability" in order to not incur a full authentication for every little graphics on a page [16:48:14] cyrus: As I said, this came up with XMPP just recently. [16:48:46] FWIW, it turned out that DIGEST-MD5 server implementations just accept anything. [16:50:36] If a client comes across a server where it *isn't* ignored, then that'll be a big surprise. [16:51:04] if the server can just ignore it then it's not worth it [16:51:22] I'd want the URI/server name/whatever to salt the password [16:51:27] nico: Right. It's just an interop failure waiting to happen. [16:51:47] also [16:51:58] I don't want this comlicating GS2 [16:52:08] (could you turn down the "floating" mike a little?) [16:52:25] if you salt the password with this then GS2 handles this trivially [16:52:52] We're talking about something to protect the case were we're not using channel binding, right? [16:53:10] I think that's part of it [16:53:28] So why not say "Do channel binding if you want to protect yourself from this attack". [16:53:39] if you don't authenticate the server and there are N servers the user could choose to o to, then an attacker can redirect the user from one of those to any other [16:53:52] dave: I agree [16:54:19] Simon Josefsson joins the room [16:54:20] oops. time zone problems here as well, i just joined. no jabber scribe? [16:54:28] anyone looking at the jaber room? [16:54:34] Do you want to add a possibility for the server to "scope" the replayability of the authentication? [16:54:50] Yes - will get you heard in a sec... [16:54:57] yeah [16:56:10] Well, SCRAM might not be implemented. [16:56:11] =JeffH joins the room [16:56:14] stefan.santesson joins the room [16:56:20] rlbob joins the room [16:57:12] hold on [16:57:26] I have, and did. [16:57:31] we have one school of thought that says: sec layers are too hard [16:57:37] Is channel bindings sufficient? Has anyone implemented it on client/server? [16:57:44] and another saying: no one will implement channel binding [16:57:53] we have to pick at least one of those two answers [16:57:57] And it's pretty easy, once you find the right bits in OpenSSL. (And expose them to Python, in my case). [16:57:57] OR [16:58:03] we have to live with this issue [16:58:10] pretty simple [16:58:48] should we have a protocol for requesting to be channeled? [16:58:55] :) [16:59:02] Kind of. Dave Cridland also thinks it's a pain in the arse, and has proven so with DIGEST-MD5 in XMPP just recently, where it turned out nobody (aside from Alexey) knew what the digest-uri ought to be. [17:00:21] I think there were two different antecedents for "it" in Dave's last two messages [17:00:41] "it" == channel binding in "And it's pretty easy, once you find the right bits in OpenSSL. ..." [17:00:47] nico: My backreferencing compression algorithm is a little too aggressive. ;-) [17:01:05] so you still can fool those servers that look at the "extra/optional" hashes [17:01:07] and "it" == URI in "Kind of. Dave Cridland also thinks it's a pain ..." [17:01:10] Dave: :) [17:01:11] +don't [17:01:24] Three hums: [17:01:43] Maybe four: [17:01:49] 1) Full URI support [17:01:50] one more choice: do this in a separate variant of SCRAM with a diff mech name [17:02:03] 2) servicename, hostname [17:02:06] 3) servicename [17:02:07] nico: I think we have enough variants, really. [17:02:10] 4) don't bother [17:02:17] ietf-meeting leaves the room [17:02:20] ietf-meeting joins the room [17:02:25] I'm humming for (4). In fact, I might even break into song. [17:02:46] lol [17:02:58] 5) servicename, hostname optional domainname [17:03:02] sm leaves the room [17:03:41] First question actually is: shall we modify SCRAM to put some notion of a service identity into the client's request? [17:03:56] Hands for yes: [17:04:05] (speak up on jabber...) [17:04:20] two hands in the room [17:04:33] I'll raise my virtual hand against. [17:04:34] against: 6 hands in the room [17:04:34] me is against [17:04:36] any yes/no/undecided from jabber? [17:04:44] undecided: about the same in the room [17:05:27] mic! [17:06:07] i'm undecided, but leaning towards (4) [17:06:10] How undecided are the undecodeds? [17:06:26] s/undecodeds/undecideds/ [17:06:27] cyrus: "Undecodeds"? [17:07:21] there is an option [17:07:32] assuming channel bindings is the better solution to this problem [17:07:49] have the client name the server, but the server MUST indicate whether the server validated the server name requested by the client [17:07:54] I don't think a servicename buys anything, ince if someone's trying to be a "Bad actor", they're likely to be attacking the same service as they masquerade as. [17:08:25] nico: Wouldn't a bad actor merely say "Yes, that's me!" [17:08:31] What is the problem the "yes" voters want to solve? [17:08:32] but I'd still rather have something that salts the password with the server name (and the server equested salt) [17:08:40] Server impersonation is one key issue. [17:08:52] Dave: the bad actor has to be able to produce its proof [17:09:01] which means anything goes [17:09:03] nico: That's one of the causes of DIGEST-MD5 implementations holding cleartext passwords, though. [17:09:36] Dave: I understand [17:09:45] which is why I'm not strongly in favor of that [17:09:45] Make Sam talk a bit away from that mike [17:09:54] yes, Sam, don't eat the mic [17:10:14] GSS_Inquire_sec_context() [17:10:39] would return GSS_C_NT_ANONYMOUS for the acceptor if the acceptor did not validate the server name [17:10:57] jhutz: my answer re: GSS is in the jabber room; cue mrex objection [17:11:01] :) [17:11:50] (IIRC mrex would object that the targ_name passed to GSS_Init_sec_context() has to match that which is returned by GSS_Inquire_sec_context() because GSS apps are not required to check the latter) [17:12:15] sam: if that's what you want then salt the password with the server name [17:12:28] jhutz: heh [17:12:43] jhutz: that did not need channeling [17:12:59] which is why we need a jabber->MIC channeling protocol [17:13:11] I'll prefix messages to be channeled with MIC: [17:13:29] Chairs position: no clear consensus to add this feature right now. [17:13:36] nico: Or with ietf-meeting - that might get highlighted by the client watching the room. [17:13:41] Need more concrete proposal from those who want this. [17:14:20] we'll not have any time left for GS2, will we? [17:14:33] nico: So there's good news, then... ;-) [17:14:38] I think we'd be better off trying to get consensus on issues where we're likely to get consensus [17:14:41] Dave: no [17:15:00] MIC: I'd like us to move on; we're not going to settle this now [17:15:09] MIC: let's do this on the list [17:15:42] what is going on: we've entered a rat hole [17:15:43] :) [17:16:01] This is as much about protecting the account as the server. So the client has an interest in making sure that its validation constraints are met. [17:16:54] let's move on [17:17:08] If it's all optional to verify, I think it's a bit pointless. [17:17:21] semery leaves the room: Disconnected [17:17:30] But then, even if it's not optional, I think it's still pointless in the face of channel binding. [17:17:33] I've proposed what Chris is proposing [17:17:37] Another question: can we put this off until later? Then do a scram variant that adds this is needed? [17:17:45] nico seconds Chris [17:18:09] but I really, really want to move on to issues where we have a chance of getting consensus [17:18:13] we are back in the rathole :) [17:19:32] can we please crawl out of the rathole now? [17:19:41] Done with that issue - phew! [17:19:53] Next issue: GS2 framing. [17:19:56] slide 3? [17:19:56] nico: The advantage of being remote is that I can go off and make a cup of tea at such moments. [17:20:16] Dave: you're happy to let them filibuster us [17:20:21] Dave: I'm not :) [17:20:33] nico: No, I just like tea. [17:20:41] Slide title: Open Issues (3 of 4) [17:20:51] yes, sure [17:21:09] Are people up to date with the new proposal? [17:21:09] mrex leaves the room [17:21:30] Nico's slides now on screen: New GS2 Design [17:22:19] Slide Title: New GS2: Headers [17:22:31] oh, there's been one innovation since I wrote these slides: the RFC2743 header compression flag is now missing in one case [17:22:44] i.e., I've compressed the RFC2743 header compression flag [17:23:08] I've lost audio [17:23:18] nico: I've still got audio. [17:23:36] I think my client froze [17:23:44] got it back [17:25:10] heh [17:25:11] I'm still confused about this "y" state. [17:25:43] MIC: jhutz: you might want to point out that I've compressed the RFC2743 initial context token compression flag [17:25:45] I don't get why the client doesn't just try doing channel binding anyway, and have the server just not verify it if it can't. [17:26:00] Who understands this? A few hands. Chairs want others to look at this and decide whether it works. [17:26:13] I've not looked at the GS2, but I have looked at the effect on SCRAM, and it's okay. [17:26:25] Dave: excellent [17:27:06] Right. [17:27:13] But why not have "n" or "p". [17:27:57] Dave: for the same reason [17:27:59] I don't understand the question [17:28:01] Several hands "yes" to support moving forward. No hands opposed to moving forward. [17:28:04] As in, if the server can't handle channel binding data, it knows that, that's fine, it won't pass that into GSS-API channel binding verification, it can just include it in the hashes blindly. [17:28:06] Quick show of hands: agreement in the room that this is the right way forward (GS2). [17:28:27] Dave: if we tried to compress the CB flag then the SASL/GS2 implementor would run into the same problem that Jeff just explained [17:28:57] Dave: a SASL/GS2 implementor cannot look inside the client message to find out what happened -- it can only look at the GS2 header [17:28:58] Going back to chairs slides. [17:29:06] so we have consensus? [17:29:12] Yes. [17:29:15] awesome [17:29:17] thanks [17:29:18] we do. when is the party? [17:29:22] Decision is to move forward with this GS2 approach. [17:29:24] Jeff helped a lot [17:29:30] Chairs thank Nico for his work on ths. [17:29:56] Next issue: GS2 related issues... [17:30:04] mrex joins the room [17:30:21] can we use the "+" US-ASCII char? [17:30:24] nico: I'm obviously missing something, I just don't see how a problem could exist. [17:30:31] Should we have one or two SASL names for channel binding or not variants? [17:30:37] Dave: because you're not a GSS-API implemetor [17:30:48] Dave: imagine you've got this layering: [17:31:04] app->libsasl->gs2-plugin->libgss->gss_scram [17:31:22] dperkins3600 joins the room [17:31:22] Chairs: two name approach seems to be consensus. [17:31:32] here gs2-plugin and libgss cannot inspect the bits that belong to gss_scram [17:31:41] Sure... [17:31:44] the reason is that libgss is a plugin framework [17:31:50] No, I follow all this. [17:31:53] there could be other mechs, such as Kerberos v [17:32:09] so we cannot know whether the client included actual channel binding data [17:32:12] Going back to Nico's GS2 slides [17:32:18] without a flag in the GS2 header [17:32:28] we can actually get rid of one CB flag value though [17:32:41] Quickly skimming slides to see if there is anything else to talk about.... [17:32:43] Sure, but gss_scram knows if the data is there. And it presumably also knows whether the server provided it with channel binding data itself. [17:32:45] because we can unambiguously detect that it's missing [17:32:54] dperkins3600 leaves the room [17:32:59] gss_scram is constrained by GSS-APIs [17:33:34] the GSS-API makes channel binding something that's all-or-nothing and you can't retry -- you have to know a priori if you're going to do CB or not [17:33:39] So one of the properties of the GSS-API abstraction is that you get to pass CB data in to the mehanism, in which case it verifies it, or not. In the case of GS2 as we've described it here, we actually _always_ pass in "CB data" to the GSS-API mechanism, because we use it to encode other things that we have to protect, like the SASL authzid. So the question is not even "do we pass in CB", but "what CB do we pass in?" [17:33:48] you don't get a "success but CB failed" result [17:34:04] badra leaves the room [17:34:05] cyrus leaves the room [17:34:06] stefan.santesson leaves the room [17:34:32] also, GSS mechs can have arbitrary round-trips, so it's not like when the "bad channel bindings" error comes up you can retry the last token without feeding in CB [17:34:40] cyrus joins the room [17:34:57] rlbob leaves the room: Replaced by new connection [17:34:59] cyrus leaves the room [17:35:10] wait [17:35:12] I missed something [17:35:12] cyrus joins the room [17:35:16] what document structure? [17:35:22] MIC: what doc structure? [17:35:40] Nothing important. We're talking about SCRAM [17:35:45] ah, OK [17:35:49] lol [17:35:51] ghudson@mit.edu/owl joins the room [17:35:56] ... and whether the one document will suffice also to descibe SCRAM as GSS [17:36:06] jhutz: I think it does [17:36:11] have you looked at it? [17:36:11] Alexey will try to finish scram this week (or so). [17:36:16] i think the gs2 document is ready for wglc [17:36:26] I think it does, too. So does the room. That was the discussion you missed. [17:36:50] I should update my implementation to -11. [17:36:59] I don't think we should WGLC GS2 until we're sure SCRAM is done [17:37:03] yes, I think both documents are ready for WGLC, modulo the URI issue that needs resolution [17:37:22] Chairs: want both docs in WGLC by the end of the month (or sooner). [17:37:30] i'm not going to start implementing it until it is in wglc [17:37:38] also, I think we want the GS2 doc to depend on the SCRAM doc [17:37:51] since the SCRAM doc includes some parts of GS2 [17:37:54] i.e. about a week. [17:38:07] Done with GS2 and SCRAM discussions. [17:38:19] Next agenda item: interop report [17:38:32] Nothing done on interop reports yet. [17:38:41] BTW, slide #3 (Major Changes since -07" has an error: "Unrecognized channel bindings are ignored by the server" (no, they are not, not in -11) [17:39:00] Inerop report should wait until after saslprep is done? [17:39:45] On saslprep: idnabis folks have some contentious issues they are dealing with right now. Once they get past that we can think about revising saslprep. [17:40:08] Hoping that apps community figures out a general way forward for all stringprep profiles. [17:40:38] Our AD should pay attention to this issue... [17:40:51] ghudson@mit.edu/owl leaves the room [17:41:48] nico had another agenda for wanting to move on from the URI issue: lunch (I'm in CDT) [17:42:06] stringprep BOF? [17:43:02] REfugees From Stringprep - REFS? [17:45:37] Next issue on agenda: CRAM-MD5 [17:45:48] Anything we actually need to talk about? [17:45:57] Nope! [17:46:37] Chairs: result of consensus call - general agreement to Tom's statements on mailing list - except for issue of whether to say SCRAM is the CRAM-MD5 replacement. [17:46:54] nico is for the proposal sent to the list re: CRAM-MD5 [17:46:59] semery joins the room [17:47:07] semery leaves the room [17:47:11] Didn't DIGEST go after CRAM? [17:48:10] Chris Newman: You instigated both SCRAM and DIGEST - I vaguely recall that both were aimed as "a better CRAM"? [17:48:20] "it has a cool name" is an "ad hominem support" [17:48:44] I think SCRAM is much simpler than DIGEST-MD5, so fitting it into HTTP should be fine [17:48:54] but we'd rather use the HTTP/Negotiate scheme [17:49:15] nico: DIGEST came from HTTP, though, so it fits nicely. [17:49:24] Dave: agreed [17:49:34] OK - so we pitch SCRAM in HTTP as NEGOTIATE. [17:49:54] Dave/cyrus: alternatively we add HTTP/SASL [17:49:55] :) [17:50:11] nico: Yes, because every attempt to do so has been so well received. [17:50:54] Discussing milestones. [17:51:09] Let's discuss the non-issue some more. [17:51:24] Dave: with SASL/GS2 there's barely any difference between HTTP/SASL and HTTP/Negotiate [17:51:26] nico: So, SCRAM-HMAC-SHA-1 - if I can do channel binding, I need to say "y" here, right? (Whereas for -PLUS, I say "p" and do them). [17:51:52] the difference between HTTP/SASL and HTTP/Negotiate is that the latter was deployed the-IETF-be-damned :) [17:51:52] mrex leaves the room [17:52:24] Dave: no, if the server said it CANNOT do CB, but the client can, THEN you set the CB flag == "y" [17:52:35] if the client CANNOT do CB then you set it == "n" [17:52:47] Leif was working on an HTTP/GSS2 thingy - where is that? [17:53:00] if the client and server both can do CB (or the client isn't negotiating mechanisms) then set it to "p" and include the channel bindings [17:53:23] cyrus: I think that's become an extension to HTTP/Negotiate and MSFT ran with it [17:53:33] cyrus: but you'd have to ask Larry [17:54:27] http://tools.ietf.org/html/draft-johansson-http-gss-05 [http://tools.ietf.org/html/draft-johansson-http-gss-05] [17:54:44] nico: But the absence of -PLUS means the server can't do channel binding, right? [17:54:48] Chairs: moving out milestones. [17:55:14] Dave: right [17:55:41] so if the client is NOT negotiating mechanisms then it never sets CB flag == "y" -- it either uses CB ("p") or does not ("n") [17:55:42] nico: So that means I can only send y or n. [17:55:46] Dave: If the server doesn't advertise -PLUS, either it doesn't support channel bindings or there is an active attacker. [17:56:20] Dave: if the client does do mech negotiation and sees SCRAM-HMAC-SHA-1-PLUS && the client can do CB, then it sets the CB flag to "p" and uses CB [17:56:41] Chris Newman: Or, of course, there's no external channel - -PLUS won't be available prior to a starttls, right? [17:56:44] Open Mic: [17:56:44] Dave: if the client does do mech negotiation and does NOT see SCRAM-HMAC-SHA-1-PLUS && the client can do CB, then it sets the CB flag to "y" [17:57:00] nico: Right. I thought that's what I said, but never mind. :-) [17:57:04] Question: relationship between SASL and OAuth? [17:57:08] Dave: if the client does not support CB then it always sets the CB flag to "n" [17:57:30] Dave: true -- no channel, no -PLUS [17:57:51] Alexey: keeping a close eye on OAuth - but others should participate too. [17:58:07] so sasl_server_list_mechs() will need to know if there's CB data and the app can do CB [17:59:04] nico: But a client's mechanism selection doesn't need to take this into account? ie, a server cannot advertise only -PLUS and require CB? [17:59:16] Sam does not see a lot of overlap between the two. [17:59:30] the client's mechanism select needs to know: a) the server's mech list, b) whether the client can do CB [17:59:35] (a) is already there today [18:00:45] Chairs: this is the end! [18:00:47] lunch! [18:00:59] ietf-meeting leaves the room [18:01:01] Chris Newman leaves the room [18:01:05] nico leaves the room [18:01:12] tonyhansen leaves the room [18:01:13] cyrus leaves the room [18:01:28] stefan.santesson joins the room [18:02:37] Simon Josefsson leaves the room [18:02:40] stefan.santesson leaves the room [18:05:13] =JeffH leaves the room: Logged out [18:06:01] Glenn joins the room [18:07:41] Shirley.M.Huang leaves the room [18:09:01] alexey.melnikov leaves the room [18:11:30] tlyu leaves the room [18:25:21] Glenn leaves the room [18:28:08] semery joins the room [18:37:43] semery leaves the room [18:42:33] Simon Josefsson joins the room [18:42:44] Simon Josefsson leaves the room [20:10:35] =JeffH joins the room [21:26:33] Dave Cridland leaves the room: offline