Re: [Anima] verification of manufacturer in BRSKI

['Toerless Eckert' <[e-mail]>]

On Fri, Feb 23, 2018 at 12:37:47PM +0530, Anoop Kumar Pandey wrote:
> I think that is not necessary. When a pledge/device is bought, it is manually added to a network of buyer [usually intranet], where it can discover a JRC.  Therefore it is not the choice/privilege of pledge to verify the domain. On the other side, JRC should validate if the pledge has come from genuine manufacturer and is clean.

I did explain to you in my prior email, that one primary purpose of Voucher/MASA is to prohibit
man-in-the-middle attacks. 

> Alternatively, If a pledge is put on internet, then considering there may be countless number of JRCs on internet, and trying to connect to each JRC until the pledge finds actual owner is practically impossible; the pledge will have to be configured to discover a particular JRC while buying. So again the pledge doesn???t have much choice.

I did explain to you in another email in this thread that piece as well.

> Also Quoting Toer advocating pledge requiring to verify JRC: ???. If you are a buyer of large number of pledges and do not need any protection against theft,  misassignment of pledges to other networks or intrusions into pledges that intend to impact your network later, then sure - you may be happy with pledges not requiring vouchers to get enrolled.???

That was purely respective to theft protectin, not men in the middle attacks.

> In a parallel mail, you have mentioned that BRSKI is one time process and need to be deliberately re-run/started. So once BRSKI is completed and pledge is enrolled; intrude in it or steal and put it in some other network, it won???t matter. 

I did explain to you that BRSKI is meant to be be run every time pledge is in factory reset state.

> But the case where BRSKI runs automatically if pledge is disconnected and added to anywhere else, at least theft won???t work because pledge won???t work without re-verifying the voucher with new network/JRC.  I think this can be made mandatory in pledge to re-run BRSKI if it detects network change.

That is explcitly mentioned as a nogo in BRSKI already. Change of network you're
connecting to does not imply change of ownership.

> I still believe that Pledge need not verify JRC


We did provide a lot of answers/reasons to your questions re. why/where/how BRSKI/MASA/Voucher
are necessary/beneficial. You did not provide any technical or use-case reasoning why
those arguments are incorrect in your opinion. You  are just repeating you initial
opinion and think you can ignore the answers provided to you. 


>  But if necessary, the easy way will be following:
> 
>  
> 
> When pledge verifies a JRC, these steps are there [your first mail to me]:
> 
> 1.       Pledge issues voucher request to JRC
> 
> 2.       JRC passes voucher request to MASA. 
> 
> 3.       MASA verifies request and issues voucher to JRC
> 
> 4.       JRC passes voucher to Pledge
> 
> 5.       Pledge verifies the voucher and send voucher status telemetry and trusts JRC. 
> 
>  
> 
> These steps require MASA to be online, else they will fail.

That is the preferred, standard method, yes. There are mentionings of offline MASA/voucher
options, i think i the appendix.

> What I propose is, when we buy the device, MI can issue a digitally signed invoice issued to domain/JRC.

Yes, this would be one instantiation option of what we call an offline voucher,
which is covered by BRSKI. I think BRSKI also outlines the issues/limitations that can
come with offline vouchers. For example if you buy from a shop that bought
from a reseller that bought from a distributor that bought from the manufacturer,
the whole sales integration to be able to generate such a voucher may be
cost prohibitive. A key contribution of BRSKI is the concept of the logging of
voucher requests as a way to generate the hopefully most cost-reduced optoin to
generate vouchers. Which can also be applied to offline vouchers.

The various means and processes how to provide most easily vouchers in various
situations are definitely a good and long term discussion topic, even offering
opportunity to write additional draft/RFCs.

> Now when a pledge wants to validate the JRC, he simply needs to verify the signature of MI on the invoice. No communication with MASA or even MASA itself is not required. 

Yes. I have this picture in my head of a guy (called Scotty ;-) holding
a printed sales receipt with QR-code and trying to show it to his new 
router/equipment.

The classicial representation of an offline voucher is a USB stick and a
pair of sneakers to represent the physcial media and transport channel,
but i like the QR-code too to represent the potential complexities of
offline vouchers.

