Thanks Eliot
Very interesting, but can you explain why you think this is in the
same ballpark as the issue Anoop raised ?
More inline.
On Tue, Jul 10, 2018 at 08:43:30AM +0200, Eliot Lear wrote:
> 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.
Haha. I am not sure you want to mention "interoperability friction"
in a venue whose purpose in life is interoperability (IETF).
We discussed during BRSKI design this aspect, and i think
we can all see good flexiblity reasons for this side-channel, even
without having to blame ineroperability.
The main issue is that it is a side-channel, and if there is any concerns
about BRKI it is the mistrust against manufacturers. SO i would hope that
any use of the side-channel would allow to establish the ability on
the registrar to passively analyze/observe that side-channel.
> * 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.
You mean we have the issue of getting initial 802.11 credentials to the
pledge ? If not, then i didn't understand this bullet point.
> * 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.
Right. BRSKI is called zero-touch, but there is really one touch left:
plugging a network cable into a right network port. With WiFi this can
be automated because selecting the right SSID can be done without
a human touch. I just wonder how we call it when we take one more touch
away. BRSKI double zero (with a license to kill) ? ;-))
> Owen will present something in Montreal that begins the discussion of
> these issues.
Great.
Cheers
Toerless
> 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
> >
>
--
---
t...@cs.fau.de
_______________________________________________
Anima mailing list
Anima@ietf.org
https://www.ietf.org/mailman/listinfo/anima
