Subject: Re: [Netconf] ietf-tls/ssh groupings CA certs and peer certs

From: Kent Watsen <[email-masked]>
Date: Wed, 7 Jun 2017 16:55:50 +0000

Hi Balazs,

Please see inline below for [KENT]

K.

On 6/6/17, 10:55 AM, "Netconf on behalf of Balázs Kovács" <[email-masked]<mailto:[email-masked]> on behalf of [email-masked]<mailto:[email-masked]>> wrote:

Hi,

In the ‘server-auth’ section TLS/SSH client models and the ‘client-auth’ section of TLS/SSH server models there is usually a leaf pair defined for configuring both trusted-ca- or trusted-server/client certificates. For instance, in the TLS client grouping:

         leaf trusted-ca-certs {

           type leafref {

             path "/ks:keystore/ks:trusted-certificates/ks:name";

           }

           description

             "A reference to a list of certificate authority (CA)

              certificates used by the TLS client to authenticate

              TLS server certificates.";

         }

         leaf trusted-server-certs {

           type leafref {

             path "/ks:keystore/ks:trusted-certificates/ks:name";

           }

           description

             "A reference to a list of server certificates used by

              the TLS client to authenticate TLS server certificates.

              A server certificate is authenticated if it is an

              exact match to a configured trusted server certificate.";

         }

       }

I attempted to figure out how to enforce the rule “A server certificate is authenticated if it is an exact match to a configured trusted server certificate” and the rule lately added by Kent mentioned in a recent mail “A server certificate is authenticated if it has a valid chain of trust to a configured trusted CA certificate.”

[KENT] more like a clarification than a new rule, but okay.

Is the TLS/SSH client/server implementation required to check whether the X.509 certificate Basic Constraints field contains CA assertion or not before accepting a certificate set as CA or client/server certs?

https://tools.ietf.org/html/rfc5280#section-4.2.1.9

[KENT] I think that even a certificate with CA:true can be an end-entity certificate (based on KeyUsage field), so it's okay/normal for a CA:true cert to appear in the 'trusted-server-certs' list.  Likewise, a CA:false cert could appear in the 'trusted-ca-certs' list, though it won't match anything except itself (e.g., a self-signed cert).

I guess this could mean that a user of keystore can mix up different type of trusted certificates in keystore within one trusted-certificate list element, which later turns out to be invalid as leafrefs are set to them.

[KENT] I don't think they'd be "invalid" (see above)

Or is there any other hint how the above requirements shall be enforced? Should maybe the keystore model validate trusted certificate type (based on CA boolean assertion) beforehand?

[KENT] I don't think this is necessary.   What I would do in code, for a TLS-server, is:

  - given a new TLS-client connection, upon obtaining its client-certificate

     - iterate over 'trusted-server-certs' to see if there is an exact match

     - else, iterate over 'trusted-ca-certs' to see if the cert has a chain of trust to any of them

K.

---

From: Balázs Kovács <[email-masked]>
Date: Fri, 9 Jun 2017 09:30:23 +0000

Hi Kent,

Balazs> OK, I see checking CA assertion is useless.

To my experience, the most common TLS stack implementations work from a single trust store, so all of these certs above would get into the same store. Then one can set whether an exact match or a chain (with certain limit) is allowed. But I think this cannot be done per certificate, but only on the whole store.

An alternative option is to write custom verification callbacks and do what you propose, but that requires to be in control of the TLS APIs. All-in-all, my point is that there are a lot of 3PPs out there supporting TLS, which might not have this advanced verification capabilities. But I don’t know if you want to consider this aspect.

Br,
Balazs

From: Kent Watsen [mailto:[email-masked]]
Sent: Wednesday, June 07, 2017 6:56 PM
To: Balázs Kovács <[email-masked]>; [email-masked]
Subject: Re: [Netconf] ietf-tls/ssh groupings CA certs and peer certs

Hi Balazs,

K.

Hi,

         leaf trusted-ca-certs {

           type leafref {

           }

           description

         }

           type leafref {

           }

           description

         }

       }

K.

---

From: Kent Watsen <[email-masked]>
Date: Fri, 9 Jun 2017 14:45:40 +0000

Hi Balazs,

I haven't used many TLS libraries, but all the SSH libraries I've used let you register a callback that will include the SSH host-key from which you can do whatever validation check you want, returning a boolean based on the result back to the library.

Nonetheless, I don't have any strong feelings about keeping the ca-certs and the entity-certs separate.  To be honest, I thought that maybe I had inherited the idea from draft-ietf-netconf-rfc5539bis-04, but it looks like I just grabbed the "cert-maps" structure from that draft.   Tracing back through history, it looks like the idea was introduced in draft-ietf-netconf-server-model-01, but I don't see any on-list discussion on it until now.

So, if you're proposing to collapse these two constructs into a single list of certificates that may be a combination of entity and CA certs, I can't think of any Security reasons for why we shouldn't do it.  Is this indeed your proposal?

Kent

On 6/9/17, 5:30 AM, "Balázs Kovács" <[email-masked]<mailto:[email-masked]>> wrote:

Hi Kent,

Br,
Balazs

Hi Balazs,

K.

Hi,

         leaf trusted-ca-certs {

           type leafref {

           }

           description

         }

           type leafref {

           }

           description

         }

       }

K.

---

From: "Gary Wu (garywu)" <[email-masked]>
Date: Fri, 9 Jun 2017 15:39:43 +0000

The trusted-server-certs is meant to facilitate certificate pinning:
https://www.owasp.org/index.php/Certificate_and_Public_Key_Pinning

