[10:19:57] --- psavola has joined
[10:35:15] --- sasl has joined
[11:01:55] --- Melinda has joined
[11:03:17] --- tlyu has joined
[11:03:37] --- cyrus_daboo has joined
[11:04:57] --- chris_newman has joined
[11:05:39] --- jeaton has joined
[11:05:44] --- rlbob has joined
[11:05:47] --- kmurchison has joined
[11:05:59] <rlbob> called to order at 9:05
[11:06:03] <rlbob> agenda bash
[11:06:18] <rlbob> kurt: doc status: we're behind
[11:06:26] <rlbob> hoping to close on base spec in next few weeks
[11:07:08] --- chris_newman has left: Logged out
[11:07:11] <rlbob> tom: less certain about direction on cram-md5
[11:07:21] --- chris_newman has joined
[11:07:34] <rlbob> anyone object to LC on GSSAPI doc?
[11:08:34] <rlbob> sam: can LC with the understanding that silence is not consent
[11:08:54] <rlbob> kurt: plain doc is with IESG, right?
[11:10:00] <rlbob> sam: waiting on kurt and i to talk ...
[11:10:15] <rlbob> kurt: plan is to wait for bsae to be done, then do plain
[11:11:02] <rlbob> kurt: digest-md5 is in progress
[11:11:23] <rlbob> kurt: so, overall, back on track and making some progress
[11:11:58] <rlbob> kurt: we'll talk about milestones at end of session
[11:12:17] <rlbob> tom: seemed to have consensus about taking cram off stds track
[11:12:19] --- dumdidum has joined
[11:12:27] <rlbob> more recent discussion is questioning that
[11:12:41] --- dumdidum has left
[11:12:46] <rlbob> people seem to be leaning toward informational rather than historic
[11:13:15] <rlbob> anyone want cram to remain on stds track? (a couple of hands)
[11:13:45] <rlbob> kurt: problem is that to be stds track we have to fix problems, not just publish current practice
[11:13:54] <rlbob> eg fix I18N, other problems
[11:14:50] <rlbob> kurt: overall sense of ietf seems to be that cram-md5 isn't recommendable for use due to sec problems
[11:15:04] <rlbob> simonj: what problems?
[11:15:17] <rlbob> kurt: doesn't offer protection
[11:15:39] <rlbob> simon: neither does plain, can we recommend it with mandatory TLS?
[11:15:43] <rlbob> kurt: could
[11:16:42] <rlbob> simon: it's in use, so should be some reason to remove it
[11:17:24] <rlbob> kurt: to be stds track, have to fix problems, which most likely means breaking compatibility, which is what people want
[11:17:50] <rlbob> chrisn: seems like informational is a reasonable compromise
[11:17:58] --- dumdidum has joined
[11:18:09] <cyrus_daboo> Is the scope of any proposed change to CRAM-MD5 such that it effectively requires vendors to reimplement it? i.e. in 'fixing' it are we really creating a new mechanism? If so, how many vendors really want to do that as opposed to using another mechanism that does not already have these problems.
[11:18:16] <rlbob> simon: can live with informational
[11:19:06] --- hartmans has joined
[11:19:21] --- tonyhansen has joined
[11:19:24] <rlbob> tom: anyone else really want std and not informational? (no one)
[11:19:46] <rlbob> kurt (responding to cyrus): fixing I18N would mean saslprep, which is a change
[11:20:57] <rlbob> kurt: as informational could encourage saslprep but not mandate
[11:20:57] --- alexeymelnikov has joined
[11:21:25] <rlbob> tony: should document why it's no longer stds track
[11:21:42] <rlbob> kurt: sure
[11:22:27] <rlbob> alexey on digest ...
[11:22:43] <rlbob> a: new version, two changes
[11:23:08] <rlbob> added text about channel binding
[11:23:27] <rlbob> removed one of two AES-CBC modes
[11:23:58] <rlbob> channel binding is backwards compatible ...
[11:24:34] <rlbob> new ABNF also, ref new ABNF RFC
[11:24:41] <rlbob> ABNF changes not finished
[11:25:01] <rlbob> ABNF extensions to be split into separate doc
[11:25:49] <rlbob> questions about counter mode
[11:26:27] <rlbob> sam: could use gcm instead of counter mode, some advantages, would be more complicated
[11:27:01] <rlbob> sam: personally support using counter mode
[11:27:43] <rlbob> kurt: anyone support using counter mode? (5 hands)
[11:28:06] <rlbob> alexey: some people ask: do we even care about security layer in digest?
[11:28:29] --- prkj has joined
[11:29:07] <rlbob> kurt: are people prepared to write text and review to make this change happen? (a hum or two)
[11:29:18] <rlbob> sam: i'll answer questions and review
[11:29:42] <rlbob> kurt: won't happen unless people contribute text
[11:30:28] <rlbob> simon: either do sec-layers right or not at all
[11:30:37] --- stephenfarr has joined
[11:31:04] --- stephenfarr has left
[11:31:17] <rlbob> kurt: oppose removing sec layers from digest-md5, since some protocols depend on it as MTI
[11:31:50] <rlbob> sam: agree with both kurt and simon, aes-cbc mode meets the need, though not in performant way
[11:32:08] <rlbob> not clear that high-performance is a requirement ...
[11:32:40] <rlbob> sam: wouldn't approve it without sec layer
[11:33:33] <rlbob> kurt: so seems like we need to proceed with sec layer in the doc
[11:34:01] <rlbob> kurt: can you find us someone to help us with counter mode, sam?
[11:34:07] <rlbob> sam: sure
[11:34:44] <rlbob> tom: people prepared to delay the doc to get this in?
[11:35:20] <rlbob> simon: note that RC4 is MTI encryption in spec, so why delay for change to non-MTI component?
[11:35:51] <rlbob> sam: simon, you propose not having RC4 be MTI, I agree with that
[11:36:53] <rlbob> kurt: will delay caused by this change be a problem for people?
[11:37:07] <rlbob> alexey: have other stuff to do too, shouldn't take that long
[11:37:56] <rlbob> simon: security already questionable due to use of MD5 ...
[11:38:26] <rlbob> kurt: alexey, you were saying this shouldn't cause much additional delay?
[11:38:30] <rlbob> a: yes
[11:39:02] <rlbob> kurt: delay consideration of MTI change until counter-mode text is done (if it is)
[11:40:15] <rlbob> alexey: effort in doc to be compatible with iso-8859-1 since http digest specs that
[11:40:47] <rlbob> on http list, people seem OK with permitting utf-8 with http digest, so maybe we can too
[11:42:09] <rlbob> kurt: regardless of http position, there is installed base of SASL digest-md5 using 8859, this would be compatibility problem
[11:42:46] <rlbob> alexey: if need to have chars outside of 8859-1, have to use utf-8 anyway
[11:43:01] <rlbob> kurt: do we know what implementations do about this?
[11:43:32] <rlbob> simon: can use utf-8 as an option, this change would be OK
[11:44:38] <rlbob> kurt: should we check with http community, or just do it? prefer just to do it
[11:45:02] <rlbob> kurt: definitely best in the long term
[11:45:23] <rlbob> tom: recommend researching it more with http community to ensure compatibility
[11:45:37] <rlbob> kurt: OK, will engage apps ADs on this
[11:46:01] <rlbob> sam: sure, nice to use same stringprep profile too ...
[11:46:10] <rlbob> kurt: hope they're going to use saslprep
[11:46:33] <rlbob> kurt: date for next rev, alexey?
[11:47:40] <rlbob> kurt: alexey says: before next IETF meeting ... kurt would like to see it sooner
[11:48:14] <rlbob> kurt: would like to do WGLC on this before next IETF meeting
[11:48:31] <rlbob> kurt: hence shoot for next rev by end of year
[11:49:19] <rlbob> kurt: 2222bis changes ...
[11:50:58] <rlbob> kurt: issue with Authentication Outcome in sec 3.6
[11:52:08] <rlbob> kurt: chris n suggests text with guidance on how to handle various kinds of errors
[11:52:19] <rlbob> (no complaints)
[11:52:42] <rlbob> kurt: empty server challenge requirement
[11:53:03] <rlbob> chrisn: this was added by John Myers in early 2222bis rev
[11:53:34] <rlbob> kurt: problem is digest-md5 can sometimes be client-first, sometimes server-first
[11:53:57] <rlbob> kurt: login also doesn't necessarily have empty challenge
[11:54:17] <rlbob> kurt: proposal just to delete text requiring challenge to be empty
[11:55:27] <rlbob> kurt: example shows how this req adds extra RT to digest-MD5 fast reauth
[11:56:35] <rlbob> also problem with non-standardized LOGIN mech, where req which break installed base
[11:56:59] <rlbob> kurt: so propose making the change, haven't seen objections so far
[11:57:17] <rlbob> (no one objects)
[11:58:34] <rlbob> kurt: issue: mech downgrade detection behavior: simon proposes SHOULD close connection
[11:58:40] <rlbob> (no objection)
[11:59:00] <rlbob> kurt: issue from pekka: sec considerations
[12:00:08] <rlbob> discussion of MITM attacks muddles several different attacks: downgrade, hijack, C/R modification
[12:00:34] <rlbob> kurt: propose splitting discussion as suggested
[12:02:53] <rlbob> will provide new proposed text this week
[12:03:08] <psavola> note: I discussed this with kurt yesterday. My biggest concern with security considerations was that it was not explicit enough in its assumptions of the security properties of lower layers (like IPsec, TLS, plaintext or whatever). The direction kurt suggested seemed good.
[12:03:09] <rlbob> kurt: any other changes requested on sec considerations?
[12:03:40] <rlbob> (no)
[12:03:57] <rlbob> kurt: IANA considerations
[12:04:48] <rlbob> kurt: simon thought RFC for family registration is too restrictive, some discussion
[12:06:25] <rlbob> kurt: intent was to make sure IANA knows how to handle registrations within family
[12:06:41] <rlbob> simon: why does IANA have to know?
[12:07:56] <rlbob> sam: in GSS you don't have to register mechs separately
[12:08:21] <rlbob> kurt: that's because OID reg ensures uniqueness
[12:09:01] <rlbob> sam: hope that new proposal for handling GSS won't require IANA reg
[12:10:24] <rlbob> kurt: some people would like refer to IANA registry to list all mechs, this was requested in similar LDAP-oriented registry
[12:10:29] <rlbob> sam: that's lame
[12:11:21] <rlbob> sam: if you require IESG approval, give IESG explicit instructions on how to judge
[12:11:53] <rlbob> sam: IANA policy should be set in RFCs
[12:13:13] <rlbob> kurt: question is whether family registration is delegation of namespace, simon is suggesting this, right?
[12:13:33] <rlbob> simon: yes
[12:14:11] <rlbob> kurt: so could permit family owner to list registered mechs with IANA if desired
[12:14:15] <rlbob> simon: sure
[12:14:26] <rlbob> kurt: any objections?
[12:14:43] <rlbob> (none)
[12:15:10] <rlbob> kurt: sam suggested a family for X-*, still want it?
[12:15:13] <rlbob> sam: nah
[12:15:39] <rlbob> sam: if I care I can just go register it ...
[12:16:31] <rlbob> kurt: will submit 2222bis-13 tomorrow, recommend WGLC on it
[12:17:47] <rlbob> kurt: milestone review
[12:18:18] <rlbob> 2222bis to IESG by December ...
[12:18:57] <rlbob> will use new "chair shepherding" process with it
[12:19:42] <rlbob> kurt: cram-md5 probably not last-callable until 2006-03 or so
[12:20:06] <rlbob> kurt: digest-md5 similarly
[12:20:16] <rlbob> alexey: might be even later
[12:20:51] <rlbob> kurt: GSSAPI mech?
[12:21:05] <rlbob> tom: need positive support before progressing it
[12:21:22] <rlbob> tom: so last-callable now with that caveat
[12:21:53] <rlbob> sam: stringprep advancing to Draft?
[12:22:18] <rlbob> kurt: needs revision to deal with Unicode issues ...
[12:23:29] <rlbob> kurt: implementation reports probably summer 2006
[12:24:38] <rlbob> kurt: open mike
[12:24:58] <rlbob> simon: does GSS include GSS family?
[12:25:07] <rlbob> sam: no, do you want to work on it?
[12:25:59] <rlbob> sam: discussion of a "GSS2" perhaps to make improvements, want to work on that?
[12:26:05] <rlbob> simon: sure ...
[12:26:30] <rlbob> simon: initial draft in Feb 2006
[12:27:36] <rlbob> simon: some discussion about BASE32 spec from dnsext, may be changing ...
[12:28:04] <rlbob> kurt: end-milestone for GSS family?
[12:28:40] <rlbob> simon: Sep 2006?
[12:28:43] <rlbob> kurt: OK
[12:30:07] <rlbob> mark crispin: want to make sure that non-requirement of empty challenge doesn't permit dumb PLAIN mech impls
[12:30:50] <rlbob> kurt: please propose text
[12:31:38] <rlbob> kurt: anything else?
[12:31:41] <cyrus_daboo> HTTP sasl as a topic?
[12:31:55] <cyrus_daboo> Oops - Sam beat me to it.
[12:32:02] <rlbob> sam: discussion about SASL for HTTP
[12:33:01] <rlbob> sam: most likely will be need to discuss channel bindings in that context, so be prepared
[12:33:48] <rlbob> kurt: sure, but let's not break compat, so via new mechs, or extensibility features of existing ones
[12:34:33] <rlbob> tom: any further discussion? if not, we're adjourned (at 10:34)
[12:35:00] --- dumdidum has left
[12:35:19] --- rlbob has left
[12:35:59] --- chris_newman has left: Logged out
[12:36:17] --- cyrus_daboo has left
[12:36:20] --- dumdidum has joined
[12:36:46] --- kmurchison has left
[12:37:59] --- Melinda has left
[12:39:17] --- hartmans has left
[12:39:51] --- jeaton has left
[12:43:24] --- alexeymelnikov has left
[12:43:43] --- sasl has left: Disconnected
[12:46:20] --- tlyu has left: Disconnected
[12:48:15] --- prkj has left
[13:04:40] --- alexeymelnikov has joined
[13:04:48] --- alexeymelnikov has left
[13:05:35] --- dumdidum has left: Disconnected
[13:07:36] --- psavola has left: Disconnected
[13:31:01] --- alexeymelnikov has joined
[13:39:02] --- alexeymelnikov has left: Disconnected
[15:02:25] --- alexeymelnikov has joined
[15:17:00] --- tonyhansen has left
[16:03:32] --- alexeymelnikov has left