Re: [Anima] verification of manufacturer in BRSKI

>"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:tte@cs.fau.de] 
Sent: 20 February 2018 11:52
To: Anoop Kumar Pandey <anoop@cdac.in>
Cc: 'Brian E Carpenter' <brian.e.carpenter@gmail.com>; 'Michael Richardson'
<mcr+ietf@sandelman.ca>; anima@ietf.org
Subject: Re: [Anima] verification of manufacturer in BRSKI

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

> 

>  

> 

> "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 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:becarpenter46@gmail.com>
mailto:becarpenter46@gmail.com] On Behalf Of 

> Brian E Carpenter

> Sent: 20 February 2018 01:00

> To: Anoop Kumar Pandey < <mailto:anoop@cdac.in> anoop@cdac.in>; 'Michael
Richardson' 

> < <mailto:mcr+ietf@sandelman.ca> mcr+ietf@sandelman.ca>;
<mailto:anima@ietf.org> anima@ietf.org

> Subject: Re: [Anima] verification of manufacturer in BRSKI

> 

>  

> 

> On 19/02/2018 21:52, Anoop Kumar Pandey wrote:

> 

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

> 

>  

> 

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

> 

>  

> 

> > 

> 

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

> 

>  

> 

> 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

> 

>  

> 

> > 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:mcr+ietf@sandelman.ca>
mailto:mcr+ietf@sandelman.ca> 

> >  <mailto:mcr+ietf@sandelman.ca> mailto:mcr+ietf@sandelman.ca]

> 

> > Sent: 19 February 2018 05:57

> 

> > To:  < <mailto:anima@ietf.org> mailto:anima@ietf.org>
<mailto:anima@ietf.org> anima@ietf.org

> 

> > Cc: Anoop Kumar Pandey < < <mailto:anoop@cdac.in> mailto:anoop@cdac.in>
<mailto:anoop@cdac.in> anoop@cdac.in>

> 

> > Subject: verification of manufacturer in BRSKI

> 

> > 

> 

> >  

> 

> > 

> 

> >  

> 

> > 

> 

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

> > out}

> 

> > 

> 

> >  

> 

> > 

> 

> > Anoop Kumar Pandey < < < <mailto:anoop@cdac.in> mailto:anoop@cdac.in>
<mailto:anoop@cdac.in> mailto:anoop@cdac.in>  < <mailto:anoop@cdac.in>
mailto:anoop@cdac.in>  <mailto:anoop@cdac.in> anoop@cdac.in> 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  [

> 

> > 

> 

> > ]      < < <mailto:mcr@sandelman.ca> mailto:mcr@sandelman.ca>
<mailto:mcr@sandelman.ca> mailto:mcr@sandelman.ca>  <
<mailto:mcr@sandelman.ca> mailto:mcr@sandelman.ca>
<mailto:mcr@sandelman.ca> mcr@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:mcr+IETF@sandelman.ca>
mailto:mcr+IETF@sandelman.ca> 

> >  <mailto:mcr+IETF@sandelman.ca> mailto:mcr+IETF@sandelman.ca>

> 

> >  < <mailto:mcr+IETF@sandelman.ca> mailto:mcr+IETF@sandelman.ca>
<mailto:mcr+IETF@sandelman.ca> mcr+IETF@sandelman.ca>, Sandelman 

> > Software Works  -= IPv6 IoT

> 

> > consulting =-

> 

> > 

> 

> >  

> 

> > 

> 

> >  

> 

> > 

> 

> >  

> 

> > 

> 

> > 

> 

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

> > --

> 

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

> 

> > [ C-DAC is on Social-Media too. Kindly follow us at:

> 

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

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

> 

> > 

> 

> > This e-mail is for the sole use of the intended recipient(s) and may

> 

> > contain confidential and privileged information. If you are not the

> 

> > intended recipient, please contact the sender by reply e-mail and

> 

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

> > review,

> 

> > use, disclosure, dissemination, forwarding, printing or copying of

> 

> > this email is strictly prohibited and appropriate legal action will be
taken.

> 

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

> > --

> 

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

> 

> > 

> 

> > 

> 

> > 

> 

> > 

> 

> > _______________________________________________

> 

> > Anima mailing list

> 

> >  < <mailto:Anima@ietf.org> mailto:Anima@ietf.org>
<mailto:Anima@ietf.org> Anima@ietf.org

> 

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

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

> 

> > 

> 

>  

> 

>  

> 

> 

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

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

> [ C-DAC is on Social-Media too. Kindly follow us at:

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

> 

> This e-mail is for the sole use of the intended recipient(s) and may 

> contain confidential and privileged information. If you are not the 

> intended recipient, please contact the sender by reply e-mail and 

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

> use, disclosure, dissemination, forwarding, printing or copying of 

> this email is strictly prohibited and appropriate legal action will be
taken.

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

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

> 

> _______________________________________________

> Anima mailing list

>  <mailto:Anima@ietf.org> Anima@ietf.org

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

--

---

 <mailto:tte@cs.fau.de> tte@cs.fau.de

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