Subject: [Anima] Revision of scope of MASA in the BRSKI - Reg

From: "Anoop Kumar Pandey" <[email-masked]>
Date: Fri, 6 Jul 2018 12:38:48 +0530

Hi Michael,

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

This process with eliminate all the communication overhead with MASA and
multiple level verification (voucher request, voucher, telemetry etc at
JRC/MASA/Pledge).

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

Regards,
Anoop Kumar Pandey  

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

---

From: Michael Richardson <[email-masked]>
Date: Sat, 07 Jul 2018 14:58:52 -0400

Anoop Kumar Pandey <[email-masked]> 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.

    > multiple level verification (voucher request, voucher, telemetry etc at

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.

    > digital invoice can’t be changed, otherwise verification of digital signature
    > of manufacturer at JRC end will fail.

    > 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  [
]     [email-masked]  http://www.sandelman.ca/        |   ruby on rails    [

--
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-

---

From: Toerless Eckert <[email-masked]>
Date: Tue, 10 Jul 2018 08:29:56 +0200

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:
>     > digital invoice can???t be changed, otherwise verification of digital signature
>     > P.S.: As you had earlier mentioned ???On resale, the device should be put
>     > issue a new voucher to the new domain owner..???; here also, manufacturer may

> _______________________________________________
> Anima mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/anima

-- 
---
[email-masked]

---

From: Eliot Lear <[email-masked]>
Date: Tue, 10 Jul 2018 08:43:30 +0200

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

---

From: "Anoop Kumar Pandey" <[email-masked]>
Date: Tue, 10 Jul 2018 12:44:45 +0530

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. 

Once pledge and JRC have verified each other, enrolment can go on using EST.
I want to eliminate the communication overhead or MASA itself.

Toerless>I think those solutions are not ideal because they do introduce
another new "touch" to the pledge.

Anyway manufacturer is installing an IDevID, they can also install a digital
invoice (or voucher). 

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.

@Michael: You mentioned

"Yes, it does, at the cost of making every device in the warehouse unique to
a

> you are suggesting that netflix go back to mailing DVDs to people."

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.

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.

Regards,

Anoop

-----Original Message-----
From: Toerless Eckert [mailto:[email-masked]] 
Sent: 10 July 2018 12:00
To: Michael Richardson <[email-masked]>
Cc: Anoop Kumar Pandey <[email-masked]>; [email-masked]
Subject: Re: [Anima] Revision of scope of MASA in the BRSKI - Reg

Anoop:

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 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-masked]> [email-masked]> wrote:

>     > I propose that similarly, a digital invoice can be issued which will
contain

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

>  <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

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

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

> ]      <mailto:[email-masked]> [email-masked]
<http://www.sandelman.ca/> http://www.sandelman.ca/        |   ruby on rails
[

> Michael Richardson < <mailto:[email-masked]>
[email-masked]>, Sandelman Software Works  

 

>  <mailto:[email-masked]> [email-masked]

>  <https://www.ietf.org/mailman/listinfo/anima>

--

---

 <mailto:[email-masked]> [email-masked]

---

From: 'Toerless Eckert' <[email-masked]>
Date: Tue, 10 Jul 2018 10:16:34 +0200

> 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]

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

> Anyway manufacturer is installing an IDevID, they can also install a digital

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.

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

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

> Pledge's owner is, it's the Pledge which does not know who owns it."
>  
> 

Agreed. And we have an object that does this, its called the voucher.

Cheers
    Toerless

-- 
---
[email-masked]

---

From: Toerless Eckert <[email-masked]>
Date: Tue, 10 Jul 2018 10:35:28 +0200

Thanks Eliot

Very interesting, but can you explain why you think this is in the
same ballpark as the issue Anoop raised ?

More inline.

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

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

>     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

Great.

Cheers
    Toerless

-- 
---
[email-masked]

---

From: "Anoop Kumar Pandey" <[email-masked]>
Date: Tue, 10 Jul 2018 14:30:12 +0530

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). That's why I
proposed use of digital signature and later verification to establish the
identity of both JRC and Pledge.

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.

Toerless> 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".

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. 

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.

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.

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

Regards,

Anoop

-----Original Message-----
From: 'Toerless Eckert' [mailto:[email-masked]] 
Sent: 10 July 2018 13:47
To: Anoop Kumar Pandey <[email-masked]>
Cc: 'Michael Richardson' <[email-masked]>; [email-masked]
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.

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

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]

> 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

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

> 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".

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. 

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.

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

Cheers

    Toerless

> From: Toerless Eckert [ <mailto:[email-masked]> mailto:[email-masked]]

> To: Michael Richardson < <mailto:[email-masked]>
[email-masked]>

> Cc: Anoop Kumar Pandey < <mailto:[email-masked]> [email-masked]>;
<mailto:[email-masked]> [email-masked]

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

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

> 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!

> understand the options. Followup documents refining individual 

> interesting workflows would certainly be useful IMHO (contributor, not WG
chair hat on).

> > Anoop Kumar Pandey < < <mailto:[email-masked]> mailto:[email-masked]>
<mailto:[email-masked]> [email-masked]> wrote:

> >     > When a device is purchased in real world, usually an invoice 

> > is

> issued in the

> >     > I propose that similarly, a digital invoice can be issued 

> > which will

> >     > 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

> > 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

> > It seems very difficult to make digitally signed invoices occur in 

