ISMS – March 2005 IETF

1. ISMS – March 2005 IETF David T. Perkins Presentation at ISMS WG Meeting

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. Presentation at ISMS WG Meeting

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. Presentation at ISMS WG Meeting

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. Presentation at ISMS WG Meeting

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 Presentation at ISMS WG Meeting

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 Presentation at ISMS WG Meeting

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 Presentation at ISMS WG Meeting

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 Presentation at ISMS WG Meeting

9. Info not Required to beHeld by SNMP Managers • Radius server address • Shared secret for use with Radius • Other authentication method specific info Presentation at ISMS WG Meeting

10. Pure EAP Authen Message Flow MethodspecificAuthenservers EAPPEER Authenticationserver Authenticator SNMPManager SNMPAgent RadiusClient RadiusServer Session setup: authen with Radius server Key and session ID handoff Presentation at ISMS WG Meeting

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 Presentation at ISMS WG Meeting

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? Presentation at ISMS WG Meeting

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 Presentation at ISMS WG Meeting

14. Reuse USM? • Problems with mapping the pair msgAuthoritativeEngineID:msgUserName to session identifier (how to distinguish multiple sessions that have the same engineID:name 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 Presentation at ISMS WG Meeting

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 Presentation at ISMS WG Meeting

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 Presentation at ISMS WG Meeting