2.7.5 Integrated Security Model for SNMP (isms)

NOTE: This charter is a snapshot of the 64th IETF Meeting in Vancouver, British Columbia Canada. It may now be out-of-date.

Last Modified: 2005-10-24


Juergen Schoenwaelder <j.schoenwaelder@iu-bremen.de>
Juergen Quittek <quittek@netlab.nec.de>

Security Area Director(s):

Russ Housley <housley@vigilsec.com>
Sam Hartman <hartmans-ietf@mit.edu>

Security Area Advisor:

Sam Hartman <hartmans-ietf@mit.edu>

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:

The Simple Network Management Protocol version 3 (SNMPv3) provides
message security services through the security subsystem, for which
there is one currently defined model - the User-based Security Model
(USM). However, the USM approach has seen limited deployment so far.
One frequently reported reasons is the lack of integration of USM
key and user management into deployed authentication infrastructures.

SSH is a widely deployed access protocol for remote devices
configuration. Many devices support the integration of SSH user
authentication with AAA systems via protocols such as RADIUS.

The goal of the ISMS working group is developing a new security model
for SNMP that integrates with widely deployed user and key management
systems, as a supplement to the USM security model.

For this integration the working group will define a standard method
for mapping from AAA-provisioned authorization parameter(s) to
corresponding SNMP parameters.

In order to leverage the authentication information already accessible
at managed devices, the new security model will use the SSH protocol
for message protection, and RADIUS for AAA-provisioned user
authentication and authorization. However, the integration of a
transport mapping security model into the SNMPv3 architecture should be
defined such that it is open to support potential alternative transport
mappings to protocols such as BEEP and TLS.

The new security model must not modify any other aspects of SNMPv3
protocol as defined in STD 62 (e.g., it must not create new PDU types).

Work on new access control models or centralized administration of
View-based Access Control Model (VACM) rules and mappings is outside
the scope of the working group.

The working group will cover the following work items:

- Specify an architectural extension that describes how transport
mapping security models (TMSMs) fit into the SNMPv3 architecture.
- Specify an architectural extension that describes how to perform a
mapping from AAA-provisioned user-authentication and authorization
parameter(s)to securityName and other corresponding SNMP parameters.
- Specify a mapping from RADIUS-provisioned authentication and
authorization parameter(s) to securityName and other corresponding
SNMP parameters. This item may be a RADEXT work item last-aclled
in both groups.
- Specify a mapping from locally-provisioned authentication and
authorization parameter(s) to securityName and other corresponding
SNMP parameters.
- Define how to use SSH between the two SNMP engines
- Specify the SSH security model for SNMP.

Goals and Milestones:

