Re: [Anima] Adam Roach's Discuss on draft-ietf-anima-bootstrapping-keyinfra-22: (with DISCUSS and COMMENT)

[Eliot Lear]

> On 16 Jul 2019, at 21:29, Barry Leiba  wrote:
> 
>>> I would personally not suggest using IRIs here, given that the scheme
>>> (https) is expected to retrieve a resource at a well-known location and
>>> thus will always have to be mapped to a URI to do the retrieval (rather
>>> than used in a string comparison or something similar) .  RFC 5280,
>>> which this cites, actually goes through the steps pretty well, and I
>>> think the complexity there demonstrates the advantage for constrained
>>> devices of always using the URI form.
>> 
>> I have changed the references from IRI to URL, and the components from
>> iauthority to 'authority'.
> 
> I think the best thing for IETF documents is to use "URI" (rather than
> "URL"), and to cite RFC 3986.

And that really is what this is: it’s a URI.  Call them RESTful calls or call 
them something else but they look and smell quite RESTful to me, and REST 
requires URIs, and 3986 is a great reference.

Eliot


> 
> The W3C, via the WHATWG, is (re-)defining "URL", and we *could* cite
> that work.  That would not be my preference here.
> 
> Barry
> 
> ___
> Anima mailing list
> Anima@ietf.org
> https://www.ietf.org/mailman/listinfo/anima



signature.asc
Description: Message signed with OpenPGP
___
Anima mailing list
Anima@ietf.org
https://www.ietf.org/mailman/listinfo/anima

Re: [Anima] Adam Roach's Discuss on draft-ietf-anima-bootstrapping-keyinfra-22: (with DISCUSS and COMMENT)

[Michael Richardson]

Adam, Alexey,
  version -28 of the document contains a CDDL definiton for the audit-log
  response.

https://www.ietf.org/rfcdiff?url1=draft-ietf-anima-bootstrapping-keyinfra-27=draft-ietf-anima-bootstrapping-keyinfra-28

I hope that I'm done now!

--
Michael Richardson , Sandelman Software Works
 -= IPv6 IoT consulting =-





signature.asc
Description: PGP signature
___
Anima mailing list
Anima@ietf.org
https://www.ietf.org/mailman/listinfo/anima

Re: [Anima] Adam Roach's Discuss on draft-ietf-anima-bootstrapping-keyinfra-22: (with DISCUSS and COMMENT)

[Michael Richardson]

{clearing out todo items in my inbox}

Joel M. Halpern  wrote:
> I presume I am missing something basic.
> I have tried to follow this discussion, as it seems to be about a critical
> aspect of whether the BRSKI work is acceptable.

> I have assumed that what we needed is the ability for a buyer, who has
> physical possession of the device, and possibly some simple (non
> cryptographic) credentials provided by the seller to force the device to
> reset what it thinks it is part of, and to emit in some accessible form 
the
> information the buyer needs to be able to make this device part of his
> network, using his authentication servers, etc.

> Have I got the wrong end of the stick?

Joel, you have gotten the resale problem exactly correct.

BRSKI is primarily a protocol for a buyer, who does not wish to be forced
to assert physical possession, to assert ownership of the device.

The #1 reason why they don't want to resort to physical means is that the
local entities possessing ("remote hands") the device don't have the skills
and/or equipment to set the device up.

The #2 reason is that the device is in partial public access, and
it would be a bad thing if the physical possession interface was too easily
accessed. (Bank ATM, Airport checkin kiosk, hotel room interfaces, etc.)
This has been extended to IoT devices.

A third reason is that the devices may be difficult to actually reach
physically due to the structure and activity of the factory/plant/etc. that
they are in.  A temperature sensor 50m up a distillation tower in a refinery,
for instance.

The physical mechanisms that make the device hard to physically attack may
also make it hard for the second owner to take control of the device without
the cooperation of the first owners and/or manufacturer.

The current solution in the document is that one should, for enterprise/ISP
equipment that ANIMA applies to, continue to provide the same onboarding
processes that existed prior to ANIMA.  Specifically, a "craft" or serial 
console.

--
]   Never tell me the odds! | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works|IoT architect   [
] m...@sandelman.ca  http://www.sandelman.ca/|   ruby on rails[



--
Michael Richardson , Sandelman Software Works
 -= IPv6 IoT consulting =-





signature.asc
Description: PGP signature
___
Anima mailing list
Anima@ietf.org
https://www.ietf.org/mailman/listinfo/anima

Re: [Anima] Adam Roach's Discuss on draft-ietf-anima-bootstrapping-keyinfra-22: (with DISCUSS and COMMENT)

[Joel M. Halpern]

All three of those sound like improvements.
WHichever one you and the working group pick would clearly help.

Thank you,
Joel

On 7/17/2019 5:13 PM, Michael Richardson wrote:


Joel M. Halpern  wrote:
 > Thank you Michael.  I saw the proposed change in section 9.  I wonder
 > if that is hiding the MUST, since the mechanisms are in section 7...
 > Having said that, I can live with it as you have proposed.

I take your point. Options I see are:
1) swap the sections so section 9 (applicability) comes before 7 (reduced 
security)
2) mention the ACP applicability in section 7.
3) move the 7.2 section to section 9.

The intention with section 7 is to provide a palette of things, and let
their use be dictated by how the protocol is applied.



___
Anima mailing list
Anima@ietf.org
https://www.ietf.org/mailman/listinfo/anima

Re: [Anima] Adam Roach's Discuss on draft-ietf-anima-bootstrapping-keyinfra-22: (with DISCUSS and COMMENT)

[Michael Richardson]

Joel M. Halpern  wrote:
> Thank you Michael.  I saw the proposed change in section 9.  I wonder
> if that is hiding the MUST, since the mechanisms are in section 7...
> Having said that, I can live with it as you have proposed.

I take your point. Options I see are:
1) swap the sections so section 9 (applicability) comes before 7 (reduced 
security)
2) mention the ACP applicability in section 7.
3) move the 7.2 section to section 9.

The intention with section 7 is to provide a palette of things, and let
their use be dictated by how the protocol is applied.

-- 
]   Never tell me the odds! | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works|IoT architect   [
] m...@sandelman.ca  http://www.sandelman.ca/|   ruby on rails[

 


signature.asc
Description: PGP signature
___
Anima mailing list
Anima@ietf.org
https://www.ietf.org/mailman/listinfo/anima

Re: [Anima] Adam Roach's Discuss on draft-ietf-anima-bootstrapping-keyinfra-22: (with DISCUSS and COMMENT)

[Toerless Eckert]

Definitely. 

My main point was more about the architecture vs. protocols:

originally, ANIMA was chartered to avoid doing architectures, and it
reflects in the difficulty to even get the reference model document
accepted by our AD (for those who do not remembre). "Create only
documents that result in running code". While that latter statement
should clearly still be the outcome of further ANIMA work, my experience
from the past years is that the structure of the charter 1 documents
made it really difficult (impossible) to distinguish between the
architecture of a solution and the details of the interoperaability
protocols used to implement the architecture. In result, we had problems
what to put into voucher, how to duplicate text in Netonf Zero touch and
BRSKI and i am not even right now on top of all the IoT variations we
may get where there likely will be fever (but some) additions to the
architectural model, but more likely a lot more changes on the protocol
side.

So, i am ot quite sure how to best improve this in the future, but
thats why i bring it up as food for thought.

Cheers
Toerless

On Wed, Jul 17, 2019 at 07:38:25AM +0200, Eliot Lear wrote:
> Hi Toerless,
> 
> > On 17 Jul 2019, at 00:03, Toerless Eckert  wrote:
> > 
> > 
> > Not sure yet how to best do that, hopefully something we can discuss @105.
> 
> To the general idea??? it may be worth setting some time at the end of the 
> ANIMA WG meeting for this, or even in the onboarding/mud side meeting.  This 
> is an onboarding point??? just likely after an offboarding ;-)
> 



> ___
> Anima mailing list
> Anima@ietf.org
> https://www.ietf.org/mailman/listinfo/anima


-- 
---
t...@cs.fau.de

___
Anima mailing list
Anima@ietf.org
https://www.ietf.org/mailman/listinfo/anima

Re: [Anima] Adam Roach's Discuss on draft-ietf-anima-bootstrapping-keyinfra-22: (with DISCUSS and COMMENT)

[Eliot Lear]

Hi Toerless,

> On 17 Jul 2019, at 00:03, Toerless Eckert  wrote:
> 
> 
> Not sure yet how to best do that, hopefully something we can discuss @105.

To the general idea… it may be worth setting some time at the end of the ANIMA 
WG meeting for this, or even in the onboarding/mud side meeting.  This is an 
onboarding point… just likely after an offboarding ;-)



signature.asc
Description: Message signed with OpenPGP
___
Anima mailing list
Anima@ietf.org
https://www.ietf.org/mailman/listinfo/anima

Re: [Anima] Adam Roach's Discuss on draft-ietf-anima-bootstrapping-keyinfra-22: (with DISCUSS and COMMENT)

[Toerless Eckert]

Adam,

Not sure if you saw my reply to Alissas comments, but my biggest concern
no only to fudge more and more bits and pieces into thre tailend of this
draft (+1 to birans comment), but also to continue fudge them as protocol
extensions into the BRSKI protocol when in reality the problems we should
solve are at the architectural level, whatever protocol we use. All the
things discussed here, and i think including Eliots idea would for example
equally apply to RFC8572, so we would IMHO do a better job overall if from
now on we would try to figue out a way to define extensions to the voucher
system (or secure node behavior) in a protocol independent fashion 
(architecturally)
first, and then just have simple adoptions to the specific protocols
that want to have those extensions (BRSKI, NetConf, or whatever IoT
derivations i am sure will come up).

Not sure yet how to best do that, hopefully something we can discuss @105.

Wrt to Eliots suggestion: Its quite interesting and maybe the only one
for some slice of products, but If was thinking what really would mean 
"owning" to me, then thats the ability to replace the root trust
anchor(s) in the device with my own. And there are cases where products
at least support ADDING such trust anchors in a way that factory reset
won't remove them (and only leave vendor TAs). 

Cheers
Toerless

On Mon, Jul 15, 2019 at 10:52:02AM -0500, Adam Roach wrote:
> 
> 
> > On Jul 15, 2019, at 02:39, Eliot Lear  wrote:
> > 
> > To Adam???s broader point, there are at least several ways to approach 
> > this.  We can leave it to the vendor to decide which is correct, and we can 
> > continue to look to standardize ideas such as the one Michael had in the 
> > message I???m replying to now.
> 
> Yes; I think this is the important thing, and that specific mechanisms ??? if 
> we believe they are useful to define ??? could be worked on later. 
> 
> /a
> ___
> Anima mailing list
> Anima@ietf.org
> https://www.ietf.org/mailman/listinfo/anima

-- 
---
t...@cs.fau.de

___
Anima mailing list
Anima@ietf.org
https://www.ietf.org/mailman/listinfo/anima

Re: [Anima] Adam Roach's Discuss on draft-ietf-anima-bootstrapping-keyinfra-22: (with DISCUSS and COMMENT)

[Adam Roach]

Michael --

Thanks so much for your work on closing this issue. Assuming the rest of 
the WG agrees with it, your proposed text satisfies my concern. I've 
indicated two minor nits below.


On 7/16/19 12:55 PM, Michael Richardson wrote:

   
 As specified in the ANIMA charter, this work "..focuses on
 professionally-managed networks."  Such a network has an operator
 and can do things like install, configure and operate the
 Registrar function.  The operator makes purchasing decisions
 and is aware of what manufacturers it expects to see on it's
 network.
   



Nit: "...on its network..."



   
 Such an operator is also capable of performing bootstrapping of a
 device using a serial-console (craft console). The zero-touch
 mechanism presented in this and the ACP document represents a



Nit: add a citation for "ACP document"


Thanks!

/a

___
Anima mailing list
Anima@ietf.org
https://www.ietf.org/mailman/listinfo/anima

Re: [Anima] Adam Roach's Discuss on draft-ietf-anima-bootstrapping-keyinfra-22: (with DISCUSS and COMMENT)

[Joel M. Halpern]

With the mandates that Michael proposed adding, I can live with 
advancing the document.

Yours,
Joel

On 7/16/2019 4:31 PM, Brian E Carpenter wrote:

Up-levelling the topic a little bit:

It seems to me that from the amount of interest and discussion, BRSKI
is going to be quite important (or a resounding failure, in which case
this is all beside the point). Assuming it's a success, there will
inevitably be updates and enhancements.

So, I'd prefer that we don't try to solve all problems now. I'd rather
get the first version to Proposed Standard next week...

Regards
Brian Carpenter

On 17-Jul-19 01:57, Joel M. Halpern wrote:

I can't tell from this whether you agree that it is reasonable to put in
some mechanism to address this issue?

Yours,
Joel

On 7/16/2019 9:40 AM, Eliot Lear wrote:

