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

From: Adam Roach via Datatracker <[email-masked]>
Date: Wed, 10 Jul 2019 23:37:16 -0700

Adam Roach has entered the following ballot position for
draft-ietf-anima-bootstrapping-keyinfra-22: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-anima-bootstrapping-keyinfra/

----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

Thanks to everyone who invested time in developing this mechanism.
I have two blocking comments that should be quite easy to resolve.

---------------------------------------------------------------------------

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

---------------------------------------------------------------------------

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

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?

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

I share Warren's discomfort with the models described in this document,
especially in the context of device viability after companies disappear or
change focus.  It's not clear that this an unintended side effect of the
model: much of the text around "legal ownership" seems aimed at subverting the
doctrine of first sale/rule of exhaustion, and congruent laws around the world.

While I sincerely appreciate the treatment of this issue in section 10.3, I
think the document really needs *normative* behaviors defined that address the
two issues of resale and device utility in a world where the device
manufacturer (as that term is defined in section 1.2) is no longer available,
rather than the high-level non-normative sketches currently provided for
future study.

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.

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.

---------------------------------------------------------------------------

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

---------------------------------------------------------------------------

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

---------------------------------------------------------------------------

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

---------------------------------------------------------------------------

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

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

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

---------------------------------------------------------------------------

§5.6

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

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

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

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

---------------------------------------------------------------------------

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

With a reasonably modern version of nodejs, validation can be as simple as
something like:

node -e 'console.log(JSON.stringify(JSON.parse(`
  {
    "ietf-voucher:voucher": {
      "nonce": "62a2e7693d82fcda2624de58fb6722e5",
      "assertion": "logging"
      "pinned-domain-cert": "base64encodedvalue=="
      "serial-number": "JADA123456789"
    }
  }