Done  Cut-off date for internet-drafts to be submitted to the working group for consideration as a proposed solution
Done  Decision about which architecture the WG will focus its efforts on
Oct 2005  Initial version of a general transport mapping security models (TMSMs) document that specifies how TMSMs fit into the SNMPv3 architecture and that defines the requirements for transport mapping security models
Oct 2005  Initial version of a document specifying the SSH security model for SNMP
Feb 2006  Initial version of an applicability statement that sets up reasonable mandatory to implement methods
Feb 2006  Submit TMSM document to IESG
Jun 2006  Submit SSH TMSM to IESG
Jun 2006  Submit RADIUS mapping model for SNMP to IESG
Aug 2006  Submit applicability statement to IESG
Dec 2006  Initial version of a document specifying the RADIUS authentication and authorization mapping model for SNMP


  • draft-ietf-isms-secshell-00.txt
  • draft-ietf-isms-tmsm-00.txt

    No Request For Comments

    Current Meeting Report

    Minutes of the ISMS session at IETF 64
    Tuesday November 8, 13:00 h - 15:00 h
    notes taken by David Partain
    Integrated Security Model for SNMP working group
    Chairs: Juergen Quittek         
            Juergen Schoenwaelder   
    1. Discussed Internet drafts
    [1] Transport Mapping Security Model (TMSM) for the 
        Simple Network Management Protocol, 
    [2] Secure Shell Security Model for SNMP, 
    2. Session Summary
    The ISMS WG was re-chartered in October. The first documents
    complying with the new charter were discussed at the meeting.
    Discussions focused on the resolution of open technical issues
    concerning the operation of SNMP over SSH. Several issues have
    been closed. But since the WG did run out of time, several
    still open issues have to be resolved on the mailing list.
    The ISMS WG needs support from the RADEXT working group concerning
    the specification of RADIUS attributes for transport mapping security
    models. The ISMS WG will specify the RADIUS authentication and
    authorization mapping model for SNMP, but the actual attributes need
    to be specified by the RADEXT WG.
    3. Action Items
     - define RADIUS requirements and feed them to the RADEXT WG
     - revise the transport mapping security model document
     - revise the SSH security model document
    4. RADEXT Report
    David Harrington presented to RADEXT that we need some attributes for
    mapping user names to policy names for use by access control models
    such as VACM.  RADEXT in general seemed willing to support this
    effort.  ISMS however needs to work out the requirements. Since RADEXT
    is behind some of their milestones, they are probably not going to
    jump on ISMS related work right away.
    Glen Zorn: The best thing you could do instead of waiting for RADEXT
    is to write a draft, run it by them, and with any luck it'll be done.
    5. Secure Shell Security Model Issues
    Most of the meeting time was spend discussion open issues. Dave
    Harrington lead the discussion based on the slides he prepared. Below
    is a short summary of the discussions, indexed by the open issue
    number used on the slides. The narrative notes taken by the note taker
    can be found in the Appendix A.
    [2a] Server authentication is a requirement and SSH will take care of
         it via the host authentication mechanism.
    [2b] The SSHSM should generally trust the SSH layer to do its job and
         not try to verify whether SSH really got it right.
    [2c] The security considerations should spell out different ways how
         clients can learn host keys (e.g., first time discovery with
         operator check or pre-configured host keys) and to leave the
         decision to the operators which solution they prefer.
    [8]  The relationship between the SSH server identity (basically its
         host name) and SNMP context engineIds remains unclear. There seem
         to be two related issues: a) how to handle multiple contexts
         using a single SSH server and b) how to bind the authenticated
         host name to engineIds. This issue needs further discussion.
    [12] There was some notion in the room to allow SSH to always provide
         auth/priv services, even in cases where less is requested by the
         SNMP security level parameter.
         SSH supports a null cipher. The security considerations perhaps
         should explain that usage of the null cipher is generally not
         expected, even though implementations might support it for
         special cases (e.g. someone running ISMS over a secure IPsec
         tunnel or environments where encryption is illegal).
    [13] SSH does not seem to have specific provisions for host key
         changes and it was suggested that SSHSM does not do anything
         special (either there is a transport or the transport failed).
    [14] Yes.
    [15] This will fall out once we have solved the other open issues.
    [16] It was clarified that the SSH client always chooses the username
         to be used with a specific user authentication mechanism. The
         securityName is therefore the authenticated user name (modulo
         some potential AAA interaction which we do not understand yet).
    [18] The information will be collapsed into one place.
    [19] It seems that current SSH implementations talk to AAA servers as
         part of the user authentication process. The question seems to be
         how parameters that are relevant for SNMP can be moved into the
         SNMP engine or whether SNMP has to talk AAA itself and what the
         binding between multiple requests would be. This need more
    [32] Yes.
    [3]  We need to provide text which discusses the impact of using
         sessions. Volunteers please speak up.
    [23] The SNMP dispatcher interface does not provide hooks for opening
         and closing sessions and in particular, there are no specific
         provisions for handling failures of the transport to deliver
         messages. This issue was not resolved and session handling in
         general needs more discussion.
    [29] It seems we need to support reports as an SNMP layer error
         reporting and discovery mechanism.
    [9]  The handling of notifications, the establishment of sessions for
         notification delivery and the associated authentication questions
         (SSH is not symmetric) were not resolved during the meeting and
         need more discussion.
    A. Narrative Notes
    (Slide text is not repeated...)
    Eliot Lear:  #2a - all of 2 falls into the category of SNMP
    making demands of SSH, but we shouldn't mess around with SSH's
    business.  It's not our problem.
    Jeff Hutzelman: How we learn the host key is in fact the one part
    of this that we might want to consider.  We don't want to break
    the abstraction.  How do you know that you have the right host
    key?  Well, you'd better know the key in advance.  We may want to
    consider that issue.
    Eliot Lear: SSH requires a "leap of faith" in terms of the first
    transaction when you get the host key.  How you get that in terms
    of SNMP perhaps should not be a standardization issue.  We
    shouldn't care.
    Bill Sommerfeld: SSH documents already complete.  Agree with
    Elliot.  There are some extensions at various levels of
    completion which would make the leap of faith less of an issue.
    X.509 is one.  The GSS-API bits provide an alternate means of
    server auth.  You are better off not trying to avoid this leap of
    faith in this working group.
    Eric Fleischman: one of the differences between ISMS and USM is
    that we have now made multiple authentication methods available.
    When we get products from vendors, we want some consistency.  We
    want at least one approach that everyone does.
    Jeff Hutzelman:  Yes, we have mandatory to implement key exchange
    mechanisms and authentication mechanisms.  If they're applicable
    to ISMS we don't know.  There are ways to avoid the leap of faith
    but we don't want to decide here what they must be.
    Eliot Lear: Let's not standardize that here.
    Jeff Hutzelman: We need to talk about it somewhere.  You need
    text that discusses the operational aspect.
    David Perkins: Operationally, a big part of SSH is the file where
    you have the public key and the DNS name that goes with them.  If
    I get software from different vendors, I don't want to go through
    the "leap of faith" multiple times cause they have different file
    David Harrington:  Could you send something to the list related
    to this so we capture it?
    Juergen Schoenwaelder: Do we need to do something with the text
    or do we leave this up to SSH?
    Eliot Lear: State somewhere in the document that you should
    think about these issues, but not as normative text.  A note in
    the security considerations to address the issue, but nothing
    Jeff Hutzelman: Particularly the 2C issue.
    Jeff Hutzelman: Regarding 2a: The question is "does SNMP
    sometimes always care about the service identity?"  Not sure this
    is moot.  If we do care, the 2c advice is important for people to
    heed.  Does the SSH client used by SNMP need to verify the
    server's identity?
    Sam Hartman: I think the answer is yes, but in the sense that SSH
    always delivers.  Not add new stuff to make it more complicated.
    Object to words that say that we need to do something more than
    what is typically done.
    Question from jabber " One question is whether the
    server identity is ultimately verified by the user authentication
    Sam Hartman: In general no.
    #8 - mapping between SSH key and SNMP engineID.
    Uri Blumenthal: WRT #8, you do need to bind the key.  Need to know
    what to do if multiple agents are running on one system. Either bind
    the key to the system or to the snmpEngineID so that there is a key
    for each agent running on the system.
    Sam Hartman: There has been a fair bit of traffic on this.
    David Harrington: Haven't reached consensus.
    Juergen Schoenwaelder: Do you understand the edits?
    David Harrington: No.
    Wes Hardaker: Two comments: 1) When we talk about engineIDs, can
    we make sure we are consistent in talking about contextEngineID?
    2) the mapping between the engineID and key happens in the
    management apps, so do we need to standardize?  The management
    app gets the key and the engineID and should do the mapping.
    Sam Hartman: One disadvantage of that is that you must use an SSH
    implementations that exports keys in that way.  Secondly, you
    need to build things in a key exchange specific way.  What SSH
    documents do is bind a name (host name) to some identity (key,
    GSS name, etc.).  Do you want to add something on top of that or
    do you want to use stock SSH implementations?  Also, a reminder -
    the way you authenticate the server is different than the client
    - it's asymmetric.
    Wes Hardaker: I don't think we need to specify/mandate it.  We
    should put something in the security considerations and we are done.
    Sam Hartman: From an interoperability standpoint, what are you
    going to put in ACLs.  contextEngineId?
    Joseph Galbraith: Lots of keys floating around, so we need to be
    explicit about which key we're talking about.
    Jeff Hutzelman: SSH has no engineID.  The server doesn't have an
    identifier when you connect to it with SSH.  You have to know who
    you're going to talk to in advance.  Given a contextEngineID, you
    have some way to know in advance who you're going to talk to
    (e.g., name).
    David Perkins: I'm confused since I know how proxies work.  If I
    set up a connection to an SSH agent, the contextEngineId tells the
    system which target should receive the request.  So, why do I
    need to map?
    Joseph Galbraith: If you are going to have one connection handle
    multiple SNMP systems, you probably want multiple channels.
    Jeff Hutzelman: But you need to map between how you authenticate
    in SSH and how you authenticate in SNMP.
    Eliot Lear: Could we have an example where we need the mapping?
    Until we do, let's leave it out.
    Bill Sommerfeld: What he said.  It seems that if you're serving
    up multiple engineIds from one SSH client, you'll build up a
    table over time.
    Sam Hartman:  EngineId to hostname and key.
    David Harrington:  Reminds us of the question...
    David Perkins: Most management applications never need to know
    the engineID unless they're doing proxies.  Most don't support
    contextEngineID.  Don't store it.  They only support transport
    address.  That's it.
    David Harrington: We have to be consistent with the charter, which
    says we should be using the contextEngineID to name SNMP entities.
    Unless we don't have to follow the architecture, we seem to have to
    take care of this issue.
    (Question from jabber - get the question from jabber room)
    Jeff Hutzelman: you need to know something about the identity in
    Juergen Schoenwaelder: The issue isn't really resolved.  No clear
    Issue #12
    msgFlag part:
    Sam Hartman: Always assume that SSH provides all of the above
    (auth, priv), so just don't worry about it.
    part c:
    Eliot Lear: Security area: How do you deal with this elsewhere?
    Bill Sommerfeld: In general, there are a few countries where this
    is an issue (crypto longer than X bits), but we haven't had to
    deal with it in our products, so I'm not sure where this comes
    Eliot Lear: Can we leave part B to SSH?
    Jeff Hutzelman: What is the state of the null cipher?
    Sam Hartman: If concerned about issue, read RFC 1984.  If a site
    selects null, it's okay and they're aware of it.   They may have
    selected null because they're over an IPsec tunnel or the like.
    Jeff Hutzelman: I wanted to know if it's possible for SSH to
    provide a no-encryption environment.
    David Harrington: Part b asks if it's okay for SSH to give more
    security security than requested.  
    Robert Story: We must allow SSH to provide higher security than
    Bert Wijnen: When we designed security in v3, we discovered that
    there is a lot of info retrieved that doesn't require security,
    so we put in noAuth/noPriv.
    Robert Story: We shouldn't force people to have separate connections.
    Bert Wijnen: That's fine.
    David Harrington: I prefer to use authPriv for everything.  We'll
    take it to the list.
    Jeff Hutzelman: In traditional SSH implementations, the only
    thing stored are the host keys.  What happens if re-keying
    happens in the middle of a session?
    Wes Hardaker: We shouldn't have to think about that here.
    Bill Sommerfeld: That question hasn't been considered.
    David Harrington: In USM, a keychange can be made and we need to
    make sure we're getting an answer to
    Joseph Galbraith: The transport's either there or not.  You don't
    care about the details about things like how host keys are
    David Harrington: (Editor - ???? sorry, didn't get the question)
    Wes Hardaker: We shouldn't send out responses to questions from
    previous sessions that aren't there anymore.
    Nico's comment from jabber room.  A client would be free to
    update its mappings if there was a rekey.
    Joseph Galbraith: Client maintains a mapping file.  If that
    changes, the client can say it doesn't accept or it does.  But
    you don't care.
    David Harrington: Resolution: we'll throw away the response.
    Joseph Galbraith: what is the tmStateReference?
    David Harrington: cached information.  When we send a response,
    we must send it using the incoming state information.  Suggest we
    take it to the list.
    Joseph Galbraith: In the userauth request, it either accepts the
    user or sends back a list of methods that might work with that
    username.  The client can then either choose a different method
    or a different username.
    David Perkins: what methods are there?
    Joseph Galbraith:  There are a bunch of them.  This is a
    Bert Wijnen: So do you get back a username?
    Joseph Galbraith: No, username is input.  Client specifies
    method, username, and authentication info.  Server says yes or
    no, and if you get in, you're done. Further requests are ignored.
    Bert Wijnen: What if it says no?
    Joseph Galbraith:  It tells you methods to try.
    Sam Hartman: You're going to get at least one no, then it'll tell
    you what methods you should have tried (not usernames).
    David Harrington: What username do you use?
    Jeff Hutzelman: You use the username as a result of the
    successful userauth request.
    Sam Hartman: Don't want to specify to this level of detail
    primarily due to RADIUS interactions, but ... yes.  It's the
    username that's authenticated by the SSH server.
    Sam Hartman: Enumerating auth methods is good to make sure you
    don't have holes, but we shouldn't have a list of auth methods in
    the documents.
    Joseph Galbraith: No matter which auth method you use in SSH, it
    has the same output - the username.  How you get that information
    out of the SSH implementation into the SNMP implementation is an
    implementation-specific question.
    Juergen Schoenwaelder: Should we have language in the security
    considerations section that says that you get the SSH username
    into SNMP in a secure way.
    Chris Lonvick: Is the username singular for all thousand boxes or
    unique to each box?
    Jeff Hutzelman: A deployment issue.  Either separate usernames
    per client entity, RADIUS server, whatever.  The way these things
    work today.
    Chris Lonvick: Something to go in security considerations.  If
    you're using the same username on all boxes, is there concern
    that one box being compromised will compromise all?  Or do we
    have unique users in all boxes.
    David Harrington: Will collapse information in #18 into one place
    in the document.
    David Harrington: Don't expose SSH details into SNMP, but we may
    need to do something here if we're going to use RADIUS for SNMP
    Eliot Lear: We are back to the triangular communication that we
    had with EUSM, which we thought was ugly.
    Sam Hartman: I am the manager and talk to agent using SSH.  I'm
    the agent and talk RADIUS to the side.  I see two lines, no
    Eliot Lear: What information is exchanged with the RADIUS server?
    Sam Hartman: Let's use a Cisco CLI example.  It will verify the
    host key, i'll try to use none, Cisco box says no, says it wants
    a password, so i send one.  The Cisco box asks the radius server.
    A yes/no will then determine if I get access.
    Eliot Lear: Just don't want to hard-code RADIUS since other
    things will be used.
    Sam Hartman: We need to think about communication between SNMP
    and RADIUS.  Not hard-coded, but we need to do things that make
    it easier.
    Eliot Lear:  ???? (Editor - Sorry, didn't get this bit....)
    Jeff Hutzelman: Not sure that a port number is needed.  The
    client can provide auxiliary information in the authentication
    request to identify the SSHSM channel.
    Eliot Lear: It would be possible for me to provide as part of my
    authentication something indicating the subsystem I want to
    Jeff Hutzelman: There is something in keyboard-interactive that
    gives some hint to the server which backend to use.  Not sure
    it's relevant here.
    Sharfuddin Syed:  Sam's use case was helpful.  One thing was
    overlooked.  When a client makes a request to the server,
    shouldn't the request go through a NAS client as well?
    Jeff Hutzelman: An implementation detail that Sam glossed over.
    Assumption that the server is on the same box.
    David Nelson (jabber): No, the RADIUS management authorization
    work does not separate authorization from authentication.
    David Harrington: We have pseudo-code in the SNMP specs we have
    to have a default mapping that would mean we default to the SSH
    username.  Answer: Yes.
    Eliot Lear: Q? When you say "session", do you mean transport
    layer connection or some other form of session.
    David Harrington: Yes :-)  We just need to talk about
    implications of "sessions".  Following points are also part of
    David Harrington: We can't deal well with failure of the
    transport to deliver the message.  ASI's don't allow for an error
    from transport mappings portion of the SNMP engine.
    Jeff Hutzelman: How do other transports deal with this?
    David Harrington: UDP just fails.
    Juergen Quittek: We have only 10 minutes left, so let's make sure we
    talk about important issues.
    David Harrington: The problem is that the important issues may be
    SSHSM vs USM
    David Harrington: Yes, we need to support reports.
    David Harrington: We may not have security parameters, so do we
    really need to parse the ASN.1?  We may need to make sure it's
    not empty.
    David Harrington blew through a bunch of issues
    Wes Hardaker: unless there's a technical reason not to, why not?
    Juergen Schoenwaelder: We have a fundamental question:  How do we
    authenticate notifications since SSH is not symmetric.
    Eliot Lear: Also, in which direction can those notifications
    Jeff Hutzelman: In my limited network operations experience,
    normally notifications are used by a system configured to send
    notifications to a centralized system to let you know about
    interesting events.
    Sharfuddin Syed: If the auth fails for a number of times, we
    should send some kind of notification.
    David Perkins: There may be another question that should be asked
    before this one.  Today, using UDP, when you want to send a
    trap/inform, you just send it.  If we in the future want to send
    notifications, when do we set up the session?  When the event
    occurs?  When the notification generator comes up?
    David Harrington: Right now in the doc, when there's something to
    David Perkins: When do you tear it down?
    David Harrington: Not decided.
    David Perkins: There's a way to configure notification targets
    today, we need a way to do this this in SSH.
    Sharon Chisholm: When people want to manage a system, they're
    going to want to set up the session when they start up the
    system, not short-lived sessions.
    Juergen Schoenwaelder: Let's take this to the list.  Reminds us
    of the call-home BOF.  We need to look at the notification
    Thanks, we continue on the list.


    ISMS WG Status
    SSHSM Issues