[07:34:10] --- SharonChisholm has become available
[07:34:51] <SharonChisholm> Is this then the working group meeting
[07:50:56] --- kenh has become available
[07:57:18] --- Jim Galvin has become available
[07:59:39] <SharonChisholm> going though administrivia
[08:00:24] --- nov has become available
[08:00:33] <SharonChisholm> working group status - goal
[08:01:02] --- dinakar has become available
[08:01:06] <SharonChisholm> security model for snmpv3, address administrative tasks. Solution integrated into existing frameworks. Don't change snmpv3
[08:01:17] <SharonChisholm> oct 04 was the cut off date for proposals
[08:01:27] --- hartmans has become available
[08:01:36] <SharonChisholm> nov 04 is suppose to be the decision timeframe
[08:01:47] <SharonChisholm> in march 05 time to recharter
[08:02:06] <SharonChisholm> three proposlas - SBSM, EUSM, TLSM
[08:03:00] <SharonChisholm> most of these have already been discussed in previous meetings
[08:03:09] <SharonChisholm> agenda bashing
[08:04:03] <SharonChisholm> either talk about the decision process first or the presentations first
[08:04:13] <SharonChisholm> <no commnets>
[08:04:33] <SharonChisholm> so, decision process first then
[08:05:33] --- mlshore has become available
[08:05:39] <SharonChisholm> team to evaluate which one to move forward with ... then bring to working group for concensus
[08:05:57] <SharonChisholm> wes - can we reduce the number of proposals to bring to the team in case there isn't interest in all of them
[08:06:17] <SharonChisholm> Juergen - maybe. If there is only interest in one, then we can make a decision here today ;-)
[08:07:07] <SharonChisholm> Dave H - would suggest changing the order ... let's look at the proposals, then pros and cons then look at the requirements .... we might be willing to wave some of the requirements
[08:07:37] <SharonChisholm> Uri - hold opposite ... it is good to understand what probelm we are trying to solve and then see how the proposals meet the criteria.
[08:07:48] --- mstjohns has become available
[08:07:58] <SharonChisholm> ken - share uri's position .... would rather have the criteria first
[08:08:08] <SharonChisholm> wes - I agree with everyone but david
[08:08:34] <SharonChisholm> wes - we should look at ... requirements are imbedded in the charter ... we should look at those first.
[08:08:38] <hartmans> Keep in mind that a lot of these requirements are in our charter
[08:09:50] <SharonChisholm> dave p - last night I went a message about requirements ... what drove wes and I with SBSM ... operational usage and activities ... adding new users .. changing credentials, etc. I thought if we could do that for each of the proposals for these use cases
[08:10:20] <SharonChisholm> dave p - that would help us survice. Pain level is too high. If we can't reduce the pain level ... then this not worht it
[08:10:37] <SharonChisholm> ken - from charter ... "<stuff>"
[08:10:49] <SharonChisholm> usability
[08:11:19] <SharonChisholm> integration into infrastructure
[08:11:36] <SharonChisholm> keep SNMPv3
[08:12:05] <SharonChisholm> Q - are the requirements going to include what USM provides today and to provide those in the new thing?
[08:12:16] <SharonChisholm> ken - sure, we are just going through those defined in the charter right now
[08:12:46] <SharonChisholm> comply with RFC 3411
[08:12:57] <SharonChisholm> no changes to other protocols (SHOULD)
[08:13:05] <mstjohns> Q? - Is the text in the buffer at the beginning from the previous BOF on this?
[08:13:41] <SharonChisholm> <depends on your client.... the first line is me saying something about this being the working group meeting>
[08:13:52] <SharonChisholm> <mine had stuff from the last bof>
[08:14:24] <mstjohns> Mine has Elliot as the first text line with a time of about 12:54PM
[08:14:36] <SharonChisholm> per PDU encryption
[08:14:49] <SharonChisholm> discussion about per transaction versus per PDU
[08:15:11] <SharonChisholm> wes - some solutions lock you in ... lower transports lock you in ... don't negociate on a per transaction basis
[08:15:31] <SharonChisholm> wes - point of order ... what is within scope. I had a list ... some were nice to haves ...
[08:15:51] <SharonChisholm> per transaction security
[08:16:18] <SharonChisholm> wes - we could come up with a list that could be 30 or so long ...
[08:16:32] <SharonChisholm> wes - must not decrease charter ...
[08:16:38] --- ekr has become available
[08:16:38] <SharonChisholm> ken -not in charter
[08:16:43] <SharonChisholm> wes - been discussed
[08:17:09] <ekr> The performance rationalep for turning off crypto on a specific PDU is pretty dubious.
[08:17:16] <SharonChisholm> <elliot isn't in jabber right now>
[08:17:16] <ekr> Modern ciphers are extraordinarily fast.
[08:17:18] <mstjohns> - was "must not decrease security"
[08:17:49] <ekr> Esp. in view of the fact that you almost certainly want message integrity.
[08:17:56] <SharonChisholm> wes - some of the operators didn't want some of the strengths in USM ...
[08:18:15] <mstjohns> agree with EKR... but need to consider impact on agent vs impact on manager
[08:18:27] <SharonChisholm> <oops ... funny typo though>
[08:18:28] <kenh> ekr: I don't disagree, but some vendors are concerned about it, especially on embedded devices.
[08:18:48] <ekr> KenH: then they really need to produce performance numbers to support that claim.
[08:19:00] <SharonChisholm> wes - is somewhat subject to debate
[08:19:33] <SharonChisholm> uri - would like to take exception to wes .. they don't want to send passwords ... they want ease and convience
[08:19:43] <mstjohns> impact on agent is minimal....even for embedded agents
[08:19:47] <SharonChisholm> uri - they want convience, not weekness
[08:19:55] <ekr> though weakness is a bonus :)
[08:20:21] <SharonChisholm> ken - what else do people want?
[08:20:50] <SharonChisholm> Jeff Case - as I read charter ... concerned about usability ... 4 things .... that one sentence had 4 concepts ...
[08:21:07] <SharonChisholm> jeff c - <lists 4 concepts>
[08:21:27] <SharonChisholm> deployment success
[08:21:51] <SharonChisholm> jeff - what is the definition of success - filecabinet or being used?
[08:22:00] <SharonChisholm> jeff - third ... minimizing implementation costs
[08:22:31] <SharonChisholm> jeff - ought to make it a separate line item ... party based SNMP ... succeded on implementation and failted on deployment
[08:22:42] <SharonChisholm> jeff - we are good at the filing cabinet
[08:22:53] <SharonChisholm> time to market
[08:23:22] <SharonChisholm> jeff - one or more addresses something or concern to me ... in the past ... we have been sensitive to restrictions and regulations
[08:23:46] <SharonChisholm> jeff - our evaluation criteria ... import and export restrictions for top 20 countries
[08:24:09] <SharonChisholm> ken - ad wants to chime in here?
[08:24:32] <SharonChisholm> Steve B - we design technically sound protocols ... use as much crypto as necessary... let the lawyers fight it out
[08:24:49] <SharonChisholm> Q - I have no idea what usability means
[08:25:17] <SharonChisholm> Q - assume ... magically deploy in your box .... people who use it don't suffer too much ... if that is not what we mean, then we should be more clear
[08:25:57] <SharonChisholm> ken - pain in USM .. large scale reset of keys ... usability is harder to quantify ... <leaving out example ;-)>
[08:26:36] <SharonChisholm> Q - infrastructure ... rekeying .. left half ... right half is scalability ... tighted 7
[08:26:46] <SharonChisholm> Q - remove 2 ... over wordsmithing perhaps
[08:27:01] <SharonChisholm> Juergen - availability of functions and ease of using them
[08:27:24] <SharonChisholm> Q2 - when we get into these, we should talk about agents and managters and be clear which one you are talking about
[08:27:58] <SharonChisholm> Q3 - the best ... for deployment ... one requirements ... works with the credentially infrastructure you have ... don't want yet another smart card ... not as good.
[08:28:11] <SharonChisholm> Q3 - that might be worth mentioning explicitly
[08:28:17] <mstjohns> sorry - last four speakers were Jeff Case, Eric Rescorla, Mike StJohns, Sam Hartmann
[08:28:50] <SharonChisholm> Wes - what is what I was going to say ... refrase .... operator desirability ... flexible enough to work in their environment
[08:29:09] <SharonChisholm> <actually I got jeff, but 2/3 of the unknows were who you said .. thanks>
[08:29:09] --- kenh has left: Lost connection
[08:29:09] --- hartmans has left: Lost connection
[08:29:25] <SharonChisholm> wes - would operators want to use it.
[08:29:36] --- kenh has become available
[08:30:14] <SharonChisholm> sharon - i hope we quantify that is we use it ... it is very very fuzzy
[08:30:36] <SharonChisholm> dave h - like it vague ... meets all requirements ;-)
[08:30:54] <SharonChisholm> dave h - also want to integrate into management infrastructure
[08:31:14] <SharonChisholm> ken - for me the management piece needs to be done by the protocol proper
[08:31:51] <SharonChisholm> dave h - SNMPv2 party .. nice and secure .. needed to do stuff on the box ... couldn't discover the box until they configured it first ... not usuable.
[08:32:16] <SharonChisholm> dave h - shouldn'
[08:32:30] <SharonChisholm> dave h - have to provide the keys on the device before it can be discovered
[08:32:31] --- hartmans has become available
[08:33:04] <SharonChisholm> Dave p - when someone deploys and plugs into the network .. they havfe unrealistic expectations if they think they can manage it and do it securly
[08:33:36] <hartmans> You can perhaps manage securely after the first keying though. Limiting your exposure window
[08:34:01] <SharonChisholm> <I'm with Dave ... you need to be able to discover a box dynamically>
[08:34:15] <SharonChisholm> Dave P - let's enumerate the use cases better
[08:34:42] <SharonChisholm> Dave H - make a response .. you said you disagreed but I was talking about discovery and you talked about discovery
[08:35:05] <SharonChisholm> Dave P - if I put a box on the network ... then I shouldn't be able to use it
[08:35:21] <SharonChisholm> Dave H - need to be able to discovery, not necessarily manage it.
[08:35:37] <SharonChisholm> Dave p - unrealistic to think you can manage it
[08:35:50] <SharonChisholm> Everyone - no, we said *DISCOVER*, not manage
[08:36:05] <SharonChisholm> Dave p - this doesn't have anything to do with management
[08:36:05] --- mlshore has left: Replaced by new connection
[08:36:22] <SharonChisholm> Dave <something> - don't break basic discovery
[08:36:27] <hartmans> Wait, you don't have any guarantee that the device supports SNMP or has it enabled, do you
[08:36:30] --- mlshore has become available
[08:36:30] --- mlshore has left
[08:36:46] <SharonChisholm> K - it is critical to support discovery
[08:37:10] <SharonChisholm> Juergen - we have it, we can weigh the requirement later
[08:37:12] <hartmans> I.E. you cannot be guaranteed that all devices on your network will support SNMP discovery.
[08:38:18] <SharonChisholm> <No, but they often have it on for the type of boxes one plugs in. Plus personally I need to be able to discover boxes I don't know about for actual management reasons but that is a harder sell. Management is too expensive otherwise>
[08:38:36] <SharonChisholm> Juergen - more criteria for evaluation.
[08:39:03] <SharonChisholm> Dave h - 3412, noauthnopriv is specified in architecture, not in the USM bit
[08:39:27] <SharonChisholm> -------------
[08:39:32] <SharonChisholm> Dave - TLSM
[08:39:34] <hartmans> I don't see why discovery for management should be a hard sell; it's a different set of security assumptions, but no worse than say initial ssh connections.
[08:40:28] <SharonChisholm> <it depends who you are selling it to ;-) basically, some people don't undertstand the difference between discovering for monitoring purposes versus full out configuration >
[08:41:15] <SharonChisholm> Transport Mapping Security Model
[08:41:42] <SharonChisholm> Architecture
[08:42:29] <SharonChisholm> Lower Layer Protocols - TLS, DTLS, SASL, SSH, Others
[08:42:49] <ekr> The key question here is: is Datagram necessary.
[08:43:15] <ekr> Cause if so, that kind of means that TLS (without DTLS), SASL, and SSH aren't enough.
[08:43:20] <SharonChisholm> Which services ... report up to SNMP bit
[08:43:32] <SharonChisholm> auth, priv, others ....
[08:43:54] <SharonChisholm> interface between underlying and SNMP bit
[08:44:25] <hartmans> What's the draft name?
[08:44:35] <SharonChisholm> TM - Transport Model ... goes down and gets the specifics
[08:45:23] <SharonChisholm> http://www.ietf.org/internet-drafts/draft-schoenw-snmp-tlsm-00.txt (except it has been updated )
[08:45:49] <SharonChisholm> MP Portion
[08:45:59] <SharonChisholm> Message Processing
[08:46:15] <SharonChisholm> maps model-specific/mechanism-specific security principles to securityName
[08:47:01] <SharonChisholm> maps to SNMPv3 security levels ... this bit may need to do some analysis
[08:47:02] --- robpayne has become available
[08:47:08] --- robpayne has left
[08:47:31] <SharonChisholm> passes it thought various bits of the SNMP architecture picture
[08:47:35] --- mlavenstein has become available
[08:48:33] <SharonChisholm> Dave p - on mailing list, we said ... security services below the SNMP message, but SNMP emssage has the security level in it ... if you are using a new lower level stuff, do you then ignore the SNMP security bit, or is in concert ... what happens to the field ... is it redundant or a source of conflict?
[08:49:29] <SharonChisholm> bert - on receiving side ... if what is in the message header differs from the protoocl bit, what do you do? We just need to work this out ... similar to acknowledge or not ...
[08:50:10] <SharonChisholm> dave h - quick tangent ... this is a proposal put together at the last minute ... internet draft in repository ... really .. don't bother... nothing there ... posted a new one on thursday ... a lot of these questions are answered in there
[08:51:02] <SharonChisholm> Dave h - now to answer the question ... the message flag ... the mp portion does some additional analysis ... looks at message flags ... does this map to what has beenr equest ... if it is less than ... it is not acceptible ... then yo throw it away ... if greater then, we need to debate
[08:51:09] --- jhutz has become available
[08:51:17] <SharonChisholm> Dave p - do you encrypt it twice?
[08:51:36] <SharonChisholm> Dave h - you probably don't want to do double encryptyion
[08:51:41] <SharonChisholm> Q - it is a useless thing to do.
[08:52:39] <SharonChisholm> Q - an alternative thing to do .. do you think of these bits as signals between the sender and receiver or from one layer of the stack to another ... none of the transport bits we are talking about have the capability to do exactly what we need here
[08:53:18] <SharonChisholm> Q - similarly, on receiver side, if they don't want if you have ....it had to have been the implementation (if the message was not modieid)
[08:53:55] <SharonChisholm> Q - security systems where the bits and the eleged rprocessing don't match and that is an attack. In this case, it would just be a bad implementation
[08:54:27] <SharonChisholm> Wes - new question ... draft today .. newest.. only talks about architecture ... does not solve the hard bits ...how to map stuff
[08:54:30] --- jaltman has become available
[08:54:55] <SharonChisholm> dave h - there are appendices .. TLS .. for security name ... you used the username from the handshake protocol ... tyou indicated the type from the handshaking
[08:56:12] <SharonChisholm> Jeff case - got up to help with old Dave p question, ... the ASI at the invoker sayts I want to use security model and security level, if that model happenede to use transport layer security .... security level in the message part of that message would have noAUthnoPriv .. its ASI would indicate authPriv ... it would be transparent whether that was done at transport layer or the snmp layer.
[08:56:50] <SharonChisholm> jeff case - you could invision tha tthe layers would degrade ... message wrapper would been separate flags
[08:57:10] <SharonChisholm> jeff case - it probably would not be double encrypted unless we designed it that way.
[08:57:26] <SharonChisholm> dave p - minimally we would need a clarrification of ASIs
[08:57:38] <SharonChisholm> jeff case - how ASIs get mapped and what the elemetns of procedure were
[08:57:58] <SharonChisholm> jeff case - or when you did session set up .....
[08:58:19] <SharonChisholm> dave h - in first version of document... thought use message flags and pass through as is ... and then put in a second set of bits
[08:59:01] <SharonChisholm> uri - want to interupt and put in a few words ... dangerous to try to take complete control ... when it leaves your layer you can not guarantee what will happen ... not only is it difficult ... I'm starting to not like it
[08:59:27] <SharonChisholm> dave h - to continue .... was going to do two sets of flags in the message .. what was requested and what was mapped.
[09:00:11] <SharonChisholm> dave h - came to the conclusion that dealking with the ASM.1 stuff would not be worthwhile. new version of draft just uses a cache. includes set of flags to indicate what services were provided by the lower layer.
[09:00:30] <SharonChisholm> uri - in typical implementations you can't know what was provided by other layers
[09:00:45] <SharonChisholm> dave h - we have a mapping .. there needs to be trust ....
[09:01:14] <SharonChisholm> Randy - i think there are a lot of ways to attack this problem ... perhaps we should leave time for other presetations
[09:02:10] <SharonChisholm> wes - that having been said, I have just come accross some other problems .... if you encrypt and the manager didn't know it, you mess with benchmarking ... if sent over channel and manager said only encrpt ... agent receives it ... what does it send to VACM
[09:02:40] --- bert has become available
[09:02:55] <SharonChisholm> randy - if you are going to solve the problem .... don't mess with flags ....that way you will get the date that they asked for ... i might have a specific reason to ask for noAuthnoPriv
[09:03:50] <SharonChisholm> Q - new topic .. read the draft ... did you discuss how you handle with transports .. not all the same .. dome suppoort integration into radius server .. some don't. I don't know how you negociate
[09:04:08] <SharonChisholm> -----------------
[09:04:19] <SharonChisholm> SBSM - Wes
[09:04:37] <SharonChisholm> <Can someone take over for 5 mins or so?>
[09:05:15] <SharonChisholm> < please :-) >
[09:05:28] <SharonChisholm> Session-based securitry model for SNMPv3
[09:05:58] <SharonChisholm> draft-hardaker-snmp-sbsm-03.txt
[09:06:24] <SharonChisholm> <this stuff is all on the slides, I'll be right back>
[09:09:53] <hartmans> By ssh we mean ssh public keys, not the full ssh key exchange and userauth set?
[09:10:33] <SharonChisholm> <I'm back>
[09:10:51] <kenh> hartmans: yes
[09:11:28] <SharonChisholm> compression; identity disclosure protection; relay protection; reuses SNMPv3 when "possible", flexible enough to negot.
[09:11:36] <SharonChisholm> - based on SIGMA
[09:11:50] <SharonChisholm> implementation reports (wes')
[09:12:10] <SharonChisholm> done in net-snmp, but has not released it
[09:12:45] <SharonChisholm> look 19.5 hours to implement it
[09:13:06] <SharonChisholm> eric - I've read the draft and notice that you reimplemted IKE
[09:13:14] <SharonChisholm> wes - it is simpler than that. ....
[09:13:17] <SharonChisholm> eric - or not
[09:13:33] <SharonChisholm> eric - that is layer confusion .. sigma and ike are based on STS
[09:14:05] <SharonChisholm> eric - don't agree with your complexity assesemtn ... on whiteboards things look easy
[09:14:25] <SharonChisholm> eric - trying to build a system ... to throw in new security things ... ends up being a lot of work
[09:14:51] <SharonChisholm> eric - scared with YAWG creating YA Key exchange mechansim
[09:15:01] <SharonChisholm> eric - ike is complicated but it is done
[09:15:35] <SharonChisholm> wes - agree ... interoperability ... set you can do... must do .. limit the number of things you can negotiate ... encryption ... and authentication
[09:15:51] <SharonChisholm> eric - it took 4 years to do TLS ...
[09:16:22] <SharonChisholm> wes - when I said one to two pages to defined new mechanism ... that didn't include working group negotiations
[09:16:35] <SharonChisholm> wes - systems defined today and the ones I've been thinking of are trivial ...
[09:16:43] <SharonChisholm> wes - local accounts, ... other things.
[09:17:13] <SharonChisholm> wes - diffie - helmand ... etc
[09:17:15] <SharonChisholm> eric - my point. this is starting to get complicated
[09:17:20] <SharonChisholm> wes - i don't think we want to get into sematics
[09:17:29] <SharonChisholm> eric - things get complicated fast ...
[09:18:10] <SharonChisholm> Q - havn't read draft but, can you go back to flow diagram for a second ... seems to violate typical layer stuff ... an initiation via send a PDU and magic happens ... then dotted lines of closing ... how is closing done
[09:18:20] <SharonChisholm> wes - good question ... it was explained in another version i did
[09:18:54] <SharonChisholm> wes - <pointing and bits of the figure> .... the dotted lines ... application might close or lower layer libraries might close
[09:19:06] <SharonChisholm> wes - dotted line to accomodate both
[09:19:43] <SharonChisholm> Q - besides echoing what eric said ... we already have a lot of key exchange and authentication protocols ... don't want to see another ....
[09:19:47] <SharonChisholm> wes - dave's solution ....
[09:20:02] <SharonChisholm> Q - deriving keys to use with existing v3 stuff?
[09:20:17] <SharonChisholm> wes - no ... existing algorithms ... defines DES and AIS ...
[09:20:30] <SharonChisholm> wes - my stuff allows you to turn off des
[09:20:56] <SharonChisholm> Q - if transport layer model is going to be rejected, I think you may want to consider how per PDU is used and use something else
[09:21:01] <SharonChisholm> Q1 - out of charter
[09:21:07] <SharonChisholm> Q - then review things
[09:21:11] <SharonChisholm> <modes>
[09:21:44] <SharonChisholm> Q - i think it would be best to not reinvent key exchange.
[09:21:53] <SharonChisholm> wes - so you prefer dave's stuff?
[09:22:04] <SharonChisholm> q - no, I'm saying you something that exists like IKE
[09:22:39] <SharonChisholm> wes - you could put the same ike exchange in the ... sign all aspects ... it would be possible... ike has had a lot deployment issues.
[09:23:10] <SharonChisholm> wes - could plug in an existing exchange mechanisms
[09:23:40] <SharonChisholm> eric - three levels of separate - key exchange is one of them.
[09:24:00] <SharonChisholm> wes - the third preso will discuss some of this
[09:24:47] <SharonChisholm> eric - choice between transport mapping and application specific algorithm .... the choice of what key exchange protocol to use once you decide to intrate SNMP models .... i think it is orthogonal
[09:25:29] <SharonChisholm> wes - history ... aftering figuring out .. operators so many forms of authentication ... people complian about the authentication bits not the application bit ....
[09:25:37] <SharonChisholm> wes - long ago, ken and I did kerberose.
[09:26:15] <SharonChisholm> eric - there are a minimume of 4 ... EAP, TLS, SSH and two more
[09:26:33] <SharonChisholm> eric - there is a high burden on why you can't use one of them.
[09:26:55] --- mstjohns has left: Replaced by new connection
[09:26:55] --- mstjohns has become available
[09:26:56] --- mstjohns has left
[09:27:05] --- mstjohns has become available
[09:28:50] <SharonChisholm> sharon - let's make sure we don't invent new things when we don't need to ... it would make the problem worse
[09:28:57] <SharonChisholm> ---------------------
[09:29:06] <SharonChisholm> EUSM
[09:29:34] <SharonChisholm> Design Considerations
[09:30:13] <SharonChisholm> we started working on this three years ago
[09:30:21] <SharonChisholm> - we wanted to integrate into CLI
[09:30:42] <SharonChisholm> - don't change SNMPV3 protocol
[09:31:25] <SharonChisholm> change one attribute on 5000 devices ... need to watch the overhead therefore
[09:31:55] <SharonChisholm> therefore negotiate with a third party
[09:32:24] <SharonChisholm> <the picture where the manager does talk to the key server>
[09:33:42] <SharonChisholm> key_setup protocol requirements - use existing protocols
[09:34:20] <SharonChisholm> radius/TACACS+\
[09:35:06] <SharonChisholm> trap and inform processing - someone different on account of authoritative source
[09:36:00] <SharonChisholm> the agent needs to set up the master session key
[09:36:14] <SharonChisholm> EAP as key-setup protocol
[09:36:34] <SharonChisholm> not just restricting to just EAP ... first choice
[09:38:09] <SharonChisholm> Radius - arrow between manager and radius server
[09:38:10] --- jaltman has left
[09:38:32] <SharonChisholm> randy - how does the radius server know which engineid to use. how does it know which to use from the radius request
[09:39:31] <SharonChisholm> k - <explanation> ... and we are also looking at mechanism to talk to engines it does not know aout
[09:40:08] <SharonChisholm> dave h - in snmpv3 we introduced it .. multiple engineIds per IP and multiple IP per engineID ... you can't use this to do the mapping
[09:40:25] <SharonChisholm> uri - you can authorize the user ...
[09:40:53] <SharonChisholm> k - most radius servers today ... have this sort of info .. i need to go back to proposal
[09:41:03] <SharonChisholm> key caching for short periods of time.
[09:41:42] <SharonChisholm> jeff case - why did you recommend such a short duration
[09:41:56] --- Jim Galvin has left
[09:42:28] <SharonChisholm> k - when we did a bunch of use cases for typical usage .. most of the change-based operations ... scheduled ... polling or change ... period is within that duration.
[09:42:47] <SharonChisholm> k - not applicable for all applications ... not definitive recommendation
[09:42:57] <SharonChisholm> k - do want to avoid caching for long periods of time.
[09:43:33] <SharonChisholm> implementation status - have prototype impl.
[09:43:51] <SharonChisholm> k - fabulous
[09:44:26] <SharonChisholm> k - wanted to avoid peer to peer negotiate for key negotiation since it doesn't scale
[09:44:36] <SharonChisholm> dave p - have you come out with new draft
[09:44:41] <SharonChisholm> k - sometime this week
[09:45:01] <SharonChisholm> dave p - in original draft ... talked about inband set up of the keys ...
[09:45:19] <SharonChisholm> k - the key set up protocol .. depends on the properties of the key set up protocol ...
[09:45:29] <SharonChisholm> dave p - don't want details,just want it covered
[09:45:51] <SharonChisholm> dave p - you use the term AAA, too fuzzy. sometimes it is radius, sometimes it is other protocols as well.
[09:45:59] <SharonChisholm> k - prototype was radius
[09:46:06] <SharonChisholm> k - have some tacacs
[09:46:19] <SharonChisholm> k - when I say AAA, i mean radius and TACACS+
[09:47:00] <SharonChisholm> dave p - with tacacs, you can't do this key set up and even if you could it would be very different from radius. this bothers me
[09:47:38] <SharonChisholm> k - two parts to proposal .. key set up protocol ... any of the protocols that we use that are defined in the IETF today. does not include AAA .. those are use dfor key exchange response
[09:47:56] <SharonChisholm> k - it does not require a change to the protocol to be able to acheive the exchange
[09:48:35] <SharonChisholm> dave p - most important question ... use case analysis ... you seem to have done, but you have not shown my use case .... new device, new user, change user, delete user, that is OPEX ... that is important
[09:49:13] <SharonChisholm> k - not an incrementatl cost for SNMP ... doing it in existing solutions cover most of these ... don't see that in other proposals as well.
[09:49:28] <SharonChisholm> dave p - use cases were presented in the <something>
[09:49:32] <SharonChisholm> Everyone - what?
[09:49:53] <SharonChisholm> Wes - the point is that none of the drafts cover this issue and its a working group question
[09:50:06] <SharonChisholm> juergen - would it be much different
[09:50:26] <SharonChisholm> dave p - there is a lot of magic and hand waving in the draft ... until I see concrete steps
[09:50:35] <SharonChisholm> dave h - i think that would be useful to have ... how to use the protocol
[09:51:05] <SharonChisholm> wes - it is still your model ... the use of an authentication server, means that the network is working ... the doc still says that if the network is not working things fall back to USM.
[09:51:15] <SharonChisholm> k - goes back to what you fallback is ... same as local user
[09:51:34] <SharonChisholm> wes - no huge difference ... forces another set of users ....
[09:52:00] <SharonChisholm> k - one is USM can support concept of loocal users which is no different than creating then through local users.
[09:52:13] <SharonChisholm> wes - they would only have to have one USM user fallback.
[09:52:16] --- mlshore has become available
[09:53:05] <SharonChisholm> <can't the USM be the same users and the radius stuff since you need to do a mapping from one to the other either way?>
[09:53:47] <SharonChisholm> uri - this is a big misundertanding ... USM is to provide the user name ... then there is VACM ... doesn't matter if it is locally defined ....
[09:53:54] <SharonChisholm> wes - he requires a network.
[09:54:04] <SharonChisholm> k - it will work on a broken network.
[09:54:14] <SharonChisholm> k - it falls back on USM ...
[09:54:33] <SharonChisholm> uri - in the beginning when there is little in USM ... if network is not up, you can't discover the thing.
[09:55:05] <SharonChisholm> Q - i don't see any reason to not colate the key server with the agent
[09:55:24] <SharonChisholm> ken - <story of past work when SNMP people screamed>
[09:55:32] <SharonChisholm> uri - want longer key lifetime
[09:55:58] <SharonChisholm> uri - helps case when network is down
[09:57:20] <SharonChisholm> randy - comment on all proposals .. reason with integration with existing stuff is important ... an operator want to be able to get access using a particular identiy and past phrase without having to know how well or how sick the network is, if there is a fallback to local account ... would like the local account as normal operation stuff.
[09:57:23] --- jhutz has left: Lost connection
[09:57:34] <SharonChisholm> randy - when we start looking at fallback ... how can we keep these things in synch
[09:57:46] --- mstjohns has left: Disconnected
[09:57:58] <SharonChisholm> k - I'll take an action to look at that.
[09:58:12] <SharonChisholm> ken - need to takie stuff to the mailing list
[09:58:31] <SharonChisholm> randys - this issue will existing with all of these except local accounts.
[09:58:42] <SharonChisholm> <yeah, that's what Randy said>
[09:59:07] <SharonChisholm> <uri was commenting or randy two comments ago>
[10:00:08] <SharonChisholm> elliot - comment on customer requirement ... unified managmenet ... when things are broken they consider it an exception ... they have a single fallback account ... they already handle that case today. recognize the requirement .... don't go overboard ... don't assume the same credentials
[10:00:23] <SharonChisholm> Dave h - how much is radius used on core devices
[10:00:31] --- mstjohns has become available
[10:00:34] <SharonChisholm> k - it's universal ... most operators have switched to use that
[10:01:09] <SharonChisholm> dave h - in snmpv3 architecutre ... we dropped agent and manager terminology ... you used agent and manager ... want to make sure we are not having to go back to that terminology
[10:01:19] <SharonChisholm> k - i need to clean up the draft
[10:02:03] <SharonChisholm> dave h - in order to do an inform ... agent needes to initiate the process ... what if there is already something set up on the manager side ...
[10:02:35] <SharonChisholm> k - we thought ... does the agent need to do a full set up ... what if there was already cached keys ... we used the optomization in our implementatiohn ... needs more discussion
[10:02:48] <SharonChisholm> dave h - radious provides group name ... what sort of record?
[10:03:03] <SharonChisholm> k- we have a customer things for the prototype ... we would need to define something standard
[10:03:11] <SharonChisholm> dave h - can the radius server revoke a key?
[10:03:26] <SharonChisholm> k - currently, no. That is one reason we have the cache time so small.
[10:03:30] --- ekr has left
[10:04:13] <SharonChisholm> k - master session key could be revoke on the server. the session key for each agent is difficult since there are no flows in that direction today
[10:04:26] <SharonChisholm> dave h - i thought AAA did have something, but I could be wrong
[10:04:30] <SharonChisholm> -----------------
[10:04:49] <SharonChisholm> juergen - time to go back to our criteria list
[10:05:50] <SharonChisholm> <back to excel>
[10:06:42] <SharonChisholm> Q - EUSM kind of looks like kerberose third authentication to me.
[10:07:32] <SharonChisholm> Q - EUSM might not be bad, but he fallback might have issues
[10:08:00] <SharonChisholm> k - the fallback is kind of been beaten to death. same as netconf and CLI.
[10:08:20] <SharonChisholm> q - don't duplicate databases everywhere
[10:08:43] --- mlshore has left
[10:08:59] <SharonChisholm> do they all offer the same level of security?
[10:09:14] <SharonChisholm> wes - tls potentially offers relay protection ...
[10:09:25] <SharonChisholm> uri - with that you lose the transport capability
[10:09:41] <SharonChisholm> wes - i had a slide there. i don't think you can fit that into this one cell
[10:09:52] --- mstjohns has left
[10:10:01] <SharonChisholm> eric - little concerned ... architecture features versus other stuff
[10:10:17] <SharonChisholm> eric - EUSM does key s...
[10:10:38] <SharonChisholm> <relay protection>
[10:11:03] <SharonChisholm> randy - use goofy objects in TC, you can get it without changing the protocol
[10:11:12] <SharonChisholm> <some of this EUSM might be talking about USM>
[10:11:39] <SharonChisholm> eric - sbbs style key exchange could be done without relay protection
[10:11:59] <SharonChisholm> eric - you could do something else without doing relay protection
[10:12:10] <SharonChisholm> chocolate
[10:12:17] <SharonChisholm> let's add chocolate
[10:12:36] <SharonChisholm> eric - let concentrate on things that are inherent rather than the minor design choices
[10:13:00] <SharonChisholm> juergen - let's go to the ones that are important here.
[10:13:19] <SharonChisholm> juergen - 9-11 are all fine ... let's go to 7,8
[10:13:45] <SharonChisholm> jeff case - perhaps 'ok' and 'not ok' isn't the right marking ... USM should be the baseline
[10:14:46] <SharonChisholm> wes - going to boil to a weighting discussion and we don't have time to resolve this
[10:15:09] <SharonChisholm> wes - some of these integrate into small set of integration technologies, some work on broken network, some don't
[10:15:32] <SharonChisholm> dave h - in models like TLSM if you don't do it right things could be worse ... hard to say that it is OK.
[10:16:32] <SharonChisholm> randy - all three of the proposals have in comment that isn't in USM is the concept of a session. with the introduction of this concept ... what sort of latency .. how many exchanges will it take to establish a session .. to terminate .... what is required operationally to introduct anew user
[10:16:53] <SharonChisholm> randy - remove a user ... given the caching .. how long ddoes it take to propegate things out.
[10:17:03] <SharonChisholm> randy - should be thinking about these things
[10:17:55] <SharonChisholm> eric - look at big picture ... key important question ... what rough sort of architecture ... integrate tightly into SNMP then SBSM ... layered over then you want to Transport stuff ... if you want an exernal system, then you want EUSM
[10:18:33] <SharonChisholm> eric - it doesn't make sense to talk about some of these individual requirements ... i can make them all to work.
[10:18:45] <SharonChisholm> eric - we need to chose architecture A, B, C first
[10:19:20] <SharonChisholm> wes - i agree ... slight caveat, need to be done soon, can we just pick the architecture direction can we gut one to make it all work by march.
[10:20:00] <SharonChisholm> sharon - picking the wrong solution 'cause we don't want gut a solution doesn't seem right either
[10:20:33] <SharonChisholm> Q - the more I think about it, i think EUSM is a mechanism for SBSM.
[10:20:56] <SharonChisholm> Q - concerned it won't be more scalable than kerberose
[10:21:07] <SharonChisholm> q - shifting around the burden from the manager to the agent
[10:21:19] <SharonChisholm> Q - don't think user to user kerberose will go faster than kerberose
[10:21:33] <SharonChisholm> ken - still only fair to keep them all.
[10:22:19] <SharonChisholm> wes - one of the goals of EUSM was not to modify SNMPv3. ... as far as integrating EUSM into SBSM ... we do their stuff already ...
[10:23:18] <SharonChisholm> randy - important feature in EUSM not in the other .. how it provides the <> .. dynamic adding and removing of users from ... hate to lose that... keep it under consideration
[10:23:31] <SharonChisholm> k - like to respond to statement that it isn't scalabily.
[10:23:41] <SharonChisholm> ken - no, he said that it wouldn't scale any better.
[10:24:05] <SharonChisholm> k - as far as the motivation ... wanted to make sure we make the minimal changes as possible.
[10:24:21] <SharonChisholm> k - minimize cost and risk
[10:24:42] <SharonChisholm> Q - I will be the AD for this group ... getting an architecture chosen by march would be making good progress
[10:25:02] <SharonChisholm> -------
[10:25:25] <SharonChisholm> juergen - don't think we will eliminate one of the proposals right now
[10:25:36] <SharonChisholm> juergen - we will pass to an evaluation team.
[10:25:55] <SharonChisholm> juergen - still forming the team ...
[10:26:12] <hartmans> AD will map to Sam hartman
[10:26:19] <SharonChisholm> <randy, lak>
[10:26:33] <SharonChisholm> <eric>
[10:26:46] <SharonChisholm> <chris>
[10:26:51] <SharonChisholm> <uri>
[10:27:31] <SharonChisholm> <nico>
[10:27:58] <SharonChisholm> ken - do we have operations people?
[10:28:34] <SharonChisholm> dave h - how many of the operators think these are all viable. I think we can eliminate
[10:29:08] <SharonChisholm> Q - (new AD) I would not be comfortable if you eliminated one today
[10:29:23] <SharonChisholm> juergen - let's not do this in a hury
[10:29:28] <SharonChisholm> dave h - ok. take it to the list.
[10:29:48] <SharonChisholm> wes - one of the goal is to streamline down quickly is we have a tight deadline.
[10:30:07] --- mlavenstein has left
[10:30:46] <SharonChisholm> Sam (new AD) - don't care if you eliminate one on the mailing list quickly is fine, but not enough time in this meeting.
[10:31:05] <SharonChisholm> <wrapping Up>
[10:31:08] <SharonChisholm> <and done>
[10:31:15] <SharonChisholm> :jester
[10:31:17] --- nov has left
[10:31:20] --- hartmans has left
[10:34:47] --- bert has left: Disconnected
[10:42:30] --- dinakar has left: Replaced by new connection
[10:42:30] --- dinakar has become available
[10:42:30] --- dinakar has left
[10:50:10] --- SharonChisholm has left: Disconnected
[10:57:16] --- kenh has left: Disconnected
[11:36:32] --- jaltman has become available
[12:11:12] --- bert has become available
[12:23:55] --- kenh has become available
[12:35:18] --- jaltman has left: Disconnected
[12:38:22] --- mlavenst05 has become available
[12:39:42] --- mlavenst05 has left
[13:07:27] --- kenh has left
[13:56:45] --- bert has left: Disconnected