Subject: [Anima] verification of manufacturer in BRSKI

From: Michael Richardson <[email-masked]>
Date: Sun, 18 Feb 2018 19:26:57 -0500

{sorry if this is a duplicate, my draft folder says it did not go out}

Anoop Kumar Pandey <[email-masked]> wrote directly to the draft authors list,
and then gave me permission to share this on the list:
    Anoop> This is in context to the RFC detailing process of enrolling a pledge to a
    Anoop> domain. The major problem with the procedure is that the registrar doesn’t
    Anoop> verify the manufacturer. It simply verifies the voucher and enrols the
    Anoop> pledge. If pledge send a self-defined URL of manufacturer where provision for
    Anoop> issuing fake vouchers is in place, then the registrar can be fooled into
    Anoop> enrolment [assuming the registrar can’t know all the manufacturers
    Anoop> exhaustively] and later exploited from inside the domain. Additionally pledge
    Anoop> and a random manufacturer can also collaborate to do the same.

You raise a number of issues.

So let me name them so that we can discuss them easier, and make sure that I
understand you correctly.
Probably, we need to add some text to the Security Considerations, and I
would welcome your help in crafting that text!

    Anoop> In the similar way a registrar may collaborate with the manufacturer to lure
    Anoop> a device using fake voucher.

    Anoop> How can these problems be tackled?

I agree that the Pledge may point at any Manufacturer (in the form of a MASA)
that it wishes to.   The following identities exist:

1) The Pledge's Identity (PI) in the form an IDevID certificate.
   (It signs the voucher request to the JRC, and the Client side of the TLS
   connection from Pledge to JRC)
2) The Manufacturer's Identity (MI) which signs the IDevID certificate.
3) The MASA Identity (MASA) which signs the voucher.
4) The Join Registrar (JRC) which signs the voucher request to the MASA.
   It also signs the Server side of the TLS connection from Pledge to JRC.
5) The Domain PKI Certificate Authority, which signs the LDevID.

(The MI might be the same as the MASA, but in general the MASA
may be outsourced.  The Pledge SHOULD have a trusted anchor for both,
but it can be designed where it has a manufacturer CA which signs both MASA
and MI certificate)

Each of these in essence represent a private key!
I'd like start by ruling out of bounds for this discussion any scenario where
the attack requires that the private key be leaked, shared or used
incorrectly.  It's not that they can't happen, but rather that it is a
problem of TPMs, etc. and not protocol design.

The Pledge trusts network part works by:
a) MASA signs VOUCHER.
b) VOUCHER lists JRC in pinned-domain-cert.
c) Pledge uses MASA to validate VOUCHER, and therefore validates JRC.
d) JRC can also audit (verify signatures even) the voucher really comes
   from MASA, although unless there is a common CA, it may not be able to
   prove MASA and MI are same entity.

The JRC trusts Pledge part works by:
e) MI signs IDevID.
f) Pledge uses IDevID to identify to JRC.
g) JRC validates IDevID using MI certificate.

Now, to translate what you said:

problem 1.
    Anoop> The major problem with the procedure is that the registrar doesn’t
    Anoop> verify the manufacturer.

To translate, the JRC has no obvious way to verify that the "MI" key belongs
              to the manufacturer that they care about.

You actually hit the major reason this is not a problem when you assume:
   > assuming the registrar can’t know all the manufacturers exhaustively

We assume that in a managed network that the JRC *can* know all the
legitimate manufacturers.  The keys can come from sales channel integration
(via digital "packing slips" perhaps), can be manually loaded by humans, be
scanned from QR codes on the box, etc.  We believe that this is out of scope.

And if the JRC does see a MI that it does not know, then it can ask a human.
That's one reason we made sure that failures to enroll do not cause the
Pledge to never try again with that JRC.  It needs to try again later,
because maybe nobody has answered the "Yes/No" Dialog on the management
station yet.

And of course there is the WebPKI.  We aren't saying that MI keys
(or MASA server TLS keys) MUST be in the WebPKI, but we aren't saying that
they can't be.  That's not a panacea... between ComodoGate type situations
and certificates for "C1SC0" in a hard to distinguish font, many social
engineering attacks could get that "Yes" button pressed.

problem 2.
    Anoop> If pledge send a self-defined URL of manufacturer where provision for
    Anoop> issuing fake vouchers is in place, then the registrar can be fooled into
    Anoop> enrolment [assuming the registrar can’t know all the manufacturers
    Anoop> exhaustively] and later exploited from inside the domain.

The URL of the manufacturer is embedded in the IDevID certificate (section
2.3 defines the extension).  So the Pledge can't create this lie itself, it
requires collaboration with the MI to create an IDevID.  Such an MI can
point to any MASA it wishes, so long as that device can issue vouchers that
the Pledge can validate.

What this means is that JRC always knows the MI that created the Pledge.
If we can solve problem 1, then it's done.

problem 3.
    Anoop> Additionally pledge
    Anoop> and a random manufacturer can also collaborate to do the same.

I don't see how this is the case.  The pledge can only collaborate with
the manufacturer whose IDevID it has.

problem 4.
    Anoop> In the similar way a registrar may collaborate with the manufacturer to lure
    Anoop> a device using fake voucher.

The Pledge will only trust a voucher signed by MASA.
Any signature from a different entity will be rejected by the Pledge.
So a fake voucher is not possible.
Any voucher created by the real MASA is, by definition, not a fake voucher.
Can you explain this scenario clearer?
Or explain what text we need to change to clear up the mis-understanding?

--
]               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: Brian E Carpenter <[email-masked]>
Date: Mon, 19 Feb 2018 16:11:49 +1300

> scanned from QR codes on the box, etc.  We believe that this is out of scope.

Yes, but please ensure that the draft states this assumption and states
that how it is achieved is out of scope.

Also note the air-gap case described in section 6.3 bullet 3. That's listed
as a security reduction, but if your threat model considers rogue MASAs
to be a real risk, pre-loading vouchers and then totally disconnecting from
the Internet might even be considered a security improvement.

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

---

From: "Anoop Kumar Pandey" <[email-masked]>
Date: Mon, 19 Feb 2018 14:22:13 +0530

Dear Author,

           I am further expanding my query and raising concern over your response. The Problem Nos. are same as in the trailing reply.:

Problem 1: 
Response: " We assume that in a managed network that the JRC *can* know all the legitimate manufacturers."

May be!! But practically may not be possible. Manufacturers keep adding and also getting out of business. Tracking each MI is difficult.

Response: " The keys can come from sales channel integration (via digital "packing slips" perhaps), can be manually loaded by humans, be scanned from QR codes on the box, etc.  We believe that this is out of scope.

And if the JRC does see a MI that it does not know, then it can ask a human."

If manual intervention is required, then it is no longer “Automated BRSKI”. Humans can anyway observer and add/install new device.

Problem 2: 

Response: The URL of the manufacturer is embedded in the IDevID certificate (section 2.3 defines the extension).  So the Pledge can't create this lie itself, it requires collaboration with the MI to create an IDevID.

I had asked the same thing. If pledge collaborates with a rouge MI [given Problem 1 is not solved], the domain can easily be invaded.

Problem 3: 
Response: The pledge can only collaborate with the manufacturer whose IDevID it has.

Agreed. Then this problem reduces to Problem 2 where Pledge and MI can collaborate to fool JRC

Problem 4: 

Response: The Pledge will only trust a voucher signed by MASA. Any signature from a different entity will be rejected by the Pledge. So a fake voucher is not possible.

I only raised concern that there is no way to detect if MASA and JRC have collaborated to lure the pledge into a malicious domain unless the MASA certificate and IDevID certificate have common Root Certifying authority.

Regards,

Anoop

-----Original Message-----
From: Michael Richardson [mailto:[email-masked]] 
Sent: 19 February 2018 05:57
To: [email-masked]
Cc: Anoop Kumar Pandey <[email-masked]>
Subject: verification of manufacturer in BRSKI

Anoop Kumar Pandey < <mailto:[email-masked]> [email-masked]> wrote directly to the draft authors list, and then gave me permission to share this on the list:

So let me name them so that we can discuss them easier, and make sure that I understand you correctly.

Probably, we need to add some text to the Security Considerations, and I would welcome your help in crafting that text!

(The MI might be the same as the MASA, but in general the MASA may be outsourced.  The Pledge SHOULD have a trusted anchor for both, but it can be designed where it has a manufacturer CA which signs both MASA and MI certificate)

I'd like start by ruling out of bounds for this discussion any scenario where the attack requires that the private key be leaked, shared or used incorrectly.  It's not that they can't happen, but rather that it is a problem of TPMs, etc. and not protocol design.

a) MASA signs VOUCHER.

e) MI signs IDevID.

problem 1.

   > assuming the registrar can’t know all the manufacturers exhaustively

We assume that in a managed network that the JRC *can* know all the legitimate manufacturers.  The keys can come from sales channel integration (via digital "packing slips" perhaps), can be manually loaded by humans, be scanned from QR codes on the box, etc.  We believe that this is out of scope.

That's one reason we made sure that failures to enroll do not cause the Pledge to never try again with that JRC.  It needs to try again later, because maybe nobody has answered the "Yes/No" Dialog on the management station yet.

