1. Session-based Security Model for SNMPv3 (SNMPv3/SBSM) David T. Perkins Wes Hardaker IETF November 12, 2003

2. Nov 12, 2003IETF2 Goals Lower the cost of deployment and ongoing operation of SNMPv3 by using existing security infrastructure(s) for identification authentication Provide additional security features not currently found in SNMPv3 with USM Conform to the security model guidelines of the SNMPv3 architecture. (That is, NO changes to ANY SNMPv3 RFC!)

3. Nov 12, 2003IETF3 SNMPv3 Background SNMPv3 is an application layer protocol for management, which provides: –Configuration creation, deletion, and modification –Monitoring –Performing actions –Event reporting SNMPv3 was designed to allow pluggable security models (that is, SBSM is a new security model conforming with SNMPv3’s architecture)

4. Nov 12, 2003IETF4 SNMP Management Model The SNMP management model contains: –Several (typically many) managed systems with an entity (an agent) that provides access to management information –At least one SNMP entity (a manager) that runs management applications –A management protocol –Management information

5. Nov 12, 2003IETF5 Managed Networks A managed network consists of one (or more) management domains (which may overlap) Domain “A”Domain “B”Domain “C” manager managed system

6. Nov 12, 2003IETF6 Security In SNMPv3 Security is viewed as being applied at two different stages: Transmission/receipt of messages, which is called by SNMP a “security model” Processing the content of messages, which is called by SNMP an “access control model” Presently, only one security model is defined, which is called User Security Model (USM) SBSM is a new SNMP security model

7. Nov 12, 2003IETF7 SNMP Security at Message Level Services provided: –Identity authentication of the message sender –Message authentication (data integrity; replay, re-order, and delay protection) –Disclosure protection (encryption) Set of services provided is called the security level, with values: –noAuthNoPriv: no authentication and no encryption –authNoPriv: authentication, but no encryption –authPriv: authentication and encryption

8. Nov 12, 2003IETF8 SNMP Access Control Authorization rules for access to management information based on: –Operation type: “Get”, “Set”, and “Notification” –Management info: object type and optionally instance –Security level: noAuthNoPriv, authNoPriv, authPriv –Identity (called security name) and security model type Presently, only one access control model is defined, which is called VACM (view-based access control model) SBSM result must work with VACM

9. Nov 12, 2003IETF9 SNMPv3 Message Format msgVersionmsgGlobalDatamsgSecurityParmsmsgData msgIDmsgMaxSizemsgFlagsmsgSecurityModel New value for SBSM New format for SBSM (No change for SBSM), present legal values are: '100'b - a noAuthNoPriv request '000'b - a noAuthNoPriv response or unacknowledged notification '101'b - an authNoPriv request '001'b - an authNoPriv response or unacknowledged notification '111'b - an authPriv request '011'b - an authPriv response or unacknowledged notification Nothing changed to support SBSM (no new PDUs)

10. Nov 12, 2003IETF10 USM Characteristics Combines sender identity authentication with message authentication Sender identity shared between manager and agent (that is, single identity authentication) By convention, a single pass phrase per user in a management domain is used to create a unique identity (and message) authentication key (and encryption key) per managed system

11. Nov 12, 2003IETF11 USM Characteristics(cont.) Message authentication and privacy keys are “reused” and long lived, since it is expensive to change user passwords User identity authentication entirely unique to SNMPv3/USM

12. Nov 12, 2003IETF12 SBSM Requirements Related to Using Existing Security Infrastructures Must use existing security infrastructures for identity authentication (should support many) Must have a low incremental cost to add a new identity authentication mechanism

13. Nov 12, 2003IETF13 SBSM Requirements (cont) Related to Additional Security Features Must support authentication of both ends of the message exchange, and allow use of a different mechanism by each end (including “anonymous” identity) When session establishment is initiated by a manager, the agent must reveal its identity and authenticate before the manager (note that identities must be encrypted)

14. Nov 12, 2003IETF14 SBSM Requirements (cont) Must separate security mechanism used for identity authentication from that used for message authentication and encryption Must support limited life time keys for message authentication and encryption Must support at session establishment negotiation of the algorithms used for session message authentication and encryption Must have a low incremental cost to add a new session message authentication or encryption algorithm

15. Nov 12, 2003IETF15 SBSM Requirements (cont) Must support no reprocessing of messages that are duplicated or replayed (reduces cost of packet loss – processing and latency) Must operate over connection oriented and connectionless transports Must work with unmodified VACM Must have a low incremental cost to add new security features such as capability-based authorization

16. Nov 12, 2003IETF16 Consequences of Requirements Very low cost to create new identities, change their authentication credentials, or delete, since provided by existing security infrastructure Saved encrypted messages can not be decrypted after identity credentials are compromised

17. Nov 12, 2003IETF17 Deployment and Initialization Putting a new device into operation, may require: –Creating X.509 certs –Creating SSH server keys –Setup for Radius (shared key, device identity, Radius server address) (Similar for TACACS+) –Creating an “administrative user” and password –Specifying authorization rules (access control policies)

18. Nov 12, 2003IETF18 Ongoing Operation Adding a new user –Create an Identity, specify credentials for identity authentication –Assignment of authorized activities Changing a user’s authentication credentials Changing authorization policies Deleting a user Suspending a user’s account Auditing and billing

19. Nov 12, 2003IETF19 Deployment of a New System with USM Activities to support other access(es) (depends on what is supported) SNMP engineID assignment Addition of all existing users to the USM MIB tables for the SNMP agent (requires access to each user’s password) Configuration of VACM MIB tables

20. Nov 12, 2003IETF20 Ongoing Operation with USM New user requires adding the user to the USM MIB tables for each agent in the domain, and the value of the user’s password to add the user keys. Also, must add the user to VACM’s “toGroup” table in each agent. Change of a user’s password requires access to the password and an update of the auth and priv keys on every agent in a management domain

21. Nov 12, 2003IETF21 Ongoing Ops with USM (cont) Changing authorization rules requires update of VACM MIB for all agents in a management domain Deleting a user requires modification of the USM MIB tables for all agents in a management domain, and an update of VACM’s “toGroup” table Suspending a user requires update of VACM’s “toGroup” table for all agents in a management domain

22. Nov 12, 2003IETF22 Deployment of a New System with SBSM Activities to support other access(es) (depends on what is supported) SNMP engineID assignment Configuration of VACM MIB tables Note: no need to know every user and their “SNMP password”

23. Nov 12, 2003IETF23 Ongoing Operation with SBSM New user requires adding the user to VACM’s “toGroup” table in each agent Note: no need for user password or additions to USM MIB tables Change of a user’s password requires no SNMP related modifications Note: password update done via mechanisms in existing security infrastructure

24. Nov 12, 2003IETF24 Ongoing Ops with SBSM (cont) Changing authorization rules requires update of VACM MIB for all agents in a management domain Deleting a user requires update of VACM’s “toGroup” table for all agents in a management domain Suspending a user requires update of VACM’s “toGroup” table for all agents in a management domain

25. Nov 12, 2003IETF25 End of Introduction Questions