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:[email protected]]
Sent: 23 February 2018 07:25
To: Anoop Kumar Pandey <[email protected]>
Cc: 'Brian E Carpenter' <[email protected]>; [email protected]
Subject: Re: [Anima] verification of manufacturer in BRSKI
Anoop Kumar Pandey < <mailto:[email protected]> [email protected]> 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:[email protected]> [email protected]>,
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
[email protected]
https://www.ietf.org/mailman/listinfo/anima
