Re: [Iot-onboarding] BRSKI : proximity registrar cert and MITM question

Michael Richardson <> Thu, 20 February 2020 09:10 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 7CFDE120868 for <>; Thu, 20 Feb 2020 01:10:06 -0800 (PST)
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 9yMvbIMtxtYW for <>; Thu, 20 Feb 2020 01:10:01 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 8BC4D1200D8 for <>; Thu, 20 Feb 2020 01:10:01 -0800 (PST)
Received: from (unknown []) by (Postfix) with ESMTPS id E9D0A1F481; Thu, 20 Feb 2020 09:09:58 +0000 (UTC)
Received: by (Postfix, from userid 179) id 4D5081A3B74; Thu, 20 Feb 2020 10:04:36 +0100 (CET)
From: Michael Richardson <>
To: "M. Ranganathan" <>
In-reply-to: <>
References: <> <25486.1582103702@dooku> <>
Comments: In-reply-to "M. Ranganathan" <> message dated "Wed, 19 Feb 2020 10:55:12 -0500."
X-Mailer: MH-E 8.6; nmh 1.7+dev; GNU Emacs 25.2.1
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha512; protocol="application/pgp-signature"
Date: Thu, 20 Feb 2020 10:04:36 +0100
Message-ID: <12970.1582189476@dooku>
Archived-At: <>
Subject: Re: [Iot-onboarding] BRSKI : proximity registrar cert and MITM question
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: Thu, 20 Feb 2020 09:10:08 -0000

M. Ranganathan <> wrote:
    >> M. Ranganathan <> wrote: > The BRSKI spec says that
    >> the pledge needs to send the proximity > registrar certificate when it
    >> requests a voucher. This establishes to > the registrar that it is the
    >> same pledge with whom it established a TLS > association. Can the
    >> server certificate be re-used if a different > pledge connects?
    >> The registrar uses the same certificate for all pledges.  The pledge
    >> puts that certificate into the voucher request, which is a kind of
    >> witness to the connection.
    >> > I don't understand the MITM scenario. An example would be helpful.
    >> Which specific scenario are you talking about?

    > Thanks for your response.

    > In section 5.2 it says : The registrar confirms that the assertion is
    > 'proximity' and that pinned 'proximity-registrar-cert' is the
    > Registrar's certificate. If this validation fails, then there is an
    > On-Path Attacker (MITM), and the connection MUST be closed after the
    > returning an HTTP 401 error code.

    > I was wondering about how that could occur and was trying to construct
    > a MITM attack which would be thwarted by having that certificate.

Let's assume use the BRSKI/ANIMA use case of ISP operators ("ISP-A")
So, assume multi-port router ("BFR1") at a peering data center (IX-A).

It is cabled to customers, to an IX switch, to the insides of the operator
network (maybe via long-haul fiber), and due to a human error (or enemy
action), it is also cabled into a cabinet of attackers who also happen to
have connectivity to the edge of the operator's network via another IX-B.

So, BFR1 sees Join Proxy announcements from:
1) ISP-B via the IX switch
2) CustomerC via the customer connection
3) ISP-A via it's long haul connection
4) nest-of-vipers "NV-D"

It runs BRSKI-EST with (4) first.
NV-D terminates the TLS connection to it's Rogue Registrar, presenting it's
Registrar Certificate to BFR1.   BFR1 pins this certificate into a voucher request.
NV-D then uses a Join Proxy belonging to ISP-A that it found at IX-B to form
a TLS connection to ISP-A's legitimate Registrar.  It uses an IDevID from a
a router (BFR2, same brand as BFR1) to form the TLS connection.
ISP-A's Registrar can't tell BFR1 from BFR2 at this point.

The Voucher-Request is then relayed from BFR1 via NV-D to ISP-A's Registrar.
(I can draw a picture if it will help)

ISP-A's registrar now has:
  1) TLS connection from NV-D's BFR2 with Client Certificate-2.
  2) Voucher-Request from BFR1 that pins NV-D's Registrar.

In thie case, ISP-A can see that the Voucher-Request pins a certificate which
is not it's certificate.  It also can see that the TLS connection is from
an entity other than that which signed the voucher-request, so it knows that
there was a (failing) attempt to MITM the connection.

    >> A lot of situations turn out to be difficult to construct in a
    >> convincing way because the device is authenticated by it's IDevID, and
    >> so a MITM would have to have an acceptable IDevID as well.

    > The device signs the request with it's private key and likewise accepts
    > a Voucher signed by the MASA which it has the ability to verify. How
    > can a MITM intervene?

Yes, it's because of those signatures that a MITM attempt is defeated.

]               Never tell me the odds!                 | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works        | network architect  [
]        |   ruby on rails    [

Michael Richardson <>ca>, Sandelman Software Works
 -= IPv6 IoT consulting =-