Hi Joel,




On 16 Jul 2019, at 14:59, Joel Halpern Direct  
wrote:

I am having trouble connecting your reply with my request.
Let's take the direct issue first, and then the analogy.

I had suggested a specific enhancement to device behavior.  The response was "but 
that removes the theft protection."  It is that form of theft protection that I am 
objecting to.  As far as I can tell, the mechanism I suggested does not break zero touch. 
 It allows someone who controls their network, and who physically controls a new device, 
to put that new device in their network without asking anyone's permission.
It does not permit someone with a device, but not network control, from adding 
that device to the network.  It does not permit someone with control of the 
network, but not physical access to the device, to achieve anything special.  
So it seems compatible with the goals.


My apologies I took your statement as something more general than you intended. 
 With respect to this from earlier:


I have assumed that what we needed is the ability for a buyer, who has physical 
possession of the device, and possibly some simple (non cryptographic) 
credentials provided by the seller to force the device to reset what it thinks 
it is part of, and to emit in some accessible form the information the buyer 
needs to be able to make this device part of his network, using his 
authentication servers, etc.



That was indeed what we discussed.  We just got into means a bit more than 
perhaps necessary.  I’ll point out that it’s always going to be a manufacturer 
call on how best to do this; and how to transport credentials, and how to keep 
them safe, even.



In terms of the analogy, I would have problem with IEtF defining a new protocol 
that added significant risk to the buyer when they buy from new vendors.
And existing vendors do go out of businesses.  And vendors do end-of-life 
products.  (You can't get a new key to your car because the vendor has stopped 
supporting that model???)


I wouldn’t implement a 1:1 mapping products->MASA server function.  That seems 
excessive.  And rare is the case when a vendor EOLs a product and then cripples it 
through an update mechanism.  The only issue here is whether a database entry 
would stay around.




Now it may be that the particular approach I suggested won't work.  But it 
seems to me that there needs to be a way for folks to keep using, and to keep 
re-selling, devices without the support of the vendor.  That usage may not get 
all the zero-touch advantages that supported re-sale would get.  But it has to 
work.  And putting the onus for that on the original vendor does NOT seem an 
effective solution.


I think you mean, “requiring the vendor to stay around for ever doesn’t seem 
like an effective solution.”  Again, I don’t want to overgeneralize.

Eliot



___
Anima mailing list
Anima@ietf.org
https://www.ietf.org/mailman/listinfo/anima





___
Anima mailing list
Anima@ietf.org
https://www.ietf.org/mailman/listinfo/anima

Re: [Anima] Adam Roach's Discuss on draft-ietf-anima-bootstrapping-keyinfra-22: (with DISCUSS and COMMENT)

[Brian E Carpenter]

Up-levelling the topic a little bit:

It seems to me that from the amount of interest and discussion, BRSKI
is going to be quite important (or a resounding failure, in which case
this is all beside the point). Assuming it's a success, there will
inevitably be updates and enhancements.

So, I'd prefer that we don't try to solve all problems now. I'd rather
get the first version to Proposed Standard next week...

Regards
   Brian Carpenter

On 17-Jul-19 01:57, Joel M. Halpern wrote:
> I can't tell from this whether you agree that it is reasonable to put in 
> some mechanism to address this issue?
> 
> Yours,
> Joel
> 
> On 7/16/2019 9:40 AM, Eliot Lear wrote:
>> Hi Joel,
>>
>>
>>
>>> On 16 Jul 2019, at 14:59, Joel Halpern Direct  
>>> wrote:
>>>
>>> I am having trouble connecting your reply with my request.
>>> Let's take the direct issue first, and then the analogy.
>>>
>>> I had suggested a specific enhancement to device behavior.  The response 
>>> was "but that removes the theft protection."  It is that form of theft 
>>> protection that I am objecting to.  As far as I can tell, the mechanism I 
>>> suggested does not break zero touch.  It allows someone who controls their 
>>> network, and who physically controls a new device, to put that new device 
>>> in their network without asking anyone's permission.
>>> It does not permit someone with a device, but not network control, from 
>>> adding that device to the network.  It does not permit someone with control 
>>> of the network, but not physical access to the device, to achieve anything 
>>> special.  So it seems compatible with the goals.
>>
>> My apologies I took your statement as something more general than you 
>> intended.  With respect to this from earlier:
>>
>>> I have assumed that what we needed is the ability for a buyer, who has 
>>> physical possession of the device, and possibly some simple (non 
>>> cryptographic) credentials provided by the seller to force the device to 
>>> reset what it thinks it is part of, and to emit in some accessible form the 
>>> information the buyer needs to be able to make this device part of his 
>>> network, using his authentication servers, etc.
>>
>>
>> That was indeed what we discussed.  We just got into means a bit more than 
>> perhaps necessary.  I’ll point out that it’s always going to be a 
>> manufacturer call on how best to do this; and how to transport credentials, 
>> and how to keep them safe, even.
>>
>>>
>>> In terms of the analogy, I would have problem with IEtF defining a new 
>>> protocol that added significant risk to the buyer when they buy from new 
>>> vendors.
>>> And existing vendors do go out of businesses.  And vendors do end-of-life 
>>> products.  (You can't get a new key to your car because the vendor has 
>>> stopped supporting that model???)
>>
>> I wouldn’t implement a 1:1 mapping products->MASA server function.  That 
>> seems excessive.  And rare is the case when a vendor EOLs a product and then 
>> cripples it through an update mechanism.  The only issue here is whether a 
>> database entry would stay around.
>>
>>
>>>
>>> Now it may be that the particular approach I suggested won't work.  But it 
>>> seems to me that there needs to be a way for folks to keep using, and to 
>>> keep re-selling, devices without the support of the vendor.  That usage may 
>>> not get all the zero-touch advantages that supported re-sale would get.  
>>> But it has to work.  And putting the onus for that on the original vendor 
>>> does NOT seem an effective solution.
>>
>> I think you mean, “requiring the vendor to stay around for ever doesn’t seem 
>> like an effective solution.”  Again, I don’t want to overgeneralize.
>>
>> Eliot
>>
> 
> ___
> Anima mailing list
> Anima@ietf.org
> https://www.ietf.org/mailman/listinfo/anima
> 

___
Anima mailing list
Anima@ietf.org
https://www.ietf.org/mailman/listinfo/anima

Re: [Anima] Adam Roach's Discuss on draft-ietf-anima-bootstrapping-keyinfra-22: (with DISCUSS and COMMENT)

[Michael Richardson]

Adam Roach  wrote:
>> On Jul 15, 2019, at 02:39, Eliot Lear  wrote:
>> 
>> This give you the option for that not to be the case (people needn’t
>> worry about Siemens, Rockwell, JCI, Honeywell, or Schneider Electric
>> going out of business anytime soon, for instance

> When I started IETF work, Nortel would have been on your list.

It's a really good example, and I use it all the time when talking about this 
work.

I bought some very cheap shares just before they stopped trading, because I
thought that they might get bailed out.  So I get updates on where it is in
the bankruptcy process.  It's still not over.  The company technically still
exists.  Their VPN boxes are amazingly, still in use in my town.

I want to point out that this is why we wrote Manufacturer *AUTHORIZED*
Signing Authority.  We envision that this is a process that can be
outsourced, and that customers will insist that it is escowed.  25 years ago,
when I worked in one of the first firewall companies, dead 20 years now, I
regularly provided escrow tapes.  It's almost never worth the customers'
money to use them, but I'm sure someone has used them.

-- 
Michael Richardson , Sandelman Software Works
 -= IPv6 IoT consulting =-





signature.asc
Description: PGP signature
___
Anima mailing list
Anima@ietf.org
https://www.ietf.org/mailman/listinfo/anima

Re: [Anima] Adam Roach's Discuss on draft-ietf-anima-bootstrapping-keyinfra-22: (with DISCUSS and COMMENT)

[Joel M. Halpern]

Thank you Michael.  I saw the proposed change in section 9.  I wonder if 
that is hiding the MUST, since the mechanisms are in section 7...

Having said that, I can live with it as you have proposed.

Yours,
Joel

On 7/16/2019 3:47 PM, Michael Richardson wrote:


Joel Halpern Direct  wrote:
 > It allows someone who
 > controls their network, and who physically controls a new device, to
 > put that new device in their network without asking anyone's
 > permission.

Right, get your "blue cable" out, connect it to the serial console, bring up
minicom, and tell the device to enroll.  Verify the registrar's certificate
when prompted, perhaps.

You can still use GRASP to find the Registrar, and all the rest of the ACP
mechanism  or not.

That's been in section 7.2, but the complaint was that it was not normative.
So, we have added in section 9, for the ACP use case, that implementing
something is a MUST.  I don't think it will work for lightbulbs, but whomever
writes that Applicability Statement will have to cope with that.
(it will be me: I have a document in 6tisch, which is that document. I would
appreciate your thoughts on what might be acceptable there)

BTW: A number of router manufacturers have BRSKI-like mechanisms already, but 
they
only really work when you drink all their koolaid, and build your network
exclusively with their equipment.  At one ISP that I consult for, they wound
up turning the super-duper auto-join management system off because it ate all
of a very high end VM platform, and they just couldn't afford that at the
time...   Maybe cross-vendor mechanisms will result in some competition and
some better products.

 > Now it may be that the particular approach I suggested won't work.  But
 > it seems to me that there needs to be a way for folks to keep using,
 > and to keep re-selling, devices without the support of the vendor.
 > That usage may not get all the zero-touch advantages that supported
 > re-sale would get.  But it has to work.  And putting the onus for that
 > on the original vendor does NOT seem an effective solution.

As long as vendors support blue cables, and are willing to provide firmware
updates, I don't see any change.



___
Anima mailing list
Anima@ietf.org
https://www.ietf.org/mailman/listinfo/anima

Re: [Anima] Adam Roach's Discuss on draft-ietf-anima-bootstrapping-keyinfra-22: (with DISCUSS and COMMENT)

[Michael Richardson]

Joel Halpern Direct  wrote:
> It allows someone who
> controls their network, and who physically controls a new device, to
> put that new device in their network without asking anyone's
> permission.

Right, get your "blue cable" out, connect it to the serial console, bring up
minicom, and tell the device to enroll.  Verify the registrar's certificate
when prompted, perhaps.

You can still use GRASP to find the Registrar, and all the rest of the ACP
mechanism  or not.

That's been in section 7.2, but the complaint was that it was not normative.
So, we have added in section 9, for the ACP use case, that implementing
something is a MUST.  I don't think it will work for lightbulbs, but whomever
writes that Applicability Statement will have to cope with that.
(it will be me: I have a document in 6tisch, which is that document. I would
appreciate your thoughts on what might be acceptable there)

BTW: A number of router manufacturers have BRSKI-like mechanisms already, but 
they
only really work when you drink all their koolaid, and build your network
exclusively with their equipment.  At one ISP that I consult for, they wound
up turning the super-duper auto-join management system off because it ate all
of a very high end VM platform, and they just couldn't afford that at the
time...   Maybe cross-vendor mechanisms will result in some competition and
some better products. 

> Now it may be that the particular approach I suggested won't work.  But
> it seems to me that there needs to be a way for folks to keep using,
> and to keep re-selling, devices without the support of the vendor.
> That usage may not get all the zero-touch advantages that supported
> re-sale would get.  But it has to work.  And putting the onus for that
> on the original vendor does NOT seem an effective solution.

As long as vendors support blue cables, and are willing to provide firmware
updates, I don't see any change. 

-- 
]   Never tell me the odds! | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works|IoT architect   [
] m...@sandelman.ca  http://www.sandelman.ca/|   ruby on rails[



signature.asc
Description: PGP signature
___
Anima mailing list
Anima@ietf.org
https://www.ietf.org/mailman/listinfo/anima

Re: [Anima] Adam Roach's Discuss on draft-ietf-anima-bootstrapping-keyinfra-22: (with DISCUSS and COMMENT)

[Michael Richardson]

Adam Roach  wrote:
> On 7/15/19 3:38 PM, Brian E Carpenter wrote:
>> On 15-Jul-19 16:45, Joel M. Halpern wrote:
>>> I presume I am missing something basic.  I have tried to follow this
>>> discussion, as it seems to be about a critical aspect of whether the
>>> BRSKI work is acceptable.
>>> 
>>> I have assumed that what we needed is the ability for a buyer, who
>>> has physical possession of the device, and possibly some simple (non
>>> cryptographic) credentials provided by the seller to force the device
>>> to reset what it thinks it is part of, and to emit in some accessible
>>> form the information the buyer needs to be able to make this device
>>> part of his network, using his authentication servers, etc.

>> Yes, but *not* a solution that works if the device is stolen.

> I'm actually a little ambivalent with respect to this use case. For the
> kind of devices that the document purports to be targeting, I would
> imagine that theft is in the range of parts-per-thousand (or lower) as
> compared to things like post-bankruptcy liquidation. If you can fix the
> first without ruining the second, great.

