Anoop> Pledge verifying the

Anoop> domain is anyway overrated.

Michael>So, I think you are saying that you do not subscribe to the problem 
statement.

 

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.

 

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.

 

 

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

 

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. 

 

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.

 

 

Anoop> Besides, it can also be done by verifying

Anoop> the certificate of JRC during enrolment.

Michael>Please explain.

Michael>It would be great to simplify the protocol.

 

I still believe that Pledge need not verify JRC, 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.

 

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

 

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. 

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

 

 

Anoop> I would also like to quote/remind following lines from Section 1.3

Anoop> [Scope of Solution] of the RFC:

Anoop> “But this solution is not exclusive to the large, it is intended to

Anoop> scale to thousands of devices located in hostile environments, such as

Anoop> ISP provided CPE devices which are drop-shipped to the end user. The

Anoop> situation where an order is fulfilled from distributed warehouse from

Anoop> a common stock and shipped directly to the target location at the

Anoop> request of the domain owner is explicitly supported. That stock

Anoop> ("SKU") could be provided to a number of potential domain owners, and

Anoop> the eventual domain owner will not know a-priori which device will go

Anoop> to which location.”

Michael>Yes, it's designed exactly to deal with situation.

Michael>Are you saying that it fails in some way?

 

You said “We assume that in a managed network that the JRC *can* know all the 
legitimate manufacturers.”. 

Brian said “ANIMA is scoped to support professionally managed networks. So it 
seems reasonable to assume that they have procurement procedures in place to 
buy from known sources and not to buy kit "off the back of a lorry" to use a 
British idiom.”

 

Basically you have known manufacturers and you are buying from known source. 
Therefore there is no hostility. 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].

 

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

 

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.

 

 

Regards,

Anoop

 

 

 

 

 

 

 

 

-----Original Message-----
From: Michael Richardson [mailto:mcr+i...@sandelman.ca] 
Sent: 23 February 2018 07:25
To: Anoop Kumar Pandey <an...@cdac.in>
Cc: 'Brian E Carpenter' <brian.e.carpen...@gmail.com>; anima@ietf.org
Subject: Re: [Anima] verification of manufacturer in BRSKI

 

 

Anoop Kumar Pandey < <mailto:an...@cdac.in> an...@cdac.in> 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:mcr+i...@sandelman.ca> mcr+i...@sandelman.ca>, 
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.
-------------------------------------------------------------------------------------------------------------------------------

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

Reply via email to