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

Dan Harkins <dharkins@lounge.org> Sun, 05 April 2020 08:37 UTC

Return-Path: <dharkins@lounge.org>
X-Original-To: iot-onboarding@ietfa.amsl.com
Delivered-To: iot-onboarding@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 90AAC3A0433 for <iot-onboarding@ietfa.amsl.com>; Sun, 5 Apr 2020 01:37:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4smnJVFt5dRc for <iot-onboarding@ietfa.amsl.com>; Sun, 5 Apr 2020 01:37:42 -0700 (PDT)
Received: from www.goatley.com (www.goatley.com [198.137.202.94]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A4C033A040C for <iot-onboarding@ietf.org>; Sun, 5 Apr 2020 01:37:42 -0700 (PDT)
Received: from trixy.bergandi.net (cpe-76-93-158-174.san.res.rr.com [76.93.158.174]) by wwwlocal.goatley.com (PMDF V6.8 #2433) with ESMTP id <0Q8B0070Q3YU2X@wwwlocal.goatley.com> for iot-onboarding@ietf.org; Sun, 05 Apr 2020 03:37:42 -0500 (CDT)
Received: from Dans-MacBook-Pro.local ([69.12.173.8]) by trixy.bergandi.net (PMDF V6.7-x01 #2433) with ESMTPSA id <0Q8B00MEB3Y7B2@trixy.bergandi.net> for iot-onboarding@ietf.org; Sun, 05 Apr 2020 01:37:20 -0700 (PDT)
Received: from 69-12-173-8.static.dsltransport.net ([69.12.173.8] EXTERNAL) (EHLO Dans-MacBook-Pro.local) with TLS/SSL by trixy.bergandi.net ([10.0.42.18]) (PreciseMail V3.3); Sun, 05 Apr 2020 01:37:20 -0700
Date: Sun, 05 Apr 2020 01:37:39 -0700
From: Dan Harkins <dharkins@lounge.org>
In-reply-to: <CAHiu4JNjcaRymun442-vRKXhd-L2W6Jgudkyi5DG8dZjTwzrkw@mail.gmail.com>
To: "M. Ranganathan" <mranga@gmail.com>
Cc: iot-onboarding@ietf.org
Message-id: <ca4a00cf-4cf0-24ab-25e0-b07c41e9c492@lounge.org>
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 (recv=trixy.bergandi.net, send-ip=69.12.173.8)
X-PMAS-External-Auth: 69-12-173-8.static.dsltransport.net [69.12.173.8] (EHLO Dans-MacBook-Pro.local)
References: <CAHiu4JMF22GQBV+yNtN5ySUvJtcc8_+xj9biJLE9Dcc1YvUp9w@mail.gmail.com> <0e3c75ca-52b1-6117-cd5c-0bfe5ba9c381@lounge.org> <CAHiu4JNjcaRymun442-vRKXhd-L2W6Jgudkyi5DG8dZjTwzrkw@mail.gmail.com>
X-PMAS-Software: PreciseMail V3.3 [200402] (trixy.bergandi.net)
X-PMAS-Allowed: system rule (rule allow header:X-PMAS-External noexists)
Archived-At: <https://mailarchive.ietf.org/arch/msg/iot-onboarding/BZ4L4ZA48ro3TMVy-Xx2p2O2Mvs>
Subject: Re: [Iot-onboarding] BRSKI-EST and TLS Unique ID check
X-BeenThere: iot-onboarding@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Discussion of IoT onboarding mechanisms <iot-onboarding.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/iot-onboarding>, <mailto:iot-onboarding-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/iot-onboarding/>
List-Post: <mailto:iot-onboarding@ietf.org>
List-Help: <mailto:iot-onboarding-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/iot-onboarding>, <mailto:iot-onboarding-request@ietf.org?subject=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 <dharkins@lounge.org> 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) 
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.

> 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
>> Iot-onboarding@ietf.org
>> https://www.ietf.org/mailman/listinfo/iot-onboarding
>
>