Re: [Anima] verification of manufacturer in BRSKI

["Anoop Kumar Pandey" <[e-mail]>]

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