> > the

> > <https://mailarchive.ietf.org/arch/msg/6tisch-security/2kObJLkLlhuI-

> > HU9>

> > these certificates with purpose built signed artifacts that 

> > expresses

> >     > When a pledge starts the registration process, it will present 

> > the

> >     > 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)

> > A pledge which has sat in a warehouse for a year before being sold 

> > to

> > secure-out-of-band mechanism, (i.e. during the manufacturing 

> > process),

> >     > This process with eliminate all the communication overhead 

> > with MASA

> and

> >     > multiple level verification (voucher request, voucher, 

> > telemetry etc

> at

> > Yes, it does, at the cost of making every device in the warehouse 

> > unique

> to a

> >     > 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

> >     > 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

> > The reason for all the JRC,MASA etc, is so that we do not need to 

> > have

> > ]               Never tell me the odds!                 | ipv6 mesh

> networks [

> > ]   Michael Richardson, Sandelman Software Works        | network

> architect  [

> > ]      < <mailto:[email-masked]> mailto:[email-masked]>
<mailto:[email-masked]> [email-masked]

> < <http://www.sandelman.ca/> http://www.sandelman.ca/>

> > Michael Richardson < < <mailto:[email-masked]>
mailto:[email-masked]>

>  <mailto:[email-masked]> [email-masked]>, Sandelman Software
Works

> >  < <mailto:[email-masked]> mailto:[email-masked]>

> >  < <https://www.ietf.org/mailman/listinfo/anima>
https://www.ietf.org/mailman/listinfo/anima>

>  < <mailto:[email-masked]> mailto:[email-masked]>  <mailto:[email-masked]>
[email-masked]

> ----------------------------------------------------------------------

> ---------------------------------------------------------

> Facebook:  <https://www.facebook.com/CDACINDIA>
https://www.facebook.com/CDACINDIA & Twitter: @cdacindia ]

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

> ----------------------------------------------------------------------

> ---------------------------------------------------------

--

---

---

From: "Anoop Kumar Pandey" <[email-masked]>
Date: Tue, 10 Jul 2018 14:34:11 +0530

I shall go through those RFCs that you have mentioned and get back to you. If you have used similar artefacts earlier, may it be revived. Thank you.

-----Original Message-----
From: Michael Richardson [mailto:[email-masked]] 
Sent: 08 July 2018 00:29
To: Anoop Kumar Pandey <[email-masked]>
Cc: [email-masked]
Subject: Re: [Anima] Revision of scope of MASA in the BRSKI - Reg

    > manufacturer. The digital invoice may be embedded in the pledge along with

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.

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.

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

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

--
Michael Richardson <[email-masked]>, Sandelman Software Works  -= IPv6 IoT consulting =-

---

From: Eliot Lear <[email-masked]>
Date: Tue, 10 Jul 2018 12:08:21 +0200

Hi Toerless,

> same ballpark as the issue Anoop raised ?

Yes, the reason I mentioned this is that it seems like we may want some
additional authentication mechanism, such as proof of knowledge *on top*
of the voucher model – in some cases.  This might involve labeling/BoM
aspects.  Also, where the MASA lives is an interesting question.  From
the AN perspective, at least to me, what is important is that the
mechanism be tightly bound in terms of what code needs to be written,
maybe with a few compile-time options.
> the registrar to passively analyze/observe that side-channel.

Yes, that is an argument for documentation, and maybe some authorization.

> pledge ? If not, then i didn't understand this bullet point.

Yes.
> away. BRSKI double zero (with a license to kill) ?  ;-))

Well, that is the work to be done.  Someone else should name the
solution, given how good I am at naming.
Eliot

---

From: 'Toerless Eckert' <[email-masked]>
Date: Tue, 10 Jul 2018 12:19:46 +0200

On Tue, Jul 10, 2018 at 02:30:12PM +0530, Anoop Kumar Pandey wrote:
> 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.

> Certificate is just a container for public key along with other meta data.

Right. And that meta data makes the crucial difference.

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

> 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

-- 
---
[email-masked]

---

From: Michael Richardson <[email-masked]>
Date: Thu, 12 Jul 2018 11:12:29 -0400

> and even resetting the device won't get you to the right network.

I don't understand how the "manufacturer" can have a desire ("the pledge
avoid joining a network ...") that is different from the MASA's desire.

The MASA *is* the expression manufacturer's desire.
If the manufacturer has sales channel information that indicates the Pledge
is on the wrong network, it should not issue a voucher.

So the situation you describe makes no sense to me.

---

From: Eliot Lear <[email-masked]>
Date: Thu, 12 Jul 2018 18:37:34 +0200

The problem is that the manufacturer doesn't have enough context to make
decisions as to which network to join.  That is the challenge.

---

From: "Owen Friel (ofriel)" <[email-masked]>
Date: Fri, 13 Jul 2018 09:26:31 +0000

I think its more accurate to state:

“What a CUSTOMER 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.” E.g. I plug in a wi-fi device and it connects to the SSID of the company on the floor below me.

The MASA cannot help with this unless there is complex sales channel integration and the MASA explicitly knows in advance exactly what network each pledge will be connecting to. A potential option is to also require the registrar to provide some proof of ownership to the MASA in the VoucherRequest.

