Integrated Security Model for SNMPv3 (ISMS) pronounced "is" "miss"

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

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

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

8. msgID msgMaxSize msgFlags msgSecurityModel SNMPv3 Message Format msgVersion msgGlobalData msgSecurityParms msgData 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 A unique number to identify each security model 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 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) 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 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 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 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 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 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 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 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 60th IETF

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