1. Integrated Security Model for SNMPv3 (ISMS) pronounced "is" "miss" David T. Perkins & Wes Hardaker 60 th IETF August 6, 2004

2. 60th IETF 2 Problems to Solve The cost to deploy and operate SNMPv3 with USM (using auth/noPriv or auth/priv) is too high resulting in lack of usage. The security features that are needed for certain environments are not available (or not strong enough) in USM resulting in ruling out use of SNMPv3/USM in those environments.

3. 60th IETF 3 Solution 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 Provide for low cost evolution of crypto proto's No modification of existing SNMP specifications or modification of existing security systems

4. 60th IETF 4 SNMP Background SNMPv3 is an application layer protocol for management, which provides: –Configuration creation, deletion, and modification –Monitoring –Performing actions –Event reporting SNMPv3 was designed with a modular architecture to allow additions and replacements without changing SNMPv3 (see diagram that follows)

5. 60th IETF 5 SNMPv3: Architecture Dispatcher Message Processing Security UDP TCP... SNMPv3 MP User-based (USM) Network Application or Agent Access Control VACM CG CR NG NR SNMPv3 Engine New Model Modular & Extensible (Our new work)

6. 60th 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” SNMPv3 was designed to allow pluggable security models Presently, only one security model is defined, which is called User Security Model (USM)

7. 60th IETF 7 Functions of a Security Model Provides the Following Message Services: –Identity authentication of the message sender –Message authentication (data integrity; replay, re-order, and delay protection) –Disclosure protection (encryption) Services in sets called "security level" with values: –noAuthNoPriv: no authentication and no encryption –authNoPriv: authentication, but no encryption –authPriv: authentication and encryption

8. 60th IETF 8 SNMPv3 Message Format msgVersionmsgGlobalDatamsgSecurityParmsmsgData msgIDmsgMaxSizemsgFlagsmsgSecurityModel A unique number to identify each security model Security Model Specific Message type and security services, 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

9. 60th IETF 9 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 passphrase per user in a management domain is used to create a unique identity (and message) authentication key (and encryption key) per managed system Shared identities and keys between mgrs and agents

10. 60th IETF 10 Needed 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)

11. 60th IETF 11 Need Security Features (cont 1) 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

12. 60th IETF 12 Need Security Features (cont 2) Must have a low incremental cost to add a new session message authentication or encryption algorithm Must work with unmodified VACM Must have a low incremental cost to add new security features such as capability-based authorization

13. 60th IETF 13 Problems and Solutions Any solution must not lose track of the primary goal to integrate with existing security infrastructures without the need to change them. Also, any solution must support more than one security infrastructure because there is currently no overwhelming leader

14. 60th IETF 14 Changes What Must Change –SNMP library used by managers –SNMP agent toolkit What Shouldn't Change –Management apps that use an SNMP library –Access routines in SNMP agents –Existing security infrastructures and the security protocols that they use

15. 60th IETF 15 Identity Authentication Schemes Local database on the agent –Current USM –Local accounts –SSH key pairs Agent Verification via Identity Server –Radius –TACACS+ Pre-communication Verification by Mgr App –Kerberos –X.509 certs

16. 60th IETF 16 Security Infrastructures Supported by Each Proposal SBSM –All (Radius, TACACS+, Kerberos, SSH, local, X.509 certs, etc) Kerberos-based Security Model –Kerberos EUSM –Radius MISM –Only those that plaintext passphrase can be retrieved

17. 60th IETF 17 New Security Features By Each Proposal SBSM –Lots (see list) Kerberos-based Security Model –(finish this) EUSM –Session key MISM –Session key

18. 60th IETF 18 Changes Required By Each Proposal SBSM –Only agent and manager SNMP libraries Kerberos-based Security Model –Only agent and manager SNMP libraries EUSM –New Radius protocol extensions, Radius server, and agent and manager SNMP libraries MISM –New service, new SNMP objects and notification, and agent and manager SNMP libraries

19. 60th IETF 19 Discussion How do we make progress? Can we support development of multiple approaches and then test them?