[07:55:34] --- ams has joined
[07:56:32] --- ams has left
[07:59:13] --- ams has joined
[08:01:23] --- Simon Josefsson has joined
[08:01:31] --- kmurchison has joined
[08:01:56] --- hartmans@jis.mit.edu/owl has joined
[08:06:26] <ams> hi.
[08:06:58] * ams has set the topic to: IETF68 - Simple Authentication and Security Layer (SASL) WG
[08:07:52] --- tlyu@jis.mit.edu has joined
[08:09:05] --- rlbob has joined
[08:09:54] <rlbob> i'll be scribing as best i can ...
[08:10:07] <rlbob> session starts at 13:10
[08:10:17] --- ietf-meeting has joined
[08:10:20] <rlbob> tom: agenda bash
[08:11:37] <Simon Josefsson> (please check mic gains, quite distorted now)
[08:11:46] <rlbob> item on smtp tls doc that currently has iesg discuss on it?
[08:12:05] <Simon Josefsson> (better now)
[08:12:05] <rlbob> sam: maybe relevant to how sasl and tls interact
[08:12:20] <rlbob> kz: doc status
[08:12:25] --- jhutz@jis.mit.edu/owl has joined
[08:12:28] --- Dave Cridland has joined
[08:12:34] <rlbob> gs2 LC ended yesterday
[08:12:51] <rlbob> crammd5 LC ends shortly
[08:12:54] --- aaronstone has joined
[08:13:20] <rlbob> document: cram-md5: any issues?
[08:13:33] <rlbob> alexey: frank ellerman's comments?
[08:13:51] <rlbob> kz: preparing response
[08:14:10] <rlbob> tom: seem to be items previously discussed
[08:14:14] --- kasumigaura has joined
[08:14:59] <rlbob> kz: anyone reviewed the cram-md5 doc? (justa couple ofhands)
[08:15:13] --- kdz has joined
[08:15:16] <rlbob> more reviewers needed, even if sasl is not your area
[08:15:18] --- alexeymelnikov has joined
[08:15:25] <ams> i've just read it, and it looked ok to me.
[08:16:11] --- jimsch1 has joined
[08:16:18] <rlbob> gs2 doc: now going thru second LC, only a couple of nits
[08:16:40] <rlbob> alexey: this doc is dependent on nico's channel bindings doc, now in IETF LC
[08:17:18] <rlbob> digest-md5: "to be or not to be", that is, y'know, the question
[08:17:45] --- nico has joined
[08:17:57] <rlbob> alexey: some interop problems, too many features, not implemented properly, some security problems
[08:18:05] <rlbob> complex to implement from scratch
[08:18:26] <rlbob> comments from many, including original author, that something better should be done
[08:19:27] <rlbob> three alternatives put to sasl list: drop the doc; just do clarification doc; do new doc with new features
[08:19:43] <rlbob> no one has supported doc-with-new-features
[08:19:59] <rlbob> some would like mechanism with its properties, just simpler
[08:20:51] <rlbob> drafts have been published recently with those properties for new mechanisms
[08:21:18] <rlbob> kz: would need to publish something to justify move to historic
[08:21:56] <rlbob> sam: may not need RFC to move digest to historic, just request it
[08:22:29] <rlbob> kz: people may object to new mech under old name
[08:22:50] <rlbob> alexey: proposal is backward compatible, thru negotiation
[08:22:56] --- nico has left
[08:23:06] <rlbob> sam: key benefit is sharing authn database with SIP
[08:23:16] <rlbob> kz: anyone actually doing that?
[08:23:19] <ams> hm? is someone proposing to reuse the name for a new mechanism?
[08:23:45] <Dave Cridland> ams: No, discussing how different digest-md5 bis is from the original.
[08:24:08] <Dave Cridland> ams: Hence Alexey's backwards compatible comment.
[08:24:22] <ams> oh, i see.
[08:24:46] <rlbob> sam: would like not to make credentials store problem worse
[08:24:57] <rlbob> sam: would like channel bindings in new mech too
[08:25:20] <rlbob> nico: sam, should new SASL mechs be GSS mechs?
[08:25:28] <rlbob> sam: yes, SHOULD be
[08:25:53] <rlbob> nico: GSS mech ala Digest should be easy
[08:25:57] <Simon Josefsson> I agree with Nico about specifying a digest mech as a GSS mech. I have one document laying here doing exactly that. I thought about publishing, but we already had three other new mech's to discuss.
[08:26:28] <rlbob> sam: some say cram is better than digest, don't want that with new one too
[08:26:50] <jhutz@jis.mit.edu/owl> It helps if the power strip is on.
[08:26:53] --- kdz has left
[08:27:19] <ams> don't people say it's better because it's just so much simpler to implement?
[08:27:23] <rlbob> sam: would like new mech, if specified as GSS mech, to also have text about how to use it easily as SASL mech
[08:28:01] <rlbob> kz: sounds like we're getting into the alternative-mech agenda item, so let's do it
[08:28:31] <rlbob> three recent mechs: hexa, scram, yap
[08:28:32] --- nico has joined
[08:28:37] <Simon Josefsson> (fyi: http://josefsson.org/gss-hmac/draft-josefsson-gss-cram.txt)
[08:28:42] <nico> any of them GSS mechs?
[08:28:51] <Dave Cridland> No
[08:29:02] <ams> no
[08:30:16] <nico> simon: thanks for the doc and URL
[08:30:38] <rlbob> dave: hexa, bad name for simple concept
[08:31:08] <jhutz@jis.mit.edu/owl> No, none of them are GSS mechs. I believe the question was already asked on the mailing list; in fact, I thought it was you who asked.
[08:31:11] --- kdz has joined
[08:31:32] <rlbob> hexa intended to be a better DIGEST, easy to implement, good for sysadmins
[08:31:33] <nico> jhutz: I'm jetlagged
[08:31:41] <nico> maybe I did, maybe I didn't
[08:31:44] <rlbob> similar to SCRAM, should be merged
[08:32:59] <Simon Josefsson> One property I believe any solution in this space should be is: make it possible to use non-HMAC MAC constructs. I'd very much like to have AES-CMAC or similar there.
[08:33:00] <rlbob> protocol described ...
[08:33:36] <jhutz@jis.mit.edu/owl> Agenda and slides available online at http://tools.ietf.org/wg/sasl/agenda HTML slides for this presentation at http://dave.cridland.net/slides/
[08:35:04] <rlbob> permits hashed password storage on client and server
[08:35:18] <nico> so, does this share credentials with MD5-DIGEST?
[08:36:03] <rlbob> goals: no plaintext on wire, no external channel for mutual auth, can use DH or leap-of-faith cert val
[08:36:17] <rlbob> hash agility ...
[08:36:41] <rlbob> non-goals: security layers, which nobody does or wants
[08:36:59] <jhutz@jis.mit.edu/owl> "no mechanisms provide this yet, so no one uses it yet, so we decided also not to do it". Great.
[08:37:00] <nico> I like the focus on channel binding :)
[08:37:01] <rlbob> non-goal: fast reauth, nobody does this either
[08:37:17] <jhutz@jis.mit.edu/owl> Though given channel bindings, I suppose it's probably OK to abandon security layers.
[08:37:30] <nico> jhutz: yes, but hexa does have something others don't that makes up for it (channel binding)
[08:37:43] <nico> since everyone uses SASL over TLS anyways
[08:38:28] <rlbob> nico: share creds with digest-md5?
[08:38:31] <rlbob> dave: no
[08:38:59] <rlbob> since deployers don't want plaintext passwords on server
[08:39:48] <rlbob> syadmin goals: like /etc/shadow, hash upgradability
[08:40:05] <nico> well, password hash agility is difficult -- store the plaintext password or force password changes or have a protocol to re-compute the password hash when needed
[08:40:48] <rlbob> chris n: scram draft revived from 1998 ... chris won't continue as editor
[08:41:09] <rlbob> abhijit menon-sen will
[08:41:14] <nico> of course, one might wonder why not use PBKDF#5
[08:41:31] <nico> :)
[08:42:21] <rlbob> features: stored key not plaintext equiv, no realms, no security layer
[08:42:59] <rlbob> in digest-md5 no one stores hashes, this has limited uptake
[08:43:15] <rlbob> protocol described ...
[08:43:25] <nico> actually, these two do share creds with DIGEST-MD5
[08:43:49] <nico> if the latter stores them in the clear...
[08:44:06] <rlbob> chris: let scram go 9 years ago since digest-md5 looked like a big win, but it hasn't been
[08:44:16] <Simon Josefsson> Question: what hash do SCRAM use?
[08:45:22] <ams> simon: chris suggests to put the hash name in the mechanism name
[08:45:38] <rlbob> would use SHA256, would name it with that
[08:46:05] <Simon Josefsson> Comment: SCRAM hard-code HMAC as the MAC algorithm. I would prefer support for non-HMAC MAC's. (e.g., aes-cmac)
[08:46:06] --- lebobits has joined
[08:46:38] <ams> who's speaking now? kurt?
[08:46:44] <rlbob> chris: like upgradability from hexa, but mech name should identify hash
[08:46:53] <Dave Cridland> Kurt speaking.
[08:47:03] <rlbob> kz: YAP ...
[08:47:54] <nico> jhutz: doing a GSS digest mech, of course, would allow us to steal the per-msg tokens from RFC4121 and then we'd get security layers for free
[08:48:02] <rlbob> passwords, no realms, no layers, i18n, hash agility, identity assumption
[08:48:49] <Dave Cridland> Simon: I'm not convinced people would use them. I chose MD5 (Sam, please note) note because it was strong, but because most HMAC implementations are hard-coded to use MD5, and I don't have faith that people would bother to implement HMAC-SHA256.
[08:50:06] <nico> implementing HMAC-x is simple given an implementation of x
[08:50:08] <Simon Josefsson> Dave Cridland: I understand, but don't feel comfortable standardizing anything today that uses MD5. If the MAC-algorithm AND the hash-algorithm is part of the SASL mechanism name, negotiation is easy.
[08:50:09] <rlbob> protocol described ...
[08:50:57] <rlbob> nico: need a nonce to support channel bindings
[08:51:22] <Simon Josefsson> Generally speaking, I think we should think not only about HASH-agility but also MAC-agility.
[08:51:31] <nico> rlbob: no, I said you can't always use channel bindings as a nonce
[08:52:26] <Dave Cridland> nico: Yes, *I* know that HMAC-X is trivial. Unfortunately I don't have that much faith in the average implementor.
[08:52:48] <Dave Cridland> Simon: And yes, MAC agility sounds good.
[08:52:48] <rlbob> kz: slightly different goals than others, always use TLS so authcid is protected
[08:52:56] <nico> dave: well, tough
[08:52:59] <nico> :/
[08:53:39] <rlbob> chris: single round trip is good ...
[08:53:54] <rlbob> sam: channel bindings useless without mutual authn
[08:54:24] <jhutz@jis.mit.edu/owl> Dave, hash agility is mandated; it doesn't matter if _you_ don't think anyone will ever implement with another hash; you need to be prepared to handle the transition to a new hash when (not if) it happens.
[08:54:35] <nico> with channel binding you can do a digest mech in one round-trip w/o a challenge
[08:55:04] <nico> w/o channel binding you should do any digest mech in 1 1/2 round-trips so you can have message two be a challenge
[08:55:28] <rlbob> kz: so, now back to discussing future of DIGESTMD5 ...
[08:55:43] <jhutz@jis.mit.edu/owl> Can people hear Nico OK on the audio?
[08:55:48] <kmurchison> yes
[08:55:54] <rlbob> nico: kill DIGEST, do digest-like GSS mech
[08:56:00] <jhutz@jis.mit.edu/owl> OK, then I'll stop worrying that he sounds quiet in the room
[08:56:24] <Dave Cridland> jhutz@jis.mit.edu/owl: Yes, and that's supported. I figured it'd be easier to switch hash on an existing mech, rather than trying to do everything in one step.
[08:56:27] <rlbob> sam: worry about gss being seen as too hard to implement
[08:56:47] <rlbob> so define a SASL mech that happens to also work as a GSS mech
[08:57:23] <jhutz@jis.mit.edu/owl> You might think that, but then you have to choose a mech before you know which hashes are supported for which mechs. In other words, you have a classic multi-level negotiation problem, which needs to be avoided.
[08:57:31] <Simon Josefsson> My goal with draft-josefsson-gss-cram is to be exactly such a GSS mechanism
[08:57:36] <rlbob> chris: encourage doc editors to experiment with GS2 approach suggested by sam
[08:57:46] <nico> jhutz: what?
[08:57:50] <ams> oh great.
[08:58:15] <Simon Josefsson> The only problematic thing is the token prefix, but that is easily hard-coded with a 5-10 lines of code ASN.1 length computation. The code can be included in the draft to ease implementations
[08:58:17] <jhutz@jis.mit.edu/owl> Note that I don't think you can just say "BTW, this is also a GSS mech"; you have to specify how various abstract GSS features map onto the mechanism's capabilities, if they do at all. But it shouldn't be that hard.
[08:58:39] <rlbob> sam: recommend looking at PKDF2 (?) for password processing (?)
[08:58:46] <nico> ah, yes, PBKDF2, not PBKDF#5 (PBKDF2 is from PKCS#5)
[08:58:53] <tlyu@jis.mit.edu> re ASN.1 length: it's just base-128 variable-length integer encoding...
[08:59:17] <nico> jhutz: no, you make the set of features small, so all are mapped to GSS
[08:59:26] <tlyu@jis.mit.edu> er, nevermind, i was thinking of the wrong thing. length is actually easier
[09:00:41] <rlbob> kz: seems like continued work on digest-md5 is supported by no one
[09:01:14] <Simon Josefsson> tlyu@jis.mit.edu: it is not difficult, but providing examples to implement it would help I think. when some people see "ASN.1 DER length field" they stop listening
[09:01:20] <rlbob> sam: would be failure for this wg to deprecate digest and not recharter to do something else
[09:01:21] <ams> did someone (nico?) volunteer to help with gss stuff?
[09:01:36] <nico> simon: heh
[09:01:39] <rlbob> nico said he would write text, not edit
[09:01:51] <nico> what rlbob said
[09:01:53] <Simon Josefsson> fwiw, i definitely volunteer to work on a gss mech. i have already started the document (see earlier url)
[09:02:04] <nico> simon: thanks
[09:02:14] <Simon Josefsson> i missed the -00 cut-off dates due to travels, and stopped editing it
[09:02:35] <jhutz@jis.mit.edu/owl> The point is, you have to say things like which status flags get set when, etc.
[09:03:18] <rlbob> alexey: can't we just to replacement under digest-md5 milestone?
[09:03:43] <rlbob> sam: no, must recharter, but it's not hard to do, just write new text
[09:04:49] <rlbob> kz: options for digest: ask to move to historic; ask to move, but with i-d document; or do something more complicated
[09:05:39] <rlbob> sam: would need a couple paragraphs of text to request move to historic
[09:06:21] <rlbob> kz: is there value in having an RFC to document this? would be 1-pager
[09:06:43] <rlbob> sam: if it takes as long as cram applicability statement, then no
[09:06:57] <ams> why exactly do new SASL mechanisms have to be GSS mechanisms too? that's not clear to me. (i'm sorry, i don't know anything about GSS.)
[09:07:20] <nico> ams: are you physically here?
[09:07:26] <ams> nico: no.
[09:07:30] <Dave Cridland> NFS was mentioned as a protocol which does GSSAPI but not SASL.
[09:07:39] <nico> ams: don't be confused, a GSS mechanism does not require that you have an implementation of the GSS-API
[09:07:59] <nico> doing it as a GSS mechanism is more general than as a SASL mech
[09:08:05] <rlbob> chris: if there is no volunteer to write digest-clarification, then have to move to historic ...
[09:08:22] <nico> because the GSS-API (note: the protocol, forget the API, which is where the complexity is) is more general than SASL
[09:08:24] <rlbob> alexey: he could write this, but only if people want it
[09:08:30] <nico> GSS mechanisms can be SASL ones (see GS2)
[09:08:31] <Simon Josefsson> ams: fwiw, I see it is convergence between sasl and gss-api. next step is to converge eap and gss-api/sasl too
[09:08:34] <nico> but the reverse is not true
[09:08:52] <ams> simon: and this will make things simpler?
[09:08:55] <rlbob> sam: as individual, would rather not see an update document
[09:08:56] <Dave Cridland> So there's logistical reasons to have it as a GSS mech. Although I'm pretty sure that there's no chance of the average programmer writing a SASL mech that needs the GS2-* wrapping.
[09:09:11] <rlbob> kz: right, that reinforces usability
[09:09:19] <Simon Josefsson> ams: yes, that's the goal. it is easy to have one digest-mechanism than having one gss-api digest mechanism and one sasl digest mechnism
[09:09:49] * Simon Josefsson raises hand to move digest-md5 to historic
[09:09:52] <nico> ams: the GSS-API is two things: a protocol pattern and an API
[09:10:08] <kdz> historic or not?
[09:10:13] <ams> <- raises hand too
[09:10:40] <nico> the protocol part is trivial, the API is complex, though there are use cases where you need a very small subset of the API
[09:10:45] <rlbob> straw poll: move DIGEST-MD5 to historic? (7-10 hands) don't move? (no hands) don't care (a few)
[09:10:50] <nico> so don't be scared by "GSS"
[09:10:55] <Simon Josefsson> Dave Cridland: the bits on the wire that differs are quite small. gs2 is a lot of text for a small things
[09:11:15] <Simon Josefsson> Dave Cridland: but i understand this concern. the documents must be very clear for people who do not want to understand any of gss
[09:11:24] <Dave Cridland> Simon: So tell that to average joe IMAP client implementor. :-)
[09:11:34] <nico> I'm quickly coming to the conclusion that RFC2743 is way too difficult to read and that we need a gentle intro to the GSS-API that is mostly uncluttered by API matters
[09:12:10] <tlyu@jis.mit.edu> you could write a one-page about how to code the initial token framing
[09:12:11] <rlbob> kz: anyone prefer a RFC moving to historic? (no hands?)
[09:12:36] <ams> i agree with alexey
[09:12:53] <rlbob> alexey: would like someone looking at RFC index to see positive indication that DIGEST is deprecated
[09:12:54] <Simon Josefsson> (the jabber round-trip lag feels like around 5s... sigh)
[09:13:32] <rlbob> dave: can new mechanism doc declare DIGEST historic?
[09:13:48] --- lebobits has left
[09:13:52] <rlbob> sam: sure, but better to separate
[09:14:18] <jhutz@jis.mit.edu/owl> nico, sounds like an item for kitten.
[09:15:15] <ams> rlbob: what was the question again?
[09:15:19] <rlbob> poll: work group item for hash-based password mech? (7-10 hands) should not be work item? (no hands)
[09:15:34] <hartmans@jis.mit.edu/owl> I want to run this doc by imap implementers. If the gss approach is not actually simple enough for them. . . Then we'll revisit
[09:15:39] <ams> oh, fine. i raise my hand too, somewhat delayed.
[09:15:47] --- shpark has joined
[09:16:06] <rlbob> sam: will new charter state specific mech, or generic?
[09:16:10] <nico> jhutz: actually, it is an item for KITTEN, and I was convinced of this years ago :)
[09:16:14] <rlbob> kz: would like it to be generic
[09:16:31] <ams> was it sam or chris saying to not specify gss in the charter?
[09:16:34] <rlbob> sam: <groan> propose what you want, i'll respond
[09:16:52] <rlbob> ams: kurt
[09:17:26] <ams> ok, i agree with that. (but i couldn't understand what sam's saying.)
[09:17:31] <rlbob> kz: opinions on what to put into charter?
[09:18:03] <rlbob> dave: merge best points from hexa+scram, maybe yap could stand alone
[09:18:53] <rlbob> kz: would favor one mechanism as DIGEST replacement, don't think YAP is a candidate
[09:19:27] <rlbob> kz: YAP can continue as individual effort, maybe experimental
[09:19:56] <rlbob> kz: already writing an implementation of it ...
[09:20:46] <rlbob> alexey: interested to do YAP impl just to see if it's simple, lemonade would be interested
[09:20:54] <rlbob> kz: HTTP might be interested too
[09:21:20] * Simon Josefsson thinks sam speaks too close to the mic
[09:21:28] <ams> sam: you have the mic too close to you, i think
[09:21:43] <rlbob> sam: need security-area review, security-area LC on a spec
[09:22:40] <rlbob> chris: definitely varying requirements, eg ntp which doesn't want channel protection
[09:23:28] <rlbob> vs lemonade which really wants to avoid roundtrips
[09:24:20] <rlbob> kz: good for WG to focus on scram/hexa based on their requirements
[09:24:37] <rlbob> kz: and consider what to do with YAP after more work
[09:25:01] <rlbob> sam: for lemonade to use it it would have to be standards track
[09:26:48] <ams> for what it's worth, i was going to implement yap too.
[09:27:52] --- kasumigaura has left
[09:28:35] --- shpark has left
[09:28:56] <rlbob> tom: may need to investigate appl demands before deciding on charter rev, eg if lemonade wants YAP it should be WG item
[09:33:02] <rlbob> poll: have enough info to make choice of one vs two/more mechs today? yes (none), no (4 or so)
[09:33:40] --- kasumigaura has joined
[09:33:56] --- aaronstone has left
[09:34:58] <rlbob> kz: though there is consensus on hexa+scram to replace DIGEST
[09:36:34] <rlbob> kz: implementation reports to be done for SASL base RFC
[09:36:49] <rlbob> (new topic, that is)
[09:37:11] <rlbob> kz: so, chairs starting to assemble reports
[09:37:19] <rlbob> that's RFC 4422, btw
[09:37:35] <ams> question: what do the chairs need/want from implementers?
[09:37:56] <rlbob> sam: 4422 has normative refs to various things that are not going to Draft, most notably ACAP
[09:38:25] <rlbob> kz: ouch, that was an editorial mistake
[09:38:40] <Dave Cridland> I say we have to push ACAP to draft. ;-)
[09:38:55] <ams> dave: i was just waiting for you to say that.
[09:39:42] <rlbob> sam: can be fixed on way to Draft status
[09:40:34] <rlbob> kz: also ref to saslprep, but it's a profiling requirement, not impl; basically BCP-type SHOULD
[09:42:06] <Dave Cridland> That was Bob Morgan, saying about RFC2119 talking solely in terms of implementations.
[09:43:03] <rlbob> kz: people referencing 2119 in specs say how it applies to non-implementation activities
[09:43:53] <rlbob> new item: smtp-auth doc
[09:44:35] <rlbob> alexey: recently became editor of smtp-auth doc, it got "discuss" comment from sam
[09:45:59] <tlyu@jis.mit.edu> https://datatracker.ietf.org/public/pidtracker.cgi?command=view_comment&id=64389
[09:46:11] <rlbob> comment is: have to be more clear about mandating PLAIN, also have to say which external mech is to be used by SASL EXTERNAL ...
[09:47:07] <Simon Josefsson> can anyone hear who is speaking in the streamed audio?
[09:47:21] <jhutz@jis.mit.edu/owl> Alexey is speaking; are you having trouble hearing him?
[09:47:46] <Simon Josefsson> jhutz@jis.mit.edu/owl: yes, i can't hear anything. i think i hear him through a secondary mic
[09:48:28] <jhutz@jis.mit.edu/owl> The mic he was using wasn't on.
[09:48:35] <Simon Josefsson> jhutz@jis.mit.edu/owl: ok, thansk!
[10:42:12] --- LOGGING STARTED
[10:42:39] --- frank has joined
[10:42:59] --- frank has left
[10:43:05] --- frank has joined
[10:43:50] --- frank has left
[13:24:41] --- alexeymelnikov has joined
[13:58:20] --- alexeymelnikov has left
[15:38:34] --- shpark has joined
[15:38:40] --- shpark has left