|
==========================================
Minutes of the ISMS BOF session at IETF 60 Friday August 6, 9:00 h - 11:30 h ========================================== Integrated Security Module foe SNMP BOF Chaired by Wes Hardaker Minutes taken by Juergen Quittek 0. Session Summary 1. Introduction to problem space 2. Charter Discussion 3. EUSM - External User security Model 4. KSM - Kerberos Security Model 5. A Minimal Approach 6. SBSM - Session-Based Security Model 7. Discussion ---------------- 0. Session Summary At this BoF session, several approaches for integrating SNMPv3 security into existing security infrastructure were presented. It was agreed that there is a need for standardizing such an integration. A charter for this work was discussed. There was no agreement on which approach to use yet. Choosing one will be the first major milestone of a working group on this issue. It was suggested that such a working group should get a tight deadline for making this decision. ---------------- 1. Introduction to problem space (presented by Wes Haraker, slides by David Perkins) The problem to solve is high cost of SNMPv3 deployment. The goal of the proposed WG is reducing this cost. This should be achieved by re-using existing SNMP and security infrastructure and without modifying the existing SNMPv3 full standard. Wes explained the SNMPv3 architecture and suggested that the WG should standardize a new security model providing authentication, integrity, and privacy, which can be used instead of (or in parallel to the User-based Security Model (USM). A new model must be designed such that it works well with the View-based Access Control Model (VACM). [Eric Fleischman] Operators view should be considered. Wes further suggested the idea of not necessarily disclosing identities. [?] What is anonymous access useful for? [Wes] It may be useful for accessing services anonymously [?] Isn't that not equivalent with noAuth/priv? [Wes] No, noAuthPriv does not provide integrity. Wes further explained what needs to be changed and what should remain unchanged: SNMP libraries and agent toolkit to be changed, management infrastructure should remain unchanged as well as the existing security infrastructures. ---------------- 2. Charter Discussion The first BOF session on this topic was held at IETF 58 in Minneapolis, but there were no operators were present. Since then the issue was presented at NANOG and Wes conducted an electronic survey. [Erik F] What is an operator? [Wes] A network operator Wes showed graphs on the result of the survey. Almost all use SNMP for monitoring, many for alarms and events, 15% also for configuration. 50% SNMPv1, 50% SNMPv2, 25% SNMPv3. A majority considers configuring SNMPv3 an urgent problem. Most think USM does, however, provide sufficient security properties. Asked for what security infrastructure were currently in use, responses were (in order) local accounts, ssh keys, radius, tacacs+, X.509 certificates, and others. When asked what identification mechanisms operators wanted to use, they responded (in order) radius, SSH keys, kerberos, and X.509 certificates, and others. [?] They all want a known mechanism, but they don't all want the same known mechanism. [Wes] Everybody thinks that their environment is special. Many use local accounts and do not have a problem with it. [Chris Eliott] It should be possible to combine some of the used methods. [Wes] You can also combine local accounts and SSH keys. [Chris] No, I think you can't. but they do not exclude mutually. Wes presented a slide showing that radius and SSH keys are the infrastructures not-in use but wanted most by operators. [Eric R] Wouldn't it be good to invent a new one? [Erik F] We are installing a new card-based security system at Boeing Integration into existing systmes is essential [Wes] I was hoping to see more requests for X.509. [?] Sometimes different mechanisms are used for authentication and privacy/integrity [Wes] Yes, this should have been separated Wes explained that 30% of the operators would still use USM if a methods were avaiable. [David Nelson] They might like to use USM in addition as backup in case the security infrastructure fails. Wes started discussing requirements for a solution. It must be possible to integrate with an existing infrastructure. It must not be less secure than USM. It must work without modifying the SNMPv3 standard. It must work with all SNMPv3 message types. It should support managing a box during times of network instability. [Juergen Quittek] The problem of configuring SNMPv3 has two parts: USM configuration and VACM configuration. We should also consider VACM. [Wes] We should not cover both at once. Solutions may not be able to support VACM configuration. [Juergen] Solutions should be open for adding VACM support later. [Russ Mundy] It was a lot of work separating things well in SNMPv3. We should be careful not to do too much at once. [Chris Elliott] We should make it a requirement that integration with VACM configuration is not precluded. [?] 'Should not be less secure than SNMPv3/USM' is not a reasonable requirement. It will be hard to check this [Eric F] this means different things to different people [Sharon] Still the security level of v3/USM should be matched. We should understand well any loss of security below that level and ensure we have a very good reason for it. [Wes] We want not to modify existing security standards. [Chris] The desired solution is a new security model. [Bert] We should add to the charter, that solving the security configuration solves one part, but the problem of VACM configuration remains. [?] TACACS+ is listed in the charter as security infrastructure to consider but TACACS+ is not a standard. [Eric F] It is not recommendable having a fixed list of security infrastructures to be supported. [Wes] We should support the most used security infrastructures. [Randy Presuhn] Creating a security model is not enough, we should also consider well operational practice. [Chris] The protocol itself should support multiple security infrastructures, but a single implementation should be free to use only one of them. [David] Give a recommendation of a preferred infrastructure. [Eric R] There are already three IETF WGs defining security frameworks. Their output should be re-used. [Juergen] Why there no standards on the list of infrastructures? Should not at least Diameter make it into the list, which is used by 3GPP? [Wes] Primary goal is supporting existing infrastructures. [Bert] Is it consensus, that the list is to be considered, not "must be supported"? [Wes] Yes. [Bert] If we charter the WG, it will be chartered for 6 months. If then there is way to a solution agreed on, then the WG can be re-chartered. [Wes] 6 months should mean 2 IETF meetings. [Steve Bellovin] Yes. [Steve] We want the WG to make the hard decisions early. Do we all agree with that? [no disagreement] This ended the charter discussion. Individual presentations of the proposed solutions started. The list of proposals includes EUSM - External User security Model KSM - Kerberos Security Model SBSM - Session-Based Security Model TLS - Transport Layer Security [no proposal or presentation but there is interest in seeing one]. MIASMA - A recent proposal from Randy Presuhn. ---------------- 3. EUSM - External User security Model (Kaushik Narayan) draft-kaushik-snmp-external-usm-00.txt Kaushik Narayan presented EUSM. EUSM defines a framework for SNMPv3 authentication and key distribution via an external AAA server. SNMPv3 authentication and privacy keys are served from an external AAA server to the agents based on the user identity. By caching the proposed scheme avoids an AAA request per SNMP request. [?] How is lifetime of cached values negotiated? [Kuashik] EAP is negotiating master session key. AAA server will send lifetime. [Bernhard] The agent operates a key cache, but the manager not. How does this work well? [Kuashik] for the manager this is not necessary. [?] I am concerned about this. Can we discuss it on the list? Kuashik reported that and implementation for IOS is almost complete. [David Nelson] In case of requests you have a user identity, in case of a notification do you have a machine identity? [Wes] There is little time. The presentations are intended to give a high-level overview. Let's have this discussion not at this session but on the list. ---------------- 4. KSM - Kerberos Security Model (Michael Baer) draft-hornstein-snmpv3-ksm-02.txt Michael presented the Kerberos Security Model (KSM). This SNMPv3 security model integrates the kerberos mechanisms for providing security. Michael described the steps of interaction with the kerberos infrastructure required for a sender of an SNMP message and for a receiver of an SNMP message. [David] Is there a different flow for requests and informs? [Michael] Yes, you can derive the procedure for informs from the one for requests. ---------------- 5. A Minimal Approach Randy Presuhn explains his idea of a minimal approach. He suggests distributing keys via SNMP using extensions of the USM MIB. A security administrator assistant application would interact with an existing security infrastructure and distribute keys to all SNMPv3 agents for which the keys are relevant. While in the EUSM keys are pulled, here they are pushed. It's the approach with the least need for standardization. Just an augmentation of the USM MIB is required. Key lifetime is a critical issue. Default should be 'never expires'. [David] At the protocol level, is it USM? [Randy] yes [?] Does the agent have some mechanism to download keys for users that do not have a role defined? [Randy] Unknown users go to this application. [?] Is there just key expiration or also user expiration? [Randy] In addition to key expiration, it also supports user expiration [Chris] This model achieves very high compatibility with existing USM ---------------- 6. SBSM - Session-Based Security Model Wes explains that this security model for SNMP creates sessions between two endpoints. It allows compression and supports multiple types of identification. It was already presented at the SBSM BoF in Minneapolis. [?] How do you calculate the EngineID? [Wes] It is negotiated during the session establishment. [?] Does it work well for huge numbers of systems? [Wes] Yes. ---------------- 7. Discussion [Wes] More proposals are welcome Wes presented a table comparing the discussed approaches. and a yet unspecified TLS approach to the existing USM. [Sharon Chisolm] This comparison does not necessarily match the requierements There was full agreement that this problem needs to be solved by the IETF. The decision about a solution will be made in December. [Bert] Are there candidates for a chair [Wes] There is one from the security area, there should be a second one from the management area. [Bert] Please re-submit the charter. [?] Should there be an explicit call by the IETF for solutions? [Bert] People receiving the open call would have very limited time, since the final deadline for submission will be October 19. [Eric F] the real question is which security framework to support [Bert] Do you mean, we also need to know by October 19, which frameworks to support [Randy] Some of the proposals are specific for certain infrastructures. The authors need to solve in how far they could integrate with other infrastructures. For the proposals that are not specific, the authors need to analyze which infrastuctures they can support. [Steve] It is very useful checking all security features of the proposals against requirements. Wes asked the audience for preferences [sharon] Why is TLS in the List? [Chris] TLS meets most requirements. [Eric] How much security is required ? |