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

"M. Ranganathan" <> Sat, 04 April 2020 21:02 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id EC6403A0C00 for <>; Sat, 4 Apr 2020 14:02:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Sq65faSyXvsh for <>; Sat, 4 Apr 2020 14:02:47 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::12e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 14D893A0A2F for <>; Sat, 4 Apr 2020 14:02:46 -0700 (PDT)
Received: by with SMTP id t11so11013740ils.1 for <>; Sat, 04 Apr 2020 14:02:46 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=+kwGCrdR6WKh4RGZeEvUWnzj3hP9Fj1UFoTpfrXqjzk=; b=T97smzLqMkEexnbZ7CJN3xgt6I4b1kASiMN7w0Z+heLHtknP7s6W47UGSLN+gUMjWQ RZwS6j36NzALAuu01UqATLIXXgbNxLFCj1hSoIqcOeFVlbazbSs0fpXP0+VPClu8ph7U ZWoDg9FKuPRFJke1CVa4XfpmeaZBLvHlPhL/DpYc62CsF56h9VW/ORax+oeYvAZJmler n22spxRxebfBS1AOr879DfRnIfvM5G65Sxdp/GLUqv5R69zuuYr6X0hMtDi8wX1yTDB3 71EQNdjJWYWBQLpTZnDQH8A2xtSLT/IW6cZpsXVo5nhlmKSgx078plYDy8UuE4XeoRnq d5yQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=+kwGCrdR6WKh4RGZeEvUWnzj3hP9Fj1UFoTpfrXqjzk=; b=A3W8oEo0nNePRzmKnVTZd/+/KFQ8UIqGTnGvjxmrkfQyA/jOF/R6Gn06vWumx/D9LA vmBqtYR55FntyBcVRT0u7t35XTh/6bSwI0MEQBlFZIr6gO5X0Zy3qkD2/tzRjaUptpXE /3BBYq4PUXnSLZinXH111ejtiiMqPW0LSRMosK+VI1x5vdA8+iXPKOgGHqhBHj77DH8W VXFyJF1mVfvuuQwOjRmFMTio9smrgOYhHhcTfev6GUgyeAYyK383Y0ugM75BvMg8u+DX aduc3laUD9OFdVaTIG/ilr7oDjVIcqdXY0BCTBl2WGOJctD/zw48sWWpaztXbCJugOxy y9Ow==
X-Gm-Message-State: AGi0PuZuByDe9MdpqP+0MtWAesaVxYZqUTkdsiKvbg22I3M22IeboHGm S2dEAfwzYMEMPfDKHOSiU920lu2NyPXWckpW7DM=
X-Google-Smtp-Source: APiQypK1JUVAjiHqXB2YIONszWTHjS0UTTrayBDcoc2RnJqKEd3OXGxEQ+rzidhNuRlvHJN7WoAg8PXKfSRs7oGi6fw=
X-Received: by 2002:a05:6e02:90:: with SMTP id l16mr15418508ilm.294.1586034165885; Sat, 04 Apr 2020 14:02:45 -0700 (PDT)
MIME-Version: 1.0
References: <> <>
In-Reply-To: <>
From: "M. Ranganathan" <>
Date: Sat, 4 Apr 2020 17:02:11 -0400
Message-ID: <>
To: Dan Harkins <>
Content-Type: text/plain; charset="UTF-8"
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: Sat, 04 Apr 2020 21:02:50 -0000

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.

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



>    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

M. Ranganathan