============================================================= Integrated Security Model for SNMP WG (isms) IETF #79, Beijing, China WEDNESDAY, November 10, 2010, 1510-1610, Room Pearl Minutes by Wes Hardaker and Juergen Schoenwaelder ============================================================= WG Chairs: Juergen Schoenwaelder Russ Mundy WG URL: http://tools.ietf.org/wg/isms/ Jabber: xmpp:isms@jabber.ietf.org AGENDA: 1) Agenda bashing, WG status (10 min) (Juergen Schoenwaelder, Russ Mundy) - Blue sheets - Minute and note takers - Jabber scribe 2) Kerberos Security Model (30 min) (Yiu L. Lee, Wes Hardaker) - shall we take on this work? 3) Charter Discussion (10 min) (Juergen Schoenwaelder, Russ Mundy) - discuss a new charter, proposals welcome 4) Wrap up and review of action items (10 min) (Juergen Schoenwaelder, Russ Mundy) WG RFCs: [1] Transport Subsystem for the Simple Network Management Protocol (SNMP) RFC 5590, [2] Transport Security Model for SNMP RFC 5591, [3] Secure Shell Transport Model for SNMP RFC 5592, [4] Remote Authentication Dial-In User Service (RADIUS) Usage for Simple Network Management Protocol (SNMP) Transport Models RFC 5608, [5] Transport Layer Security (TLS) Transport Model for the Simple Network Management Protocol (SNMP) RFC 5953, WG INTERNET DRAFTS: [6] Using Authentication, Authorization, and Accounting services to Dynamically Provision View-based Access Control Model User-to-Group Mappings RELATED INTERNET DRAFTS: [7] Kerberos Security Model for SNMPv3 Summary: The ISMS working group met in a one hour session on Wednesday at 15:10 to discuss a proposal for a Kerberos security model. The discussion centered around the question of whether or not a Kerberos security model should be added to the existing set of security models. At the end of the meeting, which was attended by a relatively small number of people, there was no consensus in the room as to whether or not the WG should take on the work to develop a Kerberos security model. The chairs have to address the need and adoption issue with the mailing list. For the (D)TLS transport of SNMP and related specifications, interoperability testing is ongoing with the goal to advance the specifications to Draft Standard. Actors: WH - Wes Hardaker JS - Juergen Schoenwaelder RM - Russ Mundy YL - Yiu Lee RG - Rich Graveman Slides: https://datatracker.ietf.org/meeting/79/materials.html Audio: http://www.ietf.org/audio/ietf79/ietf79-ch5-wed-noon2.mp3 Meeting Notes: After agenda bashing and WG status report, a request was made for implementations reports of RFCs 5590, 5591, 5953, and 5343. The rest of the meeting was spent discussing a proposal for a Kerberos security model. YL first presented his slides. The following notes cover some of the subsequent discussion. RG: How does the KDC know that the ticket is coming from a legitimate KDC? WH: There is a secret in the box, management of this secret is outside of the scope normally of Kerberos. RG: Who is going to run the Kerberos server? YL: The network/service provider. RG: Why not use DTLS with pre-shared keys? YL: Not available currently on the devices. RG: What does KSM offer that DTLS with long-lived pre-shared keys does not offer? WH: With TLS, all managers have to have access to all keys of the devices. With Kerberos, the KDC only has the keys and the KDC can provide authorization information. RG: What is the difference between the secret stored for the KDC and a secret stored for say DTLS? WH: Kerberos is a trusted third party system. TLS/DTLS with pre-shared keys requires that the keys for the devices are given to all management applications. Kerberos centralizes this since the device keys are only known to the KDC - and the KDC can also provide authorization information. RG: So this means that the KDC becomes a single point of failure. WH: You can do things to mitigate the single point of failure problem of the KDC. RM: It is true that a KDC is a single point of failure and these things should be discussed in the security considerations if this work goes forward. RG: Questions regarding popularity of Kerberos and whether it is a popular technology since the survey of a room couldn't find interest. RM: Reminds people that the original reason for starting the ISMS WG was to support security mechanisms that already exist in operational environments. RG: One of the stumbling blocks of IPsec was that applications could not get to the network and one of the stumbling blocks if Kerberos was that it requires modifications of the applications. JS: The cable network industry seems to be interested in KSM. What the cable network industry using currently to secure SNMP? YL: Nothing. JS: So this is the initial deployment of SNMP security... YL: Discussion of the SNMP history in cable modems. JS: How centralized is the management in your network? WH said that centralized key storage in the KDC is the benefit of Kerberos. YL: We do regular polls ever few minutes and we already have the Kerberos infrastructure in place. WH: Centralized authorization requires a RADIUS client embedded in the device to talk to a RADIUS server, which is not needed with Kerberos. RM: Any further input from the room concerning adoption as a WG work item? RG: Is this going to be experimental or standards-track? RM: This certainly needs to be decided and should be discussed on the list. YL: There were 2-3 people list on the list who committed resources to review these documents. JS: Anybody in the room (other than cable labs) who is interested to implement and/or deploy this? WH: NETSNMP has an implementation and it was deployed, but there were no questions about it recently anymore. JS: So it is out for 10 years? WH: Yes. There are some slight differences between the current ID and the running code. Even though Ken and myself are listed as co-authors, we are really more reviewers than authors. RG: Everything is a trade-off. My initial caution is if got a recommendation is to use (D)TLS to secure SNMP at the transport, what should we provide as guidance as to when KSM should we used? Have we proven existing solutions are not sufficient or aren't being used? I have no objection at all if it should go on an experimental track unless I hear a wider consensus that it should go on the standards track. RM: It seems you are saying that if this work is taken on, it requires a clear description how this relates to the other options available to secure SNMP. RM: SNMPv3 has many applications that it can be used for and when you look at security aspects, it can become a challenge to fit it into different operational environments. RG: No objection against this work but a lots of question why. WH: The TLS/DTLS work was driven by customers that wanted to use these transports. Since there are large Kerberos deployments, it may make sense to make SNMP work with existing security infrastructures, which is the goal of this working after all. JS: Since there is no strong motion in the room (which is very quiet) to support this work, we have to take this back to the list and see whether there is support on the list for this work.