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

Toerless Eckert <tte+ietf@cs.fau.de> Tue, 01 November 2016 20:15 UTC

Return-Path: <eckert@i4.informatik.uni-erlangen.de>
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 5945F1299DF for <anima-bootstrap@ietfa.amsl.com>; Tue, 1 Nov 2016 13:15:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.696
X-Spam-Level:
X-Spam-Status: No, score=-5.696 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.497] 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 d_v-uRQrWY62 for <anima-bootstrap@ietfa.amsl.com>; Tue, 1 Nov 2016 13:15:25 -0700 (PDT)
Received: from faui40.informatik.uni-erlangen.de (faui40.informatik.uni-erlangen.de [131.188.34.40]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6DFFF128DF6 for <anima-bootstrap@ietf.org>; Tue, 1 Nov 2016 13:15:25 -0700 (PDT)
Received: from faui40p.informatik.uni-erlangen.de (faui40p.informatik.uni-erlangen.de [131.188.34.77]) by faui40.informatik.uni-erlangen.de (Postfix) with ESMTP id DBA6C58C4AE for <anima-bootstrap@ietf.org>; Tue, 1 Nov 2016 21:15:23 +0100 (CET)
Received: by faui40p.informatik.uni-erlangen.de (Postfix, from userid 10463) id C0155B0ACBC; Tue, 1 Nov 2016 21:15:23 +0100 (CET)
Date: Tue, 1 Nov 2016 21:15:23 +0100
From: Toerless Eckert <tte+ietf@cs.fau.de>
To: anima-bootstrap@ietf.org
Message-ID: <20161101201523.GB9776@faui40p.informatik.uni-erlangen.de>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.5.21 (2010-09-15)
Archived-At: <https://mailarchive.ietf.org/arch/msg/anima-bootstrap/Q5w4ayX66rnq3yWwRYEecfwFIp8>
Subject: [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: Tue, 01 Nov 2016 20:15:27 -0000

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

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:

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

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

  -> A doesn't do anything more. Audit log would show B that A did see device,
     but also that A never got voucher so that it could not have modified
     device == B will happily enroll pledge.


  ... A makes up its mind if it wants pledge and decides that it does want to:

  A->MASA: request voucher for (pledge,nonce1)
  MASA:    Examine audit-log that no voucher was granted since the audit-log
           was given to A [1]. requests for audit-logs since [1] are
	   ignored in this determination.
  MASA->A: If audit-log ok:
           reply OK: voucher(nonce1)
           audit-log entry: "A received voucher for pledge, hash(nonce1)" [2]

	   If audit-log nok:
           reply NOK: audit-log
           audit-log entry: "A failed voucher request for pledge, hash(nonce1), hash(nonce2)"
	   hash(nonce2) would be from an audit-log entry that did happen after
	   [1] and 
          

Cheers
    Toerless