Subject: [Netconf] Stephen Farrell's Discuss on draft-ietf-netconf-call-home-11: (with DISCUSS and COMMENT)

From: "Stephen Farrell" <[email-masked]>
Date: Mon, 19 Oct 2015 01:36:15 -0700

Stephen Farrell has entered the following ballot position for
draft-ietf-netconf-call-home-11: Discuss

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/

----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

I have three points to discuss, I think these may be fairly
easy to resolve, or maybe not, but I'd like to chat about 'em.

(1) HTTP Auth: is it ok for a client to send it's e.g. basic
auth credential to any of the servers that the client can
validate? I.e., is an additional level of pinning needed for
this? That would be a new form of pinning and is not defined
for either TLS or SSH afaik. That could also be done in
various ways and I'm not sure if those might have
interoperability consequences. Or perhaps if not doing that,
this draft should say something about a need for stronger
credentials esp. for basic auth. Did the WG consider this?

(2) The secdir review [1] calls out issues related to TLS-PSK
and (I guess also) bare keys. I think it'd be good to be
speific as to wheher or how those are to be supported here. If
you are going to say those are supported, then I suspect some
additional text is needed. Kent's answer to that (which was
"see RFC7589" as I read it) doesn't quite do it here I think.
that says that certificates must be supported (which is fine) 
but doesn't say that TLS-PSK or bare keys can or cannot be 
supported.

   [1]
https://www.ietf.org/mail-archive/web/secdir/current/msg06087.html

(3) Consider zmap. When this is deployed, what'll be the
effect of surveys that fingerprint all of the devices on the
visible Internet who implement this protocol? Did the WG
consider that? I'm not sure of the impact, if any, but it
could be good if there's a way to help deployments end up less
vulnerable to fingerprinting (and the ensuing exposure to
unpatched vulns).

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

- OCSP: any issue there? is it mandatory to use in any case
for TLS?

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 19 Oct 2015 20:17:20 +0200

> https://www.ietf.org/mail-archive/web/secdir/current/msg06087.html

RFC 7589 only covers X.509 authentication and this was a deliberate
decision. Earlier I-Ds did include support for pre-shared keys but
this was taken out and the WG concensus was to write another NETCONF
over TLS with PSK document if the usage of pre-shared keys with
NETCONF gets more traction.

/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: Stephen Farrell <[email-masked]>
Date: Thu, 22 Oct 2015 00:27:22 +0100

Hiya,

(Aside: I don't think I've seen a response to my points 1 and
3 but my mail client's a bit flakey at the 'mo so please re-tx
if I missed something.)
 19/10/15 19:17, Juergen Schoenwaelder wrote:
> decision.

I'm fine with that decision. The discuss is only about whether or
not it's sufficiently well documented that you don't want folks
doing bare keys.

S.

> Earlier I-Ds did include support for pre-shared keys but

---

From: Kent Watsen <[email-masked]>
Date: Thu, 22 Oct 2015 00:34:13 +0000

Hi Stephen,

Thank you for your review.

>easy to resolve, or maybe not, but I'd like to chat about 'em.

Okay, great.

>credentials esp. for basic auth. Did the WG consider this?

Is this comment new to call home, or it is really a comment on the RESTCONF draft?  Specifically, please see this section:  https://tools.ietf.org/html/draft-ietf-netconf-restconf-08#section-2.5

Answering your questions:

> is it ok for a client to send it's e.g. Basic auth credential to any of the servers that the client can validate? 

Yes.

> I.e., is an additional level of pinning needed for this? 

Not that I’m aware of.

> Did the WG consider this?

No, but Kathleen made a good point to reference RFCs 7615 and 7616, which I will do.   Still, I think this comment is more on the RESTCONF draft than this one.  Yes?

>https://www.ietf.org/mail-archive/web/secdir/current/msg06087.html

Juergen mentioned that PSK was deliberately taken out of rfc7589 - and this draft has a normative reference to it.

Separately, you just now wrote to Juergen: "I'm fine with that decision. The discuss is only about whether or not it's sufficiently well documented that you don't want folks doing bare keys.”   

Would that be in this draft, or should it be in RRC7589?

