Last Modified: 2005-07-08
| Done | Cut-off date for internet-drafts to be submitted to the working group for consideration as a proposed solution | |
| Done | Decision about which architecture the WG will focus its efforts on | |
| Aug 05 | Working group will recharter to include publication goals or shutdown if no consensus on a technical direction is reached by this time |
|
===========================================
Minutes of the ISMS session at IETF 63 Tuesday August 2, 14:00 h - 16:00 h taken by Martin Stiemerling =========================================== Integrated Security Model for SNMP working group
Chairs: Ken Hornstein (KH) <kenh@cmf.nrl.navy.mil>
Juergen Quittek (JQ) <quittek@netlab.nec.de>
0. Session Summary 1. ISMS WG Status 2. SNMP & BEEP 3. Selection of the ISMS transport protocol 4. Wrap up ---------------- Discussed Internet drafts Transport Layer Security Model (TLSM) for the Simple Network Management Protocol version 3 (SNMPv3) http://www.ietf.org/internet-drafts/draft-schoenw-snmp-tlsm-02.txt A BEEP Profile for SNMPv3 PDUs http://www.ietf.org/internet-drafts/draft-kaushik-isms-btsm-01.txt ---------------- 0. Session Summary In April the WG achieved (very rough) consensus on using an encapsulated keying architecture (as used by the TLSM proposal). At this meeting the WG progressed the decision on a transport protocol to be used by ISMS. Candidate protocols were TLS+SASL, SSH, DTLS, and BEEP. Among the proposals, DTLS is the only one based on UDP. Since DTLS is not yet commonly deployed and not extensively tested, it was eliminated from the discussion after the WG agreed that UDP transport is not necessarily required for the ISMS solution. For all of the remaining three protocols there was support in the WG. Among them, SSH had clearly the strongest support, mainly, because SSH is already widely deployed and used in network management and thus could best achieve the goal of integrating the ISMS solution into existing security infrastructures. Within the session there was a consensus on choosing only one protocol as work item and there was rough consensus that this protocol would be SSH. The consensus still needs to be confirmed on the mailing list. ---------------- 1. ISMS WG Status (JQ) In April the WG achieved (very rough) consensus on using an encapsulated keying architecture (as used by the TLSM proposal). At this meeting the WG progressed the decision on a transport protocol to be used by ISMS. Candidate protocols were TLS+SASL, SSH, DTLS, and BEEP. ---------------- 2. SNMP & BEEP (Eliot Lear, EL)) Eliot presented draft-kaushik-isms-btsm-01.txt on 'A BEEP Profile for SNMPv3 PDUs'. (ER, Eric Rescola) Why is BEEP initiated in either direction? (EL) beep is meant peer2peer, could be done in SSH too, but nobody has done (JQ) What is the advantage of this proposal? (EL) All (almost) IETF protocols re-used. SSL used in other groups (such as NETCONF) too. Reuse of existing security associations groups (such as NETCONF) too. Reuse of existing security associations (JQ) NETCONF says SSH is mandatory and BEEP is optional (EL) Preference is BEEP (BW, Bert Wijnen) EL is a co-author of BEEP, so I understand that he prefers BEEP. Do we want the operators to be forced to use BEEP or TLS? So I wondered that we must not answer "what is the best solution" but instead we must answer "what is the best solution for operators". I also worry that here we would choose BEEP, while in NetConf we have chosen SSH as the mandatory to implement and BEEP as an optional to implement. I would think operators want the same mandatory to implement SSH for NetConf and ISMS. (EL) BEEP features peer2peer and that features is nice for ISMS (JQ) A problem with the choice of SSH in NETCONF was missing support of notifications. (EL) Difference between notifications in NETCONF and ISMS. NETCONF looks like syslog. Notifications not fully specified in ISMS yet. (BW) One or two mechanisms, what is the operators opinion? (DH David Harrington via jabber) If BEEP is used is it possible to integrate syslog, NETCONF, and ISMS. (SH, Sam Hartman) Why not using SSH or BEEP for notifications? (EL) If you use the same connection must be authenticated in the same way. (UB, Uri Blumenthal) May be different security mechanisms for different operations. Do not care about using it know. Is it OK to use TCP for retrieval and UDP for pinging. ---------------- 3. Selection of the ISMS transport protocol (ER) Pretty clean cut needed. Datagram mode of operation needed or not? (UB) As Wes pointed out on the mailing list, it does not matter if TCP or UDP if network is in regular operation. Need UDP if network is in trouble. (JQ) We can agree on several ways and do not need to focus on single. But we need to eliminate choices. (UB) If network is in trouble, than TCP is in trouble, than you do need datagram in this case. (MS, Mike StJohns) Major problem in security transport is messages can going back and forth in the beginning. Reuse of credentials. (EL) ... (JQ) More comments whether we need the UDP transport, I think it is needed. (UB) What is the scope the proposed solution. Is it supposed to cover notifications, access control. (SC, Sharon Chisholm) Not sure whether to decide yet on whether datagram or connection oriented. Basic question: Do we need notifications. Yes! What are the other requirements. (UB) Does not concur with observations. (JQ) They will probably use SSH in this case (ER) Two axes here, transport mode and what form of authentication. Do you need flexible authentication and/or datagram? (MS) ... Dealing with cable modems, got only to talk if in trouble. (DH) We need UDP for certain purposes, but non UDP can be used for other purposes. We need UDP to troubleshoot broken networks, but TCP would be good for downloading large tables when the network is running fine. (JQ) You need some authentication, if this needs to come over TCP, then why bother with UDP? (EL) Radius runs over TCP (ER) Got a matrix here, ... use DTLS if pki and shared secret is fine, SASL+TLS or BEEP, flexible authentication no datagram...SASL+TLS or BEEP in terms of flexibility good. I would cut SSH out as the authentication model is not so flexible as SASL. (SC) Concerns on interworking (SH) Why is SSH not so flexible? (ER) SSH is back on the list (DH) ... (EL) If Dave's point is that we can use what we have, it is fine. (ER) ... (JQ) We've got an improved view but no decision yet. (DP, David Perkins) You can create username and password on a system I'm working on. An ideal solution would you allow two sets of user names and passwords. (JQ) Do we need both, the TCP and the UDP protocols? (SC) Don't we have list of requirements somewhere, and evaluate the proposals against these requirements. (JQ) Either we need notifications or not? (SC) Notifications is requirement, datagram not. (JQ) We do need notifications! We should make a decision at some time. If we end up with three proposals we need to go back to the requirements. Do we really need the datagram in ISMS networks? (DH) Optional use secured datagram might be a future extension. (WH, Wes Hardaker via jabber) ... (UB) Existing infrastructure offer mean to authenticate but not session. IPsec has certain infrastructure, but it uses IP datagrams. But choosing kerberos, PKI, or whatever does not matter on the transport. They are independent. (JQ) Do we have an alternative suggestion to progress in this discussions? (UB) My personal opinion is adding ways to add, to obtain keying material for the session and reuses whatever it is to protect the traffic. This seems to be the simplest and the most straight forward. (JQ) I'm not fully sure that I got this. (UB) Current USM security is like IPsec with manual keying. People want automated keying and automation whatever they have already. Based on authentication derive short lived keys (SH) How is this in scope of authentication keying? (UB) Probably misunderstanding in terminology. What is missing currently in the model, ... (JQ) I also still the conflict of not having a decision in not having on authentication keying. (JQ) Yes, do we need a datagram mode of operation, or eliminate it? Do we support datagram transport mode for ISMS? People who think so please hum now. [no humming to be heard] (JQ) Please speak up if anybody thinks we need datagram mode. [Nobody spoke up] (JQ) Please speak up if you think we should not eliminate DTLS from the list. [Nobody spoke up] (JQ) It is not a mature protocol yet as the other protocols. No objections to eliminate DTLS. Three candidates left. (DH) Who proposed DTLS as transport protocol? (CE, Chris Elliot) SNMP is most often used in network devices that don't do application devices things. A lot of these network devices are traditionally managed over telnet and now moving to SSH. Running SNMP over SSH, boxes have it anyway. I have the feeling SSH is the better fit. (EL) Call home is basically, where the network element is initiating to be managed. (SH) Lets have a discussion about whether call home is necessary? (EL) Can have persistence connection, because of firewall. You wanna turn the connection round. (SH) SSH supports call home today. Some auth mechanisms where call home in one direction can use it but not the other. I'm just wrong. (RP, Randy Preshun) Call home is essential for configurations, to deliver notifications to other devices not online now (SC) Call home is a new call home. Helps with the firewall problem but was not in scope (RP) Does not origin in firewall. (SC) Agents initiating communication could introduce new types of attacks and need to think a lot of it. (SH) Agent wants to send notification, would it be sufficient to open SSH connection, back to central server, do authentication and dropping a note. (EL) This would one function for call home. Two aspects: basic get request and response, the other the notifications. Call home says, you have the option the element initiating the TCP connection back to the manager, and everything gets tunneled via the TCP connection. (SH) Some mechanisms of authentication will work in one direction but not in the other (EL) ... (SH) SSH mechanisms should be considered if enough (CE) Distinction between SASL+TLS and BEEP. Channel multiplexing over TCP than BEEP needs to eliminated. (EL) What are the benefits of BEEP: Channel multiplexing and framing. Benefit of sharing TCP connection, use the same authentication and ensure the security association, ... (GW, Glenn Waters) ... (ER) SSH/TLS which side is the active open. ... (DP) Yes you do. (RP) Some elements act as manager, many elements acting as agent, some do both. An example are the DISMAN MIBs (doing both agent and manager). (UB) A piece that does managing is a difference piece of the agent (RP) They are different entities, but SNMP architecture allows to share single engine. DISMAN and RMON have underlying single engine. (UB) ... (RP) Applications know who they are, the engine acts on behave of the application. (DP) Different ways to go in SNMP implementations. Pretty feel strongly, majority are not dual role entities. (ER) SASL+TLS / SSH have clearly client and server role. (ER) based on network topology, then need 1000 TCP connections in both directions, ... (BW) I was really reluctant to charter this WG in my area. Initially security people pushed for SSL, SASL, later operators looked for solution. Operators should be able to reuse their technology. SSH is their mandatory protocol. Unhappy about the few operators here do not speak up. BEEP may show up in the future but is not used yet. Merge with what infrastructure operators are using. Which protocols meet the needs of the security space? SSH to meet them, otherwise would have been swept of the table by ISPs. (GW) Who really cares if the operators use SSH? SSH is great for typing, but nobody is typing NETCONF commands via SSH. (BW) It is not whether to type at the terminal or if beep has more features than SSH; Beep exists only some/few devices, but SSH is available on many (most) devices. So that is what operators need/want (I would think). (GW) Do we need to deploy multiple stacks? (BW) Do we need multiple stacks, if one WG (NETCONF) chooses BEEP and another an another protocol? (GW) Merge them into a small set. Don't care about the protocol. Secondary to the problem is decreasing code size. Key issue is functionality to get (RV, Ruediger Volk) To a large extend I agree with Glenn. If the vendors deliver many stacks in the box, I don't care. Syslogs could go with beep, so we have it already. There is not much infrastructure to use SNMP via something, there is not much. For NETCONF I can envision typing command, but not for SNMP. (RP) Focusing on the choice of the security protocol and not considering the authentication infrastructure we miss the integration. Implementations missing hooks for infrastructure we wouldn't do them a favor. (EL) Juergen's work is good but not complete... (JQ) Technical comment on the SSH issue: Many operators are using SSH for configuration and troubleshooting. Even if we propose a different protocol, operators will not automatically move to the new protocol. (JS, Juergen Schoenwaelder) Whatever comes out of the discussion, the solution must integrate with SSH. (SH) There are many jabber questions not answered yet. (JQ) Somebody following the jabber comments? (SL, Simon Leinen) Practically SSH password authentication is used even though it is not the best solution. (N?, Nico ? via jabber) Why not having a trivial notification mechanisms to solve the call home. (DH) Proposal from TLS, SALS, DTLS to see problems arise. (N?) ... (EL) Trivial notification to call home. First, send text and if you have send text consider I will consider firewalls. Different administrative domains to consider. Rather then choosing a proposal, seeing them all. It needs to be mature. (JQ) More questions or statements on the choices we have? (JQ) When there are no new arguments we can discuss a different approach. Look at NETCONF, taking three approaches, deciding on one mandatory one and two optional. Need statement for what to go. I do not like the idea of developing several solutions in parallel. (EL) I do not think the proposals are ready to make the choice. We have bits for BEEP other for TLS. If draft proposals do not advance decisions are rather academic. (DN, David Nelson) What are the other pieces of infrastructure? Changes to managed entities, ... Talking SSH, talking about human fingers typing commands, scripty. Talking about SNMP, means talking about applications with GUIs. (JS) If you have an SSH account on your device, you do not need any additional work to get secure transport running. (EL) All drafts need to take into account firewall configurations. (JQ) How is the current state of the WG. Hand waving on three approaches: TLS+SASL: 5 raised hands (including jabber) SSH: big majority in room BEEP: 7 raised hands (including jabber) (RP) DTLS (JQ) DTLS has been eliminated (JQ) Are there volunteers for writing drafts? [for each protocol there were few volunteers] (JQ) Are there people willing to participate in the WG by reading, giving comments. [several hands raised, (DH on Jabber) (SC) Go for one solution. NETCONF and SNMP are different grounds. (EL) Would be nice to have a solution. I would prefer a single solution compared to multiple solutions. (SH) As an AD, I think there needs to be one mandatory to implement solution. There can be other solutions, but that should be because there is a market demand for the other solutions or because the other solutions work in different environments. However if we have multiple solutions it needs to be because we believe multiple solutions are needed not because we are unable to make a decision between solutions. (RP) I've got strong preference to one solution. People should say if they have SSH implementation that talk to YXC authentication infrastructure. (EL) We see the alternatives on SSL/TLS. Proposal for a charter change. (EL) Shoot in our foot if we press to fast for people getting a draft out. (WH) Wondering if we consider two protocols. One for TCP, one for UDP. (N?) can write text but no formats (JH, J. Hutz via jabber) Design SSH solution, writing text, but not being primary editor (JQ) We are getting close to a decision. Looks like we are going for a single solution, at least for the first stage. There is a majority for using SSH. I tend to go for SSH. (SH) I haven't committed to the get change. (JQ) Please hum if we should extend the decisions to Vancouver. [Hum against a little bit stronger than the hum for]. (JQ) Sam do you think we have to wait until we make the decision. (SH) Interesting to know WG opinion. But opinion independent of my decision. (JQ) Rough consensus for going with SSH, shaping charter for this WG. (SH) Send charter proposal by end of next week. Must be done in August (JQ) JS has made a proposal, not yet talked with Ken. (DH) Willing to work on SSH portions. (JQ) No time to do charter discussions now. Suggestions to be discussed on the mailing lists ---------------- 4. Wrap up (JQ) Got some volunteers to do work. Lets wait for charter to complete (SH) Start work now. There is the possibility that somebody comes back to object on the charter. High probability to have the charter approved. Recommend to start work now. (DH) Let's get a proposal started. I'm willing to work on fleshing out the SSH portion of TMSM IFFFF somebody with knowledge of SSH helps craft the text. Who is willing to be the security-side co-editor for an SSH document? (DH) Add one item to the charter: do an SSH proposal and pick a deadline. (DH) I am willing to try to get a draft written by the end of August if co-editors are available. (SH) Bert do want to make the proposal you said you wanted to make. (BW) Interim? Yes. I have jabbered with Sam and suggested that maybe I could accept an interim in September if the WG would commit to do more work (i.e. invest) on the writeups and evaluations to then choose between BEEP and SSH. I am happier if the WG sticks to the decision for SSH now. But I personally can live interim in September to make the decision. It is up to your AD though to decide if he would allow it or not (SH) Better do decision here and seems to have made the decision here. (JQ) Thinks also not needing an interim. (BW) Interim would ask a serious effort because of time limit. Happy with decision just made. (JQ) I wonder if we get to a different decision if we make the interim? (SH) Bert you are claiming to have a SSH draft? I think it is required (EL) Happy to host a gathering end of September if you want a checkpoint. (JQ) Not having a problem with interim meeting, good idea, maybe we should have one. We can make decision on the mailing list. |