ISMS March 2005 IETF

1
ISMS March 2005 IETF

• David T. Perkins

2
Problem To be Solved

• Reduce the incremental operational cost of
  supporting SNMPv3 to approach zero!
• Primarily for network infrastructure devices
  (such as routers, bridges, etc), but also servers
  and work stations
• Assume work is already done to configure
  authentication for access via CLI and/or WEB
• Problem is both authentication and authorization,
  but WG charter defers authorization solutions.

3
Types of SNMP Entities

• Agents provide access to management information
  on the system containing the agent
• Managers access management info on managed
  systems (that is systems containing agents)
• Observers "third party" reporter of events
• Proxy Agents Application level forwarder (and
  optionally version translator) of SNMP messages
• Mid-level Managers are simply quite powerful
  agents that access info from other agents and
  make it available to managers.

4
Categories of SNMP Managers

• Poller identity is a service name, such as
  "poller". Long running. Transport address need
  not be stable. Only reads mgmt info.
• Notification receiver identity is a service,
  such as "notifyrcvr". Long running. Transport
  addr must be stable. Passive.
• Mgmt app identity is the user that initiated it.
  Used for config, trouble shooting, etc. Transport
  addr need not be stable. May read and write mgmt
  info.

5
SNMPv3/USM

• Each operation is independent from each other
• Each message provides for identity verification,
  message integrity check (MIC), encryption, and
  timeliness and limited replay detection
• Identities are in a name-space that is
  independent of all other existing security
  infrastructures
• Key for authentication verification also used for
  MIC
• Authentication and encryption keys are long
  lived, since they are typically changed together
  and based on identity pass-phrase

6
SNMPv3/USM DoesNot Solve the Problem

• Requires extra work to be done on each system
  containing an SNMP agent
• Requires extra work and separate SNMP specific
  applications to manage USM users and keys

7
Ideal solution

• Uses existing name space and attributes of
  existing security infrastructures including SSH
  key pairs, X.509 certs, name/password, and/or
  name secureID card
• Network infrastructure device configured with
  identities and verification mechanisms, then
  support for SNMPv3 is turned on
• No new information or configuration is needed on
  systems that run SNMP management applications

8
Info Held By SNMP Managers

• User identity to use
• Credentials for the user identity
• Transport address of a system containing an SNMP
  agent
• Identity and info to verify SNMP agent identity
  (for example, for SSH - IP address and
  fingerprint of public key, for X.509 CA cert)
• Note, Proxy has not yet been considered

9
Info not Required to beHeld by SNMP Managers

• Radius server address
• Shared secret for use with Radius
• Other authentication method specific info

10
Pure EAP Authen Message Flow
MethodspecificAuthenservers
EAPPEER
Authenticationserver
Authenticator
SNMPManager
RadiusServer
SNMPAgent
RadiusClient
Session setup authen with Radius server
Key and session ID handoff
11
Mixed Authen Message Flow
Perform authentication locally or via EAP based
on policy setting
MethodspecificAuthenservers
Authenticationserver
RadiusServer
SNMPManager
SNMPAgent
Localaccount
X.509 Certs
SSH key
12
Sessions Two Parts

• Session establishment, results in
• Mutual authentication
• Session ID (such as a SA pair)
• Master session key (used to derive MIC and
  encryption keys)
• Operating, uses
• Session ID
• MIC and encryption keys
• What is used for timeliness and replay detection?

13
USM Timeliness and Replay Detection

• Uses a loosely synchronized clock
• Replays and message delays can occur within a 150
  second window
• Because in USM, each message is independent, a
  complex mechanism is used
• The concept of "authoritative" and
  "nonauthoritative" engine and procedures were
  created to manage and update the loosely
  synchronized clock
• Authoritative and nonauthoritative causes
  problems with traps and informs

14
Reuse USM?

• Problems with mapping the pair msgAuthoritativeEng
  ineIDmsgUserName to session identifier (how to
  distinguish multiple sessions that have the same
  engineIDname pair)
• Problems with clock (msgAuthoritativeEngineBoots
  msgAuthoritativeEngineTime) (see previous page)
• However, can reuse msgAuthenticationParameters
  and msgPrivacyParameters, and crypto procedures
  associated with values for usmUserAuthProtocol
  and usmUserPrivProtocol

15
Updated Security Model Specific Info

• UsmSecurityParameters SEQUENCE
• -- global User-based security parameters
• msgAuthoritativeEngineID OCTET STRING,
• msgAuthoritativeEngineBoots INTEGER
  (0..2147483647),
• msgAuthoritativeEngineTime INTEGER
  (0..2147483647),
• msgUserName OCTET STRING
  (SIZE(0..32)),
• -- authentication protocol specific parameters
• msgAuthenticationParameters OCTET STRING,
• -- privacy protocol specific parameters
• msgPrivacyParameters OCTET STRING
• msgSrcSA INTEGER (0..4294967295),
• msgDstSA INTEGER (0..4294967295),
• msgSeqNum INTEGER (0..4294967295),

Make appropriatechanges
Stay the same
Replacement for firstpart above
16
Summary

• Operating message flow requires a session to be
  established between the SNMP manager and SNMP
  agent.
• SNMP agent to choose authentication method based
  on policy configuration at the agent.
• Sessions instead of per message allows
  simplification of timeliness and replay detection