>vulnerable to fingerprinting (and the ensuing exposure to

The WG did not discuss this.  

I know that you mention zmap by example, but reading on it I see that is sends a SYN message, and tests if a SYN-ACK is returned.  I never completes the TCP connection and, in fact sends a RST.

This concern seems to be true for any protocol, not specific to call-home.  Still, I could add to the Security Considerations section something like:

  NETCONF/RESTCONF clients having a open port for call home
  should be aware that network scanning tools are many times
  used to fingerprint hosts with the hope of finding unpatched
  vulnerabilities.  Effort should be made to limit exposure
  only to needing to access the NETCONF/RESTCONF client.

What do you think?

>- OCSP: any issue there? is it mandatory to use in any case

Again, this draft has a normative references to RFC 7589, which says:

   Both peers MUST use X.509 certificate path validation [RFC5280] to
   verify the integrity of the certificate presented by the peer.

And RFC5280 defines certificate path validation as including revocation checking.  So both CRL and OSCP are available, and would be up to the CA to specify CRL distribution points or authority info access in their certificates.

Thanks again,
Kent

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 22 Oct 2015 02:07:58 +0100

Hiya,

On 22/10/15 01:34, Kent Watsen wrote:
>> I have three points to discuss, I think these may be fairly easy to
>> resolve, or maybe not, but I'd like to chat about 'em.
> 
> Okay, great.
> 
> 
>> (1) HTTP Auth: is it ok for a client to send it's e.g. basic auth
>> credential to any of the servers that the client can validate?
>> I.e., is an additional level of pinning needed for this? That would
>> be a new form of pinning and is not defined for either TLS or SSH
>> afaik. That could also be done in various ways and I'm not sure if
>> those might have interoperability consequences. Or perhaps if not
>> doing that, this draft should say something about a need for
>> stronger credentials esp. for basic auth. Did the WG consider
>> this?
> 
> Is this comment new to call home, or it is really a comment on the
> RESTCONF draft?  Specifically, please see this section:
> https://tools.ietf.org/html/draft-ietf-netconf-restconf-08#section-2.5

I'd say it perhaps affects both. But could arguably be a broader
issue. See below.

>> is it ok for a client to send it's e.g. Basic auth credential to
>> any of the servers that the client can validate?
> 
> Yes.

Ick - at least, that's ickky if only the basic-auth realm is used
to select the password to send out (effectively in clear). Both
basic and digest I think talk about a user selecting the password
to input based on the realm, but here you're automating that based
on a packet received over the network.

What ensures a client here never sends the password to an incorrect
server? Say a client has two servers (A and B) that can call-home
to the client, and A cheats on B by using B's realm (which is not
considered a strong secret) in A's WWW-Authenticate?

Now if that is a real issue, I think we could argue that basic and
digest, unmodified, are just not safe here. I'm not sure what
modification could usefully be done if one is needed other than
maybe pinning the password to the server identity. Having just now
re-read RFC7617 I think we may need to tackle that issue somehow
as 7617 envisages the user not typing the password as the control
here.

(Or we could short-circuit this is the wg were willing to give
up on use of crappy http auth schemes like basic and only allow
better things - do you really really need this so badly as to
put these devices at risk?)

>> I.e., is an additional level of pinning needed for this?

We may want to chat about that more.

> No, but Kathleen made a good point to reference RFCs 7615 and 7616,
> which I will do.   Still, I think this comment is more on the
> RESTCONF draft than this one.  Yes?

Sorry no, I don't think so.

> 
> 
> 
> 
>> (2) The secdir review [1] calls out issues related to TLS-PSK and
>> (I guess also) bare keys. I think it'd be good to be speific as to
>> wheher or how those are to be supported here. If you are going to
>> say those are supported, then I suspect some additional text is
>> needed. Kent's answer to that (which was "see RFC7589" as I read
>> it) doesn't quite do it here I think. that says that certificates
>> must be supported (which is fine) but doesn't say that TLS-PSK or
>> bare keys can or cannot be supported.
>> 
>> [1] 
> Juergen mentioned that PSK was deliberately taken out of rfc7589 -
> and this draft has a normative reference to it.
> 
> Separately, you just now wrote to Juergen: "I'm fine with that
> decision. The discuss is only about whether or not it's sufficiently
> well documented that you don't want folks doing bare keys.”
> 

Show me where it says "don't do bare keys" and I'll answer you;-)
I think it perhaps needs to be here.