From: Anima <[email-masked]> On Behalf Of Eliot Lear
Sent: Thursday 12 July 2018 17:38
To: Michael Richardson <[email-masked]>; [email-masked]
Subject: Re: [Anima] Revision of scope of MASA in the BRSKI - Reg

The problem is that the manufacturer doesn't have enough context to make decisions as to which network to join.  That is the challenge.

Anima mailing list

[email-masked]<mailto:[email-masked]>

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 14 Jul 2018 11:34:21 +1200

> “What a CUSTOMER 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 net…

That is so far outside the scope of the autonomic networking infrastructure
application of BRSKI that I don't see why we'd even mention it. It's a case
that definitely needs to fail hard in the autonomic context.

If we want to extend the scope of BRSKI to cover BYOD on insecure WiFi, I
think that's for some other WG.

   Brian

---

From: Eliot Lear <[email-masked]>
Date: Sat, 14 Jul 2018 16:47:04 +0200

Brian, is it your contention that 802.11 is beyond the scope of
autonomic computing?

---

From: Brian E Carpenter <[email-masked]>
Date: Sun, 15 Jul 2018 03:20:20 +1200

> Brian, is it your contention that 802.11 is beyond the scope of

No, of course not. But autonomic nodes aren't supposed to connect
to any old WiFi they happen to find; that's exactly the case where
secure bootstrap needs to fail. If they connect to a network on
which there's a registrar that knows nothing about them,
it won't authorize them to join the ACP.

"The domain registrar authenticates the pledge, makes authorization
decisions,..."

In Figure 3, I guess authorization is the tiny item "[accept device?]".

BRSKI is defined in a nicely general way, but in an AN it's
the domain registrar's job to decide who's allowed in.
Actually there seems to be a glitch in the text on this.
We find:

> 5.2.  Pledge Requests Voucher from the Registrar
>    ...
>    ...The registrar performs authorization as
>    detailed in [[EDNOTE: UNRESOLVED.  See Appendix D "Pledge
>    Authorization"]]. 

but that leads nowhere that I can find. BRSKI authors, please comment.

   Brian

---

From: Toerless Eckert <[email-masked]>
Date: Sun, 15 Jul 2018 09:19:28 +0200

Owen,

I've associated draft-friel-brski-over-802dot11 to anima so folks
will see it in data tracker. Next time post new work for a particular
WG with draft-<group>-<friel>-<whatever>, that will make it happen
automatically.

2.1.1.1) There is no need to bother the MASA with sales
integration just so that the owner will know whether or not
it owns a particular device. Any protocol from the manufacturer/reseller
to the owner will suffice.

I recommend carrier pidgeons with USB sticks trained to insert them into
a USB slot releasing a food portion. Great protection against against
unrecognize NSA interception of the channel especially for vendors
products on the NSA shortlist ;-))

Kidding aside: A standard protocol for sales information disemination
would be great, and given how its for bootstrap automation it would
be fine for ANIMA. I would jus resist of mixing it with BRSKI/MASA
unless there is clear evidence of not keeping it modular. Especially
given how it cold come from the reseller, and nothe vendor.

2.1.1.2) This read a bit confused. I think it should mention
two methods: One is the aove mentioned to know what you own - independent
of MASA (yor last sentence in 2.1.1.2 confused this option with the
MASA). The other option is just to try the MASA in the absence
of better information. BUT: If you only try the MASA, you should
only do this automatically if you do know the MASA has sales
integation. Otherwise you better include a manual checkpoint before
enrollment.

2.1.2) This section is a bit unmotivated even though its part of the
best solution, but that solution requires more details than just WiFi.

Aka: You want to allow announcement (using any of the options
you specified) of open access SSID that allow to connect to cloud-registrars.
These do not even have to be free internet access. Ideally we would
think about an unencrypted channel to the cloud registrar that
relies only on authenticated but unencrypted messages. That way
the owner of the AP can veryify and constrict communications
to only cloud-registrar-enrollment so that this access is not
as a side-channel to gain full internet access. TLS 1.2 still allows
zero-encryption, that would be the easiest option. TLS 1.3 removed it *sigh*.

Note also that we have not defined cloud-registrar behavior. I
think Eliot wold jus like to add something like WiFi SSID to
vouchers, but i would rather like to see it as a separate
"next-step after enrolment" message

Cheers
    Toerless

---

From: Eliot Lear <[email-masked]>
Date: Sun, 15 Jul 2018 09:38:47 +0200

Hi Toerless,

> "next-step after enrolment" message

There is an ordering problem with 802.11 in particular.  In order to get
the voucher one has to have network connectivity.  In order to have
network connectivity, one needs to be authenticated (e.g., having
received the voucher).  An EAP method seems like a good way to break
that logjam, especially in environments where EAP is already prevalent,
and TEAP has many of the characteristics that are already amenable to
BRSKI.  As to SSID selection, the principle issue is some sort of proof
of ownership to the device.  A blind acceptance solely by a MASA is what
causes our issue.  If we can accept that problem statement, then we have
multiple paths we can take to avoid a deadlock.

There are a few constraints:

  * In an environment with many SSIDs advertised, one doesn't want to
    simply round robin, due to power consumption.  Some sort of shortcut
    is desirable.
  * The discovery mechanism cannot be "chatty".  This is what Stewart
    Cheshire calls the "Stadium Problem".  That is not to say that
    devices must be entirely quiescent all the time.

Finding the right balance here is the trick.

