Re: [secdir] [Anima] Secdir last call review of draft-ietf-anima-bootstrapping-keyinfra-16

["Joel M. Halpern" <[e-mail]>]

Off-list:

It sounds from you rnote like either:
1) Anima admission process is seriously underspecified in a way that 
affects itneroperability, or
2) BRSKI is actually irrelevant to ANIMA, and should be reviewed and 
advanced (if desired) by some other working group.

I doubt either is your intention.
And statements such as Eliot's ill-formed comment that no one would do 
that do not help the case for the Anima WG having thought this through.

Yours,
Joel

On 10/2/18 3:46 PM, Brian E Carpenter wrote:
> On 2018-10-03 08:00, Michael Richardson wrote:
>>
>>      lear> I think we've lost sight of what we're talking about.  We're talking
>>      lear> about a completely automated method for a local trust anchor to be
>>      lear> installed on a device, and a kick to EST for the device to receive a
>>      lear> local credential.  For that to happen there needs to be a trusted
>>      lear> introduction, and the device manufacturer or its agent is in the best
>>      lear> position to do that.
>>
>> Randy Bush <[e-mail]> wrote:
>>      > no.  the owner's trust controller is.
>>
>> Cool.  It's a relief to know that we've missed something obvious.
>> Could you please explain things more?
>>
>> We call the owner's trust controller the "Registrar", or sometimes the
>> Join-Registrar/Coordinator.  I don't mind calling it a trust controller, but
>> maybe your term has a different meaning.
> 
> There's a point that close followers of Anima may know and that others
> don't. There is a topic intentionally missed out of the BRSKI document,
> which is how the registrar decides whether a particular device, let's
> say device X12345, is allowed to join the secure domain in question.
> 
> This point is skated over in the draft; in fact there is a text glitch
> in section 5.2 where it should be stated, already known to the authors.
> (Sorry, but we didn't find that text glitch soon enough to fix it before
> the IETF Last Call.)
> 
> The actual authorization mechanism - "X12345 is allowed to join" - is
> not part of BRSKI. It is, as Randy rightly implies, not the business
> of the manufacturer.
> 
> The MASA is used only to verify that X12345 is in fact X12345. It's
> part of the trust model, not the authorization model.
> 
> If I had my wishes, the MASA would be optional, with a local voucher
> store in the registrar as the alternative. But that wasn't the WG
> consensus.
> 
>      Brian
> 
> _______________________________________________
> Anima mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/anima
>