I mostly agree!

While a great deal of the ACP use case deals with physically large devices
which are in datacenters, in locked cages, there are aspects where we are
dealing with devices in significantly more vulnerable places.  This ranges
From FTTN equipment in a box on a nearby curb, to ISP owned CPE devices
physically in people's homes [%].

But, the more vulnerable devices are also of lower dollar value.
We are mandating vendors to provide *A* way, but that doesn't have to
be an enable prompt with no password.
There could be a one-time-password on the port. 
S/Key would fine given the initial seed provided in the packaging.

draft-wkumari-opsawg-sdi would also work, the initial configuration could
include "est-enroll [2001:db8:0:1]:443".

[%] the CPE CMTS use case is the domain of TR-069. I don't know what DSL
providers do, some have service PPPoE username/password that they use.

Let other use cases write different requirements for access.

-- 
]   Never tell me the odds! | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works|IoT architect   [
] m...@sandelman.ca  http://www.sandelman.ca/|   ruby on rails[



signature.asc
Description: PGP signature
___
Anima mailing list
Anima@ietf.org
https://www.ietf.org/mailman/listinfo/anima

Re: [Anima] Adam Roach's Discuss on draft-ietf-anima-bootstrapping-keyinfra-22: (with DISCUSS and COMMENT)

[Barry Leiba]

> > I would personally not suggest using IRIs here, given that the scheme
> > (https) is expected to retrieve a resource at a well-known location and
> > thus will always have to be mapped to a URI to do the retrieval (rather
> > than used in a string comparison or something similar) .  RFC 5280,
> > which this cites, actually goes through the steps pretty well, and I
> > think the complexity there demonstrates the advantage for constrained
> > devices of always using the URI form.
>
> I have changed the references from IRI to URL, and the components from
> iauthority to 'authority'.

I think the best thing for IETF documents is to use "URI" (rather than
"URL"), and to cite RFC 3986.

The W3C, via the WHATWG, is (re-)defining "URL", and we *could* cite
that work.  That would not be my preference here.

Barry

___
Anima mailing list
Anima@ietf.org
https://www.ietf.org/mailman/listinfo/anima

Re: [Anima] Adam Roach's Discuss on draft-ietf-anima-bootstrapping-keyinfra-22: (with DISCUSS and COMMENT)

[Michael Richardson]

Adam Roach  wrote:
> "HTTP", but even that may be unnecessary in this case.

> REST means... something. Exactly what depends on who you ask. In
> practice, the least controversial thing to do is avoid the term; and,
> if you're trying to describe a specific quality (e.g., idempotence),
> say so explicitly.

I have removed the two occurences of "RESTful", and in the place where
we use 201-Created w/Location:, I mentioned that it is the idempotency that
is probably important.

-- 
]   Never tell me the odds! | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works|IoT architect   [
] m...@sandelman.ca  http://www.sandelman.ca/|   ruby on rails[



signature.asc
Description: PGP signature
___
Anima mailing list
Anima@ietf.org
https://www.ietf.org/mailman/listinfo/anima

Re: [Anima] Adam Roach's Discuss on draft-ietf-anima-bootstrapping-keyinfra-22: (with DISCUSS and COMMENT)

[Michael Richardson]

Ted Hardie  wrote:
> Howdy,

> I would personally not suggest using IRIs here, given that the scheme
> (https) is expected to retrieve a resource at a well-known location and
> thus will always have to be mapped to a URI to do the retrieval (rather
> than used in a string comparison or something similar) .  RFC 5280,
> which this cites, actually goes through the steps pretty well, and I
> think the complexity there demonstrates the advantage for constrained
> devices of always using the URI form.

I have changed the references from IRI to URL, and the components from
iauthority to 'authority'.

-- 
]   Never tell me the odds! | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works|IoT architect   [
] m...@sandelman.ca  http://www.sandelman.ca/|   ruby on rails[



signature.asc
Description: PGP signature
___
Anima mailing list
Anima@ietf.org
https://www.ietf.org/mailman/listinfo/anima

Re: [Anima] Adam Roach's Discuss on draft-ietf-anima-bootstrapping-keyinfra-22: (with DISCUSS and COMMENT)

[Michael Richardson]

Adam Roach  wrote:
mcr> *** but manufacturers have to want to do it ***


adam> I completely agree with everything you just said, and sincerely
adam> thank you for the work you've done in this area. I think where our
adam> perspectives might diverge is our beliefs about what *we*, the
adam> IETF, can do about it in this specific case.

adam> The IETF, as a matter of practice, includes normative statements in
adam> documents all the time regarding processes that conformant
adam> implementations "MUST" follow for the sake of security. In many
adam> cases, the protocol works just fine if implementors ignore these
adam> requirements, which means that implementation of them resolves to
adam> exactly one thing:  manufacturers have to want to do it.



adam> The smallest change that would satisfy my concern would be a statement
adam> that says that devices conformant to this specification MUST contain a
adam> local means of bootstrapping that does not rely on any specific server
adam> being available.

I propose to add text to section 9:
  Applicability to the Autonomic Control Plane

that makes implementing something from 7.2 a normative MUST.

  
As specified in the ANIMA charter, this work "..focuses on
professionally-managed networks."  Such a network has an operator
and can do things like install, configure and operate the
Registrar function.  The operator makes purchasing decisions
and is aware of what manufacturers it expects to see on it's
network.
  
  
Such an operator is also capable of performing bootstrapping of a
device using a serial-console (craft console). The zero-touch
mechanism presented in this and the ACP document represents a
significiant efficiency: in particular it reduces the need to
put senior experts on airplanes to configure devices in person.
  
  
There is a recognition as the technology evolves that not every
situation may work out, and occasionally a human may still have to
visit.  In recognition of this, some mechanisms are presented in
. The manufacturer MUST provide at
least one of the one-touch mechanisms described that permit
enrollment to be proceed without availability of any manufacturer
server (such as the MASA).
  

I have additionally, added a fourth example to section 7.2:

   4.  A craft/serial console COULD include a command such as "est-
   enroll [2001:db8:0:1]:443" that begins the EST process from the
   point after the voucher is validated.  This process SHOULD
   include server certificate verification using an on-screen
   fingerprint.

--
]   Never tell me the odds! | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works|IoT architect   [
] m...@sandelman.ca  http://www.sandelman.ca/|   ruby on rails[



--
Michael Richardson , Sandelman Software Works
 -= IPv6 IoT consulting =-





signature.asc
Description: PGP signature
___
Anima mailing list
Anima@ietf.org
https://www.ietf.org/mailman/listinfo/anima

Re: [Anima] Adam Roach's Discuss on draft-ietf-anima-bootstrapping-keyinfra-22: (with DISCUSS and COMMENT)

[Eliot Lear]

> On 16 Jul 2019, at 15:57, Joel M. Halpern  wrote:
> 
> I can't tell from this whether you agree that it is reasonable to put in some 
> mechanism to address this issue?

I think I do because I proposed such a mechanism up thread.

Eliot
> 
> Yours,
> Joel
> 
> On 7/16/2019 9:40 AM, Eliot Lear wrote:
>> Hi Joel,
>>> On 16 Jul 2019, at 14:59, Joel Halpern Direct  
>>> wrote:
>>> 
>>> I am having trouble connecting your reply with my request.
>>> Let's take the direct issue first, and then the analogy.
>>> 
>>> I had suggested a specific enhancement to device behavior.  The response 
>>> was "but that removes the theft protection."  It is that form of theft 
>>> protection that I am objecting to.  As far as I can tell, the mechanism I 
>>> suggested does not break zero touch.  It allows someone who controls their 
>>> network, and who physically controls a new device, to put that new device 
>>> in their network without asking anyone's permission.
>>> It does not permit someone with a device, but not network control, from 
>>> adding that device to the network.  It does not permit someone with control 
>>> of the network, but not physical access to the device, to achieve anything 
>>> special.  So it seems compatible with the goals.
>> My apologies I took your statement as something more general than you 
>> intended.  With respect to this from earlier:
>>> I have assumed that what we needed is the ability for a buyer, who has 
>>> physical possession of the device, and possibly some simple (non 
>>> cryptographic) credentials provided by the seller to force the device to 
>>> reset what it thinks it is part of, and to emit in some accessible form the 
>>> information the buyer needs to be able to make this device part of his 
>>> network, using his authentication servers, etc.
>> That was indeed what we discussed.  We just got into means a bit more than 
>> perhaps necessary.  I’ll point out that it’s always going to be a 
>> manufacturer call on how best to do this; and how to transport credentials, 
>> and how to keep them safe, even.
>>> 
>>> In terms of the analogy, I would have problem with IEtF defining a new 
>>> protocol that added significant risk to the buyer when they buy from new 
>>> vendors.
>>> And existing vendors do go out of businesses.  And vendors do end-of-life 
>>> products.  (You can't get a new key to your car because the vendor has 
>>> stopped supporting that model???)
>> I wouldn’t implement a 1:1 mapping products->MASA server function.  That 
>> seems excessive.  And rare is the case when a vendor EOLs a product and then 
>> cripples it through an update mechanism.  The only issue here is whether a 
>> database entry would stay around.
>>> 
>>> Now it may be that the particular approach I suggested won't work.  But it 
>>> seems to me that there needs to be a way for folks to keep using, and to 
>>> keep re-selling, devices without the support of the vendor.  That usage may 
>>> not get all the zero-touch advantages that supported re-sale would get.  
>>> But it has to work.  And putting the onus for that on the original vendor 
>>> does NOT seem an effective solution.
>> I think you mean, “requiring the vendor to stay around for ever doesn’t seem 
>> like an effective solution.”  Again, I don’t want to overgeneralize.
>> Eliot



signature.asc
Description: Message signed with OpenPGP
___
Anima mailing list
Anima@ietf.org
https://www.ietf.org/mailman/listinfo/anima

Re: [Anima] Adam Roach's Discuss on draft-ietf-anima-bootstrapping-keyinfra-22: (with DISCUSS and COMMENT)

[Joel M. Halpern]

I can't tell from this whether you agree that it is reasonable to put in 
some mechanism to address this issue?


Yours,
Joel

On 7/16/2019 9:40 AM, Eliot Lear wrote:

Hi Joel,




On 16 Jul 2019, at 14:59, Joel Halpern Direct  
wrote:

I am having trouble connecting your reply with my request.
Let's take the direct issue first, and then the analogy.

I had suggested a specific enhancement to device behavior.  The response was "but 
that removes the theft protection."  It is that form of theft protection that I am 
objecting to.  As far as I can tell, the mechanism I suggested does not break zero touch. 
 It allows someone who controls their network, and who physically controls a new device, 
to put that new device in their network without asking anyone's permission.
It does not permit someone with a device, but not network control, from adding 
that device to the network.  It does not permit someone with control of the 
network, but not physical access to the device, to achieve anything special.  
So it seems compatible with the goals.


My apologies I took your statement as something more general than you intended. 
 With respect to this from earlier:


I have assumed that what we needed is the ability for a buyer, who has physical 
possession of the device, and possibly some simple (non cryptographic) 
credentials provided by the seller to force the device to reset what it thinks 
it is part of, and to emit in some accessible form the information the buyer 
needs to be able to make this device part of his network, using his 
authentication servers, etc.



That was indeed what we discussed.  We just got into means a bit more than 
perhaps necessary.  I’ll point out that it’s always going to be a manufacturer 
call on how best to do this; and how to transport credentials, and how to keep 
them safe, even.



In terms of the analogy, I would have problem with IEtF defining a new protocol 
that added significant risk to the buyer when they buy from new vendors.
And existing vendors do go out of businesses.  And vendors do end-of-life 
products.  (You can't get a new key to your car because the vendor has stopped 
supporting that model???)


I wouldn’t implement a 1:1 mapping products->MASA server function.  That seems 
excessive.  And rare is the case when a vendor EOLs a product and then cripples it 
through an update mechanism.  The only issue here is whether a database entry 
would stay around.




Now it may be that the particular approach I suggested won't work.  But it 
seems to me that there needs to be a way for folks to keep using, and to keep 
re-selling, devices without the support of the vendor.  That usage may not get 
all the zero-touch advantages that supported re-sale would get.  But it has to 
work.  And putting the onus for that on the original vendor does NOT seem an 
effective solution.


I think you mean, “requiring the vendor to stay around for ever doesn’t seem 
like an effective solution.”  Again, I don’t want to overgeneralize.

Eliot



___
Anima mailing list
Anima@ietf.org
https://www.ietf.org/mailman/listinfo/anima

Re: [Anima] Adam Roach's Discuss on draft-ietf-anima-bootstrapping-keyinfra-22: (with DISCUSS and COMMENT)

[Eliot Lear]

Hi Joel,



