[11:54:01] --- david.black has joined
[12:01:13] --- hartmans@jis.mit.edu/owl has joined
[12:01:31] --- nico has joined
[12:01:37] <nico> no scribe?
[12:01:38] <hartmans@jis.mit.edu/owl> We have not quite started yet
[12:02:01] <hartmans@jis.mit.edu/owl> Do you not have audio? I can see if we can cons up a jabber scribe
[12:02:03] <nico> ok
[12:02:08] <david.black> Nothing coming through on audiocast
[12:03:53] <nico> ok, some audio
[12:06:55] <david.black> No audio here (worked yesterday)
[12:07:32] <hartmans@jis.mit.edu/owl> Hmm. Nico are you hearing audio?
[12:07:42] <nico> yes
[12:07:50] <nico> loud and clear
[12:08:05] <nico> http://videolab.uoregon.edu/events/ietf/ietf703.m3u
[12:08:08] <david.black> Technical problem on my end ...
[12:08:35] <hartmans@jis.mit.edu/owl> David, have you followed my waves?
[12:08:39] <nico> slides UTL?
[12:08:45] <nico> URL even
[12:09:09] <david.black> No audio for me yet, but I did see Sam's post to list and discussion
[12:09:28] <nico> ietf.org is slow today
[12:10:29] <david.black> Ok, problem fixed, Tom's coming through loud and clear ...
[12:11:36] <david.black> I can stay on until about 10:30 Vancouver time.
[12:13:30] <nico> iSER may not be a good spec to follow
[12:13:50] <nico> is the jabber room up on a projector in the physical room?
[12:14:28] <nico> iSER may not be a good spec to follow because iSCSI came about before channel binding and depends on IPsec w/o channel binding
[12:15:06] <david.black> "Undefined Interfaces" = "Magic happens here"
[12:15:16] <hartmans@jis.mit.edu/owl> No, I can channel
[12:15:22] <nico> ok
[12:15:48] <nico> BTNS will pick up no new work items for NFSv4
[12:16:25] <nico> we need to find a way to make sure that the jabber room is always projected in the physical rooms
[12:17:39] <david.black> No slides in meeting materials tool
[12:19:37] <david.black> Ok, Nico - now you have a customer for connection latching ...
[12:19:59] <nico> david.black: this was *always* the main intended customer for it
[12:20:08] <nico> there are other customers for it also
[12:20:20] <nico> but this one has been the main intended one
[12:20:40] <david.black> I know, but now Sam has committed this as necessary
[12:22:37] <hartmans@jis.mit.edu/owl> Right. The only things BTNS may do is ipsec channel binding and connection latching. I need to figure out if channel binding registration is within btns's charter. I think that it is not and that is broken and should be fixed
[12:23:37] <david.black> Need to get the ipsec channel binding work done once, so iSCSI can pick it up (don't hold your breath waiting for it, though)
[12:24:19] <nico> sam: channel binding for IPsec is trivial as an individual submission once we have connection latching
[12:24:55] <nico> david.black: yes, the way iSCSI did authentication, folding channel binding into it will be a lot more involved than for NFSv4
[12:26:44] <hartmans@jis.mit.edu/owl> And defining the channel binding is clearly out of scope for btns
[12:27:09] <nico> hartmans: right, but like I said, that's trivially done as an individual submission I-D
[12:27:43] <hartmans@jis.mit.edu/owl> Agreed
[12:27:49] <david.black> Nico: I think most of the work is to get it folded into a CHAP-like mechanism (don't gag, please). The SPKM mechanisms are effectively obsolete, Kerberos ought to be redone to follow what NFS does and I'm not sure whether SRP is actually used.
[12:28:13] <nico> david.black: sounds like a mess :)
[12:28:27] <david.black> Yes, but it's *my* mess ;-)
[12:28:28] <hartmans@jis.mit.edu/owl> Take a look at scram in sasl for a chap-like mechanism that does channel binding
[12:32:03] <nico> what Sam said
[12:33:04] <david.black> I'll take a look. This might turn into an "inflict SASL on iSCSI" activity, which is not that hard to specify, but would need implementation to make sure it works.
[12:33:32] <nico> well, only the new gs2 mechanism for SASL knows how to do channel binding
[12:33:51] <nico> gs2 is a new version of the old "GSSAPI" SASL mechanism
[12:34:10] <nico> and we still lack a decent set of password-based GSS mechanisms
[12:34:15] * nico sighs
[12:34:54] <hartmans@jis.mit.edu/owl> I thought you were going to help specify scram as a gss mech and scram definitely knows about channel binding
[12:35:01] <nico> yes
[12:35:06] <nico> that is true
[12:35:22] <nico> but first someone's got to produce a doc that I can work with
[12:35:39] <nico> or maybe I should follow what's been going on in the SASL WG :^/
[12:36:20] <david.black> For iSCSI, a GSSAPI "cure" may be worse than the "disease". SASL's going to be hard enough ...
[12:38:09] <nico> david.black: I agree, use SASL/GS2 and you'll be doing all of the correct GSS-API things + supporting channel binding
[12:38:24] <nico> without having to think about the details of how to do channel binding
[12:39:54] <david.black> I'm concerned about the amount of code that GSSAPI pulls into a system that hasn't already done Kerberos (and there are lots of iSCSI systems in that situation)
[12:40:14] <david.black> In contrast, SASL in principle is no big deal, as iSCSI happily exchanges text blocks as part of setting up a connection.
[12:40:27] <nico> again, SASL/GS2 pulls in GSS-API
[12:40:38] <nico> other SASL mechanisms may not know how to do channel binding
[12:41:15] <david.black> Understood - life never ceases to be "interesting"
[12:41:35] <nico> the only other SASL mechanism likely to support channel binding is SCRAM, which Sam just mentioned, and which will be available as a GSS-API mechanism (and therefore through SASL/GS2 as well)
[12:41:55] <nico> SCRAM is a password-based mechanism that someone's working on
[12:42:04] <nico> so it's probably what you're looking for
[12:42:24] <nico> the GSS-API is no sweat for an impleementor that already supports Kerberos V
[12:42:59] <david.black> Right, if Kerberos is there, GSS-API is not a big deal, but I believe a lot of the iSCSI systems don't support Kerberos.
[12:43:10] <hartmans@jis.mit.edu/owl> No, gss-api does not mean a lot of code. We're trying to separate gss as a protocol which is easy from gss the library.
[12:43:34] <nico> true, the GSS-API is no big deal either if you don't want to support Kerberos V
[12:45:21] <hartmans@jis.mit.edu/owl> We're trying to prove with scram that you can do a very very simple over the wire gss protocol
[12:45:41] <david.black> Sam's comment sounds promising - implementers may want to just do the one mechanism with the GS2 syntax on the wire without building the end-point framework that allows other mechanisms to drop in.
[12:46:06] <hartmans@jis.mit.edu/owl> But I would do sasl rather than gss for iscsi
[12:46:24] <nico> sam: we all agree
[12:46:34] <nico> but SASL/SCRAM or SASL/GS2 using SCRAM?
[12:46:43] <david.black> Completely agree - SASL is clearly the place to start for iSCSI, and SASL/GS2 is then a means to the end of "channel binding".
[12:47:15] <hartmans@jis.mit.edu/owl> I thought the plan is that sasl/scram would have the same over the wire as sasl/gs2/scram
[12:47:16] <david.black> If I can get channel binding with SCRAM over SASL without GS2, that's attractive.
[12:48:06] <nico> sam: ah, yes, that's right
[12:48:12] <nico> thanks for the reminder
[12:48:20] <nico> I'd swapped that out, as you say
[12:52:42] <david.black> Questions are very faint on audio
[12:55:12] <david.black> Clearly need to make it work for NFSv4 first ...
[12:58:47] <david.black> If Lars just suggested sending the federated FS work to a BOF, that sounds like a good idea.
[12:59:30] <nico> note to self: must read that I-D
[12:59:47] <nico> yeah, can someone ask that folks use the mic?
[12:59:49] <nico> please?
[13:00:59] <david.black> The good news about that ID is they got the "go use LDAP" clue ...
[13:09:31] <hartmans@jis.mit.edu/owl> I'm sorry. Lars and I had already packed up our computers to leave
[13:16:49] <nico> ok
[13:16:56] <nico> thanks
[13:23:59] <david.black> Need to go now ...
[13:24:06] --- david.black has left
[13:24:37] --- nico has left
[13:28:25] --- nico has joined
[13:28:42] <nico> sigh, use the mic
[13:34:56] --- nico has left