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

From: Balázs Kovács <[email-masked]>
Date: Wed, 31 May 2017 07:40:16 +0000

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'?

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

---

From: Martin Bjorklund <[email-masked]>
Date: Wed, 31 May 2017 10:08:03 +0200 (CEST)

Hi,

Balázs Kovács <[email-masked]> wrote:
> 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

> 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,
> 
>   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
>

---

From: Balázs Kovács <[email-masked]>
Date: Wed, 31 May 2017 11:45:06 +0000

Hi,

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

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. Would it be appropriate to have such a reference at generate-certificate-signing-request of ietf-keystore?

Br,
Balázs

-----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,

  container server-auth {

  }

/martin

---

From: Kent Watsen <[email-masked]>
Date: Wed, 31 May 2017 18:07:42 +0000

> 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).

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,

  container server-auth {

  }

/martin

>   server host address, and that this is especially important in the CA
_______________________________________________
Netconf mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/netconf