[08:49:13] --- rstory has joined
[09:28:53] --- lengyel has joined
[10:01:09] --- j.schoenwaelder@jabber.eecs.iu-bremen.de has joined
[10:11:51] --- bert has joined
[10:12:02] * bert has set the topic to: ISMS session at IETF68
[10:13:38] --- sharonchisholm has joined
[10:13:50] <sharonchisholm> sharon is jaber scribe
[10:13:53] --- jhutz@jis.mit.edu/owl has joined
[10:14:06] <sharonchisholm> milestones
[10:15:17] <sharonchisholm> one of the documents is still in last cal. send comments
[10:16:02] <sharonchisholm> internet drafts
[10:16:18] --- dbh2 has joined
[10:16:32] <sharonchisholm> WG Agenda
[10:17:42] <sharonchisholm> no changes
[10:17:47] <sharonchisholm> -------
[10:17:54] <sharonchisholm> Dave H.
[10:18:57] <sharonchisholm> These slides will be uploaded in a few minutes
[10:19:48] <sharonchisholm> <good use of colour fonts>
[10:19:50] --- dromasca has joined
[10:20:04] <sharonchisholm> status of three drafts (version numbers ... etc)
[10:20:10] --- mike has joined
[10:20:13] <sharonchisholm> transport subsystem
[10:20:17] --- dromasca has left
[10:20:17] <sharonchisholm> 11 reviewers
[10:20:27] <sharonchisholm> two versions published to address issues. most of them
[10:20:35] <sharonchisholm> proposals for rest of issues
[10:20:37] --- ShoichiSakane has joined
[10:20:53] <sharonchisholm> issue #1 - responses MUST go back on the same transport session
[10:21:29] --- dromasca has joined
[10:21:31] --- miaofuyou has joined
[10:21:46] <sharonchisholm> issue #2 - cache contents - do we defined this?
[10:22:45] <sharonchisholm> Issue #3 - how to tell difference between notification or request/response
[10:22:49] <sharonchisholm> it doesn't
[10:22:56] --- raeburn@mit.edu has joined
[10:23:07] <sharonchisholm> issue #4 - keep info around after session is closed
[10:23:26] <sharonchisholm> make it implementation dependant
[10:23:46] <sharonchisholm> Issue #5 - do informs work correctly?
[10:23:54] <sharonchisholm> No one has indicated why they wouldn't work.
[10:24:08] <sharonchisholm> Bert is going to talk about the issue
[10:24:23] <sharonchisholm> Bert does not find anything that might go wrong
[10:24:33] <sharonchisholm> so he went back to Jeff Case's message to see if there were hints
[10:24:42] <sharonchisholm> page 15 in revisition 5 of the document
[10:24:53] <sharonchisholm> lots of dsicussion about session establishment and it is vague
[10:25:07] <sharonchisholm> don't think it has any influence on inform not work while a get/set does
[10:25:16] <sharonchisholm> they are all confirmed class PDUs
[10:25:26] <sharonchisholm> the receiving end if the authoritative thing
[10:25:57] <jhutz@jis.mit.edu/owl> "authoritative SNMP engine"
[10:25:58] <sharonchisholm> he also talked about a violation of architecture
[10:26:12] <sharonchisholm> (I know. thing was more ammusing to me .... bad jabber scribe ;-))
[10:26:52] <jhutz@jis.mit.edu/owl> I think that concept is really specific to USM, but I don't think that actually matters for the sake of Bert's argument.
[10:27:02] <sharonchisholm> in USM, the authorative engine ID is carried
[10:27:12] <sharonchisholm> with transport security model, it isn't in the message
[10:27:31] <sharonchisholm> as the first step to start process, make security engine id equal to the local id
[10:27:41] <sharonchisholm> that is the thing that is different then USM
[10:27:53] <sharonchisholm> the security folks said this wasn't a security problem
[10:28:08] <sharonchisholm> also had a 2005 dsicussion with Steve Wallbuser ...
[10:28:20] <sharonchisholm> he wanted to make the receiver authoritative
[10:28:40] <sharonchisholm> he also thinks the security engine id also has meaing outside the security model
[10:28:57] <sharonchisholm> people should go read Steve's email if they think this is imporant
[10:29:11] <sharonchisholm> that is the information so far, I don't know if it is a real problem
[10:29:35] <sharonchisholm> Jeff H - does he say what use he thinks the security engine id has outside the security model?
[10:30:01] <sharonchisholm> Bert - he does elaborate a bit, populating the database with possibly thousands of users ...
[10:30:13] <sharonchisholm> Bert - there is some more detail in his email that I didn't grasp right away
[10:30:34] <sharonchisholm> Bert - before I was against making the receiver the authoritive thing because it adds complexity
[10:32:08] <dromasca> sharon - in disman it used to be cached, uniqueness not security reasons
[10:32:14] <sharonchisholm> Jeff H - I thought last time we came to the conclusion that the security engine id does not have any meaning outside the context of USM.
[10:32:49] <sharonchisholm> bert - in USM data model ... it is possible to have the same user twice with different keys
[10:33:10] <sharonchisholm> Bert - username bert for get as appose to username bert for get/send
[10:33:23] <sharonchisholm> Joe - the authorization then is based on username instead of engineID
[10:33:42] <sharonchisholm> Dave H - <something about clocks>
[10:34:05] <sharonchisholm> Juergen - if people believe the engine Id was being used outside of USM, please tell us when
[10:34:53] <sharonchisholm> Bert - in my email I tried to get Jeff Case to respond and elaborate.
[10:35:24] <sharonchisholm> Bert - SNMP Research has a stack that is well deployed .... if there are people who are using his products, then perhaps they could use that get a response back from him
[10:35:50] <rstory> dave h said the authoritative engine id also determines the side that has the authoritative clocks for any time checks
[10:35:51] <sharonchisholm> Bert - find out the issue . if he sees one, there very well could be in either the protocol or in that stack. Either way, you want to know now
[10:36:15] --- Dave Nelson has joined
[10:36:16] <sharonchisholm> Issue #6 - double authentication
[10:36:34] <sharonchisholm> Transport SEcurity Model
[10:36:44] <sharonchisholm> 02 published and reviewed
[10:36:54] <sharonchisholm> WGLC
[10:37:01] <sharonchisholm> (03)
[10:37:21] <sharonchisholm> WGLC Comments
[10:37:27] <sharonchisholm> almost entirely editorial
[10:37:53] --- dlpartain has joined
[10:38:11] <sharonchisholm> transport model determines the security name and the amount of security in the transport of the message
[10:38:14] <sharonchisholm> auth priv
[10:38:31] <sharonchisholm> then there is what is asked for
[10:38:32] --- ShoichiSakane has left
[10:38:42] <sharonchisholm> it is ok to send it more secure then what is asked, but not less
[10:39:00] <sharonchisholm> confusing to look at both sets of varaibles when they have the same name
[10:39:19] <sharonchisholm> the lesser value is what should be applied up to the application
[10:39:26] <sharonchisholm> most times it won't matter
[10:39:37] <sharonchisholm> proxy might be a problem
[10:39:45] <sharonchisholm> app to app is end to end
[10:39:51] <sharonchisholm> transport level is hop per hop
[10:39:57] <sharonchisholm> could then have different levels.
[10:40:29] <sharonchisholm> that is why you should report the requested one
[10:40:41] <sharonchisholm> Secure Shell Transport
[10:40:43] <sharonchisholm> not been touched
[10:40:56] <sharonchisholm> plan WGLC before IETF 69
[10:41:25] <sharonchisholm> Questions?
[10:41:52] <sharonchisholm> ---------------------
[10:41:58] <sharonchisholm> Radius Document
[10:42:12] <sharonchisholm> What to do about it? As working group document or wait for another revision?
[10:42:45] <sharonchisholm> Dave H was one of the people who thinks the document requires work. SHould be more from architecture perspective rather then radius
[10:42:59] <sharonchisholm> who has read it
[10:43:05] <sharonchisholm> <4?>
[10:43:17] <sharonchisholm> From those people, what do they think>
[10:43:31] <sharonchisholm> Dave H - biggest concern is it is inconsistent with other documents
[10:43:56] <sharonchisholm> Dave H - we no longer have a secure shell security model
[10:44:08] <sharonchisholm> Dave H - I have strong feelings on the structure
[10:44:35] <sharonchisholm> Dave H - obvious conflict between snmpv3 that says that authentication and authorization should be separate tied together with parameters
[10:44:46] <sharonchisholm> Dave H - radius has authentication tied with authorization
[10:44:51] <sharonchisholm> Dave H - no separation
[10:45:07] <sharonchisholm> Dave H - we have subsystems that don't know anything about either
[10:45:17] <sharonchisholm> Dave H - there is a real problem ensuring we get the separation we need
[10:45:33] <sharonchisholm> Dave H - in the existing doucment, there are three approaches discussed that are muddled together
[10:45:46] <sharonchisholm> Dave H - 1) getting authentication and authorizing the subsystem
[10:45:50] <sharonchisholm> we don't see that in SNMP
[10:46:07] <sharonchisholm> Dave H - it would be a small piece to go in a document to say that SSH might choose to use Radius
[10:46:21] <sharonchisholm> Dave H - implementation specific magic ...
[10:46:37] <sharonchisholm> Dave H - the AA could be cached and used later
[10:47:04] <sharonchisholm> Dave H - 2) dynamic authorization ... authentication is done and the radius state is done to do an authorization only operation
[10:47:19] <Dave Nelson> Dynamic authorization is initiated from the server not the client.
[10:47:19] <sharonchisholm> Dave H - then authentication is based on state, not a new operation
[10:47:55] <Dave Nelson> Dynamic re-auth request need username and state, not only stare.
[10:47:58] <sharonchisholm> <jeurgen reads Dave N's comment>
[10:48:05] <Dave Nelson> Yes, RADIUS server.
[10:48:06] --- hartmans@jis.mit.edu/owl has joined
[10:48:13] <sharonchisholm> Dave H - I thought it could iniatiate if it wanted, that may not be true
[10:48:32] <Dave Nelson> It could, but it's not the same as Dynalic RADIUS.
[10:48:38] <sharonchisholm> Dave H - there are some paramters that would need to be passed up
[10:48:56] <sharonchisholm> Jeurgen - there does need to be more work on this document. Do we take it now, or wait a bit later
[10:48:57] --- joshlitt has joined
[10:49:05] <sharonchisholm> Jerugen - propose we accept it
[10:49:11] <sharonchisholm> J - since it is in the charter
[10:49:24] <sharonchisholm> Dave H - question what we are chartere (not all of it)
[10:49:33] <sharonchisholm> Dave H - no acess control
[10:49:54] <sharonchisholm> J - correct - so that should go into separte document
[10:50:08] <sharonchisholm> AD (Sam) - may be mis remembering, havenot read charter this week.
[10:50:29] <sharonchisholm> Sam - changing of user to group models was in scope but a new access control model was not
[10:50:42] <sharonchisholm> Sam - I may be wrong
[10:50:55] --- dromasca has left
[10:50:58] <sharonchisholm> Jeff H - "work on new access control, where <something about VACM> is outside the scope"
[10:51:05] <sharonchisholm> Jeff H - that is all it says
[10:51:18] <sharonchisholm> Jeff - mapp SSH users to security names does not fall out of scope
[10:51:41] <sharonchisholm> Sam - nor is strictly something that modifies groups.
[10:51:49] <sharonchisholm> Jeff - not sure what they mean by mappings
[10:51:53] <sharonchisholm> <mike exchange>
[10:52:31] <sharonchisholm> Dave H - in VACM access model, the first table that you encounter when you enter the AC system, mapping between security name and group name
[10:52:46] <sharonchisholm> Dave H - group anme is a role "admin, "oper"
[10:52:54] <sharonchisholm> Dave H - security name and map to policy
[10:53:18] <sharonchisholm> Dave H - some discussion in and out fo working group that it is too bad that wasn't done outside the security model
[10:53:26] <sharonchisholm> Dave H - it would be more flexible
[10:53:43] <sharonchisholm> Dave H - mapping from security name to policy group, happens inside AC
[10:54:08] <sharonchisholm> Steve H - my reading of the charter is that detailed work on those mappings would be outside the scope
[10:54:31] <sharonchisholm> Sam - before I say more, I woudl want to go back and read the disussion that led to the charter.
[10:54:48] <sharonchisholm> Sam - if the working group agrees with David about the right way to do it, then no problem
[10:55:03] <sharonchisholm> Jeurgen - some interest in getting gropu mapping done
[10:55:07] <sharonchisholm> <lots>
[10:55:16] <sharonchisholm> Jeurgen - don't want new access control moel
[10:55:17] <sharonchisholm> model
[10:55:48] <sharonchisholm> Dave H - one problem with the current document ... if does mapping that belongs in access control model and this muddies the architecture
[10:55:54] <sharonchisholm> Jeurgen - that is documentation
[10:56:03] <sharonchisholm> Jeurgen - the question is whether we want to do this
[10:56:15] <sharonchisholm> Jeurgen - anyone appose the secutityy name to group name done in this workin gruop
[10:56:33] <sharonchisholm> Jeff H - not opposed to it, but whether or not it fits iwth the literal work in the charter ...
[10:56:42] <Dave Nelson> It might be well to have tow documents, one to address authentication, which could move forward quickly, and a second one to address authorization, which appears to have more challenges, in meeting the current SNMP architecture.
[10:57:00] <sharonchisholm> Jeff H - this level of work ... seems out of the spirit of the work I thought this working gropu would do
[10:57:00] <Dave Nelson> two documents
[10:57:09] <sharonchisholm> Jeff - we should finish the other stuff first
[10:57:17] <sharonchisholm> Jeff _ then think of rechartering
[10:57:45] <sharonchisholm> Jeurgen - goes back to A & A being coupled
[10:58:21] <sharonchisholm> Joe - back when we were coming up with a charter ... there was desire to solve this problem
[10:58:30] <sharonchisholm> Joe - don't fully grasp the complexities there
[10:58:52] <sharonchisholm> Joe - charter to allow it but not open up to all that VACM stuff
[10:59:23] <sharonchisholm> Dave P - back when we did VACM, one problem we noted was that a user could not be in multiple groups, so you could not do role-based security model
[10:59:50] <sharonchisholm> Dave P - some recent work that I have done, I think it is worthwhile to go back and work on the problem
[11:00:11] <sharonchisholm> Bert - do not understand radius well enough ... does radius allow this?
[11:00:30] <Dave Nelson> It's a matter of back enbd server implementation.
[11:00:39] <sharonchisholm> Joe - <question off mike>
[11:00:57] <sharonchisholm> Sam - <response I missed>
[11:01:14] <sharonchisholm> Joe - no concept within radius of a group that you get back. No standardized attribute
[11:01:40] <sharonchisholm> bert -so it seems like we need to something special for one user to become a member of multiple groups
[11:01:55] <sharonchisholm> Joe - you would have to do something for a user to be a member of any group
[11:02:00] <sharonchisholm> Dave h - need mike
[11:02:20] <sharonchisholm> Dave H - the way radius is written ... you either get an administrative shell or an operator shell
[11:02:33] <sharonchisholm> Dave H - that is the only distinction they have at this time
[11:02:41] <sharonchisholm> Jeff H - I think that is CLI specific and I think you can get more
[11:02:51] <sharonchisholm> Jeff H - would need to define attribute
[11:03:02] <sharonchisholm> Dave H - Think Dave N did soemthing
[11:03:23] <sharonchisholm> Bert - back when I was AD we did charter ... I was opposed to opening up all this.
[11:03:39] <sharonchisholm> Bert - I would rather focus on using the secure shell stuff
[11:03:58] <sharonchisholm> Bert - authoriation
[11:04:19] <sharonchisholm> Sam - help me understand what would be ok and what wouldn't be ok
[11:04:35] <sharonchisholm> Sam - don't know how to use radius without opening up things you don't want opened up
[11:05:06] <Dave Nelson> What do we want to do with our curent draft?
[11:05:12] <jhutz@jis.mit.edu/owl> > back when I was AD That was what, 5 minutes ago? :-)
[11:05:20] <sharonchisholm> Dave P - Suggesting two things. 1) there has to be work done to return a group, but instead return a list on the radius side
[11:05:45] <sharonchisholm> DaveP - <something> could be extended to support multiple groups
[11:05:59] <sharonchisholm> Dave H - agree with dave perkins
[11:06:18] <sharonchisholm> Dave H - and everyone. would be good to have access cointrol model that provides radius integration
[11:06:33] <sharonchisholm> Dave H - BUT concerned this will distract from authentication
[11:06:40] <sharonchisholm> Dave H - get htat done first
[11:06:46] <sharonchisholm> Jeurgen - Move to list
[11:06:52] <sharonchisholm> -----------
[11:07:00] <sharonchisholm> Revise Milestones
[11:07:30] <sharonchisholm> (slide 6)
[11:07:39] <sharonchisholm> Can Dave H commit to these dates?
[11:07:55] <sharonchisholm> Dave H - I think we can get transport subsystem and security model ....
[11:08:14] <sharonchisholm> Dave H - my concern is with the ssh security model ... hope to get to last call before IETF 69
[11:08:19] <sharonchisholm> Jeurgen - that's July
[11:08:45] <sharonchisholm> Jeurgen - planned on keeping transport and other documents around until we finish third
[11:08:56] <sharonchisholm> so move to august instread of june
[11:09:17] <sharonchisholm> Dave H - set to 2008 so we can beet the deadline
[11:09:31] <sharonchisholm> Dan (AD Hat) - Nope.
[11:09:48] <sharonchisholm> Dave H - revised ssh thing by april 07. Can do that.
[11:09:57] <jhutz@jis.mit.edu/owl> Hm; my bad. This WG is actually SEC, not O&M. But I don't think Sam would go for 2008 either.
[11:10:07] <sharonchisholm> ----------------
[11:10:19] <sharonchisholm> SNMP EngineId Discovery
[11:10:38] <sharonchisholm> problem: context engineID Discovery
[11:11:28] <sharonchisholm> proposal: introduce well-known localEngineID
[11:12:12] <sharonchisholm> solve discovery problem by not doing discovery
[11:12:46] <sharonchisholm> use enterprise id 0
[11:13:13] <sharonchisholm> <Jeff quietly sneaks out while almost knocking over the projector>
[11:14:01] <sharonchisholm> Dave P - the way the engine id is set up, it has enterprise in it ... you are really just talking about special stuff
[11:14:10] <sharonchisholm> Dave p - not talking about IANAN control
[11:14:31] <sharonchisholm> Jeurgen - allocating this new format ... 6 ... another way woul be to formally request
[11:14:55] <sharonchisholm> Dave H - IANA already reserves ID 0, but they don't say for what. we might be able to use it
[11:15:21] <sharonchisholm> Dan - from a procedure point of view, this probably isn't a problem.
[11:15:35] <sharonchisholm> Dan - didn't we use the 0 OID in trap translation
[11:15:51] <sharonchisholm> Sharon - No, that was an zero in the second last octet, it was not the enterprise ID
[11:16:24] <sharonchisholm> Bert - these numbers are reserved and there is no registry. We can probably do he document and ask IANA to create a registry. Otherwise we would have to udpate the TC
[11:16:40] <sharonchisholm> Jeuren - ok. understand .... I will create some text.
[11:16:48] <sharonchisholm> Jeurgen - running over time.
[11:17:11] <sharonchisholm> Jeurgen - interesting presentation on prototype on <something>
[11:17:29] <sharonchisholm> SNMP over TLS
[11:17:48] <sharonchisholm> ---------------
[11:17:54] <sharonchisholm> SNMP over TLS
[11:18:51] <sharonchisholm> Sam - can't run a meeting over this long
[11:18:55] --- j.schoenwaelder@jabber.eecs.iu-bremen.de has left: Disconnected
[11:19:06] <sharonchisholm> Formally the meeting needs to be over
[11:19:22] <sharonchisholm> <people are debating whether or not do continue informally>
[11:19:33] --- dbh2 has left
[11:20:01] <sharonchisholm> <we are going ahead>
[11:20:18] <sharonchisholm> Session Establishment Overhead
[11:20:32] --- raeburn@mit.edu has left
[11:21:12] <sharonchisholm> It shows a significant overhead for session establishment
[11:21:22] --- jhutz@jis.mit.edu/owl has left: Disconnected
[11:23:04] <sharonchisholm> Are there any known proposals to add something like session resumption to SSH?
[11:23:09] <sharonchisholm> Dave H - don't know of anything?
[11:23:14] <sharonchisholm> Joe - have not heard of anything either
[11:26:30] <sharonchisholm> <he is showing a graph and people hav asked some clarifying questions>
[11:26:42] <sharonchisholm> Overhead for Long Sessions
[11:26:50] <sharonchisholm> Dave P - that is software AES
[11:26:54] <sharonchisholm> Vlad - yes
[11:27:16] <sharonchisholm> That is what I wanted to show about the peformance. We can discuss later...
[11:27:35] <sharonchisholm> ok. we are done the second meeting
[11:27:41] --- sharonchisholm has left
[11:28:13] --- mike has left
[11:28:21] --- Dave Nelson has left
[11:28:22] --- rstory has left
[11:28:44] --- dlpartain has left
[11:33:13] --- lengyel has left
[11:41:51] --- joshlitt has left
[11:42:34] --- bert has left
[11:45:44] --- miaofuyou has left: Replaced by new connection.
[11:46:48] --- miaofuyou has joined
[11:55:47] --- miaofuyou has left