Subject: Re: [Netconf] ietf-tls-client@2017-03-13, some questions and comments

From: Balázs Kovács <[email-masked]>
Date: Thu, 1 Jun 2017 08:33:21 +0000

Hi,

> I've updated my local copy.  I also updated the tls-server module, as well as both the ssh-client and ssh-server modules.

I believe a tls-server should be ok without authenticating clients by ca or client certificate. Client is then authenticated in the application layer. Same for ssh-server (x509). Or do you have some requirement that the client identity must always be derived from a client certificate?

For ssh-client user have 3 choices (host-key, ca-cert, server-cert). Note that in case of host-keys, some SSH implementations (e.g., OpenSSH) allows for automatic recording of host keys (StrictHostKeyChecking no).

>           A server certificate is
>           authenticated if it has a valid chain of trust to
>           a configured trusted CA certificate. 

>I made the same change to both tls-client and ssh-client, the latter of which made it apparent that the statement was missing.
>Anyway, is this what you had in mind?

Partly, this is a good improvement.

> "The specified assertions need to be appropriate for the
>   certificate's use.  For example, an entity certificate for
>   a TLS server should have subject and subjectAltName values
>   satisfying RFC 6125 processing."?
>
> Note, generate-certificate-signing-request might be used to generate certificates for other use cases too (e.g., email).

Yes, this is what I had in mind. I think the text is a good proposal. Certainly it could be other type of certs.

Thank you,
Best Regards,
Balázs

-----Original Message-----
From: Kent Watsen [mailto:[email-masked]] 
Sent: Wednesday, May 31, 2017 8:08 PM
To: Balázs Kovács <[email-masked]>; Martin Bjorklund <[email-masked]>
Cc: [email-masked]
Subject: Re: [Netconf] ietf-tls-client@2017-03-13, some questions and comments

> Thank you Martin.

Indeed, but would the count() approach not work?  I was worried about future updates, but a quick look at 7950 s.11 shows:

   o  A "must" statement may be removed or its constraint relaxed.

And I guess going from must 'A or B' to must 'A or B or C' can be considered a relaxation of the constraint...

> Kent, will you add the proposal of Martin to the next version?

I've updated my local copy.  I also updated the tls-server module, as well as both the ssh-client and ssh-server modules. 

> Regarding issue #3, you're right, RFC6125 explains reference 
> identities and matching requirements; however, I think a reference 
> could be useful to identify certification attribute requirements for 
> server identities.

I think that PKIX has a gazillion rules that I'd rather not repeat.  Looking at the YANG, I noticed that 'trusted-ca-certs'
description was missing a statement, which I just added in my local copy:

           A server certificate is
           authenticated if it has a valid chain of trust to
           a configured trusted CA certificate. 

I made the same change to both tls-client and ssh-client, the latter of which made it apparent that the statement was missing.
Anyway, is this what you had in mind?

> Would it be appropriate
> to have such a reference at generate-certificate-signing-request
> of ietf-keystore?

generate-certificate-signing-request has two params: subject and attributes, both of which would presumably (depending on the CA) go into the final certificate that would be returned to the device, so that it can present it when establishing SSH or TLS, client or server, connections.  Here you would like a statement like:

  "The specified assertions need to be appropriate for the
   certificate's use.  For example, an entity certificate for
   a TLS server should have subject and subjectAltName values
   satisfying RFC 6125 processing."?

Note, generate-certificate-signing-request might be used to generate certificates for other use cases too (e.g., email).

> Br,
> Balázs

Kent

-----Original Message-----
From: Martin Bjorklund [mailto:[email-masked]] 
Sent: Wednesday, May 31, 2017 10:08 AM
To: Balázs Kovács <[email-masked]>
Cc: [email-masked]
Subject: Re: [Netconf] ietf-tls-client@2017-03-13, some questions and comments

Hi,

Balázs Kovács <[email-masked]> wrote:
> fyi
> 
> From: Kent Watsen [mailto:[email-masked]]
> Sent: Tuesday, May 30, 2017 8:01 PM
> To: Balázs Kovács <[email-masked]>
> Cc: Balázs Lengyel <[email-masked]>
> Subject: Re: ietf-tls-client@2017-03-13, some questions and comments
> 
> Per your questions:
> 
> 1. I am not trying to support null-authentication cipher suites.  In 
> practice, I expect *one* or *both* trusted-ca-certs and 
> trusted-server-certs to be configured, but not *neither*.  I'm not 
> sure how to represent that in YANG, maybe a must expression using the
> count() xpath function?  must 'count(./*) > 0'?

It can be done like this:

  container server-auth {
    leaf trusted-ca-certs { ... }
    leaf trusted-server-certs { ... }

    must 'trusted-ca-certs or trusted-server-certs';

  }