Eliot

---

From: Toerless Eckert <[email-masked]>
Date: Sun, 15 Jul 2018 19:33:34 +0200

Eliot:

I think you're trying this type of bootstrap:

https://en.wikipedia.org/wiki/M%C3%BCnchhausen_trilemma#/media/File:Muenchhausen_Herrfurth_7_500x789.jpg

The way to IMHO unconfuse this is to separate out the discussion
about how to get the voucher, and if at all, how to signal the right
SSID to a pledge.

1. A pledge can either try to find his owners
AP/SSID and hope that if it gets connected to another AP/owner in before,
then it will get rejected.  That rejection could logically be done
in two ways:

a) cooperatively by those other owners knowing what they own
   and rejecting anything else. Knowing what they own could have
   a standards protocol but IMHO it should be different from MASA
   because it could come from a reseller, not the manufacturer
   (because the MASA has no sales integration).

b) Some form of sales integration on the MASA so that it would reject
   non-owners. We did not talk about those schemes so far in ANIMA,
   IMHO the most simple sales integration is if there is a protocol
   by which a reseller could indicate to the MASA who owns a particular
   pledge. This transaction would then happen from the vendor as soon
   as it sold the pledge (and knows its serial number). The customer
   would need to provide once its trust anchors to the reseller,
   so they could be passed to the manufacturer by the reseller whenever
   this customer buys new pledges. The reseller could also guarantee
   any form of anonymity required, aka: manufacturer would not know
   who owns the trust anchors (paranoid customers may need to generate
   a bunch of trust anchors so they can not be identified by correlation
   over the set of pledges with the same trust anchor).

Both 1.a and 1.b are trial and error wrt. finding the right SSID. Once
can just limit search to those SSIDs that do support BRSKI and those
who don't by coming up with appropriate network announcements, but
those will not be able to help identifying the right owner.

2. Open but potentially constrained WiFi access allowing to access a
cloud-registrar. Constrained in so far that the AP operator only
support passing through BRSKI but not anything else (to avoid
providing a free internet service).

In this option, a case can be made to provide SSID information
to the pledge during the voucher stage or after the enrolment stage.
The argument for providing it during the voucher stage is that the
pledge could earlier break the connection and take the third-party AP
and manufacturer cloud registrar out of the picture.

The main question is whether we should try to get the SSID passed
to the pledge in an encrypted fashion so that the manufacturer MASA
can not decrypt it. Of course, if you trust the manufacturers pledge,
you kinda trust the manufacturer, but if i was running a MASA in
a company of a country with perpass agencies, then i would like to
define security procedures that would do its best to ensure that
customers privacy is maximized.

Cheers
    Toerless

-- 
---
[email-masked]

---

From: "Owen Friel (ofriel)" <[email-masked]>
Date: Mon, 16 Jul 2018 20:01:23 +0000

-----Original Message-----
From: Brian E Carpenter <[email-masked]> 
Sent: Saturday 14 July 2018 16:20
To: Eliot Lear <[email-masked]>; Owen Friel (ofriel) <[email-masked]>; Eliot Lear <[email-masked]>; Michael Richardson <[email-masked]>; [email-masked]
Subject: Re: [Anima] Revision of scope of MASA in the BRSKI - Reg

> Brian, is it your contention that 802.11 is beyond the scope of 

No, of course not. But autonomic nodes aren't supposed to connect to any old WiFi they happen to find; that's exactly the case where secure bootstrap needs to fail. If they connect to a network on which there's a registrar that knows nothing about them, it won't authorize them to join the ACP.
[ofriel] Are we making the assumption that all networks are well behaved and a Registrar will actually reject devices it does not explicitly own? What about a rogue network where the operator does not own the connecting devices but the registrar accepts them anyway? That is the issue here.

"The domain registrar authenticates the pledge, makes authorization decisions,..."

BRSKI is defined in a nicely general way, but in an AN it's the domain registrar's job to decide who's allowed in.
Actually there seems to be a glitch in the text on this.

   Brian

>> That is so far outside the scope of the autonomic networking 
>> infrastructure application of BRSKI that I don't see why we'd even 
>> mention it. It's a case that definitely needs to fail hard in the autonomic context.
>>
>> If we want to extend the scope of BRSKI to cover BYOD on insecure 
>> WiFi, I think that's for some other WG.
>>
>>    Brian
>>

---

From: Toerless Eckert <[email-masked]>
Date: Tue, 17 Jul 2018 01:29:59 +0200

On Mon, Jul 16, 2018 at 08:01:23PM +0000, Owen Friel (ofriel) wrote:
[ofriel] Are we making the assumption that all networks are well behaved and a Registrar will actually reject devices it does not explicitly own? What about a rogue network where the operator does not own the connecting devices but the registrar accepts them anyway? That is the issue here.

I think Brians comment was abouut fixing BRSKI to re-include
text we lost in rev -08. The details of that text are not too
relevant except IMHO giving some examples, as it did in -07.

For the benefit of BRSKI becoming RFC, i would like to really
only ask the minimum necessary to fix this piece, but not draw it into the
larger discussion here related to your draft.

As you point out, we can never be sure that rogue  domains are not
simply accepting devices they do not own. But we can build secure
pledges by making MASA more secure and not hand out vouchers without
more than the minimum necessary logging. That is not saying that
the MASA should do more than just logging for every device, for
example if the MASA supports both lightbulbs and core routers, it's
clear that the MASA policies could be different.