> On 16 Jul 2019, at 14:59, Joel Halpern Direct  
> wrote:
> 
> I am having trouble connecting your reply with my request.
> Let's take the direct issue first, and then the analogy.
> 
> I had suggested a specific enhancement to device behavior.  The response was 
> "but that removes the theft protection."  It is that form of theft protection 
> that I am objecting to.  As far as I can tell, the mechanism I suggested does 
> not break zero touch.  It allows someone who controls their network, and who 
> physically controls a new device, to put that new device in their network 
> without asking anyone's permission.
> It does not permit someone with a device, but not network control, from 
> adding that device to the network.  It does not permit someone with control 
> of the network, but not physical access to the device, to achieve anything 
> special.  So it seems compatible with the goals.

My apologies I took your statement as something more general than you intended. 
 With respect to this from earlier:

> I have assumed that what we needed is the ability for a buyer, who has 
> physical possession of the device, and possibly some simple (non 
> cryptographic) credentials provided by the seller to force the device to 
> reset what it thinks it is part of, and to emit in some accessible form the 
> information the buyer needs to be able to make this device part of his 
> network, using his authentication servers, etc.


That was indeed what we discussed.  We just got into means a bit more than 
perhaps necessary.  I’ll point out that it’s always going to be a manufacturer 
call on how best to do this; and how to transport credentials, and how to keep 
them safe, even.

> 
> In terms of the analogy, I would have problem with IEtF defining a new 
> protocol that added significant risk to the buyer when they buy from new 
> vendors.
> And existing vendors do go out of businesses.  And vendors do end-of-life 
> products.  (You can't get a new key to your car because the vendor has 
> stopped supporting that model???)

I wouldn’t implement a 1:1 mapping products->MASA server function.  That seems 
excessive.  And rare is the case when a vendor EOLs a product and then cripples 
it through an update mechanism.  The only issue here is whether a database 
entry would stay around.


> 
> Now it may be that the particular approach I suggested won't work.  But it 
> seems to me that there needs to be a way for folks to keep using, and to keep 
> re-selling, devices without the support of the vendor.  That usage may not 
> get all the zero-touch advantages that supported re-sale would get.  But it 
> has to work.  And putting the onus for that on the original vendor does NOT 
> seem an effective solution.

I think you mean, “requiring the vendor to stay around for ever doesn’t seem 
like an effective solution.”  Again, I don’t want to overgeneralize.

Eliot



signature.asc
Description: Message signed with OpenPGP
___
Anima mailing list
Anima@ietf.org
https://www.ietf.org/mailman/listinfo/anima

Re: [Anima] Adam Roach's Discuss on draft-ietf-anima-bootstrapping-keyinfra-22: (with DISCUSS and COMMENT)

[Joel Halpern Direct]

I am having trouble connecting your reply with my request.
Let's take the direct issue first, and then the analogy.

I had suggested a specific enhancement to device behavior.  The response 
was "but that removes the theft protection."  It is that form of theft 
protection that I am objecting to.  As far as I can tell, the mechanism 
I suggested does not break zero touch.  It allows someone who controls 
their network, and who physically controls a new device, to put that new 
device in their network without asking anyone's permission.
It does not permit someone with a device, but not network control, from 
adding that device to the network.  It does not permit someone with 
control of the network, but not physical access to the device, to 
achieve anything special.  So it seems compatible with the goals.


In terms of the analogy, I would have problem with IEtF defining a new 
protocol that added significant risk to the buyer when they buy from new 
vendors.
And existing vendors do go out of businesses.  And vendors do 
end-of-life products.  (You can't get a new key to your car because the 
vendor has stopped supporting that model???)


Now it may be that the particular approach I suggested won't work.  But 
it seems to me that there needs to be a way for folks to keep using, and 
to keep re-selling, devices without the support of the vendor.  That 
usage may not get all the zero-touch advantages that supported re-sale 
would get.  But it has to work.  And putting the onus for that on the 
original vendor does NOT seem an effective solution.


Yours,
Joel

On 7/16/2019 7:21 AM, Eliot Lear wrote:

Hi Joel,

On 15 Jul 2019, at 23:42, Joel M. Halpern > wrote:


I would probably go a step further than Adam.  Protecting the device 
so a thief can not use it in the thiefs' own network seems to me to be 
something that we should not be trying to achieve.  An active 
non-goal. It is not our problem.


 And trying to achieve it has the implications that lead to this whole 
discussion about the original manufacturer controlling who can resell 
/ re-buy the device.


I would rather we redressed this directly.  There is an entire work flow 
that involves zero-touch provisioning that at least two, and likely four 
large platforms are driving toward, that *all* require some sort of 
manufacturer assertion for device ownership to be transferred.  This is 
not just a good idea or an anti-theft mechanism, but an aspect that is 
required for zero-touch, particularly with wireless, where network 
selection has to occur.  While in that sense, you might say, “Anti-theft 
wasn’t the goal”, it is certainly a nice add-on, and it seems like a 
valuable function.


Personally I *like* that we had this discussion.  I think the BRSKI work 
will be much improved because of it, and people have a better 
understanding of how the mechanisms can be used/abused as a result.  I 
only wish we had had it earlier.


So now let’s talk about anti-theft and counterfeiting.  BRSKI has an 
interesting link to both.  If a manufacturer is able to show the 
customer what devices have been registered, any device that seems to be 
operational but is NOT registered has to be considered suspect by the 
customer.  That’s a nice counterfeit protection, and it isn’t there by 
accident.


Similarly having a way to say, “the thing won’t join an unauthorized 
network” is a very strong theft deterrent, very much akin to the 
electronic keys that we see now in cars.  You generally can no longer go 
to the local locksmith to get a duplicate key for a great many cars, but 
your theft insurance has dropped through the floor (particularly if you 
own a Honda).  Might GM, Ford, BMW etc might fail?  Sure.  No more new 
keys for those cars: the old ones had better suffice.


In this case we discussed several approaches to deal with the case where 
the supplier drops dead.  IMHO that’s a good outcome.


Eliot




 While manufacturers may like that, it does not seem to be something 
we should get involved in. At all.


Yours,
Joel

On 7/15/2019 5:10 PM, Adam Roach wrote:

On 7/15/19 3:38 PM, Brian E Carpenter wrote:

On 15-Jul-19 16:45, Joel M. Halpern wrote:

I presume I am missing something basic.
I have tried to follow this discussion, as it seems to be about a
critical aspect of whether the BRSKI work is acceptable.

I have assumed that what we needed is the ability for a buyer, who has
physical possession of the device, and possibly some simple (non
cryptographic) credentials provided by the seller to force the 
device to

reset what it thinks it is part of, and to emit in some accessible form
the information the buyer needs to be able to make this device part of
his network, using his authentication servers, etc.

Yes, but *not* a solution that works if the device is stolen.
I'm actually a little ambivalent with respect to this use case. For 
the kind of devices that the document purports to be targeting, I 
would imagine that theft 

Re: [Anima] Adam Roach's Discuss on draft-ietf-anima-bootstrapping-keyinfra-22: (with DISCUSS and COMMENT)

[Eliot Lear]

Hi Joel,

> On 15 Jul 2019, at 23:42, Joel M. Halpern  wrote:
> 
> I would probably go a step further than Adam.  Protecting the device so a 
> thief can not use it in the thiefs' own network seems to me to be something 
> that we should not be trying to achieve.  An active non-goal. It is not our 
> problem.

>  And trying to achieve it has the implications that lead to this whole 
> discussion about the original manufacturer controlling who can resell / 
> re-buy the device.

I would rather we redressed this directly.  There is an entire work flow that 
involves zero-touch provisioning that at least two, and likely four large 
platforms are driving toward, that all require some sort of manufacturer 
assertion for device ownership to be transferred.  This is not just a good idea 
or an anti-theft mechanism, but an aspect that is required for zero-touch, 
particularly with wireless, where network selection has to occur.  While in 
that sense, you might say, “Anti-theft wasn’t the goal”, it is certainly a nice 
add-on, and it seems like a valuable function.

Personally I like that we had this discussion.  I think the BRSKI work will be 
much improved because of it, and people have a better understanding of how the 
mechanisms can be used/abused as a result.  I only wish we had had it earlier.

So now let’s talk about anti-theft and counterfeiting.  BRSKI has an 
interesting link to both.  If a manufacturer is able to show the customer what 
devices have been registered, any device that seems to be operational but is 
NOT registered has to be considered suspect by the customer.  That’s a nice 
counterfeit protection, and it isn’t there by accident.

Similarly having a way to say, “the thing won’t join an unauthorized network” 
is a very strong theft deterrent, very much akin to the electronic keys that we 
see now in cars.  You generally can no longer go to the local locksmith to get 
a duplicate key for a great many cars, but your theft insurance has dropped 
through the floor (particularly if you own a Honda).  Might GM, Ford, BMW etc 
might fail?  Sure.  No more new keys for those cars: the old ones had better 
suffice.

In this case we discussed several approaches to deal with the case where the 
supplier drops dead.  IMHO that’s a good outcome.

Eliot




>  While manufacturers may like that, it does not seem to be something we 
> should get involved in. At all.
> 
> Yours,
> Joel
> 
> On 7/15/2019 5:10 PM, Adam Roach wrote:
>> On 7/15/19 3:38 PM, Brian E Carpenter wrote:
>>> On 15-Jul-19 16:45, Joel M. Halpern wrote:
 I presume I am missing something basic.
 I have tried to follow this discussion, as it seems to be about a
 critical aspect of whether the BRSKI work is acceptable.
 
 I have assumed that what we needed is the ability for a buyer, who has
 physical possession of the device, and possibly some simple (non
 cryptographic) credentials provided by the seller to force the device to
 reset what it thinks it is part of, and to emit in some accessible form
 the information the buyer needs to be able to make this device part of
 his network, using his authentication servers, etc.
>>> Yes, but *not* a solution that works if the device is stolen.
>> I'm actually a little ambivalent with respect to this use case. For the kind 
>> of devices that the document purports to be targeting, I would imagine that 
>> theft is in the range of parts-per-thousand (or lower) as compared to things 
>> like post-bankruptcy liquidation. If you can fix the first without ruining 
>> the second, great.
>> /a



signature.asc
Description: Message signed with OpenPGP
___
Anima mailing list
Anima@ietf.org
https://www.ietf.org/mailman/listinfo/anima

Re: [Anima] Adam Roach's Discuss on draft-ietf-anima-bootstrapping-keyinfra-22: (with DISCUSS and COMMENT)

[Joel M. Halpern]

Adding such scope text, along with the mechanism to get the needed 
credentials, would be fine with me.

Joel

On 7/15/2019 6:28 PM, Brian E Carpenter wrote:

Joel,

I'd be happy with that as long as there is a scope statement that makes
it clear to the reader.

Regards
Brian

On 16-Jul-19 09:42, Joel M. Halpern wrote:

I would probably go a step further than Adam.  Protecting the device so
a thief can not use it in the thiefs' own network seems to me to be
something that we should not be trying to achieve.  An active non-goal.
It is not our problem.  And trying to achieve it has the implications
that lead to this whole discussion about the original manufacturer
controlling who can resell / re-buy the device.  While manufacturers may
like that, it does not seem to be something we should get involved in.
At all.

Yours,
Joel

On 7/15/2019 5:10 PM, Adam Roach wrote:

On 7/15/19 3:38 PM, Brian E Carpenter wrote:

On 15-Jul-19 16:45, Joel M. Halpern wrote:

I presume I am missing something basic.
I have tried to follow this discussion, as it seems to be about a
critical aspect of whether the BRSKI work is acceptable.

I have assumed that what we needed is the ability for a buyer, who has
physical possession of the device, and possibly some simple (non
cryptographic) credentials provided by the seller to force the device to
reset what it thinks it is part of, and to emit in some accessible form
the information the buyer needs to be able to make this device part of
his network, using his authentication servers, etc.

Yes, but *not* a solution that works if the device is stolen.



I'm actually a little ambivalent with respect to this use case. For the
kind of devices that the document purports to be targeting, I would
imagine that theft is in the range of parts-per-thousand (or lower) as
compared to things like post-bankruptcy liquidation. If you can fix the
first without ruining the second, great.

/a



___
Anima mailing list
Anima@ietf.org
https://www.ietf.org/mailman/listinfo/anima



___
Anima mailing list
Anima@ietf.org
https://www.ietf.org/mailman/listinfo/anima

Re: [Anima] Adam Roach's Discuss on draft-ietf-anima-bootstrapping-keyinfra-22: (with DISCUSS and COMMENT)

[Brian E Carpenter]

Joel,

I'd be happy with that as long as there is a scope statement that makes
it clear to the reader.

Regards
   Brian