> It is just like the way, JRC verifies the pledge using the IDevID certificate issued by MI.

If you have a side-channel to get the voucher into the pledge, yes. But
very often in "professionally managed networks" (ANIMA charter), the guy who
gets the sales receipt could be (hundreds of) miles away from the pledge,
so in those environments its much more likely that any type of offline
voucher can easily be injected into the Registrar first than through a side
channel physcially into the pledge.

> 
> Basically you have known manufacturers and you are buying from known source. Therefore there is no hostility

Repeated incorrect conclusion. Asked and answered.

> Further it???s not a cloud environment where you don???t know, where your device is placed. Installation of pledge will be manual [barely any chance of error, until you consider humans are hostile].

Repeated incorrect conclusion. Asked and answered.

> If there were hostility, like unknown manufacturer which could give you malicious pledge, BRSKI anyway can???t detect that, since it simply checks IDevID  which is anyway signed by unknown manufacturer and will check out. You mentioned in earlier mail also that manual intervention is required for such case. [You quoted ???if the JRC does see a MI that it does not know, then it can ask a human.???]

Repeated incorrect conclusion. Asked and answered.

> There are hostile networks and pledges, but you have only whitelist of manufacturers [your assumption only ???the JRC *can* know all the legitimate manufacturers???] which only talks about known manufacturers. But it doesn???t provide security in case of unknown or known turned rogue MI/pledge. For that manual intervention is required.

Repeated incorrect conclusion. Asked and answered.

Cheers
    Toerless

> Regards,
> 
> Anoop
> 
>  
> 
>  
> 
>  
> 
>  
> 
>  
> 
>  
> 
>  
> 
>  
> 
> -----Original Message-----
> From: Michael Richardson [mailto:[e-mail]] 
> Sent: 23 February 2018 07:25
> To: Anoop Kumar Pandey <[e-mail]>
> Cc: 'Brian E Carpenter' <[e-mail]>; [e-mail]
> Subject: Re: [Anima] verification of manufacturer in BRSKI
> 
>  
> 
>  
> 
> Anoop Kumar Pandey < <mailto:[e-mail]> [e-mail]> wrote:
> 
>  
> 
>     > Besides, it can also be done by verifying
> 
>     > the certificate of JRC during enrolment.
> 
>  
> 
> Please explain.
> 
> It would be great to simplify the protocol.
> 
>  
> 
>  
> 
>     > I would also like to quote/remind following lines from Section 1.3
> 
>     > [Scope of Solution] of the RFC:
> 
>  
> 
>     > ???But this solution is not exclusive to the large, it is intended to
> 
>     > scale to thousands of devices located in hostile environments, such as
> 
>     > ISP provided CPE devices which are drop-shipped to the end user. The
> 
>     > situation where an order is fulfilled from distributed warehouse from
> 
>     > a common stock and shipped directly to the target location at the
> 
>     > request of the domain owner is explicitly supported. That stock
> 
>     > ("SKU") could be provided to a number of potential domain owners, and
> 
>     > the eventual domain owner will not know a-priori which device will go
> 
>     > to which location.???
> 
>  
> 
> Yes, it's designed exactly to deal with situation.
> 
> Are you saying that it fails in some way?
> 
>  
> 
> --
> 
> Michael Richardson < <mailto:[e-mail]> [e-mail]>, Sandelman Software Works  -= IPv6 IoT consulting =-
> 
>  
> 
>  
> 
>  
> 
> 
> -------------------------------------------------------------------------------------------------------------------------------
> [ C-DAC is on Social-Media too. Kindly follow us at:
> Facebook: https://www.facebook.com/CDACINDIA & Twitter: @cdacindia ]
> 
> This e-mail is for the sole use of the intended recipient(s) and may
> contain confidential and privileged information. If you are not the
> intended recipient, please contact the sender by reply e-mail and destroy
> all copies and the original message. Any unauthorized review, use,
> disclosure, dissemination, forwarding, printing or copying of this email
> is strictly prohibited and appropriate legal action will be taken.
> -------------------------------------------------------------------------------------------------------------------------------
> 

-- 
---
[e-mail]