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

From: Toerless Eckert <[email-masked]>
Date: Tue, 1 Nov 2016 21:15:23 +0100

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

---

From: "Max Pritikin (pritikin)" <[email-masked]>
Date: Tue, 1 Nov 2016 22:16:45 +0000

I see this as the same discussion for “concern2” so please look to that thread for responses.

- max

> On Nov 1, 2016, at 2:15 PM, Toerless Eckert <[email-masked]> wrote:
> 
> _______________________________________________
> Anima-bootstrap mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/anima-bootstrap

---

From: Toerless Eckert <[email-masked]>
Date: Wed, 2 Nov 2016 02:35:44 +0100

On Tue, Nov 01, 2016 at 10:16:45PM +0000, Max Pritikin (pritikin) wrote:
> I see this as the same discussion for ???concern2??? so please look to that thread for responses.

I can not identify any text n the sections 6.4 and 7 (that you referred
to in the other mail reply) that are discusing the case i made below.

Cheers
    Toerless

-- 
---
[email-masked]

---

From: Michael Richardson <[email-masked]>
Date: Sat, 12 Nov 2016 11:56:10 +0900

> As discussed today on the call, restated for the rest of the team with

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

    >    Audit log shows A, so B is concerned. B rejects device.  Without the
    > entry in audit log, B would have enrolled device.

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

    >   MASA: request audit-log for (pledge,nonce1)
    > A: reply: audit-log

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

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