And this "sales" integration could be simply that the MASA requires
some simple identity for a domains registrar. E.g: verify some
domains email, credit-card number, ... something easily
automated and good enough to track back the bad guy with enough
likelihood.

Cheers
    Toerless

---

From: "Owen Friel (ofriel)" <[email-masked]>
Date: Tue, 17 Jul 2018 00:55:23 +0000

-----Original Message-----
From: Anima <[email-masked]> On Behalf Of Toerless Eckert
Sent: Tuesday 17 July 2018 00:30
To: Owen Friel (ofriel) <ofriel=[email-masked]>
Cc: Michael Richardson <[email-masked]>; [email-masked]; Eliot Lear <[email-masked]>
Subject: Re: [Anima] Revision of scope of MASA in the BRSKI - Reg

I think Brians comment was abouut fixing BRSKI to re-include text we lost in rev -08. The details of that text are not too relevant except IMHO giving some examples, as it did in -07.

For the benefit of BRSKI becoming RFC, i would like to really only ask the minimum necessary to fix this piece, but not draw it into the larger discussion here related to your draft.
[ofriel] Agreed. I think the point Eliot and I are making is that the BRSKI draft is fine as is (with that edit Brian pointed out) and does not need to explicitly address the Wi-Fi SSID rogue network issue. And its worth pointing out that the BRSKI draft does not preclude building a solution for that rogue network SSID issue either (we have discussed this at length with Max). The draft-friel-brski-over-802dot11 draft starts to touch on some mechanisms for how to address the SSID selection issue, and that is a potential place to start to document possible solutions.

As you point out, we can never be sure that rogue  domains are not simply accepting devices they do not own. But we can build secure pledges by making MASA more secure and not hand out vouchers without more than the minimum necessary logging. That is not saying that the MASA should do more than just logging for every device, for example if the MASA supports both lightbulbs and core routers, it's clear that the MASA policies could be different.

And this "sales" integration could be simply that the MASA requires some simple identity for a domains registrar. E.g: verify some domains email, credit-card number, ... something easily automated and good enough to track back the bad guy with enough likelihood.

Cheers
    Toerless

---

From: "Owen Friel (ofriel)" <[email-masked]>
Date: Tue, 17 Jul 2018 03:26:59 +0000

-----Original Message-----
From: Toerless Eckert <[email-masked]> 
Sent: Sunday 15 July 2018 08:19
To: Owen Friel (ofriel) <[email-masked]>
Cc: Eliot Lear <[email-masked]>; Michael Richardson <[email-masked]>; [email-masked]
Subject: Re: [Anima] Revision of scope of MASA in the BRSKI - Reg

Owen,

I've associated draft-friel-brski-over-802dot11 to anima so folks will see it in data tracker. Next time post new work for a particular WG with draft-<group>-<friel>-<whatever>, that will make it happen automatically.

2.1.1.1) There is no need to bother the MASA with sales integration just so that the owner will know whether or not it owns a particular device. Any protocol from the manufacturer/reseller to the owner will suffice.
[ofriel] The point here isn't for the MASA can tell the owner that he owns the devices, the purpose is for the owner to explicitly claim the devices on the MASA to accomplish your option 1(b) for later in this thread (the thread is very disjointed at this stage):
" b) Some form of sales integration on the MASA so that it would reject non-owners. "
I think we are actually talking about exactly the same thing here, if that's not clear in the draft text, we can certainly clarify.

I recommend carrier pidgeons with USB sticks trained to insert them into a USB slot releasing a food portion. Great protection against against unrecognize NSA interception of the channel especially for vendors products on the NSA shortlist ;-))

Kidding aside: A standard protocol for sales information disemination would be great, and given how its for bootstrap automation it would be fine for ANIMA. I would jus resist of mixing it with BRSKI/MASA unless there is clear evidence of not keeping it modular. Especially given how it cold come from the reseller, and nothe vendor.

2.1.1.2) This read a bit confused. I think it should mention two methods: One is the aove mentioned to know what you own - independent of MASA (yor last sentence in 2.1.1.2 confused this option with the MASA). The other option is just to try the MASA in the absence of better information. BUT: If you only try the MASA, you should only do this automatically if you do know the MASA has sales integation. Otherwise you better include a manual checkpoint before enrollment.
[ofriel] Sales integration with the MASA (where sales integration means that the MASA explicitly has a map of devices to owners) is not required here at all. One of the core features of MASA is that it audit logs all issued vouchers and the vouched registrar identity. If a network operator knows the identity of a device they own, but that device has not connected to their network, the operator can query the MASA audit logs to see if that missing device has been vouched for on a different network.

E.g. I own serial#abc123 signed by AcmeCA, I can see it powered up and apparently live on the desk beside me, but my Registrar/AAA doesn't see it. My Registrar /AAA could query MASA for logs pertaining to serial#abc123 and see that a voucher was issued for that device against registrar.the-company-on-the-floor-above-me.com. So this does not prevent my device from connecting to the wrong network, but it does allow me to detect it after the fact.

2.1.2) This section is a bit unmotivated even though its part of the best solution, but that solution requires more details than just WiFi.

