Re: [Anima] verification of manufacturer in BRSKI

[Brian E Carpenter <[e-mail]>]

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:[e-mail]] 
> Sent: 19 February 2018 05:57
> To: [e-mail]
> Cc: Anoop Kumar Pandey <[e-mail]>
> 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:[e-mail]> [e-mail]> 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:[e-mail]> [e-mail]   <http://www.sandelman.ca/> http://www.sandelman.ca/        |   ruby on rails    [
> 
>  
> 
>  
> 
> --
> 
> Michael Richardson < <mailto:[e-mail]> [e-mail]>, 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.
> -------------------------------------------------------------------------------------------------------------------------------
> 
> 
> 
> 
> _______________________________________________
> Anima mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/anima
>