On 16-Jul-19 09:42, Joel M. Halpern wrote:
> I would probably go a step further than Adam.  Protecting the device so 
> a thief can not use it in the thiefs' own network seems to me to be 
> something that we should not be trying to achieve.  An active non-goal. 
> It is not our problem.  And trying to achieve it has the implications 
> that lead to this whole discussion about the original manufacturer 
> controlling who can resell / re-buy the device.  While manufacturers may 
> like that, it does not seem to be something we should get involved in. 
> At all.
> 
> Yours,
> Joel
> 
> On 7/15/2019 5:10 PM, Adam Roach wrote:
>> On 7/15/19 3:38 PM, Brian E Carpenter wrote:
>>> On 15-Jul-19 16:45, Joel M. Halpern wrote:
 I presume I am missing something basic.
 I have tried to follow this discussion, as it seems to be about a
 critical aspect of whether the BRSKI work is acceptable.

 I have assumed that what we needed is the ability for a buyer, who has
 physical possession of the device, and possibly some simple (non
 cryptographic) credentials provided by the seller to force the device to
 reset what it thinks it is part of, and to emit in some accessible form
 the information the buyer needs to be able to make this device part of
 his network, using his authentication servers, etc.
>>> Yes, but *not* a solution that works if the device is stolen.
>>
>>
>> I'm actually a little ambivalent with respect to this use case. For the 
>> kind of devices that the document purports to be targeting, I would 
>> imagine that theft is in the range of parts-per-thousand (or lower) as 
>> compared to things like post-bankruptcy liquidation. If you can fix the 
>> first without ruining the second, great.
>>
>> /a
>>
> 
> ___
> Anima mailing list
> Anima@ietf.org
> https://www.ietf.org/mailman/listinfo/anima
> 

___
Anima mailing list
Anima@ietf.org
https://www.ietf.org/mailman/listinfo/anima

Re: [Anima] Adam Roach's Discuss on draft-ietf-anima-bootstrapping-keyinfra-22: (with DISCUSS and COMMENT)

[Joel M. Halpern]

I would probably go a step further than Adam.  Protecting the device so 
a thief can not use it in the thiefs' own network seems to me to be 
something that we should not be trying to achieve.  An active non-goal. 
It is not our problem.  And trying to achieve it has the implications 
that lead to this whole discussion about the original manufacturer 
controlling who can resell / re-buy the device.  While manufacturers may 
like that, it does not seem to be something we should get involved in. 
At all.


Yours,
Joel

On 7/15/2019 5:10 PM, Adam Roach wrote:

On 7/15/19 3:38 PM, Brian E Carpenter wrote:

On 15-Jul-19 16:45, Joel M. Halpern wrote:

I presume I am missing something basic.
I have tried to follow this discussion, as it seems to be about a
critical aspect of whether the BRSKI work is acceptable.

I have assumed that what we needed is the ability for a buyer, who has
physical possession of the device, and possibly some simple (non
cryptographic) credentials provided by the seller to force the device to
reset what it thinks it is part of, and to emit in some accessible form
the information the buyer needs to be able to make this device part of
his network, using his authentication servers, etc.

Yes, but *not* a solution that works if the device is stolen.



I'm actually a little ambivalent with respect to this use case. For the 
kind of devices that the document purports to be targeting, I would 
imagine that theft is in the range of parts-per-thousand (or lower) as 
compared to things like post-bankruptcy liquidation. If you can fix the 
first without ruining the second, great.


/a



___
Anima mailing list
Anima@ietf.org
https://www.ietf.org/mailman/listinfo/anima

Re: [Anima] Adam Roach's Discuss on draft-ietf-anima-bootstrapping-keyinfra-22: (with DISCUSS and COMMENT)

[Adam Roach]

On 7/15/19 3:38 PM, Brian E Carpenter wrote:

On 15-Jul-19 16:45, Joel M. Halpern wrote:

I presume I am missing something basic.
I have tried to follow this discussion, as it seems to be about a
critical aspect of whether the BRSKI work is acceptable.

I have assumed that what we needed is the ability for a buyer, who has
physical possession of the device, and possibly some simple (non
cryptographic) credentials provided by the seller to force the device to
reset what it thinks it is part of, and to emit in some accessible form
the information the buyer needs to be able to make this device part of
his network, using his authentication servers, etc.

Yes, but *not* a solution that works if the device is stolen.



I'm actually a little ambivalent with respect to this use case. For the 
kind of devices that the document purports to be targeting, I would 
imagine that theft is in the range of parts-per-thousand (or lower) as 
compared to things like post-bankruptcy liquidation. If you can fix the 
first without ruining the second, great.


/a

___
Anima mailing list
Anima@ietf.org
https://www.ietf.org/mailman/listinfo/anima

Re: [Anima] Adam Roach's Discuss on draft-ietf-anima-bootstrapping-keyinfra-22: (with DISCUSS and COMMENT)

[Brian E Carpenter]

On 15-Jul-19 16:45, Joel M. Halpern wrote:
> I presume I am missing something basic.
> I have tried to follow this discussion, as it seems to be about a 
> critical aspect of whether the BRSKI work is acceptable.
> 
> I have assumed that what we needed is the ability for a buyer, who has 
> physical possession of the device, and possibly some simple (non 
> cryptographic) credentials provided by the seller to force the device to 
> reset what it thinks it is part of, and to emit in some accessible form 
> the information the buyer needs to be able to make this device part of 
> his network, using his authentication servers, etc.

Yes, but *not* a solution that works if the device is stolen. That's why
Eliot's comment:

>> Many credentials are written on your wireless devices right now.

doesn't provide an acceptable answer, IMHO. (As it doesn't for
devices that are deployed where third parties might have physical
access to them.)

Brian

> Have I got the wrong end of the stick?
> Joel
> 
> On 7/14/2019 5:33 PM, Michael Richardson wrote:
>>
>> Eliot Lear  wrote:
>>  > Whether such a voucher would be pinned is something we do not have to
>>  > specify, with the risks of it not being pinned being born by the 
>> owner.
>>
>> I beg to differ!
>> I think that the security properties are vastly different.
>> It's why we decided when creating RFC8366 not to do bearer tokens.
>> We simply didn't think we were competent enough to specify it tightly enough
>> to not become a security disaster.
>>
>> An unpinned voucher is some kind of bearer token, and if disclosed has
>> significant operational risk.  As such, keeping it around/online is a serious
>> issue.
>>
>> A voucher pinned to the public part of a keypair whose private key is
>> kept offline (to be turned over to a new owner) is different because there
>> are potentially far fewer things to keep private.  Worse case, it's perhaps
>> the same, I would agree.
>>
>> The bigger problem is that I don't see a way to define such an artifact in a
>> timely fashion, nor do I know which WG we'd do it in.
>>
>>
>> ___
>> Anima mailing list
>> Anima@ietf.org
>> https://www.ietf.org/mailman/listinfo/anima
>>
> 
> ___
> Anima mailing list
> Anima@ietf.org
> https://www.ietf.org/mailman/listinfo/anima
> 

___
Anima mailing list
Anima@ietf.org
https://www.ietf.org/mailman/listinfo/anima

Re: [Anima] Adam Roach's Discuss on draft-ietf-anima-bootstrapping-keyinfra-22: (with DISCUSS and COMMENT)

[Adam Roach]

> On Jul 15, 2019, at 02:39, Eliot Lear  wrote:
> 
> To Adam’s broader point, there are at least several ways to approach this.  
> We can leave it to the vendor to decide which is correct, and we can continue 
> to look to standardize ideas such as the one Michael had in the message I’m 
> replying to now.

Yes; I think this is the important thing, and that specific mechanisms — if we 
believe they are useful to define — could be worked on later. 

/a
___
Anima mailing list
Anima@ietf.org
https://www.ietf.org/mailman/listinfo/anima

Re: [Anima] Adam Roach's Discuss on draft-ietf-anima-bootstrapping-keyinfra-22: (with DISCUSS and COMMENT)

[Adam Roach]

> On Jul 15, 2019, at 02:39, Eliot Lear  wrote:
> 
> This give you the option for that not to be the case (people needn’t worry 
> about Siemens, Rockwell, JCI, Honeywell, or Schneider Electric going out of 
> business anytime soon, for instance

When I started IETF work, Nortel would have been on your list.

/a 
___
Anima mailing list
Anima@ietf.org
https://www.ietf.org/mailman/listinfo/anima

Re: [Anima] Adam Roach's Discuss on draft-ietf-anima-bootstrapping-keyinfra-22: (with DISCUSS and COMMENT)

[Eliot Lear]

> On 13 Jul 2019, at 17:10, Michael Richardson  wrote:
> 
> Signed PGP part
> 
> Eliot Lear  wrote:
>> I think the simplest way to address the bulk of both Adam’s and
>> Warren’s concern is to require the device to emit via whatever
>> management interface exists, upon request, a voucher that it has signed
>> with its own iDevID.  It would have to be nonceless with perhaps a long
>> expiry, and that would cover a number of other use cases as well.  That
>> way if the manufacturer goes out of business, or if the owner wants to
>> transfer the device without manufacturer consent, there is a way
>> forward.
> 
> 1) would it have a pinned-domain-cert for the new owner, or would it be
>   some kind of wildcard/bearer voucher?

Again, I think this is a matter for the seller, and also a matter for the 
seller as to when the voucher is generated, so that it doesn’t need to lie 
around.  I was also thinking that this would be the sort of thing that could be 
printed out, either in a QR or OCR form, if necessary.

> 
> 2) what would the management interface be, specifically, how would it be
>   secured?

The reason I mentioned CIP and Profinet in a previous message is that once the 
device is bootstrapped, if it has a management interface, that is what should 
be used.  Adding new services on a device is undesirable. This covers the case 
when the manufacturer becomes unavailable.  However, it should be viewed as a 
backstop.  See below.

> 
> This would seem to cover the case where there is an orderly sale of equipment
> From an owner who is still in business to a new owner who is ready to receive
> the device.  In my experience buying used routing equipment, this is never
> the case.

Unless the owner printed out such a label in advance.  The point is that the 
mechanism could reasonably be used.  Many credentials are written on your 
wireless devices right now.  This give you the option for that not to be the 
case (people needn’t worry about Siemens, Rockwell, JCI, Honeywell, or 
Schneider Electric going out of business anytime soon, for instance - they may 
feel differently about Joe’s Tool and Die).

Another way to look at this would be to for the manufacturer to ping the owner 
periodically to reconfirm ownership.  If the owner fails to respond, allow 
another owner to transfer the device.  Or… simply ping the owner when a 
transfer request is made.  But these require that the MASA be present.

To Adam’s broader point, there are at least several ways to approach this.  We 
can leave it to the vendor to decide which is correct, and we can continue to 
look to standardize ideas such as the one Michael had in the message I’m 
replying to now.

Eliot



signature.asc
Description: Message signed with OpenPGP
___
Anima mailing list
Anima@ietf.org
https://www.ietf.org/mailman/listinfo/anima

Re: [Anima] Adam Roach's Discuss on draft-ietf-anima-bootstrapping-keyinfra-22: (with DISCUSS and COMMENT)

[Joel M. Halpern]

I presume I am missing something basic.
I have tried to follow this discussion, as it seems to be about a 
critical aspect of whether the BRSKI work is acceptable.


I have assumed that what we needed is the ability for a buyer, who has 
physical possession of the device, and possibly some simple (non 
cryptographic) credentials provided by the seller to force the device to 
reset what it thinks it is part of, and to emit in some accessible form 
the information the buyer needs to be able to make this device part of 
his network, using his authentication servers, etc.


Have I got the wrong end of the stick?
Joel

On 7/14/2019 5:33 PM, Michael Richardson wrote:


Eliot Lear  wrote:
 > Whether such a voucher would be pinned is something we do not have to
 > specify, with the risks of it not being pinned being born by the owner.

I beg to differ!
I think that the security properties are vastly different.
It's why we decided when creating RFC8366 not to do bearer tokens.
We simply didn't think we were competent enough to specify it tightly enough
to not become a security disaster.

An unpinned voucher is some kind of bearer token, and if disclosed has
significant operational risk.  As such, keeping it around/online is a serious
issue.

A voucher pinned to the public part of a keypair whose private key is
kept offline (to be turned over to a new owner) is different because there
are potentially far fewer things to keep private.  Worse case, it's perhaps
the same, I would agree.

The bigger problem is that I don't see a way to define such an artifact in a
timely fashion, nor do I know which WG we'd do it in.


___
Anima mailing list
Anima@ietf.org
https://www.ietf.org/mailman/listinfo/anima



___
Anima mailing list
Anima@ietf.org
https://www.ietf.org/mailman/listinfo/anima

Re: [Anima] Adam Roach's Discuss on draft-ietf-anima-bootstrapping-keyinfra-22: (with DISCUSS and COMMENT)

[Michael Richardson]

Eliot Lear  wrote:
> I think the simplest way to address the bulk of both Adam’s and
> Warren’s concern is to require the device to emit via whatever
> management interface exists, upon request, a voucher that it has signed
> with its own iDevID.  It would have to be nonceless with perhaps a long
> expiry, and that would cover a number of other use cases as well.  That
> way if the manufacturer goes out of business, or if the owner wants to
> transfer the device without manufacturer consent, there is a way
> forward.