Aka: You want to allow announcement (using any of the options you specified) of open access SSID that allow to connect to cloud-registrars.
These do not even have to be free internet access. Ideally we would think about an unencrypted channel to the cloud registrar that relies only on authenticated but unencrypted messages. That way the owner of the AP can veryify and constrict communications to only cloud-registrar-enrollment so that this access is not as a side-channel to gain full internet access. TLS 1.2 still allows zero-encryption, that would be the easiest option. TLS 1.3 removed it *sigh*.

Note also that we have not defined cloud-registrar behavior. I think Eliot wold jus like to add something like WiFi SSID to vouchers, but i would rather like to see it as a separate "next-step after enrolment" message

Cheers
    Toerless

---

From: "Owen Friel (ofriel)" <[email-masked]>
Date: Tue, 17 Jul 2018 03:38:05 +0000

-----Original Message-----
From: Toerless Eckert <[email-masked]> 
Sent: Sunday 15 July 2018 18:34
To: Eliot Lear <[email-masked]>
Cc: Owen Friel (ofriel) <[email-masked]>; Michael Richardson <[email-masked]>; [email-masked]
Subject: Re: [Anima] Revision of scope of MASA in the BRSKI - Reg

Eliot:

The way to IMHO unconfuse this is to separate out the discussion about how to get the voucher, and if at all, how to signal the right SSID to a pledge.
[ofriel] If the pledge is connecting to an 802.1x network behind an SSID, I don't think there is any need at all to explicitly tell the pledge the SSID at all. There could be multiple different SSIDs (in theory anyway) connecting to the same 802.1x network, the key thing is that the voucher tells the pledge to trust the EAP server that is it is establishing the TLS connection to. If the EAP connection is trusted, then is doesn't really matter which AP or SSID the pledge used to get there...

1. A pledge can either try to find his owners AP/SSID and hope that if it gets connected to another AP/owner in before, then it will get rejected.  That rejection could logically be done in two ways:

a) cooperatively by those other owners knowing what they own
   and rejecting anything else. 
[ofriel] I don't think we can rely on that.

Knowing what they own could have
   a standards protocol but IMHO it should be different from MASA
   because it could come from a reseller, not the manufacturer
   (because the MASA has no sales integration).

Both 1.a and 1.b are trial and error wrt. finding the right SSID. Once can just limit search to those SSIDs that do support BRSKI and those who don't by coming up with appropriate network announcements, but those will not be able to help identifying the right owner.
[ofriel] Agreed. Simple 802.11u/aq/etc. could reduce the number of SSID candidates, but its still a round robin by the device if it fails to get a voucher when it tried any given SSID candidate.

2. Open but potentially constrained WiFi access allowing to access a cloud-registrar. Constrained in so far that the AP operator only support passing through BRSKI but not anything else (to avoid providing a free internet service).

In this option, a case can be made to provide SSID information to the pledge during the voucher stage or after the enrolment stage.
The argument for providing it during the voucher stage is that the pledge could earlier break the connection and take the third-party AP and manufacturer cloud registrar out of the picture.
[ofriel] If connecting to a cloud-registrar then that pretty much mandates strong sales integration and ownership info on the MASA.

The main question is whether we should try to get the SSID passed to the pledge in an encrypted fashion so that the manufacturer MASA can not decrypt it. Of course, if you trust the manufacturers pledge, you kinda trust the manufacturer, but if i was running a MASA in a company of a country with perpass agencies, then i would like to define security procedures that would do its best to ensure that customers privacy is maximized.
[ofriel] There is an option 3, which is https://tools.ietf.org/html/draft-friel-brski-over-802dot11-01#section-2.1.3. DPP or any similar protocol where proof-of-ownership is required.

Cheers
    Toerless

On Sun, Jul 15, 2018 at 09:38:47AM +0200, Eliot Lear wrote:
> > Note also that we have not defined cloud-registrar behavior. I think 
> > Eliot wold jus like to add something like WiFi SSID to vouchers, but 
> > i would rather like to see it as a separate "next-step after 
> > enrolment" message
> 
> There is an ordering problem with 802.11 in particular.  In order to 
> get the voucher one has to have network connectivity.  In order to 
> have network connectivity, one needs to be authenticated (e.g., having 
> that logjam, especially in environments where EAP is already 
> prevalent, and TEAP has many of the characteristics that are already 
> amenable to BRSKI.  As to SSID selection, the principle issue is some 
> sort of proof of ownership to the device.  A blind acceptance solely 
> by a MASA is what causes our issue.  If we can accept that problem 
> statement, then we have multiple paths we can take to avoid a deadlock.
> 

--
---
[email-masked]

---

From: Toerless Eckert <[email-masked]>
Date: Tue, 17 Jul 2018 05:49:44 +0200

Thanks,

probably better to use the high frequency meeting options we have
this week than extending this thread too much right now. I guess
my highest level point is that i could see benefit in using the wifi
case you folks want to drive to build out document(s) for some
generic pieces we're missing like cloud registrar (BRSI is just a stub IMHO),
and really try to have the wifi doc only do the wifi specific piece - 
and inherit any components we could equally use for non-wifi scenarios from
such shared additional docs.

Cheers
    Toerless

-- 
---
[email-masked]

---

From: Michael Richardson <[email-masked]>
Date: Mon, 16 Jul 2018 23:49:39 -0400

Anoop Kumar Pandey <[email-masked]> wrote:
    > Anyone can present certificate of anyone else (it’s public). That’s
    > why I proposed use of digital signature and later verification to
    > establish the identity of both JRC and Pledge.

Presenting a certificate of another party doesn't work.
TLS and other protocols don't just use a certificate, but they use
the related private key to sign part of the transaction.

---

From: Michael Richardson <[email-masked]>
Date: Mon, 16 Jul 2018 23:51:13 -0400

Eliot Lear <[email-masked]> wrote:
    > The problem is that the manufacturer doesn't have enough context to
    > make decisions as to which network to join. That is the challenge.

So... who knows then?
I'm asking seriously.

You are looking down (like god) with knowledge that apparently isn't in the
network.

So please explain.

    > ----------------------------------------------------
    > Alternatives:

    > ----------------------------------------------------

---

From: Michael Richardson <[email-masked]>
Date: Mon, 16 Jul 2018 23:56:20 -0400

> “What a CUSTOMER 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.”
    > E.g. I plug in a wi-fi device and it connects to the SSID of the
    > company on the floor below me.

Ah!  This I can comprehend.

    > The MASA cannot help with this unless there is complex sales channel
    > integration and the MASA explicitly knows in advance exactly what
    > network each pledge will be connecting to. A potential option is to
    > also require the registrar to provide some proof of ownership to the
    > MASA in the VoucherRequest.

Max, Kent and I discussed the possibility that there would be a QR code in
the packaging that would act as proof of ownership.  What we concluded was
that this would be a protocol on-top-of BRSKI.

Instead of trying to integrate that into BRSKI, what the QR code would do is
permit the Registrar to set up *sales channel integration* with the MASA.
This would be a new extension to the BRSKI-MASA channel.

This requires the MASA to cooperate.  If the vendor doesn't support that,
then the answer is that you bought the wrong product :-)

