[13:49:54] --- frank has joined
[15:32:26] --- frank has left
[15:56:50] --- ietf-meeting has joined
[16:01:36] --- kmurchison has joined
[16:02:24] --- tlyu@jis.mit.edu has joined
[16:02:43] --- semery@jis.mit.edu has joined
[16:02:59] --- jhutz has joined
[16:03:21] <jhutz> Audio for this session: http://videolab.uoregon.edu/events/ietf/ietf703.m3u
[16:04:05] --- hartmans@jis.mit.edu/owl has joined
[16:04:13] <jhutz> Meeting materials for this session: https://datatracker.ietf.org/meeting/70/materials.html#sasl
[16:04:30] <jhutz> And there is a public VNC server showing the projector available at ietf-vnc.central.org
[16:07:24] <jhutz> agenda bashing
[16:07:28] --- kdz has joined
[16:07:32] <jhutz> I foolishly agreed to scribe
[16:07:40] --- nico has joined
[16:07:44] <jhutz> hello, nico
[16:07:50] <nico> hi
[16:08:50] --- tonyhansen has joined
[16:08:51] <jhutz> The only comment on the agenda was from me: "the agenda sucks".
[16:09:01] <jhutz> Tom is asking whether anyone wants to further bash the agenda.
[16:09:10] <jhutz> Sam Hartman: Do you have charter discussion in there?
[16:09:25] <jhutz> Tom: I think we have consensus on the description; just need to tweak the milestones.
[16:09:28] <jhutz> Document status
[16:09:36] <jhutz> crammd5 - waiting on another LC writeup.
[16:10:15] <jhutz> Kurt: Due to chair fault, this doc hasn't moved forward since LC. During LC, there were comments by frank ellerman that we discussed at a previous meeting; all issues were previously discussed; no changes made in response to frank's comments.
[16:10:26] <jhutz> ... chairs were tasked to respond to frank; haven't done that yet.
[16:10:50] <jhutz> chairs will do that, and take it from there. hopefully after that we can push it forward
[16:11:06] <hartmans@jis.mit.edu/owl> No simon?
[16:11:19] <jhutz> next, gs2
[16:11:41] <jhutz> Sam Hartman: I think we're down to one issue.
[16:12:03] <jhutz> Sam: I asked for a revision, got one. Thought there'd be another issue, but we ended up altering rfc4556.
[16:12:30] <jhutz> Sam: 4556 requires that the app be able to tell if CB failed. If I read GS2 correctly, one side sends the CB to the other, and... nothing.
[16:13:01] <jhutz> If you happen to have a different QOP if CB succeeded, you can tell; otherwise, not.
[16:13:17] <jhutz> I think it'll work to add a bit to QOP indicating CB succeeded.
[16:13:36] <jhutz> Simon comented; Sam replied; waiting to hear from Simon.
[16:14:13] <jhutz> Kurt: Why is the RFC5056 [not 4556 --jhutz] there?
[16:14:20] --- finn- has joined
[16:14:21] <jhutz> Sam: If it fails, it's a sign of an attack.
[16:14:53] <jhutz> [anyone know where simon is?]
[16:15:19] <jhutz> Kurt: In the absence of Simon, can't really have this discussion. Take to lisk? (done)
[16:15:21] --- Dave Cridland has joined
[16:15:27] <jhutz> Tom: rfc2831bis - to historic
[16:15:32] <jhutz> Tom: hexa - merged with scram
[16:15:43] <jhutz> digest-to-historic - ready for WGLC?
[16:15:55] <jhutz> alexey: you want me to comment about hexa and scram?
[16:15:59] <nico> I was away
[16:16:02] <jhutz> tom: after doc status
[16:16:12] <jhutz> scram - new rev submitted
[16:16:18] --- guenther has joined
[16:16:22] <jhutz> yap - not a WG doc, but... kurt submitted a new version
[16:16:29] <jhutz> Kurt: I asked secdir for advice on my use of hmac
[16:17:05] <nico> any chance to have YAP as a mode of SCRAM?
[16:17:09] <jhutz> Sam: I assume it is the opinion of this WG that yap isn't a conflict?
[16:17:09] <nico> mic
[16:17:16] <nico> folks use the mic
[16:17:20] <jhutz> Kurt: I think we agreed it's reasonable for me to proceed as individual.
[16:17:34] <jhutz> Sam: Some of us may submit comments to RFC Editor
[16:17:49] <jhutz> What will happen wrt IESG review is I will need to ask SASL WG if this conflicts with IETF work.
[16:18:00] <jhutz> If you don't take it into your charter, you can't say it conflicts forever.
[16:18:17] <jhutz> The question is, should you delay publication of YAP until whatever password mech you're doing is done.
[16:18:32] <jhutz> Reason to do that is if you think publication of YAP first will confuse the market.
[16:18:49] <jhutz> Or, you can decide it's different enough or there won''t be a problem.
[16:19:08] <jhutz> Kurt: Speaking as author, I'm open to whatever the WG decides.
[16:19:27] <jhutz> Sam: Since we know this is coming, unless I hear from the WG before this gets to the IESG, I'll assume SASL doesn't want to delay it.
[16:19:36] <jhutz> Basically, people who do want to delay, say so
[16:19:48] <nico> channel me?
[16:19:58] <jhutz> GA
[16:20:01] <nico> any chance to have YAP as a mode of SCRAM?
[16:20:25] <jhutz> Kurt: I think the answer is no.
[16:20:28] <nico> ok
[16:20:37] <nico> well
[16:20:45] <nico> it depends on having unique channel bindings
[16:20:46] <jhutz> YAP is designed as a one-message protocol; SCRAM is designed to support standalone mode; requires multiple messages
[16:20:58] <nico> I'm not so sure
[16:21:27] <nico> I don't yet see a reason that YAP couldn't be how SCRAM works when there's unique channel bindings
[16:21:29] <jhutz> Kurt, correcting minutes: /I'm open to whatever the WG decides/s/I'm open to/I will support/
[16:22:10] <nico> not any, unique
[16:22:22] <jhutz> Sam: The problem is that in YAP, the client sends a quantity to the server that is a stong password equivalent.
[16:22:40] <jhutz> Even in the unique CB case, I find that concerning. I'd rather you send something salted.
[16:22:59] <nico> is that a feature of YAP?
[16:23:08] <nico> that no salting with the server name is done?
[16:23:08] <jhutz> Kurt: I didn't want to make the mistake of digest-md5 of tying the salt to the authentication ID
[16:23:17] <nico> i c
[16:23:31] <jhutz> Kurt: In a one-message situation, there's nothing available to salt with.
[16:23:39] <nico> I thought YAP was 1-rtt
[16:23:50] <nico> but, OK, if it's 1/2 rtt, then I agree
[16:23:51] <jhutz> Not one round trip; one message (half round trip)
[16:23:57] <nico> it can't be a mode of SCRAM
[16:24:23] <jhutz> Kurt: Of course there's the usual SASL handshaking, communicating the server's final response, but the mech itself is one msg.
[16:24:40] <nico> SASL doesn't do optimistic negotiation, right?
[16:25:01] <jhutz> Chris Newman: You could ram them together under one name, but it'd really be separate mechs, and just make both mechs more complicated. I'd rather they be separate
[16:25:13] <jhutz> Chris: No present profiles do optimistic negotiation.
[16:25:15] <nico> right, thanks
[16:25:27] <nico> negotiation not being part of SASL per-se
[16:25:31] <jhutz> Sam: RFC4422 doesn't talk about optimistic negotiation at all.
[16:25:36] * nico gives up the mic
[16:25:37] <nico> :)
[16:26:19] <jhutz> Tom: Simon Josefsson has a now-expired draft that defines a password-based mech that would be a valid GS2 mech without defining in terms of the GSSAPI
[16:26:35] <jhutz> Tom: Simon tells me he's not interested in pursuing that doc at this time.
[16:26:45] <jhutz> WG has concensus to take on this approach, or at least attempt.
[16:26:58] <jhutz> Sam: Are there differences between this and SCRAM that anyone cares about?
[16:27:08] --- badra has joined
[16:27:08] <nico> I suspect the answer is no
[16:27:12] <jhutz> Kurt: I thought the idea was to take the concepts from SCRAM and wrap them in GS2
[16:27:38] --- frank has joined
[16:27:52] <jhutz> Sam: We agreed to do that, but Simons draft had been presented to us in this space and hadn't been considered, and I had told you that you have to consider the proposals presented to you
[16:29:02] <jhutz> It sounds like Simon is saying he doesn't care much. If this doesn't have any other features over SCRAM, maybe you can take SCRAM, take Simon's text about wrapping in GS2, and use it to meet the deliverable.
[16:29:11] <nico> I think it's reasonable to describe GS2 mechanisms as SASL mechs
[16:29:34] <nico> a bit redundant, but for most mechs still a small enough subset of GS2 that it won't be so redundant
[16:29:40] <nico> however
[16:29:42] <jhutz> [Yes, Nico; I think we mostly agree on that; it's not the question]
[16:29:44] <nico> one concern that I have
[16:30:22] <nico> is that it will be harder to make sure that normative GS2-mech-described-as-native-SASL-mech text is consistent with GS2
[16:30:31] <kdz> Is Abhijit here?
[16:30:40] <Dave Cridland> I can't see his jid.
[16:30:40] --- cnewman@jabber.org has joined
[16:30:53] --- Alexey has joined
[16:31:10] <Dave Cridland> (I've pinged him)
[16:31:30] <nico> BTW, looking at draft-ietf-sasl-gs2-09.txt, I see that it doesn't address Sam's point about CB directly, but the examples do show that both sides get to verify the CB
[16:32:32] <jhutz> Chris Newman: It's my opinion that the proposal isn't complete until you can store the credentials in one of the common credential stores out there (e.g. LDAP, RADIUS)
[16:32:58] <jhutz> Chris: I just looked at Simon's PW auth draft; there are basically 3 paragraphs you could copy into SCRAM that would make it a GS2 mechanism.
[16:34:37] <jhutz> jhutz: you also have to do the name
[16:34:52] <nico> heh
[16:34:53] <jhutz> chris: can we figure out what name we want, and select the OID appropriately?
[16:34:58] <Dave Cridland> (I thought MD5 was meant to be weak... :-)
[16:35:09] <nico> no, there's no point to having aliases of GS2-* names
[16:35:15] <jhutz> several people: if you can come up with a preimage attack against MD5
[16:35:43] <nico> no, MD5 is not OK for anything new
[16:35:45] <jhutz> Alexey: MD5 is mandatory hash; is that OK
[16:35:50] <jhutz> jhutz: how is the hash used?
[16:35:57] <jhutz> [not true - HMAC-MD5 is probably still OK]
[16:35:58] <nico> except for GS2 mech names, because there's no cryptographic point to it
[16:36:17] <jhutz> [yes, and anyplace it's not used for cryptographic properties]
[16:36:28] <nico> but, keep in mind that using MD5 even for that will probably cause heartburn when doing FIPS-140-2 validation
[16:37:00] <jhutz> Sam: When Tim and I discussed this, I don't think either of us feels HMAC-MD5 is bad in an existing protocol. We're kind of wondering why you'd pick it in a new protocol. We'd suggest SHA-1 or SHA-256.
[16:37:07] <nico> I think we shouldn't recommend SHA-1 either, even HMAC-SHA-1, not for *new* things
[16:37:08] <jhutz> Chris: I'd prefer we drop MD5 and go to at least SHA-1
[16:37:31] <Dave Cridland> I thought SHA-1 had a paper out on preimage attacks (theory, weak variant of SHA-1, etc).
[16:37:59] <jhutz> > I thought MD5 was meant to be weak Uh, no.
[16:38:19] <jhutz> > I thought SHA-1 had a paper out on preimage attacks I don't recall that. You sure it wasn't a collision attack?
[16:38:19] * nico lends jhutz some humor
[16:38:33] <jhutz> Alexey: two other issues, related to channel bindings
[16:38:42] <jhutz> We need to look at how they're being hashed.
[16:38:49] <Dave Cridland> jhutz: No, Bruce Schneier (sp?) published it. Referenced from the RFC on hash attacks, whatever that is.
[16:39:05] <nico> no, there's no preimage attacks on SHA-1
[16:39:14] <nico> there's collision attacks on it
[16:39:23] <cnewman@jabber.org> What we could do is look at the next available IANA OID for GSS mechanisms, and run through the number space generating the SASL GS- name until we get a name that's memorable, then ask IANA for that number ;-)
[16:39:24] <nico> IIRC on the order of 2^69
[16:39:49] <Alexey> Question from Abhijit: 1. Right now, the client sends the actual channel-binding data to the server in order to detect MITM attacks. Is this necessary? Is it even good, since an attacker would presumably gain access to it? Would it be OK instead to mix the channel-binding data in to the Message and thus the ClientSignature, and just tell the server to do the same while verifying, without sending the actual data?
[16:40:44] <jhutz> Alexey: Using a hash would keep it secret, but that's not necessary, right?
[16:41:00] <Dave Cridland> http://eprint.iacr.org/2004/304
[16:41:01] <nico> answer to abhijit: a) if there's an MITM then the MITM already has the channel binding data, b) it's protected by the SASL mech, so an MITM in the lower layer won't be able to modify it
[16:41:17] <jhutz> Kurt: You take the secret things and hash them when constructing the CB value; there's no need to keep it secret
[16:41:36] <jhutz> Sam: Looking at RFC5056, one of the things you can register for a channel is whether the CB data requires confidentiality.
[16:41:40] <nico> there's no need to provide privacy protection of the channel binding data against MITMs, only against eavesdroppers
[16:41:41] <nico> channel me
[16:41:51] <jhutz> So it's at least possible to have such a CB type. None of the ones we have so far have that requirement.
[16:41:55] <jhutz> The registry will have that information.
[16:42:09] <nico> sigh, channel me
[16:42:09] <jhutz> Kurt: But that means a mech would need to protect CB if they're secret.
[16:42:23] <jhutz> yes yes, I will
[16:42:24] <nico> you're all getting it wrong :(
[16:42:34] <nico> argh!
[16:42:51] <nico> shall I repeat or can you scroll up?
[16:43:38] <nico> thanks
[16:43:40] <nico> :)
[16:43:41] <jhutz> No; we scrolled up an alexey readit
[16:44:00] <nico> yes, I can hear, though with lag
[16:44:40] <Dave Cridland> Humour my stupidity a sec: Why do we need to send the CB data at all, when presumably both ends know what it ought to be?
[16:44:45] <nico> heh -- TLS master secret as a channel binding that requires secrecy -- true, but funny
[16:45:04] <jhutz> Sam: If I designed a CB type that needs confidentiality, and used it with a channel that doesn't provide confidentiality, then the upper layer needs to provide confidentiality if that's going to be secure.
[16:45:16] <nico> dave cridland: RFC5056 allows using MICs of CB data
[16:45:28] <jhutz> Philip Guenther(sp?): But the CB definition could just use a hash
[16:46:08] <jhutz> Sam: What you'd have to say is, if the SASL mech doesn't provide confidentiality for the CB, then that CB type must not be used with that SASL mech over channels that don't provide confidentiality.
[16:46:22] <nico> right, Sam's getting it right
[16:46:27] <Alexey> Dave: you also need to signal CB type (prefix), which is also a part for the CB
[16:46:33] <jhutz> You can make it the app's problem - if you have one of those stupid CB types, then only offer it to sasl if you're getting confidentiality from your channel
[16:46:48] <jhutz> ???: "Doctor, it hurts when I do this!"
[16:47:11] <nico> oh yeah, we'd certainly react that way to stupid CB specs
[16:47:15] <jhutz> Sam: I don't know why anyone would want to define a CB type with that property. I'd hope if someone tried, Nico would come forward and say there's a better way.
[16:47:21] <jhutz> ???
[16:47:22] <nico> we left that in just in case
[16:47:26] <nico> don't hash!
[16:47:29] <nico> use MICs
[16:47:31] <jhutz> Sam: We can solve this with sec cons text or hashing.
[16:47:55] <nico> make GS2 use MIC instead of wrap tokens for channel binding data if you like
[16:48:02] <jhutz> [um, doesn't using hashing or MIC require unique CB?]
[16:48:06] <nico> IIRC it uses a wrap because there's other data being sent
[16:48:09] <jhutz> Sam: By "hash", we mean soemthing with a key
[16:48:13] <nico> got it
[16:48:46] <nico> it might be good to revise GS2 to use a MIC of the CB and shove that into the wrap token
[16:49:05] <nico> both sides must be able to reconstruct the channel bindings
[16:49:06] <jhutz> nevermind
[16:49:15] <nico> which is why there's no need to send them in the cleartext
[16:49:24] <nico> it'd be good to have Simon here :)
[16:49:35] <jhutz> [well, know his jid?]
[16:50:02] <jhutz> Sam: One issue is that mixing CB into the message may be problematic; do you want to support the case where one side uses CB and the other side doesn't?
[16:50:04] <jhutz> Kurt: no
[16:50:18] <nico> Sam: yes, we support that in GS2
[16:50:31] <nico> and that affects security layer negotiation
[16:50:36] <jhutz> Philip: GS2 supports the ability for the two sides to choose from multiple CB's
[16:50:38] <nico> CB success -> no sec layers
[16:50:45] <nico> CB failure -> sec layers
[16:50:52] <jhutz> Chris: I'd be inclinde to say, if TLS was used, you must use TLS.
[16:51:02] <jhutz> Sam: You're supposed to use the one closest to the app; 5056 covers this.
[16:51:22] <jhutz> Chris: What concerns me is IPsec.
[16:51:26] <nico> right, that allows you to nest channel binding if you really want
[16:51:30] <jhutz> Because the app might not know about it.
[16:51:41] <nico> app->SASL->TLS->IPsec
[16:51:50] <nico> rat hole?
[16:51:55] --- kdz has left
[16:52:15] <jhutz> jhutz: This discussion belongs in review of 5056
[16:52:27] <nico> sam: GS2 already covers this!
[16:52:33] <jhutz> Sam: In case XXX, you don't want the auth to fail; you just want to not believe CB happened.
[16:52:40] <nico> channel me
[16:52:52] <jhutz> Sam: I don't want a server that goes out of its way to discover that IPsec is used to have less interop than a simpler server,
[16:53:07] <nico> lag sucks :)
[16:53:10] <jhutz> Nico, we know GS2 covers the nesting thing.
[16:53:23] <nico> so why is Sam going on about it then? :)
[16:53:27] <jhutz> Oh, no, nevermind.
[16:53:44] <jhutz> I meant something else. But sam has it right
[16:54:05] <jhutz> Sam: Once we fix a bug that may not exist in GS2, all the problems will be solved; then borrow from it.
[16:54:11] <nico> man
[16:54:17] <nico> it's already covered
[16:54:25] <jhutz> Chris: Advice to abhijit is... ?
[16:54:31] <jhutz> Sam: "Do what GS2 does"
[16:54:49] <jhutz> Kurt: He can handwave on CB, get stuff in the right place, then we can talk about converting to GS2.
[16:55:01] <jhutz> Chris: I do not believe there is consensus to make this a GS2 mech. Is there?
[16:55:08] <jhutz> Kurt: There's consensus to try.
[16:55:24] <nico> there was consensus to make it a GS2 mechanism described as non-GS2
[16:55:30] <jhutz> Sam: If you make it a GSS mechanism, it introduces extra round trips.
[16:55:36] <nico> so that folks who are scared of the GSS-API don't get scared
[16:55:41] <nico> really?!
[16:55:56] <nico> I thought we worked hard to make GS2 not require extra RTTs
[16:56:41] <nico> well, yeah, GS1 is dead :)
[16:57:23] <jhutz> jhutz: I don't see extra complexity in making this a GS2 mech.
[16:57:45] <jhutz> Alexey: We need to make sure it aligns with GS2.
[16:57:48] <jhutz> Sam: right.
[16:57:57] <nico> if you don't make it a GS2 mech then you lose CB
[16:58:02] <jhutz> Sam: Looking at GS2, it answers questions as follows...
[16:58:03] <nico> and you re-do lots of work
[16:58:15] <jhutz> - It doesn't confidentiality-protect CB's
[16:58:21] <Dave Cridland> One of the issues with DIGEST-MD5 was implementation complexity. I don't see how making it GS2-* help this.
[16:58:48] <jhutz> - It provides a facilitiy so that if one end provides CB and the other doesn't, it still works (without CB)
[16:59:00] <nico> dave: if you implement a GS2 layer and your GS2 mechs as plugins then it simplifies things
[16:59:36] <jhutz> Dave, the point here is that defining this correctly means that there isn't increased implementation complexity for people implementing it directly, and we have the ability later to abstract out the GSS part and use it as a GSS mechanism, and then ==nico
[16:59:57] <jhutz> Sam: I believe the message formats will be ugly, but it'll be one round trip
[17:00:10] <Dave Cridland> nico: Well, I'm thinking in terms of the XMPP crowd, who don't have a GS2 layer anyway, and quite possibly don't want one. They're currently happy with DIGEST-MD5. I'd rather not see additional stuff involved.
[17:00:15] <jhutz> Chris Newman: I want to get more clarification here ... Will Copying the text from Simon's draft do what we need?
[17:00:28] <jhutz> Chris: If we need additional text, someone needs to write it.
[17:00:39] <nico> dave: but then they never, ever get to do CB
[17:00:50] <nico> because they'll never want to implement a new thing
[17:00:55] <jhutz> Sam: If we can't get GSS experts, I'll try to twist their arms; if that doesn't work, we'll give up.
[17:00:59] <Dave Cridland> nico: Doesn't compute. How is GS2-* magical on the subject of CB?
[17:01:02] <nico> and then we'll all bitch and moan for years
[17:01:16] <nico> dave: it gets it right (or will by the time it's published)
[17:01:26] <nico> ignore it at your own risk
[17:01:43] <Dave Cridland> nico: Sure, but I don't see why that means nothing else can.
[17:01:49] <jhutz> Dave, nothing is magical about GS2 wrt CB. But basically, if we don't do GS2, we still get to pick one of (1) no CB, (2) copy CB from GS2, or (3) peril
[17:01:54] <Alexey> Kurt: I18N is missing. Need to add SASLPrep, etc
[17:01:59] <nico> yes
[17:02:01] <nico> I will
[17:02:14] --- kdz has joined
[17:02:27] <nico> yes
[17:02:41] <jhutz> Chris: Nico writes the text for how we make this a SASL mech, and I review, and then we give it to abhijit. OK?
[17:02:50] <jhutz> Nico, please be specific due to latency.
[17:02:50] <nico> I volunteered to write the text that says "and this is how you make this a GSS mech"
[17:03:02] <kdz> re comment last attributed to me: s/I18n is missing/i18n appears to be incomplete/
[17:03:09] <jhutz> s/GSS/GS2?
[17:03:17] <nico> no, GSS
[17:03:22] <nico> because we agreed that
[17:03:29] <jhutz> You're not volunteering for the thing we're looking for.
[17:03:45] <nico> we would write this mech as a GS2 mech but without describing it as a GSS mech to avoid scaring non-GSS weenies
[17:03:48] <jhutz> Someone needs to write the text that will go into the draft that makes it a GS2 mechanism instead of something you lose on.
[17:04:02] <nico> then we'd slap on additional text to explain how you make a GSS mech out of it too
[17:04:08] <jhutz> Yes, Nico, we get that. But someone needs to write things like "this is what has to go on the front of the first token"
[17:04:12] <nico> fine!
[17:04:15] <nico> I can do that too
[17:04:17] <nico> but
[17:04:27] <nico> I'm crushed with day job work till mid-January
[17:04:36] <nico> if you're willing to wait until February
[17:04:36] <jhutz> I think Alexey actually volunteered for that, too. But basically it's going to need people to look over the text from Simon's draft, if we use that.
[17:04:38] <nico> ...
[17:04:41] <jhutz> I'll help too, as needed.
[17:04:51] <jhutz> Next: charter and milestones.
[17:05:17] <jhutz> Tom: I sent a list of proposed milestones to the list. We slipped some of them. I suggest moving everything 4 months later. Comments?
[17:05:31] <jhutz> Alexey: Issue WGLC now on digest-to-historic
[17:05:58] <jhutz> Alexey: That'll be a 3-month slip. We can do 4 for the rest; that's fine.
[17:06:12] --- badra has left
[17:06:16] <jhutz> Kurt: We'll ask the secretariat to mark your existing document as a WG doc
[17:06:32] <frank> Alexey: itt needs an md5-sess incompatibility example (2831 vs. 2617+erratum)
[17:06:55] <jhutz> Frank, are you quoting alexey?
[17:06:59] <jhutz> Or are you asking a question?
[17:07:12] <jhutz> Alexey: I'm not convinced.
[17:07:33] <Dave Cridland> I think if someone has one, it'd be nice to document. I had a lot of trouble explaining this one to the XSF.
[17:07:36] <frank> asking a question
[17:08:16] <jhutz> Kurt: Issue the last call.. Frank is welcome to give the comment as a LC comment (specific text would help)
[17:08:29] <jhutz> Kurt: We want to have discussion around a specific suggestion.
[17:08:51] <jhutz> Kurt: We can do this during LC; don't need to hold up the start of WGLC for it.
[17:09:17] --- badra has joined
[17:09:30] <jhutz> Kurt: Frank, go ahead and submit your comment when you see the WGLC; if you have suggested text, that would be appreciated.
[17:09:57] <frank> ACK, needs to be checked with another implementation
[17:09:58] <jhutz> tom: Given holidays etc; I think 4 mos shift is better than 3.
[17:10:39] <jhutz> Open Mic.
[17:10:50] <nico> where are the slides?
[17:10:51] <jhutz> Philip Guenther: I don't know if this WG wants to tackle this, but...
[17:11:03] <jhutz> ietf-vnc.central.org and on IETF meeting materials
[17:11:06] <guenther> that's Mark Crispin
[17:11:20] <jhutz> <damn; I lost track of what philip was saying>
[17:11:25] <jhutz> Oh, oops.
[17:11:28] <jhutz> Mark, then.
[17:11:32] <guenther> (btw, jhutz, you did spell my name correctly before, thank you)
[17:11:46] <jhutz> Damn; did I attribute some earlier comment of Mark's to you, too?
[17:11:50] <guenther> no
[17:12:54] <jhutz> Someone fill in what Mark said
[17:13:11] <jhutz> Kurt (as individual): This is really an issue for the app SASL profile, not for sasl itself.
[17:13:15] --- badra has left
[17:13:21] <jhutz> We don't know if SASL is the only mech, or if the app supports others.
[17:13:55] <jhutz> If people designing app protocols have multiple facilities, they need to deal with it.
[17:14:56] <jhutz> Philip: concern is that clients that do follow the rule that if there are SASL mechs don't use non-SASL will lose?
[17:14:59] <jhutz> Mark: yes
[17:15:05] <jhutz> Kurt: LDAP has this problem, too
[17:15:36] <jhutz> We used to say that you never use SASL PLAIN and ANONYMOUS becuase sasl has simple. Turns out that was a bad idea, because SASL PLAIN is not the same as LDAP's simple.
[17:17:11] <Dave Cridland> Indeed. New protocols with legacy auth does not make sense... Older protocols need to make their own choices.
[17:18:37] <nico> they've already made them...
[17:18:38] <jhutz> jhutz: This is a problem for legacy protocols [crispin agrees]. You need to specify the answer for each legacy protocol that adopts SASL. But such protocols should not leave it up to implementations; that's what causes problems for IMAP [crispin adds ftp, smtp, etc]
[17:19:55] <jhutz> chris: maybe advice to put in sasl base spec, that when you have a legacy mech that is the same as a sasl mech, you want consistent security policy.
[17:19:56] <Dave Cridland> nico: Not always clearly.
[17:20:16] <nico> dave: well, yes, that's why they're older protocols
[17:20:18] <nico> :)
[17:20:21] <jhutz> nico, ==dave is the problem mark was trying to bring up. IMAP hasn't made the choice; IMAP implementors have.
[17:20:48] <nico> sadness
[17:21:02] <frank> Getting rid of APOP could be tricky
[17:21:54] <cnewman@jabber.org> APOP is still one of the few authentication protocols in an IETF _full Standard_ document.
[17:22:05] <jhutz> someone else scribe, please
[17:22:31] <nico> I could, with lag...
[17:22:35] <nico> ...
[17:22:57] <nico> kurt: what's helped with the LDAP case, is that it says if you do this then you must use TLS or not use PLAIN w/o TLS
[17:23:03] <nico> who's speaking? chriss?
[17:23:08] <semery@jis.mit.edu> Mark
[17:23:10] <tlyu@jis.mit.edu> mark crispin
[17:23:25] <nico> ?: most ppl in the IMAP community would like to say Though Shall Use TLS
[17:23:38] <Dave Cridland> Erm, I'd only abandon IMAP LOGIN if we mandated SASL-IR, too. Otherwise I use LOGIN over PLAIN - fewer RTTs.
[17:23:39] <nico> mark: a large vendor requires that you fall back...
[17:23:54] <nico> kurt: write an I-D
[17:24:04] <nico> tlyu: it's not clear this belongs in SASL WG
[17:24:09] <nico> kurt: anything else
[17:24:11] <nico> ?
[17:24:14] <nico> huh?
[17:24:25] <nico> kurt is not speaking into the mic
[17:24:29] <nico> oh
[17:24:35] <nico> kurt: adjourned
[17:24:37] <nico> blue sheet
[17:24:38] <nico> s
[17:24:39] <Dave Cridland> nico: That explains why, then. :-)
[17:24:40] <nico> ...
[17:24:46] <nico> dave: kinda, yeah
[17:24:47] <nico> :)
[17:25:34] <nico> l8er
[17:25:39] <Dave Cridland> nico: Aside from RFC5056, what else is there to understand channel binding?
[17:25:54] <frank> thanks to the scribes
[17:26:12] <nico> dave: er, not much
[17:26:26] <nico> hopefully RFC5056 captures all that you need
[17:26:45] <nico> I think I've a blog post on channel bindigns somewhere
[17:26:59] <nico> plus an unfinished one too (that I need time to finish)
[17:27:11] --- finn- has left
[17:27:34] --- semery@jis.mit.edu has left
[17:27:58] <Dave Cridland> nico: Right, I'll reread it and try to get my head around them. I can't help feeling I'm missing something in it somewhere.
[17:28:50] <nico> the jit is: you have a secure channel somewhere but the way you're using it might allow MITMs
[17:29:08] <nico> alice<--tls-->mitm<--tls-->bob
[17:29:14] --- ietf-meeting has left: Disconnected
[17:29:25] <Dave Cridland> I got the impression it was to bind the endpoints of the authentication with the endpoints of a "secure" channel, right?
[17:29:25] <nico> and you are using some authentication mechanism above that channel
[17:29:46] <nico> and you want to make sure that there is no MITM, that what you have is alice<--tls-->bob
[17:30:03] <nico> so you can just not bother doing session crypto above that channel
[17:30:06] <nico> that's the gist
[17:30:12] <nico> that's the purpose of channel binding
[17:30:24] <nico> your description is correct too
[17:31:06] --- frank has left
[17:31:07] <Dave Cridland> Right. So both Alice and Bob know the method for uniquely identifying the channel - so is sending the channel binding data merely in case of, say, two TLS layers in effect or something?
[17:31:38] <nico> I don't follow from ", say..."
[17:32:05] <nico> the channel binding data MUST be at least integrity protected using the authentication mechanism being used above the channel
[17:32:13] <nico> so that the MITM can't modify it
[17:32:28] <Dave Cridland> Well, why can't we just say "Do channel binding with TLS", instead of "Do channel binding with the TLS channel whose Hello messages were <xxx>"?
[17:32:37] <nico> if you have an MITM then the MITM knows the channel bindings that Alice sees and the channel bindings that Bob sees
[17:32:40] <Dave Cridland> I see the need for intergrity of some sort, certainly.
[17:32:41] --- tonyhansen has left
[17:32:50] <nico> you're close
[17:32:58] <nico> the Hello messages aren't enough
[17:33:38] <nico> you need something that cryptographically identifies that channel in such a way that the MITM can't force the channel bindings seen by Alice and Bob to be the same
[17:33:48] --- cnewman@jabber.org has left
[17:33:53] <Dave Cridland> Oh, it's the completion messages rather than the hellos, isn't it? But why send those, rather than just saying "It's TLS", and then binding that into the crypto in the auth?
[17:33:57] <nico> yes
[17:34:15] <nico> "it's TLS" is not enough
[17:34:20] <nico> we need to make sure there's no MITM
[17:34:42] <nico> the only way to do that is to confirm that it's the *same* TLS channel on A's side as on B's side
[17:35:09] <nico> with no chance for the MITM to make two channels A<->MITM and MITM<->B appear to be the same
[17:35:17] <Dave Cridland> But surely both Alice and Bob can then get the completion messages from TLS, include them in the gunk used in the authentication hashes (or whatever), and then the authentication fails if Alice and Bob aren't seeing the same TLS channel?
[17:35:27] <nico> that's channel binding!
[17:35:29] --- kdz has left
[17:35:34] <nico> so now you understand it
[17:35:35] <nico> :)
[17:35:54] <Dave Cridland> Right... Except Alice does send Bob the completion messages, right?
[17:36:09] <nico> Finished messages, yes
[17:36:23] <nico> *protected* by the authentication mechanism being used above TLS
[17:36:32] <Dave Cridland> So Bob gets them from Alice, and from TLS, and compares, rather than Alice and Bob both using them as input to some cryptographic magic.
[17:36:51] <nico> yes, but you can also work them into the A<->B authentication messages
[17:36:53] <nico> that works too
[17:36:59] <nico> provided that you do it right
[17:37:20] <nico> for GS2 we decided to send the CB data
[17:37:23] <Dave Cridland> Ah, okay - so strictly speaking, there's no need to physically send the channel binding data.
[17:37:34] <nico> yoiu can go read the list archives to find out why
[17:37:36] <nico> correct
[17:37:47] <nico> strictly speaking there's not even a need to send MICs of it
[17:37:52] <Dave Cridland> The impression I've had from various people is that actualyl sending it was important somehow.
[17:38:13] <nico> you can plug in the CB data into the upper layer authentication mechanism's key derivation for key exchange
[17:38:17] <Dave Cridland> Well, you need to agree on which layer you're relying on, don't you?
[17:38:26] <nico> yes
[17:38:37] <nico> upper layer here == the app layer
[17:38:39] <nico> not TLS
[17:38:42] <Dave Cridland> So if, say, you have IPSec+TLS, you'd need to point at one of them.
[17:38:59] <nico> if you have the app layer, TLS and IPsec
[17:39:06] <nico> then you'd want TLS to bind to IPsec
[17:39:10] <nico> and the app to bind to TLS
[17:39:22] <nico> you'd not want the app to bind to IPsec
[17:39:34] <nico> if you only have IPsec then you'd want the app to bind to IPsec
[17:39:59] <nico> now, GS2 is based on GSS-API mechanisms
[17:40:00] <Dave Cridland> Right. And if TLS is providing integrity and privacy, then we don't really care if TLS has bound to IPSec, so we still bind to the highest layer underneath which provides int+priv.
[17:40:07] <nico> using a standard API (GSS-API)
[17:40:26] <nico> so modifying those mechanisms to fold CB into authentication wasn't feasible
[17:40:40] <Dave Cridland> Right, that makes sense.
[17:40:43] <nico> and the GSS-API channel binding facility didn't provide the semantics that GS2 needed
[17:41:00] <Dave Cridland> Rather like trying to modify DIGEST-MD5, although Alexey had a pretty good attempt there.
[17:41:04] <nico> which is why GS2 does it's own thing
[17:41:15] <Dave Cridland> Yes, this all makes sense now.
[17:41:18] <nico> yay!
[17:41:22] <nico> me so happy
[17:41:25] <kmurchison> Dave, Nico: I just came back to close my jabber window, and saw your wonderful description of CB. Thx!
[17:41:26] <Dave Cridland> :-)
[17:41:37] <nico> :)
[17:41:42] <nico> me so happy x 2
[17:41:52] <nico> you bring tears to my eyes guys
[17:42:07] <nico> ok, now go forth and implement
[17:42:28] <Dave Cridland> Heh.
[17:42:30] <kmurchison> That will take a couple of more beers :)
[17:42:53] <Dave Cridland> Yes, I did try that one already in HEXA. Now I'll have to do it all over again in SCRAM.
[17:43:13] <nico> I'll buy beers!
[17:43:27] <nico> (within reason)
[17:43:31] <nico> also
[17:43:38] <nico> I'm not physically in Vancouver this week
[17:43:41] --- jhutz has left
[17:43:42] <Dave Cridland> Although this is interesting - if SCRAM becomes GS2-lkjshdlvdh, then this would mean it would have to use GS2-*'s method for channel binding, right? It couldn't bind the CB data into the hash exchange?
[17:44:31] <kmurchison> Either am I. I'm home in Buffalo. My son has 3 hockey games this week (tonight's against a bunch of friends), so I chose family over work
[17:45:08] <nico> dave: correct
[17:45:11] <Dave Cridland> Yeah, I'm in Wales, the only place, apparently, raining more than Vancouver.
[17:45:26] <nico> I'm in Austin
[17:45:29] <nico> it's warm here
[17:45:31] <Dave Cridland> Texas?
[17:45:32] <nico> and dryish
[17:45:34] <nico> yes
[17:45:48] <Dave Cridland> Yes, that's desert, isn't it?
[17:45:51] <kmurchison> Snowing here. Dinner time for me. Thanks again guys. Enjoy the rest of the week.
[17:45:54] --- tlyu@jis.mit.edu has left: Disconnected
[17:46:33] <Dave Cridland> More or less bedtime for me, but thanks Nico, you've cleared a lot up for me.
[17:46:50] <nico> it's not desert
[17:46:58] <nico> there's plenty of vegetation
[17:47:02] <nico> l8er all
[17:47:12] <nico> np
[17:47:19] --- Dave Cridland has left
[17:47:29] --- nico has left
[17:50:58] --- Alexey has left: Computer went to sleep
[17:51:02] --- guenther has left
[18:12:44] <hartmans@jis.mit.edu/owl> Ugh. Ugh. And ugh. To be a useful gss mech it needs to support gss channel binding. But to be a sasl mech it needs to have a wrap token with at least integrity
[18:13:18] --- kmurchison has left
[18:39:00] <hartmans@jis.mit.edu/owl> v4 also breaks management processors on hosts
[18:39:07] <hartmans@jis.mit.edu/owl> mix
[21:34:28] --- kdz has joined
[21:34:49] --- kdz has left