2.6.4 Integrated Security Model for SNMP (isms)

NOTE: This charter is a snapshot of the 61st IETF Meeting in Washington, DC USA. It may now be out-of-date.

Last Modified: 2004-10-04


Ken Hornstein <kenh@cmf.nrl.navy.mil>
Juergen Quittek <quittek@netlab.nec.de>

Security Area Director(s):

Russell Housley <housley@vigilsec.com>
Steven Bellovin <smb@research.att.com>

Security Area Advisor:

Steven Bellovin <smb@research.att.com>

Mailing Lists:

General Discussion: isms@ietf.org
To Subscribe: isms-request@ietf.org
In Body: in body: (un)subscribe
Archive: http://www.ietf.org/mail-archive/working-groups/isms/current/maillist.html

Description of Working Group:

Version 3 of the Simple Network Management Protocol (SNMPv3) was
elevated to Internet Standard in late 2002 and added security to the
previous versions of the protocol. Although the enhanced protocol
is secure, operators and administrators find that deploying it can
be problematic in large distributions. This is due primarily to two
synchronization problems. The first is the addition of yet another
authentication system specific to SNMPv3 that needs to be maintained
across all networking devices. Most of these devices already
contain local accounts and/or the ability to negotiate with
authentication servers (e.g. RADIUS servers). However, SNMPv3 does
not make use of these authentication mechanisms, and this causes
additional synchronization burdens. The second issue found with
deploying SNMPv3 is that distributing and maintaining View-based
Access Control Model (VACM) rules is also difficult in large-scale

The ISMS working group will focus on finding and identifying a solution
for the first of the two above mentioned problems: creating a security
model for SNMPv3 that will meet the security and operational needs of
network administrators. The solution should maximize useability in
operational environments to achieve high deployment success and at
the same time minimize implementation and deployment costs to
minimize the time until deployment is possible. The work will
include the ability to make use of existing and commonly deployed
security infrastructure. The following security infrastructures
will be considered by the working group as potential existing
authentication infrastructures to make use of within the new
security model. The solution will hopefully be able to be integrated
with multiple of these user databases although it is expected that
one will be mandatory.

- Local accounts
- SSH identities
- Radius
- X.509 Certificates
- Kerberos
- Diameter

A solution must not modify the other aspects of SNMPv3 protocol as
defined in STD 62 (EG, it must not create new PDU types). It should
also be compliant with the security model architectural block of
SNMPv3, as outlined in RFC 3411. And if at all possible, it should
also not change any other protocols either.

The working group will begin focusing on initial proposals, which
must be submitted for consideration by the Internet-Draft cut-off
date for the 61st IETF (Oct 19th, 2004). Documents submitted for
consideration need not be well-polished but are expected to
adequately describe the proposed model enough that working group
participants can adequately understand them to make an informed
decision when considering it along with the other candidates. The
working group will select one forward path from all the proposals
submitted by the cut-off date. If no such selection is made by the
end of March, 2004 then the working group will be closed down.

Work Items

- Choose a technical direction for the working group to focus on.

Goals and Milestones:

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

No Current Internet-Drafts

No Request For Comments

Current Meeting Report

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...

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.


Transport Maping Security Model