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

[Brian E Carpenter <[e-mail]>]

On 2018-10-03 09:06, Joel M. Halpern wrote:
> Off-list:
> 
> It sounds from you rnote like either:
> 1) Anima admission process is seriously underspecified in a way that 
> affects itneroperability, or

No, it's *intentionally* underspecified w.r.t. authorization. The registrar
is part of a specific autonomic networking implementation, so I think it's
OK that this is not standardized. Once there is established practice, it
might be time to revisit this.
 
> 2) BRSKI is actually irrelevant to ANIMA, and should be reviewed and 
> advanced (if desired) by some other working group.

I think BRSKI has the misfortune of being potentially quite general, but
it is in fact required by Anima as the basis for the initial secure
substrate.

> I doubt either is your intention.

Indeed not.

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

I think it's been thought through but badly articulated. In that sense,
the Last Call is doing its job.

   Brian

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