[Anima] does BRSKI need three-way handshake before MASA commits?

Michael Richardson <mcr+ietf@sandelman.ca> Sun, 13 August 2017 00:26 UTC

Return-Path: <mcr+ietf@sandelman.ca>
X-Original-To: anima@ietfa.amsl.com
Delivered-To: anima@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C769C132406 for <anima@ietfa.amsl.com>; Sat, 12 Aug 2017 17:26:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-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 p1kbVKlE44MW for <anima@ietfa.amsl.com>; Sat, 12 Aug 2017 17:26:06 -0700 (PDT)
Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7DAF51323FD for <anima@ietf.org>; Sat, 12 Aug 2017 17:26:06 -0700 (PDT)
Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 91FFDE223 for <anima@ietf.org>; Sat, 12 Aug 2017 20:28:32 -0400 (EDT)
Received: from obiwan.sandelman.ca (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id C8465806BA for <anima@ietf.org>; Sat, 12 Aug 2017 20:26:05 -0400 (EDT)
From: Michael Richardson <mcr+ietf@sandelman.ca>
To: anima <anima@ietf.org>
X-Attribution: mcr
X-Mailer: MH-E 8.6; nmh 1.6+dev; GNU Emacs 24.5.1
X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m<nPbLgmtKK-5dC@#:k
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha256; protocol="application/pgp-signature"
Date: Sat, 12 Aug 2017 20:26:05 -0400
Message-ID: <1077.1502583965@obiwan.sandelman.ca>
Archived-At: <https://mailarchive.ietf.org/arch/msg/anima/8YIiNNxyQ_i0U6byFEtNzNO_HWM>
Subject: [Anima] does BRSKI need three-way handshake before MASA commits?
X-BeenThere: anima@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Autonomic Networking Integrated Model and Approach <anima.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/anima>, <mailto:anima-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/anima/>
List-Post: <mailto:anima@ietf.org>
List-Help: <mailto:anima-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/anima>, <mailto:anima-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 13 Aug 2017 00:26:09 -0000

Max, in the process of writing up the security considerations for freshness
of voucher requests, which is here, and attached below.

https://github.com/anima-wg/anima-bootstrap/commit/17724acb3a1810c09f113eb652cb66e274f9c640#diff-ea76ed1df307bcbcc86a5d34c5547032

It occurs to me that the problem outlined in the last paragraph, that the
MASA winds up with a voucher issued that was never successfully used, could
be solved if:
  a) the Voucher Status in section 3.5 was a signed artifact!
  b) that it contained some freshness present in the voucher.
  c) that a voucher that was not confirmed to have been used prior to
     expiring would be marked as such.

I think that this *could* be added as an extension in the future.
If we were going to say something today, it would be that successful
Status Telemetry SHOULD be relayed by the Registrar to the MASA,
(?even if the Registrar does not understand the contents?)

  6.1.  Freshness in Voucher Requests
+
+   A concern has been raised that the voucher request produced by the
+   Pledge should contain some content (a nonce) from the Registrar and/
+   or MASA in order for those actors to verify that the voucher request
+   is fresh.
+
+   There are a number of operational problems with getting a nonce from
+   the MASA to the pledge.  It is somewhat easier to collect a random
+   value from the Registrar, but as the Registrar is not yet at this
+   point validated, such a Registrar nonce has little value.  There are
+   privacy and logistical challenges to the process, so if such a thing
+   were to be considered, it would have to provide some clear value.
+   This section examines the impacts of not having a fresh voucher
+   request from the pledge.
+
+   Consider the case where a MITM is between the Pledge and the
+   legitimate Registrar.  This fake Registrar will obtain from the
+   Pledge a signed voucher request.  The pledge will have accepted the
+   fake Registrar as legitimate up to this point as the EST connection
+   will still be at the provisional state.
+
+   The fake Registrar (Ra) can communicate the signed voucher request to
+   a collaborator, perhaps located in another network, and communicate
+   with a some Registrar (Rb) to obtain a voucher signed by the MASA.
+   Assuming that the MASA accepts the voucher request (either because
+   this is the legitimate Registrar according to supply chain
+   information, or because the MASA is in audit-log only mode), then a
+   voucher linking the pledge to the Registrar Rb.
+
+   Such a voucher, when passed back to the Pledge, would link the pledge
+   to Registrar Rb, and would permit the Pledge to attempt to end the
+   provisional state.  The pledge will then attempt to validate the
+   pinned-domain-certificate linked to in the voucher.  That certificate
+   will point at Registrar Rb.  But the pledge will have a provisional
+   TLS/EST connection to the MITM Registrar Ra.  The pledge will fail
+   the process, close the provisional connection unsuccessfully, and
+   restart.
+
+   The conclusion is that lack of MASA provided freshness does cause a
+   pledge to join the wrong network.
+
+   There is an additional concern when the MASA is in audit-log only
+   mode.  When the unfortunate pledge above does connect to directly to
+   a legitimate Registrar, that Registrar will discover that a voucher
+   was previously issued.  If the legimate Registrar is actually Rb,
+   then all is well.  Otherwise, there is a fault as the Registrar has
+   to consider whether or not to accept a previously owned device.  This
+   may involve consulting a human.  If a large number of devices are
+   attacked in such a way, a human might just accept all the devices in
+   a batch mode, permitting an actually compromise device through.




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