[08:04:25] --- amelnikov has joined
[11:50:27] --- jas has joined
[13:43:22] --- Kurt has joined
[13:44:33] --- raeburn has joined
[14:01:38] --- kmurchison has joined
[14:03:04] --- hartmans has joined
[14:06:28] --- kenh has joined
[14:28:33] --- raeburn has left: Disconnected
[14:37:03] <kenh> (Note: I'll be the gateway if there are questions from jabber to the WG)
[14:37:19] --- raeburn has joined
[14:37:26] --- lha has joined
[14:38:33] <jas> (thanks. is someone in the room taking jabber notes?)
[14:38:58] <hartmans> We're not started yet
[14:39:03] <hartmans> We understand that is critical
[14:40:15] --- ludomp has joined
[14:45:27] <hartmans> jaltman is scribing
[14:45:48] --- Jeffrey Altman has joined
[14:45:58] <Jeffrey Altman> Scribe is online
[14:46:01] --- larry has joined
[14:46:45] <Jeffrey Altman> Agenda: Intro and Agenda Bashing Review of SASL Base last call Digest MD5 CRAM-MD5 Milestones Open MIC Russ would like two minutes at the end
[14:47:09] <Jeffrey Altman> Sam Hartman is the new Security AD and will be leaving the working group chair position
[14:47:59] <Jeffrey Altman> First Last Call issued on the SASL base document. Terminology issues are still being discussed
[14:48:19] <hartmans> Significant comments after the first last call technically ended
[14:48:21] <Jeffrey Altman> There might be another working group last call
[14:48:50] <Jeffrey Altman> Summary of issues was posted to the mailing list by Alexi
[14:50:00] <hartmans> Kurt is going over that summary
[14:50:06] <Jeffrey Altman> Alexi's e-mail has been displayed to the group via the projector
[14:50:29] <kenh> (Note: if you have comments, now would be the time to raise them)
[14:51:48] <Jeffrey Altman> Issues: Normalization, dropped text from -09, access control text, and re-keying.
[14:52:53] <amelnikov> dropped text from -09 == access control text
[14:53:18] <Jeffrey Altman> There is some support for Nico's re-keying text for those mechanisms which support re-keying. Alexey has alternative text
[14:54:56] <jas> regarding new section 3.2: to me it is unclear what is meant by "precise form(s)". is it the encoding of characters? the character set?
[14:56:51] <Jeffrey Altman> Sam: identities. there is confusion between the concept of "authorization identity" as in the one used for authorization versus a separate identity requested by the client.
[14:57:53] <Jeffrey Altman> There are many subtle differences in the use of terms throughout the SASL documents not just the base document.
[14:57:54] --- dumdidum has joined
[14:59:29] <kenh> Kurt: I started rewriting section 3.1, and I realized it was a sort of introduction, and I realized that the text should go in the introduction. In other words, the document still need some work (this is in response to simon's question).
[14:59:44] <jas> section 3.2 now says that the precise form(s) of identities are out of scope of SASL, but ends by saying that mechanisms MUST preserve unicode code points in the identities. if the precise forms is out of scope for SASL, how can it make such a specific requirement?
[14:59:53] <amelnikov> Jas: about "precise form(s)" - both
[15:00:19] <hartmans> jas: I think it is the character set values.
[15:01:13] <amelnikov> Sam: what is "character set value"?
[15:01:22] <hartmans> The SASL mechanism must not change the characters in the requested identity
[15:01:33] <kenh> Kurt: There's a misconception about authentication identities; it's not neccessarily transmitted on the wire.
[15:01:49] <hartmans> The SASL mechanism must not change the characters in the requested identity/msg sasl I.E. the code points must be preserved for the requested identity
[15:02:00] <hartmans> The authentication identity is mechanism specific.
[15:02:22] --- raeburn has left: Disconnected
[15:02:23] <hartmans> It may have forms within the mechanism; it may also have som additional forms that are unique to a mechanism and application
[15:03:42] <kenh> Sam: What we're trying to say is that we're trying to preserve the semantics, but the encoding is your problem. But we haven't been precise in saying that.
[15:03:58] <kenh> Kurt: There is still work that needs to be done on this document.
[15:04:12] <hartmans> The reason we cannot just say that the mechanism sends the UTF8 string provided by the application as the requested identity is that the mechanism may not choose to use UTF8
[15:04:21] <hartmans> It may for example need to escape certain characters
[15:04:45] <Jeffrey Altman> Kurt: give the document back to the editor along with freedom to make it work; but give a better explanation of what is confusing people. Basically we need more reviewers.
[15:04:57] <amelnikov> It can use any other character set, as long as there is no loss during conversion
[15:05:22] <hartmans> Alexey: True
[15:06:20] <amelnikov> All: At this stage I would prefer specific suggestions, rather "this sentence doesn't look right".
[15:06:29] <Jeffrey Altman> Very few people have reviewed the document from front to back.
[15:06:44] <amelnikov> But of course something is better than nothing
[15:07:50] <jas> I could try to send something on the list.
[15:08:12] <jas> I was happy with the text in -08...
[15:09:09] <Jeffrey Altman> Kurt: At the very least, please read sections 3.1 and 3.2 and others which are causing confusion. We would like to have review done before the end of the month.
[15:10:47] <Jeffrey Altman> Onto DIGEST-MD5.
[15:11:26] <Jeffrey Altman> List of open issues is being displayed on projector. How many folks have reviewed this document? Answer: not enough
[15:12:36] <Jeffrey Altman> Sam: I apologize for not have followed up on the crypto action item which was picked up at the end of last meeting.
[15:13:14] <Jeffrey Altman> Onto GSSAPI.
[15:13:46] <Jeffrey Altman> GSSAPI has not been reviewed and will not be taken to Last Call until it has been.
[15:14:22] <amelnikov> Sam: can you send me a message about CBC mode attack in DIGEST ASAP?
[15:14:44] --- cnewman has joined
[15:14:45] <hartmans> Not ASAP, but reasonably soon. I realize I suck
[15:14:48] <Jeffrey Altman> Sam: Is this document meant solely to deal with GSS-KRB5 and GSS-SPNEGO or is it to address future GSS mechanisms.
[15:15:16] <amelnikov> Sam: I meant *for me*, not for the mailing list. Doesn't have to be long
[15:16:05] <Jeffrey Altman> Nico: we will not perform re-keying as part of the SASL-GSS mech.
[15:16:43] <Jeffrey Altman> We do not want to alter the SASL-GSS mech. We want to revise to clarify the text but not change the mech.
[15:17:12] <amelnikov> What do we do with SPNEGO?
[15:17:55] <Jeffrey Altman> Kurt: we will not commit resources to new docs until existing ones are reviewed.
[15:18:17] <Jeffrey Altman> Nico: what do we want for new GSS mechs? re-keying? few round-trips?
[15:18:57] <Jeffrey Altman> Kurt: rekeying may not be appropriate for all SASL-GSS mechs. Should be determined on a per mech basis
[15:19:45] <Jeffrey Altman> Kurt: rekeying can be done with the GSS layer outside the knowledge of the SASL layer
[15:20:15] <Jeffrey Altman> Kurt: we need to twist arms to get reviewers for GSS
[15:20:22] <Jeffrey Altman> Onto CRAM-MD5
[15:20:43] <Jeffrey Altman> Has anyone reviewed CRAM? Is there anyone here to speak on CRAM?
[15:20:55] <amelnikov> Do we want to have a look at Simon's KerberosV5 draft?
[15:21:33] <Jeffrey Altman> Chris: if the editor believes we are ready for last call on CRAM we are probably ready. Its technically correct.
[15:21:43] <hartmans> I think I'll object to that draft fairly strongly because it duplicates work of the GSSAPI mechanism.
[15:21:54] <jas> I sent several cram-md5 comments to the list, at least the document on ietf.org does not seem finished.
[15:21:55] <hartmans> I'm not sure whether that objection is as an individual or an AD
[15:22:11] <hartmans> I'm also open to discussion from Simon on that draft and why it is a good idea.
[15:22:33] <amelnikov> Sam: but it can carry Kerberos exchange in-band. GSSAPI can't do that.
[15:22:47] <Jeffrey Altman> Sam: Simon does not believe the existing document is finished
[15:23:06] <hartmans> Why not bring iakerb back from the dead
[15:23:26] <amelnikov> What is "iakerb"?
[15:23:41] <hartmans> A gssapi mech that did kerberos exchanges in-line
[15:23:54] <cnewman> RFC 2195 is already deployed so statements about overlap with GSSAPI mechanisms are irrelevant.
[15:24:05] <lha> iakerb is somewhat special, I'm not sure I like it
[15:24:10] <Jeffrey Altman> Onto Milestones: Kurt: we would like another Working Group Last Call on the base spec before the end of the year
[15:24:19] <Kurt> alexey, when can you submit revisions for base and other i-ds?
[15:25:00] <hartmans> If you get rid of the special parts it seems fine
[15:25:07] <Jeffrey Altman> Kurt: if you only have time to review one document, review the base document
[15:26:01] <amelnikov> Chris: I think Sam was talking about GSSAPI vs. Simon's KerberosV5.
[15:26:11] <Jeffrey Altman> The Milestones on the Working Group page are out of date. They need to be updated.
[15:26:12] <hartmans> I was.
[15:27:11] <amelnikov> Kurt: I need clear suggestions, am not lacking time at the moment.
[15:27:13] <Jeffrey Altman> Russ is approaching the mike
[15:28:03] <Jeffrey Altman> Russ: Sam has done a good job as chair. Congrats to Sam on his new job as A.D.; and for a job well done in this group. If you have suggestions for replacements please speak to Sam or Russ.
[15:28:09] <Jeffrey Altman> Open mic:
[15:28:23] <jas> Re krb5, the features I'm primarily experimenting with (non-infrastructure mode) is not available via gssapi. I'm going to move the specification into the manual for my implementation, since there hasn't been much interest in it.
[15:29:31] <Jeffrey Altman> What is the status of the "Login" mech? Its not a charter working group item. This could be done as an individual submission.
[15:30:03] <Jeffrey Altman> If an individual submission was done, it should be done as a historical document
[15:30:13] <Jeffrey Altman> "Plain" supercedes "Login"
[15:30:23] <hartmans> What's up with SRP
[15:30:54] <Jeffrey Altman> Chris: it is implemented in our SMTP server but it should not leak anywhere else
[15:31:04] <amelnikov> I would like to resurrect SRP, I haven't heard from the author for ages.
[15:31:49] <kmurchison> if i could, i'd like to solicit opinions from the group on creating a SASL mech in which the plaintext password can be recovered by the server (ala Tony's PKI strawman or Chris' old PASSDSS doc). people in the NNTP space need this and will fight against TLS+PLAIN vehemently
[15:31:52] <Jeffrey Altman> Nico: Sun would like to have all new SASL mechs be GSS mechs. Sam: The discussion of generic SASL-GSS mechs should be held on the list.
[15:32:05] <amelnikov> However there are no cycles for SRP, until SASL base is done
[15:32:44] <hartmans> Ken, why can't that be a GSSAPI mech;)
[15:32:53] <Jeffrey Altman> Sam: As an indivdual I am reluctant to support a new mech which is not a GSS mech; as AD I will have a serious conversation with the first person who proposes one. We, the IETF, needs a solution for SASL-GSS which are non-Krb5
[15:33:23] <kmurchison> no particular reason, i'm more familiar with the SASL framework than GSSAPI
[15:33:33] <Jeffrey Altman> The meeting is closed.
[15:33:34] <hartmans> I'm very interested in helping people make GSs mech design simple
[15:33:49] <hartmans> I recognize that getting work done is a much higer priority than technology choice
[15:33:57] <hartmans> But Ken you should discuss the nntp issue with me
[15:33:57] --- Jeffrey Altman has left
[15:33:58] <lha> I've comments on the SRP stuff, esp gss related parts
[15:34:12] --- cnewman has left
[15:34:20] <amelnikov> Whether PASSDSS is GSS or not is irrelevant. The questions are:
[15:34:23] <Kurt> Alexey, thanks much for being on line during this. Will chat with you later... bye.
[15:34:25] --- Kurt has left
[15:34:26] <amelnikov> 1) are people interested
[15:34:42] <amelnikov> 2) is it a good idea
[15:34:50] <amelnikov> Probably 2) should be #1
[15:34:56] <hartmans> Right. I'd be happy to discuss those issues with anyone
[15:35:29] <kmurchison> should i take the PASSDSS (or similar) discussion to the list?
[15:35:43] <amelnikov> Ken: yes, please
[15:35:57] <kmurchison> ok
[15:36:07] --- dumdidum has left
[15:36:23] <amelnikov> Although I suspect we have more SASL mechanisms then active participants
[15:37:36] <lha> PASSDSS ?
[15:38:06] <kmurchison> http://www.watersprings.org/pub/id/draft-newman-sasl-passdss-01.txt
[15:38:41] <kmurchison> its essentially an SSH-style negotiation and to encrypt the plaintext password
[15:39:36] --- hartmans has left
[15:40:01] --- ludomp has left
[15:40:06] --- kmurchison has left
[15:40:58] --- lha has left
[15:41:11] --- jas has left
[15:41:23] --- amelnikov has left
[16:26:23] --- kenh has left
[16:59:45] --- larry has left