==================================================== Minutes of the ISMS session at IETF 66 Wednesday, July 12, 2006, 1510-1610, Room 519B notes by Olivier Festor and Sharon Chisholm (jabber) edited by Juergen Schoenwaelder ==================================================== Chairs: Juergen Schoenwaelder (JS) Juergen Quittek (JQ) Content: 0. Relevant Documents 1. Session Summary 2. ISMS WG Status 3. Transprot Subsystem 4. Notifications and Session Establishment 5. Radius Integration 6. Wrap Up == 0. Relevant Documents == - Transport Mapping Security Model (TMSM) for SNMP - Secure Shell Security Model (SSHSM) for SNMP - RADIUS Usage for SNMP SSH Security Model - RADIUS NAS-Management Authorization == 1. Session Summary == The two existing WG I-Ds on a transport mapping model and on an SSH security model for SNMP still have few remaining decisions to be made. The room had consensus to introduce a transport sub-system into the TMSM document which has the effect of simplifying the terminology significantly. In particular, the TMSP becomes a transport model and the SMSP becomes a more generic session-based security model (which might map to multiple different session-based secure transports). The discussion on how to create sessions for notifications from a managed mode to a management system could still not get solved. From the management system point of view, there is a clear preference for initiating sessions in 'reverse' direction. However, the security problems implied by this approach might be too severe to use it. Finally, the WG discussed RADIUS integration of the SSH security model. There was consensus in the room to separate user authentication from authorization for establishing a session and from authorization required for access MIB elements. There seem to be different positions in the security community about whether or not 'authorization only' requests harmonize or dis-harmonize with the Kerberos architecture. == 2. ISMS WG Status == The core documents have improved significantly and only a few issues remain under discussion. Radius extension documents have been started. Volunteers are still needed for the applicability document. A short poll among the participants showed that 6 people in the room did read the transport mapping security model document, 4 people did read the secure shell document and no-one did read the radius document. == 3. Transport Subsystem == Dave Harrington (DH) explains that he likes to introduce a transport subsystem to simplify the documents. He proposes to change the SSH security model into a generic session-based security model. The SSH specific part would become an SSH transport model in the transport subsystem. He believes this change can be implemented by adding two more ASIs to the RFC 3411 architecture for the transport subsystem. See DH's slides. There was consensus in the room to follow the proposal and DH will make the required changes to the document. == 4. Notifications and Session Establishment == Juergen Schoenwaelder (JS) explains the issues involved with sending notification from a notification originator. In essence, the asymmetric nature of SSH authentication works nicely if the session has been established by a command generator (CG) or notification receiver (NR). The open question is what happens if such a session does not exist and the notification originator (NO) wants to deliver a notification. JS is basically concerned about having to configure credentials on agents. See JS's slides for the details. Robert Story (RS), Wes Hardacker (WH) and Sam Hartmans (SH) together pointed out that notification targets point to a host and associated parameters. If there are multiple sessions, the notification might be broadcasted to all suitable sessions which might be different from the model that is currently used by SNMP and clearly needs to be documented since a command generator today typically does not receive notifications. Margaret Wasserman (MW) questions whether a user is the target of a notification. She wants to send a notification to a log file under a given user's permissions. Bert Wijnen (BW) believes this is OK since one can create specific users for the notifications. WH believes this will work out, but the WG session may be the wrong place to work out the details. WH points out that an agent can use its host key to start an SNMP session but he believes this is not the identity to use for access control. A discussion of the approach which reverses roles took place. Chris Elliot (CE) says that he likes the idea. RS points out that it needs to be worked out how the notification receiver determines the user that is used to establish the SSH session. WH points out that this needs discussion with SSH experts since he expects security issues with this approach. Jeffrey Hutzelman (JH) explains that the hard issue is that SSH assumes that the SSH client knows the host it likes to talk to. This does not work in reverse since you do not know which host you are connected to nor whether you want to talk to that hosts. Some key exchange methods require to know the name of the host you like to talk to. There are additional issues with NATs where multiple agents appear as using a single IP address. SH suggests to have a conference call on this issue. == 5. Radius Integration == David Nelson (DN) goes through a list of issues (see DN's slides). There was a discussion whether separation of authentication and authorization causes issues with Kerberos. JH (chair of the Kerberos WG) says that he does not see a problem with Kerberos and authorize only. DH tries to explain the difference between authorization of a session (ssh subsystem) and authorization of access to managed objects. BW questions what the scope of the RADIUS authorization is. DH explains that the scope is security name to group name mapping within VACM since groups and the associated access control rules are typically rather static. Due to the lack of readers of the Radius document, the decision to accept the Radius document as a WG document was deferred. == 6. Wrap Up == Running out of meeting time. The notification authentication issues as well as the Radius issues will be further discussed on the mailing list.