1) would it have a pinned-domain-cert for the new owner, or would it be
   some kind of wildcard/bearer voucher?

2) what would the management interface be, specifically, how would it be
   secured?

This would seem to cover the case where there is an orderly sale of equipment
From an owner who is still in business to a new owner who is ready to receive
the device.  In my experience buying used routing equipment, this is never
the case.

The best case is that equipment was removed from active service 6 to 10
months previously, stored somewhere until it was certain that no spares would
be required, and then sold on eBay directly to the buyer.

Creating this new voucher would require that the sellor spin the systems up,
hook them back onto some management interface (which effectively means going
through the onboarding process again, since their IP addresses will be wrong,
having been replaced), and then getting a voucher issued for the buyor's
domainID.   Is this ridiculous? No. Knowing that the systems boot (and
haven't rotted), and knowing that the old configurations have correctly wiped
is pretty good hygiene.

Often the systems are purchased by a used equipment broker, and having the
broker issue an intermediate (could be time limited) voucher to themselves
would be reasonable as they take the systems into their inventory.  In larger
sales, the broker could provide personnel to do the spin-up at the sellor's
location.

The sellor *could* generate that voucher themselves before the device is
taken offline, linking the voucher to a newly generated domain owner
keypair.  This effectively is now a bearer voucher.  At which point one could
consider some other kind of existing technology: a TLS session resumption
ticket (issued by the BRSKI client to the Registrar) might make more
sense. It has all the properties of a bearer voucher, and all the risks,
but is well established mechanism.

I would be happy to start a draft that explained this process.
It's something that I wish we have a SEC-AREA BRSKI WG to make sure we get
this right.

In the worst case, the reason the equipment is being sold is because the
sellor went into bankruptcy.  There is no sellor Registrar to invoke this
API.

--
Michael Richardson , Sandelman Software Works
 -= IPv6 IoT consulting =-


signature.asc
Description: PGP signature
___
Anima mailing list
Anima@ietf.org
https://www.ietf.org/mailman/listinfo/anima

Re: [Anima] Adam Roach's Discuss on draft-ietf-anima-bootstrapping-keyinfra-22: (with DISCUSS and COMMENT)

[Michael Richardson]

Eliot> I think the simplest way to address the bulk of both Adam’s and
Eliot> Warren’s concern is to require the device to emit via whatever
Eliot> management interface exists, upon request, a voucher that it has
Eliot> signed with its own iDevID.  It would have to be nonceless with
Eliot> perhaps a long expiry, and that would cover a number of other use
Eliot> cases as well.  That way if the manufacturer goes out of business, or
Eliot> if the owner wants to transfer the device without manufacturer
Eliot> consent, there is a way forward.

Benjamin Kaduk  wrote:
> An interesting thought.  Would there be a way (or a need) to usefully
> audit such voucher issuance?

The vendor would be unable to provide any record of them being issued.
The device could provide an audit log.  Perhaps we could use some kind of
merkle tree such that every such voucher had a record of all previous ones,
going back to the original MASA issue voucher.

I had originally considered this to be the right way to do resale, but many
others thought it too complex.

--
Michael Richardson , Sandelman Software Works
 -= IPv6 IoT consulting =-





signature.asc
Description: PGP signature
___
Anima mailing list
Anima@ietf.org
https://www.ietf.org/mailman/listinfo/anima

Re: [Anima] Adam Roach's Discuss on draft-ietf-anima-bootstrapping-keyinfra-22: (with DISCUSS and COMMENT)

[Michael Richardson]

Eliot Lear  wrote:
> Whether such a voucher would be pinned is something we do not have to
> specify, with the risks of it not being pinned being born by the owner.

I beg to differ!
I think that the security properties are vastly different.
It's why we decided when creating RFC8366 not to do bearer tokens.  
We simply didn't think we were competent enough to specify it tightly enough
to not become a security disaster.

An unpinned voucher is some kind of bearer token, and if disclosed has
significant operational risk.  As such, keeping it around/online is a serious
issue.

A voucher pinned to the public part of a keypair whose private key is
kept offline (to be turned over to a new owner) is different because there
are potentially far fewer things to keep private.  Worse case, it's perhaps
the same, I would agree.

The bigger problem is that I don't see a way to define such an artifact in a
timely fashion, nor do I know which WG we'd do it in.

-- 
]   Never tell me the odds! | ipv6 mesh networks [ 
]   Michael Richardson, Sandelman Software Works| network architect  [ 
] m...@sandelman.ca  http://www.sandelman.ca/|   ruby on rails[ 




signature.asc
Description: PGP signature
___
Anima mailing list
Anima@ietf.org
https://www.ietf.org/mailman/listinfo/anima

Re: [Anima] Adam Roach's Discuss on draft-ietf-anima-bootstrapping-keyinfra-22: (with DISCUSS and COMMENT)

[Adam Roach]

Thanks for your reply. Responses to questions below.

On 7/12/19 4:07 PM, Michael Richardson wrote:


 > 
---

 > §5.6

 >> {
 >> "ietf-voucher:voucher": {
 >> "nonce": "62a2e7693d82fcda2624de58fb6722e5",
 >> "assertion": "logging"
 >> "pinned-domain-cert": "base64encodedvalue=="
 >> "serial-number": "JADA123456789"
 >> }
 >> }

 > This JSON is syntactically invalid. Please run this example and all other
 > instances of JSON in this document through a validation tool.

I have moved all of our examples json into separate files in our directory so
that we can validate them better, and added the validation to the Makefile.
I see that "FALSE" is not valid, but "false" is.
Please note that we know we have to renumber the figures.

In the appendix, we have examples of the JSON that is inside the CMS.
These are from real examples, and we have the private keys so that implementors
can make sure they can produce the same outputs.

The pinned-domain-cert has base64 in it, and it's more than 60 characters
wide.  I noticed it wasn't wrapped at all in -22, and just fixed that to be
wrapped at 60 characters, but then, it isn't valid JSON, because it has
LF in the "".  I shall leave a note, but maybe you have a better suggestion 
here.



Your approach is fine. Many other protocols make the same kind of note 
when they need to break the syntax for RFC format purposes. The only 
other thing I've seen done is taking the whole message and bas64 
encoding it, but that makes it less useful as an illustration in this 
case, so I would advise against it.




 > §5.8.1:

 >> Distribution of a large log is less than ideal.  This structure can
 >> be optimized as follows: Nonced or Nonceless entries for the same
 >> domainID MAY be truncated from the log leaving only the single most

 > Nit: "truncate" means to shorten something by removing only the 
beginning or
 > only the end. I believe that you mean "omitted" (here and elsewhere in 
this
 > section).

How about*abridged*? I also used omitted where it referred to a single entry.



"Abridged" seems a bit awkward: the *structure* is abridged, but the 
*entries* are omitted or elided or removed or excised or suppressed.



You have two other queries, but they're addressed to other people. Let 
me know if you'd like my perspective on them.


/a


___
Anima mailing list
Anima@ietf.org
https://www.ietf.org/mailman/listinfo/anima

Re: [Anima] Adam Roach's Discuss on draft-ietf-anima-bootstrapping-keyinfra-22: (with DISCUSS and COMMENT)

[Michael Richardson]

Max and Toerless, please search for your name.

Adam Roach via Datatracker  wrote:
> §2.1

>> |+--v---+
>> || (5) Enroll   |<---+ (non-error HTTP codes  )
>> ^+  |\___/ (e.g. 201 'Retry-After')
>> | Enroll +--+---+
>> | Failure   |

> I can't work out what a "Retry-After" would mean in a "201 Created" 
response.
> As noted above, section 5.6 of this document does indicate the use of a
> "Retry-After" header field with a 202 response, so I presume this diagram
> should say 202?

Thank you. It should say 202.

> 
---

> §5:

>> BRSKI uses existing CMS message formats for existing EST operations.
>> BRSKI uses JSON [RFC7159] for all new operations defined here, and
>> voucher formats.

> RFC 7159 has been obsoleted by RFC 8259.

updated.

> 
---

> §5.2

>> The pledge SHOULD include an [RFC7231] section 5.3.2 "Accept" header
>> indicating the acceptable media type for the voucher response.  The

> Nit: ..."Accept" header field indicating...

fixed.

> 
---

> §5.5

>> The Registrar SHOULD include an [RFC7231] section 5.3.2 "Accept"
>> header indicating the response media types that are acceptable.  This

> Nit: ..."Accept" header field indicating...

fixed.

>> field and appropriate 'Accept header' field values from the physical

> Nit: ...'Accept header field' values...

fixed.

> 
---

> §5.6

>> pledge would keep track of the appropriate Retry-After header values

> Nit: "...Retry-After header field values..."

fixed.

>> desired type or using the desired algorithms (as indicated by the
>> Accept: headers, and algorithms used in the signature) cannot be

> Nit: "...Accept: header fields, ..."

fixed.

>> The voucher response format is as indicated in the submitted accept
>> header or based on the MASA's prior understanding of proper format

> Nit: "...Accept header field..."

fixed.

> 
---

> §5.6

>> {
>> "ietf-voucher:voucher": {
>> "nonce": "62a2e7693d82fcda2624de58fb6722e5",
>> "assertion": "logging"
>> "pinned-domain-cert": "base64encodedvalue=="
>> "serial-number": "JADA123456789"
>> }
>> }

> This JSON is syntactically invalid. Please run this example and all other
> instances of JSON in this document through a validation tool.

I have moved all of our examples json into separate files in our directory so
that we can validate them better, and added the validation to the Makefile.
I see that "FALSE" is not valid, but "false" is.
Please note that we know we have to renumber the figures.

In the appendix, we have examples of the JSON that is inside the CMS.
These are from real examples, and we have the private keys so that implementors
can make sure they can produce the same outputs.

The pinned-domain-cert has base64 in it, and it's more than 60 characters
wide.  I noticed it wasn't wrapped at all in -22, and just fixed that to be
wrapped at 60 characters, but then, it isn't valid JSON, because it has
LF in the "".  I shall leave a note, but maybe you have a better suggestion 
here.

> 
---

> §5.8:

>> A MASA that returns a code 200 MAY also include a Location: header
>> for future reference by the registrar.

> Nit: "Location: header field"

> Also, it's not 100% clear what the registrar would use this URI for. 
Please
> explain in the document.

okay.

> §5.8.1:

>> Distribution of a large log is less than ideal.  This structure can
>> be optimized as follows: Nonced or Nonceless entries for the same
>> domainID MAY be truncated from the log leaving only the single most

> Nit: "truncate" means to shorten something by removing only the beginning 
or
> only the end. I believe that you mean "omitted" (here and elsewhere in 
this
> section).

How about *abridged*? I also used omitted where it referred to a single entry.

> 
---

> §6:

>> In the BRSKI context, the EST "Content-Transfer-Encoding" header if
>> present, SHOULD be ignored.  This header does not need to included.

> Nit: "...header field, if present..."

> Nit: "This header field does not..."

done.

> 
---

> §8.1:

>> This document extends the definitions of "est" (so far defined via
>> RFC7030) in the 

Re: [Anima] Adam Roach's Discuss on draft-ietf-anima-bootstrapping-keyinfra-22: (with DISCUSS and COMMENT)

[Max Pritikin (pritikin)]

FYI what you all are discussing are potential changes to the normative language 
of
https://tools.ietf.org/html/draft-ietf-anima-bootstrapping-keyinfra-22#section-7.2

Probably strengthening this paragraph from MAY/SHOULD to a MUST:

   3.  The pledge MAY have an operational mode where it skips voucher
   validation one time.  For example if a physical button is
   depressed during the bootstrapping operation.  This can be useful
   if the manufacturer service is unavailable.  This behavior SHOULD
   be available via local configuration or physical presence methods
   (such as use of a serial/craft console) to ensure new entities
   can always be deployed even when autonomic methods fail.  This
   allows for unsecured imprint.

If this is a suggested change please comment on the subsequent paragraph which 
reads:

It is RECOMMENDED that "trust on first use" or any method of skipping
   voucher validation (including use of craft serial console) only be
   available if hardware assisted Network Endpoint Assessment [RFC5209]
   is supported.  This recommendation ensures that domain network
   monitoring can detect innappropriate use of offline or emergency
   deployment procedures when voucher-based bootstrapping is not used.

The use of SHOULD and RECOMMEND are strong indicators of how this should be 
done. As much so as a MUST "security requirements we write into our specs, 
we'll have no means of enforcement”.

Since Eliot has brought up other options like being able to replace the MASA 
trust anchors or some form of  “self emitted” voucher here are the current 
thoughts along those lines:

If one possessed a nonceless voucher then one possesses a permanent token to 
enable bootstrapping of the device. This is the very first point in section 7.2 
discussed above:

   1.  The pledge MUST accept nonceless vouchers.  This allows for a use
   case where the registrar can not connect to the MASA at the
   deployment time.  Logging and validity periods address the
   security considerations of supporting these use cases.

