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

Dan Harkins <> Sun, 05 April 2020 08:37 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 90AAC3A0433 for <>; Sun, 5 Apr 2020 01:37:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 4smnJVFt5dRc for <>; Sun, 5 Apr 2020 01:37:42 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id A4C033A040C for <>; Sun, 5 Apr 2020 01:37:42 -0700 (PDT)
Received: from ( []) by (PMDF V6.8 #2433) with ESMTP id <> for; Sun, 05 Apr 2020 03:37:42 -0500 (CDT)
Received: from Dans-MacBook-Pro.local ([]) by (PMDF V6.7-x01 #2433) with ESMTPSA id <> for; Sun, 05 Apr 2020 01:37:20 -0700 (PDT)
Received: from ([] EXTERNAL) (EHLO Dans-MacBook-Pro.local) with TLS/SSL by ([]) (PreciseMail V3.3); Sun, 05 Apr 2020 01:37:20 -0700
Date: Sun, 05 Apr 2020 01:37:39 -0700
From: Dan Harkins <>
In-reply-to: <>
To: "M. Ranganathan" <>
Message-id: <>
MIME-version: 1.0
Content-type: text/plain; charset=utf-8; format=flowed
Content-language: en-US
Content-transfer-encoding: 8BIT
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:68.0) Gecko/20100101 Thunderbird/68.5.0
X-PMAS-SPF: SPF check skipped for authenticated session (, send-ip=
X-PMAS-External-Auth: [] (EHLO Dans-MacBook-Pro.local)
References: <> <> <>
X-PMAS-Software: PreciseMail V3.3 [200402] (
X-PMAS-Allowed: system rule (rule allow header:X-PMAS-External noexists)
Archived-At: <>
Subject: Re: [Iot-onboarding] BRSKI-EST and TLS Unique ID check
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Discussion of IoT onboarding mechanisms <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sun, 05 Apr 2020 08:37:45 -0000

   Hi Ranga,

On 4/4/20 2:02 PM, M. Ranganathan wrote:
> On Sat, Apr 4, 2020 at 1:51 PM Dan Harkins <> wrote:
>>     Hi Ranga,
>>     This check does proof-of-possession of the private key. I think it's
>> very important.
> 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.

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

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

   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.

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

   I've actually heard this is a requirement from our federal (DoD) 
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.



> Thanks,
> Ranga
>>     regards,
>>     Dan.
>> On 4/3/20 9:45 AM, M. Ranganathan wrote:
>>> 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
>> --
>> Iot-onboarding mailing list