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

2. Presentation at ISMS WG Meeting2 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. Presentation at ISMS WG Meeting3 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. Presentation at ISMS WG Meeting4 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. Presentation at ISMS WG Meeting5 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. Presentation at ISMS WG Meeting6 SNMPv3/USM Does Not 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. Presentation at ISMS WG Meeting7 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. Presentation at ISMS WG Meeting8 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. Presentation at ISMS WG Meeting9 Info not Required to be Held by SNMP Managers Radius server address Shared secret for use with Radius Other authentication method specific info

10. Presentation at ISMS WG Meeting10 Pure EAP Authen Message Flow SNMP Manager Radius Server SNMP Agent EAP PEER Authenticator Authentication server Method specific Authen servers Session setup: authen with Radius server Key and session ID handoff Radius Client

11. Presentation at ISMS WG Meeting11 Mixed Authen Message Flow SNMP Manager Radius Server SNMP Agent X.509 Certs Method specific Authen servers Authentication server SSH key Local account Perform authentication locally or via EAP based on policy setting

12. Presentation at ISMS WG Meeting12 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. Presentation at ISMS WG Meeting13 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. Presentation at ISMS WG Meeting14 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

15. Presentation at ISMS WG Meeting15 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), Stay the same Make appropriate changes Replacement for first part above

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