Most TLS/SSL libraries don't come with pinning built-in, it's up to the user to
implement it should they wish to support it, OWASP gives a few examples.
`trusted-server-certs` won't be used in standard certification path validation,
as such I don't agree with rolling it into `trusted-ca-certs`.

Thanks,
Gary

From: Netconf <[email-masked]> on behalf of Kent Watsen <[email-masked]>
Date: Friday, June 9, 2017 at 7:45 AM
To: Balázs Kovács <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [Netconf] ietf-tls/ssh groupings CA certs and peer certs

Hi Balazs,

Kent

Hi Kent,

Br,
Balazs

Hi Balazs,

K.

Hi,

         leaf trusted-ca-certs {

           type leafref {

           }

           description

         }

           type leafref {

           }

           description

         }

       }

K.

---

From: Balázs Kovács <[email-masked]>
Date: Mon, 12 Jun 2017 12:19:57 +0000

Hi,

Thank you Gary. Can some documentation reference be added to the corresponding server/client attributes that makes a clear connection to pinning? I see RFC7469 describes pinning as well in the context of HTTP. https://tools.ietf.org/html/rfc7469

As I see, filling the trusted-server-certs or trusted-client-certs can also occur from the local TLS stack after first verified handshake (“trust-in-first-use”).

However, if these leaf lists are not used in standard certification path validation, should they be part of some feature, such as ‘certificate-pinning’?

Br,
Balazs

From: Gary Wu (garywu) [mailto:[email-masked]]
Sent: Friday, June 09, 2017 5:40 PM
To: Kent Watsen <[email-masked]>; Balázs Kovács <[email-masked]>; [email-masked]
Subject: Re: [Netconf] ietf-tls/ssh groupings CA certs and peer certs

Thanks,
Gary

From: Netconf <[email-masked]<mailto:[email-masked]>> on behalf of Kent Watsen <[email-masked]<mailto:[email-masked]>>
Date: Friday, June 9, 2017 at 7:45 AM
To: Balázs Kovács <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [Netconf] ietf-tls/ssh groupings CA certs and peer certs

Hi Balazs,

Kent

Hi Kent,

Br,
Balazs

From: Kent Watsen [mailto:[email-masked]]
Sent: Wednesday, June 07, 2017 6:56 PM
To: Balázs Kovács <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Subject: Re: [Netconf] ietf-tls/ssh groupings CA certs and peer certs

Hi Balazs,

K.

Hi,

         leaf trusted-ca-certs {

           type leafref {

           }

           description

         }

           type leafref {

           }

           description

         }

       }

K.

---

From: Kent Watsen <[email-masked]>
Date: Mon, 12 Jun 2017 12:46:18 +0000

Alternatively, could servers that aren't able to implement distinct checks (pinned entity certs vs CA certs) merge the lists together on the backend when feeding them to their TLS library stack?  Or the server could have a deviation saying that it doesn't support the entity certs?

Kent

On 6/12/17, 8:19 AM, "Balázs Kovács" <[email-masked]<mailto:[email-masked]>> wrote:

Hi,

Br,
Balazs

Thanks,
Gary

Hi Balazs,

Kent

Hi Kent,

Br,
Balazs

Hi Balazs,

K.

Hi,

         leaf trusted-ca-certs {

           type leafref {

           }

           description

         }

           type leafref {

           }

           description

         }

       }

K.

---

From: Balázs Kovács <[email-masked]>
Date: Tue, 13 Jun 2017 07:40:04 +0000

Hi,

Merging them together sounds to be a violation of the interface. The deviation is better, but in this case I think there is a high probability of deviations. I assume it really depends on your strategy when deciding between features versus deviations.

Balazs

From: Kent Watsen [mailto:[email-masked]]
Sent: Monday, June 12, 2017 2:46 PM
To: Balázs Kovács <[email-masked]>; Gary Wu (garywu) <[email-masked]>; [email-masked]
Subject: Re: [Netconf] ietf-tls/ssh groupings CA certs and peer certs

Kent

Hi,

Br,
Balazs

From: Gary Wu (garywu) [mailto:[email-masked]]
Sent: Friday, June 09, 2017 5:40 PM
To: Kent Watsen <[email-masked]<mailto:[email-masked]>>; Balázs Kovács <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Subject: Re: [Netconf] ietf-tls/ssh groupings CA certs and peer certs

Thanks,
Gary

Hi Balazs,

Kent

Hi Kent,

Br,
Balazs

Hi Balazs,

K.

Hi,

         leaf trusted-ca-certs {

           type leafref {

           }

           description

         }

           type leafref {

           }

           description

         }

       }

K.

---

From: "Gary Wu (garywu)" <[email-masked]>
Date: Tue, 13 Jun 2017 13:44:56 +0000

I agree that the server should not merge them in the backend.  Given that not
every TLS implementation supports pinning/TOFU, perhaps an if-feature is
warranted.

Thanks,
Gary

From: Balázs Kovács <[email-masked]>
Date: Tuesday, June 13, 2017 at 12:40 AM
To: Kent Watsen <[email-masked]>, "Gary Wu (garywu)" <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: RE: [Netconf] ietf-tls/ssh groupings CA certs and peer certs

Hi,

Balazs

Kent

Hi,

Br,
Balazs

Thanks,
Gary

Hi Balazs,

Kent

Hi Kent,

Br,
Balazs

Hi Balazs,

K.

Hi,

         leaf trusted-ca-certs {

           type leafref {

           }

           description

         }

           type leafref {

           }

           description

         }

       }

K.