There are two ways to leverage this. Predominately his means that after a 
single BRSKI exchange any domain owner can opt out of any future BRSKI stuff 
and still be able to (re)perform over-the-wire bootstrapping (this is of course 
captured in the audit log). Additionally the privacy protections mean that this 
voucher can be tied to a transient keypair that could be distributed with the 
device for resale. So this can be passed on to entities further down the supply 
chain or during a resale of the device.

These two methods hit a large percentage of use cases being discussed while 
maintaining the audit log.

- max

On Jul 12, 2019, at 1:27 AM, Eliot Lear mailto:l...@cisco.com>> 
wrote:

Hi Adam

On 12 Jul 2019, at 00:25, Adam Roach 
mailto:a...@nostrum.com>> wrote:


The smallest change that would satisfy my concern would be a statement that 
says that devices conformant to this specification MUST contain a local means 
of bootstrapping that does not rely on any specific server being available. As 
with the security requirements we write into our specs, we'll have no means of 
enforcement. But as with the security requirements we write into our specs, 
we'll give interested parties just that little bit more leverage that might tip 
the scales towards the correct behavior.


I think this is easily possible within the paradigm of the document after the 
device has first been onboarded. At this stage, I would also suggest that the 
MUST be a SHOULD for another reason: there may be cases where it is in the 
customer best interest to prevent onboarding of a device just through proof of 
possession.  I am thinking of anti-theft mechanisms.  Having a discussion of 
this and the risks of not having any on-prem method ever seems like a 
reasonable add.

Eliot

___
Anima mailing list
Anima@ietf.org
https://www.ietf.org/mailman/listinfo/anima

Re: [Anima] Adam Roach's Discuss on draft-ietf-anima-bootstrapping-keyinfra-22: (with DISCUSS and COMMENT)

[Eliot Lear]

Hi Adam

> On 12 Jul 2019, at 00:25, Adam Roach  wrote:
> 
> 
> The smallest change that would satisfy my concern would be a statement that 
> says that devices conformant to this specification MUST contain a local means 
> of bootstrapping that does not rely on any specific server being available. 
> As with the security requirements we write into our specs, we'll have no 
> means of enforcement. But as with the security requirements we write into our 
> specs, we'll give interested parties just that little bit more leverage that 
> might tip the scales towards the correct behavior.



I think this is easily possible within the paradigm of the document after the 
device has first been onboarded. At this stage, I would also suggest that the 
MUST be a SHOULD for another reason: there may be cases where it is in the 
customer best interest to prevent onboarding of a device just through proof of 
possession.  I am thinking of anti-theft mechanisms.  Having a discussion of 
this and the risks of not having any on-prem method ever seems like a 
reasonable add.

Eliot


signature.asc
Description: Message signed with OpenPGP
___
Anima mailing list
Anima@ietf.org
https://www.ietf.org/mailman/listinfo/anima

Re: [Anima] Adam Roach's Discuss on draft-ietf-anima-bootstrapping-keyinfra-22: (with DISCUSS and COMMENT)

[Brian E Carpenter]

On 12-Jul-19 10:52, Adam Roach wrote:
> On 7/11/19 3:05 PM, Michael Richardson wrote:
>> <#secure method=pgpmime mode=sign>
>>
>> Adam Roach via Datatracker  wrote:
>>  > §5.8:
>>
>>  >> Rather than returning the audit log as a response to the POST (with a
>>  >> return code 200), the MASA MAY instead return a 201 ("Created")
>>  >> RESTful response ([RFC7231] section 7.1) containing a URL to the
>>  >> prepared (and easily cachable) audit response.
>>
>>  > The DISCUSS portion of my comment on this text is that it is unclear 
>> about how
>>  > the URL is to be returned. It can just as easily be interpreted as 
>> returning
>>  > it in a "Location" header field as it could as returning it in the 
>> response
>>  > body -- or maybe somewhere else entirely (e.g., a link relation).  
>> This
>>  > ambiguity will cause an interop issue. Please be explicit about 
>> precisely how
>>  > the value is conveyed.
>>
>> I see how this could be confusing.
>>
>>  > While not part of the DISCUSS, I also have a fairly serious comment 
>> on the
>>  > phrasing and citation of  "return a 201 ("Created") RESTful response
>>  > ([RFC7231] section 7.1)". Section 7.1 points to the top-level 
>> discussion of
>>  > Control Data header fields, rather than any general discussion of 
>> RESTful
>>  > responses.  It's worth noting that the term "RESTful" never appears 
>> in RFC
>>  > 7231, so it's really unclear what section this was attempting to 
>> target.
>>  > Perhaps 6.3.2?
>>
>> Yes, that's what we are trying to target.
>> I guess we also latched onto section 7.1.2 ("Location")
>>
>> Can you point me to another document that tries to specify the same thing.
>> If we shouldn't say we are trying to be RESTful, what should we say?
> 
> 
> "HTTP", but even that may be unnecessary in this case.
> 
> REST means... something. Exactly what depends on who you ask. In 
> practice, the least controversial thing to do is avoid the term; 

I am unbelievably happy to read that. I thought it was forbidden to be
an unbeliever in RESTfulness.

> and, if 
> you're trying to describe a specific quality (e.g., idempotence), say so 
> explicitly.

In the simplest possible terms, isn't the quality we require that
an operation has unambiguously succeeded or unambiguously failed?
But in fact, simply deleting the two occurrences of "RESTful"
seems appropriate.

Brian

> 
> For this document, I don't think you really care much the purported 
> properties of REST -- by any definition -- and I suspect you don't 
> conform to them, for at least some number of mutually incompatible and 
> religiously-held definitions of that term.
> 
> In any case, I don't think the reference adds anything to the text, 
> regardless of whether it points to 7.1.2 or to 6.3.2. So I would propose 
> something along the lines of:
> 

>     Rather than returning the audit log as a response to the POST (with 
> a 200
>     (OK) response code), the MASA MAY instead return a 201 (Created) 
> response
>     containing a "Location" header field that indicates the location of the
>     prepared audit response. This allows the audit response to appear at a
>     location that enables caching.
> 
> 
> If that says something other than what you meant, let me know, and I'll 
> try to fix it.
> 
> /a
> 
> ___
> Anima mailing list
> Anima@ietf.org
> https://www.ietf.org/mailman/listinfo/anima
> 

___
Anima mailing list
Anima@ietf.org
https://www.ietf.org/mailman/listinfo/anima

Re: [Anima] Adam Roach's Discuss on draft-ietf-anima-bootstrapping-keyinfra-22: (with DISCUSS and COMMENT)

[Adam Roach]

On 7/11/19 3:05 PM, Michael Richardson wrote:

<#secure method=pgpmime mode=sign>

Adam Roach via Datatracker  wrote:
 > §5.8:

 >> Rather than returning the audit log as a response to the POST (with a
 >> return code 200), the MASA MAY instead return a 201 ("Created")
 >> RESTful response ([RFC7231] section 7.1) containing a URL to the
 >> prepared (and easily cachable) audit response.

 > The DISCUSS portion of my comment on this text is that it is unclear 
about how
 > the URL is to be returned. It can just as easily be interpreted as 
returning
 > it in a "Location" header field as it could as returning it in the 
response
 > body -- or maybe somewhere else entirely (e.g., a link relation).  This
 > ambiguity will cause an interop issue. Please be explicit about 
precisely how
 > the value is conveyed.

I see how this could be confusing.

 > While not part of the DISCUSS, I also have a fairly serious comment on 
the
 > phrasing and citation of  "return a 201 ("Created") RESTful response
 > ([RFC7231] section 7.1)". Section 7.1 points to the top-level discussion 
of
 > Control Data header fields, rather than any general discussion of RESTful
 > responses.  It's worth noting that the term "RESTful" never appears in 
RFC
 > 7231, so it's really unclear what section this was attempting to target.
 > Perhaps 6.3.2?

Yes, that's what we are trying to target.
I guess we also latched onto section 7.1.2 ("Location")

Can you point me to another document that tries to specify the same thing.
If we shouldn't say we are trying to be RESTful, what should we say?



"HTTP", but even that may be unnecessary in this case.

REST means... something. Exactly what depends on who you ask. In 
practice, the least controversial thing to do is avoid the term; and, if 
you're trying to describe a specific quality (e.g., idempotence), say so 
explicitly.


For this document, I don't think you really care much the purported 
properties of REST -- by any definition -- and I suspect you don't 
conform to them, for at least some number of mutually incompatible and 
religiously-held definitions of that term.


In any case, I don't think the reference adds anything to the text, 
regardless of whether it points to 7.1.2 or to 6.3.2. So I would propose 
something along the lines of:


   Rather than returning the audit log as a response to the POST (with 
a 200
   (OK) response code), the MASA MAY instead return a 201 (Created) 
response

   containing a "Location" header field that indicates the location of the
   prepared audit response. This allows the audit response to appear at a
   location that enables caching.


If that says something other than what you meant, let me know, and I'll 
try to fix it.


/a

___
Anima mailing list
Anima@ietf.org
https://www.ietf.org/mailman/listinfo/anima

Re: [Anima] Adam Roach's Discuss on draft-ietf-anima-bootstrapping-keyinfra-22: (with DISCUSS and COMMENT)

[Adam Roach]

On 7/11/19 2:55 PM, Michael Richardson wrote:

EXECSUM: Please stop beating us up for having solved the problem that the WG
  charter said we we should solve, and for having not solved a
  problem that the WG charter said was out-of-scope.



I apologize if the objection came off as harsh. My intention was to be 
clear, and that may have come off as more blunt as intended. I 
understand that there's a problem to be solved here, and I think there's 
a fairly simple solution that would satisfy the points I raise (at 
least, to the extent that the IETF can do so).




Adam Roach via Datatracker  wrote:
 > In short, beyond the user-hostile effects of these two issues, I have
 > ethical issues with the IETF publishing a protocol that promotes the
 > unnecessary creation of e-waste; and, unless handled properly, that will
 > be the inevitable result of the two factors I cite above.

I really hate e-waste.  More than many, I think.

I have worked very hard in my spare time in years past on projects like
cyanogen (when it was a thing) to continue to support perfectly good phones
that were abandonned by their manufacturers.

Much of the effort of supporting these phones has been because there is no
protocol for the manufacturers to pass on the real ownership keys to the
physical owner.   BRSKI can do exactly this.

   *** but manufacturers have to want to do it ***



I completely agree with everything you just said, and sincerely thank 
you for the work you've done in this area. I think where our 
perspectives might diverge is our beliefs about what *we*, the IETF, can 
do about it in this specific case.


The IETF, as a matter of practice, includes normative statements in 
documents all the time regarding processes that conformant 
implementations "MUST" follow for the sake of security. In many cases, 
the protocol works just fine if implementors ignore these requirements, 
which means that implementation of them resolves to exactly one thing: 
manufacturers have to want to do it.


We have no enforcement, and frequently no means to easily detect of 
violations of these normative statements. And yet we make them. And we 
give them normative force. And this allows customers, researchers, and 
even in some cases regulators to use those statements as a stick to try 
to get vendors to behave.


The smallest change that would satisfy my concern would be a statement 
that says that devices conformant to this specification MUST contain a 
local means of bootstrapping that does not rely on any specific server 
being available. As with the security requirements we write into our 
specs, we'll have no means of enforcement. But as with the security 
requirements we write into our specs, we'll give interested parties just 
that little bit more leverage that might tip the scales towards the 
correct behavior.


That's all I'm asking for.


[snip]


So I totally understand and agree with your reluctance: if BRSKI gets into
residential IoT, in the fly-by-night vendors that ship crap and then shut
down, then I agree that it could be pretty user and environmentally hostile.
Do I think that will happen?  No: the fly-by-night vendors can't keep
their telnetd debug ports closed, and they aren't going to implement BRSKI
until such time as it's just there without them knowing it, and they start
buying IoT system platforms from Intel/ARM/Microsoft/etc.



I'm not worried about fly-by-night vendors. I'm worried about 
acquisition of extremely reputable medium-sized businesses by one of the 
several behemoth vendors who, as a matter of policy, give newly acquired 
business units exactly one year to show >$1MUSD net profit per 
engineering head or be shut down.


/a

___
Anima mailing list
Anima@ietf.org
https://www.ietf.org/mailman/listinfo/anima

Re: [Anima] Adam Roach's Discuss on draft-ietf-anima-bootstrapping-keyinfra-22: (with DISCUSS and COMMENT)

[Eliot Lear]

