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

Michael Richardson <mcr+ietf@sandelman.ca> Fri, 21 February 2020 20:00 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 76B8D12011D for <iot-onboarding@ietfa.amsl.com>; Fri, 21 Feb 2020 12:00:26 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 2.501
X-Spam-Level: **
X-Spam-Status: No, score=2.501 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, KHOP_HELO_FCRDNS=0.399, RCVD_IN_SBL_CSS=3.335, SPF_HELO_NONE=0.001, SPF_SOFTFAIL=0.665, URIBL_BLOCKED=0.001] autolearn=no 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 crJQ1XoPRCeZ for <iot-onboarding@ietfa.amsl.com>; Fri, 21 Feb 2020 12:00:24 -0800 (PST)
Received: from relay.sandelman.ca (minerva.sandelman.ca [IPv6:2a01:7e00::3d:b000]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C1E2212087A for <iot-onboarding@ietf.org>; Fri, 21 Feb 2020 12:00:24 -0800 (PST)
Received: from dooku.sandelman.ca (unknown [209.171.88.160]) by relay.sandelman.ca (Postfix) with ESMTPS id 202C21F458; Fri, 21 Feb 2020 20:00:23 +0000 (UTC)
Received: by dooku.sandelman.ca (Postfix, from userid 179) id 7A51C1A2BAC; Fri, 21 Feb 2020 21:00:21 +0100 (CET)
From: Michael Richardson <mcr+ietf@sandelman.ca>
To: "M. Ranganathan" <mranga@gmail.com>
cc: iot-onboarding@ietf.org
In-reply-to: <CAHiu4JMKt_FwDa1rd=TfkU3eTZzom3pxfPbEthJ4Kcjvp7=fcw@mail.gmail.com>
References: <CAHiu4JPRyNT=DmykHw6KaU+Q6X_o70Zc_+i0NosM-zU_iiRSZg@mail.gmail.com> <25486.1582103702@dooku> <CAHiu4JO2oBKeTypA+opUMOhCcWeuxJ-Vi8=qzji8dUMbQ6fP7A@mail.gmail.com> <12970.1582189476@dooku> <CAHiu4JMKt_FwDa1rd=TfkU3eTZzom3pxfPbEthJ4Kcjvp7=fcw@mail.gmail.com>
Comments: In-reply-to "M. Ranganathan" <mranga@gmail.com> message dated "Thu, 20 Feb 2020 16:45:58 -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: Fri, 21 Feb 2020 15:00:21 -0500
Message-ID: <19167.1582315221@dooku>
Archived-At: <https://mailarchive.ietf.org/arch/msg/iot-onboarding/cX0cqQMAAv0jU_mtgjcRejpWqC8>
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: Fri, 21 Feb 2020 20:00:36 -0000

M. Ranganathan <mranga@gmail.com> wrote:
    > <mcr+ietf@sandelman.ca> 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

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

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.

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