Subject: [Netconf] Ben Campbell's No Objection on draft-ietf-netconf-call-home-11: (with COMMENT)

From: "Ben Campbell" <[email-masked]>
Date: Tue, 20 Oct 2015 15:05:28 -0700

Ben Campbell has entered the following ballot position for
draft-ietf-netconf-call-home-11: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-netconf-call-home/

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

One comment and a question:

- 3.1, S1:

If the client MAY be configured to listen on a non-standard port, doesn’t
that imply that the server MUST be _capable_ of being configured to
connect to a non-standard port?

- 4:

I'm curious why people felt it necessary to reverse the usual TLS or SSH
client and server roles. Did the working group consider having the
NETCONF/RESTCONF server act as the TLS or SSH client? If so, can the
reasons be summarized in a sentence or two?

---

From: Mahesh Jethanandani <[email-masked]>
Date: Tue, 20 Oct 2015 23:05:48 -0700

Ben,

> On Oct 20, 2015, at 3:05 PM, Ben Campbell <[email-masked]> wrote:
> 

That is correct. The client and the server would have to decide up-front that they would negotiate the connection on a non-standard port and for the server to be configured with that capability.

> reasons be summarized in a sentence or two?

I believe that the NETCONF/RESTCONF server is acting as the TLS or SSH client during call home. What (I think) Kent is trying to imply is that  "NETCONF/RESTCONF server” is the entity that runs on the network element, and is a server for NETCONF/RESTCONF and TLS/SSH during normal operations, but which acts as a TLS or SSH client during call home.

Would it help to say as such?

Mahesh Jethanandani
[email-masked]

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 21 Oct 2015 09:51:18 +0200

> I believe that the NETCONF/RESTCONF server is acting as the TLS or SSH client during call home. What (I think) Kent is trying to imply is that  "NETCONF/RESTCONF server” is the entity that runs on…

I am confused by the answer. My understanding is that the
NETCONF/RESTCONF server hosts the SSH/TLS server no matter whether
there is call-home or not.

   Both NETCONF Call Home and RESTCONF Call Home preserve all but one of
   the client/server roles in their respective protocol stacks, as
   compared to client-initiated NETCONF and RESTCONF connections.  The
   one and only role reversal that occurs is at the TCP layer; that is,
   which peer is the TCP-client and which is the TCP-server.

Early versions of this document (actually when this was still part of
the NC over TLS document) had the SSH/TLS roles swapped but this was
troublesome since authentication mechanisms are not necessarily
symmetric (and this is in particular true for SSH). We had a longer
discussion about this at one of the IETF meeting a couple of IETF's
ago where Bert also managed to bring in security experts and this lead
to the current design.

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103         <http://www.jacobs-university.de/>

---

From: Barry Leiba <[email-masked]>
Date: Wed, 21 Oct 2015 05:28:33 -0400

> I believe that the NETCONF/RESTCONF server is acting as the TLS or SSH
> client during call home. What (I think) Kent is trying to imply is that
> "NETCONF/RESTCONF server” is the entity that runs on the network element,
> and is a server for NETCONF/RESTCONF and TLS/SSH during normal operations,
> but which acts as a TLS or SSH client during call home.

No, not so.  Normally, if protocol XX will run over, say, TLS, the XX
client opens a TCP connection to the XX server, and then the XX client
starts a TLS handshake.

Here, where XX == NETCONF or RESCONF, the XX *server* opens a TCP
connection to the XX *client*... and then the XX client responds by
starting a TLS handshake.

What Ben is asking is this: Why doesn't the NETCONF/RESCONF server
start the TLS handshake (and similarly for SSH), maintaining the
normal TLS or SSH setup?  What was the reason for reversing it?

Barry

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 21 Oct 2015 11:40:08 +0200

> normal TLS or SSH setup?  What was the reason for reversing it?

Authentication is not symmetrics, in particular with SSH where the
server is authenticated by its hostkey and the client by credentials
(of different forms) associated with the notion of a user.

/js

---

From: "Ben Campbell" <[email-masked]>
Date: Wed, 21 Oct 2015 09:34:19 -0500

> (of different forms) associated with the notion of a user.

Paraphrasing back to check my understanding:

