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

[Michael Richardson <[e-mail]>]

M. Ranganathan <[e-mail]> wrote:
    >> M. Ranganathan <[e-mail]> 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  [
]     [e-mail]  http://www.sandelman.ca/        |   ruby on rails    [


--
Michael Richardson <[e-mail]>ca>, Sandelman Software Works
 -= IPv6 IoT consulting =-