On Tue, Jul 10, 2018 at 02:30:12PM +0530, Anoop Kumar Pandey wrote: > Toerless>When the pledge opens a TLS connection to the registrar, the pledge > can authenticate the certificate presented by the registrar as part of the > TLS connection setup with the voucher. Thats what the voucher does. > > Anyone can present certificate of anyone else (it's public).
YOu do understand how TLS authentication works, right ? > That's why I proposed use of digital signature and later verification > to establish the identity of both JRC and Pledge. Please try to understand how authentication of TLS peer with the help of voucher works. If it's unclear from BRSKI and rfc8366, feel free to ask more detailled questions. > Toerless>[there is the detail aspect of you saying owner public key whereas > the voucher uses the owners certificate, which is better, but lets ignore > tht for a second] > > Certificate is just a container for public key along with other meta data. Right. And that meta data makes the crucial difference. > Why go to such lengths and give headache of extra USB. Why can't the digital > invoice(or voucher) be embedded in the ROM in the device itself or be kept > wherever the IDevID has been put. Asked and answered. Also: Read up on ROM to understand why its not storage for device specific information and on TAM why those are not a good place to store public information like vouchers. > [If you use any external detachable device then that usb can used with other > pledge also(may be). If it is embedded, it's part of device] > > Toerless> Agreed. And we have an object that does this, its called the > voucher. > > I know. I only want to put it into the device itself so that communication > with MASA is not required and protocol becomes simpler as now pledge and JRC > can authenticate themselves using digital signature on the voucher. Sure. Hope you understood my explanations. No new artefact needed, no change to BRSKI needed. Cheers Toerless > Regards, > > Anoop > > > > > > -----Original Message----- > From: 'Toerless Eckert' [mailto:[email protected]] > Sent: 10 July 2018 13:47 > To: Anoop Kumar Pandey <[email protected]> > Cc: 'Michael Richardson' <[email protected]>; [email protected] > Subject: Re: [Anima] Revision of scope of MASA in the BRSKI - Reg > > > > On Tue, Jul 10, 2018 at 12:44:45PM +0530, Anoop Kumar Pandey wrote: > > > Toerless >The pledge simply needs to locate the voucher locally, and > > > when it connects to the registrar, it can skip the step of retrieving > > > the voucher because it already does trust the registrar as it has the > voucher locally. > > > > > > The pledge may have the voucher locally, but how will it know that the > > > domain it is going to register is the real owner. It may be some other > > > domain. For that, I suggested use of public key of owners in the > > > digital invoice which can be used to verify the signed acceptance sent by > JRC. > > > > Maybe i am confused and overlook something in your assumed setup, but: > > > > When the pledge opens a TLS connection to the registrar, the pledge can > authenticate the certificate presented by the registrar as part of the TLS > connection setup with the voucher. Thats what the voucher does. > > > > [there is the detail aspect of you saying owner public key whereas the > voucher uses the owners certificate, which is better, but lets ignore tht > for a second] > > > > > Once pledge and JRC have verified each other, enrolment can go on using > EST. > > > I want to eliminate the communication overhead or MASA itself. > > > > Yes, what i said does this. Pledge has voucher, pledge doe not need to > request voucher from Registrar, ergo Registrar does not need to connect to > MASA. > > > > > Toerless>I think those solutions are not ideal because they do > > > Toerless>introduce > > > another new "touch" to the pledge. > > > > > > > > > Anyway manufacturer is installing an IDevID, they can also install a > > > digital invoice (or voucher). > > > > Unless your devie is built to order, you do not know the owner at the time > when you put an IDevID onto a device. And putting an IDevID onto a device is > a highly specialized process in manufacturing where even if you where doing > build-to-order, you likely would want to separate it from assigning an owner > to a device. As Max said, the mayority of all devices are assigned an owner > when the product has long left the manufacturer and is now sitting in some > reseller hosted storge facility. > > > > > Toerless> The BRSKI document does allude to these options but does not > > > necessarily detail them well enough for every uninitiated reader to > > > understand the options. > > > > > > > > > Why leave something to someone's imagination. All necessary > > > details/angles/options can be entailed if it's provisioned in the > > > BRSKI already so that no stone is left unturned. > > > > ? Not sure i correctly understand that sentence. If its saying that it would > be good to write down the possible derived workflows, i think i already said > that in my email. > > > > > > > When a device is manufactured, it will only have IDevID. But when a > > > device is sold; before shipping, digital invoice may be embedded in > > > it. In this way the device may lie in the warehouse for years but > > > unless it has been sold, it is not unique to a customer. > > > > Its IMHO certainly a better option if the reseller puts the voucher onto the > device when it is shipping it out to the customer than the customer doing it > upon receipt/installation of the device. Alas, even in that option there are > operational pitfalls: > > > > Lets say you want voucher-on-a-stick. As long as you just attach that USB > stick to the products packaging, you're up to a high rate of errors on the > receiver side.. "What.. there was a USB stick in the packaging ? Where do i > need to put it ? Oh wait, the cleaner already threw away the packaging". > > > > So you want to make sure that the voucher is actually in the device itself. > > At minimum you would need the reseller to open the box and put the USB stick > into a specific USB port designed not to stick out, so tht that USB stick is > an undistinguishable part of the device. I knew few router products where > this is mechanically feasible. > > > > Or you can try to electronically load the voucher onto the device. > > Which just makes the whole thing even worse: > > > > IMHO, no reeller in their sane mind would want to open boxes to physically > attach a sales dongle to a device. Even less so do they want to > eletctrically power it on and run some magic uploa routine to put the > voucher onto the device. > > > > I think there are ways around this, i can write up something if i find the > time, but suffice to say: Without some better solutions than this, the most > lightweigt option is still to think of an offline system to feed the voucher > into the registrar if you want to avoid the BRSKI-MASA connection. Instead > of trying to feed it directly to the pledge. > > > > > > > > Michael"> Ultimately, it's not the JRC which is suspicious of who the > > > Pledge's owner is, it's the Pledge which does not know who owns it." > > > > > > > > > I assure you that pledge can verify the JRC using the public key put > > > in the digital invoice and using it to verify the digitally signed > > > acceptance note from JRC. > > > > Agreed. And we have an object that does this, its called the voucher. > > > > Cheers > > Toerless > > > > > Regards, > > > > > > Anoop > > > > > > > > > > > > -----Original Message----- > > > From: Toerless Eckert [ <mailto:[email protected]> mailto:[email protected]] > > > Sent: 10 July 2018 12:00 > > > To: Michael Richardson < <mailto:[email protected]> > [email protected]> > > > Cc: Anoop Kumar Pandey < <mailto:[email protected]> [email protected]>; > <mailto:[email protected]> [email protected] > > > Subject: Re: [Anima] Revision of scope of MASA in the BRSKI - Reg > > > > > > > > > > > > Anoop: > > > > > > > > > > > > To rephrase from Michaels reply: > > > > > > > > > > > > You do not need any BRSKI protocol or voucher changes to do what you want. > > > > > > > > > > > > The pledge simply needs to locate the voucher locally, and when it > > > connects to the registrar, it can skip the step of retrieving the > > > voucher because it already does trust the registrar as it has the voucher > locally. > > > > > > > > > > > > In fact, you can even use RFC7030. If you already have a voucher > > > locally, you do not need BRSKI for voucher signalling. IMHO, you still > > > want BRSKI (instead of just RFC7030) because of the proxy and the > enrolment telemetry. > > > > > > > > > > > > This just leaves the whole painfull question Michael brings up: > > > > > > > > > > > > "how the heck do we get vouchers onto devices in the real world" ? > > > > > > This is IMHO where everybodies favourite options for managing "offline > > > vouchers" come into play. There are a lot of vendor solutions where > > > you feed those nodes information such as vouchers via USB sticks, or > > > temporarily connected cellphones to the pledge. > > > > > > > > > > > > I think those solutions are not ideal because they do introduce > > > another new "touch" to the pledge. But there are also simply a lot of > > > options how to get the voucher into the registrar without having to > > > use an online BRSKI-MASA connection. And then you just need to send > > > the voucher from the registrar to the pledge using BRSKI: No new > > > "touch" on the pledge, no BRSKI-MASA connection! > > > > > > > > > > > > The BRSKI document does allude to these options but does not > > > necessarily detail them well enough for every uninitiated reader to > > > understand the options. Followup documents refining individual > > > interesting workflows would certainly be useful IMHO (contributor, not WG > chair hat on). > > > > > > > > > > > > > > > > > > Cheers > > > > > > Toerless > > > > > > > > > > > > > > > > > > On Sat, Jul 07, 2018 at 02:58:52PM -0400, Michael Richardson wrote: > > > > > > > > > > > > > > Anoop Kumar Pandey < < <mailto:[email protected]> mailto:[email protected]> > <mailto:[email protected]> [email protected]> wrote: > > > > > > > > When a device is purchased in real world, usually an invoice > > > > is > > > issued in the > > > > > > > > name of the purchaser with stamp of vendor/manufacturer. > > > > > > > > > > > > > > > I propose that similarly, a digital invoice can be issued > > > > which will > > > contain > > > > > > > > the public key(s) of the <domain owner(s)/JRC(s)> and > > > > digitally > > > signed by the > > > > > > > > manufacturer. The digital invoice may be embedded in the > > > > pledge > > > along with > > > > > > > > the IDevID. > > > > > > > > > > > > > > That's an interesting idea, perhaps you could write it up in the > > > > form > > > > > > > of an Internet-Draft? Then I could make sure that I fully > > > > understand > > > > > > > your proposal. > > > > > > > > > > > > > > It seems very difficult to make digitally signed invoices occur in > > > > the > > > > > > > real world, given the constrained of the supply chain. Still, BRSKI > > > > > > > makes provisions for higher security if the supply chain is integrated. > > > > > > > > > > > > > > I once proposed something similar using signed certficates: > > > > > > > > > > > > > > > > > > <https://mailarchive.ietf.org/arch/msg/6tisch-security/2kObJLkLlhuI- > > > > HU9> > > > <https://mailarchive.ietf.org/arch/msg/6tisch-security/2kObJLkLlhuI-HU9> > https://mailarchive.ietf.org/arch/msg/6tisch-security/2kObJLkLlhuI-HU9 > > > > > > > s5yqfRm0n00 > > > > > > > > > > > > > > In effect, the voucher artifact that we created in RFC8366 replaces > > > > > > > these certificates with purpose built signed artifacts that > > > > expresses > > > > > > > what the invoice attempts to express. > > > > > > > > > > > > > > > When a pledge starts the registration process, it will present > > > > the > > > digital > > > > > > > > invoice along with IDevID. The JRC can verify the digital > > > > signature > > > of the > > > > > > > > manufacturer on the digital invoice and sent a signed note of > > > acceptance to > > > > > > > > the pledge. The pledge can verify the signed note using the > > > > public > > > key(s) > > > > > > > > mentioned in the digital invoice, thereby verifying its true > owner. > > > > > > > > > > > > > > A pledge which has sat in a warehouse for a year before being sold > > > > to > > > > > > > an owner will not have the invoice on it yet. That's okay, because > > > > > > > the invoice, being digitally signed, could be retrieved from another > > > > > > > place, and that's effectively what the BRSKI-MASA protocol *does*. > > > > > > > > > > > > > > If the invoice needs to be loaded into the Pledge via a > > > > > > > secure-out-of-band mechanism, (i.e. during the manufacturing > > > > process), > > > > > > > then the Pledge could also be fully configured, and could include a > > > > > > > simple PSK too. This is the approach which is being used in > > > draft-ietf-6tisch-minimal-security. > > > > > > > > > > > > > > Ultimately, it's not the JRC which is suspicious of who the Pledge's > > > > > > > owner is, it's the Pledge which does not know who owns it. > > > > > > > > > > > > > > > This process with eliminate all the communication overhead > > > > with MASA > > > and > > > > > > > > multiple level verification (voucher request, voucher, > > > > telemetry etc > > > at > > > > > > > > JRC/MASA/Pledge). > > > > > > > > > > > > > > Yes, it does, at the cost of making every device in the warehouse > > > > unique > > > to a > > > > > > > specific customer. If I may make an analogy to distribution of movies, > > > > > > > you are suggesting that netflix go back to mailing DVDs to people. > > > > > > > > > > > > > > > From security point of view: Given that the digital invoice is > > > digitally > > > > > > > > signed by manufacturer, the public key of domain owner > > > > embedded in > > > the > > > > > > > > digital invoice can???t be changed, otherwise verification of > > > digital signature > > > > > > > > of manufacturer at JRC end will fail. > > > > > > > > > > > > > > > Requesting you to give your comments as it will simplify the > > > protocol. > > > > > > > > > > > > > > > P.S.: As you had earlier mentioned ???On resale, the device > > > > should > > > be put > > > > > > > > through a factory reset to clear things. The MASA will have to > > > > be > > > willing to > > > > > > > > issue a new voucher to the new domain owner..???; here also, > > > manufacturer may > > > > > > > > issue a new digital invoice in case of resale. > > > > > > > > > > > > > > yes, that's true. But, since you said that the invoice is in the > > > > > > > Pledge, the manufacturer would have to take the device back to do that. > > > > > > > > > > > > > > The reason for all the JRC,MASA etc, is so that we do not need to > > > > have > > > > > > > the manufacturer touch the device a second time. > > > > > > > > > > > > > > -- > > > > > > > ] Never tell me the odds! | ipv6 mesh > > > networks [ > > > > > > > ] Michael Richardson, Sandelman Software Works | network > > > architect [ > > > > > > > ] < <mailto:[email protected]> mailto:[email protected]> > <mailto:[email protected]> [email protected] > > > < <http://www.sandelman.ca/> http://www.sandelman.ca/> > <http://www.sandelman.ca/> http://www.sandelman.ca/ | ruby on rails > > > [ > > > > > > > > > > > > > > > > > > > > > -- > > > > > > > Michael Richardson < < <mailto:[email protected]> > mailto:[email protected]> > > > <mailto:[email protected]> [email protected]>, Sandelman Software > Works > > > > > > > -= IPv6 IoT consulting =- > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > Anima mailing list > > > > > > > < <mailto:[email protected]> mailto:[email protected]> > <mailto:[email protected]> [email protected] > > > > > > > < <https://www.ietf.org/mailman/listinfo/anima> > https://www.ietf.org/mailman/listinfo/anima> > > > <https://www.ietf.org/mailman/listinfo/anima> > https://www.ietf.org/mailman/listinfo/anima > > > > > > > > > > > > > > > > > > -- > > > > > > --- > > > > > > < <mailto:[email protected]> mailto:[email protected]> <mailto:[email protected]> > [email protected] > > > > > > > > > ---------------------------------------------------------------------- > > > --------------------------------------------------------- > > > [ C-DAC is on Social-Media too. Kindly follow us at: > > > Facebook: <https://www.facebook.com/CDACINDIA> > 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. > > > ---------------------------------------------------------------------- > > > --------------------------------------------------------- > > > > > > > -- > > --- > > <mailto:[email protected]> [email protected] > > > ------------------------------------------------------------------------------------------------------------------------------- > [ 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. > ------------------------------------------------------------------------------------------------------------------------------- > -- --- [email protected] _______________________________________________ Anima mailing list [email protected] https://www.ietf.org/mailman/listinfo/anima