> On 11 Jul 2019, at 23:48, Benjamin Kaduk  wrote:
> 
> On Thu, Jul 11, 2019 at 11:44:55PM +0200, Eliot Lear wrote:
>> One thought:
>> 
>> I think the simplest way to address the bulk of both Adam’s and Warren’s 
>> concern is to require the device to emit via whatever management interface 
>> exists, upon request, a voucher that it has signed with its own iDevID.  It 
>> would have to be nonceless with perhaps a long expiry, and that would cover 
>> a number of other use cases as well.  That way if the manufacturer goes out 
>> of business, or if the owner wants to transfer the device without 
>> manufacturer consent, there is a way forward.
> 
> An interesting thought.  Would there be a way (or a need) to usefully audit
> such voucher issuance?
> 

Now you’re asking tough questions ;-)

“Usefully audit” is a bit loaded, but let me posit the following functions:

Produce a voucher with an expiry of X pinned to domain Y
Show a record of vouchers you’ve produced
Add (the hash of) voucher X to a revocation list.

Again, I would be hesitant to mandate a particular protocol for this sort of 
thing, but simply require the functions.  In some cases it could be CIP (Common 
Industrial Protocol) while in others it might be Profinet, and perhaps it could 
be something we could shove into the TEAP draft (draft-lear-eap-teap-brski), 
though I am not a big fan of that approach.  In other cases, it could be as 
simple as “Alexa [do one of the above]” ;-)

The key point here is that at least the first buyer should be able to enjoy a 
seamless zero-touch onboarding experience.

Eliot



signature.asc
Description: Message signed with OpenPGP
___
Anima mailing list
Anima@ietf.org
https://www.ietf.org/mailman/listinfo/anima

Re: [Anima] Adam Roach's Discuss on draft-ietf-anima-bootstrapping-keyinfra-22: (with DISCUSS and COMMENT)

[Benjamin Kaduk]

On Thu, Jul 11, 2019 at 11:44:55PM +0200, Eliot Lear wrote:
> One thought:
> 
> I think the simplest way to address the bulk of both Adam’s and Warren’s 
> concern is to require the device to emit via whatever management interface 
> exists, upon request, a voucher that it has signed with its own iDevID.  It 
> would have to be nonceless with perhaps a long expiry, and that would cover a 
> number of other use cases as well.  That way if the manufacturer goes out of 
> business, or if the owner wants to transfer the device without manufacturer 
> consent, there is a way forward.

An interesting thought.  Would there be a way (or a need) to usefully audit
such voucher issuance?

-Ben

___
Anima mailing list
Anima@ietf.org
https://www.ietf.org/mailman/listinfo/anima

Re: [Anima] Adam Roach's Discuss on draft-ietf-anima-bootstrapping-keyinfra-22: (with DISCUSS and COMMENT)

[Eliot Lear]

Just to complete the thought:

Whether such a voucher would be pinned is something we do not have to specify, 
with the risks of it not being pinned being born by the owner.

Eliot

> On 11 Jul 2019, at 23:44, Eliot Lear  wrote:
> 
> Signed PGP part
> One thought:
> 
> I think the simplest way to address the bulk of both Adam’s and Warren’s 
> concern is to require the device to emit via whatever management interface 
> exists, upon request, a voucher that it has signed with its own iDevID.  It 
> would have to be nonceless with perhaps a long expiry, and that would cover a 
> number of other use cases as well.  That way if the manufacturer goes out of 
> business, or if the owner wants to transfer the device without manufacturer 
> consent, there is a way forward.
> 
> Eliot
> 
> 



signature.asc
Description: Message signed with OpenPGP
___
Anima mailing list
Anima@ietf.org
https://www.ietf.org/mailman/listinfo/anima

Re: [Anima] Adam Roach's Discuss on draft-ietf-anima-bootstrapping-keyinfra-22: (with DISCUSS and COMMENT)

[Eliot Lear]

One thought:

I think the simplest way to address the bulk of both Adam’s and Warren’s 
concern is to require the device to emit via whatever management interface 
exists, upon request, a voucher that it has signed with its own iDevID.  It 
would have to be nonceless with perhaps a long expiry, and that would cover a 
number of other use cases as well.  That way if the manufacturer goes out of 
business, or if the owner wants to transfer the device without manufacturer 
consent, there is a way forward.

Eliot


signature.asc
Description: Message signed with OpenPGP
___
Anima mailing list
Anima@ietf.org
https://www.ietf.org/mailman/listinfo/anima

Re: [Anima] Adam Roach's Discuss on draft-ietf-anima-bootstrapping-keyinfra-22: (with DISCUSS and COMMENT)

[Ted Hardie]

Howdy,

On Thu, Jul 11, 2019 at 1:02 PM Michael Richardson 
wrote:

>
> Adam Roach via Datatracker  wrote:
> > §5:
>
> >> MASA URI is "https://; iauthority "/.well-known/est".
>
> > This doesn't make sense: iauthority is a component of IRIs, not of
> URIs. In
> > URIs this is simply an "authority." It's not simply a terminology
> distinction:
> > converting from an iauthority to an authority requires idna
> encoding. Please
> > consult with an IRI expert (which I do not consider myself to be) to
> work out
> > the proper terminology and procedures here.  If you need help
> finding an
> > expert, please let me know and I'll track someone down for you.
>
> okay, this one is my fault.
> I agree, we should have consulted an expert.  I thought I was being clever.
> Please, can you find us an expert, if you think we should go this
> direction.
>
> I thought IRIs were supersets of URIs, and that all URIs were IRIs, and the
> only reason to RFC3987 instead of RFC3986 is because one might have legacy
> systems that couldn't handle idna.  Since I thought we had a greenfield
> here,
> I figured we could specify the superset.
>
> It is correct that all IRIs are URIs, but the core purpose of the IRI was
to be a presentation format.  The presumption was that you turn it into
wire-format (that is a URI) whenever you passed it to the protocol
machinery that were going to retrieve a resource or take some other action
over the network.  For something that is already a URI, this is a null
transform.  For everything else, there's a set of steps in 3987, which
includes ToASCII for ireg-name components which are domain names.

I would personally not suggest using IRIs here, given that the scheme
(https) is expected to retrieve a resource at a well-known location and
thus will always have to be mapped to a URI to do the retrieval (rather
than used in a string comparison or something similar) .   RFC 5280, which
this cites, actually goes through the steps pretty well, and I think the
complexity there demonstrates the advantage for constrained devices of
always using the URI form.

Just a personal opinion, obviously, and I also would not class myself as an
expert here.

Ted


> I can easily make this "authority" and RFC3986.
> Please advise.
>
> Some background: this text is slightly new, and is the result of interop
> failures.   I had placed "https://example.com/; in the certificate, while
> another implementer placed "example.com:9443/.well-known/est" in,
> assuming that
> "https:" was naturally implied.
>
> So, we disagreed what the base was, and we then agreed that there were
> sometimes reasons to include the the entire URL, but that less is better.
> We then looked for what the term for the "hostname:port" part was, and
> found 3986 and 3987.
>
> --
> ]   Never tell me the odds! | ipv6 mesh
> networks [
> ]   Michael Richardson, Sandelman Software Works|IoT
> architect   [
> ] m...@sandelman.ca  http://www.sandelman.ca/|   ruby on
> rails[
>
>
>
>
>
> --
> Michael Richardson , Sandelman Software Works
>  -= IPv6 IoT consulting =-
>
>
>
>
___
Anima mailing list
Anima@ietf.org
https://www.ietf.org/mailman/listinfo/anima

Re: [Anima] Adam Roach's Discuss on draft-ietf-anima-bootstrapping-keyinfra-22: (with DISCUSS and COMMENT)

[Michael Richardson]

Adam Roach via Datatracker  wrote:
> §5:

>> MASA URI is "https://; iauthority "/.well-known/est".

> This doesn't make sense: iauthority is a component of IRIs, not of URIs. 
In
> URIs this is simply an "authority." It's not simply a terminology 
distinction:
> converting from an iauthority to an authority requires idna encoding. 
Please
> consult with an IRI expert (which I do not consider myself to be) to work 
out
> the proper terminology and procedures here.  If you need help finding an
> expert, please let me know and I'll track someone down for you.

okay, this one is my fault.
I agree, we should have consulted an expert.  I thought I was being clever.
Please, can you find us an expert, if you think we should go this direction.

I thought IRIs were supersets of URIs, and that all URIs were IRIs, and the
only reason to RFC3987 instead of RFC3986 is because one might have legacy
systems that couldn't handle idna.  Since I thought we had a greenfield here,
I figured we could specify the superset.

I can easily make this "authority" and RFC3986.
Please advise.

Some background: this text is slightly new, and is the result of interop
failures.   I had placed "https://example.com/; in the certificate, while
another implementer placed "example.com:9443/.well-known/est" in, assuming that
"https:" was naturally implied.

So, we disagreed what the base was, and we then agreed that there were
sometimes reasons to include the the entire URL, but that less is better.
We then looked for what the term for the "hostname:port" part was, and
found 3986 and 3987.

--
]   Never tell me the odds! | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works|IoT architect   [
] m...@sandelman.ca  http://www.sandelman.ca/|   ruby on rails[





--
Michael Richardson , Sandelman Software Works
 -= IPv6 IoT consulting =-





signature.asc
Description: PGP signature
___
Anima mailing list
Anima@ietf.org
https://www.ietf.org/mailman/listinfo/anima

Re: [Anima] Adam Roach's Discuss on draft-ietf-anima-bootstrapping-keyinfra-22: (with DISCUSS and COMMENT)

[Michael Richardson]

EXECSUM: Please stop beating us up for having solved the problem that the WG
 charter said we we should solve, and for having not solved a
 problem that the WG charter said was out-of-scope.

Adam Roach via Datatracker  wrote:
> In short, beyond the user-hostile effects of these two issues, I have
> ethical issues with the IETF publishing a protocol that promotes the
> unnecessary creation of e-waste; and, unless handled properly, that will
> be the inevitable result of the two factors I cite above.

I really hate e-waste.  More than many, I think.

I have worked very hard in my spare time in years past on projects like
cyanogen (when it was a thing) to continue to support perfectly good phones
that were abandonned by their manufacturers.

Much of the effort of supporting these phones has been because there is no
protocol for the manufacturers to pass on the real ownership keys to the
physical owner.   BRSKI can do exactly this.

  *** but manufacturers have to want to do it ***

I actually considered abandonning this document a year ago rather than build
something that could potentially lock in relationships.  Slowly I remembered
that outside of the open source operating system on x86 platform (which now
is ubiquitiously successful in the data center space), or openwrt
on semi-documented SoC,  everything else already is locked to the vendor.

My opinion is that pretty much every IoT product out there is pretty much
already e-waste because it does not support SUIT, RATS and BRSKI.

But, ANIMA is not chartered to do residential IoT, but rather Enterprise/ISP
equipment, and while we expect to use constrained-BRSKI for 6tisch, 6tisch is
about industrial IoT equipment.
In each case, the equipment is essentially e-waste as soon as the
manufacturer stops producing security updates.

So I totally understand and agree with your reluctance: if BRSKI gets into
residential IoT, in the fly-by-night vendors that ship crap and then shut
down, then I agree that it could be pretty user and environmentally hostile.
Do I think that will happen?  No: the fly-by-night vendors can't keep
their telnetd debug ports closed, and they aren't going to implement BRSKI
until such time as it's just there without them knowing it, and they start
buying IoT system platforms from Intel/ARM/Microsoft/etc.  at which point
it will the manufacturers' *AUTHORIZED* signing authority. (Not the 
manufacturer)

> While this isn't part of my DISCUSS, I can't in good conscience ballot "No
> Objection" to a document that doesn't normatively address those issues.  I
> urge the authors and working group to add text that does so.  I do, 
however,
> recognize that the prospect of this happening at this stage of the 
process is
> vanishingly small. In the absence of such admittedly unlikely action, I 
plan
> to Abstain after my DISCUSS issue has been addressed.

I am saddened by your cynicism, but I understand it.
(I feel you might need a hug at this point)

Can we write a protocol to replace trust anchors?  Yes, easily.
It's a one page yang model.  There are vestiages of it a key
anchor/management document that Kent Watsen wrote... I can't find it right
now.  We wanted to use in the early 6tisch zero-touch system that evolved
into BRSKI.  Can I force manufacturers to implement it?  No.  We aren't
mandating any kind of CLI, NETMOD, SNMP, COMI, etc. interface in the BRSKI
document, and we'd need at least one of them.

We also had this debate back in November/December/January.
I sure wish that your view had come forward then, rather than now.
I don't know how to fix things to satisfy the resale problem, while not at
the same time, opening the barn door to supply chain installed trojans.

Please stop beating us up for having solved the problem that the WG charter
said we we should solve, and for having not solved the problem that the WG
charter said was out-of-scope.

I'm curious if anyone has read Verner Vinge's Rainbow's End.

--
Michael Richardson , Sandelman Software Works
 -= IPv6 IoT consulting =-



signature.asc
Description: PGP signature
___
Anima mailing list
Anima@ietf.org
https://www.ietf.org/mailman/listinfo/anima