Re: [Anima-bootstrap] brsky concern1: separating audit-log retrieval from voucher generation

Michael Richardson <mcr@sandelman.ca> Sat, 12 November 2016 02:56 UTC

Return-Path: <mcr@sandelman.ca>
X-Original-To: anima-bootstrap@ietfa.amsl.com
Delivered-To: anima-bootstrap@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6FEDB129536 for <anima-bootstrap@ietfa.amsl.com>; Fri, 11 Nov 2016 18:56:15 -0800 (PST)
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, 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 LpezPb_EcyFA for <anima-bootstrap@ietfa.amsl.com>; Fri, 11 Nov 2016 18:56:14 -0800 (PST)
Received: from relay.sandelman.ca (relay.cooperix.net [176.58.120.209]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 32CC61294C0 for <anima-bootstrap@ietf.org>; Fri, 11 Nov 2016 18:56:14 -0800 (PST)
Received: from dooku.sandelman.ca (unknown [182.172.168.109]) by relay.sandelman.ca (Postfix) with ESMTPS id B79AD1F906; Sat, 12 Nov 2016 02:56:12 +0000 (UTC)
Received: by dooku.sandelman.ca (Postfix, from userid 179) id 2255B321D; Fri, 11 Nov 2016 21:56:10 -0500 (EST)
To: anima-bootstrap@ietf.org
In-reply-to: <20161101201523.GB9776@faui40p.informatik.uni-erlangen.de>
References: <20161101201523.GB9776@faui40p.informatik.uni-erlangen.de>
Comments: In-reply-to Toerless Eckert <tte+ietf@cs.fau.de> message dated "Tue, 01 Nov 2016 21:15:23 +0100."
X-Mailer: MH-E 8.6; nmh 1.6; GNU Emacs 24.5.1
From: Michael Richardson <mcr@sandelman.ca>
X-Attribution: mcr
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha1; protocol="application/pgp-signature"
Date: Sat, 12 Nov 2016 11:56:10 +0900
Message-ID: <9461.1478919370@dooku.sandelman.ca>
Archived-At: <https://mailarchive.ietf.org/arch/msg/anima-bootstrap/-YSBi6Dz4ij4OyC6zEuIs8hPMUQ>
Cc: Toerless Eckert <tte+ietf@cs.fau.de>
Subject: Re: [Anima-bootstrap] brsky concern1: separating audit-log retrieval from voucher generation
X-BeenThere: anima-bootstrap@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Mailing list for the bootstrap design team of the ANIMA WG <anima-bootstrap.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/anima-bootstrap>, <mailto:anima-bootstrap-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/anima-bootstrap/>
List-Post: <mailto:anima-bootstrap@ietf.org>
List-Help: <mailto:anima-bootstrap-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/anima-bootstrap>, <mailto:anima-bootstrap-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 12 Nov 2016 02:56:15 -0000

Toerless Eckert <tte+ietf@cs.fau.de> wrote:
    > As discussed today on the call, restated for the rest of the team with
    > more detail:

    -> pledge connects to two networks, A, B.  Pledge tries to well-behave,
    -> only offers nonce to one network first, A.  (registrar of) A gets
    -> voucher. A looks at audit-log. Audit log is fine.
    >    Ultimately, A decides not to enroll pledge though.

It might be a good idea to understand why... I think it matters why here,
because it would affect if the registrar ought to have told the MASA
something or not... your next sentence says that something was audited.

    -> Pledge offers nonce to B, B gets voucher and audit-log.
    >    Audit log shows A, so B is concerned. B rejects device.  Without the
    > entry in audit log, B would have enrolled device.

    > My worry is that the current audit log approach can too easily create
    > false positives that will make enrolment fail if a device has multiple
    > network connections:

Agreed, this is a problem.

    > It's impossible for A to get an audit-log without also getting a
    > voucher, which in return would make another domain suspicious and
    > likely make it decide not to accept the device.

    > Separating out request for voucher from request for audit-log could
    > work like this:

    >   MASA: request audit-log for (pledge,nonce1)
    >   MASA: audit-log entry: "A requested audit log for pledge,
    > hash(nonce1)" [1]
    > A: reply: audit-log

    >   ... A makes up its mind if it wants pledge and decides that it does
    > NOT.

I agree, we need something like this.
I think we have a race condition here, but I think we can solve it once we
have established what the problem is, and decide what are the compromises.
I think we actually need to do a threat analysis here...
I am pretty sure Max has it all in his head, but we'll need to explain to
others..