> 
> 
> 
> 
>> (3) Consider zmap. When this is deployed, what'll be the effect of
>> surveys that fingerprint all of the devices on the visible Internet
>> who implement this protocol? Did the WG consider that? I'm not sure
>> of the impact, if any, but it could be good if there's a way to
>> help deployments end up less vulnerable to fingerprinting (and the
>> ensuing exposure to unpatched vulns).
> 
> I know that you mention zmap by example, but reading on it I see that
> is sends a SYN message, and tests if a SYN-ACK is returned.  I never
> completes the TCP connection and, in fact sends a RST.

zmap has been used for all sorts of more complex handshakes.

> 
> This concern seems to be true for any protocol, not specific to
> call-home.  

I think a role-change like this makes it far more notable.

> Still, I could add to the Security Considerations section
> something like:
> 
> NETCONF/RESTCONF clients having a open port for call home should be
> aware that network scanning tools are many times used to fingerprint
> hosts with the hope of finding unpatched vulnerabilities.  Effort
> should be made to limit exposure only to needing to access the
> NETCONF/RESTCONF client.
> 
> What do you think?

But what efforts can one make and what is the impact of not making
those (for this protocol). The role-change here is a minor transport
change but doing that for publicly reachable hosts has a lot of
consequences.

> 
> 
> 
>> - OCSP: any issue there? is it mandatory to use in any case for
>> TLS?
> 
> And RFC5280 defines certificate path validation as including
> revocation checking.  

No. Revocation checking is optional in 5280. (Sorry;-)

> So both CRL and OSCP are available, and would
> be up to the CA to specify CRL distribution points or authority info
> access in their certificates.

If you want clients here to support status checking I think you need
to say that or reference something that says that.

Cheers,
S.

> Thanks again, Kent

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 22 Oct 2015 08:09:49 +0200

> not it's sufficiently well documented that you don't want folks

I think all we can do is to mention that RFC7589 supports X.509
authentication only in case that is not clear enough. I am not sure we
have strong technical reasons to rule out other mechanisms. SSH
supports a number of differnt user authentication mechanisms and we
did not restrict them here.

/js

---

From: Kent Watsen <[email-masked]>
Date: Fri, 23 Oct 2015 14:25:34 +0000

Hiya Stephen!

>I'd say it perhaps affects both. But could arguably be a broader

Sure, but this draft has a Normative reference to the RESTCONF draft for user auth.  Unless you’re saying that “call home” is introducing a new/stricter requirement, wouldn’t it be best to not repeat text from a normative reference?

>on a packet received over the network.

Not true.  Call home *only* impacts the TCP protocol layer.  The TLS and HTTP protocol layers are unchanged.  It is still the case that the client (NMS) sends an HTTP request (GET) and, if inadequate credentials are provides, the server (device) sends a WWW-Authenticate challenge, including the ‘realm’, as REQUIRED by RFC 7617.

>put these devices at risk?)

I wonder if maybe an aspect of this draft is being overlooked.  To recap, just as with a normal RESTCONF (HTTPS) connection, when a call home connection is being established, the RESTCONF server will present its server certificate and the TLS crypto session will be established *before* Basic/Digest auth.   That is, the RESTCONF client would NOT send its Basic/Digest auth to a server if it can’t first authenticate the server (via its server certificate).  In this draft, this is captured by C5-C7 (see below).  Please note that “proceeds as normal” in C7 below is when the Basic /Digest auth would occur:

  C5  As part of establishing an SSH or TLS connection, the NETCONF/
     RESTCONF client MUST validate the server's presented host key or
     certificate.  This validation MAY be accomplished by certificate
     path validation or by comparing the host key or certificate to a
     previously trusted or "pinned" value.

  C6  If certificate path validation is used, the NETCONF/RESTCONF
     client MUST ensure that the certificate has a valid chain of
     trust to a preconfigured trust anchor and that the certificate
     encodes an "identifier" [RFC6125] that the client had awareness
     of prior to the connection attempt.  How identifiers are encoded
     in certificates MAY be determined by a policy associated with the
     certificate's trust anchor.  For instance, a given trust anchor
     may be known to only sign IDevID certificates [Std-802.1AR-2009]
     having a unique identifier (e.g., serial number) in the X.509
     certificate's "CommonName" field.

  C7  After the server's host key or certificate is validated, the SSH
     or TLS protocol proceeds as normal to establish a SSH or TLS
     connection.