I hope to start a document on this this summer as part of work I'm
doing to build a secure home gateway for IoT use.

---

From: Michael Richardson <[email-masked]>
Date: Mon, 16 Jul 2018 23:59:05 -0400

Brian E Carpenter <[email-masked]> wrote:
    > mention it. It's a case 

Actually, the only thing lacking is the sales channel integration.
If the MASA knows the intended owner, then everything works.

    > think that's for some other WG.

I don't know if it's for another WG or not, but Owen's document deals with
this... I'm not sure I'd call it "BYOD", exactly... Bring a not-yet-Owned
Device, that you'd like to Own, and get pOwned.  And the WiFi is insecure,
because the device doesn't (yet) have accesss to the secure WiFi.

---

From: Michael Richardson <[email-masked]>
Date: Tue, 17 Jul 2018 00:07:39 -0400

> about how to get the voucher, and if at all, how to signal the right

Yup... please see the work that is occuring in 6tisch.

The technology is 802.15.4, and so the Stadium isn't full of smartphones, but
rather it's a parking garage of intelligent cars, or an industrial setting.

The one-touch (PSK) mechanism that includes the network info:
    https://datatracker.ietf.org/doc/draft-ietf-6tisch-minimal-security/

The zero-touch mechanism that is constrained BRSKI:
    https://datatracker.ietf.org/doc/draft-ietf-6tisch-dtsecurity-zerotouch-join/

The Enhanced Beacon that provides a bit of information as to what network
might be worth joining:
      https://datatracker.ietf.org/doc/draft-richardson-6tisch-enrollment-enhanced-beacon/
      (now adopted. I should post under correct name)

How to pick the PANID is not specified yet.  Mostly the same as picking an
SSID.

---

From: Michael Richardson <[email-masked]>
Date: Tue, 17 Jul 2018 00:49:35 -0400

> simply accepting devices they do not own. But we can build secure

Please explain how this works.
A Registrar that accepts a device that has an audit-only MASA is not
rogue. It's doing exactly the right thing.

I think the problem is that some people think they are going to
sell $100K BFRs with audit-only policies?

    > clear that the MASA policies could be different.

And given the ability to embed different URLs in the IDevID certificate,
I'd want to run two completely different MASA :-)

---

From: Toerless Eckert <[email-masked]>
Date: Tue, 17 Jul 2018 07:24:01 +0200

*arghhh*

Thanks, Michael!

Not sure how i got that permutation bug into my email. Sorry for the confusion.

Cheers
    Toerless

On Tue, Jul 17, 2018 at 12:50:50AM -0400, Michael Richardson wrote:
>     > I've associated draft-friel-brski-over-802dot11 to anima so folks will
>     > see it in data tracker. Next time post new work for a particular WG
>     > with draft-<group>-<friel>-<whatever>, that will make it happen
>     > automatically.
> 
> while draft-group-friel-whatever would work, the tradition is that it
> should be draft-friel-group-whatever :-)
> 
> --

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 17 Jul 2018 23:10:23 +1200

> If the MASA knows the intended owner, then everything works.

Sure. But that is surely out of scope for the purposes of getting
the BRSKI document into the RFC Editor queue, which is what we need
to do next...

> because the device doesn't (yet) have accesss to the secure WiFi.

Indeed. But I really don't see why ANIMA would handle this.

    Brian

---

From: Toerless Eckert <[email-masked]>
Date: Wed, 18 Jul 2018 06:49:29 +0200

> rogue. It's doing exactly the right thing.

You don't legally own such a pledge just because you claim it on a MASA,
but doing so could easily be interpreted to be at least theft of service.