At least for the case of TLS, The NETCONF/RESTCONF server is 
authenticated by TLS, and the client by credentials that are exchanged 
after the TLS handshake completes?

I'm going to go out on a limb and guess that that approach is an 
artifact of the normal (non-call-home) connection direction, and a lack 
of client certs? I am no NETCONF expert, so forgive me if I am missing 
some other obvious reason.

That motivation appears reasonable on the surface. I will leave it to 
people who have a deeper understanding of TLS subtleties than I to say 
if that causes any problems.

However, this does make me wonder about the statement in the Security 
Considerations that the DoS potential is "no different than for any 
other secured service". The reversed connection approach seems to allow 
an attacker to cause the NETCONF client to perform computationally 
intense operations with just a TCP connection--that is, with marginally 
less effort on the part of the attacker. I'm not sure that's enough 
difference to make a real-world difference, but it might be worth a 
mention.

Thanks!

Ben.

---

From: Kent Watsen <[email-masked]>
Date: Wed, 21 Oct 2015 20:18:34 +0000

Hi Ben,

Thank you for your review.

> connect to a non-standard port?

This is correct and what draft-ietf-netconf-server-model-08 allows.   Were you thinking that there needs to be a change in this draft?

> NETCONF/RESTCONF server act as the TLS or SSH client? If so, can the

As Juergen noted, this allows that all existing authentication to continue working.  Also, since SSH is not a symmetric protocol, it’s actually important for the client to be the SSH-client so it can open/close SSH channels (e.g., to start the “netconf” subsystem).

>after the TLS handshake completes?

NETCONF over TLS requires the client to use client-certificate based authentication and this happens at the time the TLS session is being established, for the NETCONF protocol layer starts.

RESTCONF over TLS (the only choice) uses HTTP Authentication [RFC7235].  When “Basic” or “Digest” are used, the client-authentication is after the TLS session has been established.  The “ClientCertificate” is used, then the client-authentication occurs at the time the TLS session is being established (same as NETCONF over TLS). 

>some other obvious reason.

Yes, that is fair to say, in the sense that it is very easy to implement it this way.   For instance, JUNOS uses `inetd` to listen on port 22 and, when a TCP connection is established, it forks/execs `sshd -i` passing the open socket descriptor.   So to implement call home, all that had to be done was to write a daemon that initiates the TCP connection to the client and then, as soon as the TCP connection is established, it forks/execs `sshd -i` exactly like how `inetd` does it.   Everything else stays the same.  In fact, the SSH has no awareness of how it was invoked.

>difference to make a real-world difference, but it might be worth a 

A normal SSH or TLS server accepts the TCP connection and immediately starts a computationally expensive operation (proving it has the private key associated with its SSH host key or TLS server certificate).   

Here we have similar setup, except the client has the port open and it starts the SSH/TLS client protocol.  It could be argued that the client protocol is less expensive than the server protocol, so perhaps it’s not so bad.

Still, for the draft, what do you recommend changing?   The current text follows:

    An attacker could launch a denial of service (DoS) attack on the
    NETCONF/RESTCONF client by having it perform computationally
    expensive operations, before deducing that the attacker doesn't
    posses a valid key.  This is no different than any secured service
    and all common precautions apply (e.g., blacklisting the source
    address after a set number of unsuccessful login attempts).

Thanks again,
Kent

---

From: "Ben Campbell" <[email-masked]>
Date: Wed, 21 Oct 2015 16:24:26 -0500

On 21 Oct 2015, at 15:18, Kent Watsen wrote:

> This is correct and what draft-ietf-netconf-server-model-08 allows.   
> Were you thinking that there needs to be a change in this draft?

I think it's worth a mention. People will probably figure it out for 
themselves, but it's usually better to be explicit.

