Last Modified: 2004-10-04
| Oct 04 | Cut-off date for internet-drafts to be submitted to the working group for consideration as a proposed solution | |
| Nov 04 | Decision about which solution approach the WG will focus its efforts on | |
| Mar 05 | 2005 Working group will recharter to include publication goals or shutdown if no consensus on a technical direction is reached by this time |
|
Minutes for the Integrated Security Model for SNMPv3 (ISMS) WG
IETF 61, November 8th, 2004 The meeting was opened by chairs Ken Hornstein (KH) and Juergen Quittek (JQ). (JQ) - Review of meeting goals Oct 4 cut off for proposal submission Nov we decide which solution Currently there are three proposals: SBSM - A higher-level approach EUSM - Straight forward extension of USM to support AAA TLSM - SNMP over TLS (or some other transport mapping service). Traditional agenda bashing was next (minor changes to the order were suggested, but the original agenda order was kept). (JQ) - procedure Question, due we want to create evaluation team to decide on which proposal? Wes Hardaker (Wes) - maybe only examine proposals that work group want (i.e. not necessarily all three) JQ - let's select criteria for proposal acceptance Unknown - Perhaps we should use proposals to drive requirements Wes - lets bring it back to talking about criteria again Dave Perkins (DP) - looking at what drives operations for the same, we should look at each proposal to see if we can reduce the pain level for managers to use and implement. Ken - Our charter: maximize usability in environment integration into existing infrastructures. must not modify SNMPv3 protocol should be compliant with SNMPV3 security model, RFC 3411/2 if at all possible, don't change any other protocols Unknown - make sure existing SNMPv3 support isn't changed Ken - we're still going over charter right now. Ken - discussion of per-PDU encryption on the list, regarding the ability to have different encryption/authentication per PDU Wes - point of order, what things are in scope at this point are we listing anything (i.e. goals and/or requirements?), JQ - we should make a difference between requirements and nice to haves Wes - I believe one of requirements is must not decrease security. Ken - technically that is not in charter Wes - It has been discussed before. Jürgen Schönwälder (JS) - what does that mean? Wes - we can't create a new protocol that doesn't provide same strengths that USM provides. But some of operators didn't like strengths USM provides, they send passwords in clear so that they can log in to the machines. i.e. they don't find USM usable, so there may be some question as to what strengths we need to support. But we should have encryption / authentication capability and the protection of breaking one client not breaking all clients. Unknown - Operators pass passwords in clear for convenience; they prefer convenience in this case instead of security. Jeff Case (JC) - I'm concerned about usability line derived from the charter, can it be broken into 4 things from the line in charter: usability, deployment success, minimize implementation cost, quick time to market... usability minimum implementation cost minimum deployment cost time to market JC - should we consider what they export/import restrictions in top countries in world so that the technology selected is acceptable to most/all of them Steve Belovin (SB) [AD] - we design technically sound protocols, let the lawyers fight over legal acceptability. Unknown - questioning usability, be clearer on what we do mean. Ken - example of problem with USM, large scale re-keying of passwords... In the eye of the beholder. JQ - usability, what functions are needed and how easy is it to use them Michael St.John? (MSJ) - should differentiate between agent and manager Sam Hartman (SH) - deployment ease : security should work with existing the authentication infrastructure you have Wes - operator desirability, operators have varying environments so we should have flexibility in ISMS, (within reasons). Would operators want to use it?, would someone actually start using it? JQ - desirability Wes - should we strike usability JQ - we're high in abstraction, we should be talking about a lower level DH - 7 (integration into infrastructure) should be split into two parts, management and security integration Ken - management is done by SNMP proper DH - snmp parity as example, it was nice and secure but one had to go to the box to configure. people use HP OV to find devices on network but had to configure box before it could be discovered, it wasn't usable. DP - somewhat different view that when someone deploys a new box, if they just plug it into the network, they have unreal expectations if they think the can, without configuration, manage it and manage it securely. Many different ways to do initial configuration, but something that may not be obvious to anyone is that wouldn't it be nice if they didn't have to do anything extra to integrate with SNMPv3. Should go through use cases. DH - said you disagreed with what I said, but I just meant we should be able to do discovery DP - but I disagree, you should need to configure a box when putting it on a network DH - but I want to find a rogue box put on network. Ken - I think both are compatible DP - but different way of looking on world, a manager will need to configure any device put on network Unknown - don't break basic discovery. JQ - let's move this discussion off-line Unknown - we should support engine ID discovery for example JQ - on the list we have integration into infrastructure, let's keep requirements, but we can discuss details later. Uri - change item 12 ??? Ken - since we're not changing SNMPv3, USM is still there, engine ID discovery could be done via USM, just to throw an idea out there JQ - does any one think we should have more criteria here? DH - re URI, in RFC 3412 noAuthNoPriv specified in architectural portion not security portion. --- TLSM proposal Dave Harrington Transport Mapping Security Model lot's of people on list said they wanted to see a TLS model, so I did one. Not a strong proponent but I thought it needed to be done. Lower Layer protocols, TLS, DTLS, SASL, SSH, others... tried to create a proposal that would allow fitting a transport layer mapping to the SNMP engine. different protocols provide different services. TM model, should understand what service mechanisms? available, which services, which security principle DP - from the list, if we provide lower level transport, do you ignore the security level field in PDU or does it have to match the transport or what. How do these interact? DH - message flags are SNMP requirements, that must be communicated to lower layer. Bert Wijnen (BW) [AD] - on the receiving side if the two don't match, what do you do. It just needs to be worked out. DH - quick tangent, this was a last minute proposal, a new version of the proposal was published and a lot of these questions are answered in it. In the new version the MP portion does same analysis of message to see if security level maps to session. If PDU security level is greater than session it is dropped. undecided what to do if it PDU security level is less than session. Don't Know - alternative thing, ???, this is case that it isn't an attack but a bug in implementation Wes - the current draft doesn't talk about parameters to pass between different lower level protocols. DH - the appendix does have some mappings of security wrappings JC - addressing DP questions, the ASI at the invoker says wants to use a particular security level / security model. What's in the PDU may not match the security level of the SM or of the ASI information to the application.... The message wrapper of security model may need separate security bits to indicate security level and info separate from security level in PDU. DP - need clarification of ASI's JC - a proposal would need to define, in separate bits or others ??? Gary? - no complete control between layers... DH - in first iteration, I was going to pass to sets of bits, security model level and message and placed in security parameters. Didn't think ASN.1'ing of that was worthwhile. So new version of draft uses cache, a pointer is passed to indicate a session's security information for a packet. Randy? - should probably skip some of the technical aspects here and discuss on list Wes - just though of another problem. if encrypt packets that the manager doesn't know are encrypted it will mess up benchmarking. And more importantly it could mess up what is sent to VACM for access control. DH - if they don't match, ??? Randy - don't mess with flags if you need more security, it means you need to create a new channel (session). Unknown - how to handle different credential types with underlying transports. talks about Transpor Layer - SNMP transaction but not with security negotiations within the transport layer. JQ - next presentation, please. Wes - update of ISMS quick overview current is draft-hardaker-snmp-sbsm-03.txt creates session between two points 3 phases, init, running , closing The init PDU'S are get and report PDU's. Applications never see these PDU's. This is similar to engieID discovery or time synching today) picture of message flow... Re-uses all existing transports because not tied to it. SNMPv3 architecture, application compliant re-uses exist authentication systems to extend authentication definitions. compression, id disclosure protection, replay protection, negation but rigid??? based on SIGMA already have basic implementation 19.5 hours to implement (with a developer that has expert knowledge SNMP toolkit used) Eric - it's a re-invent of IKE Wes - much simpler than IKE, based on SIGMA not IKE Eric - both based on STS, I think that it's more complex than it looks. Adding new authentication schemes will each add a large amount of complexity. IKE's complex, but it is finished. Wes - I agree that inter-operability needs are important... ??? Eric - TLS took a long time to finalize exchanges, 2-4 years Wes - 1-2 pages to define, but that doesn't count WG consensus time. The current way is simple...??? Eric - key exchange will get complicated very fast. Unknown - haven't read draft, but flow diagram seems to violate some of the layers... How is closing done? Wes - applications can close, low layer library can close. It can be an application decision, a toolset issue not a protocol issue Nico Williams (NW) - besides echoing Eric, we (ietf) already have a lot of key exchange protocol, I don't want to see another. One thing that worries me is that you're deriving keys for the existing v3 model. Wes - no, only two modes defined in USM NW - if transport layer model is rejected, you might want to consider the way per PDU protection is done ??? adding new mechanisms to SNMPv3 NW - adding new mechanisms to SNMPv3 not within charter Wes - the reasons the modes are there today, is that is what is available to SNMPv3. NW - lastly shouldn't create a new key exchange protocol Wes - you could conceivable do IKE within in SNMPv3, but IKE has lots of deployment problems. I think we have two choices, place authentication / encryption in lower layer underneath or you do it within SNMP. Eric - three levels, lower layer, SNMP, or side negotiations. It is a choice between transport mapping and application specific protocol and which integrates better into SNMPv3 model. choice of which key exchange protocol to use determined by assessment of applicability of exchange models to user environment. Wes - some background, one purpose of ISMS is to fix a major complaint. People are not using authentication mechanisms of SNMPv3. Eric - at minimum there are already at least 4 ways to do key exchange and they support multiple protocols. Wes - so many mechanisms in use. it's difficult to choose. Unknown - pick one but don't go with all of them. Wes - I agree... I designed an architecture that would let this work group pick one. Unknown - shouldn't try to meet all cases. EUSM presentation -- Kaushik Narayan (KN) I'll talk about changes and uniqueness from other proposals. no new fields, but it uses existing SNMPv3 - USM as described in RFCs few small changes, setting up session is a high cost, so a goal was to have the session / key negotiation setup be done by third party. It uses existing key exchange protocols. EAP was one example in draft, but not only one possible. Randy - how does agent know what keying info to use with info from radius server. Dave Harrington - SNMPv3 created engine ID, because a differentiation was necessary. We need to the engine id for this. KN - caching, typical duration of 90-180 seconds for a 'session'. JC - why choose that length. KN - time window is not definitive just an example. want to avoid keeping keys on an agent for a long duration, but time should be configurable. It's not hard coded. It is configurable. KN - have a prototype implementation in AAA server and Cisco Works product. A motivations was as minimal changes to SNMP as possible, and also to make sure that peer to peer exchanges for key creation was not necessary (so use of third party AAA server) DP - have you come out with a new draft. KN - not yet DP - In the current draft, it talked about in-band set up of keys. Is that expanded upon in new draft? KN - It will be covered in new draft. DP - in draft and presentation the term AAA was used, this is fuzzy to me what does this mean more precisely Radius, TACX+?, etc... KN - when I'm talking about AAA in this context, I've been talking about Radius and TACX+, but I want to make the protocol more generic to allow others AAA servers. DP - ??? (question of fuzzyness of AAA term) KN - It does not require change in protocol to support different types of AAA servers. DP - It sound like you've done use case analysis, but I haven't seen a use case of what to do when one adds a new box, adds a new user, deletes a user,... ??? KN - reason to integrate with AAA servers is so that adding/deleting user is covered by adding deleting user to AAA servers. Other proposals don't show these use cases either. Should we cover these use cases? DP - use cases covered in IBSM in BOF's Wes - should the WG require the use case? DP - I'd like concrete steps to be able to understand how the protocols work. DH - I think that would be very useful Gary - and it would apply to all proposals DP - absolutely Wes - ???... people still need to use USM, big difference because the users today that don't use USM now, won't use it in the future if AAA server is down (faulty network case???). KN - ??? Wes - one USM user is required in this case and the operators do not have any currently. KN - if an authentication mechanism of local user is required, EUSM could add it easily. IBSM would have same problem. Wes - local user's already exist and IBSM can use local user, EUSM still requires a local USM user which don't exist. Gary - Could you clarify that? Wes - EUSM still requires AAA server, if the network is broken this is a problem. KN - can fall back to USM users? Gary? - if network not up, can't talk to machine anyway? Ken - using other servers in the past have raised many complaints in the SNMP community. Gary? - biggest comment is shortness of key lifetime, but should discuss on mailing list. DP - We should accept that we sometimes need quick revocation of keys (e.g. if someone is fired) Randy - a comment on all proposals. The reason integration of current security models is important is because operators want to log onto a machine without knowing how well or sick a network is. So with a fall back to a local account, you'd really like the mechanism to allow the same account to be able to fall back to the same user? KN - we'll clarify fall back to USM in draft. Ken - should take this to mailing list. Gary? - this issue will exist with any mechanism except local accounts. For revocation, either need to check over the network or fall back. Unknown - The way a broken device is handle today in operations, it requires special procedures to fall back to a local user. Particular you can't assume you can use the same credentials on the box as off. DH - I was wondering how much radius is used on core devices KN - I think it's pretty universal for edge or core. DH - in SNMP architecture we deliberatively moved away from manager-agent terminology and your draft uses those terms. KN - I need to clean up terminology in draft. DH - can the key from the manager side be used for informs? KN - one of the things we worried about is should the agent have to talk to the AAA server ...???..., think we should discuss this on list. DH - ?? KN - ?? DH - can a radius server revoke a key? KN - handle this via shortened key lifetime (although master key could be revoked on server) JQ - go back to criteria list, check blue sheets what are some of the key differences in proposals? KN - I think one of the big difference is use of third party by EUSM for key acquiring. Unknown - ??? something like EUSM sounds like a good idea with fall back to USM is good but replication of all users to all devices is bad idea. KN - I think fall back has been beaten to death but not any different from fall back to CLI or Netconf?? Unknown - not disagreeing, just want to reiterate, don't replicate authentication of DB's everywhere JQ - any difference of proposals for - no decrease of security Wes - .... difficult to cover this in one spreadsheet row JC - should replay protection be optimal or mandatory? Randy - is available a bit in SNMP via some parameters Eric - ... let's concentrate on inherent design of protocols and not minor details. JQ - close additional security features, items 9, 10, 11 are all good let's discuss integration (8). JC - should have chart show: same as USM, more than USM, or less than USM, instead of OK JQ - we agree they all have at least as much, but which has more we're unable to resolve today. Wes - ... probably won't be able solve discussion of which is more secure today. Randy - one thing they all have in common is the use of sessions. With the introduction of that concept we might want to examine how many exchanges it takes to initialize a session and to close a session. What types of operations to add/delete user in the big sense. How long to propagate that knowledge out to nodes. Eric - want to look at big picture, the key important question is, what type of architecture do you want. One bound tightly to SNMP, like EUSM (IBSM??), layered on top, like TLSM, external keying system that wires into SNMP, like EUSM. Many of these proposals are orthogonal to requirement choices? Wes - do we have time to make major changes to proposals. Unknown - .... can we make a choice between to instead of three. Ken - not sure we have consensus to remove one. Wes - ... a significant difference between IBSM and EUSM, EUSM forces third party keying. KN - (respond to EUSM not be scaling any better than Kereberos?), a motivation for EUSM proposals, we wanted to make sure that we made as minimal a change to SNMP as possible because we have code already and wanted to minimize the cost to upgrade. Sam? - speaking as future AD, it would be difficult to get architecture choice by March. JQ - I don't think we can drop any of the three, so we will pass all three onto to evaluation team. Ken - listed possibles, 4-5, for evaluation team DP - any operations people Ken - any here that want to volunteer DH - want to know how many of the operators think all three of these are viable. I'd like to eliminate one of these. Particular I think we should drop the TLSM (DH's) proposal. JQ - don't think we can resolve this today. Wes - one of the goals to pick quickly is because we have a very tight deadline. If the AD's want us to consider all the proposals, I'm worried we won't make our deadlines. Sam? - I don't care if one is dropped on the mailing list, I don't think there is enough time today to make a good decision. With no further discussion, the meeting was closed. |