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

From: "M. Ranganathan" <[email-masked]>
Date: Tue, 18 Feb 2020 17:23:51 -0500

Hello,

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?

I don't understand the MITM scenario. An example would be helpful.

Thanks

Ranga

-- 
M. Ranganathan

---

From: Michael Richardson <[email-masked]>
Date: Wed, 19 Feb 2020 10:15:02 +0100

M. Ranganathan <[email-masked]> wrote:
    > 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?
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.

-- 
]               Never tell me the odds!                 | ipv6 mesh networks [ 
]   Michael Richardson, Sandelman Software Works        | network architect  [ 
]     [email-masked]  http://www.sandelman.ca/        |   ruby on rails    [

---

From: "M. Ranganathan" <[email-masked]>
Date: Wed, 19 Feb 2020 10:55:12 -0500

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

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

-- 
M. Ranganathan

---

From: Michael Richardson <[email-masked]>
Date: Thu, 20 Feb 2020 10:04:36 +0100

M. Ranganathan <[email-masked]> wrote:
    >> M. Ranganathan <[email-masked]> 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

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

--
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-

---

From: "M. Ranganathan" <[email-masked]>
Date: Thu, 20 Feb 2020 16:45:58 -0500

On Thu, Feb 20, 2020 at 4:10 AM Michael Richardson
<[email-masked]> wrote:
>\

Thanks. I think I get the attack scenario although a picture would
help if you have the time (back of envelope sketch will do).

One thing I am unclear of - lets assume the MITM succeeds and attacker
gets an unauthorized voucher. What damage can it do with this voucher?
It still does not have the private key of the legitimate device that
issued the voucher request so it cannot enroll anyway. Is that a
correct statement? (I agree it is a good design to prevent the MITM in
the first place). I suppose that could screw up the MASA if it is
maintaining a log. Anything else?

-- 
M. Ranganathan

---

From: Michael Richardson <[email-masked]>
Date: Fri, 21 Feb 2020 15:00:21 -0500

M. Ranganathan <[email-masked]> wrote:
    >> 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.

    > Thanks. I think I get the attack scenario although a picture would help
    > if you have the time (back of envelope sketch will do).

Here is a diagram:
     https://github.com/anima-wg/anima-bootstrap/blob/master/diagrams/mitm-attack1.svg

    > gets an unauthorized voucher. What damage can it do with this voucher?

If you get the voucher, then you own the device.
So this voucher would let the attacker force the router/device involved to onboard to
the attacker's network.  It would have to get the device to factory reset, and
be directly connected to the device.