[11:46:08] --- Simon Josefsson has joined
[15:03:33] --- kdz has joined
[15:04:04] --- kdz has left
[15:48:08] --- Lyndon Nerenberg has joined
[15:54:14] --- robertml has joined
[15:54:25] --- robertml has left
[15:54:57] --- Robert Martin-Legene has joined
[16:10:37] <Robert Martin-Legene> Audio stream is on channel 8, right?
[16:10:46] <Lyndon Nerenberg> Yes
[16:11:01] <Simon Josefsson> At least according to http://videolab.uoregon.edu/events/ietf/
[16:11:03] <Robert Martin-Legene> OK, just thought I heard someone mentioning IDNs.
[16:11:13] <Robert Martin-Legene> a few minutes back.
[16:11:22] <Lyndon Nerenberg> THe old bunch are still vacating ...
[16:11:31] <Robert Martin-Legene> ah :-)
[16:17:05] <Lyndon Nerenberg> Simon, are you in the neeting room?
[16:17:10] <Lyndon Nerenberg> s/neeting/meeting/
[16:17:32] <Simon Josefsson> No, i'm remote. Listening to the audio
[16:17:33] --- robsiemb has joined
[16:17:47] <robsiemb> hello all
[16:17:50] <robsiemb> we're about to begin
[16:17:50] <Lyndon Nerenberg> Okay. I'm just wondering if we're going to start any time soon.
[16:17:58] <Lyndon Nerenberg> That answers that!
[16:18:00] <Robert Martin-Legene> I'm have audio too.
[16:18:01] <Simon Josefsson> saag was late
[16:18:09] <robsiemb> Kurt is showing off a crazy dependency graph of the sasl base specification
[16:18:16] --- jimsch1 has joined
[16:18:19] <robsiemb> 34 documents were waiting for the base sepc
[16:18:25] --- kmurchison has joined
[16:18:43] --- cnewman@jabber.org has joined
[16:19:09] <robsiemb> "this whole mess is ldap"
[16:19:29] <robsiemb> The big point: RFC2222 is approved and will be in the rfc-ed queue soon
[16:19:34] <robsiemb> er, RFC2222bis
[16:19:46] <robsiemb> Agenda bash
[16:19:54] <robsiemb> Can you guys hear kurt?
[16:20:03] <Simon Josefsson> What's audio quality for you? It sounds as if one mic is close a laptop fan or something...
[16:20:04] <Robert Martin-Legene> Depends who Kurt is.
[16:20:17] <robsiemb> Kurt is speaking about the agenda now
[16:20:18] <Robert Martin-Legene> Much better.
[16:20:22] <Lyndon Nerenberg> :-)
[16:20:25] <Robert Martin-Legene> Thanks.
[16:20:25] <Simon Josefsson> Much better...
[16:20:28] <robsiemb> No changes. Jeff things the agenda sucks
[16:20:37] <robsiemb> Document status
[16:20:50] <robsiemb> base spec approved, plain is in iesg eval, the rest we're working on
[16:21:11] <robsiemb> simon sent some notes, which tom/kurt are trying to read
[16:21:19] --- hartmans has joined
[16:21:22] <robsiemb> Simon's open issues
[16:21:37] <robsiemb> IAB concern about excessive layering (kurt hasn't seen a writeup)
[16:21:53] <robsiemb> Slide: draft-iab-auth-mech 1/2
[16:22:10] <Simon Josefsson> There's no writeup.. I just happened to read rescorla's draft and discussed it with him briefly.
[16:22:24] <robsiemb> draft-iab-auth-mech-05
[16:22:30] <Simon Josefsson> I think there is some merit to his point
[16:22:39] <Simon Josefsson> We should at least be aware of it
[16:23:00] <robsiemb> Jeff: This is very interesting becaue the text on the screen promotes a position with which which I diametircly disagree
[16:23:22] <robsiemb> (this is section 11.3 of the draft, jeff is reading it)
[16:24:14] <robsiemb> Jeff: Our answer in the kerberos world is "use gss directly unless you have a good reason otherwise -- too many things think they have a good reason"
[16:24:37] <robsiemb> Sam: I think I disagree with this slide
[16:24:44] <robsiemb> Without hats
[16:25:21] <robsiemb> Sam: Speaking as an AD, this is completely horrible (but unmiced)
[16:25:54] <robsiemb> Jeff: this helps us from the point of modularity
[16:26:35] <robsiemb> Jeff: I do belive that multi-level negotitation is a problem, which is why there was text in the security considerations of the v1 GSSAPI draft about SPNEGO (sp?)
[16:26:52] <robsiemb> Jeff: we will talk to the authors of this
[16:27:13] <cnewman@jabber.org> Simon: any other comments?
[16:27:21] <Simon Josefsson> I'm fine with this discussion, no comments from me.
[16:27:26] --- dumdidum has joined
[16:27:31] <Simon Josefsson> Although there is a question on the next slide.
[16:27:52] <robsiemb> slide: draft-iab-auth-mech 2/2
[16:28:07] <robsiemb> "Does anyone have concrete plans to use non-krb5 mechanism?
[16:28:19] <robsiemb> - worried about absent review from non-krb5 communities
[16:28:39] <robsiemb> Sam: we have plans, but no particular implementation timelines
[16:28:56] <Simon Josefsson> This is related to the IAB comment -- we're designing things mostly for krb5 in mind. What if GS2 doesn't work with any generic GSS-API mechanism?
[16:28:58] <robsiemb> david black: I'm about to say something likely out of scope
[16:29:37] <robsiemb> david: once upon a time, iscsi specificed some native kerberos, and it might be better for the cleanup to bring in sasl insteade
[16:30:02] --- gdweber has joined
[16:30:14] <Simon Josefsson> If GS2 doesn't work well with any mechanism, we'll have GS3, which is an interop mess.
[16:30:16] <robsiemb> sam: that would be entirely neat and clever for you, but the concern is if we could make it work with btns. Theoretically that's a great solution, but not for this WG
[16:30:55] <robsiemb> chris newman: with my implementor hat on, I have tentative plans for krb5, and plans for other mechs are many years away if ever
[16:31:34] --- tonyhansen has joined
[16:31:39] <robsiemb> Chris: if we go with this, then we're going down a path that has the SASL implementations needing to know how to map the GSS oid to a friendly name at the sasl name, I like this at a protocol level, so there is some value to that...
[16:31:44] <robsiemb> chris: but I don't have strong feelings
[16:32:33] <Simon Josefsson> Could someone relay this? My worry with absence of review is that GS2-* may not work with any GSS-API mechanism.
[16:32:54] <robsiemb> one sec
[16:32:58] --- Jeffrey Altman has joined
[16:33:34] <Simon Josefsson> So if GS2-* doesn't work with GSS-API mechanism X, we'll have to revise GS2 into GS3. Which brings up the interop problem between krb5 under GS2 and GS3
[16:33:49] <robsiemb> sam: we can get a review from the gssapi community
[16:34:08] --- jhutz has joined
[16:34:23] <robsiemb> kurt: for full standard I'd like to see multiple mechanisms
[16:34:25] --- rlbob has joined
[16:34:25] <Simon Josefsson> thanks, rob!
[16:34:34] <robsiemb> do you need me to repeat that second bit?
[16:34:58] <robsiemb> kurt: I think rough consensus is that we should continue down the path we are on
[16:35:03] <robsiemb> kurt: any objection?
[16:35:07] <Simon Josefsson> no, i'm happy with the discussion
[16:35:12] <robsiemb> kurt: the path we are on is a family of GS2-* mechanisms
[16:35:35] <Jeffrey Altman> A family of mechanisms is my preference
[16:35:44] <robsiemb> With an opaque base32 hex name in the OID
[16:35:50] <robsiemb> chirs: I have an asthetic dislike but not an objection
[16:35:59] <Simon Josefsson> If we can get review from GSS people, that would really help, I think.
[16:36:51] <robsiemb> david: I still like the idea of using this to clean up iscsi, both of his suggestions pull in SKIM, and as long as that happens sasl is more interesting to me
[16:37:01] <robsiemb> next slide
[16:37:08] <robsiemb> channel binding 1/2
[16:37:10] --- raeburn has joined
[16:37:39] <robsiemb> (kurt reading slide)
[16:38:19] <Simon Josefsson> I raised this on the list, but no response.
[16:38:30] <Simon Josefsson> I'm hoping someone has useful input on it... ;)
[16:38:34] <robsiemb> tom summarizes
[16:38:45] <robsiemb> (the room is stunned by the sheer bulk of text on the slide)
[16:39:15] <Simon Josefsson> if the WG has understood the choice, perhaps a hum would be useful
[16:39:27] <Simon Josefsson> or if this is too technical, simply move it to mailing list
[16:40:03] <robsiemb> jeff: a few of these bullets talk about what the app does with the GSSAPI level channel bindings, to which the answer is "a sasl application knows nothing about it, so it does nothing"
[16:40:17] <robsiemb> jeff: gssapi channel bindings have a "brokenness"
[16:40:20] --- kdz has joined
[16:40:30] <robsiemb> jeff: an initiator app sets some fields to approx. whatever he wants
[16:40:40] <robsiemb> jeff: an acceptor sets some fields ot approx whatever he wants
[16:40:59] <robsiemb> jeff: if they set it to the same thing, then context establiushement succeeds. If they don't, it fails. There is no optionality here
[16:41:11] <robsiemb> jeff: no oppurtunity to examine what the client sent on the server side
[16:41:29] <robsiemb> jeff: Unless you want sasl to have those semantics, you can't do this with sasl...
[16:41:41] <robsiemb> sam: 2 choices: we want the gssapi semantics for sasl
[16:41:52] <jhutz> (Sam steals my lettering scheme)
[16:42:11] <robsiemb> sam: other choice is for different semantics, so we don't use GSSAPI channel bindings
[16:42:28] <jhutz> Choice Ä: We do want GSSAPI semantics for SASL channel bindings
[16:42:31] <robsiemb> chris: if I understand correctly, sam suggests that option 3 is the right choice
[16:42:56] <jhutz> Choice Á: We do not want GSSAPI semantics for SASL channel bindings
[16:43:23] <robsiemb> your 8bit fu is beyond me jeff
[16:43:38] <jhutz> (In a discussion some time back on the Kerberos WG list, I numbered possible choices as A, Å, and Ä
[16:43:40] <robsiemb> chairs: running out of time
[16:43:51] <Simon Josefsson> rob, could you relay this? the application is responsible for negotiating tls, so it will have to be responsible for telling the sasl library about the channel binding
[16:43:52] <robsiemb> chris: I think that option 3 is the right choice
[16:43:56] <Jeffrey Altman> what is option 3?
[16:44:13] <Jeffrey Altman> only 2 options went to jabber
[16:44:43] <robsiemb> option 3 is "a with dots"
[16:44:53] <Lyndon Nerenberg> 3. Same as 2 but the "chan_binding" field MUST be NULL. In other words, for GS2 interop we disallow the GSS­API cb completely, and only support a GS2 cb.
[16:44:55] <jhutz> Options 1,2,3,4,<bullet>4 were in the slide
[16:45:04] <jhutz> Options Ä and Á were Sam's choices.
[16:45:07] <robsiemb> chairs: we should take this to the list
[16:45:28] <jhutz> If we accept Sam's option Ä, then we want Simon's choice 3
[16:45:29] <robsiemb> other comments on GS2?
[16:45:41] <robsiemb> Slide: digeest-md5 open issues
[16:45:54] <Jeffrey Altman> I am leaning towards 3
[16:45:54] <robsiemb> alexey: did -08 revision, slide has open issues
[16:46:03] <robsiemb> IANA registry for channel bindings?
[16:46:12] <jhutz> Simon, the application will have to tell SASL about channel bindings. But that should be a SASL-abstract concept, not one specific to the GSSAPI-based mechanims.
[16:47:23] <robsiemb> HTTP Digest vs DIGEST-MD5 reauth nonce differences
[16:47:44] <robsiemb> DIGEST-MD5 says the client and server nonces are both the same on reauth. Are there security implications/
[16:48:17] <robsiemb> AES in counter mode has implicit initial counter (like SSH) is this ok?
[16:48:36] <robsiemb> sam: what do you mean implicit initial counter?
[16:48:40] <Simon Josefsson> jhutz: That's only possible if we define generic channel bindings for "SASL over TLS". The ideas I've seen so far was to define channel bindings for "GSS-API over TLS"
[16:48:42] <robsiemb> [someone]: what do you mean in every block?
[16:48:53] <robsiemb> someone == jim
[16:49:19] <robsiemb> sam: clarifies that this protocol always has blocks even if the cipher doesn't
[16:49:32] <robsiemb> alexey: we need to discuss on the mailing list
[16:49:42] <robsiemb> alexey: everyone looks confused
[16:49:51] <robsiemb> kurt: finish the slide, then we'll get all the comments
[16:50:00] <Simon Josefsson> jhutz: as in http://www.ietf.org/internet-drafts/draft-ietf-kitten-gssapi-channel-bindings-01.txt
[16:50:11] <robsiemb> alexey: does timing attack still apply to aes in counter mode?
[16:50:24] <robsiemb> alexey: which cipher is mandatory to implement? Simon has concerns about RC4.
[16:50:30] --- kdz has left
[16:50:44] <robsiemb> alexey: I don't want to change the deployed/interoperable RC4 to undeployed AES
[16:51:15] <jhutz> Well, since SASL is supposed to hide mechanism details from apps, we need to define channel bindings for TLS at the SASL layer. Otherwise, how do people use, say, digest-MD5 over TLS?
[16:51:30] <robsiemb> alexey: last issue, we have this downconversion hack to ISO-8859-1, should we drop in favor of UTF-8, this has been suggested for http digest.
[16:51:52] <robsiemb> kurt: do implementations ever do this?
[16:51:57] <Simon Josefsson> jhutz: DIGEST-MD5 could define channel bindings for TLS separately. I would agree that this is a mess.
[16:52:00] <robsiemb> alexey: cyrus sasl does, but it may not be an actual issue in practice
[16:52:28] <jhutz> Once we've defined SASL-over-TLS bindings, then the GS2-* mechanisms can map from the SASL bindings to the GSS bindings, or they can set the GSS bindings to null and use a wrap token like we do today.
[16:52:29] <Simon Josefsson> re alexey's question: my implementation is utf-8 only. the iso8859-1 stuff i do is because of the specification, but i'd rather drop it
[16:52:54] <robsiemb> Love: Yes, people do this, and yes it is painful.
[16:53:05] --- kdz has joined
[16:53:18] <jhutz> ... depending on whether we choose Ä or Á
[16:53:22] <robsiemb> alexey: my gut tells me we can do this, but I'm not 100% sure.
[16:54:30] <robsiemb> kurt: we are doing this to maintain continuity... but we're going to break things with saslprep anyway, so maybe we can break this too
[16:55:12] <robsiemb> jeff: why are we doing this mechanism? (that bears directly on the answer to this question)
[16:55:36] <robsiemb> jeff: if defining new practice, we should define new practice, if we're documenting existing practice, we should do that.
[16:55:44] <Simon Josefsson> jhutz: That sounds like a good idea. Maybe someone should start working on such a document.
[16:55:50] <robsiemb> sam: as an AD, we want simple/secure/cheap/soon
[16:56:11] <robsiemb> sam: we need a shared key mechanism that we can point people at
[16:56:24] <robsiemb> sam: it is important to share credentials with http-authentication and evolves with it
[16:56:35] <robsiemb> kurt: let's not open the mic to why we are focusing on this yet
[16:56:41] <robsiemb> kurt: let's answer the AES questions
[16:57:01] <robsiemb> kurt: alexey, so you have questions about your approach with aes counter mode?
[16:57:12] <robsiemb> alexey: someone should review the text based on my basic direction
[16:57:17] <robsiemb> kurt: who will review?
[16:57:28] <robsiemb> [silence]
[16:58:03] <robsiemb> jeff: not necessaraly a bad sign, maybe the right people just aren't in this room
[16:58:19] <robsiemb> kurt: will work with AD to find someone to do this
[16:58:46] <robsiemb> chirs: I am not qualified to review this, if we can't get review by someone who we are comfortable with we should remove the security layer
[16:58:54] --- gdweber has left
[16:58:59] <robsiemb> sam: ...and then not publish as standards track
[16:59:26] <robsiemb> slide: digest-md5 todo
[16:59:33] <Simon Josefsson> digest-md5 over tls WITHOUT security layers: cheap, secure, soon
[17:00:20] <robsiemb> david: we shouldn't do the downconversion with saslprep
[17:00:58] <robsiemb> chris: 8859 downconversion has sample code in base spec that is correct to the best of our knowledge
[17:01:09] <robsiemb> chris: it is ugly, not complicated
[17:01:14] --- gdweber has joined
[17:01:35] <Simon Josefsson> problem with saslprep and 8859 is german sharp s (ß), it is saslprep:ed into 'ss' which is not backwards compatible with rfc2831...
[17:01:53] <robsiemb> alexey: this is mostly just my todo list
[17:02:06] <jhutz> Hm; is ß not in 8859-1?
[17:02:07] <robsiemb> kurt: lets just skip it then
[17:02:13] <cnewman@jabber.org> Yes, SASLprep breaks compatibility. That's unrelated to the 8859-1 issue.
[17:02:15] <robsiemb> slide: milestones
[17:02:29] <Simon Josefsson> ß is in 8859-1
[17:02:36] <Simon Josefsson> and supported by rfc2831
[17:02:52] <jhutz> I don't believe ß saslprep's into ss.
[17:02:59] <robsiemb> kurt: chris says cram-md5 is widely deployed as specified and we shouldn't break it
[17:03:07] <jhutz> That's a German-language collation order issue, not a canonicalization issue.
[17:03:22] <jhutz> I'd have to check, but I _believe_ that all ISO-8859-1 characters SASLprep to themselves.
[17:04:22] --- dumdidum has left: Replaced by new connection
[17:04:25] <Simon Josefsson> jhutz: I checked ß and you are right
[17:04:59] <robsiemb> kurt: My personal view is that we should write 1 informational document for each mechanism that describes limititations and other concerns about existing specs, and then focus our time on mechs that meet people's long term needs going forward
[17:05:05] <robsiemb> kurt: what do people think?
[17:05:17] <robsiemb> tom: we should set some action items first
[17:05:24] <jhutz> So I don't think 8859-1 downconversion is actually a problem, as long as you carefully define whether you do saslprep first (because there are combining sequences that normalized into 8859-1
[17:05:41] <Lyndon Nerenberg> CRAM-MD5: I have no outstanding technical issues to address. I do need to rev once more to update the references, and I hope to incorporate a bit of cleanup of the prose, and to clarify its applicability.
[17:05:43] <robsiemb> tom: what remains on cram-md5? (assuming we're not going to reopen discussion)
[17:06:34] <robsiemb> lyndon: do you want someone to write the text or can you do it?
[17:06:40] <robsiemb> alexey: Do we need to add saslprep text?
[17:06:41] <Lyndon Nerenberg> suggestions welcome, but i'll do it myself if need be.
[17:07:16] <robsiemb> chris: saslprep doesn't matter a great deal to me for cram, I can work around whatever happens.
[17:07:34] <robsiemb> chris: I am inclined to leave saslprep out of cram
[17:07:47] <Lyndon Nerenberg> i think we agreed that all non-ascii was "broken" anyway, so we should just do saslprep.
[17:08:23] <Simon Josefsson> jhutz: I checked all of iso8859, ½ saslprep to "1/2", same for 1/4 and 3/4
[17:08:57] <jhutz> What? That's odd.
[17:09:12] <Lyndon Nerenberg> we decided that a year or two ago
[17:09:17] <robsiemb> chris: leave this to doc ed's discression, faster is better
[17:09:34] <Lyndon Nerenberg> two weeks to a new draft ...
[17:09:36] <robsiemb> (this == "saslprep in cram")
[17:09:48] --- jis has joined
[17:09:49] <robsiemb> we will stay on that path
[17:10:11] <robsiemb> kurt: if you have any other cram comments, bring them up on the list. sets a Jun 06 milestone
[17:10:13] <Simon Josefsson> jhutz: http://josefsson.org/idn.php/?data=%C2%BC&mode=stringprep&profile=SASLprep&charset=UTF-8&lastcharset=UTF-8
[17:10:19] <jhutz> IMHO those are as broken as ß -> ss
[17:10:28] <robsiemb> kurt: lets up the numbers on the milestone by 1 year each
[17:10:41] <robsiemb> tom: alexey, how soon will digest issues be resolved
[17:10:47] <robsiemb> alexey: I need review before I can answer that
[17:10:58] <robsiemb> alexey: 2 months after review
[17:11:10] <Simon Josefsson> the entire diff between 8859 and saslprep(8859) are: - Ax   ¡ ¢ £ ¤ ¥ ¦ § ¨ © ª « ¬ ­ ® ¯ - Bx ° ± ² ³ ´ µ ¶ · ¸ ¹ º » ¼ ½ ¾ ¿ + Ax ¡ ¢ £ ¤ ¥ ¦ § ̈ © a « ¬ ® ̄ + Bx ° ± 2 3 ́ μ ¶ · ̧ 1 o » 1⁄4 1⁄2 3⁄4 ¿
[17:11:16] <robsiemb> tom: ok, 2-3 months as long as reviews are timely (July 06)
[17:11:42] <robsiemb> tom: cram-md5 should be may 06 sounds like
[17:12:10] <robsiemb> tom: we are Over Time
[17:12:17] --- dumdidum has joined
[17:12:18] --- jis has left: Logged out
[17:12:27] <robsiemb> jeff: what is left in GSSAPI spec?
[17:12:32] <robsiemb> alexey: as far as I know it is done.
[17:12:43] <robsiemb> alexey: last remaining issue was removing spenego, which is done, so should be headed sam's way
[17:12:52] <robsiemb> kurt: may 05 for it then
[17:13:00] <robsiemb> kurt: missing a milestone for GS2 family
[17:13:10] <robsiemb> Simon, when can GS2 be ready for last call?
[17:13:25] <Simon Josefsson> I don't have any open issues except for those raised today
[17:13:37] <Simon Josefsson> If we can resolve them on the list, I'm ready
[17:13:39] <robsiemb> kurt says "When?"
[17:13:48] <robsiemb> Kurt says Jun 06
[17:13:59] <Simon Josefsson> Jun 06 is fine by me
[17:14:07] <robsiemb> Kurt: back out implementation report to Oct 06
[17:14:20] <robsiemb> Kurt: revise charter backed out to Nov 06
[17:14:31] --- dumdidum has left
[17:14:35] <robsiemb> kurt: we will post to the list and send to sam
[17:14:39] --- hartmans has left
[17:14:39] <robsiemb> kurt: cookies are downstairs
[17:14:40] --- raeburn has left
[17:14:40] --- kmurchison has left
[17:14:41] --- kdz has left
[17:14:41] --- jhutz has left: Logged out
[17:14:45] --- robsiemb has left
[17:14:58] --- Robert Martin-Legene has left
[17:14:58] --- gdweber has left
[17:15:24] --- Lyndon Nerenberg has left
[17:18:31] --- cnewman@jabber.org has left: Logged out
[17:19:20] --- Jeffrey Altman has left
[17:24:10] --- rlbob has left
[17:30:02] --- jimsch1 has left
[18:00:00] --- tonyhansen has left
[18:02:10] --- robsiemb has joined
[18:04:03] --- robsiemb has left