Hi Toerless, When we look at this scenario, we should consider several factors:
* The manufacturer is in a position to control both the MASA and the
pledge. That's useful because it means that there is less
interoperability friction if the manufacturer wants to pass
additional parameters between the pledge and the manufacturer, so
long as the registrar doesn't interfere.
* In WiFi we have two additional issues: a device needs to do ANIMA,
but it needs to be authorized in some manner to do so.
* The second issue is one of network selection. There is a need for
the pledge to really *know* that this is The network when 802.11 is
involved. What a manufacturer wants to avoid is a pledge joining a
network where the MASA just does the logging and does no validation,
without any other means to determine that the device is on the
correct network. Otherwise, the pledge (we could call it the
"station" in this context) could simply home to the wrong network,
and even resetting the device won't get you to the right network.
Owen will present something in Montreal that begins the discussion of
these issues.
Eliot
On 10.07.18 08:29, Toerless Eckert wrote:
> 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 <an...@cdac.in> 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-HU9s5yqfRm0n00
>>
>> 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
>> [
>> ] m...@sandelman.ca http://www.sandelman.ca/ | ruby on rails
>> [
>>
>>
>> --
>> Michael Richardson <mcr+i...@sandelman.ca>, Sandelman Software Works
>> -= IPv6 IoT consulting =-
>>
>>
>>
>
>
>> _______________________________________________
>> Anima mailing list
>> Anima@ietf.org
>> https://www.ietf.org/mailman/listinfo/anima
>
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Anima mailing list Anima@ietf.org https://www.ietf.org/mailman/listinfo/anima