> As Juergen noted, this allows that all existing authentication to 
> continue working.  Also, since SSH is not a symmetric protocol, it’s 
> actually important for the client to be the SSH-client so it can 
> open/close SSH channels (e.g., to start the “netconf” subsystem).
>
>
>
>
>
> NETCONF over TLS requires the client to use client-certificate based 
> authentication and this happens at the time the TLS session is being 
> established, for the NETCONF protocol layer starts.
>
> RESTCONF over TLS (the only choice) uses HTTP Authentication 
> [RFC7235].  When “Basic” or “Digest” are used, the 
> client-authentication is after the TLS session has been established.  
> The “ClientCertificate” is used, then the client-authentication 
> occurs at the time the TLS session is being established (same as 
> NETCONF over TLS).
>
>
>
>
> Yes, that is fair to say, in the sense that it is very easy to 
> implement it this way.   For instance, JUNOS uses `inetd` to listen on 
> port 22 and, when a TCP connection is established, it forks/execs 
> `sshd -i` passing the open socket descriptor.   So to implement call 
> home, all that had to be done was to write a daemon that initiates the 
> TCP connection to the client and then, as soon as the TCP connection 
> is established, it forks/execs `sshd -i` exactly like how `inetd` does 
> it.   Everything else stays the same.  In fact, the SSH has no 
> awareness of how it was invoked.
>
>
>
> A normal SSH or TLS server accepts the TCP connection and immediately 
> starts a computationally expensive operation (proving it has the 
> private key associated with its SSH host key or TLS server 
> certificate).
>
> Here we have similar setup, except the client has the port open and it 
> starts the SSH/TLS client protocol.  It could be argued that the 
> client protocol is less expensive than the server protocol, so perhaps 
> it’s not so bad.

My point is not that this increases the work of the NETCONF client, it's 
that it decreased the work of an attacker. In the normal case, the 
client has to open a TCP connection and send a ClientHello before the 
server is forced to send the ServerHello. In this case, an attacker 
could force the client to send the ClientHello by merely opening a TCP 
connection.

Admittedly, the ClientHello is not a particularly heavyweight operation, 
so the required work for the NETCONF client, and the reduced work for 
the attacker may be too trivial to matter.

>  address after a set number of unsuccessful login attempts).

I think it wouldn't hurt to change the "This is no different" text to 
say "This is slightly different...because...". But if you believe the 
trigger of the ClientHello is too trivial to matter, then the text is 
okay as is.

(In any case, this is a non-blocking comment, so don't get too wrapped 
around it.)

Thanks!

Ben.

---

From: Martin Stiemerling <[email-masked]>
Date: Wed, 21 Oct 2015 23:29:26 +0200

Am 21.10.15 um 23:24 schrieb Ben Campbell:
>> private key associated with its SSH host key or TLS server certificate).
>>

The question is how 'expensive' the state keeping for a ClientHello is 
on the client side, especially since an attacker could send a large 
amount of TCP connection requests, and handle them so that the TCP 
connection is set up, and potentially drive the client out of memory.

Just my two cents

   Martin

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 22 Oct 2015 00:00:45 +0200

> after the TLS handshake completes?

No.
 
> some other obvious reason.

RFC 7589 uses X.509 on both sides.

> if that causes any problems.

We got told back at that IETF meeting that even with TLS, server and
client certs may not be fully interchangeable. Anyway, with SSH
credentials and the authentication mechanisms clearly are not
symmetric.

/js

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 22 Oct 2015 00:23:59 +0100

Hiya,

> connection is set up, and potentially drive the client out of memory.

I think that'd be worth checking, and maybe documenting yeah.

I doubt there's a really bad thing here, e.g. I can't see there's a
way to get the client to accept a session ticket from a bogus source
but it would still be worth a look. But TLS clients could well be
allocating space to hold a running hash for the finished and so be
somewhat worse than a raw socket. I don't know if server-side
mitigations for that kind of thing would be common in clients.

Probably best to just wait 'till all the IESG comments are in and
then we can work on a crisp (set of) question(s) to ask the TLS WG,
and the openssh list, including Martin's. I'm happy to help with
crafting that if folks want.

S.

---

From: Benoit Claise <[email-masked]>
Date: Thu, 22 Oct 2015 13:10:55 +0200

> As Juergen noted, this allows that all existing authentication to continue working.  Also, since SSH is not a symmetric protocol, it’s actually important for the client to be the SSH-client so it c…
Ben, do you feel we need to mention it in the draft?

Regards, Benoit

---

From: "Ben Campbell" <[email-masked]>
Date: Thu, 22 Oct 2015 15:18:18 -0500

On 22 Oct 2015, at 6:10, Benoit Claise wrote:

>> continue working.  Also, since SSH is not a symmetric protocol, 
>> it’s actually important for the client to be the SSH-client so it 
>> can open/close SSH channels (e.g., to start the “netconf” 
>> subsystem).