Please let me know if there was a misunderstanding here, or if I’m altogether missing something in your comment!

>We may want to chat about that more.

This is tied to the above comment.

>Sorry no, I don't think so.

Again, this is tied to the above comment.   I’m hoping that this is a simple misunderstanding wrt how the RESTCONF/HTTPS client auths the server’s TLS certificate *before* passing Basic/Digest auth credentials...

>I think it perhaps needs to be here.

I may need your help here, but my understanding is that bare keys (and PSK) are alternatives to PKI.  So if we have a statement like “you MUST do PKI”, does it not preclude the use of bare keys?

Both RFC 7589 and draft-ietf-netconf-restonf (which the call-home draft depends on) require X.509 certificates.   These statements can be found here:

  https://tools.ietf.org/html/rfc7589#section-5:

  "Both peers MUST use X.509 certificate path validation [RFC5280] to
   verify the integrity of the certificate presented by the peer.”

And here:

  https://tools.ietf.org/html/draft-ietf-netconf-restconf-08#section-2.2:

  "Consistent with the exclusive use of X.509v3 certificates for NETCONF
   over TLS [draft-ietf-netconf-rfc5539bis-10], use of certificates in
   RESTCONF is also limited to X.509v3 certificates."

So I’m not sure, does this sufficiently lock the use of TLS (for both NETCONF and RESTCONF) to X.509 certificates?  - or is more text needed?

>change but doing that for publicly reachable hosts has a lot of

I hope that this will be discussed on the TLS WG and openssh lists.  I imagine that it may culminate in better Security Considerations language in this draft.

>No. Revocation checking is optional in 5280. (Sorry;-)

OK, fair point.   To answer your question then, neither OCSP nor CRL revocation checking is required (but see next comment below).

>to say that or reference something that says that.

It’s certainly true that we would *want* NETCONF/RESTCONF clients to do revocation checking, but we cannot mandate it as some deployments are on private networks and hence unable to download a CRL or access an OCSP server.

That said, I believe that C5 could be enhanced with a SHOULD and a MUST as follows (see last two sentences).  Would this update address your concern?

OLD:

   C5  As part of establishing an SSH or TLS connection, the NETCONF/
      RESTCONF client MUST validate the server's presented host key or
      certificate.  This validation MAY be accomplished by certificate
      path validation or by comparing the host key or certificate to a
      previously trusted or "pinned" value.

NEW:

   C5 As part of establishing an SSH or TLS connection, the NETCONF/
      RESTCONF client MUST validate the server's presented host key or
      certificate. This validation MAY be accomplished by certificate
      path validation or by comparing the host key or certificate to a
      previously trusted or "pinned" value.  If a certificate contains
      revocation checking information, the NETCONF/RESTCONF client
      SHOULD check the revocation status of the certificate.  If it is

      determined that a certificate has been revoked, the client MUST
      immediately close the connection.

Thanks again, and I apologize if this thread is beginning to become long - hopefully we’ll start closing out some of these DISCUSS points soon though  :)

Kent

---

From: Kathleen Moriarty <[email-masked]>
Date: Fri, 23 Oct 2015 10:49:44 -0400

Sent from my iPhone

> On Oct 23, 2015, at 10:25 AM, Kent Watsen <[email-masked]> wrote:
> 
> 
> Hiya Stephen!
> 
> 
> 
> 
> 
> 
>>> 
>>> 
Right, but your adding a new capability in the callback that adds risk.

Thanks,
Kathleen

---

From: Stephen Farrell <[email-masked]>
Date: Fri, 23 Oct 2015 18:10:00 +0100

Hiya,

various bits down below...

