[14:34:59] --- Dave Nelson has become available
[15:00:16] --- rstory has become available
[15:05:22] --- jschoenwae@jabber.org has become available
[15:05:34] --- bert has become available
[15:07:16] --- hartmans has become available
[15:08:41] --- jschoenwae@jabber.org has left
[15:10:21] <bert> Rstory are you hear or remote?
[15:10:34] <bert> and can Dave and you hear the audio
[15:11:12] <bert> we have no jabber scribe, but I can relay any questions you may have and post here
[15:11:34] <rstory> remote, til i finish my lunch..
[15:12:06] <Dave Nelson> I'm listening to the streaming audio.
[15:12:10] --- Roy Brabson has become available
[15:12:13] <rstory> i can scribe in about 5 minutes..
[15:12:14] --- jschoenwae@jabber.org has become available
[15:12:21] --- Roy Brabson has left
[15:12:21] <bert> great
[15:12:25] <Dave Nelson> Yes, I'm listening to the streaming audio,
[15:15:35] <Dave Nelson> Hi, Dave. :-)
[15:15:40] <jschoenwae@jabber.org> dave reports from the radext meeting
[15:16:10] <jschoenwae@jabber.org> radext likes to know the exact requirements we have
[15:16:33] <jschoenwae@jabber.org> radext is behind deadlines and thus it might be difficult to accept new work
[15:17:04] --- Eliot Lear has become available
[15:19:37] <jschoenwae@jabber.org> dave starts talking about the issues list
[15:19:44] <jschoenwae@jabber.org> slides are on the meeting web page
[15:20:22] <jschoenwae@jabber.org> https://onsite.ietf.org/proceedings/05nov/
[15:21:04] <rstory> issue #2 from the list: sshsm vs ssh
[15:21:49] <rstory> eliot: 2 is something snmp may demand from ssh, but we shouldn't break abstraction
[15:21:56] <rstory> eliot: not a wg problem
[15:22:29] <rstory> jeff h: how we learn host public key is the 1 part we do want to consider here. agree don't want to break abstraction
[15:22:59] <rstory> jeff h: how do you know that you have the right host key? in ssh, you need to know in advance..
[15:23:46] <rstory> eliot: response: ssh requires leap of faith for 1st transaction to get host key.
[15:24:06] <rstory> eliot: what if it wasn't just a host key? what if it was x.509 cert? shouldn't care.
[15:25:24] <rstory> bill s: ssh wg chair. some extensions might make leap of faith less of an issue.. eg x.509 work going on, gssappi
[15:25:40] <rstory> bill s: don't avoid leap of faith in this wg, other ways
[15:26:20] <rstory> uri: yes, need to bind the key. if don't have clear relationship and engineid/host, what do to if there are multiple snmp agents?
[15:26:31] <rstory> uri: multiple agents share ssh session?
[15:27:16] <rstory> eric f: appreciate what eliot said. don't want to push back, but want to point out other side: isms vs usm, we have make multiple auth methods possible
[15:28:01] <rstory> eric f: want vendor interoperability re auth mechanism. need on MUST implement
[15:28:19] --- nico has become available
[15:28:20] <rstory> jeff: relaying sam, ssh has mandatory to implement
[15:28:58] <rstory> jeff: leap of faith is not ssh protocol issue. ways to avoid it. eg using key distro out of band
[15:29:29] <rstory> jeff: don't want public key for every agent, as some might not use public key. need to talk about it here
[15:29:37] <rstory> eliot: in isms?
[15:30:15] <rstory> david p: operationally, a big part of ssh is the file w/public keys and ip addr/dns name
[15:30:17] --- mstjohns has become available
[15:30:48] <rstory> david p: if i get sw from one vendor, then another software vendor, don't want multiple leaps of faith.
[15:31:12] <rstory> david p: ssh key caches don't associate key w/port#, just ip addr/name
[15:31:37] <rstory> moving on to issue #8: mapping between ssh key and engine id
[15:32:16] <rstory> sam h: written about this on the list
[15:32:34] <rstory> david h: but no consensus
[15:33:40] <rstory> js: backing up to #2
[15:34:19] <rstory> eliot: state in document concerns, but not as normative test... "thing about this. it needs to be solved (somewhere)"
[15:34:27] <rstory> js: eg note in security considerations
[15:34:32] <rstory> elito: yes
[15:34:46] <rstory> jeff: particularly 2c
[15:35:03] <rstory> js: consensus?
[15:35:09] <rstory> room: light humming
[15:35:19] <rstory> david h: against?
[15:35:26] <rstory> room: <crickets>
[15:35:57] <rstory> david h: 2a) ?
[15:36:11] <rstory> oops, that was 2b
[15:36:18] <rstory> jeff: 2b part of ssh protocol
[15:36:52] <rstory> jeff: 2a = does snmp sometimes/always care about server identity?
[15:37:17] <rstory> jeff: if we care, advice for 2c is important for people to heed
[15:38:27] --- bclaise has become available
[15:38:36] <rstory> sam h: i think answer is yes, but ssh already does this. no need to add more.
[15:38:51] <rstory> sam h: no need to do more than other ssh implementations
[15:38:56] <Dave Nelson> One question is whether the server identity is ultimately verified by the user authentication sucess?
[15:39:17] --- Roy Brabson has become available
[15:39:53] <rstory> sam h: in general no. most ssh user auth do not verify server id.
[15:40:25] <rstory> js: so do nothing about 2a
[15:40:40] <rstory> js on to #8, mapping ssh key to engine id
[15:41:14] <rstory> wes: be consistent about 'engineID'.. we're talking about context engineID
[15:41:38] <rstory> wes: mapping between ssh key and engineID happens at mgmt station, we don't need to standardize
[15:41:47] <rstory> wes: like ssh maps keys to ip addresses
[15:41:54] <rstory> sam: ick
[15:42:18] <rstory> same: don't think ssh map key to ip addr
[15:42:25] <rstory> wes: clients do that
[15:43:04] <rstory> sam: consider if you want to use stock ssh. disadvantage to that approach is that ssh impl must export key
[15:43:35] <rstory> sam: other disadvantage is that it is key exchange mechanism dependent
[15:43:49] <rstory> sam: ssh docs bind user entered name to an identity
[15:44:18] <rstory> sam: questions to wg: do you want to add something on top of that, or use stock ssh implementations
[15:44:45] <rstory> sam: also, method is asymmetric
[15:44:59] <rstory> wes: we don't need to mandate, security considerations again
[15:45:34] <rstory> sam: re interoperability, what are you going to put on acls?
[15:45:42] --- mstjohns has left
[15:46:49] <rstory> wes+sam+jeff: notification side bar
[15:47:20] <rstory> wes: recipient acts on notifications.. need acls
[15:47:41] <rstory> joseph: whole lot of keys in ssh.. be specific, think we're talking about host keys
[15:47:58] <rstory> jeff: ssh doesn't have engineid
[15:48:50] <rstory> jeff: maybe right thing is, given contextengineId, map to ssh host name/ip addr?
[15:49:03] <rstory> jeff: need to know host in advance
[15:49:32] <rstory> david p: getting confused. if ssh connection to proxy, contextEngineID tells proxy who to proxy to
[15:49:44] <rstory> david p: why do i need mapping to ssh key
[15:50:10] <rstory> david h: history: can one ssh server serve 2 engineIds
[15:50:50] <rstory> joseph: if have same ssh connection w/multiple engineids, probably want different channels.. map at that level.. or diff subsystems
[15:51:05] <rstory> jeff: still have to map snmp id to ssh host authentication
[15:51:31] <rstory> eliot: propose: until someone shows example that we need mapping, leave it out.
[15:51:45] <rstory> bill s: yeah, what he said
[15:51:49] <nico> so, use SSHv2 for its key exchange, node authentication, user authentication, then in the ISMS subsystem/channel type use a protocol that asserts/requests specifici engine IDs, does any additional authentication, if any, or authorizes SSHv2-authenticated entities to the engine ID
[15:52:37] <rstory> bill s: if single ssh server w/key serving multiple engine ids, and using leap of faith, building engineid to key mapping overtime. same key for multiple engine ids wont be a problem. note: not a snmp expert either
[15:53:27] <rstory> jeff: need mapping in reverse direction
[15:54:01] <rstory> jeff: need mapping to ssh svr you want to talk to
[15:54:24] <rstory> jeff: sometimes MUST have service name
[15:54:50] <rstory> david p: most mgmt platforms don't deal w/engine ids
[15:55:00] <rstory> david p: only need it for proxies
[15:55:36] <rstory> david h: do security engine id discovery..
[15:55:41] <nico> (btw, I'm participating from NFSv4)
[15:55:48] <rstory> david p: code needs both, assumes same
[15:56:09] <rstory> [ed] nick: i waiting for the mic to relay your comment
[15:56:16] <rstory> s/nick/nico/
[15:56:52] <rstory> david p: try to solve problem infrastructure doesn't support
[15:57:01] <rstory> david h: have to follow charter
[15:57:47] <nico> my comment doesn't make the mapping issue go away
[15:57:50] <nico> :/
[15:58:06] <rstory> david p: very simple solution; engineid means system that i'm talking to
[15:59:23] --- Yoshifumi Atarashi has become available
[15:59:46] <rstory> jeff: propose might not need mapping between key/engine id. mapping between ssh host id and what snmp layer knows in advance about the host you want to talk too
[15:59:53] <rstory> s/too/to/
[16:01:03] <rstory> js: seems issue isn't resolved.. discuss on list
[16:01:43] --- nico has left
[16:02:02] <rstory> on to #12a: how does sshsm determine if ssh can provide services requeste in snmp msgFlags (eg auth/priv)
[16:02:07] --- nico has become available
[16:02:19] <rstory> sam: auth is closer to integrity in this context
[16:02:23] <rstory> room: huh?
[16:02:32] <rstory> sam: auth of contents
[16:02:39] <rstory> room: no, both
[16:02:45] <rstory> sam: in usm, it does both
[16:02:58] <Dave Nelson> Authenticity of the originator.
[16:03:04] <rstory> sam: assume ssh is providing all of the above
[16:04:27] --- abierman has become available
[16:04:42] <rstory> eliot: want to talk about c: q for security area: how is this handled elsewhere (legality of encryption)
[16:05:25] <rstory> bill s: in general, my understanding (as vendor shipping crypto) is that a few countries where there are key issues, but not something they had to cope w/in current products
[16:05:56] <rstory> eliot: ok, ignore c, part b: can we leave it to ssh?
[16:06:20] <rstory> eliot: as long a min/max security is met
[16:06:30] <rstory> jeff: to bill: state of null cipher?
[16:06:34] <rstory> bill s: still there
[16:06:54] <rstory> sam: encourage folks to read rfc 1984
[16:07:12] <rstory> sam: argue that site selecting null did so intentionally, so let them
[16:07:33] <rstory> sam: that was person opinion
[16:07:50] <rstory> jeff: can ssh provide no encryption?
[16:08:14] <rstory> joseph/jeff: if you don't want encryption, don't use ssh
[16:09:32] <rstory> rstory: allow multiple levels
[16:09:47] <rstory> bert: lots of info doesn't need encryption, thus noauth noprive
[16:09:53] --- psavola has become available
[16:10:34] <rstory> both should be options
[16:11:59] <rstory> jeff: abstraction level violation..
[16:12:13] <rstory> david h: i think should use authPriv for all.. take to mailing list
[16:12:31] <rstory> on to 13: keychange impact
[16:12:45] <rstory> jeff: host keys only used when setting up session
[16:12:50] <rstory> jospeh: and rekey
[16:13:17] <rstory> jeff: to bill s: what happens when ssh clients hostkey changes during session and then have a rekey
[16:13:27] <rstory> wes: regardless, should be transparent to isms
[16:13:52] <nico> update mappings
[16:13:53] <nico> ?
[16:13:53] <rstory> bill s: re has it been considered in ssh wg, not to my knowledge
[16:14:22] <rstory> [ed] nico: can you clarify what you want me to relay?
[16:14:23] <nico> I think a client would be free to update its mappings
[16:14:40] <nico> I'm responding to the hostkey change in re-key
[16:15:15] <rstory> josepf: transport is there or not.
[16:15:53] <rstory> david h: diff between request/response
[16:15:59] <rstory> wes: should drop
[16:17:03] <rstory> joseph: client has mapping host a/key b... client can decide to update key or disconnect
[16:17:21] <rstory> david h: will discard
[16:17:32] <rstory> on to 14
[16:17:34] <rstory> room: yes
[16:17:53] <rstory> on to 15: what is stored in state reference, and how to get it from ssh
[16:19:03] <rstory> david h: take to list
[16:19:49] <rstory> on to 16: SSH_MSG-USERAUTH_REQUEST may return different name
[16:20:26] <rstory> joseph: server may accept name, or send back methods that might authenticate that user.
[16:20:53] <rstory> joseph: don't send back username/lists... this is a non-issue
[16:21:22] <rstory> joseph: methods eg none, gssapi, password interactive, etc
[16:22:38] <rstory> joseph: explaining ssh auth a bit more
[16:24:40] <rstory> sam: user accepted by ssh is what you use
[16:25:57] <rstory> jeff: enumerating multiple methods now is ok, but shouldn't be enumerated in final document
[16:26:28] <rstory> joseph: ssh auth method doesn't matter.. how to get it is implementation detail
[16:27:08] <rstory> david h: concerned with interaction with other methods (eg radius)
[16:27:49] <rstory> js: need text in security considerations about passing name around securely?
[16:28:25] <rstory> david h: no internal maping to some other name
[16:28:35] <rstory> jeff/joseph: that would be a bug
[16:29:46] <rstory> chris l: on usernames, is that going to be singular for 100 boxes, or unique per box?
[16:29:57] <rstory> jeff: deployment issue
[16:31:30] <rstory> chris l: what happens to shared username if a box is compromised?
[16:31:54] <rstory> david h: snmpv3 localized, which is 'difficult'
[16:32:10] <rstory> on to 18, already discussed
[16:32:29] <rstory> on to 19: radius
[16:33:20] <rstory> david h: most agree, however... using radius auth and putting it into snmp.. may need to pass hints to radius service (eg pass device to be managed)
[16:33:59] <rstory> eliot: oh my god! we are back to triangular communication with eusm, which everbody though was ugly.
[16:34:02] <rstory> sam: how?
[16:34:11] <rstory> eliot: agent to radius
[16:34:15] <Dave Nelson> Or maybe SSH needs to be aware of authorization data.
[16:34:16] <rstory> jeff: behind ssh
[16:34:20] --- bclaise has left
[16:34:41] <rstory> sam: see line, no triangle..
[16:35:58] <rstory> sam: example how this works.. ssh to cisco box using radius
[16:37:04] <rstory> eliot: concern that no hardcoding to radius
[16:37:18] <rstory> [ed] eg don't want hardcoding
[16:38:00] <rstory> david h: may need to send hints to radius
[16:38:12] <rstory> eliot: that's what i'm concerned about
[16:38:35] <rstory> eliot: do we need to discuss port numbers now? order of execution can be an issue
[16:38:54] <rstory> jeff: no ssh method to provide more than username to to server
[16:38:59] <rstory> eliot: talking about backend
[16:39:31] <rstory> jeff:use keyword interactive to provide hint to server
[16:39:39] <rstory> sam: no
[16:39:57] --- Roy Brabson has left
[16:40:53] <rstory> david h: we need requirements to work with radiusext
[16:41:01] <rstory> eliot: not sure we can provide anything
[16:41:53] <rstory> jeff: agent could request info from radius after the fact
[16:42:28] <Dave Nelson> No. The RADIUS management authorization work does not separate authorization from authentication.
[16:43:26] <rstory> david h: so, work to be done
[16:43:29] <rstory> on to 32
[16:44:20] <rstory> david h: snmp pseudocode, need mapping between ssh user name and snmp security name. possibly to preconfigure mapping. should we default to direct mapping if no other mapping configured
[16:44:31] <rstory> david h: mailing list consensus: yes
[16:44:37] <rstory> on to Sessions slide
[16:44:52] <rstory> david h: need text
[16:45:10] <rstory> eliot: does session mean transport/ssh or something else
[16:45:13] <rstory> david h: yes
[16:45:35] <rstory> david h: need to understand session implication, and interactions with transport layer
[16:46:12] <rstory> 23: dealing with session closure
[16:46:39] <rstory> #25: when to call establishSession() (snmpv3 api)
[16:47:37] <rstory> david h; security piece during message processing, passed to transport before try to create session. no good way to pass back error message
[16:48:33] <rstory> david h: do we need to do something special
[16:50:07] <rstory> eliot: q for snmp folks: clarifing issue..
[16:50:39] <rstory> jq: almost of of time, lots of issues, should we prioritize remaining items?
[16:51:15] <rstory> david h: important problems are also rat-hole, not likely to solve quickly
[16:51:32] <rstory> #29: reports?
[16:51:37] <rstory> david h: yes
[16:51:57] <rstory> lots of slid flipping looking for easy issues
[16:52:29] <rstory> #30: securityParameters parsing needed?
[16:52:46] <rstory> david h: maybe to check if empty, and not a covert channel
[16:53:09] <rstory> #6 coexistence w/v1/v2
[16:53:10] <rstory> #9: reuse r/r session for notifications
[16:53:15] <rstory> wes: why not?
[16:53:47] <rstory> js: how do we authenticate? ssh isn't symmetric.
[16:53:51] <rstory> eliot: yes
[16:53:53] --- Yoshifumi Atarashi has left: Replaced by new connection
[16:53:55] --- Yoshifumi Atarashi has become available
[16:54:07] <rstory> eliot: which direction do notifications come from
[16:54:45] <rstory> jeff: q: impression that notifications is when device is preconfigure to send notifications to mgmt station to alert problems/events
[16:54:52] <rstory> david h: yes
[16:55:14] <rstory> david h: tied in with authoratative engine id issue
[16:56:05] <rstory> wes: there is no signally mechanism to tell agent i'm talking to if i'm a command generator or notification receiver
[16:56:26] <rstory> <name?>: need auth traps on failed attempts
[16:57:18] <rstory> david p: today using udp, when event occurs, you send it, don't need session. so, if you want to send traps in the future, when do you set up session? startup? new target configured? or when event occurs?
[16:57:37] <rstory> david h: current draft says when sending trap, if no session, set it up
[16:57:51] <rstory> david p: when to tear down?
[16:57:56] <rstory> david H; open question
[16:58:36] <rstory> david p: stadard to configure targets, 'interesting' in terms of identities.. ssh servers have different types if identities..
[16:59:01] <rstory> sharon: people will want to set up notification and sustain it.
[16:59:18] <rstory> sharon: otherwise it's just like udp
[16:59:55] <rstory> david p: when does mgmt set up session?
[17:01:15] <rstory> eliot: if i'm mgmt station and i want notifications, why not configure target mib?
[17:01:25] <rstory> wes: snmpget vs mgmt station
[17:01:45] <rstory> eliot: isn't that what target mib is for?
[17:02:01] <rstory> wes: could do that, don't know if target mib could do that.
[17:02:11] <rstory> js: to detailed
[17:03:27] --- hartmans has left
[17:03:37] <rstory> js: thanks for coming. continue on list and in person
[17:03:38] --- jschoenwae@jabber.org has left: Logged out
[17:03:42] --- nico has left
[17:03:43] <rstory> END OF TRANSMISSION
[17:03:53] --- rstory has left: Logged out
[17:04:09] --- abierman has left
[17:04:15] --- Dave Nelson has left
[17:05:51] --- Eliot Lear has left: Logged out
[17:13:26] --- bert has left
[17:15:44] --- psavola has left
[17:18:21] --- Yoshifumi Atarashi has left: Disconnected
[17:22:22] --- Yoshifumi Atarashi has become available
[17:22:40] --- Yoshifumi Atarashi has left