Minutes of the IETF 87 NETCONF WG Session July 31, 2013 ======================================================== Chairs Bert Wijnen and Mehmet Ersue AD: Benoit Claise Minute takers: Lada Lhotka and Robert Varga Jabber scribe: Peter Saint-Andre Agenda bashing: No comments The agenda is available at: http://www.ietf.org/proceedings/87/agenda/agenda-87-netconf WG Status: Mehmet gave the WG status and listed agenda items. The session agenda is available at: (http://www.ietf.org/proceedings/87/slides/slides-87-netconf-6.ppt) NETCONF-over-TLS (Jürgen Schönwälder): http://www.ietf.org/proceedings/87/slides/slides-87-netconf-7.pdf http://tools.ietf.org/html/draft-ietf-netconf-rfc5539bis **** slide 2 Andy: RFC publication process, do new submodules obsolete main module? Solution: republish everything at once. This is the only way to stay in sync. Bert Wijnen: it is an update, as it changes only a piece Bert: Don't you update the RFC by writing a new submodule? Andy: It would be confusing if some submodules were old and others new. Mehmet Ersue: it is still okay, what is your proposal? Andy: republish the entire RFC, obsolete the entire thing Andy: If anything is changed, then the previous module revision should be obsoleted, and the new should replace it. Bert: this needs to be discussed with NETMOD, I can live with replacing the entire RFC Bert: It is a question of structuring DMs. If an RFC updates something, we have to decide what should be done. Andy: that way submodules are just a style choice Juergen: I don't have to agree to that Bert: it is a generic theme, you guys need to decide Bert: You can obsolete or update the previous RFC. Andy: No, after an update you end up with two RFCs containing modules with different revision dates. Juergen: in IPv6 this has been done, it is perfectly fine to replace Show of hands: 5 vs. 9 against replacing **** slide 4 When to swap roles: Kent Watsen: for SSH it's important to swap roles immediately after TCP. It seems to be logical to do the same thing, as the client/server certificate protection. Kent: Same thing I am proposing for SSH. For TLS it's a weaker arg, but there is a notion of client certificate, which is expected to be protected. Steve Hanna: there are also other reasons, like EKU bits, to swap the roles early. Juergen: we assumed we would use a different server in the reverse direction Jürgen: But both sides send cert. Steve Hanna: Client and server certs are different things. If you don't do that your client will present a server cert. Different key bits are used for client and server certs. Steve: standard libraries have expectations Bert: Steve, do you opt for opt. #3? Steve: I opt for the third option Ian Smith: Why is second option not valid from TLS perspective? Steve: The question is whether you want to have one certificate, or a two at each side. Steve: It is better to keep the roles of client and server. Andy: don't preclude dual-role entities. You need to make sure we don't wait for who is going to assign the session. Andy: It should be clear who is who, we cannot rely on sending session id, we don't want a deadlock. Peter Saint-Andre: In XMPP servers use same certificates for both. You should reach out to TLS WG. Steve: Concurred. We need an evaluation of the security concerns. Steve: You have to do security considerations and decide whether it's OK to have the NETCONF client present server cert. Juergen: The port tells you who is doing what (client/server). Kent: Exactly. Juergen: We should probably do the last one, if there's no benefits in two. Kent: The only problem with #3 is that TLS specs have a specific wording WRT who initiates the connection. Peter: Let me know questions. Andy: #2 is fine with different port numbers. Andy/Kent: you need another port anyway, for both options. Bert: Andy's concern is handled either way. Security for prefer the third option. Show of hands: third option 14 in favor, 1 against Ian: #3 is complicated to implement and troubleshoot. Bert: #3 looks like the way to go, has to be verified in ML. We should also go to TLS WG for verifying. second option: 0 in favor, 4/5 against, 1 abstention Mehmet: should we find a security reviewer or talk to security ADs? Benoit Claise: ask the ADs, if the experts were here, we're fine Benoit: Is this mechanism NETCONF-specific or generic? Kent: it is generic, but it is applicable mostly for network management. Kent: Same as in SSH, it is really applicable to network management. We should have applicability note restricting its use to management. Bert: Let's have a solution for NETCONF. Benoit: Fine with that, but we should express it. Kent: we need port assignment for both drafts, we can share port, if we create a handshake Robert Varga: That brings us closer to a generic solution. Ian: Extra socket is an operational nightmare. Jürgen: It was not proposed to have an extra connection. ???: Negotiation is a bad idea, can you do something already in protocol for the role reversal? SSH has subsystem. David Lamparter: I'd suggest to use some identifier for the type of transport. Bert: The authors will specify #3, we do WGLC and ask TLS group for review. YANG API from NETCONF perspective (Andy Bierman): http://www.ietf.org/proceedings/87/slides/slides-87-netconf-0.pdf http://tools.ietf.org/html/draft-bierman-netconf-yang-api-01 (expired) **** slide 4 Bert: notification is a generic problem, but we should not wait as we did with call home. Bert: Is it the same as call-home? Andy: it seems to me that HTTP server pushing data is a generic application. Don't want to see separate solutions. Bert: We should consider the need for notifications. Peter Lothberg: Can't you just do a kick-ass solution? Kent: I can work with you on HTTP solution? Dean Bogdanovic: It is interesting for Juniper as an alternative API. Mehmet: Take it offline, to the lists, come back with a draft. And once you are back we can discuss adoption. Andy: I will try to write a new draft within one month. Reverse SSH (Kent Watsen): http://www.ietf.org/proceedings/87/slides/slides-87-netconf-5.pptx http://tools.ietf.org/html/draft-ietf-netconf-reverse-ssh **** slide 6 Bert: is this the second call-home solution? Steve: it is actually the third one Bert: Is it always the NMS that forks? K: No this happens on client. Steve: Regardless of the initiator, the secure connection is done in the same way. From the security perspective, you always do the same thing. Joe Clarke: Is this not a disclosure of information? Our NMS just accepts the key. Joe Clark: Is it info disclosure? Will the client send his credentials? Kent: This is the same as with plain SSH. The server key should not be trusted blindly. Joe: Shouldn't this be a stronger language, like a MUST? Kent: it could, but technically it's a SHOULD **** slide 10 Juergen: Can you set up periodic connections? Juergen: do you need to have a YANG module for the configurable parameters? Kent: Yes, it is covered in the YANG module. Russ(?): Does homenet have solution for zeroconf? You are establishing secure state. Russ Mundy: Bunch of challenges. We need to make sure whether zeroconf, homenet etc. can be used. Kent: zeroconf is needed, but not essential. Kent: Reverse SSH is not limited to the first connection. Russ: Hardest part is the initial establishing of security state. Steve: Agree. I'd submit it as two separate problems in different drafts. Steve: yes, the initial secure state is the hard part. The two probles are separable and should be separated. I would be glad to work on the zeroconf part of the problem. Kent: the focus of the draft is just TCP problem Joe Salowey: identification is critical, I don't know what that is, but it needs to be thought about.Joe Salomey: Always validate host keys! Other pitfall: identification problem - different form. Consider using static key files etc. It should be doable. Steve: You didn't show the NMS part. Normally NMS knows to which device it is connecting. Kent: this is typically done using libraries, which give you a chance to validate the host key. Best option is to use X.509 certificate with name field, authenticated by the CA. Joe S: You cannot expect a standard SSH client to work out of the box, but you can use existing SSH libraries. David (?): using just the hostkeys is not sufficient, because if there's just 500 devices, it's just so many keys you try out. David Lamparter: You have to have host key plus some other type of id, like an IP address. Kent: do you want the key authentication be a MUST? Joe: yes, because if passwords are involved, there's a risk Joe S: Make sure you never send password to an untrusted party. Russ: this where the details are important. Security assumption of NMS being a human being is not valid. Russ: Security designs and sec. models of SSH - there is a person at one side. In NM, it is a process rather than a human. Kent: We also have customers that insist that a human completes authentication. We can do both. Bert: do we take out the zeroconf stuff? Steve: yes, volunteer to help with it. Bert: zeroconf investigation needed, two drafts, what about security? Steve: For manual config, you have to specify parameters that must be configured. Joe S: Agreed Steve: I will provide applicability statement that it is limited to NM apps. Bert: do we need configuration which needs to be set to allow call home? Steve: yes, it should be in reverse SSH Joe: Concur. Show of hands for take out zeroconf and do a new draft with Steve: many in favor, 0 against Time Capability in NETCONF (Tal Mizrahi): http://www.ietf.org/proceedings/87/slides/slides-87-netconf-1.pdf http://tools.ietf.org/html/draft-mm-netconf-time-capability-00.txt **** slide 17 Dean: You don't know when the commit will completed. Show-hands: no hands in favor or opposed. The draft will be taken again to the maillist for discussion. Efficient XML Interchange Capability for NETCONF (Robert Varga): http://www.ietf.org/proceedings/87/slides/slides-87-netconf-2.pptx http://tools.ietf.org/html/draft-varga-netconf-exi-capability-00.txt ****** slide 11 PSA: You should just present use cases. Show hands: 12 attendees in favor and nobody against. The draft will be further updated and discussed. NETCONF rpc-error extension (Gang Yan): http://www.ietf.org/proceedings/87/slides/slides-87-netconf-3.pptx http://tools.ietf.org/html/draft-ysc-netconf-rpc-error-extension-00 ****** slide 6 Lada Lhotka: Positional parameters are fragile, I'd suggest to use named parameters. Where do the parties get the format string? Yan: In documentation. Presenter: This is an integration issue, this will need help at deployment. Lada: how do you know what is MTU or what is IF index? You should attach names. Bert: Does this need to go into the protocol? We've done this in SNMP using GUI. Presenter: it is not mandatory, we try to make it more seemless. Bert: These are implementation details, should probably go to GUI. Andy: you can do this error-info, it's anyxml. Show hands: 2 in favor and 6 against. The draft will be further discussed on the maillist.