-----Original Message-----
From: Brian E Carpenter <brian.e.carpen...@gmail.com> 
Sent: Saturday 14 July 2018 16:20
To: Eliot Lear <l...@cisco.com>; Owen Friel (ofriel) <ofr...@cisco.com>; Eliot 
Lear <l...@cisco.com>; Michael Richardson <mcr+i...@sandelman.ca>; 
anima@ietf.org
Subject: Re: [Anima] Revision of scope of MASA in the BRSKI - Reg

On 15/07/2018 02:47, Eliot Lear wrote:
> Brian, is it your contention that 802.11 is beyond the scope of 
> autonomic computing?

No, of course not. But autonomic nodes aren't supposed to connect to any old 
WiFi they happen to find; that's exactly the case where secure bootstrap needs 
to fail. If they connect to a network on which there's a registrar that knows 
nothing about them, it won't authorize them to join the ACP.
[ofriel] Are we making the assumption that all networks are well behaved and a 
Registrar will actually reject devices it does not explicitly own? What about a 
rogue network where the operator does not own the connecting devices but the 
registrar accepts them anyway? That is the issue here.

"The domain registrar authenticates the pledge, makes authorization 
decisions,..."

In Figure 3, I guess authorization is the tiny item "[accept device?]".

BRSKI is defined in a nicely general way, but in an AN it's the domain 
registrar's job to decide who's allowed in.
Actually there seems to be a glitch in the text on this.
We find:

> 5.2.  Pledge Requests Voucher from the Registrar
>    ...
>    ...The registrar performs authorization as
>    detailed in [[EDNOTE: UNRESOLVED.  See Appendix D "Pledge
>    Authorization"]]. 

but that leads nowhere that I can find. BRSKI authors, please comment.

   Brian

> 
> 
> On 14.07.18 01:34, Brian E Carpenter wrote:
>> On 13/07/2018 21:26, Owen Friel (ofriel) wrote:
>>> I think its more accurate to state:
>>>
>>> “What a CUSTOMER wants to avoid is a pledge joining a network where the 
>>> MASA just does the logging and does no validation, without any other means 
>>> to determine that the device is on the correct network.” E.g. I plug in a 
>>> wi-fi device and it connects to the SSID of the company on the floor below 
>>> me.
>> That is so far outside the scope of the autonomic networking 
>> infrastructure application of BRSKI that I don't see why we'd even 
>> mention it. It's a case that definitely needs to fail hard in the autonomic 
>> context.
>>
>> If we want to extend the scope of BRSKI to cover BYOD on insecure 
>> WiFi, I think that's for some other WG.
>>
>>    Brian
>>
>>> The MASA cannot help with this unless there is complex sales channel 
>>> integration and the MASA explicitly knows in advance exactly what network 
>>> each pledge will be connecting to. A potential option is to also require 
>>> the registrar to provide some proof of ownership to the MASA in the 
>>> VoucherRequest.
>>>
>>> From: Anima <anima-boun...@ietf.org> On Behalf Of Eliot Lear
>>> Sent: Thursday 12 July 2018 17:38
>>> To: Michael Richardson <mcr+i...@sandelman.ca>; anima@ietf.org
>>> Subject: Re: [Anima] Revision of scope of MASA in the BRSKI - Reg
>>>
>>>
>>> The problem is that the manufacturer doesn't have enough context to make 
>>> decisions as to which network to join.  That is the challenge.
>>>
>>> On 12.07.18 17:12, Michael Richardson wrote:
>>>
>>>
>>>
>>> Eliot Lear <l...@cisco.com><mailto:l...@cisco.com> wrote:
>>>
>>>     > involved. What a manufacturer wants to avoid is a pledge 
>>> joining a
>>>
>>>     > network where the MASA just does the logging and does no 
>>> validation,
>>>
>>>     > without any other means to determine that the device is on the
>>>
>>>     > correct network. Otherwise, the pledge (we could call it the
>>>
>>>     > "station" in this context) could simply home to the wrong 
>>> network,
>>>
>>>     > and even resetting the device won't get you to the right network.
>>>
>>>
>>>
>>> I don't understand how the "manufacturer" can have a desire ("the 
>>> pledge
>>>
>>> avoid joining a network ...") that is different from the MASA's desire.
>>>
>>>
>>>
>>> The MASA *is* the expression manufacturer's desire.
>>>
>>> If the manufacturer has sales channel information that indicates the 
>>> Pledge
>>>
>>> is on the wrong network, it should not issue a voucher.
>>>
>>>
>>>
>>> So the situation you describe makes no sense to me.
>>>
>>>
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>>
>>> Anima mailing list
>>>
>>> Anima@ietf.org<mailto:Anima@ietf.org>
>>>
>>> https://www.ietf.org/mailman/listinfo/anima
>>>
>>>
>>>
>>> _______________________________________________
>>> Anima mailing list
>>> Anima@ietf.org
>>> https://www.ietf.org/mailman/listinfo/anima
>>>
>> _______________________________________________
>> Anima mailing list
>> Anima@ietf.org
>> https://www.ietf.org/mailman/listinfo/anima
> 
> 

_______________________________________________
Anima mailing list
Anima@ietf.org
https://www.ietf.org/mailman/listinfo/anima

Reply via email to