And of course there is the WebPKI.  We aren't saying that MI keys (or MASA server TLS keys) MUST be in the WebPKI, but we aren't saying that they can't be.  That's not a panacea... between ComodoGate type situations and certificates for "C1SC0" in a hard to distinguish font, many social engineering attacks could get that "Yes" button pressed.

problem 2.

2.3 defines the extension).  So the Pledge can't create this lie itself, it requires collaboration with the MI to create an IDevID.  Such an MI can point to any MASA it wishes, so long as that device can issue vouchers that the Pledge can validate.

problem 3.

I don't see how this is the case.  The pledge can only collaborate with the manufacturer whose IDevID it has.

problem 4.

--

]      <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  -= IPv6 IoT consulting =-

-------------------------------------------------------------------------------------------------------------------------------
[ C-DAC is on Social-Media too. Kindly follow us at:
Facebook: https://www.facebook.com/CDACINDIA & Twitter: @cdacindia ]

This e-mail is for the sole use of the intended recipient(s) and may
contain confidential and privileged information. If you are not the
intended recipient, please contact the sender by reply e-mail and destroy
all copies and the original message. Any unauthorized review, use,
disclosure, dissemination, forwarding, printing or copying of this email
is strictly prohibited and appropriate legal action will be taken.
-------------------------------------------------------------------------------------------------------------------------------

---

From: Michael Richardson <[email-masked]>
Date: Mon, 19 Feb 2018 14:15:49 -0500

> the Internet might even be considered a security improvement.

I agree that there should be another Security Considerations section.
Should we also say something in the Introduction?

https://github.com/anima-wg/anima-bootstrap/issues/43

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 20 Feb 2018 08:30:29 +1300

> May be!! But practically may not be possible. Manufacturers keep adding and also getting out of business. Tracking each MI is difficult.

ANIMA is scoped to support professionally managed networks. So it seems reasonable
to assume that they have procurement procedures in place to buy from known
sources and not to buy kit "off the back of a lorry" to use a British idiom.

In other words, tracking each manufacturer is *necessary* as it is in fact
the origin of the trust for the BRSKI trust model. "Difficult" is not an
excuse IMHO.

> If manual intervention is required, then it is no longer “Automated BRSKI”. Humans can anyway observer and add/install new device.

Again - a professionally managed network! Our goal in ANIMA is not to eliminate
human operators; it is to avoid them having to perform mindless configuration
tasks or write obscure scripts. So requiring human action to resolve a security
alert is completely acceptable IMHO. In this case the device might have been
installed by a service technician thousands of kilometres away from the NOC,
and if that technician did install a device from an unknown source, this
is exactly a case where the NOC should be alerted.

    Brian

---

From: Michael Richardson <[email-masked]>
Date: Mon, 19 Feb 2018 14:46:21 -0500

>> May be!! But practically may not be possible. Manufacturers keep
    >> adding and also getting out of business. Tracking each MI is difficult. 

Also, the MI may be tracked in the NOC: it doesn't have to happen in the
field.  Once a single MI is added, it is probably good.

How can we improve the text to make this clearer?

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 20 Feb 2018 11:04:47 +1300

> Should we also say something in the Introduction?

I think Security Considerations is fine for this point.

   Brian

---

From: Toerless Eckert <[email-masked]>
Date: Tue, 20 Feb 2018 01:18:37 +0100

Nonwithstanding the more detailled explanations you provided for Anoop,
what i wuild think to be helpful to write into the security ection is like this:

Domain trusting pledge/manufacturer:

BRSKI does not fundamentally change this from RFC7030 EST assuming a pledge used
its IDevID with RFC7030 EST. In both cases, domain (registrar) needs to trust the manufacturer
and potentially some more detailled set of devices if manufacturer provides
such informatio (e.g.: do not trust the following serial numbers, they where
stolen from manufacturer warehouse). The domain (registrar) can authenticate and authorize
the IDevID of the pledge. Establishing this trust between domain and
manufacturer is outside the scope of BRSKI. Worst case, a domain needs to
manually provision the trust anchor for every manufacturer. Better yet, third
parties may provide signing services for manufacturer trust anchors similar to WebPKI.
BRSKI does refine EST in this respect only in demandin that pledges must not
excludeproxies/registrars after having been rejected first because the domain may
take time / manual action 

Btw, and i think this may go further than what might fit into BRSKI, especially given
how as noted above, this is not specific to BRSKI (but would equally work for just EST):

If we could educate the industry more on the use of IDevIDs, then we could end up
wih something a lot more useful than WebPKI. There are a lot of organizations that
provide all type of certifications and qualifications for devices, ranging from jokes
like "CE" over to faily useful securiy behavior certifications such as "FIPS-140".

If manufacturers would start to assign for every device-type they produce another
sub-trust-anchor with which they sign the IDevIDs of that device-type, then 
the certification organizations could sign those sub-trust-anchors after the
device type passed the certification. That would be a cryptographic equivalent of
putting certification stickers onto products.

Of course, this would only provide more security to the domains if the label
implied comes with a certification agency thats worth anything. CE for example
is self-certification by the industry, so completely useless.

Cheers
    toerless

On Sun, Feb 18, 2018 at 07:26:57PM -0500, Michael Richardson wrote:
>     Anoop> domain. The major problem with the procedure is that the registrar doesn???t
>     Anoop> enrolment [assuming the registrar can???t know all the manufacturers
>     Anoop> The major problem with the procedure is that the registrar doesn???t
>    > assuming the registrar can???t know all the manufacturers exhaustively
> 
>     Anoop> enrolment [assuming the registrar can???t know all the manufacturers

-- 
---
[email-masked]

---

From: "Anoop Kumar Pandey" <[email-masked]>
Date: Tue, 20 Feb 2018 10:29:47 +0530

“ANIMA is scoped to support professionally managed networks. So it seems reasonable to assume that they have procurement procedures in place to buy from known sources and not to buy kit "off the back of a lorry" to use a British idiom.”

"Again - a professionally managed network! Our goal in ANIMA is not to eliminate human operators; it is to avoid them having to perform mindless configuration tasks or write obscure scripts. So requiring human action to resolve a security alert is completely acceptable IMHO. In this case the device might have been installed by a service technician thousands of kilometres away from the NOC, and if that technician did install a device from an unknown source, this is exactly a case where the NOC should be alerted."

So, basically you reduced your scope to a professionally managed network. Just for the sake of clarity, if it is just like a trusted world of professionally managed network where pledges being added are from trusted manufacturers, probably we don’t require this cryptographically maintained long procedure of bootstrapping, since trust is derived from the manufacturer. A trusted manufacturer gives a trusted device, that’s all. Suppose we still want to go with this procedure and having our trust in certificates and keys, we don’t require MASA and vouchers. By simply verifying if the IDevID certificate has been signed by a trusted MI or a trusted CA or root-RA should be sufficient for verifying the pledge. Pledge verifying the domain is anyway overrated. Besides, it can also be done by verifying the certificate of JRC during enrolment.

But it is very limited scope. I would work on expanding the scope to any network, any manufacturer-device pair. 

I would also like to quote/remind following lines from Section 1.3 [Scope of Solution] of the RFC: 

“But this solution is not exclusive to the large, it is intended to scale to thousands of devices located in hostile environments, such as ISP provided CPE devices which are drop-shipped to the end user.  The situation where an order is fulfilled from distributed warehouse from a common stock and shipped directly to the target location at the request of the domain owner is explicitly supported.  That stock ("SKU") could be provided to a number of potential domain owners, and the eventual domain owner will not know a-priori which device will go to which location.”

Regards,

Anoop

 

-----Original Message-----
From: Brian Carpenter [mailto:[email-masked]] On Behalf Of Brian E Carpenter
Sent: 20 February 2018 01:00
To: Anoop Kumar Pandey <[email-masked]>; 'Michael Richardson' <[email-masked]>; [email-masked]
Subject: Re: [Anima] verification of manufacturer in BRSKI

> May be!! But practically may not be possible. Manufacturers keep adding and also getting out of business. Tracking each MI is difficult.

ANIMA is scoped to support professionally managed networks. So it seems reasonable to assume that they have procurement procedures in place to buy from known sources and not to buy kit "off the back of a lorry" to use a British idiom.

In other words, tracking each manufacturer is *necessary* as it is in fact the origin of the trust for the BRSKI trust model. "Difficult" is not an excuse IMHO.

> If manual intervention is required, then it is no longer “Automated BRSKI”. Humans can anyway observer and add/install new device.

Again - a professionally managed network! Our goal in ANIMA is not to eliminate human operators; it is to avoid them having to perform mindless configuration tasks or write obscure scripts. So requiring human action to resolve a security alert is completely acceptable IMHO. In this case the device might have been installed by a service technician thousands of kilometres away from the NOC, and if that technician did install a device from an unknown source, this is exactly a case where the NOC should be alerted.

    Brian

> Agreed. Then this problem reduces to Problem 2 where Pledge and MI can 

> collaborate to fool JRC

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

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

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

> Anoop Kumar Pandey < < <mailto:[email-masked]> mailto:[email-masked]>  <mailto:[email-masked]> [email-masked]> wrote directly to the draft authors list, and then gave me permission to share this on the list:

>     Anoop> This is in context to the RFC detailing process of 

> enrolling a pledge to a

>     Anoop> domain. The major problem with the procedure is that the 

> registrar doesn’t

>     Anoop> verify the manufacturer. It simply verifies the voucher and 

> enrols the

>     Anoop> pledge. If pledge send a self-defined URL of manufacturer 

> where provision for

>     Anoop> issuing fake vouchers is in place, then the registrar can 

> be fooled into

>     Anoop> enrolment [assuming the registrar can’t know all the 

> manufacturers

> Additionally pledge

>     Anoop> In the similar way a registrar may collaborate with the 

> manufacturer to lure

> I agree that the Pledge may point at any Manufacturer (in the form of 

> a MASA)

>    (It signs the voucher request to the JRC, and the Client side of 

> the TLS

> (The MI might be the same as the MASA, but in general the MASA may be 

> outsourced.  The Pledge SHOULD have a trusted anchor for both, but it 

> can be designed where it has a manufacturer CA which signs both MASA 

> d) JRC can also audit (verify signatures even) the voucher really 

> comes

>    from MASA, although unless there is a common CA, it may not be able 

> to

>     Anoop> The major problem with the procedure is that the registrar 

> doesn’t

> To translate, the JRC has no obvious way to verify that the "MI" key 

> belongs

>    > assuming the registrar can’t know all the manufacturers 

> exhaustively

>     Anoop> If pledge send a self-defined URL of manufacturer where 

> provision for

>     Anoop> issuing fake vouchers is in place, then the registrar can 

> be fooled into

>     Anoop> enrolment [assuming the registrar can’t know all the 

> manufacturers

> The URL of the manufacturer is embedded in the IDevID certificate 

> (section

>     Anoop> In the similar way a registrar may collaborate with the 

> manufacturer to lure

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

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

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

> consulting =-

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

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

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

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

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

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

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

---

From: Toerless Eckert <[email-masked]>
Date: Tue, 20 Feb 2018 07:21:31 +0100

Anoop, 

> So, basically you reduced your scope to a professionally managed network.

The term 'professionally managed' is in the ANIMA charter, see

https://datatracker.ietf.org/doc/charter-ietf-anima/

It was just meant to provide a clear delineation of anima vs. Homenet or similar networks,
which are meant to operate primarily unmanaged. 

I think it is a vey broad scope.

> Just for the sake of clarity, if it is just like a trusted world of professionally managed network where pledges being added are from trusted manufacturers, probably we don???t require this cryptographically maintained long procedure of bootstrapping, since trust is derived from the manufacturer. A trusted manufacturer gives a trusted device, that???s all.

I do not know what a 'trusted world' is, we have not been using that term in ANIMA.

Do you mind to elaborate what you think is redundant in the
"cryptographically maintained long procedure" ? 

> Suppose we still want to go with this procedure and having our trust in certificates and keys, we don???t require MASA and vouchers. By simply verifying if the IDevID certificate has been signed by a trusted MI or a trusted CA or root-RA should be sufficient for verifying the pledge.

MASA and Voucher are not used to verify the pledge. If you think you read that
in BRSKI, please point to the text section that confused you about this.

> Pledge verifying the domain is anyway overrated.

That is in the eye of the beholder. If you are a buyer of large number of pledges
and do not need any protection against theft,  misassignment of pledges to other
networks or intrusions into pledges that intend to impact your network later, then
sure - you may be happy with pledges not requiring vouchers to get enrolled.

BRSKI already mentions in the appendix a range of variations mostly with
lower security. It does not cover all possible lower security variants such as 
no-MASA/voucher primarily because we wanted the final BRSKI RFC number to actually
mean something wrt to security to buyers of products claiming to support it. If everythng
was optional, nothing is really standardized. It would just be like calling a lottery
a standard for Millionaires.

> Besides, it can also be done by verifying the certificate of JRC during enrolment.

That actually is what the voucher does. Feel free to propose alternatives. I have
a hard time imagining solutions that either do not achieve the goal, add pre-staging
steps or just reinvent what the voucher does under a different name.

Cheers
    Toerless

On Tue, Feb 20, 2018 at 10:29:47AM +0530, Anoop Kumar Pandey wrote:
> ???ANIMA is scoped to support professionally managed networks. So it seems reasonable to assume that they have procurement procedures in place to buy from known sources and not to buy kit "off the back of a lorry" to use a British idiom.???
> 
>  
> 
> ???But this solution is not exclusive to the large, it is intended to scale to thousands of devices located in hostile environments, such as ISP provided CPE devices which are drop-shipped to the end user.  The situation where an order is fulfilled from distributed warehouse from a common stock and shipped directly to the target location at the request of the domain owner is explicitly supported.  That stock ("SKU") could be provided to a number of potential domain owners, and the eventual domain owner will not know a-priori which device will go to which location.???
> 
>  
> 
> Regards,
> 
> Anoop
> 
>  
> 
>  
> 
>  
> 
>  
> 
> > If manual intervention is required, then it is no longer ???Automated BRSKI???. Humans can anyway observer and add/install new device.
> 
>  
> 
> > registrar doesn???t
> >     Anoop> enrolment [assuming the registrar can???t know all the 
> 
> > manufacturers
> 
> > 
> 
> > doesn???t
> >    > assuming the registrar can???t know all the manufacturers 
> 
> > exhaustively
> 
> > 
> 
> >  
> 
> > 
> 
> >     Anoop> enrolment [assuming the registrar can???t know all the 
> 
> > manufacturers
> 
> > 
> 

-- 
---
[email-masked]

---

From: "Anoop Kumar Pandey" <[email-masked]>
Date: Tue, 20 Feb 2018 15:30:14 +0530

>"I do not know what a 'trusted world' is, we have not been using that term
in ANIMA. 

>Do you mind to elaborate what you think is redundant in the
"cryptographically maintained long procedure" ?"

Trusted world is something like "every entity in the domain is a trusted
entity." Also in this case, trust can be derived. For example, if a pledge
is issued by a trusted/enlisted MI, then that pledge can also be trusted.
Here the trust is derived from the MI.

Michael had mentioned in earlier mail, "JRC  trusts pledge by validating
IDevID using MI certificate."  and you mentioned "MASA and Voucher are not
used to verify the pledge.""

If so, then I thought that 'JRC verifying audit log and voucher' step is
redundant. [Page 16 of RFC] It may not be required unless further
investigation into history of pledge is required.

For the statement :- Pledge verifying the domain is anyway overrated

>". If you are a buyer of large number of pledges and do not need any
protection against theft,  misassignment of pledges to other networks or
intrusions into pledges that intend to impact your network later, then >sure
- you may be happy with pledges not requiring vouchers to get enrolled."

Theft is anyway physical security breach. It may happen irrespective of
BRSKI in place.

Misassignment of pledge to other network can be easily detected if pledge is
not accessible in the actual network.

Intrusion in pledge can't be stopped using BRSKI. That depends on methods of
authentication and authorization employed to access the pledge.

Pledge is a device. If I buy/add a device, I need to verify if it is
compromised or not or if it comes from a trusted MI. Device need not verify
me if it wants to work in my environment or not.

If pledge doesn't require to validate JRC  then "MASA issuing voucher and
pledge using that voucher to validate and enroll to JRC" is redundant.

 

That's all from my side. I thought that this system could work in any
environment and I was trying to convince myself of the same and ascertain
that no loopholes are left so far as my understanding is concerned.

Regards,

Anoop

-----Original Message-----
From: Toerless Eckert [mailto:[email-masked]] 
Sent: 20 February 2018 11:52
To: Anoop Kumar Pandey <[email-masked]>
Cc: 'Brian E Carpenter' <[email-masked]>; 'Michael Richardson'
<[email-masked]>; [email-masked]
Subject: Re: [Anima] verification of manufacturer in BRSKI

Anoop, 

 <https://datatracker.ietf.org/doc/charter-ietf-anima/>
https://datatracker.ietf.org/doc/charter-ietf-anima/

It was just meant to provide a clear delineation of anima vs. Homenet or
similar networks, which are meant to operate primarily unmanaged. 

> Just for the sake of clarity, if it is just like a trusted world of
professionally managed network where pledges being added are from trusted
manufacturers, probably we don???t require this cryptographically maintained
long procedure of bootstrapping, since trust is derived from the
manufacturer. A trusted manufacturer gives a trusted device, that???s all.

I do not know what a 'trusted world' is, we have not been using that term in
ANIMA.

> Suppose we still want to go with this procedure and having our trust in
certificates and keys, we don???t require MASA and vouchers. By simply
verifying if the IDevID certificate has been signed by a trusted MI or a
trusted CA or root-RA should be sufficient for verifying the pledge.

MASA and Voucher are not used to verify the pledge. If you think you read
that in BRSKI, please point to the text section that confused you about
this.

> Pledge verifying the domain is anyway overrated.

That is in the eye of the beholder. If you are a buyer of large number of
pledges and do not need any protection against theft,  misassignment of
pledges to other networks or intrusions into pledges that intend to impact
your network later, then sure - you may be happy with pledges not requiring
vouchers to get enrolled.

BRSKI already mentions in the appendix a range of variations mostly with
lower security. It does not cover all possible lower security variants such
as no-MASA/voucher primarily because we wanted the final BRSKI RFC number to
actually mean something wrt to security to buyers of products claiming to
support it. If everythng was optional, nothing is really standardized. It
would just be like calling a lottery a standard for Millionaires.

> Besides, it can also be done by verifying the certificate of JRC during
enrolment.

That actually is what the voucher does. Feel free to propose alternatives. I
have a hard time imagining solutions that either do not achieve the goal,
add pre-staging steps or just reinvent what the voucher does under a
different name.

Cheers

    Toerless

On Tue, Feb 20, 2018 at 10:29:47AM +0530, Anoop Kumar Pandey wrote:

> ???ANIMA is scoped to support professionally managed networks. So it seems
reasonable to assume that they have procurement procedures in place to buy
from known sources and not to buy kit "off the back of a lorry" to use a
British idiom.???

> "Again - a professionally managed network! Our goal in ANIMA is not to
eliminate human operators; it is to avoid them having to perform mindless
configuration tasks or write obscure scripts. So requiring human action to
resolve a security alert is completely acceptable IMHO. In this case the
device might have been installed by a service technician thousands of
kilometres away from the NOC, and if that technician did install a device
from an unknown source, this is exactly a case where the NOC should be
alerted."

> ???But this solution is not exclusive to the large, it is intended to
scale to thousands of devices located in hostile environments, such as ISP
provided CPE devices which are drop-shipped to the end user.  The situation
where an order is fulfilled from distributed warehouse from a common stock
and shipped directly to the target location at the request of the domain
owner is explicitly supported.  That stock ("SKU") could be provided to a
number of potential domain owners, and the eventual domain owner will not
know a-priori which device will go to which location.???

> From: Brian Carpenter [ <mailto:[email-masked]>
mailto:[email-masked]] On Behalf Of 

> Brian E Carpenter

> To: Anoop Kumar Pandey < <mailto:[email-masked]> [email-masked]>; 'Michael
Richardson' 

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

> >            I am further expanding my query and raising concern over your
response. The Problem Nos. are same as in the trailing reply.:

> > May be!! But practically may not be possible. Manufacturers keep adding
and also getting out of business. Tracking each MI is difficult.

> ANIMA is scoped to support professionally managed networks. So it seems
reasonable to assume that they have procurement procedures in place to buy
from known sources and not to buy kit "off the back of a lorry" to use a
British idiom.

> > Response: " The keys can come from sales channel integration (via
digital "packing slips" perhaps), can be manually loaded by humans, be
scanned from QR codes on the box, etc.  We believe that this is out of
scope.

> > If manual intervention is required, then it is no longer ???Automated
BRSKI???. Humans can anyway observer and add/install new device.

> Again - a professionally managed network! Our goal in ANIMA is not to
eliminate human operators; it is to avoid them having to perform mindless
configuration tasks or write obscure scripts. So requiring human action to
resolve a security alert is completely acceptable IMHO. In this case the
device might have been installed by a service technician thousands of
kilometres away from the NOC, and if that technician did install a device
from an unknown source, this is exactly a case where the NOC should be
alerted.

> > Response: The URL of the manufacturer is embedded in the IDevID
certificate (section 2.3 defines the extension).  So the Pledge can't create
this lie itself, it requires collaboration with the MI to create an IDevID.

> > I had asked the same thing. If pledge collaborates with a rouge MI
[given Problem 1 is not solved], the domain can easily be invaded.

> > Agreed. Then this problem reduces to Problem 2 where Pledge and MI 

> > can

> > Response: The Pledge will only trust a voucher signed by MASA. Any
signature from a different entity will be rejected by the Pledge. So a fake
voucher is not possible.

> > I only raised concern that there is no way to detect if MASA and JRC
have collaborated to lure the pledge into a malicious domain unless the MASA
certificate and IDevID certificate have common Root Certifying authority.

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

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

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

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

> > {sorry if this is a duplicate, my draft folder says it did not go 

> > out}

> > Anoop Kumar Pandey < < < <mailto:[email-masked]> mailto:[email-masked]>
<mailto:[email-masked]> mailto:[email-masked]>  < <mailto:[email-masked]>
mailto:[email-masked]>  <mailto:[email-masked]> [email-masked]> wrote directly
to the draft authors list, and then gave me permission to share this on the
list:

> >     Anoop> verify the manufacturer. It simply verifies the voucher 

> > and

> > I agree that the Pledge may point at any Manufacturer (in the form 

> > of

> > (The MI might be the same as the MASA, but in general the MASA may 

> > be

> > outsourced.  The Pledge SHOULD have a trusted anchor for both, but 

> > it

> > I'd like start by ruling out of bounds for this discussion any scenario
where the attack requires that the private key be leaked, shared or used
incorrectly.  It's not that they can't happen, but rather that it is a
problem of TPMs, etc. and not protocol design.

> >    from MASA, although unless there is a common CA, it may not be 

> > able

> >     Anoop> The major problem with the procedure is that the 

> > registrar

legitimate manufacturers.  The keys can come from sales channel integration
(via digital "packing slips" perhaps), can be manually loaded by humans, be
scanned from QR codes on the box, etc.  We believe that this is out of
scope.

> > And of course there is the WebPKI.  We aren't saying that MI keys (or
MASA server TLS keys) MUST be in the WebPKI, but we aren't saying that they
can't be.  That's not a panacea... between ComodoGate type situations and
certificates for "C1SC0" in a hard to distinguish font, many social
engineering attacks could get that "Yes" button pressed.

> > 2.3 defines the extension).  So the Pledge can't create this lie itself,
it requires collaboration with the MI to create an IDevID.  Such an MI can
point to any MASA it wishes, so long as that device can issue vouchers that
the Pledge can validate.

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

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

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

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

> > Software Works  -= IPv6 IoT

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

> > Facebook:  < <https://www.facebook.com/CDACINDIA>
https://www.facebook.com/CDACINDIA> 

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

> > destroy all copies and the original message. Any unauthorized 

> > review,

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

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

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

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

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

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

--

---

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

---

From: 'Toerless Eckert' <[email-masked]>
Date: Tue, 20 Feb 2018 16:48:40 +0100

> Here the trust is derived from the MI.

"Trusted world" is misleading because the assumption in ANIMA is that the world
is actually not-trusted and instead has a lot of bad things happening and the 
cryptographic procedures of BRSKI/ACP serve to create a "trusted domain/network"
in the face of the largely "untrusted world".

If you live in a gated community you would also not claim the world is trusted.
Very similar.

> investigation into history of pledge is required.

As said. MASA and Voucher are not used in BRSKI to make the Domain trust the Pledge,
but that does not make them redundant.

> Theft is anyway physical security breach. It may happen irrespective of

Theft is not only applied to physical security breach. Illegal use of utility into
something (physical or not) also gets classified as theft in many countries. BRSKI
protects also against remotely gaining access/utility to the Pledge.

Physical theft too is less likely if you can not get utility:
If a Pledge does not allow to circumvent secure bootstrap even with
physical posession of the Pledge, then those Pledges are less likely subjects to 
physical theft.

> not accessible in the actual network.

Depending on use-case it may be expensive to detect, but in even more use cases
it will be expensive to fix.

> Intrusion in pledge can't be stopped using BRSKI.

Yes it can.

> That depends on methods of authentication and authorization employed to access the pledge.

And those methods are meant to be gated by BRSKI/EST.

Think of the most simple case:  You will not get any configuration access
to the device unless BRSKI was run, and afterwards you need to authenticate
yourself on every config connection with the cert enrolled during BRSKI.

> compromised or not or if it comes from a trusted MI.

Well, we agree on one thing. 

> Device need not verify me if it wants to work in my environment or not.

BRSKI devices only want to work for their owner.

> pledge using that voucher to validate and enroll to JRC" is redundant.

Probably true in the context of how BRSKI is currently written. Except that
for the current charter work on BRSKI we have concluded that the pledge does
need to verify the domain for all the reasons documented in BRSKI and repeated by me.
And you disagree.

Note though, that there can also be other benefits to MASA than
"pledge only wants to work for owner", and that is "pledge wants to discover
owner".

Consider the typical use case of some pledge connecting to a public
network, such as Internet, so the network connection has no way to point the
pledge to the owner. To support this, you also need a three party system: 
Pledge, Manufacturer Service, Owner: Pledge can only contact some Manufacturer
service, and that would "redirect" Pledge to owner after Owner hass
claimed pledge from manufacturer.

The BRSKI section about cloud registrar/service hints at this use-case,
but i am not sure to what extend we could/should cover this in detail
in BRSKI (see my review) because it does require some extension to
the signaling IMHO. I would be happy too if this wasn't buried
in some section of the BRSKI spec but in separate followup work that focusses
on this case. 

> that no loopholes are left so far as my understanding is concerned.

Glad to hear. I thought you where wanting to keepg the biggest loophole in place
(pledge will work for anybody).

Cheers
    Toerless

-- 
---
[email-masked]

---

From: "Anoop Kumar Pandey" <[email-masked]>
Date: Wed, 21 Feb 2018 10:15:07 +0530

>the assumption in ANIMA is that the world is actually not-trusted and
instead has a lot of bad things happening and the cryptographic procedures
of BRSKI/ACP serve to create a "trusted domain/network" in the >face of the
largely "untrusted world".

As per our previous conversations: 
1. We assume that in a managed network that the JRC *can* know all the
legitimate manufacturers.  The keys can come from sales channel integration
(via digital "packing slips" perhaps), can be manually loaded by humans, be
scanned from QR codes on the box, etc.   - Michael Richardson

2. ANIMA is scoped to support professionally managed networks. So it seems
reasonable to assume that they have procurement procedures in place to buy
from known sources and not to buy kit "off the back of a lorry" to use a
British idiom. - Brian Carpenter

So JRS has all legitimate manufacturers and is procuring pledges from known
sources (out of these legitimate manufacturers), then where is the
hostility?

That's what I was trying to say in my initial mail that given an unknown MI
or a collaboration between pledge and MI, can security be established using
Automated BRSKI?

Also the pledge trusts JRC if JRC is able to pass on the voucher from MASA
to pledge. MASA only checks JRC's certificate. Therefore any JRC having a
valid certificate may pass on the voucher from MASA to pledge and become
owner of the pledge [case of theft]. 

Anoop> Device need not verify me if it wants to work in my environment or
not.

Toer> BRSKI devices only want to work for their owner.

The will of a pledge is immaterial. A device will recognize anyone as owner
who enters a valid credential. In case of BRSKI, whoever passes voucher from
MASA to pledge.

I bought an iPhone and input my icloud credential, it will start working.
Someone else gets hand on my iPhone, he will reset, put his icloud account
and it will work for him. 

Toer>Illegal use of utility into something (physical or not) also gets
classified as theft in many countries. BRSKI protects also against remotely
gaining access/utility to the Pledge.

Anoop> Intrusion in pledge can't be stopped using BRSKI. That depends on
methods of authentication and authorization employed to access the pledge.

Toer> And those methods are meant to be gated by BRSKI/EST.

I believe, BRSKI is a one-time imprinting service to a domain through JRC.
Once that is done, any unauthorized access (depending on the vulnerability
in the pledge) post EST, may not be stopped. 

Or may be I am missing something. To clarify, please clear my doubt.

BRSKI, is it one time process? 

Or during each access to device will it re-run? 

When do we require to re-run this, only on domain-transfer? 

Does it happen automatically whenever a device enters a domain or can it
started deliberately?

Regards,

Anoop

-----Original Message-----
From: 'Toerless Eckert' [mailto:[email-masked]] 
Sent: 20 February 2018 21:19
To: Anoop Kumar Pandey <[email-masked]>
Cc: 'Brian E Carpenter' <[email-masked]>; 'Michael Richardson'

On Tue, Feb 20, 2018 at 03:30:14PM +0530, Anoop Kumar Pandey wrote:

> Trusted world is something like "every entity in the domain is a 

> trusted entity." Also in this case, trust can be derived. For example, 

> if a pledge is issued by a trusted/enlisted MI, then that pledge can also
be trusted.

> Here the trust is derived from the MI.

"Trusted world" is misleading because the assumption in ANIMA is that the
world is actually not-trusted and instead has a lot of bad things happening
and the cryptographic procedures of BRSKI/ACP serve to create a "trusted
domain/network"

If you live in a gated community you would also not claim the world is
trusted.

Very similar.

> Michael had mentioned in earlier mail, "JRC  trusts pledge by 

> validating IDevID using MI certificate."  and you mentioned "MASA and 

> Voucher are not used to verify the pledge.""

> If so, then I thought that 'JRC verifying audit log and voucher' step 

> is redundant. [Page 16 of RFC] It may not be required unless further 

> investigation into history of pledge is required.

As said. MASA and Voucher are not used in BRSKI to make the Domain trust the
Pledge, but that does not make them redundant.

> >protection against theft,  misassignment of pledges to other networks 

> >or  intrusions into pledges that intend to impact your network later, 

> >then >sure

> Theft is anyway physical security breach. It may happen irrespective 

> of BRSKI in place.

Theft is not only applied to physical security breach. Illegal use of
utility into something (physical or not) also gets classified as theft in
many countries. BRSKI protects also against remotely gaining access/utility
to the Pledge.

If a Pledge does not allow to circumvent secure bootstrap even with physical
posession of the Pledge, then those Pledges are less likely subjects to
physical theft.

> Misassignment of pledge to other network can be easily detected if 

> pledge is not accessible in the actual network.

Depending on use-case it may be expensive to detect, but in even more use
cases it will be expensive to fix.

Yes it can.

Think of the most simple case:  You will not get any configuration access to
the device unless BRSKI was run, and afterwards you need to authenticate
yourself on every config connection with the cert enrolled during BRSKI.

> If pledge doesn't require to validate JRC  then "MASA issuing voucher 

> and pledge using that voucher to validate and enroll to JRC" is redundant.

Probably true in the context of how BRSKI is currently written. Except that
for the current charter work on BRSKI we have concluded that the pledge does
need to verify the domain for all the reasons documented in BRSKI and
repeated by me.

And you disagree.

Note though, that there can also be other benefits to MASA than "pledge only
wants to work for owner", and that is "pledge wants to discover owner".

Consider the typical use case of some pledge connecting to a public network,
such as Internet, so the network connection has no way to point the pledge
to the owner. To support this, you also need a three party system: 

Pledge, Manufacturer Service, Owner: Pledge can only contact some
Manufacturer service, and that would "redirect" Pledge to owner after Owner
hass claimed pledge from manufacturer.

The BRSKI section about cloud registrar/service hints at this use-case, but
i am not sure to what extend we could/should cover this in detail in BRSKI
(see my review) because it does require some extension to the signaling
IMHO. I would be happy too if this wasn't buried in some section of the
BRSKI spec but in separate followup work that focusses on this case. 

> environment and I was trying to convince myself of the same and 

> ascertain that no loopholes are left so far as my understanding is
concerned.

Glad to hear. I thought you where wanting to keepg the biggest loophole in
place (pledge will work for anybody).

Cheers

    Toerless

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

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

> Cc: 'Brian E Carpenter' < <mailto:[email-masked]>
[email-masked]>; 'Michael Richardson'

>  < <https://datatracker.ietf.org/doc/charter-ietf-anima/>
https://datatracker.ietf.org/doc/charter-ietf-anima/>

> It was just meant to provide a clear delineation of anima vs. Homenet 

> or similar networks, which are meant to operate primarily unmanaged.

> professionally managed network where pledges being added are from 

> trusted manufacturers, probably we don???t require this 

> cryptographically maintained long procedure of bootstrapping, since 

> trust is derived from the manufacturer. A trusted manufacturer gives a
trusted device, that???s all.

> I do not know what a 'trusted world' is, we have not been using that 

> term in ANIMA.

> > Suppose we still want to go with this procedure and having our trust 

> > in

> verifying if the IDevID certificate has been signed by a trusted MI or 

> a trusted CA or root-RA should be sufficient for verifying the pledge.

> MASA and Voucher are not used to verify the pledge. If you think you 

> read that in BRSKI, please point to the text section that confused you 

> about this.

> That is in the eye of the beholder. If you are a buyer of large number 

> of pledges and do not need any protection against theft,  

> misassignment of pledges to other networks or intrusions into pledges 

> that intend to impact your network later, then sure - you may be happy 

> with pledges not requiring vouchers to get enrolled.

> BRSKI already mentions in the appendix a range of variations mostly 

> with lower security. It does not cover all possible lower security 

> variants such as no-MASA/voucher primarily because we wanted the final 

> BRSKI RFC number to actually mean something wrt to security to buyers 

> of products claiming to support it. If everythng was optional, nothing 

> is really standardized. It would just be like calling a lottery a standard
for Millionaires.

> > Besides, it can also be done by verifying the certificate of JRC 

> > during

> That actually is what the voucher does. Feel free to propose 

> alternatives. I have a hard time imagining solutions that either do 

> not achieve the goal, add pre-staging steps or just reinvent what the 

> voucher does under a different name.

> > ???ANIMA is scoped to support professionally managed networks. So it 

> > seems

> reasonable to assume that they have procurement procedures in place to 

> buy from known sources and not to buy kit "off the back of a lorry" to 

> use a British idiom.???

> > "Again - a professionally managed network! Our goal in ANIMA is not 

> eliminate human operators; it is to avoid them having to perform 

> mindless configuration tasks or write obscure scripts. So requiring 

> human action to resolve a security alert is completely acceptable 

> IMHO. In this case the device might have been installed by a service 

> technician thousands of kilometres away from the NOC, and if that 

> technician did install a device from an unknown source, this is 

> exactly a case where the NOC should be alerted."

> > But it is very limited scope. I would work on expanding the scope to 

> > any

> network, any manufacturer-device pair. 

> > I would also like to quote/remind following lines from Section 1.3 

> > [Scope

> of Solution] of the RFC: 

> > ???But this solution is not exclusive to the large, it is intended 

> scale to thousands of devices located in hostile environments, such as 

> ISP provided CPE devices which are drop-shipped to the end user.  The 

> situation where an order is fulfilled from distributed warehouse from 

> a common stock and shipped directly to the target location at the 

> request of the domain owner is explicitly supported.  That stock 

> ("SKU") could be provided to a number of potential domain owners, and 

> the eventual domain owner will not know a-priori which device will go to
which location.???

> > From: Brian Carpenter [ < <mailto:[email-masked]>
mailto:[email-masked]>

>  <mailto:[email-masked]> mailto:[email-masked]] On
Behalf Of

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

> > 'Michael

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

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

> > >            I am further expanding my query and raising concern 

> > > over your

> > > Response: " We assume that in a managed network that the JRC *can* 

> > > know

> all the legitimate manufacturers."

> > > adding

> > ANIMA is scoped to support professionally managed networks. So it 

> > seems

> reasonable to assume that they have procurement procedures in place to 

> buy from known sources and not to buy kit "off the back of a lorry" to 

> use a British idiom.

> > In other words, tracking each manufacturer is *necessary* as it is 

> > in fact

> the origin of the trust for the BRSKI trust model. "Difficult" is not 

> an excuse IMHO.

> > > And if the JRC does see a MI that it does not know, then it can 

> > > ask a

> human."

> > > If manual intervention is required, then it is no longer 

> > > ???Automated

> > Again - a professionally managed network! Our goal in ANIMA is not 

> eliminate human operators; it is to avoid them having to perform 

> mindless configuration tasks or write obscure scripts. So requiring 

> human action to resolve a security alert is completely acceptable 

> IMHO. In this case the device might have been installed by a service 

> technician thousands of kilometres away from the NOC, and if that 

> technician did install a device from an unknown source, this is 

> exactly a case where the NOC should be alerted.

> certificate (section 2.3 defines the extension).  So the Pledge can't 

> create this lie itself, it requires collaboration with the MI to create an
IDevID.

> > > Response: The pledge can only collaborate with the manufacturer 

> > > whose

> IDevID it has.

> signature from a different entity will be rejected by the Pledge. So a 

> fake voucher is not possible.

> > > I only raised concern that there is no way to detect if MASA and 

> > > JRC

> have collaborated to lure the pledge into a malicious domain unless 

> the MASA certificate and IDevID certificate have common Root Certifying
authority.

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

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

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

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

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

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

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

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

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

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

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

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

> directly to the draft authors list, and then gave me permission to 

> share this on the

> > >     Anoop> domain. The major problem with the procedure is that 

> > > the

> > >     Anoop> pledge. If pledge send a self-defined URL of 

> > > manufacturer

> > >     Anoop> issuing fake vouchers is in place, then the registrar 

> > >     Anoop> and a random manufacturer can also collaborate to do 

> > > the

> same.

> > > So let me name them so that we can discuss them easier, and make 

> > > sure

> that I understand you correctly.

> > > Probably, we need to add some text to the Security Considerations, 

> > > and I

> > >    (It signs the voucher request to the JRC, and the Client side 

> > >    It also signs the Server side of the TLS connection from Pledge 

> JRC.

> > > can be designed where it has a manufacturer CA which signs both 

> > > MASA

> > > I'd like start by ruling out of bounds for this discussion any 

> > > scenario

> where the attack requires that the private key be leaked, shared or 

> used incorrectly.  It's not that they can't happen, but rather that it 

> is a problem of TPMs, etc. and not protocol design.

> > > To translate, the JRC has no obvious way to verify that the "MI" 

> > > key

> > > We assume that in a managed network that the JRC *can* know all 

> > > the

> legitimate manufacturers.  The keys can come from sales channel 

> integration (via digital "packing slips" perhaps), can be manually 

> loaded by humans, be scanned from QR codes on the box, etc.  We 

> believe that this is out of scope.

> > > And if the JRC does see a MI that it does not know, then it can 

> > > ask a

> human.

> > > That's one reason we made sure that failures to enroll do not 

> > > cause the

> because maybe nobody has answered the "Yes/No" Dialog on the 

> management station yet.

> > > (or

> MASA server TLS keys) MUST be in the WebPKI, but we aren't saying that 

> they can't be.  That's not a panacea... between ComodoGate type 

> situations and certificates for "C1SC0" in a hard to distinguish font, 

> many social engineering attacks could get that "Yes" button pressed.

> > >     Anoop> issuing fake vouchers is in place, then the registrar 

> > > 2.3 defines the extension).  So the Pledge can't create this lie 

> > > itself,

> it requires collaboration with the MI to create an IDevID.  Such an MI 

> can point to any MASA it wishes, so long as that device can issue 

> vouchers that the Pledge can validate.

> > >     Anoop> and a random manufacturer can also collaborate to do 

> > > the

> same.

> > > I don't see how this is the case.  The pledge can only collaborate 

> > > with

> > > Any voucher created by the real MASA is, by definition, not a fake

> voucher.

> > > Or explain what text we need to change to clear up the

> mis-understanding?

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

> networks [

> > > ]   Michael Richardson, Sandelman Software Works        | network

> architect  [

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

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

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

> < <mailto:[email-masked]> mailto:[email-masked]>
<mailto:[email-masked]> [email-masked]   < < <
<http://www.sandelman.ca/> http://www.sandelman.ca/>

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

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

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

>  <http://www.sandelman.ca/> http://www.sandelman.ca/        |   ruby on
rails    [

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

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

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

> > > Facebook:  < < <https://www.facebook.com/CDACINDIA>

>  <https://www.facebook.com/CDACINDIA> https://www.facebook.com/CDACINDIA>

> > >  < <https://www.facebook.com/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

> > > this email is strictly prohibited and appropriate legal action 

> > > will be

> taken.

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

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

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

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

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

> > this email is strictly prohibited and appropriate legal action will 

> taken.

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

--

---

---

From: 'Toerless Eckert' <[email-masked]>
Date: Wed, 21 Feb 2018 19:12:09 +0100

Inline

> sources (out of these legitimate manufacturers), then where is the

Well, given how Brian mentioned it: One example is literally buying off
the back of a lorry and have IDevID/MASA be able to help know that this was
a legitimate refurbisher of old equipment as opposed to the idiomatic thief
Brian is referring to.

But the prime purpose of BRSKI/Voucher/MASA is really all those
man-in-the-middle attacks. E.g: attacker trying to look like proxy/registrar
to pledge and/or pledge to proxy/registrar.

Remember how the core purpose of ANIMA/BRSKI is to enable zero-touch,
pre-staging free deployment of pledges - anywhere on a network. Today,
pretty much all pre-existing bootstrap mechanisms require you to have
trusted physical connections in a pre-staging location and humans checking
Pledge devices are what they claim to be to be able to have a legitimate
pledge bootstrapped and secured. Just look at the security you get (none)
if instead you take an average pledge and connects it to some network.
They can be remotely recognized, and be overtaken from remote with default
passwords.

Think of the voucher as just a password given to the owner by the MASA so
it can log into the pledge, but men-in-the-middle can't.  That's the core
of BRSKI. Not really that difficult a concept. Then we added IDevID for
owners to verify pledges, a dash of TLS and PKI plus a dollop of EST to
it to make it cryptosec compliant, proxy to make it easier to deploy and
less attackable, and MASA logs to simplify sales channels.  So the overall
BRSKI recipe is a bit more involved.

> or a collaboration between pledge and MI, can security be established using

s/collaboration/collusion/ ?!

Without BRSKI, an evil Pledge with evil software from an evil manufacturer
that you the owner trusts can do all sort of evil things in the network.
Before and after BRSKI.  BRSKI does not help against this but will just
be subject to attacks from such an evil trusted pledge like any other protocol
the pledge may later run to attack the network.

A Plegde with IDevID will more likely have also secure boot and/or other
security measures that in a court of law could be used as indications that
the evil software was really from the evil manufacturer instead of a third
party attacker. But thats really only correlated with BRSKI but otherwise
has nothing to do with it. But see Ken Thomspons Hack of 1984 (thanks Hesham).

With BRSKI compliant pledges, the MI is never really unknown because
the IDevID points to it. It just may not yet be trusted by the owner.
But we already declared on this thread that the means to make owners
trusts MI is outside the scope of BRSKI. And i gave examples on this thread
of how IMHO this could nicely be done by PKI'ification of control
institution that could make statements about the trustworthyness of
manufacturer via certificates. And maybe actually do it better than
with WebPKI, where you can't trust those certification organizations.

> to pledge. MASA only checks JRC's certificate.

MASA may require proximity of Pledge to Registrar, in which case it
would know that Registrar is actually connected to Pledge.

> Therefore any JRC having a valid certificate may pass on the voucher
> from MASA to pledge and become owner of the pledge [case of theft]. 

See above.

> The will of a pledge is immaterial.

Sure. Like our discussion here. But that does not make it irrelevant.

Did you mean irrelevant ?

> A device will recognize anyone as owner who enters a valid credential.
> In case of BRSKI, whoever passes voucher from MASA to pledge.

Right. Which is BRSKIs way to express ownership. Which is what
the pledge checks so it will only work for its owner.

> and it will work for him. 

Then you go to the police and report your phone / serial number stolen,
the police gets the icloud account information from Apple to support
finding and prosecuting the thief.

I don't have an iPhone. Is it mandatory to use an iCloud account to
activate a reset iPhone ? How easy is it to create an untraceable
iCloud account ?

Similar considerations would apply to operationalizing BRSKI/MASA
interactions when you do sales integreation. If you want to use
MASA log to protect against theft, you better have traceable
identities for the owners.

> in the pledge) post EST, may not be stopped. 

True, but you need the BRSKI/voucher mechanism before EST/config.
Just like a default password.

> BRSKI, is it one time process? 

If you're always loosing your pledges like your iPhones... ;-)

> Or during each access to device will it re-run? 

In general once after you bought/installed.

But think for example about valid cases for factory reset of devices without
owner change. Typical in large organizations when devices are re-deployed
into different locations/purposes. 

BRSKI aware factory resets should IMHO have an option for reset everything
except voucher installed trust-anchors to avoid having to redo BRSKI.

> When do we require to re-run this, only on domain-transfer? 

I think the doc says unoconfigured pledge. So after a reset, see example
above. In a more flexible implementation it might simply be triggered
by the absence of the BRSKI result config, eg: configured trust-anchor
and potentially EST enrolled cert.

> Does it happen automatically whenever a device enters a domain or can it

see above.

Cheers
    Toerless

-- 
---
[email-masked]

---

From: Michael Richardson <[email-masked]>
Date: Thu, 22 Feb 2018 20:55:05 -0500

> domain is anyway overrated.

So, I think you are saying that you do not subscribe to the problem statement.

    > the certificate of JRC during enrolment.

Please explain.
It would be great to simplify the protocol.

    > [Scope of Solution] of the RFC:

    > “But this solution is not exclusive to the large, it is intended to
    > the eventual domain owner will not know a-priori which device will go
    > to which location.”

Yes, it's designed exactly to deal with situation.
Are you saying that it fails in some way?

---

From: Michael Richardson <[email-masked]>
Date: Thu, 22 Feb 2018 21:19:42 -0500

Anoop Kumar Pandey <[email-masked]> wrote:
    > So JRS has all legitimate manufacturers and is procuring pledges from
    > known sources (out of these legitimate manufacturers), then where is
    > the hostility?

There are hostile devices on the network, and there are hostile networks that
might attempt to take over the pledge.  The IDevID protects the network
against hostile pledges, and the voucher protects the pledge against hostile
networks.

There is also the non-malicious situatoin where a pledge simply has multiple
(usually wireless!) networks to which it may join.  The voucher lets the
pledge decide which network will have it.  However, we haven't decided how to
do this for 802.11; in 6tisch we are doing this for 802.15.4.

    > That’s what I was trying to say in my initial mail that given an
    > unknown MI or a collaboration between pledge and MI, can security be
    > established using Automated BRSKI?

If your network's policy is to accept devices from unknown MIs, and the
MI is willing to issue vouchers to unknown domains, then you can be sure
that the connection is good.  By definition the pledge, being built by the
MI, is *always* in collaboration with it.

In ANIMA we do not go into home user situations, but that's due to charter
restrictions, not technology.  We do think that BRSKI can be used to
bootstrap Homenet.  In that situation, one can imagine buying lightbulbs
From Home Depot, and bring them home.  A JRC could run on a phone (or more
likely an app that speaks to a JRC via an API).  Unknown MIs might be
accepted, but why do that when a QR code could be scanned by the phone to
introduce the MI.

    > Also the pledge trusts JRC if JRC is able to pass on the voucher from
    > MASA to pledge. MASA only checks JRC’s certificate. Therefore any JRC
    > having a valid certificate may pass on the voucher from MASA to pledge
    > and become owner of the pledge [case of theft].

Yes, that's the case if the manufacturer does not know (or care) who bought
what.  That's reasonable for quite a number of cases.  Routers are usually
spared by manufacturers by geography, and given <4hr replacement SLAs,
there just isn't time on a Sunday morning at 4am to do any sales paperwork.
What might matter is that the JRC is *a* customer, but it doesn't matter which.

{Such a thing would have really helped me out in quite a number of times,
as I would get woken up at 5am, when the field operative guys can't figure
out why the router with the "export" firmware won't run securely, because it
needs the "cryptographic" firmware, but that license key is not valid for
that device}

    > I believe, BRSKI is a one-time imprinting service to a domain through
    > JRC. Once that is done, any unauthorized access (depending on the
    > vulnerability in the pledge) post EST, may not be stopped.

That's true.
That's not entirely our problem; we do however, by providing the pledge
with an LDevID and certificate trust anchors via EST, support doing very
secure authorization processes later on.  No default passwords, etc.
because no passwords are needed if both ends have certificates they can use.

    > Or during each access to device will it re-run?

One time process.

    > When do we require to re-run this, only on domain-transfer?

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.

    > Does it happen automatically whenever a device enters a domain or can
    > it started deliberately?

It is not automatic.
It needs to be deliberate.

---

From: "Anoop Kumar Pandey" <[email-masked]>
Date: Fri, 23 Feb 2018 12:37:47 +0530

Anoop> Pledge verifying the

Anoop> domain is anyway overrated.

Michael>So, I think you are saying that you do not subscribe to the problem statement.

I think that is not necessary. When a pledge/device is bought, it is manually added to a network of buyer [usually intranet], where it can discover a JRC.  Therefore it is not the choice/privilege of pledge to verify the domain. On the other side, JRC should validate if the pledge has come from genuine manufacturer and is clean.

Alternatively, If a pledge is put on internet, then considering there may be countless number of JRCs on internet, and trying to connect to each JRC until the pledge finds actual owner is practically impossible; the pledge will have to be configured to discover a particular JRC while buying. So again the pledge doesn’t have much choice.

Also Quoting Toer advocating pledge requiring to verify JRC: “. If you are a buyer of large number of pledges and do not need any protection against theft,  misassignment of pledges to other networks or intrusions into pledges that intend to impact your network later, then sure - you may be happy with pledges not requiring vouchers to get enrolled.”

In a parallel mail, you have mentioned that BRSKI is one time process and need to be deliberately re-run/started. So once BRSKI is completed and pledge is enrolled; intrude in it or steal and put it in some other network, it won’t matter. 

But the case where BRSKI runs automatically if pledge is disconnected and added to anywhere else, at least theft won’t work because pledge won’t work without re-verifying the voucher with new network/JRC.  I think this can be made mandatory in pledge to re-run BRSKI if it detects network change.

Anoop> Besides, it can also be done by verifying

Anoop> the certificate of JRC during enrolment.

Michael>Please explain.

Michael>It would be great to simplify the protocol.

I still believe that Pledge need not verify JRC, But if necessary, the easy way will be following:

When pledge verifies a JRC, these steps are there [your first mail to me]:

1.       Pledge issues voucher request to JRC

2.       JRC passes voucher request to MASA. 

3.       MASA verifies request and issues voucher to JRC

4.       JRC passes voucher to Pledge

5.       Pledge verifies the voucher and send voucher status telemetry and trusts JRC. 

These steps require MASA to be online, else they will fail.

What I propose is, when we buy the device, MI can issue a digitally signed invoice issued to domain/JRC.

Now when a pledge wants to validate the JRC, he simply needs to verify the signature of MI on the invoice. No communication with MASA or even MASA itself is not required. 

It is just like the way, JRC verifies the pledge using the IDevID certificate issued by MI.

Anoop> I would also like to quote/remind following lines from Section 1.3

Anoop> [Scope of Solution] of the RFC:

Anoop> “But this solution is not exclusive to the large, it is intended to

Anoop> scale to thousands of devices located in hostile environments, such as

Anoop> ISP provided CPE devices which are drop-shipped to the end user. The

Anoop> situation where an order is fulfilled from distributed warehouse from

Anoop> a common stock and shipped directly to the target location at the

Anoop> request of the domain owner is explicitly supported. That stock

Anoop> ("SKU") could be provided to a number of potential domain owners, and

Anoop> the eventual domain owner will not know a-priori which device will go

Anoop> to which location.”

Michael>Yes, it's designed exactly to deal with situation.

Michael>Are you saying that it fails in some way?

You said “We assume that in a managed network that the JRC *can* know all the legitimate manufacturers.”. 

Brian said “ANIMA is scoped to support professionally managed networks. So it seems reasonable to assume that they have procurement procedures in place to buy from known sources and not to buy kit "off the back of a lorry" to use a British idiom.”

Basically you have known manufacturers and you are buying from known source. Therefore there is no hostility. Further it’s not a cloud environment where you don’t know, where your device is placed. Installation of pledge will be manual [barely any chance of error, until you consider humans are hostile].

If there were hostility, like unknown manufacturer which could give you malicious pledge, BRSKI anyway can’t detect that, since it simply checks IDevID  which is anyway signed by unknown manufacturer and will check out. You mentioned in earlier mail also that manual intervention is required for such case. [You quoted “if the JRC does see a MI that it does not know, then it can ask a human.”]

There are hostile networks and pledges, but you have only whitelist of manufacturers [your assumption only “the JRC *can* know all the legitimate manufacturers”] which only talks about known manufacturers. But it doesn’t provide security in case of unknown or known turned rogue MI/pledge. For that manual intervention is required.

Regards,

Anoop

 

 

-----Original Message-----
From: Michael Richardson [mailto:[email-masked]] 
Sent: 23 February 2018 07:25
To: Anoop Kumar Pandey <[email-masked]>
Cc: 'Brian E Carpenter' <[email-masked]>; [email-masked]
Subject: Re: [Anima] verification of manufacturer in BRSKI

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

    > Besides, it can also be done by verifying

    > the certificate of JRC during enrolment.

Please explain.

 

--

---

From: 'Toerless Eckert' <[email-masked]>
Date: Fri, 23 Feb 2018 16:48:47 +0100

> I think that is not necessary. When a pledge/device is bought, it is manually added to a network of buyer [usually intranet], where it can discover a JRC.  Therefore it is not the choice/privilege…

I did explain to you in my prior email, that one primary purpose of Voucher/MASA is to prohibit
man-in-the-middle attacks. 

> Alternatively, If a pledge is put on internet, then considering there may be countless number of JRCs on internet, and trying to connect to each JRC until the pledge finds actual owner is practically impossible; the pledge will have to be configured to discover a particular JRC while buying. So again the pledge doesn???t have much choice.

I did explain to you in another email in this thread that piece as well.

> Also Quoting Toer advocating pledge requiring to verify JRC: ???. If you are a buyer of large number of pledges and do not need any protection against theft,  misassignment of pledges to other networks or intrusions into pledges that intend to impact your network later, then sure - you may be happy with pledges not requiring vouchers to get enrolled.???

That was purely respective to theft protectin, not men in the middle attacks.

> In a parallel mail, you have mentioned that BRSKI is one time process and need to be deliberately re-run/started. So once BRSKI is completed and pledge is enrolled; intrude in it or steal and put it in some other network, it won???t matter. 

I did explain to you that BRSKI is meant to be be run every time pledge is in factory reset state.

> But the case where BRSKI runs automatically if pledge is disconnected and added to anywhere else, at least theft won???t work because pledge won???t work without re-verifying the voucher with new network/JRC.  I think this can be made mandatory in pledge to re-run BRSKI if it detects network change.

That is explcitly mentioned as a nogo in BRSKI already. Change of network you're
connecting to does not imply change of ownership.

> I still believe that Pledge need not verify JRC

We did provide a lot of answers/reasons to your questions re. why/where/how BRSKI/MASA/Voucher
are necessary/beneficial. You did not provide any technical or use-case reasoning why
those arguments are incorrect in your opinion. You  are just repeating you initial
opinion and think you can ignore the answers provided to you. 

>  But if necessary, the easy way will be following:
> 
>  
> 

That is the preferred, standard method, yes. There are mentionings of offline MASA/voucher
options, i think i the appendix.

> What I propose is, when we buy the device, MI can issue a digitally signed invoice issued to domain/JRC.

Yes, this would be one instantiation option of what we call an offline voucher,
which is covered by BRSKI. I think BRSKI also outlines the issues/limitations that can
come with offline vouchers. For example if you buy from a shop that bought
from a reseller that bought from a distributor that bought from the manufacturer,
the whole sales integration to be able to generate such a voucher may be
cost prohibitive. A key contribution of BRSKI is the concept of the logging of
voucher requests as a way to generate the hopefully most cost-reduced optoin to
generate vouchers. Which can also be applied to offline vouchers.

The various means and processes how to provide most easily vouchers in various
situations are definitely a good and long term discussion topic, even offering
opportunity to write additional draft/RFCs.

> Now when a pledge wants to validate the JRC, he simply needs to verify the signature of MI on the invoice. No communication with MASA or even MASA itself is not required. 

Yes. I have this picture in my head of a guy (called Scotty ;-) holding
a printed sales receipt with QR-code and trying to show it to his new 
router/equipment.

The classicial representation of an offline voucher is a USB stick and a
pair of sneakers to represent the physcial media and transport channel,
but i like the QR-code too to represent the potential complexities of
offline vouchers.

> It is just like the way, JRC verifies the pledge using the IDevID certificate issued by MI.

If you have a side-channel to get the voucher into the pledge, yes. But
very often in "professionally managed networks" (ANIMA charter), the guy who
gets the sales receipt could be (hundreds of) miles away from the pledge,
so in those environments its much more likely that any type of offline
voucher can easily be injected into the Registrar first than through a side
channel physcially into the pledge.

> 
> Basically you have known manufacturers and you are buying from known source. Therefore there is no hostility

Repeated incorrect conclusion. Asked and answered.

> Further it???s not a cloud environment where you don???t know, where your device is placed. Installation of pledge will be manual [barely any chance of error, until you consider humans are hostile].

Repeated incorrect conclusion. Asked and answered.

> If there were hostility, like unknown manufacturer which could give you malicious pledge, BRSKI anyway can???t detect that, since it simply checks IDevID  which is anyway signed by unknown manufacturer and will check out. You mentioned in earlier mail also that manual intervention is required for such case. [You quoted ???if the JRC does see a MI that it does not know, then it can ask a human.???]

Repeated incorrect conclusion. Asked and answered.

> There are hostile networks and pledges, but you have only whitelist of manufacturers [your assumption only ???the JRC *can* know all the legitimate manufacturers???] which only talks about known manufacturers. But it doesn???t provide security in case of unknown or known turned rogue MI/pledge. For that manual intervention is required.

Repeated incorrect conclusion. Asked and answered.

Cheers
    Toerless

>     > to which location.???

-- 
---
[email-masked]

---

From: Michael Richardson <[email-masked]>
Date: Fri, 23 Feb 2018 18:01:52 -0500

'Toerless Eckert' <[email-masked]> wrote:
    >> Now when a pledge wants to validate the JRC, he simply needs to verify
    >> the signature of MI on the invoice. No communication with MASA or even
    >> MASA itself is not required.

    > a printed sales receipt with QR-code and trying to show it to his new

("But, Dr. McCoy how do ya know this guy isn't the guy who invented secure enrollment?")

    > but i like the QR-code too to represent the potential complexities of

The voucher-on-USB-stick case is represented in the NETCONF work.

    > channel physcially into the pledge.

Additionally, equipement is often shipped directly to the data center where
it will be installed.

Upon arrival, the *data center* staff can be paid to remove it from the box
and physically install it.  This is called "remote hands".
       http://searchdatacenter.techtarget.com/definition/remote-hands
       http://www.365datacenters.com/services/remote-hands-services/

Remote hands can often be instructed to do things, but it requires a very
senior engineer to guide them, because they have to know PRECISELY what
should appear and all the situations that could go wrong.  I've worked this
kind of thing.  Too often an operational engineer flies there and does it
directly.  That's the kind of thing we are working to deal with.

Usually all one has the remote hands do is to configure some kind of
connectivity.
This means today:
     a) a "lights out" (iLO, iDRAC, etc.) network connection if it's a server.
     b) a craft (serial) console if it's a router.

The ACP document goes into this at length... the point is that BRSKI can
bootstrap that equipment even if it's the core routing equipment, as long as
the long-haul fiber goes into a compatible optical module.
(And the right lambda is used... I'd like to write a specification for
auto-detecting that part.  I suspect it doesn't need standardization)

---

From: Michael Richardson <[email-masked]>
Date: Fri, 23 Feb 2018 22:55:23 -0500

> Domain trusting pledge/manufacturer:

I tried to use your text directly, but after some editing it looked
completely different. This is what it turned into.   Edits welcome,
and better references are sought.

+8.2.  Trusting manufacturers
+
+   The BRSKI extensions to EST permit a new pledge to be completely
+   configured with domain specific trust anchors.  The link from built-
+   in manufacturer-provided trust anchors to domain-specific trust
+   anchors is mediated by the signed voucher artifact.
+
+   If the manufacturer's IDevID signing key is not properly validated,
+   then there is a risk that the network will accept a pledge that
+   should not be a member of the network.  As the address of the
+   manufacturer's MASA is provided in the IDevID using the extension
+   from Section 2.3, the malicious pledge will have no problem
+   collaborating with it's MASA to produce a completely valid voucher.
+
+   BRSKI does not, however, fundamentally change the trust model from
+   domain owner to manufacturer.  Assuming that the pledge used its
+   IDevID with RFC7030 EST and BRSKI, the domain (registrar) still needs
+   to trust the manufacturer.
+
+   Establishing this trust between domain and manufacturer is outside
+   the scope of BRSKI.  There are a number of mechanisms that can
+   adopted including:
+
+   o  Manually configuring each manufacturer's trust anchor.
+
+   o  A Trust-On-First-Use (TOFU) mechanism.  A human would be queried
+      upon seeing a manufacturer's trust anchor for the first time, and
+      then the trust anchor would be installed to the trusted store.
+      There are risks with this; even if the key to name is validated
+      using something like the WebPKI, there remains the possibility
+      that the name is a look alike: e.g, c1sco.com, ..
+
+   o  scanning the trust anchor from a QR code that came with the
+      packaging (this is really a manual TOFU mechanism)
+
+   o  some sales integration process where trust anchors are provided as
+      part of the sales process, probably included in a digital
+      packing "slip", or a sales invoice.
+
+   o  consortium membership, where all manufacturers of a particular
+      device category (e.g, a light bulb, or a cable-modem) are signed
+      by an certificate authority specifically for this.  This is done
+      by CableLabs today.  It is used for authentication and
+      authorization as part of TR-79: [docsisroot] and [TR069].
+
+   The existing WebPKI provides a reasonable anchor between manufacturer
+   name and public key.  It authenticates the key.  It does not provide
+   a reasonable authorization for the manufacturer, so it is not
+   directly useable on it's own.
+

...

Perhaps there are better references, but I'm not particularly clued into
them.  If there is someone more involved in the CMTS specifications, perhaps
you can tell me how to cite this better.

+   [docsisroot]
+              CableLabs, , "CableLabs Digital Certificate Issuance
+              Service", February 2018,
+              <https://www.cablelabs.com/resources/digital-certificate-
+              issuance-service/>.

+   [TR069]    Broadband Forum, , "TR-69: CPE WAN Management Protocol",
+              February 2018, <https://www.broadband-forum.org/standards-
+              and-software/technical-specifications/tr-069-files-tools>.