[07:23:55] --- fanf has joined
[07:58:09] --- pguenther has joined
[08:31:50] --- kmurchison has joined
[09:07:00] --- wyllys has joined
[09:18:59] --- shima has joined
[09:21:17] --- pguenther has left
[09:21:25] --- shima has left
[09:21:28] --- shima has joined
[09:22:07] --- fanf has left: Disconnected
[09:22:21] --- tlyu has joined
[09:22:51] --- hartmans has joined
[09:26:11] --- jhutz has joined
[09:27:05] <wyllys> Does anyone know if Nico is going to be in this meeting?
[09:28:20] <jhutz> I thought so, but he might have decided to sleep instead
[09:29:40] <wyllys> ok, thanks.
[09:33:35] --- tlyu has left: Replaced by new connection
[09:33:38] --- tlyu has joined
[09:33:38] --- hartmans has left: Disconnected
[09:36:40] <jhutz> who here is not in the room?
[09:36:40] --- leifj has joined
[09:36:42] --- tonyhansen has joined
[09:36:52] --- Jeffrey Altman has joined
[09:36:56] <leifj> I am not here
[09:36:57] <jhutz> network in the meeting room seems flaky, at least for people using b/g
[09:37:05] <Jeffrey Altman> scribing
[09:37:06] --- rlbob has joined
[09:37:12] <jhutz> I'm using a, and it's fine.
[09:37:14] <Jeffrey Altman> agenda bashing
[09:37:18] <jhutz> Anyone want to bash the agenda?
[09:37:25] <leifj> don't scribe on my account jeff - I have good audio
[09:37:39] <jhutz> we need it for notetaking anyway
[09:37:43] <Jeffrey Altman> docstat: anonymous - current draft anon-05 has not received much review
[09:37:52] <Jeffrey Altman> 3 or 4 reviewers in the room
[09:38:01] <jhutz> How many have read draft-ietf-sasl-anon?
[09:38:31] <Jeffrey Altman> it is in the rfc-editor queue according to the tracker
[09:38:48] <Jeffrey Altman> docstat crammd5 -05 some people what to issue it as historic
[09:38:54] <Jeffrey Altman> Sam proposed the idea
[09:39:03] <jhutz> "some people" is sam
[09:39:41] <jhutz> hartmans: I think we've always known we needed a strong applicability statement for CRAM
[09:40:00] <jhutz> hartmans: question is, should this be standards track; I think the answer is "no".
[09:40:09] <jhutz> hartmans: So, is it informational or historic?
[09:40:30] <jhutz> hartmans: historic: limited applicability; don't use any more
[09:41:18] <Jeffrey Altman> hartmans: informational would just be publication to document it without a recommendation for use
[09:42:19] <Jeffrey Altman> kurt: (chair hat off) focus on the applicability statement instead of trying to revise the protocol
[09:42:31] <jhutz> hartmans: would like to encourage the group to not publish on standards track
[09:43:20] <Jeffrey Altman> tony hansen: publishing as historic seems reasonable
[09:43:44] <Jeffrey Altman> tom yu: is there an applicability statement in the document?
[09:43:56] <jhutz> hartmans: you will by the time you publish
[09:43:56] <Jeffrey Altman> hartmans: there will be one by the time you publish!
[09:44:26] --- shima has left
[09:44:57] <Jeffrey Altman> tom yu: if it will be published as historic, we still need to refine the description of the protocol
[09:45:57] <Jeffrey Altman> simon josefsson: users of cram-md5 need an updated document for the internationalization support. perhaps should be informational.
[09:46:07] --- hartmans has joined
[09:46:26] --- nico has joined
[09:46:33] --- raeburn has joined
[09:46:42] <Jeffrey Altman> tony: documenting it as having saslprep would be documenting currently recommended behavior
[09:46:45] <nico> wyllys: present
[09:47:50] <jhutz> kurt: anyone have serious objections removing this from standards track and going to historic?
[09:48:38] --- fanf has joined
[09:48:42] --- ludomp has joined
[09:48:49] --- shima has joined
[09:49:01] <jhutz> jaltman: having done work with telnet moving things from historic, publishing as historic means "this is how it is; please don't use it again", whereas informational means "we don't think this is worthy of spending time to review and put on standards track", but does not say it's something that you shouldn't use it.
[09:49:12] <jhutz> jaltman: if the group wants this not to be used, then it should be historic
[09:49:34] <jhutz> jaltman: if you just want to limit to a narrow set of uses, informational
[09:49:42] <jhutz> kurt: humm on making it historic?
[09:49:47] <jhutz> kurt: informational?
[09:50:07] <jhutz> (some hums on historic; none on info)
[09:50:46] <jhutz> hartmans: I don't think publishing as historic and adding i18n is compatible
[09:50:57] <jhutz> <someone>: you could publish as info, then go to historic immediately
[09:51:01] <jhutz> hartmans: comment withdrawn
[09:51:01] <Jeffrey Altman> hartmans: comment withdrawn
[09:51:58] <jhutz> moving on while sam checks something...
[09:52:05] <jhutz> next item: sasl-gssapi
[09:52:21] <Jeffrey Altman> docstat: gssapi -02: no action in the last six months
[09:52:52] --- nico has left: Disconnected
[09:53:10] <Jeffrey Altman> alexey: -01 expired. -02 published in march with a minor change. I'm currently focusing on base spec
[09:53:54] <Jeffrey Altman> kurt: the WGs priority is the base doc
[09:54:07] <Jeffrey Altman> jhutz: what is not finished with the gss doc?
[09:54:15] <Jeffrey Altman> alexey: it needs review
[09:54:37] <Jeffrey Altman> hartmans: it has more round trips. implementors would be unhappy
[09:54:56] <Jeffrey Altman> hartmans: for kerberos implementation the current spec is good
[09:56:13] <Jeffrey Altman> alexey: maybe I should remove the references to the entire gss family
[09:56:22] --- shima has left
[09:57:15] <Jeffrey Altman> jhutz: it supports names for all mechanisms of the gss family. the gss krb5 and gss spnego are treated specially to optimize the negotiation
[09:58:03] <Jeffrey Altman> hartmans: one optimization is to piggyback authz, ... on the last token
[09:58:20] --- hartmans has left: Disconnected
[09:58:50] --- tlyu has left: Disconnected
[09:58:52] <Jeffrey Altman> jhutz: it seems premature to optimize round trips for mechanisms that are not widely deployed
[09:58:56] --- tonyhansen has left: Disconnected
[09:59:27] <Jeffrey Altman> hartmans: people get really upset when there are extra round trips. protocol designers will complain if there are extra round trips
[09:59:59] <Jeffrey Altman> Joe Salowey: optimizations to gss in Kitten might help things. It might be premature to do so now.
[10:01:08] <Jeffrey Altman> jhutz: if we want to optimize non-krb5 gss mechs in the future, we should remove the others from the document and only publish the krb5 gss mech in this spec
[10:01:37] <Jeffrey Altman> kurt: query: humm to determine if optimization is important. The consensus is "YES".
[10:02:17] <Jeffrey Altman> kurt: split the document into gss krb5 and spnego in one document and then place the other family members into a second document
[10:02:27] <Jeffrey Altman> no objections to this idea in the room
[10:02:40] <Jeffrey Altman> kurt: coordination will take place with Kitten.
[10:03:02] --- ludomp has left: Disconnected
[10:03:05] <Jeffrey Altman> docstat: saslplain -08: sent to iesg and sent back.
[10:03:46] <Jeffrey Altman> hartmans: chair and AD must meet to discuss to solve a disagreement but this is being deferred until after base.
[10:04:28] <Jeffrey Altman> kurt: will review the comments in the data tracker and discuss with the AD and will send a note to the list.
[10:05:06] <Jeffrey Altman> docstat: rfc2222bis-11 (base) WGLC issued. Many comments, mostly editorial.
[10:05:29] <Jeffrey Altman> tom: mostly related to use of saslprep
[10:05:45] <Jeffrey Altman> kurt: good amount of outside review. thanks to the reviewers
[10:07:09] <Jeffrey Altman> kurt: clear from the review that there is still confusion. clarity issues. some text has been proposed on the list to resolve some of the problems. still minor issues. believe this can be refined on the text. especially need new suggestions on how to improve the clarity.
[10:07:21] <Jeffrey Altman> kurt: need to make the wording as precise as possible.
[10:09:08] <Jeffrey Altman> jhutz: people who read the text get really confused when reading the document between authentication IDs and authz IDs. In particular, where does the responsibility lie between mechanism implementation and application implementation.
[10:09:19] --- fanf has left: Disconnected
[10:09:19] <Jeffrey Altman> kurt: do you have suggestions?
[10:09:25] <Jeffrey Altman> jhutz: I wish I did
[10:10:53] <Jeffrey Altman> jhutz: should provide text describing the history. that would make things clearer.
[10:13:00] <Jeffrey Altman> kurt: need to be careful that the clarification text does not cause changes to the intended meaning. some of the proposed changes have accidently altered the meaning.
[10:13:18] <Jeffrey Altman> kurt: normalization of identities is a sticky subject
[10:14:30] <Jeffrey Altman> tom: we need to get this reviewed by fresh eyes. people without prior sasl experience appear to be the ones that most lost.
[10:14:57] --- shima has joined
[10:15:29] <Jeffrey Altman> in a show of hands, 30% of those who have read it consider it confusing.
[10:15:40] <Jeffrey Altman> docstat: digest-md5
[10:16:01] <Jeffrey Altman> alexey: sent message to list with recent changes and a bunch of questions.
[10:16:29] <Jeffrey Altman> alexey: explained how/where saslprep was used. no comments have been received
[10:16:53] <Jeffrey Altman> tom: do you think there will be similar forms of confusion as in the base spec?
[10:17:13] <Jeffrey Altman> alexey: yes. it took me three times writing it before it made sense to me
[10:18:00] <Jeffrey Altman> jhutz: we may need boilerplate text that goes into mechanism documents that explain some basic concepts
[10:18:23] --- shima has left
[10:18:24] --- shima has joined
[10:18:42] <Jeffrey Altman> jhutz: it will reduce confusion for reviewers
[10:19:10] <Jeffrey Altman> tom: seems redundant jhutz: seems needed
[10:19:36] <Jeffrey Altman> kurt: there is an outstanding question as to whether to use CBC or counter modes
[10:20:19] --- nico has joined
[10:20:31] <Jeffrey Altman> alexey: sam, tom, kurt and I had lunch to discuss. sam suggested the use of counter mode. I need help from reviewers to help explain to implementers how to implement counter mode.
[10:21:04] <Jeffrey Altman> kurt: it would be good if there was consensus in the room for the use of counter mode.
[10:21:38] <Jeffrey Altman> tom: in the current doc, there is use of CBC mode for AES but no description of counter mode.
[10:21:54] <Jeffrey Altman> tom: how many people are familiar with counter mode?
[10:22:03] <Jeffrey Altman> tom: about ten
[10:22:09] <nico> me too
[10:22:16] <nico> I'm out of the room for a sec
[10:22:35] <Jeffrey Altman> tom: how many people are familiar with the two proposals?
[10:23:32] <Jeffrey Altman> tom: any objections to discarding proposal #2? none
[10:24:15] <Jeffrey Altman> simon: can we consider an AES mode that provides integrity protection?
[10:24:44] <Jeffrey Altman> tom: ccm mode relatively new. I am not aware of any security proofs
[10:25:03] <Jeffrey Altman> simon: there is an old proof, but I am not wed to ccm mode.
[10:25:34] <Jeffrey Altman> nico: if counter mode, you might want to wait a bit. should leave a slot for channel bindings.
[10:26:05] <Jeffrey Altman> nico: gcm is better than ccm
[10:26:22] <Jeffrey Altman> hartmans: please identify ipr restrictions on the various modes
[10:27:05] <Jeffrey Altman> jhutz: its not clear if the people in the room have the relevent knowledge
[10:27:29] <Jeffrey Altman> nico: gcm authors claim there are no ipr issues.
[10:27:34] <Jeffrey Altman> hartmans: please check carefully
[10:27:58] <Jeffrey Altman> tom: how many would like the wg to consider a combined encrypt-integrity mode?
[10:28:37] <Jeffrey Altman> no consensus
[10:28:40] --- fanf has joined
[10:29:20] --- fanf has left: Disconnected
[10:30:46] <Jeffrey Altman> <discussion on the responsibilities of wg members and chairs with regard to hunting for ipr issues>
[10:31:11] <Jeffrey Altman> hartmans: recommend that a combined mode be specified in a separate draft
[10:32:07] <Jeffrey Altman> hartmans: be see RFC 3961; CMS of S/MIME wg; and ESP packet format
[10:32:22] <Jeffrey Altman> hartmans: we do not need another ietf cipher layer
[10:32:34] <Jeffrey Altman> s/be/please
[10:32:44] --- nico has left: Disconnected
[10:36:07] <Jeffrey Altman> Philip: digest-md5 is not significantly better than cram-md5; must be used over TLS. hartmans: nico, please explain why channel binding would be useful here nico: run TLS with anonymous-DH and throw the finished messages into the Digest-MD5 challenge-response. You have now defeated the MITM
[10:37:35] <Jeffrey Altman> hartmans: SASL is kind of broken because it does not support channel bindings. But the working group is not chartered to extend SASL in this way. We don't have people to do the work. The native layer for digest-md5 must be strong until such time we are able to get to digest-md5 over TLS with binding.
[10:38:14] <Jeffrey Altman> nico: what ways does the charter allow digest-md5 modifications?
[10:39:13] --- nico has joined
[10:40:12] --- wyllys has left: Logged out
[10:41:57] <Jeffrey Altman> jaltman: discussion of the charter to see if it contains flexibility to allow the specification of channel bindings
[10:42:30] <Jeffrey Altman> kurt: wants to limit scope of the work to the minimum necessary to go to the IESG
[10:43:03] --- nico has left: Disconnected
[10:43:23] <Jeffrey Altman> hartmans: things to keep in mind: * DIGEST-MD5 vs DIGEST-SH1 * can this work be done as an independent extension * will the application community use it if it si not secure enough
[10:43:56] <Jeffrey Altman> if digest is delayed, more people will use plain
[10:44:18] <Jeffrey Altman> kurt: what work do we want to do?
[10:45:57] <Jeffrey Altman> Philip: DIGEST-MD5 by itself is only marginally better than CRAM-MD5 and if CRAM-MD5 is going to historic, then we really need to say that it should only be used if the attacks can be mitigated by using it over TLS with channel bindings; or we should kill it?
[10:46:41] <Jeffrey Altman> hartmans: does anyone have an opinion if DIGEST-MD5 has adequate security?
[10:47:03] <Jeffrey Altman> Kurt: its the best we have other than running it over TLS
[10:48:41] <Jeffrey Altman> Simon: DIGEST-MD5 seems to be adhoc and CRAM-MD5 is not; DIGEST-MD5 has not theorectical security proof.
[10:49:24] <Jeffrey Altman> hartmans: Simon is right. There is no proof, but in practice DIGEST-MD5 seems to me to what we want even if it does not use HMAC.
[10:50:18] <Jeffrey Altman> Simon: why? hartmans: I can't prove it but I think I understand it well enough to believe that DIGEST-MD5 is similar to HMAC in quality
[10:51:32] <Jeffrey Altman> Roger Harrison: LDAP community has worked to have a strong mandatory to implement security mechanism. It would be very bad if the mandatory to implement protocol is not secure
[10:51:49] <Jeffrey Altman> tom: I am not hearing consensus from the community
[10:51:57] <Jeffrey Altman> security community
[10:52:42] <Jeffrey Altman> Roger: there is uncertaintity as to whether or not the algorithms are secure given what we have discovered over the last year.
[10:53:02] <Jeffrey Altman> hartmans: the challenge-response issues are different than the hash issues.
[10:53:19] <jhutz> kurt: discussion on apparea...
[10:53:53] <jhutz> ... at apparea on challenge/response mechs in app protocols
[10:54:01] <jhutz> ... time to deprecate challenge/response protocols sent in the clear
[10:54:22] <jhutz> jaltman: over time, yes, we'll have a problem. The question is, do we have a problem now or 10 years from now?
[10:54:34] <jhutz> jaltman: If you think XXX's numbers are right, we have a problem now.
[10:55:02] <jhutz> kurt: or you can take the perspective that our protocol will be deployed for 20-30 years
[10:55:11] <jhutz> jaltman: yes, and then you do as much as you can
[10:55:32] <jhutz> tlyu: we're running short on time; I'd like to come away from this with definite directions
[10:55:45] <jhutz> hartmans: maybe we can get back to the cipher mode discussion
[10:55:58] <jhutz> tlyu: I believe we have consensus to drop the mode without an IV in every packet
[10:56:05] --- rlbob has left
[10:56:16] <jhutz> tlyu: question is do we want to consider counter mode, or only cbc mode as described.
[10:56:37] <jhutz> kurt: I think we need to consider CTR. Right now it's not a specific proposal; I think it would be good
[10:56:50] <jhutz> kurt: to add a specific proposal into the document, so we can consider it
[10:57:11] <jhutz> tlyu: objections to considering text about "proposal 1" CBC plus a separate CTR proposal
[10:57:29] <jhutz> kurt: simon's question - can we consider another alternative - yes, if we have specific text
[10:57:47] <jhutz> kurt: if you want us to consider something, write the text and send to the list
[10:58:08] <jhutz> ("another alternative" meaning some combined enc/integrity mode)
[10:58:27] <jhutz> simon: consider in a separate document
[10:59:07] <jhutz> simon(?): as I understand, you need 128 bits of randomness per packet for cbc
[10:59:17] <jhutz> hartmans: no, pseudo-randomness. it's not worse than other modes
[10:59:27] <jhutz> kurt: we need to cut this off, and talk about milestones
[10:59:46] <jhutz> kurt: already agreed to rework cram-md5; need a date, at least 3mo from now
[11:00:00] <jhutz> kurt: SASL to IESG - hoping we can do this by end of this month
[11:00:11] <jhutz> kurt: digest-md5 looks like it needs more review/work/discussion
[11:00:22] <jhutz> kurt: we need to refine this deliverable
[11:00:38] <jhutz> kurt: applies somewhat to cram-md5, too
[11:01:11] <jhutz> kurt: gssapi needs to be split
[11:01:13] <leifj> thx
[11:01:25] --- raeburn has left: Lost connection
[11:01:39] <jhutz> alexey: 2, maybe 3 months
[11:01:44] <jhutz> tlyu: october for GSSAPI
[11:01:55] <jhutz> kurt: implementation report - push back 6 months
[11:02:19] <jhutz> kurt: we have some revised milestone ideas here; we'll post to the list
[11:03:40] --- leifj has left
[11:04:15] --- shima has left
[11:04:15] --- shima has joined
[11:04:34] --- kmurchison has left
[11:10:45] --- Jeffrey Altman has left: Disconnected
[11:11:50] --- fanf has joined
[11:14:46] --- raeburn has joined
[11:17:42] --- Jeffrey Altman has joined
[11:19:19] --- Jeffrey Altman has left
[11:31:17] --- raeburn has left
[11:37:10] --- tlyu has joined
[11:37:18] --- shima has left
[11:39:49] --- jhutz has left
[11:55:01] --- nico has joined
[11:55:09] --- nico has left
[12:32:57] --- fanf has left: Disconnected
[12:52:35] --- tlyu has left: Logged out