From EECS

The goal of the ISMS working group of the IETF 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.

In particular, the working group is working on the following charter 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-called 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.

For additional status information, see the working group's status page.

Contents 1 Documents 2 Meetings 3 Issues 3.1 Session Management 3.2 SSH Authentication 3.3 Radius Integration

Documents

Current working group documents:

• Secure Shell Security Model for SNMP
• Transport Mapping Security Model (TMSM) for the Simple Network Management Protocol

Obsolete working group documents:

• Comparison of Proposals for Integrated Security Models for SNMP (Simple Network Management Protocol)

Related documents:

• RADIUS NAS-Management Authorization

Meetings

• 01. ISMS Interim (Feb. 13-14 2006, MIT, Cambridge)
• 64. IETF (Nov. 8 2005, Vancouver)
• 63. IETF (Aug. 2 2005, Paris)
• 62. IETF (Mar. 7 2005, Minneapolis)
• 61. IETF (Nov. 8, 2004, Washington)
• 60. IETF (Aug. 6 2004, San Diego)

Issues

Below is a list of high-level issues that need to be resolved before work can continue on several low-level issues.

Session Management

Session establishment seems rather obvious if we consider command generators. It is less obvious if we consider notification originators. Some of these questions have a discussion in RFC 3430. It needs to be determined whether the transport layer security model should follow RFC 3430 or take a different approach.

• SQ1: Are notifications originators responsible to establish sessions for notification delivery, and if so, how and when do they do so?
• SQ2: Can notification originators (re-)use already established sessions for notification delivery, and if so, how and when do they determine that a session does or does not exist, and how and when do they choose a session with the appropriate security characteristics (both SSH and SNMP)?
• SQ3: Is it required that a session already exists before a notification can be sent, and if so, when and how does the notification originator (or message processor) determine whether a session exists or not, and what happens if there is no session?

Session teardown also allows for multiple solutions:

• SQ4: Are sessions torn down when a logical operation is complete, and if so, how and when does the engine know that a logical operation is complete (for example, when a message is discarded during processing and no Report is generated)?
• SQ5: If sessions are kept alive for future use, how do we deal with situations where sessions either need to be torn down due to resource constrains or where sessions seem to bind resouces but are not really used?

Sessions establish state information and must be managed in various parts of the SNMP entity.

• SQ6: How is session state information managed and in particular cleaned up when sessions go away (both via clean session shutdown or due to failures)?
• SQ7: How do we deal with MIB variables that are bound to the existence of a session (e.g. notification target configurations pointing to a session established by a "manager" to receive notifications)?

SSH Authentication

SSH authentication is typically asymmetric. The SSH server is usually authenticated by its host identity (hostname) and its host key while the client is authenticated by its user identity (user name) and its associated credentials (password, keys). While the mapping seems to be straight-forward for command generators initiating SSH sessions to a command responder, things are less clear for sessions carrying notifications (node that this clearly depends on how we deal with notification sessions in general).

• AQ1: Does notification delivery via SSH require user authentication of the notification originator and host authentication of the notification receiver?
• AQ2: Does notification delivery via SSH require host authentication of the notification originator and user authentication of the notification receiver?
• AQ3: Should both authentication styles outlined above be supported and runtime configurable?
• AQ4: Is it possible/useful to have a "turn" mechanism in SSH which allows a process to initiate the SSH protocol but later turn the automatically assigned client role into a server role?

Radius Integration

One of the goals is to integrate into AAA services such as RADIUS to achieve centralized management of access to network devices for management purposes. Ideally, a solution would work not only for ISMS but consitently also for CLI access and potential other types of administrative access to devices (e.g. netconf).

• RQ1: How does AAA hook into the overall model? Is AAA integration transparent from the viewpoint of the SNMP architecture or are explicit hooks required to make things work?
• RQ2: What is the exact information that needs to be exchanged between an SNMP entity supporting ISMS and an AAA server?
• RQ3: What happens to long lasting sessions? Is there a mechanism to re-check AAA information? How is an SNMP engine supposed to react if the re-check of AAA information is negative?