[05:04:00] --- Simon Josefsson has joined
[14:44:05] --- kdz has joined
[14:44:38] * kdz has changed the subject to: Simple Authentication and Security Layer (SASL) WG
[14:51:37] --- kdz has left
[15:07:05] --- Jeffrey Altman has joined
[15:09:13] * Jeffrey Altman has changed the subject to: Simple Authentication and Security Layer (SASL) WG - Room 519A
[15:14:05] --- mrex has joined
[15:18:22] --- alexeymelnikov has joined
[15:20:50] --- jimsch1 has joined
[15:21:38] --- hartmans has joined
[15:21:52] --- IETF Meeting Room has joined
[15:23:42] --- kdz has joined
[15:25:03] --- wrstuden has joined
[15:25:23] --- jhutz has joined
[15:25:29] --- fanf has joined
[15:26:16] <jhutz> Audio Stream: http://videolab.uoregon.edu/events/ietf/ietf667.m3u
[15:26:25] --- nico has joined
[15:26:26] <jhutz> Meeting Materials: https://datatracker.ietf.org/public/meeting_materials.cgi?meeting_num=66
[15:26:49] --- kwcoffman has joined
[15:26:54] <jhutz> Skipping document status for now, and going straight into Digest-MD5, since Alexey needs to leave soon
[15:27:30] --- dumdidum has joined
[15:27:39] <jhutz> alexey: issue 1 - AES cipher IV
[15:28:02] --- psavola has joined
[15:28:09] <jhutz> : digest-MD5 suffers from some mitm attacks because the hash doesn't include data generated by both ends.
[15:28:19] <jhutz> : with a new cipher, we can fix it in the new cipher
[15:28:48] <jhutz> : Sam pointed out that if both ends are using the AES cipher, they've already negotiated confidentiality, which is the strongest mode
[15:29:01] --- cnewman@jabber.org has joined
[15:29:10] <jhutz> : however, he suggests we can get protection for qos by adding data to channel bindings
[15:29:41] <jhutz> s/qos/qop
[15:29:50] --- tlyu has joined
[15:29:57] --- kmurchison has joined
[15:30:22] <jhutz> kurt: if you're using channel bindings to protect qop, does that means you only get qop prot when you're using cb?
[15:30:33] <jhutz> alexey: no; it's in the nonce the same way as channel binding
[15:30:58] <jhutz> nico: issue is how you negotiate
[15:31:02] <jhutz> sam: you don't
[15:31:13] <jhutz> alexey: issue 2 - SASLprep vs other prep.
[15:31:35] <jhutz> -09 revision added a new way to describe what preps are supported by the server, and client picks one
[15:31:59] <jhutz> : after discussion, there is a new proposal to deal with both old and new implementations
[15:32:10] <jhutz> : we want to encourage saslprep for new impls but preserve backward compat
[15:32:29] <jhutz> : define a new attribute to say the server supports saslprep (and maybe other new features)
[15:32:55] <jhutz> [typing ahead here...]: server sets this flag, and client uses saslprep when it sees the flag
[15:33:09] <jhutz> : do we need a separate flag for saslprep?
[15:33:20] --- kwcoffman has left
[15:33:21] <jhutz> kurt: sort of sounds like a new mechanism
[15:33:40] <jhutz> alexey: new client when it sees the flag sends both saslprep and "other" string.
[15:34:06] <jhutz> : in many cases, the saslprep version will be the same as the other
[15:34:24] --- bcneuman has joined
[15:34:44] <nico> jhutz: is it worth optimizing this when the two hashes are identical
[15:35:29] <nico> ?
[15:35:53] <jhutz> sam: if you have an optimization where only one is sent, you have more code paths to test
[15:36:01] --- fanf has left
[15:36:28] <Simon Josefsson> What about future versions of SASLprep? From the apparea wg this morning, it seems there is an effort to revisit stringprep in quite some detail.
[15:37:11] <hartmans> Hmm, my reading of IDN nextsteps did not involve revisiting stringprep at this time.
[15:37:22] <hartmans> Future versions of saslprep need to be backward compatible
[15:38:01] <hartmans> I.E. I thought IDN next steps was focusing more on what characters should be permitted, and on enabling new characters etc not on any backward incompatible changes.
[15:38:35] <hartmans> I would be happy to talk to Leslie and John Klensin about this and confirm my understanding
[15:39:15] <Simon Josefsson> hartmans: I think it would be good to confirm this with Klensin
[15:40:26] --- Will Fiveash has joined
[15:41:06] <Simon Josefsson> apparea jabber logs: http://www3.ietf.org/meetings/ietf-logs/apparea/2006-07-10.html
[15:41:46] --- raeburn has joined
[15:41:53] <hartmans> I've asked John to pop up in this jabber room or to answer my question.
[15:42:34] <jhutz> alexey: issue 3 - cnonce same on fast reauth
[15:42:52] <jhutz> [we'll presumably come back to the stringprep issue when john appears]
[15:43:12] <jhutz> : digest-md5 requires the client nonce to be the same on reauth; http-digest doesn't have that restriction
[15:43:39] <jhutz> : do we care? should we make digest-md5 be like http-digest? are there security issues one way vs the other?
[15:44:04] <jhutz> : agreement in the discussion yesterday was we don't care that they're different; it doesn't break anything
[15:44:13] <jhutz> : and we don't think there are any security issues, but want to check with ekr
[15:44:24] <jhutz> alexey: issue 4 - server "SHOULD" vs "MUST" verify authzid
[15:44:47] <jhutz> : this is an issue for the protocol profiles and the base spec; this document is not trying to change
[15:45:05] <jhutz> : suggestion is to replace with a non-normative form like "the server verifies..." instead of "the server SHOULD verify"
[15:45:21] <jhutz> alexey: issue 5 - RC4 vs AES as mandatory-to-implement
[15:45:22] --- klensin has joined
[15:46:10] <jhutz> : unless anyone objects, AES in counter mode will be mandatory-to-implement, instead of RC4
[15:46:11] <hartmans> Hi, John.
[15:46:39] <jhutz> hello, john
[15:46:48] --- cnewman@jabber.org has left
[15:47:04] --- alexeymelnikov has left
[15:47:31] <jhutz> [alexey is still in the room; he's just not in the room. but he will leave soon]
[15:48:15] <hartmans> So, we're wondering what the impact of IDN nextsteps will be on stringprep. Will there be backward incompatible changes that other applications need to care about.
[15:48:55] <Simon Josefsson> [It is difficult to hear Kurt over audio]
[15:49:11] --- raeburn has left: Disconnected
[15:49:21] <jhutz> That is because he is not close enough to the mic. I'll bug him about it.
[15:49:46] <Simon Josefsson> jhutz: thanks!
[15:50:08] <jhutz> alexey: may be of interest to http folk. there will be a barbof on wednesday with http people; http abnf might become a separate doc
[15:50:30] <jhutz> kurt: any other points of discussion on digest-md5?
[15:50:46] <jhutz> kurt: thanks
[15:50:56] <jhutz> chairs: document status
[15:51:06] <jhutz> : new cram-md5. sam, had a chance to look?
[15:51:14] <jhutz> sam: will look now, get back later in meeting
[15:51:37] <jhutz> tlyu: sasl-gs2 - new version out; simon will give us some comments over jabber
[15:51:48] <Simon Josefsson> the draft is pretty self-explanatory
[15:51:57] <Simon Josefsson> the only open issue is channel bindings
[15:52:06] <jhutz> : sasl-gssapi - iesg evel
[15:52:13] <jhutz> : plain: rfc-editor queue
[15:52:23] <jhutz> : digest - just talked about it. wglc in september or so
[15:52:57] <jhutz> [simon: we have your slides; I think they'll get to you]
[15:53:00] --- alexeymelnikov has joined
[15:53:19] <jhutz> sam: where is there an AS in crammd5?
[15:53:39] <jhutz> next: gs2
[15:53:39] <Simon Josefsson> jhutz: ok. it is somewhat difficult to follow audio
[15:53:41] <klensin> Sam, yes, stringprep is going to need to be revisited. Whether SASL will be impacted is unknown and partially up to this WG. Briefly, the problem is this... The tables in stringprep are dependent on / built around Unicode normalization tables. Those tables are, in turn, Unicode-version-dependent. Now, ignoring issues with promises that "they" interpret differently than "we" do, there are circumstances in which comparing a normalized string under Unicode version N is the same as making the same comparison under version N+1. Under others it isn't. A recent proposal for "stable normalization" will help eliminate most of the latter conditions, but not all of them. But, basically, if one is not to be locked into a single version of Unicode (most of stringprep is locked to 3.2 at present), then forward-compatibility involves a bunch of edge cases. An in-person conversation or a chance to some writing would be easier than trying to explain further via Jabber
[15:53:55] <jhutz> stand by, simon
[15:55:06] <hartmans> John, is there anything oother than the coreadendum and normalization isues.
[15:55:47] <hartmans> It's my understanding that existing cases wher normalization is an issue are cases where you are not typically dealing with strings that would be valid and where breaking those strings would be acceptable.
[15:56:05] <klensin> I am expecting that we will emerge with a much more restricted list of permitted characters.
[15:56:34] <jhutz> ... permitted characters for IDN, yes? SASLprep is pretty permissive
[15:56:36] <Simon Josefsson> Are we at gs2 now?
[15:56:48] <Simon Josefsson> Audio is a bit difficult to follow.
[15:56:56] <Simon Josefsson> Oh, I guess we are still at saslprep
[15:57:00] <nico> are we talking about mixing combining characters that shouldn't really be mixed?
[15:57:12] <nico> codepoints
[15:57:33] <nico> simon: not yet
[15:58:13] <kdz> we are going to move on to GS2 now, thanks for your input regarding SASLprep
[15:58:28] <Simon Josefsson> Ok
[15:58:33] <Simon Josefsson> Are the slides up?
[15:58:37] <kdz> yes
[15:58:41] <klensin> "valid" is the key point here. If you mean "valid linguistically in a particular language" then your statement about normalization is probably true. But we have _never_ required linguistic or orthographic validity in either DNS names or personal identifiers... bc3dfg4 would not qualify under either rule. As soon as you move beyond that, the normalization assumptions and changes get into trouble.
[15:58:53] <Simon Josefsson> Right, the current draft is a bit outdated
[15:59:06] <Simon Josefsson> The post today with the latest channel binding text reflect current status
[15:59:22] --- mrex has left: Replaced by new connection
[15:59:29] <Simon Josefsson> Next slide
[15:59:34] <kdz> next
[15:59:41] <Simon Josefsson> A lot of text, I know
[15:59:44] <hartmans> John, understood, but I guess I'm more concerned about breaking linguistically useful text than other text.
[15:59:55] <Simon Josefsson> there are two sub-open issues here
[16:00:05] <Simon Josefsson> first, the general approach to channel bindings in gs2
[16:00:10] <jhutz> for saslprep? passwords are important
[16:00:14] <Simon Josefsson> I think we are done with that, with help from Nico and others
[16:00:31] --- mrex has joined
[16:00:38] <Simon Josefsson> Are there any comments or questions on the channel binding field?
[16:00:51] <Simon Josefsson> We are not using the GSS-API channel binding concept at all now
[16:01:02] <Simon Josefsson> Some GSS-API people should probably review this
[16:01:13] <Simon Josefsson> But as far as I'm concerned, I think it is done
[16:01:58] <klensin> Some linguistically non-useful text may make really good identifiers and passwords. If they don't match forom one Unicode version to the next, we are all in trouble
[16:01:59] <Simon Josefsson> speak up please
[16:02:33] <Simon Josefsson> ok, that's the second sub-open issue
[16:02:37] <jhutz> issues like that are why stringprep profiles are expected not to change their handling of already-defined characters
[16:02:42] <Simon Josefsson> the syntax of tls channel binding
[16:03:27] <Simon Josefsson> No modifications to TLS!!
[16:03:41] <Simon Josefsson> However, you need a TLS library that can compute TLS PRF for you
[16:03:50] <Simon Josefsson> Good libraries support this
[16:04:08] <Simon Josefsson> It is the same problem with client/server random finished messages
[16:04:19] <Simon Josefsson> No modifications to TLS necessary, but your library need to support it
[16:05:15] <Simon Josefsson> the finished message is encrypted
[16:06:46] --- klensin has left: Disconnected
[16:07:18] <Simon Josefsson> I still don't understand how the finished message would work
[16:07:34] <Simon Josefsson> The messages are encrypted, right?
[16:08:07] <Simon Josefsson> I don't believe it is possible to count messages
[16:08:35] <jhutz> Simon, it doesn't matter. If you use a hash of the concatenation of all the finished messages as the channel binding, you should be fine. Because any given set of messages maps to only one channel.
[16:08:53] <Simon Josefsson> My point is that an application cannot access the finished message
[16:09:10] <Simon Josefsson> The TLS library compute them
[16:09:51] <jhutz> the application _transports_ the messages
[16:10:17] <Simon Josefsson> GnuTLS can export both the PRF and the keys, so it is not a big problem
[16:10:28] <Simon Josefsson> However, it does not export the client/server finished messages
[16:10:59] <jhutz> Huh? How can it fail to provide the application with messages which are the application's responsibility to transport?
[16:11:12] <Simon Josefsson> Ok, it provides the messages, but they are encrypted.
[16:11:13] <kdz> Simon, can other widely available TLS libraries (today or easily tomorrow) export the PRF?
[16:11:22] <jhutz> Yes; you use the encrypted messages
[16:11:55] <Simon Josefsson> Many openssl versions don't easily, you need to know about internal structs. I'm not 100% on this, but it is what hostapd is using
[16:12:05] <Simon Josefsson> jhutz: ok, now I understand better
[16:12:47] <Simon Josefsson> My statement about openssl was regarding the PRF
[16:13:04] <mrex> which finished messages? the Close Notify Alerts? They're encrypted at the network level.
[16:13:18] <Simon Josefsson> jhutz: how will the application know how long the encrypted messages are?
[16:14:06] <Simon Josefsson> Maybe the discussion has gone on too long
[16:16:09] <hartmans> Martin, the finish messages sent at the end of the tls key exchange.
[16:16:22] <jhutz> That's a term-of-art in TLS
[16:16:25] <Simon Josefsson> A request: would someone please specify exactly how the client/server finished message approach would work?
[16:16:38] <jhutz> You take the messages, and you hash them.
[16:17:09] <Simon Josefsson> jhutz: but where do you stop hashing? you don't know the length of the encrypted client/finished messages
[16:17:54] <Jeffrey Altman> simon: the application doesn't need to know. the TLS implementation knows.
[16:18:50] <nico> simon: the TLS API should export the finished messages as octet strings
[16:18:54] <mrex> agree -- sorry. Still the finished message follow the ChangeCipherSpec message and are therefore (normally) encrypted
[16:19:15] <Simon Josefsson> Jeffrey Altman: Hm, ok. Then I wonder whether TLS libraries can do this
[16:19:36] <nico> JeffA claims that OpenSSL does
[16:19:48] <Simon Josefsson> Ah, that's interesting. Thanks.
[16:19:50] <nico> I'm guessing SSPI does too and JeffA will confirm
[16:19:54] <nico> I'll look at Java
[16:19:58] <Jeffrey Altman> See OpenSSL SSL_get_finished() and SSL_get_peer_finished()
[16:19:58] <Simon Josefsson> GnuTLS doesn't, but that can change
[16:20:12] <jhutz> Good. Change it. :-)
[16:20:29] <jhutz> sam: I don't believe GS2 should contain statements about use or not of security layers at the sasl layter
[16:20:39] * jhutz agrees with hartmans
[16:21:08] --- tonyhansen has joined
[16:21:12] --- hp has joined
[16:21:13] <Simon Josefsson> I also agree. Will fix it.
[16:21:31] <jhutz> sam: discussion about what channel binding to TLS should be used should _not_ be in this doc. Different things that do it should use the same binding, and there should be a doc.
[16:21:48] <Simon Josefsson> Hm. The doc on SSL_get_finished() says it return the _latest_ finished message, thus presumably there is a synchronization issue
[16:22:02] <jhutz> sam: Russ and I strongly believe definition of bindings for specific channel types needs to be done in the sec area, but is not in scope for any WG.
[16:22:07] <jhutz> ... and should be done by a WG
[16:24:46] <Simon Josefsson> (. We can move it to the IETF general list .)
[16:25:38] <hartmans> Simon, I'd recommend saag or kitten
[16:26:03] <Simon Josefsson> I don't have any remaining open issue.
[16:27:23] <Simon Josefsson> The rest where just quotes from the document
[16:27:28] <Simon Josefsson> No need to go through them
[16:27:55] <Simon Josefsson> I'll update it this week
[16:28:05] <Simon Josefsson> I think it is ready for WGLC after that
[16:28:52] <Simon Josefsson> I can reference Nico's document, and ignore it for the GS2 document
[16:29:22] <nico> ignore it?
[16:29:26] <nico> it's a normative reference
[16:29:46] <Simon Josefsson> Right, but not include text in gs2
[16:29:52] <nico> yes
[16:30:14] <nico> well, in the intro you might have a reference to it where you first mention "channel bindings"
[16:30:23] <nico> you want readers to be able to find the reference
[16:30:31] <Simon Josefsson> Yes, right. But 5.1 is dropped
[16:30:39] <nico> yes
[16:38:18] --- hartmans has left
[16:38:48] <mrex> In some environments SSL Accellerators (which terminate and re-encrypt the SSL wrapper) are becoming more and more common. These create similar problems for channel bindings based on the TLS session/endpoint as NATs do for the IP-Addresses and Kerberos-Tickets with channel bindings based on IPv4 Addresses
[16:39:02] --- psavola has left
[16:39:34] <Simon Josefsson> mrex: right, but they will have to be extended with support for channel bindings
[16:39:53] <Simon Josefsson> mrex: there is a direct security issue if they don't, which is different from NATs
[16:40:05] <Simon Josefsson> mrex: but I agree it will be a practical problem
[16:40:21] <kdz> we're done. Thanks, Kurt
[16:40:24] --- kdz has left
[16:40:29] --- wrstuden has left: Computer went to sleep
[16:41:16] --- IETF Meeting Room has left: Disconnected
[16:41:19] --- bcneuman has left
[16:42:11] --- tlyu has left
[16:43:30] --- dumdidum has left
[16:44:56] --- Jeffrey Altman has left
[16:44:59] --- jimsch1 has left
[16:47:35] --- Simon Josefsson has left
[16:47:57] --- hp has left
[16:49:13] --- nico has left
[16:50:01] --- jhutz has left: Logged out
[16:50:28] --- mrex has left
[17:23:06] --- alexeymelnikov has left
[17:23:25] --- tonyhansen has left
[17:57:01] --- alexeymelnikov has joined
[17:58:13] --- Jeffrey Altman has joined
[18:36:25] --- Will Fiveash has left
[19:00:30] --- LOGGING STARTED
[19:04:23] --- alexeymelnikov has joined
[19:08:33] --- Jeffrey Altman has joined
[19:34:08] --- alexeymelnikov has left
[19:38:05] --- kmurchison has joined
[19:40:08] --- alexeymelnikov has joined
[19:44:34] --- alexeymelnikov has left
[20:00:09] --- Jeffrey Altman has left