`)));'

If the JSON is valid, you'll get no errors.

---------------------------------------------------------------------------

§5.7:

>  {
>    "version":"1",
>    "Status":FALSE /* TRUE=Success, FALSE=Fail"
>    "Reason":"Informative human readable message"
>    "reason-context": { additional JSON }
>  }

Please see https://tools.ietf.org/html/rfc8259#section-3 --

   A JSON value MUST be an object, array, number, or string, or one of
   the following three literal names:

      false
      null
      true

   The literal names MUST be lowercase.  No other literal names are
   allowed.

There are also a number of other syntax errors in this JSON example, even
setting aside the "additional JSON" indication.

---------------------------------------------------------------------------

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

---------------------------------------------------------------------------

§5.8.1:

>  {
>    "version":"1",
>    "events":[
>      {
>       "date":"<date/time of the entry>",
>       "domainID":"<domainID extracted from voucher-request>",
>       "nonce":"<any nonce if supplied (or the exact string 'NULL')>"
>       "assertion":"<the value from the voucher assertion leaf>"
>       "truncated":"<the number of domainID entries truncated>"
>      },
>      {
>       "date":"<date/time of the entry>",
>       "domainID":"<anotherDomainID extracted from voucher-request>",
>       "nonce":"<any nonce if supplied (or the exact string 'NULL')>"
>       "assertion":"<the value from the voucher assertion leaf>"
>      }
>    ],
>    "truncation": {
>       "nonced duplicates": "<total number of entries truncated>",
>       "nonceless duplicates": "<total number of entries truncated>",
>       "arbitrary": "<number of domainID entries removed entirely>"
>       }
>  }

This JSON is syntactically invalid. Please validate.

---------------------------------------------------------------------------

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

---------------------------------------------------------------------------

§5.9.4:

>  {
>    "version":"1",
>    "Status":TRUE /* TRUE=Success, FALSE=Fail"
>    "Reason":"Informative human readable message"
>    "reason-context": "Additional information"
>  }

This JSON is syntactically invalid. Please validate.

---------------------------------------------------------------------------

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

---------------------------------------------------------------------------

§8.1:

>  This document extends the definitions of "est" (so far defined via
>  RFC7030) in the "https://www.iana.org/assignments/well-known-uris/
>  well-known-uris.xhtml" registry as follows:
>
>  o  add /.well-known/est/requestvoucher (see Section 5.5 )
>
>  o  add /.well-known/est/requestauditlog (see Section 5.7)

The .well-known registry does not contain sub-paths under the path
element that appears after ".well-known". I note that "est" has already
been registered by RFC 7030. There are a bunch of ways this can be
handled, the easiest of which would be a request for the IANA to add
this RFC alongside RFC 7030 to the entry for "est."

More complex solutions would be selecting a different path than
"est", or establishing a separate sub-registry for paths under
the "est" well-known path.

---------------------------------------------------------------------------

§8.4:

>  Service Name: _brski-proxy
...
>  Service Name: _brski-registrar

You almost certainly don't want the service name to contain a leading
underscore. That is added as part of the DNS-SD resolution process, but
not part of the service name itself.

---------------------------------------------------------------------------

Appendix B:

>  For example, if the first
>  Multicast DNS _bootstrapks._tcp.local response doesn't work then the
>  second and third responses are tried.

I got a little lost here. Where is the "bootstrapks" service defined?
I don't see it defined in this document or registered at
https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml?search=bootstrapks

---

From: Michael Richardson <[email-masked]>
Date: Thu, 11 Jul 2019 15:55:33 -0400

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.

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

    > 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 <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-

---

From: Michael Richardson <[email-masked]>
Date: Thu, 11 Jul 2019 16:02:01 -0400

> 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   [
]     [email-masked]  http://www.sandelman.ca/        |   ruby on rails    [

---

From: Michael Richardson <[email-masked]>
Date: Thu, 11 Jul 2019 16:05:10 -0400

<#secure method=pgpmime mode=sign>

    > ambiguity will cause an interop issue. Please be explicit about precisely how

I see how this could be confusing.

    > 7231, so it's really unclear what section this was attempting to target.

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?

---

From: Ted Hardie <[email-masked]>
Date: Thu, 11 Jul 2019 13:52:51 -0700

Howdy,

On Thu, Jul 11, 2019 at 1:02 PM Michael Richardson <[email-masked]>
wrote:

> 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

---

From: Eliot Lear <[email-masked]>
Date: Thu, 11 Jul 2019 23:44:55 +0200

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

---

From: Benjamin Kaduk <[email-masked]>
Date: Thu, 11 Jul 2019 16:48:48 -0500

> 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 signe…

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

-Ben

---

From: Eliot Lear <[email-masked]>
Date: Thu, 11 Jul 2019 23:49:13 +0200

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 <[email-masked]> wrote:
> 
> Signed PGP part
> One thought:
>

---

From: Eliot Lear <[email-masked]>
Date: Thu, 11 Jul 2019 23:59:57 +0200

> On 11 Jul 2019, at 23:48, Benjamin Kaduk <[email-masked]> wrote:
> 

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

---

From: Adam Roach <[email-masked]>
Date: Thu, 11 Jul 2019 17:25:44 -0500

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

>    *** 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]

> 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

---

From: Adam Roach <[email-masked]>
Date: Thu, 11 Jul 2019 17:52:12 -0500

> 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

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 12 Jul 2019 15:30:56 +1200

On 12-Jul-19 10:52, Adam Roach wrote:
> 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 

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

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

---

From: Eliot Lear <[email-masked]>
Date: Fri, 12 Jul 2019 09:27:11 +0200

Hi Adam

> On 12 Jul 2019, at 00:25, Adam Roach <[email-masked]> 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

---

From: "Max Pritikin (pritikin)" <[email-masked]>
Date: Fri, 12 Jul 2019 15:21:25 +0000

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 <[email-masked]<mailto:[email-masked]>> wrote:

Hi Adam

On 12 Jul 2019, at 00:25, Adam Roach <[email-masked]<mailto:[email-masked]>> wrote:

Eliot

---

From: Michael Richardson <[email-masked]>
Date: Fri, 12 Jul 2019 17:07:30 -0400

Max and Toerless, please search for your name.

    > "Retry-After" header field with a 202 response, so I presume this diagram

Thank you. It should say 202.

    > RFC 7159 has been obsoleted by RFC 8259.

updated.

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

fixed.

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

fixed.

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

fixed.

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

fixed.

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

fixed.

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

fixed.

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

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

okay.

    > only the end. I believe that you mean "omitted" (here and elsewhere in this

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

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

done.

    > the "est" well-known path.

The response we got from Mark Nottingham was that this document would
have to Updates: RFC7030.
I'd rather not change the "est", but we could do that at this point.
Max?

    > not part of the service name itself.

fixed.

    > https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml?search=bootstrapks

Toerless, can you help here?
I think that we renamed this.

---

From: Adam Roach <[email-masked]>
Date: Fri, 12 Jul 2019 16:29:32 -0500

Thanks for your reply. Responses to questions below.

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

> 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

---

From: Michael Richardson <[email-masked]>
Date: Sun, 14 Jul 2019 17:33:22 -0400

Eliot Lear <[email-masked]> 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  [ 
]     [email-masked]  http://www.sandelman.ca/        |   ruby on rails    [

---

From: Michael Richardson <[email-masked]>
Date: Sat, 13 Jul 2019 11:13:32 -0400

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 <[email-masked]> 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.

---

From: Michael Richardson <[email-masked]>
Date: Sat, 13 Jul 2019 11:10:27 -0400

Eliot Lear <[email-masked]> 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.

---

From: "Joel M. Halpern" <[email-masked]>
Date: Mon, 15 Jul 2019 00:45:08 -0400

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

---

From: Eliot Lear <[email-masked]>
Date: Mon, 15 Jul 2019 09:39:56 +0200

> On 13 Jul 2019, at 17:10, Michael Richardson <[email-masked]> wrote:
> 
> Signed PGP part
> 

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

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.

> the device.  In my experience buying used routing equipment, this is never

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

---

From: Adam Roach <[email-masked]>
Date: Mon, 15 Jul 2019 10:49:43 -0500

> On Jul 15, 2019, at 02:39, Eliot Lear <[email-masked]> 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

---

From: Adam Roach <[email-masked]>
Date: Mon, 15 Jul 2019 10:52:02 -0500

> 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 on…

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

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 16 Jul 2019 08:38:46 +1200

> 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

---

From: Adam Roach <[email-masked]>
Date: Mon, 15 Jul 2019 16:10:38 -0500

On 7/15/19 3:38 PM, Brian E Carpenter wrote:
> 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

---

From: "Joel M. Halpern" <[email-masked]>
Date: Mon, 15 Jul 2019 17:42:50 -0400

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

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 16 Jul 2019 10:28:14 +1200

Joel,

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

Regards
   Brian

---

From: "Joel M. Halpern" <[email-masked]>
Date: Mon, 15 Jul 2019 20:03:09 -0400

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

---

From: Eliot Lear <[email-masked]>
Date: Tue, 16 Jul 2019 13:21:38 +0200

Hi Joel,

> On 15 Jul 2019, at 23:42, Joel M. Halpern <[email-masked]> 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
> 
>> 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

---

From: Joel Halpern Direct <[email-masked]>
Date: Tue, 16 Jul 2019 08:59:47 -0400

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 <[email-masked] 
>> <mailto:[email-masked]>> 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
> 
> 
> 
> 
>>> 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
>

---

From: Eliot Lear <[email-masked]>
Date: Tue, 16 Jul 2019 15:40:27 +0200

Hi Joel,

> On 16 Jul 2019, at 14:59, Joel Halpern Direct <[email-masked]> wrote:
> 
> 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

---

From: "Joel M. Halpern" <[email-masked]>
Date: Tue, 16 Jul 2019 09:57:54 -0400

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

Yours,
Joel

---

From: Eliot Lear <[email-masked]>
Date: Tue, 16 Jul 2019 16:02:43 +0200

> On 16 Jul 2019, at 15:57, Joel M. Halpern <[email-masked]> 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

---

From: Michael Richardson <[email-masked]>
Date: Tue, 16 Jul 2019 13:55:32 -0400

Adam Roach <[email-masked]> 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.

      <t>
        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.
      </t>
      <t>
        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.
      </t>
      <t>
        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
        <xref target="pledgeReductions" />. 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).
      </t>

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.

---

From: Michael Richardson <[email-masked]>
Date: Tue, 16 Jul 2019 15:05:23 -0400

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

---

From: Michael Richardson <[email-masked]>
Date: Tue, 16 Jul 2019 15:08:40 -0400

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

---

From: Barry Leiba <[email-masked]>
Date: Tue, 16 Jul 2019 15:29:25 -0400

> 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

---

From: Michael Richardson <[email-masked]>
Date: Tue, 16 Jul 2019 15:35:34 -0400

Adam Roach <[email-masked]> 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.

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

---

From: Michael Richardson <[email-masked]>
Date: Tue, 16 Jul 2019 15:47:13 -0400

Joel Halpern Direct <[email-masked]> 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. 

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

---

From: "Joel M. Halpern" <[email-masked]>
Date: Tue, 16 Jul 2019 15:49:32 -0400

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

---

From: Michael Richardson <[email-masked]>
Date: Tue, 16 Jul 2019 15:53:25 -0400

Adam Roach <[email-masked]> 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.

---

From: Michael Richardson <[email-masked]>
Date: Tue, 16 Jul 2019 15:58:52 -0400

Eliot Lear <[email-masked]> wrote:
    >>> 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.

But, the pledge has to be programmed to do the validation we describe.

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

I am completely unfamiliar with those protocols.
I would very much like to define a way to update voucher validation trust
anchors in that.

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

This is a good sales channel integration point, and might be a win-win for
many manufacturers and operators.
Why pay for support on devices that are no longer used?
Why generate security patches for devices no longer used?

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 17 Jul 2019 08:31:36 +1200

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

---

From: "Joel M. Halpern" <[email-masked]>
Date: Tue, 16 Jul 2019 16:59:55 -0400

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

---

From: Adam Roach <[email-masked]>
Date: Tue, 16 Jul 2019 16:28:17 -0500

> iauthority to 'authority'.

I'm happy with this solution if you are.

/a

---

From: Adam Roach <[email-masked]>
Date: Tue, 16 Jul 2019 16:33:59 -0500

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.

>          and is aware of what manufacturers it expects to see on it's

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

>          mechanism presented in this and the ACP document represents a

Nit: add a citation for "ACP document"

Thanks!

/a

---

From: Toerless Eckert <[email-masked]>
Date: Wed, 17 Jul 2019 00:03:07 +0200

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

-- 
---
[email-masked]

---

From: Eliot Lear <[email-masked]>
Date: Wed, 17 Jul 2019 07:38:25 +0200

Hi Toerless,

> On 17 Jul 2019, at 00:03, Toerless Eckert <[email-masked]> wrote:
> 
> 

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 ;-)

---

From: Toerless Eckert <[email-masked]>
Date: Wed, 17 Jul 2019 10:13:39 +0200

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:
> 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 ;-)
> 

-- 
---
[email-masked]

---

From: Michael Richardson <[email-masked]>
Date: Wed, 17 Jul 2019 17:13:13 -0400

Joel M. Halpern <[email-masked]> 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...

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.

---

From: "Joel M. Halpern" <[email-masked]>
Date: Thu, 18 Jul 2019 10:24:53 -0400

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

Thank you,
Joel