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

Michael Richardson <mcr+ietf@sandelman.ca> Thu, 20 February 2020 09:10 UTC

Return-Path: <mcr@sandelman.ca>
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 7CFDE120868 for <iot-onboarding@ietfa.amsl.com>; Thu, 20 Feb 2020 01:10:06 -0800 (PST)
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 9yMvbIMtxtYW for <iot-onboarding@ietfa.amsl.com>; Thu, 20 Feb 2020 01:10:01 -0800 (PST)
Received: from relay.sandelman.ca (relay.cooperix.net [176.58.120.209]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8BC4D1200D8 for <iot-onboarding@ietf.org>; Thu, 20 Feb 2020 01:10:01 -0800 (PST)
Received: from dooku.sandelman.ca (unknown [46.114.38.67]) by relay.sandelman.ca (Postfix) with ESMTPS id E9D0A1F481; Thu, 20 Feb 2020 09:09:58 +0000 (UTC)
Received: by dooku.sandelman.ca (Postfix, from userid 179) id 4D5081A3B74; Thu, 20 Feb 2020 10:04:36 +0100 (CET)
From: Michael Richardson <mcr+ietf@sandelman.ca>
To: "M. Ranganathan" <mranga@gmail.com>
cc: iot-onboarding@ietf.org
In-reply-to: <CAHiu4JO2oBKeTypA+opUMOhCcWeuxJ-Vi8=qzji8dUMbQ6fP7A@mail.gmail.com>
References: <CAHiu4JPRyNT=DmykHw6KaU+Q6X_o70Zc_+i0NosM-zU_iiRSZg@mail.gmail.com> <25486.1582103702@dooku> <CAHiu4JO2oBKeTypA+opUMOhCcWeuxJ-Vi8=qzji8dUMbQ6fP7A@mail.gmail.com>
Comments: In-reply-to "M. Ranganathan" <mranga@gmail.com> 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: <https://mailarchive.ietf.org/arch/msg/iot-onboarding/1Bwr5T6G2aQAW9QF2YW9rpNR_V0>
Subject: Re: [Iot-onboarding] BRSKI : proximity registrar cert and MITM question
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: Thu, 20 Feb 2020 09:10:08 -0000

M. Ranganathan <mranga@gmail.com> wrote:
    >> M. Ranganathan <mranga@gmail.com> 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.

okay.
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  [
]     mcr@sandelman.ca  http://www.sandelman.ca/        |   ruby on rails    [


--
Michael Richardson <mcr+IETF@sandelman.ca>ca>, Sandelman Software Works
 -= IPv6 IoT consulting =-