[20:35:32] --- tlyu@jis.mit.edu has joined
[20:39:05] --- cnewman@jabber.org has joined
[20:39:49] --- cyrus_daboo has joined
[20:40:23] --- cyrus_daboo has left
[20:40:31] --- ietf-meeting has joined
[20:40:52] --- hartmans has joined
[20:40:54] --- pguenther has joined
[20:42:21] --- alexeymelnikov has joined
[20:42:35] --- raeburn has joined
[20:43:15] --- hartmans2 has joined
[20:44:19] --- Barry Leiba has joined
[20:44:51] <cnewman@jabber.org> Anyone hearing the audio stream?
[20:45:06] --- jaltman has joined
[20:45:49] --- cyrus_daboo has joined
[20:45:56] --- jhutz has joined
[20:46:12] --- kdz has joined
[20:46:39] --- Lisa has joined
[20:46:54] <cnewman@jabber.org> I'll be the jabber scribe
[20:47:12] --- tonyhansen has joined
[20:47:19] <cnewman@jabber.org> Agenda slide
[20:47:22] <Lisa> Is there anybody relying on jabber for participation today?
[20:47:27] <cnewman@jabber.org> Document status slide
[20:48:08] <cnewman@jabber.org> CRAM MD5 has not been revised since last IETF. Lyndon will look into text updates.
[20:48:28] <cnewman@jabber.org> GS2 we have some slides to go through later
[20:48:34] <hartmans2> Lisa, apparently not. Audio is fine. You can here people opening sodas etc.
[20:48:35] <cnewman@jabber.org> GSSAPI in RFC editor queue
[20:48:39] <cnewman@jabber.org> PLAIN is RFC 4616
[20:49:14] <cnewman@jabber.org> DIGEST going for a while, time to wrap it up.
[20:49:33] --- kmurchison has joined
[20:49:44] <cnewman@jabber.org> DIGEST-MD5 slide
[20:50:00] <jaltman> http://www3.ietf.org/proceedings/06nov/slides/sasl-0.pdf
[20:50:08] <jaltman> slide 3
[20:50:36] <cnewman@jabber.org> Alexey at mic: made editorial changes
[20:50:44] <cnewman@jabber.org> DIGEST-MD5: non-editorial changes slide
[20:51:31] <cnewman@jabber.org> Alexey thinks document has no major issues and is ready for WG last call.
[20:51:39] <cnewman@jabber.org> DIGEST-MD5: open issues slide
[20:53:53] <cnewman@jabber.org> Open issues need some additional text and new examples, no remaining technical changes.
[20:54:29] <cnewman@jabber.org> Sam: HTTP digest is under review on http mailing list to determine if it should be updated or obsoleted.
[20:56:12] --- sc has joined
[20:57:13] <cnewman@jabber.org> Sam: need make sure HTTP digest revision is kept compatible with DIGEST-MD5
[20:58:28] <cnewman@jabber.org> Kurt: How to move forward with document?
[20:58:47] <cnewman@jabber.org> Kurt: need commitment from volunteers.
[20:59:33] <cnewman@jabber.org> Volunteers: Chris N. and Jeff A.
[21:00:02] <jaltman> oh no, Britney Spears has filed for divorce
[21:00:08] <kdz> The CRAM-MD5 mechanism is intended to have limited use on the Internet. The mechanism offers inadequate protection against common attacks against application-level protocols (see the Security Considerations section) and is prone to interoperability problems (see Interoperability Considerations section). Designers considering profiling use of this mechanism in their application-level protocols should consider alternative mechanisms intended for common use, such as DIGEST-MD5.
[21:03:36] <cnewman@jabber.org> discussion issue: concern about "interoperability considerations" suggestion to use "internationalization considerations" instead
[21:04:05] <jhutz> <sigh>; using a machine whose monitori is 12' ahead and to the left and a little up is... annoying
[21:04:17] <jhutz> I should have made Jeff do it :-)
[21:04:21] <cnewman@jabber.org> Suggest deadline at end of month for CRAM-MD5 last call.
[21:05:06] <cnewman@jabber.org> Moving on to GS2 issues
[21:07:12] <cnewman@jabber.org> Alexey has action item to verify issues from last call were addressed.
[21:07:38] <cnewman@jabber.org> Simon has also raised new issues -- specifically with respect to GSS mechanism that don't support integrity
[21:09:52] <cnewman@jabber.org> Kurt: is there consensus to write things as GSS mechanisms?
[21:09:57] <cnewman@jabber.org> Jeff: yes
[21:09:58] <cnewman@jabber.org> Me: no
[21:11:21] --- keyajima has joined
[21:13:24] <cnewman@jabber.org> meta-discussion about that topic. People capable of writing SASL mechanisms, not sure how to do GSSAPI bindings.
[21:15:35] <cnewman@jabber.org> Kurt: back to slide
[21:15:53] <cnewman@jabber.org> Do we believe GS2 should support GSSAPI mechanisms that do not have integrity protection?
[21:16:01] <cnewman@jabber.org> Some evidence the answer is yes.
[21:17:13] --- keyajima has left
[21:18:33] <cnewman@jabber.org> Alexey: suggestion that people who want non-integrity mechanisms provide extra text. If text not provided, move forward without it.
[21:20:55] <cnewman@jabber.org> Chair: we will do option 1 (publish without this feature) unless option 2 is done soon. Must have volunteers in next week and early December timeframe for text.
[21:22:42] <cnewman@jabber.org> Next slide: channel binding documents
[21:25:13] <cnewman@jabber.org> GS2 references draft-williams-on-channel-binding-00
[21:25:35] <cnewman@jabber.org> But Simon believes draft-altman-tls-channel-bindings-00 is not sufficient to implement today
[21:32:40] <cnewman@jabber.org> Q: How does the GS2 implementor find the document that specifies exact protocol for TLS channel bindings.
[21:40:23] --- cnewman@jabber.org has left: Logged out
[21:40:26] <Lisa> I'm taking over scribing now.
[21:41:27] <Lisa> Sam: Channel bindings are entirely out of scope for SASL. The discussion should proceed, writeups are good, but ultimately SASL should do what draft-williams says to do about channel bindings. Send input to the list where that document is being discussed.
[21:42:03] <Lisa> Sam: That's a normative reference in SASL docs to draft-williams.
[21:42:58] <Lisa> Phillip: Are we going to have the institutional memory to continue this policy?
[21:43:35] <Lisa> Phillip: How does an IMAP client, for example, get the channel binding, considering the typical APIs?
[21:44:36] <Lisa> JeffH: Application protocols could say "Use channel bindings" and follow the SASL reference to draft-williams, or they could directly reference channel bindings. SASL doesn't know how to define this for all those application protocols.
[21:44:50] --- alexeymelnikov has left
[21:45:01] <Lisa> Phillip: How many 1-page drafts will this result in, where the draft says "here's how this protocol does channel bindings?"
[21:45:28] <Lisa> JeffH: You have to update IMAP standard because otherwise it won't do channel bindings. It won't communicate with a peer using channel bindings.
[21:46:01] <Lisa> Sam: I don't think that's true for MD5 channel bindings.
[21:47:17] <Lisa> If the client supports channel bindings and asks for it, and the server implementation of SASL doesn't support channel bindings, then the server returns a nonce that doesn't include the channel binding. What happens then?
[21:48:10] <Lisa> Sam: There's an interesting interaction between CCM and GS2. I think that means you don't use CCM with SASL.
[21:49:47] <Lisa> If the app protocol says "you MUST use channel bindings", the other end must drop your connection if you don't use channel bindings or they don't bind. But in the absence of those specified requirements, it's an implementation choice. Draft-williams should make these issues clear.
[21:52:18] <Lisa> Phillip: In essence channel bindings are a new service provided by SASL, since the old attempt wasn't successful. How do we deal with new services in a protocol like IMAP? by revving the spec.
[21:53:19] <Lisa> Kurt :We could end up with a SASL Base spec that says "Unless the protocol says otherwise, channel bindings are optional"...
[21:54:17] <Lisa> Sam: Just because GS2 was built from scratch to support channel bindings, doesn't mean the application will. It may not have the glue.
[21:55:52] <Lisa> JeffH: We'd never require an application to always have channel bindings, unless it always ran in an environment where it could.
[21:58:38] <Lisa> Sam: I'd love to see the update that does this but I don't want to block on it.
[21:59:45] <Lisa> Kurt: There's somewhat of a consensus that what the GS2 document is doing is fine. There's insufficient consensus to change the document to do something else such as reference draft-altman directly.
[21:59:57] --- alexeymelnikov has joined
[22:02:45] <Lisa> Option 1: Reference draft-altman-tls-channel: viable option? Not viable? Hum indicates it's not viable.
[22:04:58] <Lisa> Kurt: Do people believe that leaving the GS2 document as-is is a good idea? Hum indicates that's a good idea.
[22:06:10] <Lisa> Kurt: Should we get some implementation experience before the WG makes its recommendations? Is that necessary?
[22:07:23] <Lisa> Tom: we have an implementor who feels that the two drafts (other than draft-altman) aren't ready for general consumption.
[22:09:28] <Lisa> Lisa/me: Having a fully-implementable set of documents is generally thought to be a good idea! I told a WG today they couldn't published an incomplete set of documents as Proposed standard (with missing pieces like that)
[22:10:05] <Lisa> Sam: But if implementation experience isn't going to cause the documents to change, then we might as well get some process out of the way for those documents.
[22:11:06] <Lisa> Decision to go ahead and publish but not put into RFC queue until the complete set of documents is ready to go together.
[22:12:41] <Lisa> Slide on open issue 3/3: computing kerb v5 GS2 mech name. Got volunteers to double-check the computation: Alexey, Jeff, Kurt.
[22:14:21] <Lisa> Slide on milestones.
[22:14:32] --- dumdidum has joined
[22:15:23] <Lisa> These drafts will actually go to IESG in December timeframe. Beyond that, there is some work to be done on impl'n reports for Draft Standard.
[22:15:33] <jhutz> GS2, CRAM-MD5, DIGEST-MD5 to IESG - was Sep 2006, Kurt suggests Dec 2006
[22:15:56] <jhutz> draft-ietf-provreg-epp-*
[22:17:27] <Lisa> Sam: The IESG (Ted) is going to try a IETF-wide last call with a downref: the last-called document going to Draft will reference TLS as a Proposed Standard. If the community approves this, we take that to mean that downrefs through our variance process are OK.
[22:17:44] <Lisa> Sam: Then a similar thing becomes possible for this case.
[22:19:16] <Lisa> There's some debate possible about whether SASLPrep and StringPrep are "mostly unrelated documents".
[22:19:56] <Lisa> Tom: Nobody is assigned to make this advancement to Draft Std happen. Does this fall to the chairs? They can delegate.
[22:20:27] --- raeburn has left: Disconnected
[22:21:06] --- jaltman has left
[22:21:23] <Lisa> Sam: We need two implementations of some app that uses GSSAPI, use the same mechanism, and are interoperable with that mechanism. We can use that to advance GSSAPI and that mechanism (and not the app).
[22:21:31] <Lisa> May I recommend "external" as that mechanism.
[22:22:08] <Lisa> Jeffh:Does that mechanism exercise all the features of the framework? Don't we need to demo interop of a mechanism that uses security layer?
[22:23:20] <Lisa> Kurt: It doesn't matter what mechanism we demo interop with, or what status it has, as long as it exercises all of the features of the framework -- in order to advance the framework.
[22:24:19] <Lisa> Kurt: Also there's no requirement that we use exactly one mechanism to demo all the features of the framework.
[22:24:47] <Lisa> The Hunting of the Volunteers.
[22:27:38] <Lisa> The document also makes MUST requirements of future specification writers.
[22:27:54] <Lisa> Sam: You don't have to test all the MUSTs, you test the features of the protocol.
[22:28:17] <Lisa> Phillip: Does LDAP do data-with-success? LDAP supports all options so we have at least one way to demo those features.
[22:28:49] <Lisa> Kurt: OpenLDAP uses Cyrus SASL but there's hacks to use Gnu SASL, so that can be used to test two different impl's of SASL.
[22:32:26] <Lisa> Phillip: This is the tradeoff of doing a framework. Instead of having NxN protocols and auth mechanism, we have N+N plus a hairy bit in the middle.
[22:33:23] --- sc has left: Computer went to sleep
[22:33:41] <pguenther> "Hunting of the Volunteers"? What, you want to hang a volunteer's head on your wall?
[22:33:58] <Lisa> They can be as elusive as Snarks at times.
[22:34:20] <pguenther> interop report == "what I tell you three times is true"
[22:35:11] --- alexeymelnikov has left
[22:35:20] <Lisa> Kurt points out that the WG charter only requires the WG to produce something that *could* be a Draft Standard, not something that *is* :)
[22:35:37] <pguenther> Kurt will never be allowed to write a charter again
[22:38:34] <Lisa> Kurt plans a design team to solidify what's needed for interop reports, and who to talk to.
[22:40:52] <Lisa> Planned for Jun 2007?
[22:41:36] --- dumdidum has left
[22:42:07] --- kmurchison has left
[22:42:16] <Lisa> Meeting closed.
[22:42:21] --- pguenther has left
[22:42:26] --- Barry Leiba has left
[22:42:27] --- Barry Leiba has joined
[22:42:34] --- hartmans has left
[22:42:36] --- Barry Leiba has left: Logging off
[22:42:43] <jhutz> Proposed milestones: GS2, CRAM-MD5, DIGEST-MD5 in Dec 2006 Interop report in June 2007 Update or conclude in July 2007
[22:42:45] --- tlyu@jis.mit.edu has left
[22:42:45] --- hartmans2 has left: Disconnected
[22:42:47] <jhutz> GONE
[22:42:49] --- Lisa has left: Logged out
[22:42:49] --- jhutz has left
[22:42:52] --- kdz has left
[22:43:40] --- ietf-meeting has left: Disconnected
[22:43:45] --- cyrus_daboo has left
[22:49:47] --- nico has joined
[22:53:09] --- nico has left
[22:53:12] --- tonyhansen has left