Re: [Anima-bootstrap] [Anima] Ownership Concept

["Max Pritikin (pritikin)" <[e-mail]>]

Robert, good to meet you in person today. I’m picking up this old thread but any references I make concern the current version of the document as found here:
https://tools.ietf.org/html/draft-pritikin-anima-bootstrapping-keyinfra-02

The bootstrap design team wiki is here:
http://trac.tools.ietf.org/wg/anima/trac/wiki/Bootstrap
Please *please* feel free to join the mailing list and/or meetings. The feedback is appreciated even as I admit this thread petered out. I’ve modified this thread to go to the bootstrap design team rather than anima at large.

Anyway, back to the thread,

On Apr 1, 2015, at 12:10 PM, Robert Cragie <[e-mail]<mailto:[e-mail]>> wrote:

Hi Max,

Thanks for your responses. Further responses inline, bracketed by <RCC2></RCC2>

Robert

On 30/03/2015 18:03, Max Pritikin (pritikin) wrote:

There are certainly cases where I can see this being used but conceptually it is not much different to a whitelist on the registrar.

The registrar is owned and operated by the domain owner. The cloud service is not. I argue MASA substantially simplifies the threat model.

<RCC>I see now that the purpose of the MASA service is not online whitelisting, and the difference in the domain authority and the MASA.</RCC>

The only other operation it seems to do is to sign the domain certificate. But the registrar could also do this - so I guess this is really combining MASA and registrar in a single box. Either way, the NE has to have the domain public key, whether the MASA or the Registrar is authorised to issue domain certificates on behalf of the Domain CA and any other public keys relevant to the certificate chain.

The MASA does not sign certs

<RCC>So why is it called a "signing authority" then? Confusing. I can see it may sign authorisation tokes (see later).

Correct, it is called the “manufacturer authorized signing authority (MASA)” because it is signing something, the authorization token, using an authorized key issued by the manufacturer trust anchor.


Understood. It signs the “proof of logging” things we called “authorization tokens”. Please feel free to suggest terms that resonate.
<RCC2>I think "authorization token" is fine. There needs to be more detail on the process, that's all.</RCC2>
<RCC>
So please explain the authorisation token in more detail and what leads to its generation. This is a bit more than just logging.

The authorization token contains a signed statement to the device indicating that:
a) the MASA is aware the device is joining this domain
b) the MASA has logged information about how the device is joining this domain
(e.g. was a nonce involved)
It would be entirely fair to call this some sort of “proof of logging token” instead of an authorization token!

s4.1.2: NE only joins a domain if an authorization token is provided. This behavior of the NE ensures that a log of the authorization token is also a log of every time the NE joins a domain.
<RCC2>OK</RCC2>

s4.3.2: Registrar only allows the device to join the domain if the devices history (e.g. the log information) doesn’t show it has joined Mallory’s domain. Or, if the registar doesn’t care, maybe it just doesn’t check.
<RCC2>I would imagine Mallory's purpose is to manipulate the joining to make it look as if the NE didn't join Mallory's domain.

Right. And the device refusing to join Mallory’s domain until and ‘authorization token’ from the MASA server is presented provides a proof that logging has captured this event. This directly mitigates the threat that Mallory attempts to manipulate the NE to join without this being logged.

I see that the MASA check is auxiliary and optional</RCC2>

The current draft indicates that MASA verification of Mallory’s identity is mandated when nonce-less tokens are requested. But that this is optional the rest of the time with associated DoS risks as discussed in the security considerations. I’m totally open to improvements if we can meet the other requirements.


s4.3.3: Registrar MUST claim the device, obtaining an authorization token and ensuring a log entry is generated, in order to get the device to trust it.
<RCC2>OK</RCC2>

As far as I can see (and please correct me if I am wrong), the Mallory/honeypot detection isn't really shown in Figure 1.

See Figure 2 here:
https://tools.ietf.org/html/draft-pritikin-anima-bootstrapping-keyinfra-02#section-3

"[ still accept device?]” is a reference to the registrar verifying the log information, detecting Mallory and deciding what to do. The customer’s network can of course decide to ignore the security risk or to block the device from joining.


In figure1 note that “device history log” and “authorization token” are sent to the Domain from the MASA. The Domain then decides “still accept device?” based on the log information. This is the Registrar checking for Mallory. If the log information shows an unknown/unexpected log entry then Mallory has been detected.

It is still the Domain’s policy decision about continuing.

For this to work, the NE would have to send details of the registrar it has received, presumably relayed by the registrar itself (OCSP)?

The logging information from the MASA provides information about previous domains the NE has joined. If Mallory has compromised the NE then we can’t depend on the NE to expose this information.


Ummm… didn’t follow you completely. I suggest keeping the log information in the cloud and delivering it to the registrar from there because I don’t trust the NE to reveal that it is has been corrupted by Mallory.
<RCC2>I think what is missing is that the request needs to come from the NE and contain information about the Domain the NE thinks it is connecting to as well as the NE. Otherwise Mallory could successfully act as MITM and convince the NE that it is a legitimate domain. See attached diagrams.</RCC2>
Then the MASA service sends a signed authorisation token back, attesting the validity of the Registrar. A honeypot would not be able to provide valid credentials so at that point would fail.

Correct, the Mallory domain would have to contact the MASA to obtain a signed authorization token which ensures that the event has been logged.

Diagram re-attached.

In the MiTM diagram a couple of points stand out:
a) the MiTM is acting exactly like the anima proxy
b) the MiTM isn’t engaged in the exchange with MASA so the resulting authorization is for the ‘domain’ not the ‘MiTM’
c) The NE will reject the "!!MD information!!” because it is not signed by the same Trust Anchor as is indicated in the authorization token
d) Enrollment with the MiTM will similarly fail

The MiTM in this diagram is ultimately blocked from gaining control of NE but does successfully DoS the bootstrapping. Of course it could have done that by shipping packets to /dev/null (given the topology shown).

Your suggestion to bind the domain identity (in the final diagram) also works to mitigate this threat. The reason I reject this, even though it is better at the mitigation, is that it prevents cases where the MASA service is contacted in advance in this (abbreviated) flow:

.. Domain——> MASA
.. Domain<— authz token MASA
.. time passes, NE shipped
NE—> Domain [air gap] MASA unreachable
NE<—info Domain [air gap] MASA unreachable
In this case the domain pre-fetches the MASA responses using the the nonceless method and can now present the token to the NE even when the MASA is unreachable or out of business. If this isn’t clear from the current doc it sounds like expanding on this requirement is a good working group task (update to the doc is in order).

Thanks again for the conversation,

- max


If a honeypot tried to use a honeypot MASA, it wouldn't have the private key to sign the authorisation token so that would fail to. If the honeypot claims the MASA is unreachable - another failure. So I agree, a good way to simplify the threat model.
</RCC>


Regarding the honeypot (Mallory) attack - the NE is going to find out it's a honeypot as the honeypot will not be able to issue valid domain certificates.

The NE can't identify a "valid" domain certificate so I don't believe this is correct.

<RCC>It could if it were pre-provisioned with the Registrar's public key and Domain CA public key. As you point out, in Section 2, "As a service offering the MASA can incorporate many of the bootstrapping elements (such as the Registrar and the Domain CA) into the overall service." So surely in this case, there is no separation of CAs?</RCC>

For any given domain one could do this. But it doesn’t work at scale or if the target domain isn’t known when the device leaves the vendor.
<RCC2>All the more reason for the additional data needed at the beginning of the sequence (Domain ID sent to NE)</RCC2>

Robert
<draft-pritikin-anima-bootstrapping-keyinfra-diags.txt>