[20:22:21] kmurchison joins the room [20:22:53] kmurchison leaves the room [21:11:51] Simon Josefsson joins the room [21:12:27] leifj joins the room [21:16:59] nico joins the room [21:17:06] ietf-meeting joins the room [21:17:16] hartmans@jis.mit.edu/owl joins the room [21:17:17] Ken Raeburn joins the room [21:18:13] David Cooper joins the room [21:18:45] tlyu joins the room [21:22:07] prussell-nd joins the room [21:22:47] [21:22:56] that's how you scribe silence [21:23:41] [21:23:47] sorry, that's a yes [21:24:14] kdz joins the room [21:24:32] nico, you want to volunteer to jabber scribe? [21:24:41] ludovic.poitou joins the room [21:25:08] cyrus joins the room [21:25:22] alexey.melnikov joins the room [21:25:26] nico is multitasking [21:25:34] Hello [21:25:45] tlyu leaves the room [21:25:50] stpeter joins the room [21:25:52] tlyu joins the room [21:25:55] Document status [21:26:38] Kurt is trying to be politically correct about status of WG documents [21:27:25] Chairs: SCRAM LDAP draft is not a WG item [21:27:32] Ken Raeburn leaves the room [21:27:38] Ken Raeburn joins the room [21:28:10] Kurt: short term goal is to unstuck SCRAM/DIGEST/CRAM/GS2 [21:28:21] gs2 is pending on scram decision [21:28:50] I can use jabber instead of mike [21:29:26] (it is difficult to hear sam on the audio -- too close to the mic?) [21:29:28] Chris Newman joins the room [21:29:50] I'm somewhat sick. I've mostly lost my voice. [21:30:13] ok [21:30:34] :( [21:31:12] rlbob joins the room [21:31:56] semery joins the room [21:33:11] re scram and family: will there be mandatory-to-implement scram-hash variant? [21:33:16] alexey, our scribe, at the mic ... [21:33:31] discussion of SCRAM doc issues ... [21:33:31] I don't mind saying that SASL implementations that do GS2 should map GS2 mechs to SCRAM mech names if those exist [21:34:13] how to handle SCRAM-based mech names using different hashes [21:34:36] rlbob: SCRAM would have a registry [21:34:39] i don't see the benefit in the complexity of defining a family here [21:34:49] that registry would have the OID and SASL mech name for each hash [21:35:17] I agree with Chris strongly. [21:35:27] chris: should have as few hash functions as we can, so making it easy to add new ones isn't a priority [21:35:34] simon: just that it makes folks who're allergic to the GSS-API happier, I think [21:35:47] but yeah, if we can avoid this, all the better [21:35:54] alexey: clarify? [21:36:20] i agree with chris too on this [21:36:23] chrisn: names should match hashname registry when we use them, but no auto-import of all names [21:36:37] Also, build it into the title of the document. [21:36:52] essentially, make the sasl mechanism not a family of mechanisms anymore [21:37:28] BTW, the name issue is minor [21:37:32] kz: have to register family of mechs, say that names of indiv mechs have to use ... [21:37:43] should we tackle bigger issues first (if there are any)? [21:37:48] kz: registration of family just reserves namespace [21:38:02] nico: yes please [21:38:07] not real mechs, those have to be defined on their own [21:38:24] alexey: calm down, nico [21:38:28] lol [21:38:57] hey, I'm just sayin' don't risk running out of time by ratholing on the easy issues [21:39:32] alexey: clarified extensibility, all extensions optional by default, one special "m" attribute is mandatory [21:39:52] i prefer to avoid extensibility [21:39:54] we have 2 hours, one of which is set aside for rathole [21:40:15] ok, so let's rathole; ain't nothin' funner [21:40:27] alexey: ldap schema, is it appropriate? [21:40:28] sasl is extensible, doing sub-negotiation at every level adds complexity [21:40:30] ty: yes [21:40:45] simon: as long as we're negotiating hash by negotiating mechs then I agree [21:41:09] alexey: various attrs defined [21:41:12] nico: yes, i would prefer if the hash name is in the mech name [21:41:22] I thought that was agreed already [21:41:31] kz: if this is informational, could be defined in terms of password RFC, 3112? [21:41:51] kz: this would be easy [21:42:04] stefans joins the room [21:42:48] alexey: todo: examples need to be written, need implementations, and reviews [21:43:17] kz: when will next rev happen? [21:43:23] tlyu leaves the room [21:43:28] tlyu joins the room [21:43:35] alexey: could be later this week [21:43:55] not waiting for implementor feedback for next rev [21:44:55] open issue: GS2 framing? [21:45:13] leifj leaves the room [21:45:14] cyrus leaves the room [21:45:46] kz: editors need to proceed unless there are blockers [21:45:53] I thought we reached consensus on GS2 framing, or were quite close anyways [21:45:53] cyrus joins the room [21:45:59] the choices are few [21:46:10] they're all similar or equivalent in implementation difficulty [21:46:14] Sam came up with the best one [21:46:33] prussell-nd leaves the room: Replaced by new connection [21:46:36] all text for the first part (base64 encoding binary) and binary for the last part [21:46:38] prussell-nd joins the room [21:46:41] sh: in framing choices, case 3 never needs framing (?) [21:46:56] just another hash [21:47:08] never needs escaping, that is [21:47:16] yes, no escapes [21:47:28] can you recap the three cases? [21:48:03] sh: in case 2, if delimiter appears in input value, have to escape [21:49:04] thank you [21:49:05] ok [21:49:12] sh: case 1 is base64 all the way, case 2 is delimiter with escape, case 3 is reorder so escapes aren't needed [21:49:13] case 1: base64 encode both binary tokens [21:49:29] sh: dislike case 1 [21:49:32] case 2: escape the separator byte value but don't encode the binary tokens [21:49:59] everyone: dislike case 1 [21:50:01] case 3: base64 the first binary token and leave the second binary token unencoded (it's last, so there's no ambiguity) [21:50:25] nico favors (3) [21:50:29] why on the mailing list [21:50:30] ? [21:50:36] we have to confirm consensus on the list [21:50:55] but let's decide here, now, before we take another multi-month break [21:51:19] Ken Raeburn leaves the room [21:51:25] Ken Raeburn joins the room [21:51:42] we're going to try to reach a consensus on approach now. We have the face to face time. [21:52:18] case 2 is yuk [21:52:51] can someone confirm that my description of the three cases above is correct? [21:53:02] i dislike 2, either of 1 or 3 works for me. but i don't care strongly [21:53:58] case 3 assumes scram-mic is fixed length. might be an issue if scram needs to be hash agile [21:54:10] ty: go with case 3, any disagreement? [21:54:32] sh: implications for extensibility [21:55:00] tlyu leaves the room [21:55:03] if the hash is in the mech name then the MIC will be fixed length [21:55:05] tlyu joins the room [21:55:15] however, we cannot assume that's true of all GSS mechs [21:55:34] Sam: need to ignore things before mic= and things in the context token that the other end doesn't understand [21:55:40] (if I got this right) [21:57:23] someone pls scribe that [21:57:45] I have no idea what Chris and Sam were talking about :-) [21:58:45] preparing examples of gs2+krb5 and gs2+scram would be useful to understand this [21:58:58] Simon: agree [21:59:02] jhildebrand joins the room [21:59:08] requirement for gs2: send minimum number of tokens and use requirement for gss implementations of scram: become prot_ready at the point we discussed on the mailing list. [21:59:29] I agree with Sam on this [21:59:52] There is the gss-api prefix-OID that needs to be defined [22:00:21] fine [22:00:23] I agree [22:00:26] brb [22:00:48] In c2, you mic the following: c the following: "qop=none" ["," "cbqop=none" "," channelbinding] The interesting thing is what key you use. [22:02:47] i think the saslprep SHOULD should be dropped when going to draft standard [22:04:00] http://tools.ietf.org/rfcdiff?difftype=--hwdiff&url2=http://tools.ietf.org/id/draft-ietf-sasl-4422bis-00.txt [22:04:58] RFC 5198! [22:05:05] Kurt: if we are dropping saslprep, we need to replace it with something. That something needs to be in a draft [22:06:00] rfc5198 contains nfc which is normalization [22:07:02] Kurt reminds the WG that saslprep revision is not in the updated charter [22:07:07] back [22:07:29] (sorry i can't be in the room, busy in SIMPLE) could someone propose that if OAuth gets approved, it should have a SASL mechanism defined for non-HTTP protocols? [22:07:34] Kurt: There doesn't seem to be enough energy in the WG to do that [22:07:58] if there is not enough energy, rfc5198 may be good enough and solves the problem with unicode versioning [22:08:16] can't SASL mechs be done as indiv. submissions? [22:08:25] anyways, GSS mechs can be [22:08:45] so do OAuth as a GSS-API mech and then use SASL/GS2 so as to use it in SASL [22:08:59] nico: won't be implemented that way. [22:09:36] Most of the GSSAPI stuff we've done has relied on MS's GSSAPI stack to do Kerb. which means adding a GSSAPI mech is nearly impossible. [22:09:39] Pasi: nobody on the mailing list seemed to be interested in doing saslprep replacement that produces the same output as saslprep for some common cases (e.g. europeen languages) [22:10:17] jhildebrand: you don't need to use ms gssapi to do this. implementing the gss-api wire tokens is simple [22:10:24] jhildebrand: I'd have to re-read up on OAuth in order to comment fursther [22:10:36] jhildebrand: what Simon said [22:11:00] jhildebrand: the GSS-API is scary, but it's actually quite simple [22:11:13] Simon Josefsson: i'm *already* using MS GSSAPI, and can't stop. [22:11:34] Kurt/Sam: NET-UNICODE is not good enough as a replacement for SASLPrep [22:12:09] jhildebrand: I don't understand what you're saying; e-mail seems better [22:12:27] nico: will send to the list. [22:12:46] jhildebrand: i'd be happy to help specifying gss-api interface for oauth and consequently for sasl [22:12:55] jhil: adding an OAuth mech as a SASL WG item would require charter revision, so unlikely to happen without much more discussion [22:12:56] Ken Raeburn leaves the room [22:12:59] Tom talks about CRAM-MD5 future [22:13:02] Ken Raeburn joins the room [22:13:23] Q1: RFC 2195 is a Proposed - do we want to do anything about this? [22:13:26] rlbob: we could put it in the new OAuth charter, then. :) [22:13:53] but indeed people are interested in oauth/sasl, so worthy of discussion, perhaps on existing oauth list [22:14:12] Q2: IANA registry entry for CRAM-MD5 says Limited. Anything we want to do with this? [22:14:25] jhildebrand: i think it is better to specify oauth sasl mech in the oauth wg. it can be reviewed by sasl wg [22:14:30] Q3: track of draft-ietf-sasl-crammd5-10 [22:14:37] rlbob: thought i'd mention it now, in case anyone wanted to discuss it IRL. [22:14:40] Simon Josefsson: +1 [22:14:56] rlbob: I think a new OAuth list may be on the way, but point taken [22:15:00] I think nico is right; if it can be, oauth wants to be a gss mechanism. It's possible to do that such that doing a native sasl implementation is straightforward and doesn't require understanding GSS. We're doing that right now with scram. [22:15:07] jhildebrand: btw, is oauth@ietf.org up yet? i was never able to join the oauth googlegroup... [22:15:15] Kurt speaking as an individual [22:15:15] Simon Josefsson: not yet AFAIK [22:15:37] Kurt suggesting that CRAM-MD5 update should have a new mechanism name [22:16:07] Kurt doesn't think CRAM-MD5 can be moved forward anymore [22:16:16] So he wants to move it to historic [22:16:18] Simon may also be right, in that an oauth sasl/gss mech should be done in oauth [22:16:49] jhildebrand: I would interested on why you need new GSS-API functionality. [22:17:10] I think you'll get significant pushback to oauth sasl/gss in oauth because oauth two-legged is currently out of scope and there was no objection to that at the bof [22:17:27] Kurt: publish "CRAM-MD5 to historic" at the same time as SCRAM [22:17:38] sasl mech OAUTH could be an individual submission [22:18:07] tlyu leaves the room [22:18:12] tlyu joins the room [22:18:18] Chris: against publishing Kurt's document before SCRAM is published [22:18:26] Kurt confirms that was the intent [22:19:09] Ken Raeburn leaves the room [22:19:15] Ken Raeburn joins the room [22:19:34] Sam: has weak preference for living CRAM-MD5 as Limited in the IANA, has strong preference against publishing SCRAM on Standards Track [22:19:44] Chris agrees with Sam [22:19:55] the semantics of COMMON, LIMITED USE and OBSOLETE are not defined anywhere [22:20:03] are the folks who want CRAM-MD5 on the Standards Track in the room? [22:20:48] thus, what's in the 'intended usage' field does not matter for anything [22:21:03] don't you think you should ask them? [22:22:07] many: IANA registry should reference both documents (Kurt's and RFC 2195) [22:22:37] tlyu: yes, that was the antecedent of "them" [22:22:54] I've seen strong comments about CRAM-MD5 on an apps area list [22:23:24] apps-discuss@ietf.org [22:23:25] what list is that? [22:23:25] semery: authentication where the IDP is in a different security domain than the resource. kerb doesn't really get me the deployment characteristics I need. there may be other GSSAPI mechanisms that already get me what I want. Where do I go to learn about those? Don't see an IANA registry. [22:24:09] hartmans: i'm willing to do the oauth stuff three-legged. The IDP takes the role of "user", and my client the role of "consumer". [22:24:16] IIRC John Klensing and others want CRAM-MD5 on the Standards-Track, but don't quote me on that; look at the apps-discuss list archive, search for Subject: Advancing CRAM-MD5 (was: Re: datatracker for 2821bis) [22:24:46] I'll take this to the list so that I stop distracting you guys. I apologize again. [22:24:51] I'd love to talk to you off-line about oauth. [22:25:05] hartmans: i'll find you [22:25:14] I do think it should be a gss mech not sasl, but I agree nothing today gives you the same characteristics as oauth [22:25:30] Pasi polled the room about people in favour of Kurt's proposal + the IANA update proposal [22:25:34] 5 people in favour [22:25:44] I am also in favor but had commented previously [22:25:47] klensin doesn't seem very interested: http://permalink.gmane.org/gmane.ietf.apps-discuss/1103 [22:25:58] MattJ joins the room [22:26:41] general rule (there are exceptions): if you are writing a mechanism, write a GSS-API mechanism. if you are writing an application, write a SASL application. Now, if we could just get GS2 out the door... [22:27:34] Simon Josefsson is discarding his binary gs2 implementation. sigh. [22:32:03] Chris: can we just move rfc 4422 to Draft without a revision [22:33:08] Kurt/Alexey: a typo in RFC 4422 - ACAP is a normative reference [22:33:30] Chris: downref to SASLPrep and GSS-API when moving to Draft [22:34:26] kdz leaves the room [22:34:26] the downref to saslprep is why i suggested dropping saslprep when moving rfc4422bis to draft. [22:34:59] draft standard requires at least two independent interoperable implementations. my gsasl supports saslprep, are there others? [22:35:10] Chris Newman leaves the room [22:38:58] Chris Newman joins the room [22:39:03] Simon Josefsson leaves the room [22:39:21] tlyu leaves the room [22:40:02] nico leaves the room [22:40:03] cyrus leaves the room [22:40:21] Chris Newman leaves the room [22:40:27] Chris Newman joins the room [22:42:54] David Cooper leaves the room [22:44:39] Ken Raeburn leaves the room [22:46:28] ludovic.poitou leaves the room [22:48:32] ietf-meeting leaves the room [22:52:01] jhildebrand leaves the room: Disconnected. [22:58:24] Chris Newman leaves the room [23:00:08] semery leaves the room [23:05:45] alexey.melnikov leaves the room [23:11:00] alexey.melnikov joins the room [23:11:31] prussell-nd leaves the room [23:12:02] rlbob leaves the room [23:12:36] alexey.melnikov leaves the room [23:31:32] stpeter leaves the room: Replaced by new connection [23:31:32] stpeter joins the room [23:48:25] Chris Newman joins the room [23:49:59] Chris Newman leaves the room