======================================================= Integrated Security Model for SNMP WG (isms) at IETF 67 San Diego, Thursday, November 9, 2006 at 1510-1610 Taken by Juergen Quittek ======================================================= Chairs: Juergen Schoenwaelder Juergen Quittek Agenda: 0) Session summary 1) Agenda bashing, WG status 2) Discussion of existing WG drafts 3) Review of ISMS milestones 4) Performance analysis of SNMP over SSH ---------------- 0) Session summary As agreed at the last meeting, one of the two existing WG documents was split into two. The resulting three documents describe a transport subsystem for SNMP, a transport security model for SNMP, and a SSH security model for SNMP. The new document structure is more modular and simplifies the potential future specification of other security models, for example, a TLS security model in addition to the SSH model that the ISMS WG develops. The new document structure was approved by the WG and by the responsible AD Sam Hartman. For the transport subsystem for SNMP and the transport security model for SNMP all open issues have been resolved and the next versions of these documents will enter WGLC. The SSH transport model for SNMP will probably need two more revisions to be ready for WGLC. The biggest open issue is the authentication for notifications. The charter contains two more documents that do not yet exist. One describes the usage of RADIUS for the SSH transport model. We have an individual draft, but kept it on hold until the SSH security model had become sufficiently stable. This has been achieved with the current version of the SSH transport model. Now, work on the RADIUS document can go on and the initial WG draft is planned for December. The last document on the charter is an applicability statement for ISMS. With the new modular structure, the WG considers it preferable to have rather applicability statements per module instead of a generic one for ISMS. It was agreed to drop this document and instead add a specific applicability statement to the SSH security module. This change was approved by the responsible AD. ---------------- 1) WG Status (Juergen Quittek) Only two of the four planned WG documents do exist yet. One of them has been split. All are behind schedule. Therefore, we need a discussion of milestones later today. ---------------- 2) Discussion of existing WG drafts (David Harrington) - Transport Subsystem for SNMP draft-ietf-isms-tmsm-04.txt - Transport Security Model for SNMP draft-ietf-isms-transport-security-model-00.txt - Secure Shell Transport Model for SNMP draft-ietf-isms-secshell-05.txt The main change since last meeting is the new structure containing: - a transport subsystem - an SSH transport module - a session security model This structure was agreed at the last meeting, now it has been reflected by the document structure. David H presented current ISMS issues. For the transport subsystem there are - #1a How to integrated the transport subsystem into the current SNMP architecture? shall we pass all parameters through all involved SNMP ASIs? - #1b Which transport addressing scheme to be used (RFC3417, RFC3419, RFC4001)? RFC3417 (snmpDomains) are the preferred choice. Solves also issue #1a Jeff Hutzelman: What is in that SNMP address type? David H: The hostname. Jeff H: This does not have an effect our work so far? David H: Right. Jeff H: Sounds very SNMP-specific, but works OK. This is a solution we can solve within our WG scope. Other solutions might require extensions to SNMP architecture and would be out of scope. - #2 The transport subsystem MIB is not needed. Will be eliminated. All transport subsystem issues are solved. For the SSH transport model there are the following issues: - #1 It is not independent of the security model. May be possible to solve, but needs more work. Q: Why does it need to be independent? David H: You might want to use two different security models. Bert: Is the community name the securityName? David H: This may be wrong. We will fix it. Wes Hardaker: The implementers will do what needs to be done with the bits. What is separated here in the architecture may probably no be separated in an implementation. David H: Agreed. Jeff H: Can you still use USM for transport? David H: Implementors still have alternatives when implementing systems. They may not implement a transport model, but we want to make a recommendation on how it can be done. We still have to work through all the elements of procedure. Juergen S: (via Jabber) I think the security model is determined by the SNMPv3 message. We just have to check that the transport security model properly checks that a valid tmStateReference is available from a secure transport. Wes: The implementers will do what need to be done. Separation is hard to get. They are bound. Sam Hartman: Is the proposal to separate the TMSM from SSH TM so you can use another security model with SSH? David H: Yes. Juergen S: The transport security model which is left essentially looks at the tmStateReference to pick up the required data from a secure transport and then passes things on. Since the security model is determined by the SNMPv3 message, we can in principle run other security models on top of SSH. Wes: You are adding a lot of complexity with very little gain. Your user base will be pretty small. Jeff H: It is not necessarily additional complexity, but an abstraction that the security model and the transport model are separate. David H: The next version of the document will have this problem solved or state that it cannot be solved. - #2 The SSH TM does not do everything that USM can do. USM has a built-in discovery mechanism. We do not yet have a discovery mechanism built into the SSH TM or the Transport SM. One solution would be saying 'Let USM do this discovery of the context engine ID'. Wes: USM does not discover the context engine ID, but the security engine ID. David H: Correct. It's the security engine ID. At this point in time we use USM for that discovery. I would like at some time in the future to see a new mechanism doing discovery for any kind of transport model and any security model. Jeff H: SSH does not need a security engine ID? David H: No. We discover the security engine ID only in order to get the context engine ID. We also rely on USM if you want to send a notification and no session has been set up yet. Eliot Lear: (via Jabber) If you are using USM for notifications, you have to define the USM user on every agent. What we are doing here is getting around that. In effect you are saying you cannot use notification if you want to benefit from ISMS. David H: Call home is not on our charter. If I want a device to send some traps, I want to configure anyway where to send them to. I don't want them to be sent to random destinations. - #3 We had a teleconference on asymmetric notification authentication but did not find a solution. There are three options described on the slides. For the transport security model issues are solved. Some details need to be worked out in the next revision, but then we should be close to WG last call. ---------------- 3) Review of ISMS milestones (Juergen Quittek) ISMS is behind schedule. Planned was to submit the transport subsystem document and the SSH security model to the IESG in August 06. Now we have split the planned SSH security model into a transport security model and a SSH transport model. Juergen Q: Does anybody have a problem with splitting this document? Nobody spoke up. David H: The transport subsystem will be ready for WGLC after the next revision. The security model may also be ready after the next revision. The SSH transport model needs some more work. Juergen Q: Let's set the deadlines to February for the first two and to April for the SSH transport model. The document on RADIUS usage for the SSH transport model does not exist as a WG draft but as an individual I-D. This was OK, since the SSH security model has been a moving target. But now it seems to have become sufficiently stable to start working on the RADIUS document. Juergen Q: Can we have a first version of the WG I-D in December. David Nelson: We can have a document reflecting the current structure by December. The charter contains another document: the ISMS applicability statement. It was suggested to not have this document, but move applicability statements into the SSH transport model. David H: The applicability of the SSH transport model do not necessarily impact other transport models. Having its applicability stated in the same document is probably the best way to go. Juergen Q: This means we have to extend the SSH transport I-D by an applicability section. Juergen Q: Does anyone have a problem with removing this document from our charter? Nobody spoke up. ---------------- 4) Performance analysis of SNMP over SSH (Vladislav Marinov) Vladislav presented measurements of performance for session-based security vs. message-based security with a prototype implementation. Wes: Excellent results. There are some caveats. The NET-SNMP implementation of SNMPv3 was not implemented for speed and uses some obviously slow mechanisms that can be improved. We use OIDs as index and we don't do caching everytime a packet comes in we do a complex lookup.