Subject: Re: [Anima-bootstrap] brsky concern2: Timelyness of log entries

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

-> Attacker has physical access to pledge at some point in time.
-> Makes device generate nonce messages. Stashes messages away (not connecting
   to MASA).

-> Device gets later enrolled/installed later by valid owner.
-> Maybe valid owner does re-enroll devices several times, eg: between them
   being put into different locations (as often requered in big customers,
   eg: CPE and the like).

-> Attacker at some point uses stashed nonce messages to extract audit-logs
   (and vouchers) from MASA. Can not use them because attacker does not have
   access to device anymore, but would rase red flags when actual owner
   of devices would do any new re-enrollment where it looks at audit-log.

I am not sure how strong/likely this attack vector is given how the manufacturer
can identify and therefore hopefully track down the attackers registrar (given
that that requires an authenticated ID with the MASA), but:

The log-entry makes everybody easily believe that the device was having the
enrollment sgnaling at the time when it was logged when in reality that is
not true. Yes, it would require up to one more round-trip to establish that
fact, but it looks prudent to me if that was done.

Cheers
    Toerless

---

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

> On Nov 1, 2016, at 2:28 PM, Toerless Eckert <[email-masked]> wrote:
> 

I think this conversation could quickly get derailed by the flow details from above (I disagree with some of your assumptions). Perhaps it would help to start with a statement of the security concern you’re raising. I think it is: 

Can an attacker inject entries into the audit log that would cause problems for the Registrar heuristic/analytics based decisions?

The following are attempts to minimize possible attacks against the audit log:

1) Nonced entries require the attacker to have had access to the device during that boot of the device to use the audit token. If the Registrar is comfortable with the chain of control they can ignore these entries. Previous versions have indicated that Registrar authentication by the MASA is required for these as well but I’m not seeing that currently 

2) Nonceless entries are always problematic. From -04: "If a nonce is not provided then the MASA service MUST authenticate the Registrar as a valid customer.  This prevents denial of service attacks” and “the Registrar MUST be authenticated by the MASA service although no requirement is implied that the MASA associates this authentication with ownership.”. I’ve contended that doing so is why we’d have a voucher format indicating ownership. 

Also note that Section 6.4 directly discusses this issue.

A race condition is discussed in the Security Considerations section. 

> fact, but it looks prudent to me if that was done.

Section 5.1 includes an EDNOTE to discuss this case. As of yet folks haven’t responded but I’ll take it that you’re voting for this additional round trip.

- max

> 
> Cheers
>    Toerless
> 
> _______________________________________________
> 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:15:05 +0100

Thanks, Max...inline
On Tue, Nov 01, 2016 at 10:15:50PM +0000, Max Pritikin (pritikin) wrote:
> I think this conversation could quickly get derailed by the flow details from above (I disagree with some of your assumptions).

What assumptions do you disagree with ?

> Perhaps it would help to start with a statement of the security concern you???re raising. I think it is: 

> Can an attacker inject entries into the audit log that would cause problems for the Registrar heuristic/analytics based decisions?

Right. Sub-sections of section 7 about specific attack problems. This could
be one such sub-section.

> 1) Nonced entries require the attacker to have had access to the device during that boot of the device to use the audit token.

Right. But access could have been long ago and log entry created much later.
And those would trigger rejection of the device according to 3.3.4 log
verification. I call this a false positive. And spying on the audit-log.

> If the Registrar is comfortable with the chain of control they can ignore these entries. 

Just to reconfirm: You are saying that registrars could ignore the audit log
and you cal that "attempts to minimize possible attacks against the audit log" ??

> Previous versions have indicated that Registrar authentication by the MASA is required for these as well but I???m not seeing that currently 

Should vbe optional. But should have some discussion what benefits authentication
would have. Eliminate "some" ? DoS attacks against MASA ? What else..

> 2) Nonceless entries are always problematic. From -04: "If a nonce is not provided then the MASA service MUST authenticate the Registrar as a valid customer.  This prevents denial of service attacks??? and ???the Registrar MUST be authenticated by the MASA service although no requirement is implied that the MASA associates this authentication with ownership.???. I???ve contended that doing so is why we???d have a voucher format indicating ownership. 

I thought the netconf solution also supports an anonymous ownership voucher ?
Is that true ? Is that possible with BRSKY ?

> Section 5.1 includes an EDNOTE to discuss this case. As of yet folks haven???t responded but I???ll take it that you???re voting for this additional round trip.

See above on the delayed attack vector. DO you think that strong enough 
to worry about it ?

Cheers
    Toerless

---

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

Toerless Eckert <[email-masked]> wrote:
    > Device gets later enrolled/installed later by valid owner.  Maybe
    > valid owner does re-enroll devices several times, eg: between them
    >    being put into different locations (as often requered in big
    > customers, eg: CPE and the like).

I'm concerned here.
Why would they enroll it multiple times?  This doesn't make sense to me.
If they really wanted to reset to factory default, wouldn't they reflash
completely back to factory, so:

           "Attacker has physical access to pledge at some point in time."

becomes irrelevant?  Was there a TPM? Did the attacker get access to that?
Did they get access to the manufacturer installed private key?

If they didn't really reset to factory default, then it seems that they would
use the LDevID from the first enrollment to rekey with a new LDevID.

So, this is my problem with this scenario.