Session-based Security Model for SNMPv3 (SNMPv3/SBSM)

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

2. 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!) IETF

3. 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) IETF

4. 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 IETF

5. Managed Networks A managed network consists of one (or more) management domains (which may overlap) Domain “A” Domain “B” Domain “C” manager managedsystem IETF

6. 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 IETF

7. 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 thesecurity level, with values: • noAuthNoPriv: no authentication and no encryption • authNoPriv: authentication, but no encryption • authPriv: authentication and encryption IETF

8. 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 IETF

9. msgID msgMaxSize msgFlags msgSecurityModel SNMPv3 Message Format msgVersion msgGlobalData msgSecurityParms msgData New format for SBSM Nothing changed to support SBSM (no new PDUs) New value 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 IETF

10. 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 IETF

11. 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 IETF

12. 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 IETF

13. 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) IETF

14. 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 IETF

15. 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 IETF

16. 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 IETF

17. 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) IETF

18. 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 IETF

19. Deployment of aNew 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 IETF

20. 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 IETF

21. 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 IETF

22. Deployment of aNew 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” IETF

23. 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 IETF

24. 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 IETF

25. End of Introduction Questions IETF