[06:05:18] --- jschoenwae@jabber.org has become available
[06:20:40] --- jschoenwae@jabber.org has left: Logged out
[06:47:08] --- kenh has become available
[07:01:33] --- hartmans has become available
[07:03:14] --- bert has become available
[07:03:39] --- hardaker has become available
[07:03:39] --- mike has become available
[07:04:11] --- jschoenwae@jabber.org has become available
[07:09:41] --- rstory has become available
[07:10:10] <hartmans> Does anyone here need scribing?
[07:10:12] --- mike has left
[07:10:14] <hardaker> yes
[07:10:22] <kenh> The audio works fine for me.
[07:10:27] <rstory> i'm supposed to, had login problem..
[07:10:33] <hardaker> I may have to reboot to get audio I think...
[07:10:42] --- mike has become available
[07:10:46] <rstory> apologies in advance for name mangling..
[07:10:52] <rstory> earlier:
[07:10:58] <rstory> juergen: -decide on ekms
[07:11:04] <rstory> -charter says we have to decide this month what we are going to do
[07:11:08] --- ietfdbh2 has become available
[07:11:11] <rstory> -transport decision: TLS+SASL, SSH, DTLS, BEEP
[07:11:58] <ietfdbh2> hi, I'm here and am listening
[07:12:47] --- hardaker has left: Disconnected.
[07:13:28] <rstory> eric: asking about BEEP and peer to peer over tcp
[07:14:00] <rstory> elliot: both sides listening, both sides roles are know. ssh could do it, but doesn't
[07:15:14] <rstory> juergen: what advantage to this proposal?
[07:15:28] <rstory> elliot: reuse of ietf stuff, as much as possible
[07:15:47] <kenh> Note: I can think of other security mechanisms that also have a tightly defined client and server role (e.g., Kerberos)
[07:15:50] <rstory> elliot: sasl, tls is congruent with netconf and elsewhere
[07:16:22] <rstory> elliot: possible reuse of connections
[07:16:28] --- jhutz has become available
[07:16:58] <rstory> juergen: in netconf, ssh manditory, beep otional; should we do the same, or differently
[07:17:09] <rstory> elliot: i wanted beep required
[07:17:34] <rstory> bert: important question: do we want operators to use ssh for netconf, and force beep for sercure snmp?
[07:17:49] <rstory> bert: better to have 1 solution, or two?
[07:18:18] <rstory> elliot: i don't see that ssh solves the other problem i solved
[07:18:38] --- hardaker has become available
[07:18:49] <rstory> other problem solved is: ability to do peer-to-peer, call home
[07:19:05] <rstory> juergen: netconf bailed on notifications
[07:19:24] <rstory> elliot: netconf meant syslog like for notifications, which isn't the same as snmp notifications
[07:19:46] <ietfdbh2> so if BEEP were used, would we be able to integarte syslog, snmp, and netconf?
[07:19:47] <rstory> bert: any operator opinions on 1 vs 2 mechanisms?
[07:20:36] <rstory> elliot: no reason we couldnt do all 3 on one tcp connection
[07:21:20] --- mstjohns has become available
[07:21:34] <rstory> elliot: key issue: same connection, needs authentication in the same way
[07:22:11] <rstory> uri:seems like proposals are addressing only parts of snmp protocol
[07:22:28] <rstory> ure: maybe different security mechanisms for different operations?
[07:22:50] <rstory> uri: eg tcp for retrieval, udp for pinging, ?? for notifications
[07:23:08] <rstory> eric: datagram desirable?
[07:23:29] <rstory> eric: yes = DTLS, no = the others, dump DTLS
[07:23:35] <bert> is there noise on the audio? one mic is close to projector, I can move it if needed
[07:23:43] <kenh> The audio is fine for me.
[07:23:47] <hardaker> it sounds ok, but there is a whine but you couldn't fix that.
[07:23:58] <bert> ok
[07:24:08] <rstory> juergen: elimination good idea, we can eliminate 1 or 3 via UDP decision
[07:24:25] <hardaker> but keep scribing if possible because I can't pay as much attention to the audio when I'm talking
[07:24:29] <rstory> uri: wes said on list, i agree, normal network doesn't matter tcp/udp
[07:24:41] <rstory> uri: problem network, we need UDP
[07:25:04] <rstory> juergen: don't need to agree on 1 solution, but we need to eliminate some proposals
[07:25:12] <mstjohns> Datagram will continue to be needed for things like traps/notifies...
[07:26:08] <rstory> uri: notification w/out session on bad network will be problematic
[07:26:16] <kenh> To be fair, if the network is in trouble, it's likely you will have a hard time talking to your RADIUS/Kerberos/whatever server.
[07:26:37] <hartmans> kenh: I've tried to make that point but I'm not sure it has sunk in.
[07:26:41] <rstory> mstjohns: problem/cost w/secure transport is establishment
[07:27:04] <rstory> elliot: don't need datagrams for traps/notifies.. could use beep as easily?
[07:27:12] <rstory> uri: disagrees
[07:27:17] <rstory> elliot: as easy as dtls
[07:27:28] <rstory> juergen: do we need udp? more comments?
[07:27:53] <rstory> uri: if we want to cover bad networks, yes. if isms only for normal networks, no.
[07:28:00] <ietfdbh2> we need UDP because it is better for certain purposes. But we shouldn't limit ourselves to just UDP.
[07:29:00] <rstory> sharon: needed for notifications. don't need to decide tcp/udp now. cant eliminate 3/4 protocols yet
[07:29:04] <kenh> Since an explicit goal of the WG is to use existing security services, I think operating on broken networks is an explicit non-goal.
[07:29:31] <rstory> uri: connections for monitoring/display, but use cli for troubled networks
[07:29:46] <rstory> elliot/sharon/juergen: cli usually = ssh = tcp
[07:30:47] <rstory> eric: questions: do you need flexible authentication? do you need udp
[07:30:56] <rstory> elliot whiteboarding a chart..
[07:31:43] <rstory> eric: no flexible auth vs udp
[07:31:50] <rstory> auth+udp = design something
[07:32:06] <hardaker> nows the time when all you people with cell phone cameras and web servers could speak up ;-)
[07:32:22] <hardaker> (other than rstory who is taking notes and shouldn't distract his attention ;-)
[07:35:20] <ietfdbh2> microphione please!!!!
[07:35:35] <rstory> eric: back to the diagram
[07:35:44] <rstory> datagram + flexible auth = somethign new
[07:35:54] <rstory> datagram + inflexible = dtls
[07:36:06] <rstory> tcp+ flexible = sasl+tls /beep
[07:36:16] <rstory> tcp + inflexible = ssh? tls?
[07:36:54] <ietfdbh2> Some uses of a UDP transport might not need auth infrastructure. Some uses of UDP could work well with a "root" user via USM. UDP does not necessarily imply tying into a security infrstructure.
[07:37:26] <rstory> eric: i would cut ssh, not as flexible
[07:37:47] <rstory> sharon: need to integrate with deployed infrastructure?
[07:38:00] <rstory> hartmans: how is ssh not as flexible
[07:39:09] <rstory> eric: if dave's point is we can use what we have, i'm ok with that
[07:39:16] <rstory> sorry, that was elliot
[07:39:30] <rstory> eric: need new datatgram mode, better than usm needed?
[07:39:32] <jhutz> perhaps people think ssh is inflexible because they are used to using it to log in to an interactive shell, rather than to provide an authenticated, integrity-protected stream over which to run a service. ssh can do that, just as TLS can.
[07:40:21] <rstory> davep: working on products, creating admin user = username + password, using that gives acces via multiple interface
[07:40:39] <rstory> davep: that's better than needing two sets of username/passwords
[07:40:57] <jhutz> no; I now see I was lacking context. Perhaps someone here can tell me what isms people mean be "flexible authentication" ?
[07:41:31] <rstory> sharon: don't we have a requirements list? compare proposal to those, instead of eric's chart?
[07:41:45] <rstory> juergen: this is basic. need datagrams or not.
[07:42:20] <rstory> sharon: notification are a requiremen, datagrams are a solution, not the only way
[07:42:26] <ietfdbh2> I think the USM/UDP we have may be adeqaute, but being able to expand UDP to optionally use a secure UDP session (e.g. via DTLS) might be a useful future extension. For now we should concentrate on getting a securty model that ties into external security infrastructure, and most of the available infrastructure is TCP based, and having a TCP transport has additional benefits for SNMP.
[07:43:10] <rstory> juergen: is operation in troubled networks necessary? personal preference, if we don't need to, other proposals (not dtls) are more mature
[07:43:22] <hardaker> I think that isms requiring TCP doesn't buy anything for anyone needing UDP. Forcing them to use UDP/USM is a loss.
[07:44:41] <rstory> uri: existing infrastructures for authentication, nothing to do with sessions.
[07:45:34] <rstory> uri: don't need to decide now
[07:45:43] <rstory> juergen: then how do we make progress
[07:45:50] <hartmans> Wes, I don't understand what your statement means.
[07:45:55] <ietfdbh2> sharon suggested analyzing proposals versus requirements.
[07:46:25] <rstory> uri: another security model obtains key material and negotiates properties for the session.
[07:46:43] <rstory> juergen: still don't understand
[07:47:16] <rstory> uri: assumtions current usm security sorta like ipsec w/manual keys. people want automated keys, and automation to use existing infrastructure.
[07:47:38] <rstory> uri: need something like ike for snmp, a module that uses exiting credentials, and use those for authentaication
[07:48:07] <rstory> hartmans: how is that withing scope of using encapsulation keying? we've already decided on encapsulation..
[07:48:57] <rstory> uri: current model is missing session framework and mapping to access control, doesn't require transport decision [not sure if i understand uri's idea]
[07:49:22] <rstory> getting ready to hum on datagram support necessary
[07:49:32] <rstory> result: near silence
[07:49:36] <ietfdbh2> We don't need datagram transport for "our" solution because it already exists independent of our solution.
[07:49:39] <rstory> who says we need it?
[07:50:00] <rstory> juergen: can we eliminate dtls? don't have solid base for underlying protocols
[07:50:17] <rstory> juergen: no operation experience..
[07:50:18] <ietfdbh2> Who suubmitted a proposal for DTLS?
[07:51:28] <hardaker> hmmmmm (if not too late)
[07:51:40] <hardaker> not because I know it's needed, but because I don't know if it's not.
[07:51:48] <rstory> (missed name): snmp most used below application level? netowrk devices use telnet, moving to ssh, so lots of them already have ssh build in
[07:52:06] <rstory> hardaker: too late, i think dtls is gone
[07:52:11] <kenh> (That was chris newmann)
[07:52:20] <kenh> Hm, did we just lose audio?
[07:52:25] <hardaker> no
[07:52:32] <ietfdbh2> no
[07:52:47] <kenh> Hm, problem at my end, but it's fixed now.
[07:52:51] --- Margaret has become available
[07:52:54] <rstory> chris: tls/sasl may be more useful for applications, ssh for lower levels
[07:53:19] <rstory> elliot: counter argument: i want call-home functionality, which isn't in ssh today
[07:53:27] <kenh> (Louder, elliott, please?)
[07:53:30] <ietfdbh2> Why don't we encourage people to write proposals for various solutions, and then compare them ratjher than tryig to eliminate options befiore we;ve seen any proposals.
[07:53:57] <rstory> hartmans: let's discuss if call-home needed, or if persistent connections sufficient?
[07:54:23] <rstory> elliot: times when you can't have persistent connection, eg firewall, so want to have device connect
[07:54:58] <rstory> hartmans: ssh supports call home, auth mechanims are asymmetric, some where call home might have to use different machinism
[07:55:05] <jhutz> Because if you can decide what you need, and which approaches are best suited to that, then you can focus efforts on developing the approaches that are needed, instead of developing every approach.
[07:55:41] <rstory> randy: call home is essential. 1) notifications (eg to offline manager, which may have never connected to node)
[07:56:03] <rstory> sharon: is this a new requirement? not in snmp paradigm,
[07:56:34] <rstory> sharon: could be dos attack, lots of things we need to think about,
[07:57:34] <rstory> hartmans: is call home enough; an agent wanting to send notification, open ssh connection to server, authenticate, then send notification
[07:58:27] --- bert has left
[07:58:28] <rstory> elliot: 2 aspects to snmp. 1)get/response, 2)notification. all call home is, optionally element initiate connection to manager, and things get tunnel on tcp connection. direction could be anything, once connection is up
[07:59:12] <rstory> hartmans: ssh supports this today, authentaction mechanisms asymmetric.
[07:59:14] --- bert has become available
[07:59:33] <rstory> elliot: need to develop more on that point
[08:00:06] <rstory> chris: distinction between tls/sasl + beep is ability to do channel multiplexing over single connection
[08:00:18] <rstory> chris: if don't need multiplexing, x86 beep
[08:00:26] <hartmans> For example, the person to whom the connection is opened cannot use a password for authentication in ssh
[08:00:38] <rstory> uri: multiplexing expensive
[08:01:06] <rstory> elliot: also get framing; good case for multiplexing is also using netconf/syslog over the same connection.
[08:01:38] <ietfdbh2> the downside of sharing a security association is having a single point of failure.
[08:01:56] <hardaker> netconf chose beep as optional. betting on the fact that you can share a netconf/beep session with SNMP before netconf is deployed fully with an optional sub-module seems really really odd.
[08:01:56] <jhutz> Sam, such a keyex could be written, but I don't think you'd want to. Isn't the thing that would receiving the connection going to be not an interactive user anyway?
[08:02:04] <rstory> elliot: benefit of sharing: same authentication method, second (potentially) is weaker (sharing w/lot of data)
[08:02:29] <rstory> glen: back to ssh vs beep, netconf requires ssh. why use beep here?
[08:02:48] <jhutz> Note that ssh also supports multiplexing multiple channels over a single connection.
[08:02:56] <rstory> eric: you know if you are agent/manager, right?
[08:03:01] <rstory> group: no
[08:03:09] <rstory> davep: really you do know
[08:03:27] <rstory> randy: some entities are both, need to support this
[08:03:28] <jhutz> In fact, I'd have to reread the docs to be sure, but I don't think there's anything in ssh that prevents the ssh server from establishing a new channel on an existing connection.
[08:04:01] <rstory> uri: agree, dual role entity may have dual identities as well
[08:04:33] <rstory> randy: snmp envisions using single engine (disman/rmon mibs, underlying model using single engine)
[08:04:54] --- nico has become available
[08:05:01] <rstory> randy: applications know what role they are, engine is lower level
[08:05:37] <rstory> davep: majority of snmp is not dual role. each app has copy of lib, with multiple engines on a workstation
[08:05:50] <rstory> davep: managed device is one engine, the agent
[08:06:43] <hartmans> Can someone proxy jhutz's remarks if they believe that would be helpful?
[08:06:51] <hartmans> Real name is Jeff Hutzelman
[08:06:54] <rstory> eric: ally systems are inheritently asymmetrical, it is clear who is server vs manager
[08:07:12] <rstory> s/ally/all/
[08:07:51] <rstory> eric: other ways to send information, w/out using beep channel multiplexing
[08:08:37] <rstory> eric: can other proposals do the same thing. eg establish connection in both connections, same/different credentials
[08:09:18] <rstory> bert: didn't want to charter group like this in my area,
[08:09:32] <hartmans> wait, doesn't ssh support multiplexing too?
[08:09:56] <rstory> bert: initially form security group w/differnent proposals, but operators weren't happy, wanted to use existing infrastructure
[08:10:22] <rstory> bert: operators said we use ssh a lot, which is why netconf uses it
[08:10:44] <rstory> bert: beep not in current infrastructure. comments from operators? not hearing from them...
[08:11:15] <rstory> bert: a factor that should weigh heavily: what are operators using, and what would help them most
[08:11:24] <hardaker> thats why I conducted that survey.....
[08:11:33] <hardaker> though I didn't ask about beep
[08:11:42] <rstory> glen: don't want to rehash netconf ssh discussions
[08:11:46] <ietfdbh2> Can somebody relay this please? I would liek to see proposals for SSH, TLS, and SASL so we can see whether each is feasible and what problmes arise.
[08:11:50] <nico> sigh
[08:12:14] <rstory> glen: interactive ssh is different than netconf/monitoring
[08:12:40] <rstory> bert: can they use existing infrastructure? beep not deployed?
[08:12:40] <jhutz> Yes, ssh supports multiple channels with independent windowing.
[08:13:08] --- pigdog has become available
[08:13:10] <rstory> glen: do we need multiple stacks in devices?
[08:13:13] <jhutz> And most ssh implementations support those features, because you need them for X11 and TCP forwarding
[08:13:18] <rstory> bert: exactly.
[08:13:27] <nico> SSH does multiplexing and has flexible userauth; the key exchange part, where the host key goes in, is only slgithly problematic for the notifications thing, but notifications could be sent unprotected and carry very little data, merely letting the client know it has to call into the device
[08:13:42] <rstory> glen: real question: we dont' want to be managing multiple sets of authentication data..
[08:14:14] <rstory> glen: don't care what is it, if goal is merging authentication parameter, we've sovled that problem
[08:14:17] <nico> the assymertic authentication mechanism problem comes up elsewhere (e.g., NFSv4)
[08:14:29] <rstory> glen: secondary issue is code size in devices, etc
[08:14:56] <nico> ssh can be quite small if you don't implement the bits you don't need
[08:15:17] <hardaker> there still isn't a libssh for other apps to use yet right (OSS)?
[08:15:18] <rstory> ruediger?: don't care how many stacks in a box, but if lots are needed, the box might cost me more
[08:16:23] <jhutz> Sorry; I don't know the right terms for this in ISMS, but... I'm not sure this is a good idea, but I expect you could deal with notification by having the thing doing the notification start a TCP connection, and then running the ssh protocol in the opposite direction, with the server/tcp-initiator as the ssh server
[08:16:23] <nico> there's Perl5 and Java SSH libraries
[08:16:25] <rstory> reudiger: not much infrastructure for using snmp over other things (?not sure i got the comment right)
[08:16:41] <hardaker> nico: but no straight code yet? bummer.
[08:16:52] <nico> jhutz: just send a UDP "call me" datagram
[08:17:00] <jhutz> Or you could do that.
[08:17:11] <nico> hardaker: wht do you mean "straight code"?? C?
[08:17:21] <rstory> randy: multiple infrastructure discussion focusing on security protocol between systems, slighting "AAA" mechanims in use on existing infrastructure
[08:17:26] <kenh> You mean, something exactly like the existing trap/notification mechanism? :-)
[08:17:31] <hardaker> yes or C++ or something linkable that isn't java/perl
[08:17:33] <jhutz> It is common for applications built on ssh to run a normal ssh client in a separate process, connected by a pipe. scp and sftp do this, for example
[08:17:43] <rstory> randy: missing key point of integration. no matter which protocol, implementation need to hook into existing infrastructure
[08:18:40] <rstory> elliot: i agree, an issue is more details of groups and group mappings. what do we need to do with the ASI? not covered in any of the drafts
[08:18:45] <jhutz> I don't know of implementations that let you do that _and_ make useful use of multiple channels, though. And really, I wouldn't mind seeing an ssh library, or if that happened as a result of isms deciding to go that direction
[08:18:56] <rstory> elliot: none of the protocols are complete in this respect
[08:19:16] <rstory> juergen: may operators using ssh for trouble shooting, it is an essential tool.
[08:19:21] <nico> if it's Java you can probably port it to C++
[08:19:45] <rstory> juergen: i don't see if we decide on something else, will operators move away from ssh? i don't think so
[08:20:11] <rstory> other juergen: requirement is that solution must integrate with ssh. simplest way is to use ssh
[08:20:18] <nico> right, ssh is here to stay
[08:20:53] <pigdog> dave, please repeat your question
[08:21:02] <rstory> hartmans: not getting jabber comments relayed
[08:21:17] <rstory> can outstanding jabber comments re-ask them?
[08:21:35] <hardaker> they're too old at this point ;-)
[08:21:42] <nico> sure: why not have a trivial notification mechanism that says "call me"
[08:21:48] <nico> to resolve the assymetry problem
[08:21:54] <ietfdbh2> I would liek to see proposals for SSH, TLS, and SASL so we can see whether each is feasible and what problmes arise.
[08:21:56] <jhutz> I don't believe I have any outstanding questions. And since I'm in another session, I'm not using the audio
[08:22:06] <rstory> simon: reality ssh auth is username/password
[08:22:13] <nico> also, a new ssh keyex hostkey alg can be added if need be to deal with users-as-servers
[08:22:20] <jhutz> who made that claim?
[08:22:28] <nico> plus, won't systems receiving notifications be servers anyways?
[08:22:37] <nico> those are *my* questions
[08:22:47] <jhutz> nico, don't promise that so lightly; it's not trivial
[08:23:25] <kenh> jhutz: I believe that person was talking about the network management world (username/password backed by RADIUS server), not necessarily the generic SSH universe.
[08:23:27] <ietfdbh2> oh, I would also like to proposals to see whether we have the editors willing to work.
[08:23:39] <jhutz> OK. I'll buy that argument in that context
[08:24:19] <rstory> elliot: nico: trivial notification for call-home: send text; firewall need to be dealt with, esp with overlapping administation domains
[08:24:44] <rstory> elliot: agree with daveh, we need proposal develop further. even my own draft needs works
[08:24:47] <nico> simon: reality is users use publickey too
[08:25:04] <rstory> elliot: could send text via ssh, yes
[08:25:21] <nico> eilliot: sure, ALL notifications will have to deal with firewalls
[08:25:22] <rstory> more answers, questions?
[08:25:30] <nico> and if you pass ssh everywhere
[08:25:37] <nico> then you basically have no firewall
[08:25:43] <ietfdbh2> please relay: oh, I would also like to proposals to see whether we have the editors willing to work.
[08:25:44] <pigdog> nico: use of a TCP stream can mitigate firewall problems
[08:26:24] <rstory> juregen: netconf had 3 solutions, we could do the same, but might be a waste of resources
[08:27:03] <rstory> juergen: (not as chair) don't like idea of developing several in parallel
[08:27:12] <nico> jhutz: I think a no-host key hostkey alg for ssh can be trivially added, yes
[08:27:38] <rstory> eliot: proposals are not ready enough this choice, haven't resovled ASI problems discussed on list. way to early
[08:27:48] --- Margaret has left
[08:27:55] <rstory> elliot: need editors, or won't make any progress
[08:28:20] <nico> for what? ISMS over SSH?
[08:28:30] <pigdog> yes
[08:28:34] <ietfdbh2> so let's raise the question: who's willing to commit to editing proposals for various solutions?
[08:28:34] <rstory> dave nelson: another criteria, besides existing infrastructure: haven't talked about other parts of infrastructure that need to change (eg applications)
[08:29:01] <nico> BTW, that's one problem with using SSH or anything that multiplexes -- firewall admins may not like letting through such animals
[08:29:11] <nico> an argument for SASL/TLS perhaps?
[08:29:25] <nico> presumably GSS is dead here due to lack of mechs
[08:29:29] <nico> :^/
[08:29:31] <pigdog> nico: that's true.
[08:29:35] <rstory> daven: ssh is usually person typing/scripting. using snmp is usually gui based. should we consider how that impacts existing managment application? if difficult, we haven't gained anything
[08:29:48] --- jsalowey has become available
[08:29:58] <hartmans> Or we can have a snmp port as netconf did.
[08:30:29] <rstory> juergen s: applications over ssh, instead of using public community, give username (if not same as ID), maybe password (if public key not installed)
[08:30:30] <hardaker> Practically all of my users use SNMP for mostly scripting.
[08:30:53] <jhutz> nico, we'll talk about that offline
[08:31:40] <bert> I think the IAB workshop also reported that operators use scripting for their management
[08:31:41] <rstory> elliot: if multiplexing, drafts need to talk about them, and related firewall issues
[08:32:02] <nico> pls -- ssh can be used non-interactively
[08:32:06] <nico> no FUD pls
[08:32:11] <rstory> elliot: netconf uses ssh on different port, for firewall issues (one reason, anyways)
[08:32:18] <jhutz> either a sasl-based solution or an ssh-based solution will allow use of any gss mech
[08:32:23] <jhutz> well, almost any
[08:32:52] <rstory> juergen: hands on each remaining proposal (all but dtls), just for a rough idea:
[08:33:03] <rstory> first: tls+sasl, hands?
[08:33:04] <nico> jhutz: let's talk about that offline
[08:33:06] <nico> :)
[08:33:15] <nico> I raise mine
[08:33:19] <nico> hum
[08:33:25] <jhutz> > ssh is usually person typing/scripting Not always. ssh is perfectly capable of being scripted, and it is also perfectlty capable of carrying binary protocols. sftp does this and it works just fine
[08:33:31] <kenh> (raising hand for TLS+SASL)
[08:33:46] <ietfdbh2> WHO's WILLING TO EDIT?
[08:33:47] <nico> please relay my hum for sasl/tls
[08:33:51] <rstory> ~ 5
[08:33:59] <rstory> now ssh:
[08:34:00] <nico> and for GSS (if that's even asked)
[08:34:02] <nico> and for ssh
[08:34:04] <nico> :)
[08:34:04] <rstory> lots of hands
[08:34:09] <rstory> now beep:
[08:34:11] <kenh> (Raise hand for SSH as well)
[08:34:20] <jhutz> are these hands of people supporting the suggestion, or people willing to work on it?
[08:34:23] <rstory> ~ 7
[08:34:34] <rstory> jhutz: supporting
[08:34:41] <hartmans> supporting
[08:34:56] <nico> no beep
[08:35:00] <nico> beep no
[08:35:01] <jhutz> fine; I'll hum on any of tls+sasl, ssh, gss,
[08:35:19] <rstory> ok, contributors for tls+sasl:
[08:35:25] <nico> I second jhutz question
[08:35:27] <rstory> not really
[08:35:41] <rstory> for ssh: ~ 1
[08:35:52] <rstory> beep: elliot
[08:36:11] <jhutz> who volunteered to work on ssh?
[08:36:17] <rstory> any jabber volunteers for contributations?
[08:36:24] <ietfdbh2> I am willing to help the editors understand the architecture issues.
[08:36:32] <rstory> now asking about reviewers
[08:36:41] <hardaker> I'll review them all
[08:36:57] <rstory> several hands, ~7 for that
[08:36:58] <ietfdbh2> I'll review them all for architecture issues.
[08:37:25] <jhutz> I'll be happy to review any of the approachs discussed.
[08:37:37] <jhutz> I can help with ssh issues, but I cannot commit the time to edit
[08:37:41] <rstory> juergen: maybe, do we want to go for one, or multiple solutions (eg required + optional)
[08:37:55] <nico> I'll review
[08:38:08] <rstory> sharon: netconf is different, so multiple was ok. not sure if makes sense for snmp
[08:38:37] <rstory> elliot: hard to say i'll implement a protocol, when there isn't a protocol fully defined
[08:38:41] <jhutz> I would suggest that if one suggestion is far more popular than others, and the others don't have anyone willing to contribute/edit, then maybe they don't need to be specified.
[08:38:47] <rstory> elliot: would prefer single solution
[08:39:16] <jhutz> (OK, I guess only some of the others don't have any volunteers)
[08:39:34] <rstory> hartmans: as AD, i would like (but not require) for WG to focus on 1 solution initially. if need more later, it's ok if based on demand rather than 'we couldn't decide'
[08:40:03] <rstory> randy: prefer 1 solution, need to look at AAA servers which are already integrated to infrastructure
[08:40:34] <hardaker> can we consider two, one for each transport? I'm not sure we should force just one if it means we have to dump one of the two transports.
[08:41:03] <nico> BEEP uses SASL, yes?
[08:41:04] <jhutz> I wonder how common it is for existing AAA infrastructures to have something challenge/response based, rather than a simple password (such that you could use ssh keyboard-interactive but not SASL PLAIN)
[08:41:11] <rstory> elliot: propose, if we converge that we do so by next meeting
[08:41:27] <rstory> hartmans: no, charters says end of Aug, I don't want to change it
[08:42:15] <ietfdbh2> please relay: we need editors who understand SSH (etc) from the security side, not justthe snmp side.
[08:42:20] <nico> but you could always make a SASL mech that does interactive
[08:42:25] <rstory> elliot: contigent for ssh, but no draft.. willing to wait for draft, but a draft so soon might not work with such a short time-frame
[08:42:28] <nico> fine
[08:42:31] <jhutz> Neither sasl+tls nor ssh is going to work over UDP. I don't know anything about DTLS. Something GSS-based could be built on UDP, but would require supporting multiple round trips for context establishment in order to be general to arbitrary mechanisms.
[08:42:33] <nico> I can write text
[08:42:38] <nico> I won't format
[08:42:52] <nico> I need to be paired with someone who will and then I'll provide text for a -00
[08:42:53] <hardaker> I can format your text ;-)
[08:43:06] <nico> if that can get things going, great
[08:43:20] <nico> if you need an editor who will take it all the way, I'm not going to be it
[08:43:23] <nico> please relay
[08:43:25] <jhutz> I can help with design of an SSH solution, and probably provide some text, but I can't be primary editor
[08:43:44] <jhutz> I don't recall whether BEEP over UDP is defined.
[08:43:46] <hartmans> Nico, you don't have time to edit something here.
[08:43:50] <hartmans> Or really even be involved.
[08:44:03] <nico> I don't want BEEP though
[08:44:09] <nico> :)
[08:44:13] <ietfdbh2> I'm fine with doing the xml2rfc work, but I need a security person to provide the text.
[08:44:22] <rstory> juergen: getting closer..
[08:44:41] <nico> but you're right, I can't edit -- I'm not offering to
[08:44:46] <rstory> juergen: looks like it will be 1, majority seems to be for ssh
[08:44:59] <kenh> It seems like we've got nico and/or jhutz who can provide security text, and wes and david can be primary editors.
[08:45:10] <rstory> hartmans: asking from hum on extenting til next meeting would be a good idea
[08:45:10] <ietfdbh2> microphon eplease!!!
[08:45:14] <rstory> (not that he'll approves
[08:45:24] <hardaker> hummmmm
[08:45:30] <ietfdbh2> NO!!! let's get a proposal started.
[08:45:36] <nico> hummmmm
[08:45:37] <rstory> against hums seems, just slight louder
[08:45:56] <hardaker> it would get proposals started, just not define which is the must until we actually get a draft to go froward with.
[08:45:59] <jhutz> If you can't tell which hum is louder, you don't have a consensus either way
[08:46:02] <rstory> juergen: do we need to wait
[08:46:16] <rstory> hartmans: NO NO NO, just wanted opinion on elliots proposal
[08:46:28] <rstory> hartmans: not encouring you to wait
[08:46:29] <hardaker> if we're sure drafts will be written for what we want, then deciding now is fine...
[08:46:46] <rstory> elliot: we dont' have documents, if we can get them out in time, i don't think we can
[08:47:04] <jhutz> What proposal did elliot make?
[08:47:07] <rstory> juergen s: not sure if saying no text on ssh is true
[08:47:19] <rstory> jhutz: more time (til vancouver to decide)
[08:47:37] <rstory> jhutz: current charter says end of august
[08:47:45] <rstory> elliot: need text, i'll even help
[08:47:49] <jhutz> I have no opinion on that question
[08:48:07] <rstory> sharon: if there ssh stuff in tls draft, might help to flush that out
[08:48:29] <rstory> juergen: rough concensus, ssh, shape charter. Sam, ok?
[08:48:41] <rstory> hartmans: charter next week is ok, must be done by end of august
[08:48:46] <ietfdbh2> I'm willing to work on fleshing out the SSH portion of TMSM IFFFF somebody with knowledge of SSH helps craft the text.
[08:48:54] <rstory> juergen: can so something quickly
[08:49:16] <nico> ietfdbh2: jhutz has said he could help, and so can I
[08:49:24] <nico> I can send you .xml I-D templates
[08:49:27] <nico> instructions
[08:49:38] <nico> if you don't know how to format I-Ds
[08:49:45] <rstory> juergen: no time for charter discussion, only 10 min left, so move to mailing list
[08:50:07] <rstory> juergen: have ssh volunteers for isms, lets wait for charter, then start work
[08:50:12] <ietfdbh2> Add one item to the charter: do an SSH proposal and ick a dealine.
[08:50:18] <jhutz> "recharter to include publication goals" sounds like setting more milestones, no?
[08:50:47] <rstory> hartmans: no, start work now, someone might object to charter, but better off start working now. but high chance of being approved, don't want to lose momentum
[08:51:00] <jhutz> ==hartmans
[08:51:09] <nico> ietfdbh2: send jhutz, me, e-mail
[08:51:09] <ietfdbh2> Who is willing to be the security-side co-editor for an SSH document?
[08:51:25] <nico> read above
[08:52:06] <jhutz> jhutz@cmu.edu, Nicolas.Williams@sun.com
[08:52:14] <rstory> bert: happy with this decision. extending to vancouver not an idea i like, not enough text on ssh, maybe a interim in sept
[08:52:26] <rstory> hartmans: but if we can decide today, that's better, and i think we have
[08:52:27] <nico> give us a short intro
[08:52:39] <rstory> juergen: also don't think we need to
[08:53:01] <rstory> elliot (mumbling about making decsion w/out a document)
[08:53:16] <hartmans> jhutz: No, charter excludes protocol work
[08:53:21] <rstory> bert: need to work hard on this, with such a short deadline.. need REAL effort
[08:53:54] <rstory> juergen: would we decide differently if we had an interim?
[08:54:09] <rstory> hartmans: do you want ssh draft by aug? i think they only need to decide on direction
[08:54:09] <nico> nfsv4 wg is finished
[08:54:11] <nico> almost
[08:54:19] <nico> er, with this meeting, that is :)
[08:54:26] <rstory> bert: if no write, more text by interim might help
[08:54:39] <jhutz> My reading of the charter is that there needs to be only consensus on a direction
[08:54:42] <ietfdbh2> I am willing to try to get a draft written by the end of August if co-editors are available.
[08:54:57] <rstory> hartmans: lots of jabber volunteers, this is good
[08:55:16] <jschoenwae@jabber.org> I was the one who volunteered during the session.
[08:55:39] <rstory> elliot: not sure of formal iterim, juergen and i are in europe, i can host gathering or travel to discuss state of draft, etc, if useful
[08:55:56] <rstory> elliot: real bits(text) are important
[08:56:02] <jhutz> I can be available to work on a document. No way I can make an interim.
[08:56:17] <ietfdbh2> I'm unemployed so an interim is a burden for me.
[08:56:48] <rstory> juergen: formalize discussion on mailing list, decide if interim needing
[08:56:56] --- pigdog has left
[08:57:05] --- jsalowey has left
[08:57:09] <rstory> juergen: thanks everyone, glad to have made a decision for direction.
[08:57:15] --- hartmans has left
[08:57:17] <rstory> TRANSCRIPT END
[08:57:23] --- mike has left
[08:57:27] <kenh> A decision! Hooray!
[08:57:41] --- jschoenwae@jabber.org has left: Logged out
[08:59:01] --- nico has left
[08:59:30] --- mstjohns has left
[08:59:55] --- ietfdbh2 has left
[09:00:52] --- rstory has left: Logged out
[09:03:53] --- bert has left
[09:04:08] --- jhutz has left
[09:26:07] --- mstjohns has become available
[09:35:31] --- mstjohns has left
[09:46:02] --- kenh has left: Disconnected
[09:50:19] --- bert has become available
[09:52:53] --- bert has left
[10:57:33] --- hardaker has left: Disconnected.