[10:50:34] --- SharonChisholm has become available
[10:50:38] --- SharonChisholm has left
[10:51:12] --- SharonChisholm has become available
[10:51:31] --- dinakar has become available
[10:51:34] <SharonChisholm> Going through the administrivia
[10:52:50] <SharonChisholm> Problem to solve
[10:52:59] <SharonChisholm> - cost to deploy snmpv3 high
[10:53:03] <SharonChisholm> solution goals
[10:53:19] <SharonChisholm> - lower cost of deployment and operation through infrastructure reuse
[10:53:30] <SharonChisholm> - provide some additional security features
[10:53:32] <SharonChisholm> - low cost evolution
[10:53:57] <SharonChisholm> - no modification of SNMPv3 full standard ... modular add on
[10:54:21] <SharonChisholm> eric - goal should also be ... as possible .. it should use currently popular architectures
[10:54:24] <SharonChisholm> wes - yes, that is coming
[10:54:52] <SharonChisholm> snmp background
[10:55:00] <SharonChisholm> doing this in security area to bring in security folks
[10:55:22] <SharonChisholm> - snmpv3 is an application layer protocol ... modular ... allows for extensibility
[10:55:37] <SharonChisholm> SNMPv3: Architecture Picture ...
[10:55:49] <SharonChisholm> importand piece ... designed to add extensions
[10:56:10] <SharonChisholm> Security in SNMPv3 ... transmiission and processing the content
[10:56:29] <SharonChisholm> plugable security models ... currently only USM ... some prop.
[10:56:56] <SharonChisholm> functionality - identity authentication .. message auth ... disclosure protection ... as defined by architecutre
[10:57:10] <SharonChisholm> services in sets called 'security levels'
[10:57:30] <SharonChisholm> snmpv3 message format
[10:57:46] <SharonChisholm> ... there is a security model item in PDU
[10:58:15] <SharonChisholm> USM Characteristics .... combines sender identity authentication with message authentication ..
[10:58:33] <SharonChisholm> no one is saying that USM is a bad security model ... that is not the message we want to put out there
[10:58:50] <SharonChisholm> shared secret type solution
[10:59:09] <SharonChisholm> localized keys
[10:59:19] <SharonChisholm> that is a good thing
[10:59:26] <SharonChisholm> needed security features
[10:59:34] <SharonChisholm> - authentication at both ends
[10:59:53] <SharonChisholm> - allow use of different mechanisms (we have not stated this yet)
[11:00:02] <SharonChisholm> dave likes the idea of not disclosing identiyu
[11:00:09] <SharonChisholm> q - can you explain that a bit more
[11:00:47] <SharonChisholm> wes - the equiv of being able to log into a box and do stuff and know that stuff hasn't been messed with, even if you have an anonomous log in. he is looking at a service point of view were you want data but don't want to be known
[11:01:08] <SharonChisholm> q - I want to talk to the box and get the right information but I don't want you to know who I am?
[11:01:11] <SharonChisholm> wes - yes
[11:01:33] <SharonChisholm> q (new) - doesn't that really give the noauth encrypt that we said we didn't want?
[11:01:49] <SharonChisholm> wes - kind of ; sort of; not quite ... <explanation>
[11:02:04] <SharonChisholm> q (new) - doesn't this potentially affect access control
[11:02:23] <SharonChisholm> wes - you would still need <something> it's a goal ... it's Dave's goal ... these are his slides
[11:02:47] <SharonChisholm> - agent must reveal ... this was part of our solution, might not be requirement
[11:03:05] <SharonChisholm> chris - agree ... not a requirement ... disagree whose identity needs to be protected
[11:03:10] <SharonChisholm> more needed features
[11:03:31] <SharonChisholm> - separate security mechanism used for identity aith from that used for mesage auth and encrpt
[11:03:44] <SharonChisholm> - limited life time keys for message auth ...
[11:03:47] <SharonChisholm> - other stuff
[11:03:58] <SharonChisholm> - low incremental cost
[11:04:05] <SharonChisholm> -must work with VACM
[11:04:45] --- jishac has become available
[11:04:58] <SharonChisholm> View Based Access Control (VACM)
[11:05:08] <SharonChisholm> Problems and SOlutions
[11:05:25] <SharonChisholm> - must not lose track of goal to integrate with existing stuff
[11:05:38] <SharonChisholm> changes - what must change - snmp lib snmp agent toolkits
[11:06:17] <SharonChisholm> what shouldn't change - how the management infrust. that usees the snmp lib ... access routes in snmp agent .. existing security infrust. and the security protocols that they use
[11:06:31] <SharonChisholm> <switching slide packs>
[11:06:53] <SharonChisholm> my slides show what operators are really using today
[11:07:01] <SharonChisholm> Identification Schemes
[11:07:11] <SharonChisholm> - local data base authentication
[11:07:22] <SharonChisholm> - when the auth rights are kept on the device itself
[11:07:30] <SharonChisholm> - local accounts ... ssh, telnet
[11:08:08] <SharonChisholm> that data base is the device itself
[11:08:32] <SharonChisholm> randy - really that data base is on both the agent and the manager
[11:08:58] <SharonChisholm> <missed a slide that had a trusted third part or something>
[11:09:13] <SharonChisholm> Then there is the kerberose stuff ... ticket master that talks to the manager
[11:09:42] <SharonChisholm> then there is a central certificate authority such as PKI ... talks to both manager and agent
[11:10:28] <SharonChisholm> ----
[11:10:28] <SharonChisholm> problem history
[11:10:37] <SharonChisholm> - this is the second bof ... had one at IETF 58
[11:11:02] <SharonChisholm> since then he's been to NANOG ... did an electronic survey ... 149 responses ... overwhelmingly a problem
[11:11:17] <SharonChisholm> q - i am wondering what an operator is? ISP? goverment
[11:11:24] <SharonChisholm> wes - manages a network
[11:11:29] <SharonChisholm> q - admins
[11:11:34] <SharonChisholm> wes - yes
[11:11:44] <SharonChisholm> wes - many classes of operators ... not going there
[11:11:55] <SharonChisholm> primary goal of this bof is to get a charter in place ...
[11:12:09] <SharonChisholm> secondary goal is to do some technical discussion
[11:12:14] <SharonChisholm> survey results (graph)
[11:12:26] <SharonChisholm> - mainly network operators
[11:13:14] <SharonChisholm> SNMP use ... mostly monitoring ... some alarns and events ... a small amount of config ... no performing actions
[11:13:19] --- bert has become available
[11:13:47] <SharonChisholm> my wording on the last one was probably bad, so that is why 0
[11:13:59] <SharonChisholm> eliot - back up on that slide ... ok
[11:14:14] <SharonChisholm> wes - raw numbers were sent to the mailing list a while back. I've received some more since then
[11:14:14] <bert> jishac, are you in the room, or are you a remote participant?
[11:14:27] <SharonChisholm> eliot - do you think this is surprising?
[11:14:33] <SharonChisholm> wes - no ... just the last bit
[11:14:44] <SharonChisholm> randy - the expectation is that the last bit would be greator than config
[11:14:50] <SharonChisholm> q - the operator was probably confused
[11:14:59] <SharonChisholm> wes - put survey together quickly
[11:15:08] <jishac> bert: I'm am sitting in hiprg
[11:15:32] <SharonChisholm> what versions of SNMP do you use - lots of SNMPv1 & SNMPv2 ... less than half those numbers for SNMPv3
[11:15:58] <SharonChisholm> bert - of course this is a problem ... how does it stack up to IPv4 and IPv6 migration? That is the context to look at ... this isn't greenfield
[11:16:10] <SharonChisholm> bert - are these absolute numbers
[11:16:19] <SharonChisholm> bert - it is actuall 40/140 ...
[11:16:24] <SharonChisholm> wes - not bad numbers ...
[11:16:54] <SharonChisholm> <discussions on the number of responses, and other ways to interpret data>
[11:17:09] <SharonChisholm> wes - some boxes are used trilingual ..
[11:17:22] <SharonChisholm> did you find SNMPv3/USM easy to deply and use
[11:17:29] <SharonChisholm> - people mainly abstained
[11:17:55] <SharonChisholm> more no than yes, but most people abstained
[11:18:16] <SharonChisholm> wes - actually abstained is i don't use it.
[11:18:44] <SharonChisholm> is the current snmpv3 & USM sufficiently secure for you
[11:18:57] <SharonChisholm> more yes, half as many nos and abstains
[11:19:25] <SharonChisholm> what authentication mechanims do you use
[11:19:49] <SharonChisholm> - local accounts is the big winner ... then comes ssh-keys ... radius ... TACACS+ .... then the other things ...
[11:20:06] <SharonChisholm> q - they all want a known mechanism ... but they don't all want to same known mechanisms
[11:20:18] <SharonChisholm> wes - everybody thinks that there environment is special
[11:20:37] <SharonChisholm> wes - this list is not quite what I expected
[11:20:47] <SharonChisholm> wes - local accounts ... password on the box is the thing they mostyly use
[11:21:08] <SharonChisholm> eliot - looking at numbers ... add radius and TACACS+ should really be put together ...
[11:21:19] <SharonChisholm> wes - well and you could put local accounts + SSH keys
[11:21:26] <SharonChisholm> eliot - no ... i don't think you can
[11:21:39] <SharonChisholm> eliot - was this a mutually exclusive thing?
[11:21:41] <SharonChisholm> wes - no
[11:21:52] <SharonChisholm> eliot - ssh keys might be part of local accounts
[11:22:12] <SharonChisholm> q - trying to figure out what to make of this ...
[11:22:20] <SharonChisholm> wes - let me do one more slide
[11:22:35] <SharonChisholm> what auth mechanism do you not use that you would like to
[11:22:45] <SharonChisholm> radious now on top ... then ssh-keys ...
[11:23:13] <SharonChisholm> eric - is the thing we are suppose to get from this ... we would like ... profiels that you can use with SNMPv3 should sort of look like this?
[11:23:38] <SharonChisholm> no - we asked this question somewhat outside snmp3 ... we should tie this all in to reach the operators ... defining problem space not the solution
[11:23:48] <SharonChisholm> eric - head spinning from trying to support all of this
[11:24:06] <SharonChisholm> eric - intuition ... <various solutions> ... really a new security invention ...
[11:25:07] <SharonChisholm> eric (different one) - work at boeing ... one of everyhing ... more of certain things ... as a coorporation trying to correct that ... next year we are anticipating a card ... badge reader ... standardize on PKI and PKI like things ... similar to military ... DoD has similar problems
[11:25:22] <SharonChisholm> wes - in looking at the graphs i was hopinh that X.509 would be more deployed
[11:25:52] <SharonChisholm> eric (boeing) - hard job ... operators might not be tracking what the company is trying to do
[11:26:02] <SharonChisholm> wes - to move forward, we probably don't need to debate thigs
[11:26:20] <SharonChisholm> q - ssh keys are often used for machine auth, other mechanism used for user auth
[11:26:33] <SharonChisholm> q (new) - there are protocols ... stuff that should be cleaned up
[11:26:57] <SharonChisholm> wes - should have mentioned ... five predefined ones ... there was fill in the blank ... people added stuff
[11:27:17] <SharonChisholm> this slide is what people wanted to use .. local accounts got votes
[11:27:38] <SharonChisholm> would you find it useful if snmp supported above - lots of yes
[11:27:49] <SharonChisholm> would adding these new features be good - yes
[11:28:31] <SharonChisholm> if devices supported all above, would you still use snmpv3 wtih existing USM
[11:28:40] <SharonChisholm> - it's dead even yes and no
[11:28:59] <SharonChisholm> eric (boeing) - that is confusing ... there are many ways to interpret
[11:29:33] <SharonChisholm> q - people could want usm and other things to ensure they have a backup
[11:29:49] <SharonChisholm> wes - usm could be the backup
[11:30:07] <SharonChisholm> requirements discussion
[11:30:27] <SharonChisholm> - must be possible to integrate with existing infrast.
[11:30:36] <SharonChisholm> - can't be less secure than snmpv3/USM
[11:30:52] <SharonChisholm> - must not modify SNMPv3 full standards document
[11:31:02] <SharonChisholm> - must work with all snmpv3 message types
[11:31:14] <SharonChisholm> - must be abvle to manage the box during times of network instability
[11:31:45] <SharonChisholm> juergen - additional requirement .... also difficult to configurre VACM ... need to look at that as well.
[11:32:22] <SharonChisholm> wes - my view, is an important problem ... but should not marry them together ... some solutions may not be able to support VACM type stuff.
[11:32:39] <SharonChisholm> juergen - solutions be open for adding VACM support later
[11:32:48] <SharonChisholm> wes - should not do anything that will preclude VACM later
[11:32:59] <SharonChisholm> wes - somewhat up to area director ...
[11:33:35] <SharonChisholm> russ - one of the strong emphasis in SNMPv3 is to separate and do things individually. we have it at full standard ... it took too long to do it .. careful to do too much at once
[11:34:10] <SharonChisholm> chris - just want to clarify what I heard ... shodul make it a requiremetn that integration with a mechanism to integrate with VACM is requirement ... or rather that we don't preclude
[11:34:41] <SharonChisholm> juergen - one comment ... if we say we do it over radius .... <something>
[11:34:53] <SharonChisholm> wes - if you are going to do radious extensions to support VACM ... <something>
[11:35:55] <SharonChisholm> eliot - the problem with that (can't be less secure than previous solution) is that USM is very secure. assumes no trust .. difficult to support in other ways
[11:36:15] <SharonChisholm> wes - let's take some examples <examples> ...
[11:36:45] <SharonChisholm> eliot - confused ... i don't see how this is a acheivable
[11:37:08] <SharonChisholm> q - <doesn't think it's acheivable>
[11:37:41] <SharonChisholm> wes - it may not be possible ...
[11:37:57] <SharonChisholm> eric (boeing) - restate it that you can't turn off authentication
[11:39:31] <SharonChisholm> sharon - this is a goal .. to understand any loss of security and ensure we do this for a very good reason
[11:39:47] <SharonChisholm> wes - manage via network problems
[11:39:56] <SharonChisholm> chris - desirable ... not requirement
[11:40:12] <SharonChisholm> minimal impact on managers and agents
[11:40:27] <SharonChisholm> minimal impact on performance
[11:40:46] <SharonChisholm> resulting system must be manageable via snmp
[11:40:59] <SharonChisholm> any other discussion on requirements?
[11:41:16] <SharonChisholm> --
[11:41:18] <SharonChisholm> Charter Bashing
[11:41:30] <SharonChisholm> Housed in security area
[11:41:35] --- Eliot has become available
[11:41:45] <SharonChisholm> Integrated Security Module for SNMP [ISMS]
[11:42:01] <SharonChisholm> I don't think I should chair the working group since I'm (wes) doing one of the drafts
[11:42:13] <SharonChisholm> Some history is listed in the Charter
[11:42:41] <SharonChisholm> deploying snmpv3 would be problematic in large deployments ...
[11:43:37] <SharonChisholm> bert - so, this makes it sounds that it is just the security model .. as we have discussed there is also the VACM stuff ... we should make it clear it is not just the security and everything will be peachy
[11:43:44] <SharonChisholm> wes - anyone object?
[11:43:48] <SharonChisholm> <no>
[11:44:15] <SharonChisholm> focus ... SNMPv3 secuity model meetings the need of operators and netowrk adminsitrators
[11:44:41] <SharonChisholm> includes - local accounts; radius ; TACACS+ ... I might have been presumtuous in this list
[11:45:15] <SharonChisholm> q - mentioned TACAC+ ... give that TACAC+ is not a standard .. does that affect it use
[11:45:29] <SharonChisholm> eric (boeing) - either are local accounts
[11:45:47] <Eliot> [q is from Kuashik Narayan]
[11:45:59] <SharonChisholm> wes - primary goal is to please the operator ... my aswer would be ... if we decide that is an important to do ... we do
[11:46:27] <SharonChisholm> wes - local accounts not included in an RFC ... discounting the top use things because we don't want to figure out how to reference .. not good
[11:46:42] <SharonChisholm> eric (boeing) - have list that it is desirable to support, but not a must at this point
[11:46:49] <SharonChisholm> wes - take list from bar graph?
[11:47:25] <SharonChisholm> eric (boeing) - fine ... large enterprise ... converned with scaling ... do use radius ... but it doesn't scale well for this use .. smaller enterprise it is great though... who to solve
[11:47:51] <SharonChisholm> wes - personal opinion ... the one that can meet the most needs were the ones that had the most bar graphs ...
[11:48:24] <SharonChisholm> randy - i have some concern about just creating security model is too narrow .. there is also operational practice ... not just a protocol issue ...
[11:49:29] <SharonChisholm> chris - i think the protocol itself shoudl support the ability to do multiple auth mechanism ... shouldn't force devices that have never done TACACS to do TACACS
[11:49:31] <SharonChisholm> wes - agreed
[11:50:02] <SharonChisholm> q - frag on survey ... does the work of working group work go linear or exponential with the amount of solutions we do?
[11:50:05] <SharonChisholm> wes - good question
[11:50:27] <SharonChisholm> wes - it will be way too much work to define them all. we need to do what we need to do to please the most number of people
[11:50:52] <SharonChisholm> q - may need to do another survey with fewer choices
[11:51:10] <SharonChisholm> eliot - practical point ... auditing ... must answer my phone
[11:52:01] <SharonChisholm> eric (not boeing) - not sure if it is charter appropriate ... there are a minmum three working group looking at security frameworks which is really where you are going ... are you going to investigate these?
[11:52:12] <SharonChisholm> wes - you will find in some presentations later ... one uses EAP
[11:52:39] <SharonChisholm> q - i know you mentioned some of the peformance criteria ... can we be more explicit ... restrict round trips, for exaples
[11:53:05] <SharonChisholm> wes - trade off ... i don't know if we can predine some of this ... some methods will require more to get more security
[11:53:37] <SharonChisholm> <extreme load not excluded ....>
[11:53:55] <SharonChisholm> juergen - missing ... why isn't diameter in there?
[11:54:19] <SharonChisholm> juergen - general goal to get protocols to work together ... diameter will be well deployed
[11:54:42] <SharonChisholm> wes - tough to say where market will go ... probably should be in the list ... don't want to predict where operators will go.
[11:54:59] <SharonChisholm> juergen - 3GPP is using diameter .... might fit in here
[11:55:09] <SharonChisholm> wes - unless there is objection, i will add it to the list to consider
[11:55:12] <SharonChisholm> <no objection>
[11:55:41] <SharonChisholm> bert - have we agreed that instead of listing a number of things that must be supported into a list of things to be considered
[11:55:46] <SharonChisholm> <consensus>
[11:56:08] <SharonChisholm> q - based on bert's comment about VACM in the historty ... can we also include it in the goals?
[11:56:23] <SharonChisholm> wes - i would say is that we should figure out what we can bite off now ...
[11:56:44] <SharonChisholm> wes - guidance from the ADs ... we don't meet goals if we add too much
[11:56:49] <SharonChisholm> ... more charter bashing
[11:57:01] <SharonChisholm> - should not modify other aspects of SNMP
[11:57:11] <SharonChisholm> ... can add other stuff
[11:57:42] <SharonChisholm> work item - document definging integrated auth. security model for SNMPv3
[11:57:59] <SharonChisholm> nov 04 - decision about technical direction
[11:58:06] <SharonChisholm> nov 05 send stuff to IESG
[11:58:44] <SharonChisholm> ADs don't want this work to rathole
[11:58:56] <SharonChisholm> if we can't come to consensus in 6 months we will be shut donw
[11:59:26] <SharonChisholm> chris - on the dates ... I beleive that this is after the cut off for the next meeting ...
[11:59:28] <SharonChisholm> wes - what is
[11:59:39] <SharonChisholm> randy - cut off will be in late october
[11:59:46] <SharonChisholm> wes - that is for publication
[11:59:56] <SharonChisholm> wes - i was aiming for the stuff in the room
[12:00:13] <SharonChisholm> wes - i will put something in there about the document dates as well
[12:00:38] <SharonChisholm> any other charter related issues?
[12:01:15] <SharonChisholm> bert - you mentioned this six months .. i would prefer that we charter the six months .. then we see where we are and then consider rechartering at that point
[12:01:37] <SharonChisholm> wes - yes ... I didn't mention that ... then the last bullet goes away and gets replaced with a recharter bullet
[12:01:54] <SharonChisholm> <next ietf in march ... align to that>
[12:02:35] <SharonChisholm> steve b - one consequence of this .... want working groups to make tough decisions early ... not union requirement lists .. pick directions ... don't want deadlocks in two years
[12:02:45] <SharonChisholm> bert - do we all agree with that
[12:02:48] <SharonChisholm> <yes>
[12:03:14] <SharonChisholm> wes - missed randy's preso on list of proposla
[12:03:36] <SharonChisholm> there are three proposals ... 10 minutes each.
[12:04:18] <SharonChisholm> EUSM, KSM, SBSM, TLS
[12:04:37] <SharonChisholm> plus randy's presp
[12:04:39] <SharonChisholm> preso
[12:05:07] <SharonChisholm> ----
[12:05:51] <SharonChisholm> External User Security Model
[12:06:10] <SharonChisholm> deployment issues with SNMPv3
[12:06:17] <SharonChisholm> - snmpv3 does not integrate
[12:06:36] <SharonChisholm> - standard does not address key management
[12:07:16] <SharonChisholm> Design Considerations
[12:07:51] <SharonChisholm> - security model for SNMPv3 - integrate with AAA server ... strong auth and key exchange ... minimize changes
[12:08:13] <SharonChisholm> - security model MUST - extend capability of AAA server ...
[12:08:25] <SharonChisholm> wes - none of them should modify the packet? that would be bad
[12:09:09] <SharonChisholm> Kuashik - <response I've mainly missed> did not want to change what agents are doing today for USM processing
[12:09:29] <SharonChisholm> - support variety of things
[12:09:48] <SharonChisholm> - deployment scenarious ... lots of agents ... few managers ...
[12:10:00] <SharonChisholm> - avoid a AAA request for every SNMP request
[12:10:10] <SharonChisholm> - generic scheme. ... support existing profiles
[12:10:31] <SharonChisholm> EUSM overview (Picture)
[12:10:36] <SharonChisholm> uses EAP
[12:10:55] <SharonChisholm> SNMP manager talking to AAA Server
[12:11:05] <SharonChisholm> AAA Server also talking to SNMPv3 Agent
[12:11:23] <SharonChisholm> the communication between the SNMP Manager and the SNMPv3 Agent is "SNMPv3 Packet"
[12:12:57] <SharonChisholm> q - basic question ... in terms of EAP management framework ... three part exchange .. how does it relate to this ... some of your communications don't seem right
[12:13:11] <SharonChisholm> Kuashik - that is why it is a dotted line (manager to AAA server)
[12:13:29] <SharonChisholm> q - just like client
[12:13:49] <SharonChisholm> q (new) - although you could have direct communication
[12:14:12] <SharonChisholm> Kuashik - what we beleive ... ip peers ...
[12:14:41] <SharonChisholm> q (first one) - radius model is changing ... that is what it looks like ... need radius shared secret between those wo points ...
[12:14:48] <SharonChisholm> Kuashik - let me go through it
[12:14:58] <SharonChisholm> EUSM overview
[12:15:38] <SharonChisholm> - EUSM will be the AAA protocl to obtain keying material for the user form the AAA server for achieving the security goals defined for USM
[12:16:07] <SharonChisholm> <other things on slide>
[12:16:20] <SharonChisholm> q - there is a negociated lifetime .... where is it negociated
[12:16:45] <SharonChisholm> Kuashik - EAP is negotiating master session key .... AAA server will send down lifetime ... config specified on AAAA server
[12:17:06] <SharonChisholm> q - understand the AAA server ... lifetime betwen manager and SNMP agent ... how does that lifetime get negociated
[12:17:42] <SharonChisholm> Kuashik - the client actually gets a master session key ... knows how to localize ... described in USM ... <more stuff> ... the agent does not have keys .. goes to AAA to request keys
[12:17:51] <SharonChisholm> q - manager does not operate a key cahce
[12:17:55] <SharonChisholm> Kuashik - no it doesn't
[12:17:59] <SharonChisholm> q - the agent does
[12:18:02] <SharonChisholm> Kuashik - yes
[12:18:15] <SharonChisholm> wes - point of order --- this is should all be high level
[12:18:28] <SharonChisholm> wes - do deep dives off line
[12:18:40] <SharonChisholm> EUSM with EAP between Manager and AAA Server
[12:18:53] <SharonChisholm> EUSM with EAP in the 802.1x like model
[12:19:22] <SharonChisholm> SNMPv3 Trap and Informa Processing
[12:19:54] <SharonChisholm> - trap flow same as SNMPv3 defined
[12:20:06] <SharonChisholm> - inform some what different ... things get inverted
[12:20:32] <SharonChisholm> q - in terms of the two models ... two sets of identities ... user and machine?
[12:20:43] <SharonChisholm> Kuashik - no. actually it is user in both cases
[12:21:14] <SharonChisholm> Kuashik - today when we do traps ... it is user receive for trap or inform ... that would still exist ... without that it doesn't know which principle to use
[12:21:22] <SharonChisholm> q - we can discuss on list ... I'm concerned
[12:21:36] <SharonChisholm> EUSM with Radius for Key Distribtion
[12:23:17] <SharonChisholm> <mentions VACM>
[12:23:34] <SharonChisholm> Key Caching
[12:23:55] <SharonChisholm> - two sets of keys - master session key - cached 8 hours or so
[12:24:16] <SharonChisholm> then there are the short burst cached on .... session keys ... 90-180 seconds
[12:24:29] <SharonChisholm> implementation status
[12:24:55] <SharonChisholm> - started to implement in IOS ... pretty close to complete .... doing prototypes on network managemet and AAA applications ... in the middle of that
[12:25:04] <SharonChisholm> not run into any implementations problems
[12:25:10] <SharonChisholm> we can discuss more offline ..
[12:25:12] <SharonChisholm> ----
[12:25:17] <SharonChisholm> Next up Mike with kerberos
[12:26:21] <SharonChisholm> most recent draft draft-hornstein-snmpv3-ksm-02
[12:26:33] <SharonChisholm> initialize SNMP manager with FDC
[12:26:42] <SharonChisholm> <oops KDC>
[12:26:57] <SharonChisholm> initial snmp manager to agent communication
[12:27:22] <SharonChisholm> - sends a kerberose request
[12:27:59] <SharonChisholm> - gets response
[12:28:27] <SharonChisholm> - in current draft - sends ticket everytime ... could just send integer id
[12:28:42] <SharonChisholm> snmp manager to agent normal
[12:28:49] <SharonChisholm> All KSM Messages
[12:29:14] <SharonChisholm> <the manager is the one talking to the KDC ... the agent is only talking to the manager>
[12:29:22] <SharonChisholm> q - <missed it>
[12:29:45] <SharonChisholm> bernard - one question on the list was how you got the VACM?
[12:29:55] <SharonChisholm> bernard - does it go into the <something> field?
[12:30:11] <SharonChisholm> wes - there is nothing in the draft that talks about it ... i think they should be separate
[12:30:24] <SharonChisholm> wes - the implementation has its own security model .... we used <something> to get VACM in there
[12:30:41] <SharonChisholm> ----
[12:30:47] <SharonChisholm> Next up with Randy
[12:31:53] <SharonChisholm> Minimally Integrated Access Security Module Application
[12:32:01] <SharonChisholm> - I thought of this earlier this week ...
[12:32:17] <SharonChisholm> goals - provide for integration with existing security stuff with as few changes as possible
[12:32:38] <SharonChisholm> - specification and implementation goals
[12:32:52] <SharonChisholm> - maximize compatbility with existing specs
[12:32:57] <SharonChisholm> - minimize mib changes
[12:33:09] <Eliot> (eliot taking over)
[12:33:20] <Eliot> Randy: more limited goals,
[12:33:25] <Eliot> allow key lifetimes to be limited
[12:33:30] <Eliot> support "on demand" update of keys
[12:33:33] <Eliot> no on the wire changes
[12:33:48] <Eliot> speaking SNMP operational terms rather than security terms
[12:34:10] <Eliot> in the USM, what i'm proposing that we do a MIB extension that we set an expiration date for a USM user
[12:34:15] <Eliot> it's an AUGMENTS
[12:34:24] <Eliot> default behavior is "never expires"
[12:34:28] <Eliot> thus as things are today
[12:34:50] <Eliot> two objects are not-accessible for notifications, which is why we have to do this
[12:35:06] <Eliot> if we only did update of keys for expiring stuff rather than on demand,
[12:35:15] <Eliot> we wouldn't have a problem either
[12:35:39] <Eliot> so, need to send engine-id, user, date
[12:35:47] <Eliot> both on receipt of pdus and attempts to transmit pdus
[12:36:15] <Eliot> and so if i find that the keying material is expired, i need to update...
[12:36:38] <Eliot> configure VACM to allow security administrator to update keys
[12:36:45] <Eliot> can't have a user extending their own expiration time ;-)
[12:37:06] <Eliot> configure vacm to allow secured delivery, so that this stuff doesn't fly around in the clear
[12:37:38] --- bert has left: Disconnected
[12:37:43] <Eliot> configure SNMP-TARGET-MIB and SNMP-NOTIFICATION-MIB to securely deliver any usmExpiredUserNotification to a security admninistrator assistant application.
[12:38:24] <Eliot> so - from the user point of view, just discard and let the application retransmit
[12:38:33] <Eliot> super conservative approach
[12:38:47] <Eliot> then you have a security administrator application
[12:39:03] <Eliot> uses whatever key management protocols you've got
[12:39:12] <Eliot> does put constraints on what you're going to work with
[12:39:28] <Eliot> then this application works with SNMPv3 to update keying material.
[12:39:37] <Eliot> could optionally do it do other systems it knows about
[12:39:56] <Eliot> q does the agent have some mechanism to download keys for users that don't have a role defined?
[12:40:13] <Eliot> Randy: unknown users go to this application
[12:40:35] <Eliot> [discussion about goals]
[12:40:49] <Eliot> kaushik: how does this protocol integrate with an existing radius server?
[12:41:33] <Eliot> Randy: not sure. presumes that the security administration assistant would [mediate]
[12:41:46] <Eliot> Wes: probably won't work with PK solutions
[12:41:58] <Eliot> Wes: security assistant is trusted
[12:42:10] <Eliot> Randy: at a protocol level this is USM
[12:42:29] <Eliot> [q] is it distinguishable whether entries are dynamic or static?
[12:42:49] <Eliot> how long it exists is up to the security administrator application
[12:43:46] <SharonChisholm> Eliot - operationally speaking ... what would you invision the experiation lifetime to be
[12:44:01] <SharonChisholm> randy - depends ... ideally you would want to be practive
[12:44:15] <SharonChisholm> eliot - disgrunted imployee ... how fast to shut donw
[12:44:28] <SharonChisholm> randy - you can always just nuke them manually using USM
[12:44:41] <SharonChisholm> wes - let's just ask technical questions ... then bash later
[12:44:55] <SharonChisholm> randy - not trying to solve scalability issue right now
[12:45:17] <Eliot> shortcomings
[12:45:27] <Eliot> other than key expiry, no improvement to security
[12:45:35] <Eliot> Eliot: not sure that's a shortcoming
[12:45:55] <Eliot> Randy: currently munges unkonwn user and expired key together. perhaps it makes sense to separate
[12:46:37] --- bert has become available
[12:46:49] <Eliot> chris elliott: anything that allows for compatibility of existing usm is a good thing
[12:47:12] <Eliot> Chris: [this mechanism might not be mutually exclusive with other solutions]
[12:47:39] <Eliot> Chris: and this might be good enough, but I don't think so. But it still is useful.
[12:47:56] <Eliot> Randy: agrees
[12:48:15] <Eliot> Wes: we have to make a tradeoff for how much code we want written
[12:48:57] <Eliot> Wes: Session-based Security Model for SNMP
[12:49:03] <Eliot> Wes: started in Vienna
[12:49:18] <Eliot> creates a session between two points
[12:49:33] <Eliot> you get some nice properties out of having a session
[12:49:46] <Eliot> this presentation is higher level than what I gave in the last BioF
[12:50:13] <Eliot> all security parameters are negotiated, so there's backward compatibility with applications
[12:50:24] <Eliot> added compression before encryption
[12:50:32] <Eliot> supports multiple types of identification
[12:50:48] <Eliot> reuses existing infrastructure; identities are protected from sniffers
[12:51:04] <Eliot> initiator's identity is protected from active attacks
[12:51:16] <Eliot> requires no outside infrastructure, but can make use of outside infrastructure
[12:51:29] <Eliot> able to handle all authentication needs
[12:51:37] <Eliot> authenticates both sides independently
[12:51:48] <Eliot> usm had a limited replay capability
[12:51:58] <Eliot> based on SIGMA key exchange protocol
[12:52:07] <Eliot> really just a dh exchange to create random session keys
[12:52:18] <Eliot> SIGMA is a PROVEN secure protocol
[12:52:28] <Eliot> all used by IKEv12
[12:52:35] <Eliot> s/IKEv12/IKEv2
[12:52:57] <Eliot> divided into 3 phases - initiatization, running, closing
[12:53:25] --- MichaelOnJabber has become available
[12:53:37] <Eliot> initialization PDUs sent are GET/REPORT PDUs but the application never sees them. similar to engineid discovery today
[12:53:48] <Eliot> [message flow diagram]
[12:54:23] <Eliot> four pass exchange [init 1-> init 2<- init 1-> running <-
[12:54:55] <Eliot> questions?
[12:55:29] <Eliot> ekr: this commits you to dh
[12:55:36] <Eliot> Wes: yes
[12:55:53] <Eliot> q: how much additional complexity is involved with using different types of credentials?
[12:56:41] <Eliot> likely similar to TLS in character
[12:57:03] <Eliot> wes: prefer 2 party authentication system
[12:57:14] <Eliot> ekr: is there a checksum over the protocol?
[12:57:16] <Eliot> wes: yes
[12:57:28] <Eliot> wes: I am a security geek by nature, and thus i'd like others to review it
[12:58:04] <SharonChisholm> q - <stuff> lots of agents ... clearly something to look at ...
[12:58:30] <SharonChisholm> wes - tons of applications now ... that do not do algorithmic engine id thing ... too complex .. would rather lose the two packets
[12:58:53] <SharonChisholm> randy - part of it .. we have excape hatches for multiple methods .... don't know ahead of time how it was generated
[12:59:10] <SharonChisholm> wes - it was intentional too ... i have some problems with some of the engine id stuff
[12:59:24] <SharonChisholm> wes - we are negociate context engine id
[12:59:28] <Eliot> discussion of security engine id versus conext engine id
[12:59:40] <Eliot> wes: should work with proxy
[12:59:48] <Eliot> wes: should work through nats as well
[13:00:09] <Eliot> back to the agenda:
[13:00:23] <Eliot> wes: we've seen all the technical proposals on the table.
[13:00:34] <Eliot> wes: as agreed to earlier, please publish any new proposals by oct 19
[13:00:43] <Eliot> wes: how do we narrow down proposals?
[13:01:09] <Eliot> [comparison chart]
[13:01:21] <Eliot> wes: we don't have the time to go through the whole thing
[13:01:32] <Eliot> wes: there are lots of tradeoffs
[13:01:39] <Eliot> wes: all the items on it are simply security features
[13:01:58] <Eliot> [discussion of the list]
[13:03:26] <Eliot> does it provide identity protection? only sbsm
[13:03:42] <Eliot> does it support perfect forward secrecy?
[13:03:58] <Eliot> sharon: this comparison list doesn't bear much resemblence to goals
[13:04:07] <Eliot> wes: yes, this is a security list...
[13:05:24] <Eliot> USM line is unmodified USM line, not Randy's proposal
[13:05:34] <Eliot> different auth rights = different access rights?
[13:06:41] <Eliot> wes: we still need a spec for TLS
[13:07:18] <Eliot> wes: which one of these are important, or should we defer?
[13:07:31] <Eliot> sharon: how about "is this a problem worth solving?"
[13:08:02] <Eliot> call of the vote: there is consensus to move forward
[13:08:20] <Eliot> (lots of hands for, no hands against)
[13:08:25] <Eliot> Bert: we need a chair
[13:09:22] <Eliot> Wes: anything else?
[13:09:27] <Eliot> Bert: resubmit the charter, please
[13:09:58] <Eliot> Bert: do we need a goal for additional submissions?
[13:10:03] <Eliot> Wes: that's the october goal
[13:10:35] <Eliot> q: do you thnk it's important for this group to widely publicize?
[13:10:46] <Eliot> Wes: goes out with the WG announcement
[13:11:07] <Eliot> Bert: fastest path to WG creation is 4 weeks.
[13:11:59] --- jishac has left: Disconnected
[13:12:16] <Eliot> [discussion of calls for new proposals]
[13:12:45] <Eliot> [discussion about how complete proposals has to be]
[13:12:53] <Eliot> Wes: have at least proof of concept
[13:13:43] <Eliot> Sharon: lots of commonality between proposals. 50% of these solutions are doing things in the same way?
[13:14:03] <Eliot> wes: go into more depth in comparison of choices.
[13:14:18] <Eliot> wes: security drafts are hard to read due to complexity and ramifications
[13:14:44] <Eliot> ekr: the really important question - what authentication mechanism do you want to support?
[13:16:04] <Eliot> ekr: decide the list of supported authentication protocols before doing the protocol hackery
[13:16:54] <SharonChisholm> wes - valid question ... lots of solution to the problems that won't meet the needs going forward
[13:17:09] <SharonChisholm> wes - kerberos is the oldest and may not meet the needs unless we add some stuff
[13:17:17] <SharonChisholm> wes - if we are going to do something by oct ...
[13:17:36] <SharonChisholm> ekr - seen protocol decisions ... comparing ... could modify things ...
[13:18:30] <SharonChisholm> randy - what we have is some proposals ... integration with specific things ... authors of those proposals their things could accomodate other infrastructures ... likewise the general people need to consider if there are constraints for integrating with specific solutions
[13:18:51] --- Eliot has left: Disconnected
[13:19:05] <SharonChisholm> wes - what do you support ... is it extensible to support things in the future
[13:19:33] <SharonChisholm> wes - we designed ours .... new mechanisms for the future ... TLS you would expect to me easy to bootstrap in many ways
[13:19:47] <SharonChisholm> wes - put together a template for people to use
[13:20:00] <SharonChisholm> bert - need to careful that the template does not turn into a feature creep list
[13:20:24] <SharonChisholm> steve b - worth asking which of these are really needed.
[13:20:33] <SharonChisholm> wes - list of security features
[13:20:55] <SharonChisholm> sharon - clarify that this slides is not the template
[13:21:01] <SharonChisholm> wes - we are out of time
[13:21:14] --- MichaelOnJabber has left: Disconnected.
[13:21:16] <SharonChisholm> wes - consensus on how to move froward ... other things
[13:21:26] <SharonChisholm> wes - will people stay in the room?
[13:22:09] <SharonChisholm> wes - quick show of hands ... exploring the various ones ....
[13:22:20] <SharonChisholm> all of them
[13:22:44] <SharonChisholm> sharon - premature to rule out any of these
[13:23:00] <SharonChisholm> bert - <some history of TLS>
[13:23:43] <SharonChisholm> chris - don't think TLS alone will meet the requirements
[13:24:14] <SharonChisholm> eric (boeing) - don't think we should put much emphasis on the voting
[13:24:35] --- dinakar has left
[13:24:42] <SharonChisholm> eric (not boeing) - two sides ... client/server ... manager/agent ... most schemes assume either shared key or <something>
[13:24:55] <SharonChisholm> wes - always have bootstrap issues
[13:25:09] <SharonChisholm> eric (not beoing) - .... <something>
[13:25:28] <SharonChisholm> q - goes back to our goals ... snmpv3 to allow each packet to decide ... TLS not so much
[13:25:42] <SharonChisholm> eric (not boeing) - why is that an attractive goal?
[13:25:58] <SharonChisholm> q - if CPU intensive ... might not want to do encryptiong ...
[13:26:09] <SharonChisholm> eric (not boeing) - not sympathetic
[13:26:36] <SharonChisholm> <discussion continues, but Jabber scibe has to leave>
[13:45:05] --- SharonChisholm has left: Disconnected
[13:51:14] --- bert has left: Disconnected
[20:18:56] --- stilletto422 has become available
[20:20:29] --- stilletto422 has left