/martin

> 2. see #1
> 
> 3. I'm not sure if it needs to be mentioned in this document.  Already 
> RFC 6125 says this, yes?
> 
> PS: I wish that you would send these questions to the NETCONF list, as 
> it is generally good for the WG to see the Q&A too.
> 
> Thanks,
> Kent
> 
> 
> On 5/30/17, 5:19 AM, "Balázs Kovács"
> <[email-masked]<mailto:[email-masked]>> wrote:
> 
> Hi Kent,
> 
> I’m studying the module in subject and have a couple of questions.
> 
> 
>   1.  trusted-ca-certs and trusted-server-certs are both optional
>   leaves. Are you preparing for TLS servers which are not going to be
>   authenticated (i.e., with null authentication cipher suites)? Asking
>   because the ietf-tls-server has the certificate list with min-elements
>   1.
>   2.  In case I would like to avoid null authentication and require at
>   least one instance of trusted-ca-certs or trusted-server-certs I’m not
>   sure how to do it. I wonder if this distinction between CA and server
>   certificates is needed, and if yes, could these two be within a list
>   of choices so I can require at least one list element? What do you
>   suggest?
>   3.  Shouldn’t it be mentioned in the description of trusted-ca-certs
>   and trusted-server-certs that the subjectaltname or the subject fields
>   from the peer certificate received at TLS handshake must match the
>   server host address, and that this is especially important in the CA
>   case?
> 
> Br,
> Balázs
> 
_______________________________________________
Netconf mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/netconf

---

From: Kent Watsen <[email-masked]>
Date: Thu, 1 Jun 2017 18:48:01 +0000

>> I've updated my local copy.  I also updated the tls-server module, as well
>> as both the ssh-client and ssh-server modules.
>
> I believe a tls-server should be ok without authenticating clients by ca or
> client certificate. Client is then authenticated in the application layer.
> Same for ssh-server (x509). Or do you have some requirement that the client
> identity must always be derived from a client certificate?

Okay, I backed out the 'must' expression from the 'server' models.  FWIW,
both NC & RC require that the TLS-client sends a certificate, but that
these modules define groupings that may be used by other servers (e.g.,
an HTTPS server) that doesn't require a client certificate.

> For ssh-client user have 3 choices (host-key, ca-cert, server-cert).  

Yes, the 'must' expression spans all three.  

> Note
> that in case of host-keys, some SSH implementations (e.g., OpenSSH) allows
> for automatic recording of host keys (StrictHostKeyChecking no).

But do we want to expose that [insecure hack] in an IETF model?

>> Note, generate-certificate-signing-request might be used to generate
> certificates for other use cases too (e.g., email).
>
> Yes, this is what I had in mind. I think the text is a good proposal.
> Certainly it could be other type of certs.

Updated in my local copy.

K.

---

From: Balázs Kovács <[email-masked]>
Date: Fri, 2 Jun 2017 09:34:14 +0000

Hi,

> FWIW, both NC & RC require that the TLS-client sends a certificate,

Should then the 'must' expression be added to the NC & RC modules where the grouping is used?

> But do we want to expose that [insecure hack] in an IETF model?

I was a bit hesitating on this due to the initial configuration needs of an SSH client, but probably you're right, it becomes a requirement to configure at least one trusted host key. I'm ok with having the must on that too.

Br,
Balazs

-----Original Message-----
From: Kent Watsen [mailto:[email-masked]] 
Sent: Thursday, June 01, 2017 8:48 PM
To: Balázs Kovács <[email-masked]>; Martin Bjorklund <[email-masked]>
Cc: [email-masked]
Subject: Re: [Netconf] ietf-tls-client@2017-03-13, some questions and comments

>> I've updated my local copy.  I also updated the tls-server module, as 
>> well as both the ssh-client and ssh-server modules.
>
> I believe a tls-server should be ok without authenticating clients by 
> ca or client certificate. Client is then authenticated in the application layer.
> Same for ssh-server (x509). Or do you have some requirement that the 
> client identity must always be derived from a client certificate?

Okay, I backed out the 'must' expression from the 'server' models.  FWIW, both NC & RC require that the TLS-client sends a certificate, but that these modules define groupings that may be used by other servers (e.g., an HTTPS server) that doesn't require a client certificate.

> Note
> that in case of host-keys, some SSH implementations (e.g., OpenSSH) 
> allows for automatic recording of host keys (StrictHostKeyChecking no).

K.

---

From: Kent Watsen <[email-masked]>
Date: Mon, 5 Jun 2017 20:43:19 +0000

Hi Balazs,

Thanks,
Kent