=========================================== Minutes of the ISMS session at IETF 65 Wednesday, March 22, 09:00 h - 11: 30 h taken by David Partain =========================================== Integrated Security Model for SNMP working group Chairs: Juergen Schoenwaelder (JS) Juergen Quittek (JQ) 0. Session Summary 1. ISMS WG Status 2. Discussion of SSH model and TMSM open issues 3. Discussion of Radius integration open issues 4. Wrap up ---------------- Discussed Internet drafts Secure Shell Security Model for SNMP Transport Mapping Security Model (TMSM) ---------------- 0. Session Summary The ISMS discussed the open issues concerning the transport mapping security model and SSH security model that were identified at the interim meeting in February. Most of them are concerning SNMP notifications. For all issues full or partial solutions were proposed and the documents will be updated accordingly. For the remaining two documents (radius integration and applicability statement), first versions are scheduled in April. ---------------- 1. ISMS WG Status (JQ) JQ explained that versions of the first two of the planned four WG documents are available. The remaining two documents concern the integration of ISMS into Radius and the applicability of ISMS. For the integration into Radius, Kaushik Narayan and David Nelson volunteered for editing the document. Futher volunteers are highly welcome. For the applicability statement, volunteers are still missing. Initial versions of both documents are scheduled in April. At the interim meeting in February, good progress was made on solving issues of the of the SSH security model (SSHSM) have been solved. Remaining issues are listed at the ISMS Wiki page at . Issues are concern session management, SSH authentication, and Radius integration. ---------------- 2. Discussion of SSH model open issues (David Harrington, DH)) David discussed the list of open issues that are listed on the slides. The first group of issues (SQ1-SQ7) concern session mamagement. SQ1: When should the session be set up? Slide discusses options. SQ2: Reuse of sessions. No clear answer. If we cannot reuse a request/response session for notifications, we may need to be able to determine what kind of session we're using. Need to go through the doc to make sure that we have the info we need at the appropriate places to determine if re-use is appropriate. WH (Wes Hardaker): Is the goal to allow someone to set up a session and that then the other side may arbitrarily send notifications over that connection or do we require that for this some set operations are required to configure the notification targets? DH: Notifications require preconfiguration. WH: Yes, the stuff is configured but not which session. We have managers that won't be happy if you randomly send them notifications in a stream where they are only expecting responses/reports. JH (Jeff Hutzelman): If you're going to send a notification, you have a transport address and appropriate credentials and it'll be up to the transport mapping to determine which session it should use to send that, including perhaps setting up a new session. Interesting new question is the one where managers may not be prepared to accept the notifications. WH: This may be a non-issue. WH: We may need a new transport domain identifying sessions. SQ3: (no discussion) SQ4: (no discussion) SQ5: (no discussion) SQ6: (no discussion) SQ7: (no discussion) The second group of issues (AQ1-AQ4) deals with authentication issues. AQ1: Does notification delivery via SSH require user authentication of the notification originator and host authentication of the notification receiver? WH: Careful about how you use "user authentication" so it isn't confused with "username/password" since there are other ways to do authentication. Perhaps "client side" authentication. AQ2: Does notification delivery via SSH require host authentication of the notification originator and user authentication of the notification receiver? AQ3: Should both authentication styles outlined above be supported and runtime configurable? AQ4: Is it possible/useful to have a "turn" mechanism in SSH which allows a process to initiate the SSH protocol but later turn the automatically assigned client role into a server role? This is not possible in SSH, but higher-layer functionality such as channels may be turned or may be symmetric. WH: why do you want to turn them? DH: For call home. WH: This means you turn the authentication? DH: Yes. WH: No, you can't do this. You don't need to reverse SSH roles to send SNMP requests in one direction or another. You don't need to turn the connection. You just need to be able to authenticate appropriately in both directions. There are VACM issues, though. JH: Yes, we've talked about this before (and will talk about it again). We think we can do appropriate mapping to deal with the VACM issues. ---------------- 3. Discussion of Radius integration open issues David Nelson (DN) discussed the list of open issues in Radius integration (RQ1-RQ3) that were listed on the Wiki page. RQ1: How does AAA hook into the overall model? Is AAA integration transparent from the viewpoint of the SNMP architecture or are explicit hooks required to make things work? DN: This is till to be determined. We'd like to separate authentication and authorization. Authentication done in one protocol and authorization in another. Authentication will be handled by SHH and it is transparent to the SNMP architecture. For authorization, we discussed at the interim that it should be independent of the authentication and the should be means to send separate requests on it. DH: In terms of accounting, the security name was specifically made readable for logging purposes. Perhaps something we should make use of. JH: sounds like an implementation issue to me. RQ2: hat is the exact information that needs to be exchanged between an SNMP entity supporting ISMS and an AAA server? DN: Exchange credentials supported in RADIUS (username/pw, PAP, CHAP, EAP, textual challenge/response). For access control we need a mapping between the authenticated identity and the security name to be used in the current authorization process. RQ3: What happens to long lasting sessions? Is there a mechanism to re-check AAA information? How is an SNMP engine supposed to react if the re-check of AAA information is negative? DN: There are provisions (Session-Timeout) for this in RADIUS. ---------------- 4. Wrap up JS (Juergen Schoenwaelder via Jabber): Who has read the documents TMSM: 3 (excluding authors, chairs, ADs) SSHSM: 7 (excluding authors, chairs, ADs) JS: Who would volunteer to review the documents? Bert Wijnen, Eliot Lear, Sumanth Channabasappa, David Nelson/Perkins? JS: Who is implementing? EL (Eliot Lear): Cisco is looking at it. No commitment. BW: Sam Hartman is not here. He's going to want know what's going on. He'll perhaps be disappointed by the fact that no one's going to implement. Multiple people pointed out that there is a need for something like this, but that it is a bit early to decide on wheter or not to implement it. DP (David Perkins): There are various levels of support for even SNMPv3 today. EL: Until we see the final spec, we won't know what we're getting into. If we don't know what the final result is, we can't really commit. SC (Sumanth Channabasappa): Cablelabs is definitely looking at it. JS: Intl. University of bremen is working on hacking ISMS into netsnmp using libssh. JQ: We are also promoting this to the network management division. They're conservative and slow. DH: Huawei is looking at prototyping ISMS. After solving the major open issues on the Wiki page, David Harrington explained the more detailed open issues that are listed in the TMSM and SSHSM draft. One of the open issues to be worked on is #23 in the SSHSM document: How should we enable auto-discovery? JQ: We went through all the open issue and now have solutions for all major ones. JH: Yes, but still Ihave the impression like we're not getting much movement. Maybe that's because there's been a lot of discussion and we need to get a new version of the spec? Also, where's the discussion happening? it's not on the mailing list. We need to have discussion on the mailing list. Not doing it there excludes people. DH: Discussion so far was very complex. JQ: Chairs are concerned about participation on the list. At the interim meeting it became clear that even the best experts have problems to get a clear understanding of the issues. Now, most of the severe problems are solved. I expect that when the next version of the drafts is out, discussion will be much easier and there will be more discussion on the list. DH: We will post the descision made in the editors meeting yesterday on the list.