On 23/10/15 15:25, Kent Watsen wrote:
>>>> for either TLS or SSH afaik. That could also be done in various
>>>> ways and I'm not sure if those might have interoperability
>>>> consequences. Or perhaps if not doing that, this draft should
>>>> say something about a need for stronger credentials esp. for
>>>> basic auth. Did the WG consider this?
>>> 
>>> Is this comment new to call home, or it is really a comment on
>>> the RESTCONF draft?  Specifically, please see this section: 
>> issue. See below.
> 
> Sure, but this draft has a Normative reference to the RESTCONF draft
> for user auth.  Unless you’re saying that “call home” is introducing
> a new/stricter requirement, wouldn’t it be best to not repeat text
> from a normative reference?
> 
> 
> 
> 
>>>> is it ok for a client to send it's e.g. Basic auth credential
>>>> to any of the servers that the client can validate?
>>> 
>>> Yes.
>> 
> Not true.  Call home *only* impacts the TCP protocol layer.  The TLS
> and HTTP protocol layers are unchanged.  It is still the case that
> the client (NMS) sends an HTTP request (GET) and, if inadequate
> credentials are provides, the server (device) sends a
> WWW-Authenticate challenge, including the ‘realm’, as REQUIRED by RFC
> 7617.
> 
> 
> 
>> What ensures a client here never sends the password to an
>> incorrect server? Say a client has two servers (A and B) that can
>> call-home to the client, and A cheats on B by using B's realm
>> (which is not considered a strong secret) in A's WWW-Authenticate?
>> 
>> re-read RFC7617 I think we may need to tackle that issue somehow as
>> 7617 envisages the user not typing the password as the control 
>> here.
>> 
>> (Or we could short-circuit this is the wg were willing to give up
>> on use of crappy http auth schemes like basic and only allow better
>> things - do you really really need this so badly as to put these
>> devices at risk?)
> 
> I wonder if maybe an aspect of this draft is being overlooked.  To
> recap, just as with a normal RESTCONF (HTTPS) connection, when a call
> home connection is being established, the RESTCONF server will
> present its server certificate and the TLS crypto session will be
> established *before* Basic/Digest auth.   That is, the RESTCONF
> client would NOT send its Basic/Digest auth to a server if it can’t
> first authenticate the server (via its server certificate).  In this
> draft, this is captured by C5-C7 (see below).  Please note that
> “proceeds as normal” in C7 below is when the Basic /Digest auth would
> occur:
> 
> certificate.  This validation MAY be accomplished by certificate path
> validation or by comparing the host key or certificate to a 
> client MUST ensure that the certificate has a valid chain of trust to
> a preconfigured trust anchor and that the certificate encodes an
> "identifier" [RFC6125] that the client had awareness of prior to the
> connection attempt.  How identifiers are encoded in certificates MAY
> be determined by a policy associated with the certificate's trust
> anchor.  For instance, a given trust anchor may be known to only sign
> IDevID certificates [Std-802.1AR-2009] having a unique identifier
> (e.g., serial number) in the X.509 certificate's "CommonName" field.
> 
> Please let me know if there was a misunderstanding here, or if I’m
> altogether missing something in your comment!

Go back to my example. The TLS client/TCP server ("C") is correctly
configured to accept connections from two different TLS servers/TCP
clients, A and B. (I don't know why that'd be sensible, but you do
not preclude it that I can see.)

Now C will correctly validate either A or B via their TLS server
certs and all's well, but for some reason C has different passwords
for basic when authenticating to A and B via basic auth or digest.
And A is not supposed to know the password to use for basic auth
to B. Let's say A uses realm=A-realm in the WWW-authenticate and
B uses B-realm.

What happens when A sends a WWW-authenticate with realm=B-realm?

The basic auth RFC assumes there's a warm body at the keyboard who
might or might not notice and not type (and hence expose) the
wrong password. (Whether that's a reasonable assumption is not our
business, but it is explicitly in the RFCs.)

This spec has no warm body therefore more is needed.

That might be trivial enough but is a change to how basic auth
works, and one that might or might not be supported in a library.
I'd not be surprised either way, but a library for basic auth
may well not be dependent on TLS at all, in which case this
attack by A on B could work.

One fix could be to say that implementations of this (or just
those that support more than one TLS server/TCP client) need to
be able to pin any vulnerable credential to the TLS server and
the HTTP auth realm. But that's likely a code change somewhere.

And the above argument I think also applies to SSH password auth
or any similarly vulnerable auth mechanism.

And now that I think of it, there's a possible additional wrinkle
here related to a question Benoit asked on the call. If the way
that the TLS client/TCP server is configured is to have specific
information about A and B (e.g. their certs/names/public keys)
then this new kind of pinning would be easy enough, as there's
no new configuration needed on the TLS client/TCP server, just a
bit of new code. But if the TLS client/TCP server is only configured
with CA information, the this new kind of pinning is a bit more work.
And since either is possible, we may need to talk about that too.

