Re: [Anima] verification of manufacturer in BRSKI

['Toerless Eckert' <[e-mail]>]

Inline

On Wed, Feb 21, 2018 at 10:15:07AM +0530, Anoop Kumar Pandey wrote:
> >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?

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.

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

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.


> Also the pledge trusts JRC if JRC is able to pass on the voucher from MASA
> 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.

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

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.

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

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.

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

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
> started deliberately?

see above.

Cheers
    Toerless

> Regards,
> 
> Anoop
> 
>  
> 
> -----Original Message-----
> From: 'Toerless Eckert' [mailto:[e-mail]] 
> Sent: 20 February 2018 21:19
> To: Anoop Kumar Pandey <[e-mail]>
> Cc: 'Brian E Carpenter' <[e-mail]>; 'Michael Richardson'
> <[e-mail]>; [e-mail]
> Subject: Re: [Anima] verification of manufacturer in BRSKI
> 
>  
> 
> 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"
> 
> 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.
> 
>  
> 
> > 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.
> 
>  
> 
> > >". 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.
> 
>  
> 
> 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.
> 
>  
> 
> > 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.
> 
>  
> 
> > 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.
> 
>  
> 
> > 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.
> 
>  
> 
> 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.
> 
>  
> 
> > 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. 
> 
>  
> 
> > 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.
> 
>  
> 
> Glad to hear. I thought you where wanting to keepg the biggest loophole in
> place (pledge will work for anybody).
> 
>  
> 
> Cheers
> 
>     Toerless
> 
>  
> 
> > Regards,
> 
> > 
> 
> > Anoop
> 
> > 
> 
> >  
> 
> > 
> 
> >  
> 
> > 
> 
> >  
> 
> > 
> 
> > -----Original Message-----
> 
> > From: Toerless Eckert [ <mailto:[e-mail]> mailto:[e-mail]]
> 
> > Sent: 20 February 2018 11:52
> 
> > To: Anoop Kumar Pandey < <mailto:[e-mail]> [e-mail]>
> 
> > Cc: 'Brian E Carpenter' < <mailto:[e-mail]>
> [e-mail]>; 'Michael Richardson'
> 
> > < <mailto:[e-mail]> [e-mail]>;
> <mailto:[e-mail]> [e-mail]
> 
> > 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/>
> 
> >  <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:[e-mail]>
> mailto:[e-mail]>
> 
> >  <mailto:[e-mail]> mailto:[e-mail]] On
> Behalf Of
> 
> > 
> 
> > > Brian E Carpenter
> 
> > 
> 
> > > Sent: 20 February 2018 01:00
> 
> > 
> 
> > > To: Anoop Kumar Pandey < < <mailto:[e-mail]> mailto:[e-mail]>
> <mailto:[e-mail]> [e-mail]>; 
> 
> > > 'Michael
> 
> > Richardson' 
> 
> > 
> 
> > > < < <mailto:[e-mail]> mailto:[e-mail]>
> <mailto:[e-mail]> [e-mail]>;
> 
> > < <mailto:[e-mail]> mailto:[e-mail]>  <mailto:[e-mail]>
> [e-mail]
> 
> > 
> 
> > > 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:[e-mail]>
> mailto:[e-mail]>
> 
> >  <mailto:[e-mail]> mailto:[e-mail]>
> 
> > 
> 
> > > >  < <mailto:[e-mail]> mailto:[e-mail]>
> <mailto:[e-mail]> mailto:[e-mail]]
> 
> > 
> 
> > > 
> 
> > 
> 
> > > > Sent: 19 February 2018 05:57
> 
> > 
> 
> > > 
> 
> > 
> 
> > > > To:  < < <mailto:[e-mail]> mailto:[e-mail]>
> <mailto:[e-mail]> mailto:[e-mail]>
> 
> > < <mailto:[e-mail]> mailto:[e-mail]>  <mailto:[e-mail]>
> [e-mail]
> 
> > 
> 
> > > 
> 
> > 
> 
> > > > Cc: Anoop Kumar Pandey < < < <mailto:[e-mail]>
> mailto:[e-mail]> 
> 
> > > >  <mailto:[e-mail]> mailto:[e-mail]>
> 
> > < <mailto:[e-mail]> mailto:[e-mail]>  <mailto:[e-mail]>
> [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]>
> mailto:[e-mail]> 
> 
> > > >  <mailto:[e-mail]> mailto:[e-mail]>
> 
> > < <mailto:[e-mail]> mailto:[e-mail]>  <mailto:[e-mail]>
> mailto:[e-mail]>  < < <mailto:[e-mail]> mailto:[e-mail]> 
> 
> >  <mailto:[e-mail]> mailto:[e-mail]>  < <mailto:[e-mail]>
> mailto:[e-mail]>  <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]> mailto:[e-mail]>
> <mailto:[e-mail]> mailto:[e-mail]>
> 
> > < <mailto:[e-mail]> mailto:[e-mail]>
> <mailto:[e-mail]> mailto:[e-mail]>  < 
> 
> > < <mailto:[e-mail]> mailto:[e-mail]>
> <mailto:[e-mail]> mailto:[e-mail]>
> 
> > < <mailto:[e-mail]> mailto:[e-mail]>
> <mailto:[e-mail]> [e-mail]   < < <
> <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:[e-mail]>
> mailto:[e-mail]>
> 
> >  <mailto:[e-mail]> mailto:[e-mail]>
> 
> > 
> 
> > > >  < <mailto:[e-mail]> mailto:[e-mail]>
> <mailto:[e-mail]> mailto:[e-mail]>
> 
> > 
> 
> > > 
> 
> > 
> 
> > > >  < < <mailto:[e-mail]> mailto:[e-mail]>
> <mailto:[e-mail]> mailto:[e-mail]>
> 
> > < <mailto:[e-mail]> mailto:[e-mail]>
> <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>
> https://www.facebook.com/CDACINDIA>
> 
> >  <https://www.facebook.com/CDACINDIA> https://www.facebook.com/CDACINDIA>
> 
> > 
> 
> > > >  < <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:[e-mail]> mailto:[e-mail]>
> <mailto:[e-mail]> mailto:[e-mail]>
> 
> > < <mailto:[e-mail]> mailto:[e-mail]>  <mailto:[e-mail]>
> [e-mail]
> 
> > 
> 
> > > 
> 
> > 
> 
> > > >  < < <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>
> 
> > 
> 
> > > >  < <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>
> 
> >  <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:[e-mail]> mailto:[e-mail]>
> <mailto:[e-mail]> [e-mail]
> 
> > 
> 
> > >  < <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
> 
> > 
> 
> >  
> 
> > 
> 
> >  
> 
> > 
> 
> > --
> 
> > 
> 
> > ---
> 
> > 
> 
> >  < <mailto:[e-mail]> mailto:[e-mail]>  <mailto:[e-mail]>
> [e-mail]
> 
> > 
> 
> > 
> 
> > ----------------------------------------------------------------------
> 
> > ---------------------------------------------------------
> 
> > [ 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.
> 
> > ----------------------------------------------------------------------
> 
> > ---------------------------------------------------------
> 
> > 
> 
>  
> 
> --
> 
> ---
> 
>  <mailto:[e-mail]> [e-mail]
> 
> 
> -------------------------------------------------------------------------------------------------------------------------------
> [ 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.
> -------------------------------------------------------------------------------------------------------------------------------
> 

-- 
---
[e-mail]