Subject: [Iot-onboarding] BRSKI-EST and TLS Unique ID check

From: "M. Ranganathan" <[email-masked]>
Date: Fri, 3 Apr 2020 12:45:15 -0400

Hello,

The EST spec says that if the password on a simpleenroll CSR exists
then that password should match the tls unique identifier of the HTTPS
connection (section 3.5).

Given that BRSKI establishes a persistent HTTPS connection, is this
check even required?

I looked at draft-richardson-anima-registrar-considerations but I
could not find anything about this so I would appreciate some
clarification.

Thanks,

Ranga

-- 
M. Ranganathan

---

From: "M. Ranganathan" <[email-masked]>
Date: Fri, 3 Apr 2020 16:37:38 -0400

Sorry to reply to my own post ....

> connection (section 3.5).

Also TLS unique ID is deprecated in TLS 1.3 I believe. So does the
channel binding check won't work anyway (?)

-- 
M. Ranganathan

---

From: Dan Harkins <[email-masked]>
Date: Sat, 04 Apr 2020 10:50:57 -0700

Hi Ranga,

   This check does proof-of-possession of the private key. I think it's
very important.

   regards,

   Dan.

---

From: "M. Ranganathan" <[email-masked]>
Date: Sat, 4 Apr 2020 17:02:11 -0400

>    This check does proof-of-possession of the private key. I think it's

Hi Dan,

This check just ensures that the CSR was generated by same entity that
established the connection with the EST server (i.e. it is not
proxying a request for another party). It is checking if the CSR
password is the TLS unique ID.

In BRSKI EST, the way I understand it, the pledge creates a persistent
HTTPS connection with the registrar / EST server.
In doing so it presents its certificate and is challenged for proof or
possession of the corresponding private key (TLS handshake).

It now uses that private key to sign the CSR. The server in this case
has the corresponding public key and can verify the
CSR. Proof of possession of private key has already been established
above. If the client (pledge) tears down the Connection
prior to doing this, the EST server would remove its public keys and
therefore verification would fail. Hence I thought this check
is redundant for BRSKI / EST.

The one thing this does not accomplish is guarding against replay
attacks (a previously signed CSR could
be replayed) which the TLS unique ID guards against. Is this really an
issue in BRSKI EST? It could
only be replayed by the same party that generated the CSR in the first
place due to the persistent connection requirement.

Second, what can be done if TLS Unique ID is not supported (e.g. TLS 1.3)?

Thanks,

Ranga

> Iot-onboarding mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/iot-onboarding

-- 
M. Ranganathan

---

From: Dan Harkins <[email-masked]>
Date: Sun, 05 Apr 2020 01:37:39 -0700

Hi Ranga,

> password is the TLS unique ID.

   Right, so I can't take a CSR generated by Kevin Mitnick and provide it
in an EST session that I'm taking part in and result in a certificate
issued for a public key whose private analog is held by Kevin Mitnick
(even if the identity is me).

> is redundant for BRSKI / EST.

   So the public key that gets certified through BRSKI is the same as the
public key in the manufacturing certificate? I thought they were, or could
be, different.

> place due to the persistent connection requirement.

   I've actually heard this is a requirement from our federal (DoD) 
customers.
I would guess that if you're using a certificate for a CNSA (nee Suite B)
connection you'd probably want your CA/RA to do as much due diligence as
possible before issuing the certificate.

   But people are using certs for things they were never intended for (e.g.
using a LetsEncrypt certificate in an EAP server) so the amount of care
that people seem to have these days is damn near nil.

> Second, what can be done if TLS Unique ID is not supported (e.g. TLS 1.3)?

   Add it, or something similar that can be documented in an RFC to 
update 7030.

   regards,

   Dan.

---

From: Michael Richardson <[email-masked]>
Date: Sun, 05 Apr 2020 14:45:57 -0400

> Given that BRSKI establishes a persistent HTTPS connection, is this

We didn't put it in because tls_unique changed, and the voucher already acts
a sort of channel binding.

--
]               Never tell me the odds!                 | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works        |    IoT architect   [
]     [email-masked]  http://www.sandelman.ca/        |   ruby on rails    [

---

From: Michael Richardson <[email-masked]>
Date: Sun, 05 Apr 2020 16:51:24 -0400

> This check does proof-of-possession of the private key. I think it's

I agree: it matters a lot, but I think more on EST renewal.
We didn't change EST, so really 7030 text should prevail.

It's not always the case that the TLS connection will be originated with
a client certificate identical to the keypair that will be enrolled.

    > Second, what can be done if TLS Unique ID is not supported (e.g. TLS 1.3)?

There is a new channel binding interface, and really there should probably be
an update to use that.

--
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-