>>> No, but Kathleen made a good point to reference RFCs 7615 and
>>> 7616, which I will do.   Still, I think this comment is more on
>>> the RESTCONF draft than this one.  Yes?
>> 
> Again, this is tied to the above comment.   I’m hoping that this is a
> simple misunderstanding wrt how the RESTCONF/HTTPS client auths the
> server’s TLS certificate *before* passing Basic/Digest auth
> credentials...
> 
> 
> 
> 
>>> 
>>> 
>>> 
>>> 
>>> decision. The discuss is only about whether or not it's
>>> sufficiently well documented that you don't want folks doing bare
>>> keys.”
>>> 
>> Show me where it says "don't do bare keys" and I'll answer you;-) I
>> think it perhaps needs to be here.
> 
> 
> I may need your help here, but my understanding is that bare keys
> (and PSK) are alternatives to PKI.  So if we have a statement like
> “you MUST do PKI”, does it not preclude the use of bare keys?

No. A TLS stack may support all of 'em. If you don't want bare keys
used, you need to say explicitly that I think. If you do want to
allow bare keys, then that could also be done but may be more work
in this case.

> 
> Both RFC 7589 and draft-ietf-netconf-restonf (which the call-home
> draft depends on) require X.509 certificates.   These statements can
> be found here:
> 

Yeah, but that doesn't say the peer MUST present a cert.

(This is probably because bare keys is newish.)

>  "Consistent with the exclusive use of X.509v3 certificates for
> NETCONF over TLS [draft-ietf-netconf-rfc5539bis-10], use of
> certificates in RESTCONF is also limited to X.509v3 certificates."
> 

That one is ok, yes.

> So I’m not sure, does this sufficiently lock the use of TLS (for both
> NETCONF and RESTCONF) to X.509 certificates?  - or is more text
> needed?

I think a simple "X.509 server authentication MUST be used for all
TLS sessions" or similar would be enough.

>>>> (3) Consider zmap. When this is deployed, what'll be the effect
>>>> of surveys that fingerprint all of the devices on the visible
>>>> Internet who implement this protocol? Did the WG consider that?
>>>> I'm not sure of the impact, if any, but it could be good if
>>>> there's a way to help deployments end up less vulnerable to
>>>> fingerprinting (and the ensuing exposure to unpatched vulns).
>>> 
>>> I know that you mention zmap by example, but reading on it I see
>>> that is sends a SYN message, and tests if a SYN-ACK is returned.
>>> I never completes the TCP connection and, in fact sends a RST.
>> 
>>> NETCONF/RESTCONF clients having a open port for call home should
>>> be aware that network scanning tools are many times used to
>>> fingerprint hosts with the hope of finding unpatched
>>> vulnerabilities.  Effort should be made to limit exposure only to
>>> needing to access the NETCONF/RESTCONF client.
>>> 
>>> What do you think?
>> 
>> those (for this protocol). The role-change here is a minor
>> transport change but doing that for publicly reachable hosts has a
>> lot of consequences.
> 
> I hope that this will be discussed on the TLS WG and openssh lists.
> I imagine that it may culminate in better Security Considerations
> language in this draft.

Not quite. I think the tls/ssh folks can help us with the detail
of possible differences wrt DoS issues. In this case, I think we
need to ponder it a bit, and I certainly need to better understand
where these TLS client/TCP server things are likely to be deployed.
So I'd say we ought chat about it and see what we think first.

>>> Both peers MUST use X.509 certificate path validation [RFC5280]
>>> to verify the integrity of the certificate presented by the
>>> peer.
>>> 
>>> 
> OK, fair point.   To answer your question then, neither OCSP nor CRL
> revocation checking is required (but see next comment below).

Modulo my discuss point #3, that's fine.

> 
> 
> 
>>> So both CRL and OSCP are available, and would be up to the CA to
>>> specify CRL distribution points or authority info access in their
>>> certificates.
>> 
>> If you want clients here to support status checking I think you
>> need to say that or reference something that says that.
> 
> It’s certainly true that we would *want* NETCONF/RESTCONF clients to
> do revocation checking, but we cannot mandate it as some deployments
> are on private networks and hence unable to download a CRL or access
> an OCSP server.
> 
> That said, I believe that C5 could be enhanced with a SHOULD and a
> MUST as follows (see last two sentences).  Would this update address
> your concern?
> 
> OLD:
> 
> certificate.  This validation MAY be accomplished by certificate path
> validation or by comparing the host key or certificate to a 
> certificate. This validation MAY be accomplished by certificate path
> validation or by comparing the host key or certificate to a 
> revocation checking information, the NETCONF/RESTCONF client SHOULD
> check the revocation status of the certificate.  If it is
> 