> sell $100K BFRs with audit-only policies?

Bad Feeble Router ? ;-)

> I'd want to run two completely different MASA :-)

And Trust Anchors.  Epecially when you want to ve free to sell off
individual product lines in a large company.

Cheers
    Toerless

---

From: Michael Richardson <[email-masked]>
Date: Wed, 18 Jul 2018 20:22:47 -0400

> but doing so could easily be interpreted to be at least theft of service.

That's an interesting legal concern.
(To address Brian's concern about scope: I want the document to go the
IESG too, but if this is a potential sticking point with the IESG,
then it's better to address it sooner)

    > Bad Feeble Router ? ;-)

Big Fu^WFriendly Router.

    > individual product lines in a large company.

In the non-constrained (CMS/PKCS7) case, one can make the MASA trust anchor
embedded in the pledge as abstract (i.e. with as deep a CA hierarchy) as you
like.  It's only in the COSE case (which isn't in *this* document), that there
are issues with having a signing hierarchy deeper than one level.

So I wrote before that we need an operational document for the domain
registrar and ACP.   Clearly we need operational advice for the manufacturer
as well.  Maybe someone should author a book... "ANIMA for dummies"

---

From: Michael Richardson <[email-masked]>
Date: Wed, 18 Jul 2018 20:29:33 -0400

>> > think that's for some other WG.

    mcr> I don't know if it's for another WG or not, but Owen's document deals
    mcr> with this... I'm not sure I'd call it "BYOD", exactly... Bring a
    mcr> not-yet-Owned Device, that you'd like to Own, and get pOwned.  And
    mcr> the WiFi is insecure, because the device doesn't (yet) have accesss
    mcr> to the secure WiFi. 

    > Indeed. But I really don't see why ANIMA would handle this.

If you say that it's out of scope for bootstrapping-keyinfra, then I agree.

I think that it is in scope for ANIMA to specify a way to build and bootstrap
ACP tunnels over wifi, USB and BTLE (RFC7668).  We want to do this because
it provides a way for devices in cabinet A of a datacenter to find their
partners in adjacent cabinet B. Yes, there might be a 100G fiber between
them... but it might be mis-installed, and/or the lambdas might be wrong,
etc.

---

From: "Anoop Kumar Pandey" <[email-masked]>
Date: Thu, 19 Jul 2018 10:23:02 +0530

>TLS and other protocols don't just use a certificate, but they use the related private key to sign part of the transaction.

" private key to sign ": That's digital signature. In case of TLS only public key is used to encrypt and share the symmetric key which is used in later communication. No digital signature required.

-----Original Message-----
From: Michael Richardson [mailto:[email-masked]] 
Sent: 17 July 2018 09:20
To: Anoop Kumar Pandey <[email-masked]>
Cc: 'Toerless Eckert' <[email-masked]>; [email-masked]
Subject: Re: [Anima] Revision of scope of MASA in the BRSKI - Reg

Presenting a certificate of another party doesn't work.
TLS and other protocols don't just use a certificate, but they use the related private key to sign part of the transaction.

---

From: "Owen Friel (ofriel)" <[email-masked]>
Date: Thu, 19 Jul 2018 23:08:57 +0000

-----Original Message-----
From: Anima <[email-masked]> On Behalf Of Anoop Kumar Pandey
Sent: Thursday 19 July 2018 05:53
To: 'Michael Richardson' <[email-masked]>
Cc: 'Toerless Eckert' <[email-masked]>; [email-masked]
Subject: Re: [Anima] Revision of scope of MASA in the BRSKI - Reg

[ofriel] https://tools.ietf.org/html/rfc5246#section-7.4.8 and https://tools.ietf.org/html/draft-ietf-tls-tls13-28#section-4.4.3 explain how the client uses its cert private key to sign the TLS handshake transcript. If client doesn’t know the private key, it cant generate the CertificateVerify and TLS fails.

---

From: Toerless Eckert <[email-masked]>
Date: Fri, 20 Jul 2018 20:28:12 +0200

> then it's better to address it sooner)

I don't think Brian raised an issue aobut this point. The only new issue
raised was the broken reference to the section about authorizing the pledge by
the domain. See the new github issue i opened.

The audit-only log is IMHO a great new option to explore and see where
it would fall out on the legal side if there is abuse (claims made by 
non-legal owners).

> are issues with having a signing hierarchy deeper than one level.

I think we're in violent agreement.

> as well.  Maybe someone should author a book... "ANIMA for dummies"

Well, this is an OPS WG, so its perfectly fine to elaborate on informational
operational aspects in our document. Even BCP. And if you find a formal
language to express operational processes i bet we could even go standard ;-)

Cheers
    Toerless

-- 
---
[email-masked]

---

From: Michael Richardson <[email-masked]>
Date: Fri, 20 Jul 2018 17:01:08 -0400

Anoop Kumar Pandey <[email-masked]> wrote:
    >> TLS and other protocols don't just use a certificate, but they use the
    >> related private key to sign part of the transaction. 

    > " private key to sign ": That's digital signature. In case of TLS only
    > public key is used to encrypt and share the symmetric key which is used
    > in later communication. No digital signature required.

And, in order to encrypt something "to" the public key, the private key used.

This might help:
https://www.ibm.com/support/knowledgecenter/en/SSFKSJ_7.1.0/com.ibm.mq.doc/sy10670_.htm