I am happy with Stephen's suggestion (in a different branch of the 
thread) to send some questions to the TLS wg and openssh list. I will be 
fine with whatever results from that.

Thanks!

Ben.

---

From: Kent Watsen <[email-masked]>
Date: Fri, 23 Oct 2015 00:26:19 +0000

>>> As Juergen noted, this allows all existing authentication to 

Actually, the draft already has this:

  Having consistency in both the secure transport layer (SSH, TLS) and
  application layer (NETCONF, RESTCONF) roles conveniently enables
  deployed network management infrastructure to support call home also.
  For instance, existing certificate chains and user authentication
  mechanisms are unaffected by call home.

Good enough?

>fine with whatever results from that.

Yes, we’ll see how that plays out.

Thanks,
Kent

---

From: "Ben Campbell" <[email-masked]>
Date: Thu, 22 Oct 2015 19:35:43 -0500

> mechanisms are unaffected by call home.

Yes for the "why" part.

---

From: Kent Watsen <[email-masked]>
Date: Fri, 23 Oct 2015 00:53:23 +0000

Hi Ben,

The draft currently has this:

  S1  The NETCONF/RESTCONF server initiates a TCP connection request to
     the NETCONF/RESTCONF client.  The server SHOULD connect to one of
     the IANA-assigned ports defined in section Section 5, but MAY be
     configured to use a non-standard port.  Using the IANA-assigned
     ports, the server connects to port PORT-X for NETCONF over SSH,
     port PORT-Y for NETCONF over TLS, and port PORT-Z for RESTCONF
     over TLS.

I should’ve pointed out the above on my earlier response. We could replace the second sentence with:

    The server MUST default to connecting to one of the IANA-assigned
    ports defined in Section 5 and be configurable to use a non-standard
    port.

What do you think?

BTW: I just caught a typo: “section Section 5”  (fixed in my local copy).

Thanks,
Kent

---

From: "Ben Campbell" <[email-masked]>
Date: Fri, 23 Oct 2015 17:29:07 -0500

>  ports defined in Section 5 and be configurable to use a non-standard

That works for me, thanks!

---

From: t.petch <[email-masked]>
Date: Sat, 24 Oct 2015 12:41:18 +0100

----- Original Message -----
From: "Ben Campbell" <[email-masked]>
To: "Kent Watsen" <[email-masked]>
Cc: <[email-masked]>; <[email-masked]>;
"Netconf" <[email-masked]>; "Barry Leiba" <[email-masked]>;
"The IESG" <[email-masked]>
Sent: Friday, October 23, 2015 11:29 PM
> >  ports defined in Section 5 and be configurable to use a
non-standard

I think that that introduces a fresh ambiguity.  Does it mean MUST
default and MUST be configurable?  Probably not.  I suggest

The server MUST default to connecting to one of the IANA-assigned
ports defined in Section 5 and MAY be configurable to use a non-standard
port

which I think more in line with the consensus of theWorking Group.

Except that you are now moving S1 out-of-line with C1 which I think will
cause confusion.  The original wording allows them to be the same.
Introducing the idea of 'MUST default' may force them to be different.

Tom Petch

> _______________________________________________
> Netconf mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netconf
>

---

From: Kent Watsen <[email-masked]>
Date: Mon, 26 Oct 2015 16:31:34 +0000

Hi Ben,

This same text is being discussed in the Martin Stiemerling thread, where symmetric updates to both C1 and S1 using RFC 5426 language are proposed. Ben, I’m hoping that language works for you too..?  Regardless, let’s use that other thread to finish off this discussion.

BTW, thanks Tom Petch for helping on these!

Thanks,
Kent

---

From: "Ben Campbell" <[email-masked]>
Date: Mon, 26 Oct 2015 12:13:34 -0500

On 26 Oct 2015, at 11:31, Kent Watsen wrote:

> This same text is being discussed in the Martin Stiemerling thread, 
> where symmetric updates to both C1 and S1 using RFC 5426 language are 
> proposed. Ben, I’m hoping that language works for you too..?  
> Regardless, let’s use that other thread to finish off this 
> discussion.

That is fine with me. I'm sure I will be okay with whatever people come 
up with after discussion.

Thanks!

Ben.