Again, that seems good, modulo thinking about discuss point #3
which could touch on this. (E.g. if there're loads of deployments
that will likely be able to use public CAs and if one can
characterise those crisply in a way meaningful to a developer,
then one might want to mandate status checking for those cases.)

> 
> 
> Thanks again, and I apologize if this thread is beginning to become
> long - hopefully we’ll start closing out some of these DISCUSS points
> soon though  :)

No need to apologise, mail on stuff like this is just a bit
cumbersome. And in any case, it's me that's holding the DISCUSS
ballot so if anyone should be blamed, I'm it:-)

Cheers,
S.

---

From: Kent Watsen <[email-masked]>
Date: Fri, 23 Oct 2015 20:49:54 +0000

Hi Stephen,

>not preclude it that I can see.)

It’s incredibly sensible, more like “common".  A network management system (acting as a C) is many times managing large numbers of devices (acting as S's).

>to B. Let's say A uses realm=A-realm in the WWW-authenticate and

Also a very possible scenario today, as some NMS deployments may have different user auth per device.

>What happens when A sends a WWW-authenticate with realm=B-realm?

OK.  Now I understand your point.  Thank you for taking the time to explain it.

My first thought on this is to note that the RESTCONF draft is completely mute on the subject of realms - an omission for sure.  As an author on that draft, my inclination is to add a statement along the lines of “MUST use the realm FOO”, which would equate it to NETCONF, where there is no equivalent concept to a realm.

But the better answer is that C needs to follow C6 (above) especially with regards to ensuring that the server's certificate encodes an "identifier" [RFC6125] that the client had awareness of prior to the
connection attempt, driving it to use the right credentials for that identifier.   So, when A calls home, it presents a certificate that says “I’m A”, and then C uses the credentials it has pinned to being associated with A (and NOT use B’s credentials under any circumstance).

Perhaps the issue is that this is only implied (not explicitly stated) in C7’s "proceeds as normal” clause.  Would it help to add this text to the end of C7:

  When performing client-authentcation with the NETCONF/RESTCONF
  server, the NETCONF/RESTCONF client MUST ensure to only use
  credentials that had previously associated for the NETCONF/RESTCONF
  server’s presented host key or server certificate.

>the HTTP auth realm. But that's likely a code change somewhere.

Actually, I think that this is what we should do (see above), but I don’t think that it is much of a code change. At least our NMS (TLS client/TCP server) does this today. For instance, when using the j2ssh Java library, there is a callback to the user code to authenticate the presented SSH host key.  Our code uses that host key to then lookup pinned information including client-auth credentials.  Same could be done using an HTTP client library I imagine.

>And since either is possible, we may need to talk about that too.

I think that it is more the former than the latter.  (see my response above).  Do you agree?

>allow bare keys, then that could also be done but may be more work

Ah, I see now.  We need to patch S4 with something along the lines of “When sending a certificate, the NETCONF/RESTCONF server MUST only send an X.509v3 based certificate (PSK and bare key certificates MUST not be advertised).”.    Would this resolve your concern here?

>(This is probably because bare keys is newish.)

Right, and we can patch S4 above.  Perhaps also put errata on RFC 5280...

>TLS sessions" or similar would be enough.

This sounds like a statement that would be made for the client (C), but we were talking about the server in S4 above.  So put a similar patch on C5?

>So I'd say we ought chat about it and see what we think first.

OK.  Perhaps a chat in Yokohama would be more conducive.

>Modulo my discuss point #3, that's fine.

Thanks for the confirmation.

>then one might want to mandate status checking for those cases.)

OK, thanks for the confirmation on the text above.   Regarding your very last comment about mandating for some deployments, I’m not sure how to construct a MUST statement that has any more teeth than the SHOULD above.  For instance, saying something like:  If the certificate contains revocation pointers, then client MUST try to access and use the revocation information” still sounds like a SHOULD to me.  Maybe something better will come out of the discussion with the TLS WG and openssh list.

>ballot so if anyone should be blamed, I'm it:-)

That is definitely not the case here, I appreciate your help!

Thanks,
Kent