Re: [Anima] [lamps] RFC8994/8995 requirements for CSRattr

[Eliot Lear]

Hi David,

Good way to have described the situation, and the one comment you added 
about e2e validation of EE<->CA to me is something that seems worthy of 
discussion.


Eliot

On 01.09.21 15:47, David von Oheimb wrote:


Elliot,

good point that modifying things on the RA-CA channel affects fewer 
implementations/devices than updates on the EE-RA channel.


A further way to avoid opening a second channel between the RA and CA 
is not to augment the EE-RA channel
is to improve the existing RA-CA channel in a way that is already 
covered by standards.


For instance, when using CMP or CMS in this channel, the RA can inject 
new CSR fields  (or modify anything in the CSR) as follows.
The RA (Registrar) verifies the proof-of-origin and 
proof-of-possession of the CSR received from the EE (Pledge).
The RA builds up a new CSR with all the contents it wishes to take 
over and adds/modifies whatever it wishes.
The RA signs this CSR (which is on behalf of the EE) with its own key 
material, asserting that it verified the PoP etc.


Sure in this way the original PoP is broken up, but if required the 
original CSR could be sent along with the modified one.
Anyway, the RA needs to be an entity trusted by the CA, so it should 
not be a problem that it re-builds the CSR.,


    David


On 01.09.21 15:29, Eliot Lear wrote:

David,

I mention that point because we already done this in one case with a CA,
and my concern is that our code will bloat as we have to customize to
other CAs.  It's a matter of whether you think you can influence the end
devices or the CAs, and there are a lot more of the former than the
latter.  I really don't have a crystal ball here.  If we can get code
implemented on clients, keeping this to the RAs and endpoints would be
great.  But that means that the client interfaces all need the code.
And today, it's simply not there for many of them.  They have either
ruby or python or go and a bit of devkit to match.

Eliot


On 01.09.21 15:20, David von Oheimb wrote:

In my view, the idea recently brought up here (namely, to open a
further channel between RA(s) and CA(s)
besides the regular enrollment protocol just to be able to convey some
extra data to insert in the certificate)
is not good at all. It would be needlessly cumbersome and most likely
would not become generally accepted.

Instead, the extra data should be communicated as part of the
(possibly corrected/extended) existing enrollment protocol.
As far as EST is concerned, I'm glad to see that it has been decided
to update/correct the CSRattrs mechanism of RFC 7030.

     David

On 30.08.21 09:40, Eliot Lear wrote:

I would suggest that it helps in these cases to back up to the
scenarios we care to address, and the likelihood of success.  In some
cases, it will be possible to coordinate development with the
endpoints and sometimes with the CAs. The CAs may not be strongly
motivated to standardize an out-of-band/underlay RA/CA interface-
some already have proprietary versions, and may like that with the
hope of locking in the endpoints along the way.

Eliot


On 30.08.21 01:31, Dan Harkins wrote:

   Hi Michael,

   Why can't the RA signal to the CA whatever things it things should
be included in the CA, in addition to the goo provided in the client's
CSR? If the Registrar knows the name then why can't it provide it to
the CA. It will be providing the CSR to the CA, on behalf of the client,
so why can't it say "oh by the way, add this name for the pledge"

   Why don't you want to define _that_ signalling instead of overloading
a different protocol?

   Dan.


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


OpenPGP_signature
Description: OpenPGP digital signature
___
Anima mailing list
Anima@ietf.org
https://www.ietf.org/mailman/listinfo/anima

Re: [Anima] [lamps] RFC8994/8995 requirements for CSRattr

[Eliot Lear]

David,

I mention that point because we already done this in one case with a CA, 
and my concern is that our code will bloat as we have to customize to 
other CAs.  It's a matter of whether you think you can influence the end 
devices or the CAs, and there are a lot more of the former than the 
latter.  I really don't have a crystal ball here.  If we can get code 
implemented on clients, keeping this to the RAs and endpoints would be 
great.  But that means that the client interfaces all need the code.  
And today, it's simply not there for many of them.  They have either 
ruby or python or go and a bit of devkit to match.


Eliot


On 01.09.21 15:20, David von Oheimb wrote:


In my view, the idea recently brought up here (namely, to open a 
further channel between RA(s) and CA(s)
besides the regular enrollment protocol just to be able to convey some 
extra data to insert in the certificate)
is not good at all. It would be needlessly cumbersome and most likely 
would not become generally accepted.


Instead, the extra data should be communicated as part of the 
(possibly corrected/extended) existing enrollment protocol.
As far as EST is concerned, I'm glad to see that it has been decided 
to update/correct the CSRattrs mechanism of RFC 7030.


    David

On 30.08.21 09:40, Eliot Lear wrote:


I would suggest that it helps in these cases to back up to the 
scenarios we care to address, and the likelihood of success.  In some 
cases, it will be possible to coordinate development with the 
endpoints and sometimes with the CAs. The CAs may not be strongly 
motivated to standardize an out-of-band/underlay RA/CA interface- 
some already have proprietary versions, and may like that with the 
hope of locking in the endpoints along the way.


Eliot



On 30.08.21 01:31, Dan Harkins wrote:


  Hi Michael,

  Why can't the RA signal to the CA whatever things it things should
be included in the CA, in addition to the goo provided in the client's
CSR? If the Registrar knows the name then why can't it provide it to
the CA. It will be providing the CSR to the CA, on behalf of the client,
so why can't it say "oh by the way, add this name for the pledge"

  Why don't you want to define _that_ signalling instead of overloading
a different protocol?

  Dan.







OpenPGP_signature
Description: OpenPGP digital signature
___
Anima mailing list
Anima@ietf.org
https://www.ietf.org/mailman/listinfo/anima

Re: [Anima] [lamps] RFC8994/8995 requirements for CSRattr

[Eliot Lear]

I would suggest that it helps in these cases to back up to the scenarios 
we care to address, and the likelihood of success.  In some cases, it 
will be possible to coordinate development with the endpoints and 
sometimes with the CAs.  The CAs may not be strongly motivated to 
standardize an out-of-band/underlay RA/CA interface**- some already have 
proprietary versions, and may like that with the hope of locking in the 
endpoints along the way.


Eliot



OpenPGP_signature
Description: OpenPGP digital signature
___
Anima mailing list
Anima@ietf.org
https://www.ietf.org/mailman/listinfo/anima

Re: [Anima] [lamps] discussing EST CSRATTRS specifying the SAN at IETF111

[Eliot Lear]

So voluntold.

On 06.07.21 20:44, Russ Housley wrote:



LAMPS chairs: can we have ten minutes for this discussion on the Thursday
  Session III meeting at IETF111?
  The Monday Session II is conflicted with ANIMA.

I'm gonna voluntold Eliot to lead this discussion :-)

Yes, I'll add it.

Russ

___
Spasm mailing list
sp...@ietf.org
https://www.ietf.org/mailman/listinfo/spasm





OpenPGP_signature
Description: OpenPGP digital signature
___
Anima mailing list
Anima@ietf.org
https://www.ietf.org/mailman/listinfo/anima

Re: [Anima] [Iotops] BRSKI and IDevID (non-!)issues with draft-ietf-uta-use-san

[Eliot Lear]

Rich,

As I wrote, I think we’re past it, because this is about domain/IP address 
validation and not client cert validation.  Correct?

Eliot

> On 14 May 2021, at 16:02, Salz, Rich  wrote:
> 
>>   There are a VAST number of devices that run off of iDevIDs: they never 
>> transition off of them.  I’m not a fan, but that’s what they do.
> 
> Okay, so this draft doesn't apply to them.  There doesn't seem to be a 
> problem with, say, not using TLS 1.3 in cases, or not using ECDH in some 
> cases, so why is this draft different from those situation?
> 



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

Re: [Anima] [Iotops] BRSKI and IDevID (non-!)issues with draft-ietf-uta-use-san

[Eliot Lear]

Hi,

I think we’re past this, but just to be clear:

There are a VAST number of devices that run off of iDevIDs: they never 
transition off of them.  I’m not a fan, but that’s what they do.

Eliot

> On 14 May 2021, at 02:22, Michael Richardson  wrote:
> 
> Signed PGP part
> 
> I read the document before it was adopted (before SECDISPATCH), and I didn't
> see any problems with it.
> 
> I have re-read it in the context of IoT or enterprise (routers) devices that
> might contain long-lived IDevID (sometimes called Manufacturer Installed
> Certificates, confusingly appreviated "MIC").
> CISCO calls them Secure Unique Device Identifier (SUDI), and there are many
> other manufacturers with their own interesting names.
> I believe that the CHIP/MATTER effort also mandates such a thing for the
> purposes of identity and device attestation.
> 
> In BRSKI (about to be RFC8995) TLS connections are initiated from a client
> (the pledge) to a Registrar.  The TLS connections make use of
> ClientCertificates for identification.  RFC6125 rules are not relevant
> to validation of the client certificate.
> If a CN=, emailAddress= or DC= was present in the ClientCertificate it would
> not be used as part of the validation in a compliant Registrar.
> The Registrar cares about the X520SerialNumber (aka "serialNumber=") only.
> 
> In the other direction, the pledge does not initially validate the Registrar
> ServerCertificate at all.  It is taken as given, provisionally, until such
> time as the pledge gets corroboration from an RFC8366 voucher.  In general,
> the Registrar certificate is issued from a private (enterprise) PKI, and the
> corroboration depends upon a sales relationship with the vendor (the MASA).
> 
> RFC6125 DNS-ID validations may occur in the MASA, depending upon policy.
> The new rules from use-san should apply without a problem, if any 6125
> validation (vs explicit pinning) was used.
> The Registrar->MASA connection is already explicitely RFC6125 DNS-ID only.
> 
> In summary, I don't see anything in use-san that will affect BRSKI.
> 
> It may be that Cisco and other manufacturers use their certificates in other
> ways, and I can't speak for whether they might be affected.
> 
> 
> Some nits:
> 
>>  While not discussed in [RFC6125] this section also implicitly
>>  prohibits the use of the Domain Component or emailAddress RDN's.
> 
> 1) it seems like, since it's mentioned here, that it's not "implicit" at all.
>   It seems rather explicit to me.
> 
> 2) I think that the deprecation of a sequence of "DC=" probably warrants a
>   sentence of its own.
> 
> 3) I'm unclear how emailAddress was used when a DNS name was desired.
>   Were there rules that allowed the client to say, "connect to example.com"
>   and then validation was okay if the certificate says 
> emailAddress=f...@example.com?
>   If so, then I think that this situation should be more clearly deprecated.
> 
> 4) I suggest that section 3 "The New Rules" should be in positive language
>   only.  Most of the language is what not to do.  I think that this is
>   important to list, but I suggest it be split up into a section "Do this"
>   and a section "Do not do this"
> 
> --
> Michael Richardson. o O ( IPv6 IøT consulting )
>   Sandelman Software Works Inc, Ottawa and Worldwide
> 
> 
> 
> 
> 
> 



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

Re: [Anima] AUTH48 request for CSR example

[Eliot Lear]

No.

> On 14 Apr 2021, at 11:04, Brian Carpenter  wrote:
> 
> Is this worth the extra delay? A change like this is hardly editorial & I do 
> not think we want to wait for a mini last call. I am against any 
> non-essential change.
> 
> Regards,
> Brian Carpenter
> (via tiny screen & keyboard)
> 
> On Wed, 14 Apr 2021, 20:27 Esko Dijk,  > wrote:
> Hi,
> 
> It would be a good idea to add a practical example of the CSR attributes 
> response. Is there a particular reason to have an example with very little 
> content in it i.e. 1 root-level attribute only ?
> In RFC 7030:
>The structure of the CSR Attributes Response SHOULD, to the greatest
>extent possible, reflect the structure of the CSR it is requesting.
> 
> So I would expect to have a data structure that defines for example what 
> Subject DN attributes the client should include. Or particular choice of 
> crypto system, signature scheme etc.
> Given the amount of confusion around this particular data structure, examples 
> would be good. Or maybe explain why having a "minimal" CSR attributes 
> response is a good thing?
> I can imagine it is good if the Registrar puts as little as possible 
> requirements on the Pledge how to structure its CSR and only MUST-have fields 
> (like ACP related ones?) are indicated.
> 
> Here another example:
> 
> 30 30 06 03 55 04 03 06 03 55 04 05 06 03 55 04 0A 06 08 2A 86 48 CE 3D 04 03 
> 02 30 15 06 07 2A 86 48 CE 3D 02 01 31 0A 06 08 2A 86 48 CE 3D 03 01 07
> 
> SEQUENCE (5 elem)
>   OBJECT IDENTIFIER 2.5.4.3 commonName (X.520 DN component)
>   OBJECT IDENTIFIER 2.5.4.5 serialNumber (X.520 DN component)
>   OBJECT IDENTIFIER 2.5.4.10 organizationName (X.520 DN component)
>   OBJECT IDENTIFIER 1.2.840.10045.4.3.2 ecdsaWithSHA256 (ANSI X9.62 ECDSA 
> algorithm with SHA256)
>   SEQUENCE (2 elem)
> OBJECT IDENTIFIER 1.2.840.10045.2.1 ecPublicKey (ANSI X9.62 public key 
> type)
> SET (1 elem)
>   OBJECT IDENTIFIER 1.2.840.10045.3.1.7 prime256v1 (ANSI X9.62 named 
> elliptic curve)
> 
> Not sure whether this is better or worse, in terms of usage of CSR attributes 
> in practice. But it is more clear at least from an explanation point of view, 
> what this data was intended for.
> 
> Esko
> 
> -Original Message-
> From: Michael Richardson mailto:m...@sandelman.ca>>
> Sent: Wednesday, April 14, 2021 01:56
> To: anima@ietf.org ; la...@ietf.org 
> ; Esko Dijk  >; Mudumbai Ranganathan  >
> Cc: priti...@cisco.com ; tte+i...@cs.fau.de 
> ; michael.h.behrin...@gmail.com 
> ; kent+i...@watsen.net 
> 
> Subject: AUTH48 request for CSR example
> 
> https://github.com/anima-wg/anima-bootstrap/issues/20 
>  asks me to provide an
> example of a CSR attributes reply.  I have one, it looks like:
> 
> obiwan-[files/product/00-D0-E5-F2-00-02](2.6.6) mcr 11413 %openssl asn1parse 
> -in csrattr.der -inform der
> 0:d=0  hl=2 l=  72 cons: SEQUENCE
> 2:d=1  hl=2 l=  70 cons: SEQUENCE
> 4:d=2  hl=2 l=   3 prim: OBJECT:X509v3 Subject Alternative 
> Name
> 9:d=2  hl=2 l=  63 cons: SET
>11:d=3  hl=2 l=  61 cons: SEQUENCE
>13:d=4  hl=2 l=  59 cons: cont [ 1 ]
>15:d=5  hl=2 l=  57 prim: UTF8STRING
> :rfcself+fd739fc23c3440112233445500...@acp.example.com 
> 
> 
> I don't know if this worth adding.
> 
> --
> ]   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[
> 
> 
> 
> 
> ___
> 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



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

Re: [Anima] [lamps] Long-lived certificates, but frequently renewed certificates

[Eliot Lear]

> On 22 Mar 2021, at 22:28, Nico Williams  wrote:
> 
> End entities send a validation chain for their EE certs, but not the
> root CA's cert, and anyways, RPs need to know trust anchors a priori.
> Therefore rolling out new TAs is tricky.

The presumption we make in the enterprise is that distribution of TAs in 
services happens as a matter of normal system management.  Absent those TAs the 
service is going to experience a whole lot of failures.  At the application 
level beyond the bounds of the enterprise, this is a different matter, to be 
sure.


> 
> TA rollover needs a device update protocol.

Within the bounds of the enterprise, that’s EST (RFC 7030).  See Section 4.1.2 
“/cacerts”.  This delivers a PKCS#7 pack of certs.  RFC 8951 modestly amends 
that.

> 
> (Speaking of uniformResourceIdentifier type issuerAltNames, what are
> their semantics?  If RFC5280 covers that, I've missed it.)

Good question.

> 
>> The LDevID change out is harder.  A device can have many trust
>> anchors, but the LDevID change-out has to be handled a bit more
>> carefully.
>> 
>> [...]
> 
> Yes, devices can have considerations that an EST server may not be able
> to know.
> 
> So I think we're talking about the server indicating a refreshAfter time
> or a doNotRefreshBefore time rather than a refreshAt time.  An
> informative "you can refresh after this $time" and maybe a normative "do
> not even think of refreshing before this $time".

That covers one case.  Another case that has to be covered is when there’s a 
need for an unscheduled rollover.  This might happen if there was some concern 
that a private key has been compromised.  And then...

> 
> That said, a simple certificate refresh where no algorithms change, no
> parameters change, no critical extensions are added, etc. -- where the
> only real change is the validity period -- surely this is safe to
> perform whenever the device can talk to the online CA.  One could argue
> that making sure that the only change is the validity period (and maybe
> the SPKI, but not its alg or params) is difficult to ensure.  Michael
> tells me maybe the CA software gets upgraded and other changes sneak in
> that one did not expect.

Well, and we haven’t even begun to discuss secure time stamps here (you can 
track some recent discussion of that discussion on the openssl-users list).  
And you’re hitting another issue- stuff like RFC 4476.  I don’t know how widely 
that extension is found, but there are others; and there is something of a 
debate in some circles about whether to do RBAC et al in certs.

And so an occasional query also seems appropriate.  EST doesn’t really define 
that.

Eliot



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

Re: [Anima] [lamps] Long-lived certificates, but frequently renewed certificates

[Eliot Lear]

> On 20 Mar 2021, at 19:00, Michael Richardson  wrote:
> 
> It has to be a three phase commit, and it needs to be initiated from the EST 
> server.

See my answer to Nico.  The EST server certainly knows when it wants to roll 
the information.  But doing so in the middle of a heart bypass operation is not 
something it should decide.  Once the decision is made, however, the three 
phase commit sounds good,

Eliot



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

Re: [Anima] [lamps] Long-lived certificates, but frequently renewed certificates

[Eliot Lear]

[Reducing]

Hi Nico,

> On 20 Mar 2021, at 21:36, Nico Williams  wrote:
>> 
>> This is definitely a problem in a number of deployments.  One aspect
>> that people have to deal with is not so much the gross expiry time,
>> but when it is convenient to take a risk of moving to a new cert.  Of
>> course you’re going to want to make that operation as bullet-proof as
>> possible, but in some environments they want multiple levels of
>> resilience.  So scheduling does become an issue.
> 
> Can you elaborate on this?  Is the issue validation path construction in
> complex PKIs?

Mostly not.  There are two objects that have to be addressed:

Device LDevID expiration and update.
Trust Anchor roll.

The Second case is generally easier, so long as the device is regularly in 
service; and it may even be easy when the device is out of service for extended 
periods (think years) so long as it is thought about in advance by both 
implementor and deployment.

The LDevID change out is harder.  A device can have many trust anchors, but the 
LDevID change-out has to be handled a bit more carefully.

And how this happens may well vary.  Let’s consider several use cases:

An electrical substation, in which the device is expected to remain in service 
for perhaps two decades without an outage.  In this case, the updates have to 
occur in service.
A hospital bed.  In this case, the device will be out of service as often as 
in, and updates can occur when it is out of service.
A railroad box car/container.  These things are expected to run on battery 
without maintenance for five years, and may sit idle for weeks or months 
without any connectivity.  This case is extremely tough and is a bit of a 
stretch goal.

Each of these sorts of examples occurs in nearly every vertical.  One question 
is whether scheduling should be in protocols like EST or in device 
configuration.

Eliot



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

Re: [Anima] [lamps] Long-lived certificates, but frequently renewed certificates

[Eliot Lear]

Hiya,

> On 18 Mar 2021, at 19:58, Michael Richardson  wrote:
> 
> A pity that EST (and I think SCEP, but I haven't read it all), just returns
> the resulting certificate, and not something more useful, like a JSON dict
> that includes the certificate.
> 
> RFC7030 has a 202, Retry-After, which could be used to tell the holder to
> go away and come back later, but the intended use is not to say not now,
> but rather, "I'm working on it".

This is definitely a problem in a number of deployments.  One aspect that 
people have to deal with is not so much the gross expiry time, but when it is 
convenient to take a risk of moving to a new cert.  Of course you’re going to 
want to make that operation as bullet-proof as possible, but in some 
environments they want multiple levels of resilience.  So scheduling does 
become an issue.

The big question is- who does the scheduling?  Is it the end system?  Is it the 
EST server?  Who knows when “convenient” is?  Probably the answer is “both”.

Eliot

> 
> If the whole thing was more RESTful, then holders could be told to GET their
> certificate from some place, and we could use ETag, and Expiry headers to
> tell the holder that it hasn't changed, and isn't expected to change for
> awhile, so piss off and come back then.
> 
> In the full ACP situation, then we might expect holders to have active
> RESTCONF management, and then we can renew certificates in a push scenario
> using draft-ietf-netconf-sztp-csr-01, which I note is now past WGLC.
> 
>> A related idea is that an RP can want certificates to be "fresh" enough
>> regardless of when their notAfters are, and again, there's no signaling
>> that via the supplicant's certificate unless somehow the issuer is
>> expected to know a policy all RPs want.
> 
> I'm much less concerned about the RP here.
> The reason to issue long lifetime certificates is that things don't break
> just because some less critical infrastructure is not alive, or not reachable.
> 
> Our reference example/use case in brski-async-enroll is communication between
> thermostats and furnaces in a (newly built) residence.
> The furnace needs to heat keep the home above zero even when the house is not
> occupied, and possibly has not yet been occupied.
> 
> Maybe abuse of the certificate renewal process is the wrong way to accomplish
> transfers of ownership.
> 
> --
> Michael Richardson. o O ( IPv6 IøT consulting )
>   Sandelman Software Works Inc, Ottawa and Worldwide
> 
> 



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

Re: [Anima] Erik Kline's Discuss on draft-ietf-anima-autonomic-control-plane-28: (with DISCUSS and COMMENT)

[Eliot Lear]

Hi Erik

I wonder if the simpler fix is simply to replace the word “counterpart” with 
“analog”.

Eliot

> On 27 Sep 2020, at 23:52, Erik Kline  wrote:
> 
> Toerless,
> 
> Thanks for taking the time to go through all this.  Generally LGTM, but I 
> would like to iterate on the ULA text (nothing major).
> 
> 
> > [ section 2 ]
> > 
> > * "It is the approximate IPv6 counterpart of the IPv4 private address
> >   ([RFC1918])."
> > 
> >   I understand the intent but I don't think this statement is complete. I
> >   think we shouldn't let this sentence out into the wild as is since it 
> > could
> >   be read without any context nor even any pretense of interest in nuance.
> > 
> >   May I suggest:
> > 
> >   "It is often thought of as the approximate IPv6 counterpart of the IPv4
> >   private address space ([RFC1918]), though it is in fact meaningfully
> >   different in important and subtle ways [and upon which this document 
> > relies]."
> 
> Thanks for not trying to talk me out of the comparison, which i successfully
> used to explain ULA to many customers. Your proposal is a bit too verbose for
> the terminoloy section, so it's now:
> 
> It is often thought of as the approximate IPv6 counterpart of the IPv4 
> private address (). There are 
> important differences though that are beneficial for and exploited by the 
> ACP, such as the ULA Global ID prefix, which are the first 48-bits of a ULA 
> address. In this document it is abbreviated as "ULA prefix".
> 
> It's a statement of fact that this is how people unfamiliar with this space 
> view this space.  It's apparently also a statement of fact that people are 
> still actively being told this.  ;-)
> 
> But I still think it's not quite right.  For one, the real counterpart to 
> 1918 in IPv6 is the deprecated site-local prefix.  Also, to say it's "often 
> thought of" in an IETF document implies more IETF folks think of this way, 
> when in reality I'm not sure that's the case.
> 
> If you really want to leave this notion in (removing the sentence altogether 
> is good by me), perhaps we can wordsmith it a bit more.  If I may propose:
> 
> OLD:
> 
>ULA: (Global ID prefix)  A "Unique Local Address" (ULA) is an IPv6
>   address in the block fc00::/7, defined in [RFC4193].  It is often
>   thought of as the approximate IPv6 counterpart of the IPv4 private
>   address ([RFC1918]).  There are important differences though that
>   are beneficial for and exploited by the ACP, such as the ULA
>   Global ID prefix, which are the first 48-bits of a ULA address.
>   In this document it is abbreviated as "ULA prefix".
> 
> NEW:
> 
>ULA: (Global ID prefix)  A "Unique Local Address" (ULA) is an IPv6
>   address in the block fc00::/7, defined in [RFC4193].  Sometimes
>   thought of as the approximate IPv6 counterpart of the IPv4 private
>   address ([RFC1918]), there are important differences that are
>   beneficial for and exploited by the ACP.  In this document, the
>   "ULA prefix" refers to Locally Assigned Global ID prefixes, which
>   are the first 48-bits of the ULA address [RFC4193 section 3.2.1].
> 
> (I didn't think it was worth trying to get into the fc00::/8 vs fd00::/8 
> distinction in this glossary text.)
> 
> > [ section 8.1.3 ]
> > 
> > * Why is an RIO for ::/0 with a lifetime of 0 required?  Doesn't it suffice
> >   it set the default router lifetime to 0?  Separately, are all nodes 
> > required
> >   to be Type C?
> 
> Check the new text, i hope it explains everything.
> 
> Yes, type A and B do not support per-prefix auto selection of router,
> The lifetime of 0 is used so only Type C hosts will invalidate the
> default route for the ACP edge node, but not Type A/B hosts. Maybe there
> is another parameter combination that achieves this goal, but this was
> the easiest for me to assess/describe.
> 
> This looks better, thank you.
> 
> To be honest, I don't know what the point of Type A/B hosts is anymore (and 
> if it were possible to declare these anima deployments greenfield I would 
> recommend saying the default router lifetime MUST be zero in the RA header to 
> force clients to use a stack that works -- but that's just me). 
> ___
> 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] Handling of endpoint path names (from BRSKI-AE discussion today)

[Eliot Lear]

Steffen

I enjoyed today’s discussion.  My suggestion is a short document that does not 
CHANGE endpoints but simply creates new ones that have the same functionality 
as the old ones.  That doesn’t require an “Updates” header, and based on that I 
think you might even keep these in the same document.  Would people be ok with 
that?

Eliot

> On 30 Jul 2020, at 17:46, Fries, Steffen  wrote:
> 
> Hi,
> 
> Based on the discussion of splitting up the voucher handling endpoint naming 
> issues from BRSKI-AE today, I just wanted to ensure I got the way forward 
> right. 
> From the Etherpad discussion I understood Michael that he would not be too 
> happy with having a BRSKI update right after BRSKI publication as RFC. I 
> think finalizing the discussion on the list was advised.
> 
> What we discussed in the WG meeting was to have a separate short document, 
> basically defining a renaming or alternatively an alias for the current 
> endpoints, which allows to keep the current implementations as is. 
> Hence, the draft would relate to all of the endpoints defined in section 5 of 
> BRSKI for the domain registrar facing the pledge (and potentially also the 
> MASA), which are: 
> /.well-known/est/requestvoucher   used by pledge to registrar but also 
> from registrar to MASA
> /.well-known/est/voucher_status   used by pledge to registrar
> /.well-known/est/requestauditlog  used by registrar to MASA
> /.well-known/est/enrollstatus used by pledge to registrar
> 
> From Toerless I understood that he would like to not change the current draft 
> as it is already in the final state and rather provide an update as separate 
> document.
> From Michael I understood he would not be keen on having a fast update for 
> the BRSKI document. At least not for a renaming of the defined endpoints. 
> Also the IESG may view this as too fast. 
> Eliot stated that there are already implementations out there that utilize 
> the /est approach. So having aliases could be one way of dealing with it, but 
> this would double the endpoints at least for the four stated ones above. 
> 
> Both approaches have there merits. Having the endpoints distinct from the 
> beginning allows a clearer separation of the functionalities, for the pledge 
> and for server side handling. Specifically if we later on allow for 
> alternative enrollment protocols in BRSKI-AE and define the discovery 
> approach, it will lead to less confusion to align the naming with the 
> corresponding functionality. From that perspective, my gut feeling would be 
> that an integration into base BRSKI may be more appropriate. On the contrary, 
> it will slow down the process, but somebody stated that there are examples 
> that these changes have been also done in the past and could be done fast. 
> 
> What do you suggest as way forward? 
> 
> Best regards
> Steffen
> 
> 
> --
> Steffen Fries
> Siemens AG, Corporate Technology
> mailto:steffen.fr...@siemens.com
> 

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

Re: [Anima] ANIMA: Reminder: Re: Call for agenda ANIMA @ IETF 108, online

[Eliot Lear]

Hi Toerless,

The co-authors would like to have a few minutes to talk about BRSKI-AE.  I 
think 10 ought to do.

Thanks,

Eliot

> On 21 Jul 2020, at 05:54, Toerless Eckert  wrote:
> 
> Reminder. Please bring forward for any agenda items you want to see.!
> 
> Thanks
>Toerless
> 
> On Fri, Jul 10, 2020 at 07:51:34AM +, Sheng Jiang wrote:
>> Hi, all anima,
>> 
>> 
>> 
>> We have been allocated a sessions of 1 hour 40 minutes for the ANIMA WG 
>> meeting for IETF-108 (online). It is on Thursday, July 30, 2020?? 
>> 11:00-12:40 (UTC). We are now starting to collect agenda items for the 
>> session. Please send your request for agenda by July 21th, Tuesday, to 
>> anima-cha...@ietf.org and both chairs' email. Please note that email to a 
>> single chair may cause single-point failure.
>> 
>> 
>> 
>> As normal, the priority among these non-charter work items would be: these 
>> that have active discussion in mail list, then these have submitted drafts, 
>> and topics without drafts.
>> 
>> 
>> 
>> Please send us (anima-chairs at ietf.org) requests for time slot by July 
>> 21th, Tuesday and include:
>> 
>> 
>> 
>> Name of time slot:
>> 
>> Name of draft(s):
>> 
>> Time requested:
>> 
>> Presenter name(s):
>> 
>> 
>> 
>> More details about the IETF 108 can be found at:
>> 
>> 
>> 
>> https://www.ietf.org/how/meetings/108/
>> 
>> 
>> 
>> Again, presenters and draft authors please invoke active discussions in the 
>> ANIMA list. Mail list is a very good place to discuss and reach consensus on 
>> technical issues.
>> 
>> 
>> 
>> Best regards,
>> 
>> 
>> 
>> Sheng + Toerless
>> 
> 
> -- 
> ---
> t...@cs.fau.de
> 
> ___
> 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] New Version Notification for draft-ietf-anima-brski-async-enroll-00.txt

[Eliot Lear]

Hi everyone,

As Steffen has just noted, we have posted a WG draft.  I want highlight one 
aspect:

> On 10 Jul 2020, at 09:39, Fries, Steffen  wrote:
> 
>   o  Inclusion of discovery options of enrollment endpoints at the
>  domain registrar based on well-known endpoints in Section 5.3 as
>  replacement of section 5.1.3 in the individual draft.  This is
>  intended to support both use cases in the document.  An
>  illustrative example is provided.

This change as currently written would update basic BRSKI, and therefore 
deserves a lot of discussion.  If we want to go the route in the draft, and if 
it is not too late, I would get the change into the draft before the RFC comes 
out.

Eliot

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

Re: [Anima] ANIMA-WG: pls chime in: early allocation for otherName code points (draft-ietf-anima-autonomic-control-plane)

[Eliot Lear]

> On 2 Jul 2020, at 19:29, Michael Richardson  wrote:
> 
> Signed PGP part
> 
> Eliot Lear  wrote:
>> I have no objection.  My only caution is that otherName is poorly
>> supported in the open source tool sets, but that is something we could
>> conceivably work on.
> 
> I disagree!
> otherName is adequately supported (if poorly documented) in openssl.cnf for 
> our purposes.
> Creating otherName SAN extensions from library interface is fully supported.
> 
> The openssl x509 -text output program does not know how to format arbitrary
> otherName text, so it just says .

Whereas for a URI it will actually provide you the URI.  Also, if the otherName 
is at all complex, the openssl.cnf file is entirely counter-intuitive.  This 
having been said, one needn’t write to OpenSSL’s limitations.

Eliot

> 
> Here is an proprietary otherName that I created awhile ago, implemented in 
> ruby:
> 
>  # the OID: 1.3.6.1.4.1.46930.1 is a Private Enterprise Number OID:
>  #iso.org.dod.internet.private.enterprise . SANDELMAN=46930 .. 1
>  @idevid.add_extension(extension_factory.create_extension(
>  "subjectAltName",
>  sprintf("otherName:1.3.6.1.4.1.46930.1;UTF8:%s",
>  self.sanitized_eui64),
>  false))
> 
> The hardest part was figuring out the ";UTF8:" part, as I had to read the C
> code underneath to learn how that worked.
> (false, is I think, whether it is critical)
> 
> --
> Michael Richardson , Sandelman Software Works
> -= IPv6 IoT consulting =-
> 
> 
> 
> 
> 



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

Re: [Anima] ANIMA-WG: pls chime in: early allocation for otherName code points (draft-ietf-anima-autonomic-control-plane)

[Eliot Lear]

I have no objection.  My only caution is that otherName is poorly supported in 
the open source tool sets, but that is something we could conceivably work on.

Eliot

> On 2 Jul 2020, at 15:29, Toerless Eckert  wrote:
> 
> Dear WG (ACP author head/hat on)
> 
> ACP Revision -26 introduced a new otherName / AcpNodeName encoding for the 
> ACP Domain Information
> (now call AcpNodeName / acp-node-name). Michael Richardson (and potentially 
> other) implementors
> would like to update implementation to use this new encoding for interop 
> testing,
> which requires allocation of two IANA code points (technically i think only 
> one is
> required for the implementation, but the toolchain would require both if i 
> understand it
> correctly).
> 
> The early allocation process RFC7120 requires to vet the community for 
> interest in the
> early allocation, so pls. chime in with a +1, or if you must a -1 and 
> explanation.
> 
> I'll do a +1 from the authors side.
> 
> The remaining requirements of RFC7120 for early allocations are AFAIK met.
> 
> Thanks!
>Toerless
> 
> ___
> 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] Russ: Re: rfc822Name use in Autonomic Control Plane document

[Eliot Lear]

Hi Toerless,

I think either a URI or otherName are pretty much functionally equivalent.  I 
might go with URI for one particular reason, which is that the tooling – in 
particular OpenSSL – will handle it better.

Eliot

> On 30 Jun 2020, at 18:10, Toerless Eckert  wrote:
> 
> Just had a call with Russ and Barry (thanks Russ, Barry), and here is
> what transpired, and it comes with a Q to the ANIMA WG wrt. to
> solution options (see below). Hopefully Russ/Barry will correct me if i
> misrepresent anything.
> 
> Russ and Barry agreed that a solutions where email addresses are not
> primarily intended to be used for actual emails (e.g.: using SMTP/RFC5321)
> may be something found in the wild, but in their opinion, it would create
> harm (to i guess the Internet email system), significant enough to warrant
> an IESG DISCUSS if such use was to be defined into an Internet Standard.
> 
> If i understood it correctly, the choice of otherName by previous solutions
> similar might have also been influenced by the same rejection to use 
> rfc822Name
> It sounded to me from the call as if email address/rfc822Name  might have
> been desired to be used first by e.g.: XMPP but then they had to move to
> an otherName (RFC3920 i think) because of resistance to get that standardized.
> That at least would be a detail i was missing from the prior explanations on
> this thread.
> 
> I continue to disagree, but i think the resolution of this basic
> argument would create an inacceptable timeline to progress ANIMA,
> so i do not want to afford this discussion any longer for the ACP draft.
> [ Hopefully i can get back to after ACP is done because i still think it
> is quite fundamental. ]
> 
> a) Russ promised me a text stub or pointers thereto necessary/sufficient to 
> define a new
>   use (and i guess IANA registration). Probably something similar to
>   what is e.g.: found in rfc8398.
> 
>   I think IANA registration is here: 
> https://www.iana.org/assignments/smi-numbers/smi-numbers.xml
>   See e.g.: id-on-SmtpUTF8Mailbox, 
>   registration procedure: spec required, expert: Russ Housley
> 
> b) I brought up the point that using uniformResourceIdentifier instead
>   of a new otherName would avoid that any part of the ecosystem including 
>   diagnostic tools would have to be software updated with new ASN.1
>   en/decode work and create unique names useable outside certificates as well.
> 
>   If we used "acp:@", this would require
>   review process for the new "acp:" scheme, which according to my reading of
>   process would take maybe up to one month. Barry suggested to simply
>   register an IETF URN parameter (RFC3553), e.g.:
> 
>   urn:ietf:params:acp:@
> 
>   IANA registry: https://www.iana.org/assignments/params/params.xhtml
>   Registration procedure: IETF review (which i guess is the ACP draft 
> IETF review).
> 
> So, would love to hear opinions of a) vs. b). Am i overselling the URI option
> vs. the otherName option ? I have no experience on this backend side, i am
> just trying find the most pragmatic, easy to adopt option for operators,
> and i have seen a of backend systems (inventory management or the like)
> where names are shuffled around, and we started using email addresses because
> those are always supported identifier types in backend systems. No idea if 
> URI are that common,
> but at least they could be there because they are an existing defined 
> name/address type.
> For otherName, those uses outside certificates would need to come up with 
> their own
> field type i think.
> 
> Given how this is not an email address anymore, it
> would be prudent to introduce one degree of extensibility easier to manage:
> 
>  otherName: node:local@acp-domain-name
>  URN:   urn:ietf:params:acp:node:@
> 
> Where "node" is the value we define in ACP, and other values here
> are the extension points.
> 
> Final note: of course we loose the ability to use public CA that an
> sign rfc822Name, e.g.: via ietf-acme-email-smime, which we would have
> if we whee permitted to use email addresses as ACP names, and i was getting
> fond of that option, but given how we did not perceive this nice option
> when we started ACP, its at least no set-back from the original ACP goals.
> 
> Cheers
>Toerless
> 
> On Sun, Jun 28, 2020 at 06:11:49PM +0200, Toerless Eckert wrote:
>> 
>> On Sun, Jun 28, 2020 at 10:47:51AM -0400, Russ Housley wrote:
>>> Brian:
>>> 
>>> The point of a certificate is to bind the public key to the identity of the 
>>> private key holder.  The certificate supports many different forms of names 
>>> to support many different protocols.  The rfc822name is used to bind to an 
>>> email address.
>> 
>> How do you think IETF should decide on what is a semantic correct
>> email address ? RFC5280 simply inherited the non-crypto definitions
>> of email address/mailbox.
>> 
>> Do you think it is appropriate for you to recommend blocking progress
>> of a document through IESG review based on 

Re: [Anima] representing ACP info in X.509 certs

[Eliot Lear]

> On 24 Jun 2020, at 11:39, Toerless Eckert  wrote:
> 
> Thanks, Eliot,
> 
> inline
> 
> On Wed, Jun 24, 2020 at 09:04:59AM +0200, Eliot Lear wrote:
>> With ACP it???s clear they are overloading semantics of an rfc822name,
> 
> What is your definition of "overloading" ?
> 
> There are all type of entities addressed with rfc822name, not only
> people, but also functions and devices have been given rfc822names as well 
> forever.
> Ok, so the name part is somewhat strange because it's numeric.
> How about companies giving users email addresses that are serial numbers.
> Quite ccommon actuall i think. prof.dr.acme.exam...@domain.com - also roles 
> can be found in
> rfc822names. We're just doing what everybody and their dog has done
> with rfc822 names forever.
> 
>> and from an application standpoint we don???t like that because it is 
>> possible that different subsystems may have different uncoordinated 
>> allocation methods.
> 
> I don't think this is true

If the ACP subsystem allocates a name and the user management system allocates 
a name, then you have the potential of a conflict.  Again, the odds of an 
actual conflict are very low.

> 
>> That is- someone may be able to nab an email address via the mail subsystem 
>> a la 
>> rfcself+fd89b714f3db02006400+area51.resea...@acp.example.com 
>> <mailto:rfcself+fd89b714f3db02006400+area51.resea...@acp.example.com>,
> 
> The example explicitly used acp.example.com instead of example.com
> to ensure that allocation of email addresses in such a specific
> subdomain was not simply possible for arbitrary users who might
> allocate email addrs under example.com. Its common practivce
> in enterprises to have all type of subdomains for specific
> functions not accessible to the standard mail system setup.
> Arguing you can get an email address is like arguing you can
> fake a domain name in such a controlled environment. And see 
> the following: it wouldn't even be good enough.

You can make an operational recommendation of course.  However, some 
enterprises simply do not do subdomains (I email from one such enterprise now).

> 
>> get a cert for that address
> 
> Not from the necessary TA.
> 
>> , and masquerade as an AN or an AN could start sending email as a user that 
>> has such an address.
> 
> No.
> 
> See section 6.1.4
> 
> |  Certificates for an ACP MUST only be given to nodes that are allowed
> |  to be members of that ACP.  Because the signing CA relies on an ACP
> |  Registrar, the CA MUST only sign certificates with ACP domain
> |  information through trusted ACP Registrars.  Any existing CA, unaware
> |  of the new ACP domain information field, can be used as long as it
> |  only allows signing requests from trusted ACP Registrars and from
> |  nodes or registrars trusted not to include ACP domain information in
> |  their certificates.
> 

Ok, but...


> |  These requirements can be achieved by using TA private to the owner
> |  of the ACP domain or potentially through appropriate contractual
> |  agreements between the involved parties.  Public CA without such
> |  obligations and guarantees can not be used as TA for ACP domains, but
> |  they can be used to obtain certificates for TAs of ACP domain.
> 
> Aka: The ACP trust model is built on controlled access TA and 
> specific functionality registrar, it does not matter at all which
> field the information is encoded into for the trust model described.

If the TA is itself signed by a public CA, then the CA can sign other names or 
for that matter issue other signing certs , and (at least by normal use of PKI) 
the name will validate without the TA ever having been used.  Assuming that’s 
not what you mean, how does the client know which TA is authorized?


> 
>> Let???s agree that the latter is so minimal a risk as to not warrant further 
>> discussion.
> 
> Lets agree this would only happen by explicit violation of
> mandatory document requirements by a real misguided operator. And
> under those circumstances most RFCs would not be safe.
> 
>> It???s only the former that???s really of concern.  That can be mitigated 
>> through operational guidance, a???la ???don???t allow email addresses in 
>> your domain that begin with rfcSELF+???.
> 
> Actually right now my personal recommendation would be to allocate that
> email address (prefix) rfcSELF{+...}@.. to the ACP admin to see if there was 
> ever
> some unintended side effect such as email to that address
> that was generated by other software.

I like that idea.


> 
> Btw: ANIMA and ACME folks had a side meeting last year (i think you
> where there ?!), and of course one of the id

Re: [Anima] representing ACP info in X.509 certs

[Eliot Lear]

Hi there,

> On 24 Jun 2020, at 02:55, Michael Richardson  wrote:
> 
> Signed PGP part
> 
> Stephen Kent  wrote:
>> The simple answer is that when, in the past, developers have chosen to abuse
>> the semantics of subject name fields in certs, the result shave been VERY
>> long lasting, and embarrassing. Long ago, Netscape chose to shove a DNS name
>> into the DN common name filed because it was an easy fix for their
>> problem. As a result, we still have browsers and CAs that misuse that
>> field. At least that egregious behavior was not the result of an IETF
>> WG. Let's not screw this up in the name of expediency!
> 
> Yes, I remember that.
> Why do you think Netscape did that?
> What should they have done instead?
> 

Going further, sometimes expedients are appropriate.

With the benefit of hindsight of nearly 30 years of experience, there’s a lot 
that Netscape did in its first years that we wouldn’t do today, but had they 
not done those things, field delivery could have been delayed by years, 
probably the worst example being the User-Agent header.  We can say, “they 
never should have done that”, but it was what people deemed necessary and 
expedient for a number of reasons, not least of which was product 
differentiation and market maturity.

Here we have a situation where the public CA offerings have been made quite 
brittle. The ability to add either an otherName or a URI requires CAs to modify 
their code and create alternative roots.We all know that won’t happen, and 
so that leads to whether an expedient is appropriate.  Worse, as I have 
demonstrated, submitting otherName to public CAs produces garbage in certs 
(very bad, but there it is).  They not only aren’t ready, but they may have 
potential exploits lingering.

Is an expedient appropriate?

With ACP it’s clear they are overloading semantics of an rfc822name, and from 
an application standpoint we don’t like that because it is possible that 
different subsystems may have different uncoordinated allocation methods.  That 
is- someone may be able to nab an email address via the mail subsystem a la 
rfcself+fd89b714f3db02006400+area51.resea...@acp.example.com 
,
 get a cert for that address, and masquerade as an AN or an AN could start 
sending email as a user that has such an address.  Let’s agree that the latter 
is so minimal a risk as to not warrant further discussion.  It’s only the 
former that’s really of concern.  That can be mitigated through operational 
guidance, a’la “don’t allow email addresses in your domain that begin with 
rfcSELF+”.

It’s not perfect.  That’s the nature of an expedient.  But it’s probably Good 
Enough for now.  For the eventuality that another name could be used over time, 
it’s probably worth getting an OID and using otherName where possible, but we 
shouldn’t hold this work up over a highly theoretical attack.

Eliot


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

Re: [Anima] Moving forward with draft-ietf-anima-autonomic-control-plane

[Eliot Lear]

> On 23 Jun 2020, at 17:28, Eric Rescorla  wrote:
> 
> 
> 
> Oh it does the DV. It just adds garbage into the cert :-(
> 
> I'm talking about the second sentence, which requires that the SAN contain 
> only dNSName or IPAddress.


Regardless, the garbage that is left in was the point of my note.

Eliot

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

Re: [Anima] Moving forward with draft-ietf-anima-autonomic-control-plane

[Eliot Lear]

> On 23 Jun 2020, at 14:01, Eric Rescorla  wrote:
> 
> I don’t know if the group looked at this, but I can say that from a public CA 
> standpoint, it’s not much different from otherName because there is a 
> requirement to validate the name.  A new URI scheme would require a new 
> resolution mechanism.  Perhaps that is needed as part of ACP anyway.  The one 
> value of URI is that it is easier to configure in some of the tooling like 
> OpenSSL.
> 
> What disturbs me about all of this is that public CAs will accept otherNames 
> and produce garbage out.  That’s just asking for a boot to the head* from a 
> vulnerability perspective.
> 
> This would at present appear to violate the BRs. S 7.1.4.2.1 says:
> Contents: This extension MUST contain at least one entry. Each entry MUST be 
> either a dNSName containing the Fully-Qualified Domain Name or an iPAddress 
> containing the IP address of a server. The CA MUST confirm that the Applicant 
> controls the Fully-Qualified Domain Name or IP address or has been granted 
> the right to use it by the Domain Name Registrant or IP address assignee, as 
> appropriate. 
> 
> -Ekr
> 

Oh it does the DV. It just adds garbage into the cert :-(___
Anima mailing list
Anima@ietf.org
https://www.ietf.org/mailman/listinfo/anima

Re: [Anima] Moving forward with draft-ietf-anima-autonomic-control-plane

[Eliot Lear]

Hi Ben

> On 23 Jun 2020, at 05:31, Benjamin Kaduk  wrote:
> 
> Russ has been helping reach out to more of the PKIX community; one
> suggestion that came up so far is to consider defining a dedicated URI
> scheme and using a uniformResourceIdentifier SAN -- did the WG consider
> that in the initial discussions?


I don’t know if the group looked at this, but I can say that from a public CA 
standpoint, it’s not much different from otherName because there is a 
requirement to validate the name.  A new URI scheme would require a new 
resolution mechanism.  Perhaps that is needed as part of ACP anyway.  The one 
value of URI is that it is easier to configure in some of the tooling like 
OpenSSL.

What disturbs me about all of this is that public CAs will accept otherNames 
and produce garbage out.  That’s just asking for a boot to the head* from a 
vulnerability perspective.

Eliot

*https://www.youtube.com/watch?v=-V1Mn5-xF0w 

** (And one for Jenny and the whimp)

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

Re: [Anima] Adoption call for draft-fries-anima-brski-async-enroll-03, ends July 1st 2020

[Eliot Lear]

Hi Sheng

Thanks for initiating this call.  As one of the co-authors, it should surprise 
you not at all the I have read it, and indeed have modestly contributed to it 
(Steffen did the heavy lifting).  I support its adoption.

Eliot

> On 18 Jun 2020, at 11:27, Sheng Jiang  wrote:
> 
> Hi, ANIMAer,
>  
> This message starts a two-week adoption call, it ends on July 1st, 2020.
>  
> draft-fries-anima-brski-async-enroll-03 has been presented to the WG for a 
> long while and the WG showed good interest and had discussions. The draft is 
> now clearly in scope of ANIMA charter 2 that was adopted around IETF106. The 
> authors asked for adoption of the document. Giving the dependent BRSKI has 
> passed the IESG evaluation, the chairs feel that it may be the right time to 
> call the adoption.
>  
> We therefore are asking the ANIMA working group for adoption of the following 
> work:
>  
> Title:Support of asynchronous Enrollment in BRSKI
> Name: draft-fries-anima-brski-async-enroll-03
> Authors:  S. Fries, H. Brockhaus and E. Lear
> URL:  
> https://datatracker.ietf.org/doc/draft-fries-anima-brski-async-enroll/ 
> 
>  
> This document is intended to become a standards track ANIMA WG document.
>  
> Please express your support or rejection. If you think this document should 
> _not_ be adopted, please also explicitly indicate the reasons.
>  
> Regards,
>  
> Sheng
>  
> ___
> 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] rfc822Name use in Autonomic Control Plane document

[Eliot Lear]

Ok, so I just want to add that I have been able to populate otherName with 
garbage and have it get signed by a public CA.  My point is that at least some 
public CAs are loose.  If LE is important to this space, and if it’s really 
important, then this is not a solution.  Anyway, Here was the line that I used 
for my jabber server (it’s certainly not correct):

subjectAltName = 
DNS:www.ofcourseimright.com,DNS:upstairs.ofcourseimright.com,otherName:1.3..6.1.5.5.7.8.7;IA5:ofcourseimright.com,otherName:1.3.6.1.5.5.7.8.7;IA5:_xmpp-client._tcp.ofcourseimright.com,otherName:1.3.6.1.5.5.7.8.7;IA5:_xmpp-server._tcp.ofcourseimright.com,otherName:1.3.6.1.5.5.7.8.7;UTF8:ofcourseimright.com

And here’s what I got:

McNext> openssl x509 -noout -text -in jabber_ofcourseimright_com.crt 
Certificate:
Data:
Version: 3 (0x2)
Serial Number:
58:12:20:cd:47:fe:82:af:35:8d:75:50:75:05:a6:cb
Signature Algorithm: sha256WithRSAEncryption
Issuer: C=GB, ST=Greater Manchester, L=Salford, O=Sectigo Limited, 
CN=Sectigo RSA Domain Validation Secure Server CA
Validity
Not Before: Jun 18 00:00:00 2020 GMT
Not After : Jul 18 23:59:59 2020 GMT
Subject: CN=jabber.ofcourseimright.com
Subject Public Key Info:
Public Key Algorithm: rsaEncryption
Public-Key: (2048 bit)
Modulus:
00:9e:c8:c0:61:b6:5c:d1:fc:bf:2d:d2:13:6b:db:
97:09:45:e8:22:bf:89:24:7e:09:01:fe:91:37:85:
ee:25:77:54:92:68:05:07:d2:70:f5:6f:5c:fc:b4:
c6:7f:2d:e6:3e:11:68:4b:55:74:10:39:bc:1c:19:
3c:82:76:c1:76:ad:9b:6a:be:c3:be:35:dc:e5:5a:
48:95:2c:c9:9f:d7:68:c6:6f:83:b4:8d:c8:8a:0a:
b8:73:2e:10:c9:0e:a1:70:cb:a4:29:a0:b3:32:34:
72:69:9a:7d:20:35:9c:58:f1:a3:17:3f:fd:6f:22:
23:e5:58:24:65:56:38:51:6f:10:46:4b:77:fb:2d:
c9:5b:ca:db:8e:74:77:20:8b:b4:04:0a:63:75:03:
4c:be:19:9f:1f:9a:63:cd:9b:12:3e:b3:09:10:de:
d0:a1:d3:8b:bc:83:66:6a:4e:28:3c:5f:f7:ab:23:
a7:b6:da:46:59:21:eb:d7:ef:57:53:d8:72:be:55:
07:a5:95:c9:61:97:f7:39:c0:78:82:c0:1e:bd:53:
fc:ae:2c:6c:7a:c2:69:a0:c4:80:44:ac:b3:6b:f8:
01:fc:8f:ab:7e:8b:b8:24:0e:cd:7b:0e:74:94:77:
1c:4d:11:a2:d8:36:53:08:1a:d8:1b:fc:23:86:4c:
b3:f1
Exponent: 65537 (0x10001)
X509v3 extensions:
X509v3 Authority Key Identifier: 

keyid:8D:8C:5E:C4:54:AD:8A:E1:77:E9:9B:F9:9B:05:E1:B8:01:8D:61:E1

X509v3 Subject Key Identifier: 
65:8C:F2:D4:46:7C:FB:D1:5E:62:BC:8C:70:B6:99:D0:95:4B:EB:98
X509v3 Key Usage: critical
Digital Signature, Key Encipherment
X509v3 Basic Constraints: critical
CA:FALSE
X509v3 Extended Key Usage: 
TLS Web Server Authentication, TLS Web Client Authentication
X509v3 Certificate Policies: 
Policy: 1.3.6.1.4.1.6449.1.2.2.7
  CPS: https://sectigo.com/CPS
Policy: 2.23.140.1.2.1

Authority Information Access: 
CA Issuers - 
URI:http://crt.sectigo.com/SectigoRSADomainValidationSecureServerCA.crt
OCSP - URI:http://ocsp.sectigo.com

X509v3 Subject Alternative Name: 
DNS:jabber.ofcourseimright.com, 
DNS:www.jabber.ofcourseimright.com
1.3.6.1.4.1.11129.2.4.2: 

...v...\..}h.#W|W..j..a:.i..r.e...G0E.!...f...R...r.Sw.E%.}.J.i.M.
 
)!.0...L.e.fs.Z..w.7~.ba...{7.V..&[...K.ATn...r.e.:.H0F.!~...V.5F.h.\C.e.'57.{.!..
 8.I...8...U.Yf._.6..bb
Signature Algorithm: sha256WithRSAEncryption
 1c:0d:7b:38:be:c5:b5:58:8e:0e:d9:7d:c8:90:9d:ea:29:94:
 de:a7:a1:11:db:1e:b7:9c:f8:25:48:da:2d:87:2f:76:0b:f8:
 ba:2d:72:49:87:50:3e:e2:9b:2f:a4:ab:61:24:8c:6c:65:c1:
 91:16:c2:7e:50:27:50:93:a8:36:38:ad:66:c4:e4:66:ae:2f:
 21:40:8f:41:f7:53:51:61:80:59:a8:2a:56:9b:9b:e5:85:a4:
 8b:6e:31:0b:b8:ca:4d:82:af:2c:34:83:25:2b:fc:94:05:28:
 f6:04:f8:96:61:3c:21:9b:11:13:48:1d:c0:77:c0:df:d3:47:
 ff:6e:d3:6a:66:eb:16:40:d7:45:67:a0:25:1d:9f:fa:7f:85:
 20:34:08:70:b2:3b:d5:b4:15:77:9b:d5:c0:4e:08:99:ce:24:
 fb:6e:c3:4d:a9:fc:ff:25:d9:09:d0:cd:e1:8b:69:c1:bb:f0:
 40:0a:ad:1b:36:4f:ba:a0:aa:e9:f1:af:cd:73:5a:2a:0f:8a:
 0d:04:ca:52:85:10:eb:d9:fe:85:6c:a6:ae:a3:de:04:a7:9a:
 e0:8c:5d:40:b6:1f:f6:f2:b1:d9:dc:f2:f4:fd:a8:f5:b4:25:
 80:c0:ec:84:1f:bf:02:e6:3d:0c:ca:41:d5:61:d9:a3:a2:c8:
 a0:f2:46:3c


Eliot
> On 17 Jun 2020, at 04:44, Benjamin Kaduk  wrote:
> 
> Hi Brian, 

Re: [Anima] Benjamin Kaduk's Discuss on draft-ietf-anima-bootstrapping-keyinfra-28: (with DISCUSS and COMMENT)

[Eliot Lear]

> On 17 Jun 2020, at 18:10, Michael Richardson  wrote:
> 
>> 
>> Now that it is it represents a new convention.  The question at hand is
>> whether the information found on the LHS could be subject to
>> misinterpretation by non-participants.  I wonder if we could add an EKU
>> as a SHOULD to break the logjam.
> 
> Because EKUs are so much easier to get into CAs than otherName is?
> Seriously, how does that help at all?

I have definitely seen at least some CAs allow EKUs, such as XMPP, for 
instance, and was thinking of SHOULD rather than MUST.  But I do have to say 
that XMPP didn’t have a great experience with them, to be fair.

Eliot


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

Re: [Anima] Benjamin Kaduk's Discuss on draft-ietf-anima-bootstrapping-keyinfra-28: (with DISCUSS and COMMENT)

[Eliot Lear]

Hi,

Could we recap a bit on this?  I have commented on the use of the rfc822Name 
myself, and was a bit concerned about misuse and misinterpretation prior to 
rfcSELF being present.

Now that it is it represents a new convention.  The question at hand is whether 
the information found on the LHS could be subject to misinterpretation by 
non-participants.  I wonder if we could add an EKU as a SHOULD to break the 
logjam.

Eliot


> On 1 Nov 2019, at 21:14, Michael Richardson  wrote:
> 
> Signed PGP part
> 
> Benjamin Kaduk  wrote:
>doc> although it results in additional network traffic.  The relying MASA
>doc> implementation MAY leverage internal state to associate this request
>doc> with the original, and by now already validated, voucher-request so
>doc> as to avoid an extra crypto validation.
>>> 
 It seems that doing so would turn the voucher-request into a bearer
 token for retrieving audit-log information (if the MASA accepts
 unauthenticated clients).
>>> 
>>> That's what's intended.
> 
>> I can see why that functionality is needed, but it seems likely to
>> introduce some privacy and/or security considerations to document.  It's a
>> bit too late in the day for me to reason through them, though.
> 
> To be clear: any registrar which has ever formed a valid voucher-request MAY
> retrieve the audit-log at regular intervals to verify the status of the
> device.  The words, "now already validated" means that the MASA agreed with
> the voucher-request.  Most implementations are going to log the
> voucher-request as part of the internal audit log, so a memcmp() on that is 
> enough.
> 
> This would reveal new owners.  Whether the new owner is legitimate or not is
> not something we can answer: it might be that the device has been stolen, or
> maybe it's legitimately lent, rented, sold, etc.
> 
 Section 11
>>> 
 I am somewhat embarassed that I did not previously note that the
 mechanism used to generate the domainID needs to be
 second-preimage-resistant or an attacker can claim to be a registrar for
 a domain that already exists.
>>> 
>>> Right now, that's in:
>>> 
>>> 5.8.2.  Calculation of domainID
>>> 
>>> The domainID is a binary value (a BIT STRING) that uniquely
>>> identifies a Registrar by the "pinned-domain-cert"
>>> 
>>> If the "pinned-domain-cert" certificate includes the
>>> SubjectKeyIdentifier (Section 4.2.1.2 [RFC5280]), then it is to be
>>> used as the domainID.  If not, the SPKI Fingerprint as described in
>>> [RFC7469] section 2.4 is to be used.  This value needs to be
>>> calculated by both MASA (to populate the audit-log), and by the
>>> Registrar (to recognize itself).
>>> 
>>> We tried hard and found a way not to say SHA-1 directly, allowing SHA256 to
>>> replace it appropriately.
> 
>> That's all good and admirable; I'm suggesting that we add a note in the
>> security considerations of this document noting that we rely on the
>> domainID (however determined) to be second-preimage-resistant.
> 
> I've added this to the security considerations as 11.2.
> 
>doc> Although the nonce used by the Pledge in the voucher-request does not
>doc> require a strong cryptographic randomness, the use of TLS in all of
>doc> the protocols in this document does.
>>> 
 We discuss the need for strong randomness in the nonce in Section 11.3,
 so it's not clear this is actually true.
>>> 
>>> We don't think that the voucher nonce has to be of the same quality as 
>>> something that
>>> goes into a KDF.  It is at the level of TCP Sequeunce number, not seed for
>>> generating a private key...
> 
>> I mean, we literally say "Reducing the possibility of this is why the
>> pledge is mandated to generate a strong random or pseudo-random number
>> nonce."  So to also say "the nonce [...] does not require a strong
>> cryptographic randomness" seems to be in conflict with the former
>> statement.
>> Are you saying that "strong random" and "strong cryptographic random" mean
>> different things, or am I misreading the document in some other way?
> 
> I take your point, and I guess we were splitting hairs.
> I'll just rephrase it to remove the Although statement.
> 
> --
> ]   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: Message signed with OpenPGP
___
Anima mailing list
Anima@ietf.org
https://www.ietf.org/mailman/listinfo/anima

[Anima] BRSKI-AE

[Eliot Lear]

Chairs:

The authors of draft-fries-anima-brski-async-enroll-03 have been patiently 
awaiting follow-up from the previous meeting of this working group in which we 
came away assuming that there would be a call for adoption.  When might we 
expect that?

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

Re: [Anima] draft-ietf-anima-bootstrapping-keyinfra

[Eliot Lear]

Hi,

IMHO:

> On 14 Apr 2020, at 12:03, tom petch  wrote:
> 
> The IESG approval of this I-D caused me to look again at it:-(
> 
> I note that part of the formal specification is in CDDL and while other DDL - 
> ASN.1, SMI, YANG - are bracketed with CODE BEGINS CODE ENDS - the CDDL  is 
> not. I suspect that it should be - perhaps a note to the RFC Editor is called 
> for.

Yes.

> 
> In the Security Considerations I encounter MTIM which I suspect should be 
> MITM (and which needs expanding on first use in s.5).
> 

Editorial.

> In the YANG module, I see two references in square brackets which suggests 
> that they are in XML/HTML and not plain text whereas there is a requirement 
> for YANG modules to be in plain text so that they can be extracted from the 
> RFC.

Editorial.

Thanks for looking!

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

Re: [Anima] Benjamin Kaduk's Discuss on draft-ietf-anima-bootstrapping-keyinfra-39: (with DISCUSS and COMMENT)

[Eliot Lear]

Hi Ben,

> On 31 Mar 2020, at 21:29, Benjamin Kaduk  wrote:
> 
> On Tue, Mar 31, 2020 at 08:02:07AM -0700, Benjamin Kaduk wrote:
>> 
>> I am even willing to produce an updated example voucher artifact myself, if
>> that would help expedite things -- I believe I already have the needed
>> keys/certs locally from my review of the -39.  As an alternate option, if
> 
> I think I managed to do this (though I didn't adjust my clock to try to
> reproduce the signing time); attached.

Righto.  Now the point of discussion is whether that is the right thing to do.  
If it is, then the example can change to that.  If it isn’t then the text you 
pointed to has to change.

Eliot

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

Re: [Anima] [Iot-onboarding] EST CACerts and Pinned Domain Certificate

[Eliot Lear]

Hi Esko

> On 24 Mar 2020, at 14:08, Esko Dijk  wrote:
> 
> Hello Michael,
> 
> Looking at text in 5.6.2 of BRSKI:
> 
>   The 'pinned-domain-cert' is not a
>   complete distribution of the [RFC7030] section 4.1.3 CA Certificate
>   Response, which is an additional justification for the recommendation
>   to proceed with EST key management operations.  Once a full CA
>   Certificate Response is obtained it is more authoritative for the
>   domain than the limited 'pinned-domain-cert' response.
> 
> Which basically says that the Domain CA cert (that is present as 
> 'pinned-domain-cert') is a sort of partial response to the CA Certificates 
> Response of EST.

The primary purpose of the pinned-domain-cert is to validate the previously 
established TLS connection.  

> So, the Domain CA cert must be included in the full CA Certificate Response.
> Suppose the full response does not contain Domain CA cert. If the Pledge 
> receives the full response and - as stated in above text - replaces the 
> limited response (with Domain CA) with the more authoritative full response 
> (without Domain CA cert) then it would have to discard its Domain CA cert! 
> That's not wanted in this case. So from this I would conclude that Domain CA 
> cert needs to be in the (full) CA Certificates Response of EST.

But this to me seems like a misconfiguration, because RFC 7030 states in 
Section 4.1.3:

   The EST server MUST include the current root CA certificate in the
   response.


> 
> Another angle to consider is the following: by design, the pinned-domain-cert 
> is in BRSKI a Domain CA cert (i.e. it must be a CA). Why would any CA 
> certificate not be included in the list of CA certificates, that is given by 
> the CA Certificates Response? 

Why, indeed!

> 
> Third, in Section 5.9.1.:
> 
>   The pledge SHOULD request the full EST Distribution of CA Certificates 
> message.  See RFC7030, section 4.1.
>   This ensures that the pledge has the complete set of current CA
>   certificates beyond the pinned-domain-cert
> 
> This suggests that pinned-domain-cert is part of the complete set of current 
> CA certificates. 

Right.

> 
> RFC 7030 is not fully clear to me regarding our question - there are 
> requirements on what should be included in the message; let's assume that the 
> EST server certificate is a subordinate CA; then the RFC states in 4.1.3:
> 
>   if the EST CA is
>   a subordinate CA, then all the appropriate subordinate CA
>   certificates necessary to build a chain to the root EST CA are
>   included in the response.
> 
> It is unclear if the EST CA's own certificate must be included or not in 
> order to build the chain. In other words if the chain is X (subordinate CA) 
> -> Y (subordinate CA) -> Z (root CA) then does it include only Y / Z or all 
> of X / Y / Z ?

I agree that there is some ambiguity here, but because this amounts to a 
privileged operation on the device, and we are not using X to validate the 
current connection during the EST part of the transaction, it is safe to 
include it.  It’s all a matter of what happens next.  Now you have X in your 
store, chained to Y and Z, both also in your store.  TLS and DTLS should not 
blow up because the intermediate certificate is present in the store, even if 
it is presented in the HELLO.  The question is what happens if X and Y are not 
present in a normal HELLO.  TLS 1.3 says that’s ok.  But I’m not convinced 
that’s a good idea.


> 
> Still, overall it would be strange to exclude Domain CA, as it is part of the 
> full set of CA certificates, and because the "full response" would replace 
> the single pinned Domain CA cert as indicated in BRSKI. 

But see above.

Eliot

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

Re: [Anima] Benjamin Kaduk's Discuss on draft-ietf-anima-bootstrapping-keyinfra-28: (with DISCUSS and COMMENT)

[Eliot Lear]

Hi,

> On 29 Oct 2019, at 04:18, Benjamin Kaduk  wrote:
> 
> I mean, we literally say "Reducing the possibility of this is why the
> pledge is mandated to generate a strong random or pseudo-random number
> nonce."  So to also say "the nonce [...] does not require a strong
> cryptographic randomness" seems to be in conflict with the former
> statement.
> Are you saying that "strong random" and "strong cryptographic random" mean
> different things, or am I misreading the document in some other way?


I would just drop the statement.  The whole point of the nonce is to prevent 
replay attacks, so why would we want to weaken that?

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]

> 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

[Anima] Fwd: Your Webex recording is available for viewing: IoT Onboarding Meeting-20190829 1513-1

[Eliot Lear]

Hi everyone, and thanks for joining.  Those people who wish to listen to the 
recording (it started a bit after the meeting), please see attached.  I’ll 
summarize the meeting in a separate email.

Eliot

> Begin forwarded message:
> 
> From: 
> Subject: Your Webex recording is available for viewing: IoT Onboarding 
> Meeting-20190829 1513-1
> Date: 29 August 2019 at 18:30:59 CEST
> To: 
> Reply-To: 
> 
> Hi Eliot Lear,
> Your recording is now available on your Webex site.
> 
> IoT Onboarding Meeting-20190829 1513-1
> Thursday, August 29, 2019
> 5:13 pm  |  Europe Summer Time (Amsterdam, GMT+02:00)
> 
> Play recording 
> <https://cisco.webex.com/cisco/lsr.php?RCID=f2d673ea374540a5b9daee8b83167150> 
> (47 min 54 sec)
> Recording password: fRJsavS4
> 
> You can forward this message to others to allow them to play back the 
> recording.
> 



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

[Anima] IoT Onboarding Virtual Meeting

[Eliot Lear (elear)]

BEGIN:VCALENDAR
METHOD:REQUEST
PRODID:Microsoft Exchange Server 2010
VERSION:2.0
BEGIN:VTIMEZONE
TZID:W. Europe Standard Time
BEGIN:STANDARD
DTSTART:16010101T03
TZOFFSETFROM:+0200
TZOFFSETTO:+0100
RRULE:FREQ=YEARLY;INTERVAL=1;BYDAY=-1SU;BYMONTH=10
END:STANDARD
BEGIN:DAYLIGHT
DTSTART:16010101T02
TZOFFSETFROM:+0100
TZOFFSETTO:+0200
RRULE:FREQ=YEARLY;INTERVAL=1;BYDAY=-1SU;BYMONTH=3
END:DAYLIGHT
END:VTIMEZONE
BEGIN:VEVENT
ORGANIZER;CN=Eliot Lear (elear):MAILTO:el...@cisco.com
ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN=iot-onboar
 d...@ietf.org:MAILTO:iot-onboard...@ietf.org
ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN=Parisa Gra
 yeli:MAILTO:pgray...@mitre.org
ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN=anima@ietf
 .org:MAILTO:anima@ietf.org
ATTENDEE;ROLE=OPT-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN=Pascal Thu
 bert (pthubert):MAILTO:pthub...@cisco.com
ATTENDEE;ROLE=OPT-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN=Gonzalo Sa
 lgueiro (gsalguei):MAILTO:gsalg...@cisco.com
ATTENDEE;ROLE=OPT-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN=nate@cypie
 nt.com:MAILTO:n...@cypient.com
ATTENDEE;ROLE=OPT-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN=Nancy Cam-
 Winget (ncamwing):MAILTO:ncamw...@cisco.com
ATTENDEE;ROLE=OPT-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN=Thomas Fos
 sati:MAILTO:thomas.foss...@arm.com
ATTENDEE;ROLE=OPT-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN="Fries, Ste
 ffen":MAILTO:steffen.fr...@siemens.com
ATTENDEE;ROLE=OPT-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN=Eric Wenge
 r (erwenger):MAILTO:erwen...@cisco.com
ATTENDEE;ROLE=OPT-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN=scottj@goo
 gle.com:MAILTO:sco...@google.com
ATTENDEE;ROLE=OPT-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN=Jack Visok
 y:MAILTO:jmvis...@ra.rockwell.com
ATTENDEE;ROLE=OPT-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN=Max Pritik
 in (pritikin):MAILTO:priti...@cisco.com
ATTENDEE;ROLE=OPT-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN=Pierre-Ant
 oine Vervier:MAILTO:pierre-antoine_verv...@symantec.com
ATTENDEE;ROLE=OPT-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN=Timothy Jo
 nes:MAILTO:tim.jo...@forescout.com
ATTENDEE;ROLE=OPT-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN=mranga@gma
 il.com:MAILTO:mra...@gmail.com
ATTENDEE;ROLE=OPT-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN=montemurro
 .mich...@gmail.com:MAILTO:montemurro.mich...@gmail.com
ATTENDEE;ROLE=OPT-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN=Michael Ba
 rtling:MAILTO:michael.bartl...@arm.com
ATTENDEE;ROLE=OPT-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN=Jo Wlotzka
 :MAILTO:j...@patton.com
ATTENDEE;ROLE=OPT-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN=Petros Efs
 tathopoulos:MAILTO:petros_efstathopou...@symantec.com
ATTENDEE;ROLE=OPT-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN=pdemestich
 a...@gmail.com:MAILTO:pdemestic...@gmail.com
ATTENDEE;ROLE=OPT-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN=Paul Duffy
  (paduffy):MAILTO:padu...@cisco.com
ATTENDEE;ROLE=OPT-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN="Barker, Wi
 lliam C. (Assoc)":MAILTO:william.bar...@nist.gov
ATTENDEE;ROLE=OPT-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN=Susanta Na
 nda:MAILTO:susanta_na...@symantec.com
ATTENDEE;ROLE=OPT-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN="Symington,
  Susan F.":MAILTO:su...@mitre.org
ATTENDEE;ROLE=OPT-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN=Nagendra K
 umar Nainar (naikumar):MAILTO:naiku...@cisco.com
ATTENDEE;ROLE=OPT-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN="Watrobski,
  Paul (Ctr)":MAILTO:paul.watrob...@nist.gov
ATTENDEE;ROLE=OPT-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN=Randy Arms
 trong (OPC):MAILTO:randy.armstr...@opcfoundation.org
ATTENDEE;ROLE=OPT-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN="Werner, Th
 omas":MAILTO:thomas-wer...@siemens.com
ATTENDEE;ROLE=OPT-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN="Cappalli, 
 Tim (Aruba Security)":MAILTO:t...@hpe.com
ATTENDEE;ROLE=OPT-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN=Erik Nordm
 ark:MAILTO:e...@zededa.com
ATTENDEE;ROLE=OPT-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN=Schellenba
 um Aurelio Ruben Dario (scnm):MAILTO:s...@zhaw.ch
ATTENDEE;ROLE=OPT-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN=abaykal@gl
 obalcyberalliance.org:MAILTO:abay...@globalcyberalliance.org
ATTENDEE;ROLE=OPT-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN="Montgomery
 , Douglas (Fed)":MAILTO:do...@nist.gov
ATTENDEE;ROLE=OPT-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN=Pete Beal 
 (pbeal):MAILTO:pb...@cisco.com
ATTENDEE;ROLE=OPT-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN=Allaukik A
 bhishek:MAILTO:allaukik.abhis...@arm.com
ATTENDEE;ROLE=OPT-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN=Peter Romn
 ess (promness):MAILTO:promn...@cisco.com
ATTENDEE;ROLE=OPT-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN=cabocabo@g
 mail.com:

[Anima] IoT Onboarding Virtual Meeting

[Eliot Lear (elear)]

BEGIN:VCALENDAR
METHOD:REQUEST
PRODID:Microsoft Exchange Server 2010
VERSION:2.0
BEGIN:VTIMEZONE
TZID:W. Europe Standard Time
BEGIN:STANDARD
DTSTART:16010101T03
TZOFFSETFROM:+0200
TZOFFSETTO:+0100
RRULE:FREQ=YEARLY;INTERVAL=1;BYDAY=-1SU;BYMONTH=10
END:STANDARD
BEGIN:DAYLIGHT
DTSTART:16010101T02
TZOFFSETFROM:+0100
TZOFFSETTO:+0200
RRULE:FREQ=YEARLY;INTERVAL=1;BYDAY=-1SU;BYMONTH=3
END:DAYLIGHT
END:VTIMEZONE
BEGIN:VEVENT
ORGANIZER;CN=Eliot Lear (elear):MAILTO:el...@cisco.com
ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN=iot-onboar
 d...@ietf.org:MAILTO:iot-onboard...@ietf.org
ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN=anima@ietf
 .org:MAILTO:anima@ietf.org
ATTENDEE;ROLE=OPT-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN=Randy Arms
 trong (OPC):MAILTO:randy.armstr...@opcfoundation.org
ATTENDEE;ROLE=OPT-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN=pdemestich
 a...@gmail.com:MAILTO:pdemestic...@gmail.com
ATTENDEE;ROLE=OPT-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN=Nancy Cam-
 Winget (ncamwing):MAILTO:ncamw...@cisco.com
ATTENDEE;ROLE=OPT-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN="Cappalli, 
 Tim (Aruba Security)":MAILTO:t...@hpe.com
ATTENDEE;ROLE=OPT-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN="Werner, Th
 omas":MAILTO:thomas-wer...@siemens.com
ATTENDEE;ROLE=OPT-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN=Gonzalo Sa
 lgueiro (gsalguei):MAILTO:gsalg...@cisco.com
ATTENDEE;ROLE=OPT-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN=Pete Beal 
 (pbeal):MAILTO:pb...@cisco.com
ATTENDEE;ROLE=OPT-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN=cabocabo@g
 mail.com:MAILTO:caboc...@gmail.com
ATTENDEE;ROLE=OPT-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN=Jack Visok
 y:MAILTO:jmvis...@ra.rockwell.com
ATTENDEE;ROLE=OPT-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN=Erik Nordm
 ark:MAILTO:e...@zededa.com
ATTENDEE;ROLE=OPT-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN="Fries, Ste
 ffen":MAILTO:steffen.fr...@siemens.com
ATTENDEE;ROLE=OPT-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN="Bal, Kallo
 la":MAILTO:k@osram.com
ATTENDEE;ROLE=OPT-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN=Max Pritik
 in (pritikin):MAILTO:priti...@cisco.com
ATTENDEE;ROLE=OPT-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN=Pascal Thu
 bert (pthubert):MAILTO:pthub...@cisco.com
ATTENDEE;ROLE=OPT-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN=Schellenba
 um Aurelio Ruben Dario (scnm):MAILTO:s...@zhaw.ch
ATTENDEE;ROLE=OPT-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN=mranga@gma
 il.com:MAILTO:mra...@gmail.com
ATTENDEE;ROLE=OPT-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN=Nagendra K
 umar Nainar (naikumar):MAILTO:naiku...@cisco.com
DESCRIPTION;LANGUAGE=en-US:Please hold this time for the onboarding discuss
 ion (I'm on vacation and am sending this a bit early).  This is an IoT Onb
 oarding virtual meeting.\n\nTentative Agenda:\n\n - OPC UA use case\n - up
 dates on drafts\n - AOB\n\n\n\n\nMeeting Information\n\nMeeting link:\n   
  https://cisco.webex.com/cisco/j.php?MTID=m16f8e0d12f6d12c3c37984c73f20efb
 8\nMeeting number:\n207 046 128\nPassword:\nc3wvus3x (23988739 fro
 m phones)\nHost key:\n735404 \n\nMore ways to join\n\nJoin by video sy
 stem\nDial 207046...@cisco.webex.com\nYou can also dial 173.243.2.
 68 and enter your meeting number.\n\nJoin by phone\n+1-866-432-9903 Ca
 ll-in toll-free number (US/Canada)\n+1-408-525-6800 Call-in number (US
 /Canada)\nAccess code: 207 046 128\n\nGlobal call-in numbers | Tol
 l-free calling restrictions 
UID:FC26613C-9096-4D04-9B80-6BA877A27A2A
SUMMARY;LANGUAGE=en-US:IoT Onboarding Virtual Meeting
DTSTART;TZID=W. Europe Standard Time:20190829T17
DTEND;TZID=W. Europe Standard Time:20190829T18
CLASS:PUBLIC
PRIORITY:5
DTSTAMP:20190827T135808Z
TRANSP:OPAQUE
STATUS:CONFIRMED
SEQUENCE:1
LOCATION;LANGUAGE=en-US:WebEx: see below
X-MICROSOFT-CDO-APPT-SEQUENCE:1
X-MICROSOFT-CDO-OWNERAPPTID:2117616483
X-MICROSOFT-CDO-BUSYSTATUS:TENTATIVE
X-MICROSOFT-CDO-INTENDEDSTATUS:BUSY
X-MICROSOFT-CDO-ALLDAYEVENT:FALSE
X-MICROSOFT-CDO-IMPORTANCE:1
X-MICROSOFT-CDO-INSTTYPE:0
X-MICROSOFT-DONOTFORWARDMEETING:FALSE
X-MICROSOFT-DISALLOW-COUNTER:FALSE
X-MICROSOFT-LOCATIONDISPLAYNAME:WebEx: see below
X-MICROSOFT-LOCATIONSOURCE:None
X-MICROSOFT-LOCATIONS:[{"DisplayName":"WebEx: see below"\,"LocationAnnotati
 on":""\,"LocationUri":""\,"LocationStreet":""\,"LocationCity":""\,"Locatio
 nState":""\,"LocationCountry":""\,"LocationPostalCode":""\,"LocationFullAd
 dress":""}]
END:VEVENT
END:VCALENDAR
___
Anima mailing list
Anima@ietf.org
https://www.ietf.org/mailman/listinfo/anima

[Anima] Hold for IoT Onboarding Virtual Meeting

[Eliot Lear (elear)]

BEGIN:VCALENDAR
METHOD:REQUEST
PRODID:Microsoft Exchange Server 2010
VERSION:2.0
BEGIN:VTIMEZONE
TZID:W. Europe Standard Time
BEGIN:STANDARD
DTSTART:16010101T03
TZOFFSETFROM:+0200
TZOFFSETTO:+0100
RRULE:FREQ=YEARLY;INTERVAL=1;BYDAY=-1SU;BYMONTH=10
END:STANDARD
BEGIN:DAYLIGHT
DTSTART:16010101T02
TZOFFSETFROM:+0100
TZOFFSETTO:+0200
RRULE:FREQ=YEARLY;INTERVAL=1;BYDAY=-1SU;BYMONTH=3
END:DAYLIGHT
END:VTIMEZONE
BEGIN:VEVENT
ORGANIZER;CN=Eliot Lear (elear):MAILTO:el...@cisco.com
ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN=iot-onboar
 d...@ietf.org:MAILTO:iot-onboard...@ietf.org
ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN=anima@ietf
 .org:MAILTO:anima@ietf.org
DESCRIPTION;LANGUAGE=en-US:Please hold this time for the onboarding discuss
 ion (I'm on vacation and am sending this a bit early).  This is an IoT Onb
 oarding virtual meeting.\n\nTentative Agenda:\n\n - OPC UA use case\n - up
 dates on drafts\n - AOB\n\n\n\n\nMeeting Information\n\nMeeting link:\n   
  https://cisco.webex.com/cisco/j.php?MTID=m16f8e0d12f6d12c3c37984c73f20efb
 8\nMeeting number:\n207 046 128\nPassword:\nc3wvus3x (23988739 fro
 m phones)\nHost key:\n735404 \n\nMore ways to join\n\nJoin by video sy
 stem\nDial 207046...@cisco.webex.com\nYou can also dial 173.243.2.
 68 and enter your meeting number.\n\nJoin by phone\n+1-866-432-9903 Ca
 ll-in toll-free number (US/Canada)\n+1-408-525-6800 Call-in number (US
 /Canada)\nAccess code: 207 046 128\n\nGlobal call-in numbers | Tol
 l-free calling restrictions 
UID:FC26613C-9096-4D04-9B80-6BA877A27A2A
SUMMARY;LANGUAGE=en-US:Hold for IoT Onboarding Virtual Meeting
DTSTART;TZID=W. Europe Standard Time:20190829T17
DTEND;TZID=W. Europe Standard Time:20190829T18
CLASS:PUBLIC
PRIORITY:5
DTSTAMP:20190808T043130Z
TRANSP:OPAQUE
STATUS:CONFIRMED
SEQUENCE:0
X-MICROSOFT-CDO-APPT-SEQUENCE:0
X-MICROSOFT-CDO-OWNERAPPTID:2117616483
X-MICROSOFT-CDO-BUSYSTATUS:TENTATIVE
X-MICROSOFT-CDO-INTENDEDSTATUS:BUSY
X-MICROSOFT-CDO-ALLDAYEVENT:FALSE
X-MICROSOFT-CDO-IMPORTANCE:1
X-MICROSOFT-CDO-INSTTYPE:0
X-MICROSOFT-DONOTFORWARDMEETING:FALSE
X-MICROSOFT-DISALLOW-COUNTER:FALSE
END:VEVENT
END:VCALENDAR
___
Anima mailing list
Anima@ietf.org
https://www.ietf.org/mailman/listinfo/anima

[Anima] Doodle poll for IoT Onboarding Meeting

[Eliot Lear]

Hi everyone,

Please if you could, respond to the doodle poll below by the 12th.  While I 
will be on holiday next week, I’ll be sure to send along the meeting details 
for the meeting once the poll has closed.

Proposed Agenda:
OPC use case
BRSKI IESG review status
Other draft status

https://doodle.com/poll/9htegcxviwcg2hq2

Thanks,

Eliot


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

Re: [Anima] [Iot-onboarding] OPC and BRSKI

[Eliot Lear]

Randy,

Thanks.  I will be away on holiday for the next week.  However, before I go I 
will kick off a doodle for the week of the 19th for on onboarding meeting to 
discuss this.  Please everyone indicate your interest in participating by 
answering the doodle poll.

Eliot

> On 7 Aug 2019, at 10:57, Randy Armstrong (OPC) 
>  wrote:
> 
> HI Eliot,
> 
> Yes, the Operator needs to ensure that only Devices they authorize can 
> connect and the zero touch provisioning is a feature we desire.
> 
> Regards,
> 
> Randy
> 
> From: Eliot Lear 
> Sent: August 7, 2019 1:50 AM
> To: Randy Armstrong (OPC) 
> Cc: Toerless Eckert ; iot-onboard...@ietf.org; anima@ietf.org
> Subject: Re: [Iot-onboarding] OPC and BRSKI
> 
> Hi Randy,
> 
> Thanks again for your comments.  Please see below.
> 
> 
> On 7 Aug 2019, at 10:32, Randy Armstrong (OPC) 
>  <mailto:randy.armstr...@opcfoundation.org>> wrote:
> 
> Hi Eliot,
> 
> 1) In an OPC UA environment, might one expect that the join registrar and the 
> certificate manager be co-resident?
> 
> Yes that is the expectation.
> 
> 2) My bigger question is whether you want to use all of this for network 
> authentication to avoid unauthorized devices joining the network in the first 
> place, or whether this is intended solely for application authentication.
> 
> Counterfeit devices are huge issue in industrial automation. We need this 
> infrastructure so the Operators can assure themselves that the Devices they 
> plug into their network are genuine.
> 
> OTOH, Operators don’t need to prove their right to use a Device. If an 
> Operator has a Device they are entitled to use it (i.e. Devices can be 
> sold/transferred without approval from the manufacturer).
> 
> 
> The purpose, as I see it, of the voucher, is simply to provide zero-touch 
> network provisioning.  I was asking a slightly different question: for 
> purposes of network connectivity will operators want to know that only 
> devicesthey authorized are connecting (e.g., 802.1X and then like)?  This is 
> a natural assumption in the wireless world, but less so in wired.
> 
> Eliot
> 
> 
> 
> Regards,
> 
> Randy
> 
> 
> From: Eliot Lear mailto:l...@cisco.com>>
> Sent: August 7, 2019 12:33 AM
> To: Randy Armstrong (OPC)  <mailto:randy.armstr...@opcfoundation.org>>
> Cc: Toerless Eckert mailto:t...@cs.fau.de>>; 
> iot-onboard...@ietf.org <mailto:iot-onboard...@ietf.org>; anima@ietf.org 
> <mailto:anima@ietf.org>
> Subject: Re: [Iot-onboarding] OPC and BRSKI
> 
> Randy,
> 
> Thanks.  We have irregular calls, but I will poll for one in the 3rd week of 
> August to discuss your use case.
> 
> In an OPC UA environment, might one expect that the join registrar and the 
> certificate manager be co-resident?  This would be where EST/SCEP would 
> happen (BRSKI can be viewed as an extension to EST - RFC 7030).  There is no 
> "push mode" for EST.  However, my understanding is that the same capability 
> roughly speaking resides in CIP.
> 
> My bigger question is whether you want to use all of this for network 
> authentication to avoid unauthorized devices joining the network in the first 
> place, or whether this is intended solely for application authentication.
> 
> Eliot
> 
> 
> 
> 
> On 7 Aug 2019, at 01:19, Randy Armstrong (OPC) 
>  <mailto:randy.armstr...@opcfoundation.org>> wrote:
> 
> Push should be “Certificate Manager initiated”
> 
> From: Iot-onboarding  <mailto:iot-onboarding-boun...@ietf.org>> On Behalf Of Randy Armstrong (OPC)
> Sent: August 6, 2019 4:17 PM
> To: Toerless Eckert mailto:t...@cs.fau.de>>
> Cc: iot-onboard...@ietf.org <mailto:iot-onboard...@ietf.org>; anima@ietf.org 
> <mailto:anima@ietf.org>; Eliot Lear mailto:l...@cisco.com>>
> Subject: Re: [Iot-onboarding] OPC and BRSKI
> 
> Hi
> 
> 1) Sure, need to understand how TCP UA works wih the minimum amount of 
> message authentication to allow for BRSKI. Main challenge may be the need for 
> pledges to receive messages from registrar that are authenticated by the 
> registar, but where the pledge has to wait until it can actually perform the 
> authentication later. Depending on how you built TCP UA message layer 
> authentication this may be piece of cake / free or not.
> 
> It would be easy to drop in a OPC UA aware registrar and implement all of the 
> BRKSI flows back to the MASA. The only nuisance factor is the 
> 'prior-signed-voucher-request'.. If MASA's are willing allow this field to be 
> omitted and to trust the Registrar then nothing more needs to done. If MASA's 
> need this field then we could get it f

Re: [Anima] [Iot-onboarding] OPC and BRSKI

[Eliot Lear]

Hi Randy,

Thanks again for your comments.  Please see below.

> On 7 Aug 2019, at 10:32, Randy Armstrong (OPC) 
>  wrote:
> 
> Hi Eliot,
> 
> 1) In an OPC UA environment, might one expect that the join registrar and the 
> certificate manager be co-resident?
> 
> Yes that is the expectation.
> 
> 2) My bigger question is whether you want to use all of this for network 
> authentication to avoid unauthorized devices joining the network in the first 
> place, or whether this is intended solely for application authentication.
> 
> Counterfeit devices are huge issue in industrial automation. We need this 
> infrastructure so the Operators can assure themselves that the Devices they 
> plug into their network are genuine.
> 
> OTOH, Operators don’t need to prove their right to use a Device. If an 
> Operator has a Device they are entitled to use it (i.e. Devices can be 
> sold/transferred without approval from the manufacturer).


The purpose, as I see it, of the voucher, is simply to provide zero-touch 
network provisioning.  I was asking a slightly different question: for purposes 
of network connectivity will operators want to know that only devices they 
authorized are connecting (e.g., 802.1X and then like)?  This is a natural 
assumption in the wireless world, but less so in wired.

Eliot

> 
> Regards,
> 
> Randy
> 
> 
> From: Eliot Lear 
> Sent: August 7, 2019 12:33 AM
> To: Randy Armstrong (OPC) 
> Cc: Toerless Eckert ; iot-onboard...@ietf.org; anima@ietf.org
> Subject: Re: [Iot-onboarding] OPC and BRSKI
> 
> Randy,
> 
> Thanks.  We have irregular calls, but I will poll for one in the 3rd week of 
> August to discuss your use case.
> 
> In an OPC UA environment, might one expect that the join registrar and the 
> certificate manager be co-resident?  This would be where EST/SCEP would 
> happen (BRSKI can be viewed as an extension to EST - RFC 7030).  There is no 
> "push mode" for EST.  However, my understanding is that the same capability 
> roughly speaking resides in CIP.
> 
> My bigger question is whether you want to use all of this for network 
> authentication to avoid unauthorized devices joining the network in the first 
> place, or whether this is intended solely for application authentication.
> 
> Eliot
> 
> 
> 
> On 7 Aug 2019, at 01:19, Randy Armstrong (OPC) 
>  <mailto:randy.armstr...@opcfoundation.org>> wrote:
> 
> Push should be “Certificate Manager initiated”
> 
> From: Iot-onboarding  <mailto:iot-onboarding-boun...@ietf.org>> On Behalf Of Randy Armstrong (OPC)
> Sent: August 6, 2019 4:17 PM
> To: Toerless Eckert mailto:t...@cs.fau.de>>
> Cc: iot-onboard...@ietf.org <mailto:iot-onboard...@ietf.org>; anima@ietf.org 
> <mailto:anima@ietf.org>; Eliot Lear mailto:l...@cisco.com>>
> Subject: Re: [Iot-onboarding] OPC and BRSKI
> 
> Hi
> 
> 1) Sure, need to understand how TCP UA works wih the minimum amount of 
> message authentication to allow for BRSKI. Main challenge may be the need for 
> pledges to receive messages from registrar that are authenticated by the 
> registar, but where the pledge has to wait until it can actually perform the 
> authentication later. Depending on how you built TCP UA message layer 
> authentication this may be piece of cake / free or not.
> 
> It would be easy to drop in a OPC UA aware registrar and implement all of the 
> BRKSI flows back to the MASA. The only nuisance factor is the 
> 'prior-signed-voucher-request'.. If MASA's are willing allow this field to be 
> omitted and to trust the Registrar then nothing more needs to done. If MASA's 
> need this field then we could get it from the Device via OPC UA but producing 
> the CMS message adds an additional burden on low end devices (i.e. the need 
> to pull in libraries that provide the same functionality as OPC UA but do it 
> in different format).
> 
> The 2 modes of operation with a OPC UA aware registrar (the Certificate 
> Manager is an OPC UA defined entity).
> 
> Pull (device initiated)
> 
> 
> 
> Push (Registrar initiated)
> 
> 
> 
> Regards,
> 
> Randy
> 
> -Original Message-
> From: Toerless Eckert mailto:t...@cs.fau.de>>
> Sent: August 6, 2019 3:31 PM
> To: Randy Armstrong (OPC)  <mailto:randy.armstr...@opcfoundation.org>>
> Cc: Eliot Lear mailto:l...@cisco.com>>; 
> iot-onboard...@ietf.org <mailto:iot-onboard...@ietf.org>; anima@ietf.org 
> <mailto:anima@ietf.org>
> Subject: Re: [Iot-onboarding] OPC and BRSKI
> 
> On Tue, Aug 06, 2019 at 09:32:45PM +, Randy Armstrong (OPC) wrote:
> > OPC is layered to separate the application from the choice of network 
> > pr

Re: [Anima] [Iot-onboarding] OPC and BRSKI

[Eliot Lear]

Randy,

Thanks.  We have irregular calls, but I will poll for one in the 3rd week of 
August to discuss your use case.

In an OPC UA environment, might one expect that the join registrar and the 
certificate manager be co-resident?  This would be where EST/SCEP would happen 
(BRSKI can be viewed as an extension to EST - RFC 7030).  There is no "push 
mode" for EST.  However, my understanding is that the same capability roughly 
speaking resides in CIP.

My bigger question is whether you want to use all of this for network 
authentication to avoid unauthorized devices joining the network in the first 
place, or whether this is intended solely for application authentication.

Eliot


> On 7 Aug 2019, at 01:19, Randy Armstrong (OPC) 
>  wrote:
> 
> Push should be “Certificate Manager initiated”
> 
> From: Iot-onboarding  <mailto:iot-onboarding-boun...@ietf.org>> On Behalf Of Randy Armstrong (OPC)
> Sent: August 6, 2019 4:17 PM
> To: Toerless Eckert mailto:t...@cs.fau.de>>
> Cc: iot-onboard...@ietf.org <mailto:iot-onboard...@ietf.org>; anima@ietf.org 
> <mailto:anima@ietf.org>; Eliot Lear mailto:l...@cisco.com>>
> Subject: Re: [Iot-onboarding] OPC and BRSKI
> 
> Hi
> 
> 1) Sure, need to understand how TCP UA works wih the minimum amount of 
> message authentication to allow for BRSKI. Main challenge may be the need for 
> pledges to receive messages from registrar that are authenticated by the 
> registar, but where the pledge has to wait until it can actually perform the 
> authentication later. Depending on how you built TCP UA message layer 
> authentication this may be piece of cake / free or not.
> 
> It would be easy to drop in a OPC UA aware registrar and implement all of the 
> BRKSI flows back to the MASA. The only nuisance factor is the 
> 'prior-signed-voucher-request'.. If MASA's are willing allow this field to be 
> omitted and to trust the Registrar then nothing more needs to done. If MASA's 
> need this field then we could get it from the Device via OPC UA but producing 
> the CMS message adds an additional burden on low end devices (i.e. the need 
> to pull in libraries that provide the same functionality as OPC UA but do it 
> in different format).
> 
> The 2 modes of operation with a OPC UA aware registrar (the Certificate 
> Manager is an OPC UA defined entity).
> 
> Pull (device initiated)
> 
> 
> 
> Push (Registrar initiated)
> 
> 
> 
> Regards,
> 
> Randy
> 
> -Original Message-
> From: Toerless Eckert mailto:t...@cs.fau.de>>
> Sent: August 6, 2019 3:31 PM
> To: Randy Armstrong (OPC)  <mailto:randy.armstr...@opcfoundation.org>>
> Cc: Eliot Lear mailto:l...@cisco.com>>; 
> iot-onboard...@ietf.org <mailto:iot-onboard...@ietf.org>; anima@ietf.org 
> <mailto:anima@ietf.org>
> Subject: Re: [Iot-onboarding] OPC and BRSKI
> 
> On Tue, Aug 06, 2019 at 09:32:45PM +, Randy Armstrong (OPC) wrote:
> > OPC is layered to separate the application from the choice of network 
> > protocol. TLS/WebSockets is an option but the primary protocol that will be 
> > used by low end devices is UA TCP which provides complete message based 
> > security framework.  These devices do not need TLS to have security and 
> > requiring it would require duplication of code.
> 
> Sure, need to understand how TCP UA works wih the minimum amount of message 
> authentication to allow for BRSKI. Main challenge may be the need for pledges 
> to receive messages from registrar that are authenticated by the registar, 
> but where the pledge has to wait until it can actually perform the 
> authentication later. Depending on how you built TCP UA message layer 
> authentication this may be piece of cake / free or not.
> 
> > 2) At some point, the thing decides which part gets an IP address or at 
> > least is responsible for the phy.  Can that process be leveraged to 
> > establish identity?
> >
> > Machines may have a separate network for internal Devices which IPs 
> > assigned by the machine???s DHCP service. Some of these devices may 
> > interact with external equipment via a NAT router which assigns a unique 
> > port to each device. This means the individual Devices need to be granted 
> > access to the operators network when the machine is installed even though 
> > the operator cannot provide them with IPs.
> >
> > I need to consult with our machine experts to better explain this use case.
> 
> Primary questions seem to be whether this is just about authentication at the 
> TCP UA layer or further below at some implied NAC mechanism.
> 
> > 3) One possible view here is that the MASA may be offline, and may have 
> > provided

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)

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

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

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

[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] Magnus Westerlund's Discuss on draft-ietf-anima-bootstrapping-keyinfra-22: (with DISCUSS)

[Eliot Lear]

Michael, Magnus,

I want to reinforce a point I made in that previous discussion about pledges 
using BRSKI with H2 (and by extension QUIC).  In this limited case, both 
present needless overhead both in terms of dev costs and COGS.  H2 in 
particular, and in this particular case, introduces new dev complexity because 
the provisional trust model used in BRSKI means that you cannot make use of 
multiple channels within the transport until at least the BRSKI transaction is 
complete.  And once it’s complete, and once EST is complete, the session is 
expected to terminate(*).  When BRSKI is in play, these transactions will 
happen lock step.

Eliot

(*) Keep in mind these protocols are used to establish network access.  A good 
analogy is that they are the language used to communicate at the gate with the 
security guard.  Typically one prefers that conversation to be short and to the 
point, so that one can get on with the business at hand.


> On 13 Jul 2019, at 20:41, Michael Richardson  wrote:
> 
> 
> <#secure method=pgpmime mode=sign>
> 
> Magnus Westerlund via Datatracker  wrote:
>> A. This is really a discuss discuss. With to little time to dig into
>> the details it appears that this protocol is making i hack of its
>> interface towards the its transport. It appears to attempt to use an
>> HTTP rest interface, but then it is also have a lot of talking about
>> requirement for the TLS connection underlying the HTTP. So to
>> illustrate the issue I see here is what happens if one like to use QUIC
>> as the underlying transport for the rest interface rather than TCP/TLS?
>> So can this document achieve a clearer interface to the lower layers so
>> that it will be simpler to move the protocol to another underlying
>> version of the HTTP "transport"?
> 
> Between the JRC (Registrar) and the MASA, we can support any HTTPS, including
> HTTP/2 with QUIC (with the 'normal' corporate firewall issue with UDP).
> 
> Between the Pledge and the Registrar, we support any HTTPS that works over a
> single TCP connection.  We can not support QUIC, since the Pledge is behind
> an intentionally limited proxy.  We had some discussion about this a year or
> so ago, please see:
>  https://mailarchive.ietf.org/arch/msg/anima/ml1OSEKhR4-ICS0Bd0zfuzn8uw4
> 
> You are certainly right: we have linkage between the TLS layer and the
> application layer, and we expect TLSClientCertificates and
> TLSServerCertificates to have meaning at the application layer.
> 
> None of the connections could go through TLS "forced proxies" of the kind
> that are apparently common in Enterprises.
> 
> I am open to suggestions on how to make the document clearer about how it
> interfaces to TLS.  We have a sections:
>5.1.  BRSKI-EST TLS establishment details . . . . . . . . . . .  36
>5.4.  BRSKI-MASA TLS establishment details  . . . . . . . . . .  38
> 
> 
> 
>> B. Section 5.6:
> 
>> The server MUST answer with a suitable 4xx or 5xx HTTP [RFC2616] error
>> code when a problem occurs.
> 
>> Referencing RFC 2616 that has been obsolete by RFC 7230 and
>> companions. I do note that there are no normative reference for that
>> part in this document.
> 
> Fixed to 7230.
> Yes, that wasn't even a real reference, just a literal [RFC2616].
> 
> --
> ]   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
> [
> 
> 
> --
> Michael Richardson , Sandelman Software Works
> -= IPv6 IoT consulting =-
> 
> 
> 
> ___
> 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)

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

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

[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] Content-Transfer-Encoding and HTTP 1.x in ANIMA BRSKI

[Eliot Lear]

I am looking at libest and it certainly generates the header.

> On 13 Jun 2019, at 08:27, Carsten Bormann  wrote:
> 
> On Jun 12, 2019, at 19:26, Julian Reschke  wrote:
>> 
>>> 2) Assuming the answer to (1) is no, what should we make of RFC7030
>>>   that says to use it, and to base64 binary objects?
>> 
>> Raise an erratum :-).
> 
> Not sure about the smiley here.  This is an erratum.
> Now how to resolve this depends on what option causes the smallest damage.
> 
> RFC 7030 is supposed to be a widely deployed protocol, so it should not be 
> hard to find out what people out there are actually doing.
> 
> Grüße, Carsten
> 
> ___
> 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] Last Call: (Bootstrapping Remote Secure Key Infrastructures (BRSKI)) to Proposed Standard

[Eliot Lear]

> On 11 Jun 2019, at 13:39, Eric Rescorla  wrote:
> 
> As I mentioned in another email exchange, why not use two domains under 
> .example?

I missed that.  That would be fine with a good example.

Eliot

> 
> On Tue, Jun 11, 2019 at 1:40 AM Eliot Lear  <mailto:l...@cisco.com>> wrote:
> Hi
> 
>> On 10 Jun 2019, at 13:16, Eric Rescorla > <mailto:e...@rtfm.com>> wrote:
>> 
>> 
>> That's a little unfortunate from the perspective of this attack because .com 
>> is a public suffix [0] whereas example.com <http://example.com/> is not.
>> 
> 
> 
> After a private exchange, I understand the nature of Eric's concern. The 
> issue is that you want to demonstrate separate administrative entities, and 
> subdomains generally wouldn’t that point clear.  The problem is that the 
> obvious examp1e is already registered.  Thoughts?
> 
> Eliot
> 
>> -Ekr
>> 
>> [0] https://publicsuffix.org/ <https://publicsuffix.org/>
>> 
>> Brian
>> 
>> >> But taking your thought into account: There is a fundamental difference
>> >> betwen TOFU and out-of-band-authentication/approval (pick a term),
>> >> and the fact that different such mechanisms may have (often human)
>> >> weaknesses does not change this fundamental difference ??
>> >
>> >
>> > I think the key is that humans oughtn’t rely solely on a visual inspection 
>> > of whatever is presented in front of them, but rather that they might rely 
>> > on alternative inputs, such as recommendations made by the registrar 
>> > provider, or federated services.
>> >
>> >
>> >>
>> >> Maybe you want to propose text ?
>> >
>> > Manual approval by administrator or selection by administrator.
>> >
>> > Eliot
>> >>
>> >> Cheers
>> >>   Toerless
>> >>
>> >> On Wed, Jun 05, 2019 at 01:09:09PM +0200, Eliot Lear wrote:
>> >>> Hi Toerless,
>> >>>
>> >>>> On 4 Jun 2019, at 21:28, Toerless Eckert > >>>> <mailto:t...@cs.fau.de>> wrote:
>> >>>>
>> >>>> Thanks, Eliot,
>> >>>>
>> >>>> re-reading 10.3, my impression is:
>> >>>>
>> >>>> a) The use of TOFU in 10.3 seems to exceed the explanatory definition 
>> >>>> in 1.2.
>> >>>> The sentence stubs in 103 mentioning TOFU also don't seem to add value, 
>> >>>> the text
>> >>>> doesn't become IMHO worse if they are simply removed. And i am sure
>> >>>> there can easily be similar non-cyptographic leap of faiths in sales 
>> >>>> integration,
>> >>>> or consortium memberships trust chaing establishment.
>> >>>
>> >>> My point is that those are no longer leaps of faith.
>> >>>
>> >>> Eliot
>> >>>
>> >>>>
>> >>>> b) The text could IMHO be crisper:
>> >>>>
>> >>>> "will have no problem collaborating with it's MASA" ->
>> >>>> "will have no problem collaborating with it's malicious MASA" ->
>> >>>>
>> >>>> "the domain (registrar) still needs to trust the manufacturer" ->
>> >>>> "the domain (registrar) still needs to authenticate the MASA" ?
>> >>>> (i hope the latter is the correct interpretation of the text)
>> >>>>
>> >>>> Cheers
>> >>>>   Toerless
>> >>>>
>> >>>> On Tue, Jun 04, 2019 at 06:33:00PM +0200, Eliot Lear wrote:
>> >>>>> Just on this text:
>> >>>>>
>> >>>>> In Section 10.3 the following text exists:
>> >>>>>
>> >>>>>  o  A Trust-On-First-Use (TOFU) mechanism.  A human would be queried
>> >>>>> upon seeing a manufacturer's trust anchor for the first time, and
>> >>>>> then the trust anchor would be installed to the trusted store.
>> >>>>> There are risks with this; even if the key to name is validated
>> >>>>> using something like the WebPKI, there remains the possibility
>> >>>>> that the name is a look alike: e.g, c1sco.com <http://c1sco.com/>, 
>> >>>>> ..
>> >>>>>
>> >>>>> First, this 

Re: [Anima] Last Call: (Bootstrapping Remote Secure Key Infrastructures (BRSKI)) to Proposed Standard

[Eliot Lear]

Hi

> On 10 Jun 2019, at 13:16, Eric Rescorla  wrote:
> 
> 
> That's a little unfortunate from the perspective of this attack because .com 
> is a public suffix [0] whereas example.com <http://example.com/> is not.
> 


After a private exchange, I understand the nature of Eric's concern. The issue 
is that you want to demonstrate separate administrative entities, and 
subdomains generally wouldn’t that point clear.  The problem is that the 
obvious examp1e is already registered.  Thoughts?

Eliot

> -Ekr
> 
> [0] https://publicsuffix.org/ <https://publicsuffix.org/>
> 
> Brian
> 
> >> But taking your thought into account: There is a fundamental difference
> >> betwen TOFU and out-of-band-authentication/approval (pick a term),
> >> and the fact that different such mechanisms may have (often human)
> >> weaknesses does not change this fundamental difference ??
> >
> >
> > I think the key is that humans oughtn’t rely solely on a visual inspection 
> > of whatever is presented in front of them, but rather that they might rely 
> > on alternative inputs, such as recommendations made by the registrar 
> > provider, or federated services.
> >
> >
> >>
> >> Maybe you want to propose text ?
> >
> > Manual approval by administrator or selection by administrator.
> >
> > Eliot
> >>
> >> Cheers
> >>   Toerless
> >>
> >> On Wed, Jun 05, 2019 at 01:09:09PM +0200, Eliot Lear wrote:
> >>> Hi Toerless,
> >>>
> >>>> On 4 Jun 2019, at 21:28, Toerless Eckert  >>>> <mailto:t...@cs.fau.de>> wrote:
> >>>>
> >>>> Thanks, Eliot,
> >>>>
> >>>> re-reading 10.3, my impression is:
> >>>>
> >>>> a) The use of TOFU in 10.3 seems to exceed the explanatory definition in 
> >>>> 1.2.
> >>>> The sentence stubs in 103 mentioning TOFU also don't seem to add value, 
> >>>> the text
> >>>> doesn't become IMHO worse if they are simply removed. And i am sure
> >>>> there can easily be similar non-cyptographic leap of faiths in sales 
> >>>> integration,
> >>>> or consortium memberships trust chaing establishment.
> >>>
> >>> My point is that those are no longer leaps of faith.
> >>>
> >>> Eliot
> >>>
> >>>>
> >>>> b) The text could IMHO be crisper:
> >>>>
> >>>> "will have no problem collaborating with it's MASA" ->
> >>>> "will have no problem collaborating with it's malicious MASA" ->
> >>>>
> >>>> "the domain (registrar) still needs to trust the manufacturer" ->
> >>>> "the domain (registrar) still needs to authenticate the MASA" ?
> >>>> (i hope the latter is the correct interpretation of the text)
> >>>>
> >>>> Cheers
> >>>>   Toerless
> >>>>
> >>>> On Tue, Jun 04, 2019 at 06:33:00PM +0200, Eliot Lear wrote:
> >>>>> Just on this text:
> >>>>>
> >>>>> In Section 10.3 the following text exists:
> >>>>>
> >>>>>  o  A Trust-On-First-Use (TOFU) mechanism.  A human would be queried
> >>>>> upon seeing a manufacturer's trust anchor for the first time, and
> >>>>> then the trust anchor would be installed to the trusted store.
> >>>>> There are risks with this; even if the key to name is validated
> >>>>> using something like the WebPKI, there remains the possibility
> >>>>> that the name is a look alike: e.g, c1sco.com <http://c1sco.com/>, 
> >>>>> ..
> >>>>>
> >>>>> First, this isn???t REALLY Trust-On-First-Use, and I would prefer that 
> >>>>> the term be replaced with something like "out-of-band approval".  This 
> >>>>> would also be a good area for certification services to step in to 
> >>>>> indicate the trustworthiness of a manufacturer.
> >>>>>
> >>>>> Eliot
> >>>>>
> >>>>>> On 21 May 2019, at 23:21, The IESG  >>>>>> <mailto:iesg-secret...@ietf.org>> wrote:
> >>>>>>
> >>>>>>
> >>>>>> The IESG has received a request from the Autonomic Networking 
> >>>>>> Int

Re: [Anima] Last Call: (Bootstrapping Remote Secure Key Infrastructures (BRSKI)) to Proposed Standard

[Eliot Lear]

> On 7 Jun 2019, at 23:17, Toerless Eckert  wrote:
> 
> Ok, now i got you (i hope ;-).
> 
> I really liked the c1sco example (not sure if we should mention a real
> company name in such an rfc someone not reading the draft might take
> offense, maybe examp1e.com insted though).

This is a bit tricky with the glyph attack, but certainly the base should be
example.com.


> 
> But taking your thought into account: There is a fundamental difference
> betwen TOFU and out-of-band-authentication/approval (pick a term),
> and the fact that different such mechanisms may have (often human)
> weaknesses does not change this fundamental difference ??


I think the key is that humans oughtn’t rely solely on a visual inspection of 
whatever is presented in front of them, but rather that they might rely on 
alternative inputs, such as recommendations made by the registrar provider, or 
federated services.


> 
> Maybe you want to propose text ?

Manual approval by administrator or selection by administrator.

Eliot
> 
> Cheers
>   Toerless
> 
> On Wed, Jun 05, 2019 at 01:09:09PM +0200, Eliot Lear wrote:
>> Hi Toerless,
>> 
>>> On 4 Jun 2019, at 21:28, Toerless Eckert  wrote:
>>> 
>>> Thanks, Eliot,
>>> 
>>> re-reading 10.3, my impression is:
>>> 
>>> a) The use of TOFU in 10.3 seems to exceed the explanatory definition in 
>>> 1.2.
>>> The sentence stubs in 103 mentioning TOFU also don't seem to add value, the 
>>> text
>>> doesn't become IMHO worse if they are simply removed. And i am sure
>>> there can easily be similar non-cyptographic leap of faiths in sales 
>>> integration,
>>> or consortium memberships trust chaing establishment.
>> 
>> My point is that those are no longer leaps of faith.
>> 
>> Eliot
>> 
>>> 
>>> b) The text could IMHO be crisper:
>>> 
>>> "will have no problem collaborating with it's MASA" ->
>>> "will have no problem collaborating with it's malicious MASA" ->
>>> 
>>> "the domain (registrar) still needs to trust the manufacturer" ->
>>> "the domain (registrar) still needs to authenticate the MASA" ?
>>> (i hope the latter is the correct interpretation of the text)
>>> 
>>> Cheers
>>>   Toerless
>>> 
>>> On Tue, Jun 04, 2019 at 06:33:00PM +0200, Eliot Lear wrote:
>>>> Just on this text:
>>>> 
>>>> In Section 10.3 the following text exists:
>>>> 
>>>>  o  A Trust-On-First-Use (TOFU) mechanism.  A human would be queried
>>>> upon seeing a manufacturer's trust anchor for the first time, and
>>>> then the trust anchor would be installed to the trusted store.
>>>> There are risks with this; even if the key to name is validated
>>>> using something like the WebPKI, there remains the possibility
>>>> that the name is a look alike: e.g, c1sco.com, ..
>>>> 
>>>> First, this isn???t REALLY Trust-On-First-Use, and I would prefer that the 
>>>> term be replaced with something like "out-of-band approval".  This would 
>>>> also be a good area for certification services to step in to indicate the 
>>>> trustworthiness of a manufacturer.
>>>> 
>>>> Eliot
>>>> 
>>>>> On 21 May 2019, at 23:21, The IESG  wrote:
>>>>> 
>>>>> 
>>>>> The IESG has received a request from the Autonomic Networking Integrated
>>>>> Model and Approach WG (anima) to consider the following document: -
>>>>> 'Bootstrapping Remote Secure Key Infrastructures (BRSKI)'
>>>>>  as Proposed Standard
>>>>> 
>>>>> This is a second Last Call. IoT Directorate review was done after the 
>>>>> ANIMA
>>>>> WG Last Call and consensus to request the publication, and that review 
>>>>> resulted
>>>>> in substantial changes to the document.
>>>>> 
>>>>> The IESG plans to make a decision in the next few weeks, and solicits 
>>>>> final
>>>>> comments on this action. Please send substantive comments to the
>>>>> i...@ietf.org mailing lists by 2019-06-04. Exceptionally, comments may be
>>>>> sent to i...@ietf.org instead. In either case, please retain the 
>>>>> beginning of
>>>>> the Subject line to allow automated sorting.
>>>>> 
>>>>> Abstract
>>>>> 
>>>>

Re: [Anima] Last Call: (Bootstrapping Remote Secure Key Infrastructures (BRSKI)) to Proposed Standard

[Eliot Lear]

Hi Toerless,

> On 4 Jun 2019, at 21:28, Toerless Eckert  wrote:
> 
> Thanks, Eliot,
> 
> re-reading 10.3, my impression is:
> 
> a) The use of TOFU in 10.3 seems to exceed the explanatory definition in 1.2.
> The sentence stubs in 103 mentioning TOFU also don't seem to add value, the 
> text
> doesn't become IMHO worse if they are simply removed. And i am sure
> there can easily be similar non-cyptographic leap of faiths in sales 
> integration,
> or consortium memberships trust chaing establishment.

My point is that those are no longer leaps of faith.

Eliot

> 
> b) The text could IMHO be crisper:
> 
> "will have no problem collaborating with it's MASA" ->
> "will have no problem collaborating with it's malicious MASA" ->
> 
> "the domain (registrar) still needs to trust the manufacturer" ->
> "the domain (registrar) still needs to authenticate the MASA" ?
> (i hope the latter is the correct interpretation of the text)
> 
> Cheers
>Toerless
> 
> On Tue, Jun 04, 2019 at 06:33:00PM +0200, Eliot Lear wrote:
>> Just on this text:
>> 
>> In Section 10.3 the following text exists:
>> 
>>   o  A Trust-On-First-Use (TOFU) mechanism.  A human would be queried
>>  upon seeing a manufacturer's trust anchor for the first time, and
>>  then the trust anchor would be installed to the trusted store.
>>  There are risks with this; even if the key to name is validated
>>  using something like the WebPKI, there remains the possibility
>>  that the name is a look alike: e.g, c1sco.com, ..
>> 
>> First, this isn???t REALLY Trust-On-First-Use, and I would prefer that the 
>> term be replaced with something like "out-of-band approval".  This would 
>> also be a good area for certification services to step in to indicate the 
>> trustworthiness of a manufacturer.
>> 
>> Eliot
>> 
>>> On 21 May 2019, at 23:21, The IESG  wrote:
>>> 
>>> 
>>> The IESG has received a request from the Autonomic Networking Integrated
>>> Model and Approach WG (anima) to consider the following document: -
>>> 'Bootstrapping Remote Secure Key Infrastructures (BRSKI)'
>>>  as Proposed Standard
>>> 
>>> This is a second Last Call. IoT Directorate review was done after the ANIMA
>>> WG Last Call and consensus to request the publication, and that review 
>>> resulted
>>> in substantial changes to the document.
>>> 
>>> The IESG plans to make a decision in the next few weeks, and solicits final
>>> comments on this action. Please send substantive comments to the
>>> i...@ietf.org mailing lists by 2019-06-04. Exceptionally, comments may be
>>> sent to i...@ietf.org instead. In either case, please retain the beginning 
>>> of
>>> the Subject line to allow automated sorting.
>>> 
>>> Abstract
>>> 
>>> 
>>>  This document specifies automated bootstrapping of an Autonomic
>>>  Control Plane.  To do this a remote secure key infrastructure (BRSKI)
>>>  is created using manufacturer installed X.509 certificate, in
>>>  combination with a manufacturer's authorizing service, both online
>>>  and offline.  Bootstrapping a new device can occur using a routable
>>>  address and a cloud service, or using only link-local connectivity,
>>>  or on limited/disconnected networks.  Support for lower security
>>>  models, including devices with minimal identity, is described for
>>>  legacy reasons but not encouraged.  Bootstrapping is complete when
>>>  the cryptographic identity of the new key infrastructure is
>>>  successfully deployed to the device but the established secure
>>>  connection can be used to deploy a locally issued certificate to the
>>>  device as well.
>>> 
>>> 
>>> 
>>> 
>>> The file can be obtained via
>>> https://datatracker.ietf.org/doc/draft-ietf-anima-bootstrapping-keyinfra/
>>> 
>>> IESG discussion can be tracked via
>>> https://datatracker.ietf.org/doc/draft-ietf-anima-bootstrapping-keyinfra/ballot/
>>> 
>>> The following IPR Declarations may be related to this I-D:
>>> 
>>>  https://datatracker.ietf.org/ipr/2816/
>>>  https://datatracker.ietf.org/ipr/3233/
>>>  https://datatracker.ietf.org/ipr/2463/
>>> 
>>> 
>>> 
>>> The document contains these normative downward references.
>>> See RFC 3967 for additional information:
>>>   rfc8368: Using an Autonomic Control Plane for Stable Connectivity of 
>>> Network Operations, Administration, and Maintenance (OAM) (Informational - 
>>> IETF stream)
>>> 
>>> 
>>> 
>>> ___
>>> 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
> 
> 
> --
> ---
> t...@cs.fau.de



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

Re: [Anima] Last Call: (Bootstrapping Remote Secure Key Infrastructures (BRSKI)) to Proposed Standard

[Eliot Lear]

Just on this text:

In Section 10.3 the following text exists:

   o  A Trust-On-First-Use (TOFU) mechanism.  A human would be queried
  upon seeing a manufacturer's trust anchor for the first time, and
  then the trust anchor would be installed to the trusted store.
  There are risks with this; even if the key to name is validated
  using something like the WebPKI, there remains the possibility
  that the name is a look alike: e.g, c1sco.com, ..

First, this isn’t REALLY Trust-On-First-Use, and I would prefer that the term 
be replaced with something like "out-of-band approval".  This would also be a 
good area for certification services to step in to indicate the trustworthiness 
of a manufacturer.

Eliot

> On 21 May 2019, at 23:21, The IESG  wrote:
> 
> 
> The IESG has received a request from the Autonomic Networking Integrated
> Model and Approach WG (anima) to consider the following document: -
> 'Bootstrapping Remote Secure Key Infrastructures (BRSKI)'
>   as Proposed Standard
> 
> This is a second Last Call. IoT Directorate review was done after the ANIMA
> WG Last Call and consensus to request the publication, and that review 
> resulted
> in substantial changes to the document.
> 
> The IESG plans to make a decision in the next few weeks, and solicits final
> comments on this action. Please send substantive comments to the
> i...@ietf.org mailing lists by 2019-06-04. Exceptionally, comments may be
> sent to i...@ietf.org instead. In either case, please retain the beginning of
> the Subject line to allow automated sorting.
> 
> Abstract
> 
> 
>   This document specifies automated bootstrapping of an Autonomic
>   Control Plane.  To do this a remote secure key infrastructure (BRSKI)
>   is created using manufacturer installed X.509 certificate, in
>   combination with a manufacturer's authorizing service, both online
>   and offline.  Bootstrapping a new device can occur using a routable
>   address and a cloud service, or using only link-local connectivity,
>   or on limited/disconnected networks.  Support for lower security
>   models, including devices with minimal identity, is described for
>   legacy reasons but not encouraged.  Bootstrapping is complete when
>   the cryptographic identity of the new key infrastructure is
>   successfully deployed to the device but the established secure
>   connection can be used to deploy a locally issued certificate to the
>   device as well.
> 
> 
> 
> 
> The file can be obtained via
> https://datatracker.ietf.org/doc/draft-ietf-anima-bootstrapping-keyinfra/
> 
> IESG discussion can be tracked via
> https://datatracker.ietf.org/doc/draft-ietf-anima-bootstrapping-keyinfra/ballot/
> 
> The following IPR Declarations may be related to this I-D:
> 
>   https://datatracker.ietf.org/ipr/2816/
>   https://datatracker.ietf.org/ipr/3233/
>   https://datatracker.ietf.org/ipr/2463/
> 
> 
> 
> The document contains these normative downward references.
> See RFC 3967 for additional information:
>rfc8368: Using an Autonomic Control Plane for Stable Connectivity of 
> Network Operations, Administration, and Maintenance (OAM) (Informational - 
> IETF stream)
> 
> 
> 
> ___
> 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] Potential Milestones for ANIMA new charter

[Eliot Lear]

Hi Sheng,

> On 16 Mar 2019, at 01:56, Sheng Jiang  wrote:
> 
> Hi, Eliot,
> 
> As you know, the charter text is different from the milestones. In charter 
> text, we will have a paragraph to describe the BRSKI relevant works. In 
> principle, all BRSKI works, even those have not been mentioned, would be 
> covered. So, BRSKI works, no matter they are listed as milestones or not, are 
> in WG scope.

Thanks.  That’s what I was aiming at.  Are you looking for some proposed text?


> 
> Milestones are these work items that WG MUST deliver in a limited time, say a 
> year or one and half years. So, as WG chairs, we would like to have a shorter 
> list for each period, for which every work item has enough energy to complete 
> in time. This is also IESG would like to see. We could easily add milestones 
> later when the WG had shown enough interests and energy for new in-scope 
> works.
> 
> “+ One BRSKI document” means newly adopt one more BRSKI document. The reason 
> that we do not want too many new BRSKI document immediately is that the WG 
> need energy to guarantee the current adopted BRSKI works, including the main 
> BRSKI document and constrained voucher, to be completed as soon as possible 
> with high quality.
> 

I think we’re coming close to needing a bit of a work plan for just the BRSKI 
documents alone.  That is- it’s not just how many documents but which ones, in 
order to accomplish which functions.  At this point, I am presuming that the 
base document is just about done.  The constrained-voucher doc looks like it 
needs to get pushed over the finish line.  And then, it seems to me our 
chartering discussion might do well to focus down a bit on what is needed for 
different operating environments, so as to help sort overlap in drafts with an 
understanding of who wants to commit what code.

Eliot


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

Re: [Anima] Potential Milestones for ANIMA new charter

[Eliot Lear]

Hi Sheng,

Forgive me, but I believe that the charter text above the milestones needs a 
touch up.  I also see somewhere around six drafts worth of BRSKI work coming 
down the pike on their own.  They are:

draft-ietf-anima-constrained-voucher
draft-ietf-anima-contrained-voucher
draft-fries-anima-brski-async-enroll
draft-lear-eap-teap-brski
draft-vanderstok-anima-constrained-join-proxy
draft-richardson-anima-smarkarklink

And I expect that draft-lear-brski-pop will live to see another day.

Now it may be the right thing to split off this work into a separate WG, or it 
may be the right thing to continue in ANIMA.  I expect that some of the above 
can also consolidate, but there’s still a lot of work to be done, and cramming 
all of that into one draft would be inadvisable ;-)

Eliot

> On 15 Mar 2019, at 07:51, Sheng Jiang  wrote:
> 
> Hi, Toerless,
> 
> I am working on the charter text. It is not difficult to categetied the work 
> items into 4 classes: ANI+, ASA, BRSKI, Use cases. I am intending to put NOCs 
> into ANI+. I will send you a reword version on next Monday.
> 
> For milestones, giving that we have a long document waiting list as long as 
> 20. It would not sufficient to satisfy everyone for just 5 milestones by 
> saying everyone should have no more than one document through. We would face 
> more than 10 individuals asking for adoption. Anyway, here are my choice for 
> the first 5:
> 
> ASA Lifecycle (Lucent)
> ASA guideline (Brian C)
> GRASP Distribution (Bing Liu)
> Constrained Join Proxy for Bootstrapping Protocols (Michael R.)
> + One BRSKI document
> 
> This would looks good when we face IESG. Then, we may able to adopt 2 or 3 
> more document out of written milestones, I guess. But it would looks bad if 
> we have more than 10 WG document parallel. PS: we still have 7 WG documents 
> showing now, though 3 of them passed IESG review and waiting by MISREF – ACP!
> 
> Cheers,
> 
> Sheng
> ___
> 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] Call for agenda ANIMA @ IETF 104， Prague

[Eliot Lear]

Hi Sheng,

> On 12 Mar 2019, at 02:54, Sheng Jiang  wrote:
> 
> Hi, Eliot & Michael R.
> 
> Thanks for your email. I confirm your request and also the priority of BRSKI 
> relevant discussion. It would follow just after the WG documents update and 
> WG re-chartering unscrambling. Actually, I agree the discussion of BRSKI next 
> steps is part of WG recharter. We could skip the BRSKI part in the 
> re-chartering unscrambling.

Thank you.  I think this is an important aspect of the recharter.

Eliot


> 
> Regards,
> 
> Sheng
> 
>> -Original Message-
>> From: Michael Richardson [mailto:mcr+i...@sandelman.ca]
>> Sent: Tuesday, March 12, 2019 3:35 AM
>> To: Eliot Lear 
>> Cc: Sheng Jiang ; anima-cha...@ietf.org;
>> anima@ietf.org
>> Subject: Re: [Anima] Call for agenda ANIMA @ IETF 104， Prague
>> 
>> 
>> Eliot Lear  wrote:
>>> I think we had a lengthy conversation about BRSKI next steps, and that we
>>> should expect to spend some time on this in ANIMA. I think I count at least
>>> four drafts that are worth considering, and Michael might have more in
>> mind:
>> 
>>> * Draft-vanderstock-anima-constrained-join-proxy
>>> * Draft-lear-eap-teap-brski
>>> * Draft-ietf-6tisch-{…}
>> 
>>> * Draft-fries-anima-brski-async-enroll
>> {Eliot: Does this document include Oskar's requirements?}
>> 
>> Additional documents that call on BRSKI:
>> 
>> * draft-richardson-anima-smarkaklink (formerly
>> draft-richardson-anima-smartpledge)
>>   -> I have revised slides, and I walk to talka bout them.
>>  I believe that it solves draft-fries-anima-brski-async-enroll as well,
>>  but I haven't read the entire document yet.
>> 
>> * draft-reddy-dprive-bootstrap-dns-server
>> * draft-boucadair-dots-server-discovery
>>  --> some details are still TBD.
>> 
>> --
>> Michael Richardson , Sandelman Software Works  -=
>> IPv6 IoT consulting =-



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

Re: [Anima] Call for agenda ANIMA @ IETF 104， Prague

[Eliot Lear]

Hi Sheng Jiang,

I think we had a lengthy conversation about BRSKI next steps, and that we 
should expect to spend some time on this in ANIMA.  I think I count at least 
four drafts that are worth considering, and Michael might have more in mind:

Draft-vanderstock-anima-constrained-join-proxy
Draft-lear-eap-teap-brski
Draft-ietf-6tisch-{…}
Draft-fries-anima-brski-async-enroll

How would you like to organise that conversation?

Eliot


> On 8 Mar 2019, at 07:59, Sheng Jiang  wrote:
> 
> Hi, all anima,
> 
> We have been allocated a session of 2-hour for the ANIMA WG meeting for 
> IETF-104 (Prague) - Tuesday afternoon session I. We are now starting to 
> collect agenda items for the session. Please send your request for agenda by 
> March 14th, Thursday.
> 
> For this coming meeting, we would like to discuss potential future ANIMA 
> works. As normal, the priority among these non-charter work items would be: 
> these that have active discussion in mail list, then these have submitted 
> drafts, and topics without drafts.
> 
> Please send us (anima-chairs at ietf.org ) requests for 
> time slot by March 14th, Thursday and include:
> 
> Name of time slot:
> Name of draft(s):
> Time requested:
> Presenter name(s):
> 
> More details about the IETF 104, Prague can be found at:
> 
> https://www.ietf.org/how/meetings/104/
> 
> Again, presenters and draft authors please invoke active discussions in the 
> ANIMA list. Mail list is a very good place to discuss and reach consensus on 
> technical issues.
> 
> Best regards,
> 
> Toerless & Sheng
> ___
> 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] [Iot-onboarding] On boarding again

[Eliot Lear]

PRs welcome!

> On 7 Mar 2019, at 08:28, Szymon Słupik  wrote:
> 
> Hi Eliot,
> 
> It'd be great to include Bluetooth mesh in here, as (despite sharing the 
> brand and the underlying radio with Bluetooth LE) it is a completely 
> different animal, when it comes to onboarding, authentication, security. I 
> will add some initial bullets for Bluetooth mesh here, hope to do this next 
> week.
> 
> Best
> Szymon Slupik
> President, CTO
> +1-415-696-9111 
> 
> ul. Jasnogórska 44
> 31-358 Kraków
> Poland
> 
> www.silvair.com <http://www.silvair.com/>
>  <https://www.facebook.com/meetsilvair/>
> <https://www.linkedin.com/company/meetsilvair/>
> <https://twitter.com/meetsilvair>
> NOTICE TO RECIPIENT
> We inform you that Silvair sp. z o.o. with its registered office in Cracow 
> (31-358), at Jasnogórska Street 44 is the controller of your personal data. 
> You can find more information about processing personal data and your rights 
> here 
> <https://silvair.com/media/filer_public/e5/ba/e5ba1ed2-84e6-47da-8277-f10df2eed7cc/information_on_personal_data_processing_of_representative_of_entity_mail_contacts_to_establish_maintain_business_relationshipsfn.pdf>.
> This e-mail message and any documents accompanying it contain information 
> that belongs to SILVAIR. This e-mail is meant for only the intended recipient 
> of the transmission, and may be a communication privileged by law, 
> confidential and/or otherwise protected from disclosure. If you received this 
> e-mail in error and you are not the intended recipient, any review, use, 
> dissemination, distribution, or copying of this e-mail or attachment is 
> strictly prohibited. Please notify us immediately of the error by return 
> e-mail and please delete this message from your system.
> 
> 
> 
> On Wed, Mar 6, 2019 at 2:32 PM Eliot Lear  <mailto:l...@cisco.com>> wrote:
> Hi everyone,
> 
> For those who are interested in discussing onboarding, I’ve reserved an hour 
> on Wednesday afternoon (27 Mar) at 14:00 at the IETF in Karlin 3.  Since our 
> last conversation, a few of us put a bit of an inventory together, regarding 
> the mechanisms that are available.  Some of the questions we have Aren’t 
> Quite There Yet, but at least the inventory is coming along.
> 
> Goal of discussion this time around  would a shared understanding of how 
> these mechanisms work, what sort of commonality they have, and to perhaps 
> have some notion of applicability of each.
> 
> For your entertainment, you can take a look at a table… it’s a Github table 
> so you have to scroll a bit- see 
> https://github.com/iot-onboarding/catalog/blob/master/Onboard-Table.md 
> <https://github.com/iot-onboarding/catalog/blob/master/Onboard-Table.md>.  
> Feel free to issue PRs.
> 
> Also, feel free to agenda bash on iot-onboard...@ietf.org 
> <mailto:iot-onboard...@ietf.org>.
> 
> Eliot
> --
> Iot-onboarding mailing list
> iot-onboard...@ietf.org <mailto:iot-onboard...@ietf.org>
> https://www.ietf.org/mailman/listinfo/iot-onboarding 
> <https://www.ietf.org/mailman/listinfo/iot-onboarding>



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

[Anima] On boarding again

[Eliot Lear]

Hi everyone,

For those who are interested in discussing onboarding, I’ve reserved an hour on 
Wednesday afternoon (27 Mar) at 14:00 at the IETF in Karlin 3.  Since our last 
conversation, a few of us put a bit of an inventory together, regarding the 
mechanisms that are available.  Some of the questions we have Aren’t Quite 
There Yet, but at least the inventory is coming along.

Goal of discussion this time around  would a shared understanding of how these 
mechanisms work, what sort of commonality they have, and to perhaps have some 
notion of applicability of each.

For your entertainment, you can take a look at a table… it’s a Github table so 
you have to scroll a bit- see 
https://github.com/iot-onboarding/catalog/blob/master/Onboard-Table.md 
.  Feel 
free to issue PRs.

Also, feel free to agenda bash on iot-onboard...@ietf.org 
.

Eliot


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

Re: [Anima] New work item proposal / agenda request

[Eliot Lear]

Hi Sheng,

IMHO this would be a good topic to be part of the recharter discussion, and so 
I would suggest that it come before that.  And I think perhaps we indicate the 
other future work going on with BRSKI.

Eliot

> On 11 Feb 2019, at 02:42, Sheng Jiang  wrote:
> 
> Hi, Steffen,
> 
> How much time do you need? I will try my best to match your request. However, 
> giving we are in the recharter procedure, we are not sure how much time would 
> be needed for the charter discussion (if our new charter got approved before 
> the meeting, then the time would be relevant short). Therefore, I cannot 
> guarantee you the time length yet.
> 
> Regards,
> 
> Sheng
> 
>> -Original Message-
>> From: Fries, Steffen [mailto:steffen.fr...@siemens.com]
>> Sent: Saturday, February 09, 2019 12:44 AM
>> To: Toerless Eckert 
>> Cc: tte+an...@cs.fau.de; Sheng Jiang ;
>> anima@ietf.org; Brockhaus, Hendrik 
>> Subject: RE: New work item proposal / agenda request
>> 
>> Hi Toerless,
>> 
>> Sounds great. Looking forward to the meeting.
>> 
>> Best regards
>> Steffen
>> 
>>> -Original Message-
>>> From: Toerless Eckert 
>>> Sent: Freitag, 8. Februar 2019 13:26
>>> To: Fries, Steffen (CT RDA ITS) 
>>> Cc: tte+an...@cs.fau.de; jiangsh...@huawei.com; anima@ietf.org;
>>> Brockhaus, Hendrik (CT RDA ITS SEA-DE) 
>>> Subject: Re: New work item proposal / agenda request
>>> 
>>> Steffen,
>>> 
>>> This should be fine on the agenda. Sheng usually runs the agenda, he
>>> is out this week (chinese new year). Consider yourself top in queue of
>>> new work items ;-)
>>> 
>>> Cheers
>>>Toerless
>>> 
>>> On Thu, Feb 07, 2019 at 07:12:10PM +, Fries, Steffen wrote:
 Hello Toerless, hello Sheng,
 
 Based on the discussion we had in December about support of
 asynchronous operation/enrollment support in BRSKI on the mailing
>>> list, I'm preparing a contribution for the next IETF meeting. The work
>>> is based on requirements from industrial and IoT scenarios and targets
>>> the proposal a supporting self-contained objects as an extension to the
>> currently defined BRSKI to support asynchronous operation during enrolment.
 
 I'm currently preparing the draft contribution together with Hendrik
 ( a colleague) and would like to ask for a slot in the agenda. I
>>> saw the agenda request for an ANIMA WG meeting and was not sure how
>>> far advanced the planning of the meeting agenda already is. Just wanted to
>> ensure we're not too late. I will submit the draft in time before the next 
>> meeting.
 
 Best regards
 Steffen
 
> 
> ___
> 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] BRSKI support for asynchronous processing

[Eliot Lear]

Hi Steffen

> On 27 Nov 2018, at 11:49, Fries, Steffen  wrote:
> 
> Getting back to my original question, do you see the asynchronous handling of 
> pledge enrolment as part of the current charter of the working group?

I don’t know (I'll leave the to the chairs).  Assuming yes:

> If yes, would you rather expect to see EST enhanced to handle asynchronous 
> support or would it be better to allow for alternative enrolment protocol 
> support on the domain registrar featuring the handling of self-contained 
> objects? As the domain registrar is likely to be not a constraint device as a 
> pledge, this choice could technically be provided, while the pledge has the 
> freedom to choose, which enrolment to use.

If the domain registrar is not there, that’s an easy one, right?  Device just 
has to retry until the registrar is present (assuming it’s trying to onboard).  
Do you have requirements for more than that?

If the domain registrar is there and the CA is not there, there are seemingly 
two choices:
Store and forward from the registrar; or
Reject the request until the CA is present

If we add a 3rd approach of forwarding to some intermediary component, then 
*it* has to store and forward.  In any case, the registrar needs to return a 
status to the pledge, saying, “Thanks for checking in… check back with me in X 
minutes” (where X might be some value that can back off based on load.  Another 
alternative would be to refer to some 3rd player.

To implement the store and forward, the registrar just needs a queue, but the 
pledge needs to remember the request (and any associated nonce).  And I think 
that works out because any such behaviour would demand a few new EST RESTful 
endpoints.

Eliot



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

Re: [Anima] BRSKI support for asynchronous processing

[Eliot Lear]

> OK, thanks. I'm interested in another scenario too: one where the operator 
> will not accept using a connection to the open Internet and therefore will 
> not accept any real-time access to any MASA. As I've said for several years, 
> this is a highly likely scenario in some types of network which insist on 
> air-gap security or for some other reason do not trust a MASA (see Randy 
> Bush's comments a few weeks ago, e.g. 
> https://mailarchive.ietf.org/arch/msg/anima/rK_rlT3JH0AFGlS47XSRqQB2DJI ).
> 
> For such networks the only solution I can see is that all MASAs are replaced 
> by a single OASA (Operator Authorized Signing Authority) that is configured 
> and controlled by the operator. It handles the Registrar-MASA protocol and 
> returns vouchers exactly like a MASA, except that it emphatically isn't on 
> the global Internet. The OASA would procure a long-life voucher (normally 
> from the relevant MASA, via a nonceless registrar voucher-request) when a 
> device is purchased and added to inventory, and then deliver that voucher or 
> a short-term voucher when a registrar needs it. Instead of using the MASA URL 
> for each manufacturer, registrar-to-OASA connections all use a locally 
> defined URL for the OASA. Otherwise the protocol is standard BRSKI.
> 
> Any thoughts?

Yes, several.

First, there is now a mailing list that is related to this, 
iot-onboard...@ietf.org .  This is a follow-up 
to the side meeting that took place at the IETF where we are at least 
documenting existing mechanisms and requirements.There is a GitHub repo 
https://github.com/iot-onboarding  that 
people can commit into.  We haven’t yet started the requirements aspect, except 
in as much as we are asking “How"

Second, I agree that there is a desire to handle the case where onboarding 
doesn’t go all the way out the door to the vendor.  I think that is one use 
case, and a separate use case is where onboarding does.  To me this boils down 
to a combination of Join Registrar functionality and a means to communicate 
proof of possession / proof of ownership to the device through that registrar.  
Let’s not create new entities if we can at all avoid doing so.

Eliot



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

Re: [Anima] BRSKI support for asynchronous processing

[Eliot Lear]

Hi Steffen


> On 23 Nov 2018, at 20:27, Fries, Steffen  wrote:
> 
> Hi Eliot
> 
>>> We are currently in the process of discussing different scenarios and 
>>> approaches for the onboarding of (IoT) devices in plants, substations, or 
>>> cloud-based services. The current BRSKI document provides here a good 
>>> approach to address the case in which a pledge has an online connection to 
>>> a domain registrar to request a voucher for enrolling in a target domain 
>>> including the enrollment at the PKI. For the enrollment there exists the 
>>> binding between the certification request (as PKCS#10 object) and the 
>>> communication connection. I would see this as synchronous approach, as the 
>>> interaction between the pledge and the domain registrar and also the PKI 
>>> (CA) is based on a “live” communication connection.
>> 
>> I think the way to put this is that the Registrar is assumed to be 
>> integral/co-resident with the CA.
> 
> I assumed it to be collocates with the RA and that the CA is separate.

Ok, well there we have it ;-)

>> 
>>> 
>>> Besides this, we see further use cases, in which the connection to the PKI 
>>> is not always available. This may be the case if the connection to the CA 
>>> is only temporary available or not directly available. Here, the approach 
>>> would  require a rather asynchronous handling. In such a setup the domain 
>>> registrar could for instance store the object (certification request) and 
>>> forward it upon connectivity to the PKI for further processing. The forward 
>>> may be based on a communication connection or even manually. This 
>>> asynchronous approach requires that the object itself is self-protecting 
>>> ensuring its integrity (like a PKCS#7 wrapping of the PKCS#10 request or 
>>> similar). Based on the specified BRSKI features, we did not see the support 
>>> for this type of requirements directly.
>> 
>> 
>> To be clear, are we concerned about the EST request or the BRSKI request?  
>> The CA need not be available for BRSKI, but it does need to be available for 
>> EST.
> 
> I should have been more specific. I was referring to the EST request.  The 
> BRSKI request regarding the voucher is assumed to a proxy residing inside the 
> plant. I assumed a strong binding of EST and BRSKI.


Right.  And so with this, I think we do indeed have some questions:

Does the registrar have to play the role of “store and forward” and retain 
state or is it better to say, “Call me back another time”?
If we do want the registrar to retain state, then intermediate states need to 
be defined in EST, and perhaps in other mechanisms as well, to say, “Do you 
have my credential now?”
If we are assuming that the registrar and the CA are not co-resident, then 
there is a question of protecting the credential, as you mention.  Should that 
credential returned be encrypted?

And so the real question, to me, is whether or not we are handling the case 
where one has something of a roaming CA, where it is only present on occasion, 
or has to handle (re)enrolments periodically.

Right?

Eliot



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

Re: [Anima] BRSKI support for asynchronous processing

[Eliot Lear]

Hi Steffen

> On 23 Nov 2018, at 17:53, Fries, Steffen  wrote:
> 
> Hi everyone,
> 
> We are currently in the process of discussing different scenarios and 
> approaches for the onboarding of (IoT) devices in plants, substations, or 
> cloud-based services. The current BRSKI document provides here a good 
> approach to address the case in which a pledge has an online connection to a 
> domain registrar to request a voucher for enrolling in a target domain 
> including the enrollment at the PKI. For the enrollment there exists the 
> binding between the certification request (as PKCS#10 object) and the 
> communication connection. I would see this as synchronous approach, as the 
> interaction between the pledge and the domain registrar and also the PKI (CA) 
> is based on a “live” communication connection.

I think the way to put this is that the Registrar is assumed to be 
integral/co-resident with the CA.

> 
> Besides this, we see further use cases, in which the connection to the PKI is 
> not always available. This may be the case if the connection to the CA is 
> only temporary available or not directly available. Here, the approach would 
> require a rather asynchronous handling. In such a setup the domain registrar 
> could for instance store the object (certification request) and forward it 
> upon connectivity to the PKI for further processing. The forward may be based 
> on a communication connection or even manually. This asynchronous approach 
> requires that the object itself is self-protecting ensuring its integrity 
> (like a PKCS#7 wrapping of the PKCS#10 request or similar). Based on the 
> specified BRSKI features, we did not see the support for this type of 
> requirements directly.


To be clear, are we concerned about the EST request or the BRSKI request?  The 
CA need not be available for BRSKI, but it does need to be available for EST.

Eliot


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

[Anima] IoT Onboarding discussion summary from Bangkok

[Eliot Lear]

Dear Colleagues,

[Sorry for the wide distribution- on the other hand, please forward to
other interested parties ;-)]

Thanks to the 30 or so people who attended the side meeting on IoT
onboarding.  We had a pretty good discussion around the fact that there
is some fragmentation in the space that is confusing IoT developers. 
Some of this is due to the varying nature of devices and the varying
nature of deployments.  We focused a bit on 802.11, but not
exclusively.  We also discussed the relationship between "network
onboarding" and "application onboarding".

From our discussions we agreed that it would be good to catalog all the
various mechanisms that are available today, to attempt to identify
common architectural components, and to sort out the technical
requirements that these solutions need to address.  The intent was not
to limit this to either the IETF or IP (at least for now) but to capture
the whole field.  Also, non-standard mechanisms are welcome as well. 
Later perhaps we can come up with at least a document to navigate when a
particular mechanism might be appropriate.

To this end, Suresh has been kind enough to create a mailing list –
iot-onboard...@ietf.org – for this purpose.  You can join the mailing
list by going to https://www.ietf.org/mailman/listinfo/iot-onboarding.

In addition, I've created a github project that literally just catalogs
the stuff in the README.  ALL contributions are welcome.  Examples of
mechanisms that we would like to document are DPP, ANIMA/BRSKI (in all
of its varieties), how BT and Zigbee function in this regard, OCF, etc. 
The repository location can be found at
https://github.com/iot-onboarding/catalog.

We also agreed to checkpoint in December, before everyone disappears for
the holidays.  More information on this will be forthcoming.

To those who attended, did I miss anything?

Eliot



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

[Anima] side meeting on IoT onboarding

[Eliot Lear]

Hi everyone,

Thanks to those 30 or so people who participated in a side meeting just
after OPSAWG on IoT onboarding.  There was pretty clear agreement that
there is at least some fragmentation occurring in onboarding solutions,
leading to some confusion amongst some of the players.  In some cases,
like consumer, some didn't care that much, but everyone seemed to see
the problem in enterprise and industrial.  A few notes:

  * “Onboarding” means different things at different layers. As we move
forward we are primarily thinking about network onboarding here, but
if the credential used for network onboarding can be used for
application onboarding, that's a nice feature.
  * This matter spans multiple standards organizations.  In the meeting
yesterday we had participants from at least five, for example.
  * We agreed to try to flesh out a wiki that talks about all the
different mechanisms.  Some of these are cataloged in various
places, and some are not.  We are not at this point limiting
ourselves to just IP.
  * We also want to try to articulate architectural requirements.
  * As we build out the inventory of mechanisms we will seek to identify
common architectural components.
  * We'll try to get far along on the wiki for a December conference
call just to see how well we did, and to talk about next steps.
  * The activity is entirely open.  I've asked for a mailing list to be
created, and I have created a github repository known, funnily
enough, as "iot-onboarding".

If you're interested in this activity, please feel free to join the
mailing list when it is announced or otherwise add to the repository. 
If you were in the room and want to add your views, great.

Eliot




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

[Anima] change of venue: onboarding side meeting

[Eliot Lear]

As we seem to have a lot of interest in the topic of onboarding, we are
at risk of overflowing the very small room we were assigned.  Therefore,
the side meeting will now take place immediately after OPSAWG in Chitlada 2.

This meeting is intended as a discussion about whatever common
architectural blocks we can find between mechanisms such as ANIMA BRSKI,
DPP, EAP-NOOB, and others.

Regards,

Eliot





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

Re: [Anima] ship and forget use cases for onboarding

[Eliot Lear]

Hi Michael,


On 22.10.18 21:54, Michael Richardson wrote:
>
>
> https://en.wikipedia.org/wiki/Joe_Isuzu  ... I asked google, and I'm not
> quite sure I get the connection.

Sorry- this was a reference to an earlier message.  There is a mode in
which the MASA is acting based on its relationship with the registrar. 
The punch line with Joe Isuzu was “Trust me!”
> It's not enough to say that they are going to be deployed in disconnected
> environments.  It's that they one wants to drop-ship them from the
> *manufacturers* warehouse to the disconnected location.

There are quite a number of use cases where connectivity may be an issue:

  * A secure building, where Internet access is limited, and even
carrying in a USB stick is problematic.  This can range from a
military installation to a pharmaceutical laboratory, to certain
departments of financial institutions.
  * It could simply be an order of operations matter, where the device
has arrived in advance of Internet connectivity but still wants to
function (think fire suppression systems).

You may say, “but onboard them advance of their deployment”.  That may
or may not be practicable.

> When one thinks about drop-ship to a disconnected location, one tends to
> think about containers of humanitarian AID going out the back of a aircraft
> (C-2, Hercules, etc.) with a parachute.   If anything, that situation is
> probably *NOT* the case we are thinking about, because in that case the kit
> would have already gone through the owner's warehouse (whether the owner is
> a UN aid agency, some FEMA equivalent).  The entire kit could have been
> onboarded (wirelessly) as it went *onto* the aircraft, or could even occur
> as late as when it's on the aircraft.

I think we're get a better feel for some of this as time goes on, but
one could imagine components sitting in a drawer for five years. 
>
> And you said, "online MASA", when it could well be that it's an offline
> MASA.  If you buy enough product, the manufacturer could well just put
> a custom trust anchor in and give you the private key.  That's essentially
> what happens in Industrial 4.0 802.15.4 deployments today.

I certainly know manufacturers who do that, and they mostly hate it,
because it requires custom builds.

>
> So I'm saying, let's not invent a problem before we understand who actually
> has the problem and make sure that the people who can solve the problem
> are at our table.

This sounds like an EXCELLENT conversation for the next few weeks.

Eliot

>
> --
> Michael Richardson , Sandelman Software Works
>  -= IPv6 IoT consulting =-
>
>
>
>
>
> ___
> Anima mailing list
> Anima@ietf.org
> https://www.ietf.org/mailman/listinfo/anima



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

Re: [Anima] Fwd: New Version Notification for draft-lear-brski-pop-00.txt

[Eliot Lear]

[Christian, read down a ways]


On 22.10.18 20:15, Michael Richardson wrote:
> Eliot, thanks for this document. If nothing else, it means that
> we BRSKI authors can deal with some review comments by pointing to "future
> work" :-)
>
> (A)"request-voucher-with-possession" <-- what about intent to traffic? :-)
>   (for those that don't get the joke:
>   
> https://criminal.findlaw.com/criminal-charges/possession-with-the-intent-to-distribute.html
>  )
>
> if leaf out-of-band-claim to be set by the PLEDGE?
> I think it is set by the Registar?

In all cases, any out of band claim has to be collected by the
Registrar.  It is possible that having received such a claim from the
Registrar, the pledge forwards it along to the MASA.

>
> The document sadly ends too soon...

Gosh.  You want it all at once, don' you?!  Become an editor ;-)
>
> You say it is trying to do a few things.
>   1) deal with middle value pledge,
>  (and low-value pledges in very congested places)
>  where an out-of-band supply-chain integration is unavailable,
>  and the MASA has a any-registar policy for the device.

Yes.
>
>   2) provide a ship-and-forget mechanism.

Yes.
>
> It seems that the cryptographic POP mechanism is an ends to accomplish a
> means, rather than a core goal of the protocol.

I never employ hashes just for fun ;-)

> The Pledge already can
> sign it's voucher-request, and since it includes the Registrar's key when it
> does a proximity assertion, it's pretty good proof of possession for the
> *Registrar*, but it might provide inadequate assurance to the MASA of it's
> freshness.

I think this covers the Joe Isuzu case that can fall out of the draft,
and maybe one other.  The fundamental issue with the others is that the
Pledge needs some reason to believe that it is really on the correct
network.  Proof of possession can come in several forms, depending on
the device, but we're assuming that there's no user input to the device
available (e.g., no buttons, to touch screen, etc).  It could also be
that the Pledge really doesn't want to validate proof of possession by
itself.  In that case, there's no reason for the pledge to even know the
proof of possession.


>If the MASA could provide a nonce for the pledge to sign
> (requiring another round trip, and even more online assurance), that would
> provide even more proof.
>
> Given that you pushed this out before today's cutoff, I am not upset
> that there is so few details.  I am suspecting that in your thinking that you
> created the three objects, and realized that could accomplish
> "ship-and-forget" using a combination of them?

That's part of the thinking, yes.

>
> I also wonder if cryptographic-POP is being confused with "proof of
> ownership", which I think is what you really want to accomplish.

We can have that discussion .
>
> If one assumes some machine readable (QR) code that comes with the product,
> then there are a few things one can do to differently.  One of the things
> that I have thought a lot about is that one uses the printed code in the
> Registrar to establish a relationship with the MASA.  That is, one creates
> the supply-chain-integration by using the QR code with some zero-knowledge
> proof (I think that PAKE is the latest one) to establish that one is the
> legitimate Registrar for the product.  One can do this as *any time*
> (some mumble about the lifetime of the CA of the Registrar's key), and
> the product will be enrolled correctly at any future time.

Good point.  One possible thought in terms of the evolution of this work
would be “More stuff you can do with vouchers” with a plethora of
documented uses.  Or we might want to spawn a few more drafts.  Again,
worth discussion.

>
> About my joke (A) above, I think that ship-and-forget is an interesting
> goal, and in particular, if also may enable desireable "traffic"ing.  That
> is, if the manufacturer can transfer the product to my ownership without any
> online interaction, then presumably, I can also *resell* the device to
> you using the same lack-of-interaction?

Yes.  In fact that is a goal that I think both Christian and Randy have
motivated.  I would want to explore a bit whether or not to split out
ship and forget, but I would rather we tried to solve for that problem
because it really is here (see below).
>
> 
>
>> In addition, some manufacturers may prefer not to require the
>> existence of a MASA.  In these circumstances proof of possession to
>> the device is required.
>
> I would prefer that we split this into a different draft.
>
> I am very concerned that ship-and-forget is not a desireable property
> in the IoT space.  It essentially means that the manufacturer has no further
> interest in providing any kind of updates for the device.I have serious
> cybersecurity concerns about such devices being out there (sitting unpatched
> and untracked in a warehouse somewhere), as well as significant environmental
> concerns about devices 

Re: [Anima] FW: New Version Notification for draft-choi-anima-trust-networking-01.txt

[Eliot Lear]

Hi!

This is a very interesting draft that addresses an issue industry has
been seeing.  One of the challenges within an autonomic system is the
establishments of rights, even when a device is identified.  If we look
at Figure 6 in your draft, it is very similar to that of the conduit and
conduit controller mechanism envisioned by IEC 62443.  It would be
useful to have a discussion about that work in the context of this draft.

Eliot


On 22.10.18 03:43, 최태상 wrote:
> A new version of I-D, draft-choi-anima-trust-networking-01.txt
> has been successfully submitted by Tae Sang Choi and posted to the IETF 
> repository.
>
> Name: draft-choi-anima-trust-networking
> Revision: 01
> Title:Trust networking and procedures for Autonomic Networking
> Document date:2018-10-14
> Group:Individual Submission
> Pages:32
> URL:
> https://www.ietf.org/internet-drafts/draft-choi-anima-trust-networking-01.txt
> Status: 
> https://datatracker.ietf.org/doc/draft-choi-anima-trust-networking/
> Htmlized:   
> https://tools.ietf.org/html/draft-choi-anima-trust-networking-01
> Htmlized:   
> https://datatracker.ietf.org/doc/html/draft-choi-anima-trust-networking
> Diff:   
> https://www.ietf.org/rfcdiff?url2=draft-choi-anima-trust-networking-01
>
> Abstract:
>This document describes trust networking as an application of
>autonomic networking. The objective of trustworthy autonomic
>networking is providing trust networking environment where all
>autonomic nodes can communicate without any security concern. It
>defines a trust networking domain and describes how to configure and
>maintain the trust networking domain. While communication within the
>trust networking domain is done with trust, the communication with
>external nodes should be done via a specific autonomic service agent
>(ASA) called "trust gateway". The trust gateway ASA performs trust
>evaluation of the external nodes and enforces domain specific
>policies to keep the domain trustworthy.
>
>
>
>   
> 
>
>
> Please note that it may take a couple of minutes from the time of submission 
> until the htmlized version and diff are available at tools.ietf.org.
>
> The IETF Secretariat
>
> ___
> Anima mailing list
> Anima@ietf.org
> https://www.ietf.org/mailman/listinfo/anima
>




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

[Anima] Fwd: New Version Notification for draft-lear-brski-pop-00.txt

[Eliot Lear]

As promised, here is a draft that attempts to wangle BRSKI to allow for
proof of possession tests.  This is very early work and intended for
discussion at this point during OPSAWG and at the side meeting we have
scheduled for Tuesday night.  If people like what they see, we can
discuss in more detail in Prague.

This draft includes three specific test types, one of which may come out
Real Soon:

 1. The registrar has obtained proof of possession and provides that
proof to the MASA.  This solves a wireless case.
 2. The registrar has obtained proof of possession and, rather than
providing proof to the MASA, provides proof to the pledge (two-party
instead of three).
 3. The registrar tells the MASA, “Trust Me!  Really!” in its best Joe
Isuzu voice*.  (This may be redundant, which is why it may come out.)

Discussion points:

  * The basis of all of this work is really that Max, Michael, and Kent
did a bang up job by coming up with the voucher concept, and so
let's all agree PLEASE that no matter how we slice it, a voucher
request needs to be generated, and a voucher response needs to be
delivered.  The means for proof, and even the identity returned, can
be stretched.
  * Should we stretch further, and include different keying material
objects?  I'm CCing EAP folk because that is a big fat question for
them.

Eliot

* See https://www.youtube.com/watch?v=mR361ASrMew


--- Begin Message ---

A new version of I-D, draft-lear-brski-pop-00.txt
has been successfully submitted by Eliot Lear and posted to the
IETF repository.

Name:   draft-lear-brski-pop
Revision:   00
Title:  Proof of Possession to Devices for Onboarding
Document date:  2018-10-20
Group:  Individual Submission
Pages:  7
URL:https://www.ietf.org/internet-drafts/draft-lear-brski-pop-00.txt
Status: https://datatracker.ietf.org/doc/draft-lear-brski-pop/
Htmlized:   https://tools.ietf.org/html/draft-lear-brski-pop-00
Htmlized:   https://datatracker.ietf.org/doc/html/draft-lear-brski-pop


Abstract:
   This memo specifies a RESTful interface for local deployments to
   demonstrate proof of possession to a device or to a manufacturer
   authorized signing authority (MASA).  This covers the case where a
   MASA would not otherwise have knowledge of where a device is
   deployed, or when a MASA may not be required.  Such knowledge is
   important to onboard certain classes of devices, such as those on
   IEEE 802.11 networks.


  


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat


--- End Message ---


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

Re: [Anima] Secdir last call review of draft-ietf-anima-bootstrapping-keyinfra-16

[Eliot Lear]

Hi Michael:


On 03.10.18 04:35, Michael Richardson wrote:
> 1) you run a half-mind Registrar that is on the secure side of your air-gap, 
> and it has
>a USB interface (or 9-track tape drive... statscan.gc.ca used to run
>unidirectional UUCP over 9-track tapes walked across the machine room 
> air-gap)
>on which it can place voucher requests, and receive vouchers from
>other-half-mind Registrar.
>
>This lets you use nonced vouchers, potentially with expiry dates.
>Maybe very long expiry dates.  Or maybe your personnel-safety-critical
>equipment has a best-before date, and so it's acceptable for you to have
>vouchers only until that date.

One approach I would like would be to get the voucher size down to the
point where it could reasonably fit into a QR code.  Then it's a scan. 
I see that as future work.

Eliot



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

Re: [Anima] Secdir last call review of draft-ietf-anima-bootstrapping-keyinfra-16

[Eliot Lear]

Ted,


On 02.10.18 21:10, Ted Lemon wrote:
> The problem is that possibly billions of devices will be bricked and
> landfilled before this becomes the norm.

You really answered your own concern.  Nobody would put up with such an
approach that either intentionally bricked* a perfectly functional
device.  We have to pay some attention change of ownership and
organizations going out of business.  That's work to do, not a reason to
claim the sky is falling.

Eliot




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

Re: [Anima] Secdir last call review of draft-ietf-anima-bootstrapping-keyinfra-16

[Eliot Lear]

Randy

On 02.10.18 13:21, Randy Bush wrote:
>>> when i sell the lightb^Hrouter to mary, of course i reset to factory
>>> settings.
>> Great.  Mary can register the device with light^hrouter manufacturer
>> and life goes on.
> iff the manufacturer still exists and the manufacture is willing.
>
> you and others seem to be missing that there is a major right of
> ownership war going on out here in the real world.
>
>

I think we've lost sight of what we're talking about.  We're talking
about a completely automated method for a local trust anchor to be
installed on a device, and a kick to EST for the device to receive a
local credential.  For that to happen there needs to be a trusted
introduction, and the device manufacturer or its agent is in the best
position to do that.

There are many ways for a manufacturer to lock a device to a deployment
without this, just one example being a software license that gets erased
on device reset (remember?  you said you were going to perform a device
reset).  I'd suggest that we not get wrapped around the axle over the
ownership war. 

I would be more concerned about what happens if the manufacturer goes
out of business.  I think that's a bigger deal, but can I ask that we
also consider that problem with some more experience under our belts?  I
could easily envision a few solutions, but better would be to face down
the problem with some more code and deployment.  BTW, manufacturer going
out of business also means no more {bug fixes, security patches, h/w
support, etc}, and so zooming in and just dealing with this may be
suboptimal.

Eliot





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

Re: [Anima] Secdir last call review of draft-ietf-anima-bootstrapping-keyinfra-16

[Eliot Lear]

Hi Christian,

On 01.10.18 07:42, Christian Huitema wrote:
> If the manufacturer is willing to issue "good until time=X" vouchers,
> then in theory you could provide the voucher to your buyer, provided the
> time limit of the voucher has not elapsed. If the manufacturer signs a
> voucher "good until infinity", then the device can in theory be sold and
> resold forever. But that's probably not true in practice, because the
> voucher is written for a specific domain, and includes the certificate
> of the domain for which the voucher is good. You may be able to play
> games with some kind of certificate chain and make it work, but I will
> believe that when I see it.

IMHO it should be possible as an option to not pin the domain.  In that
case, a voucher could be a scannable label or BOM that can be handed off
directly with the device.  Obviously that's a nonceless option as well. 
Think of it as a file that one simply uploads to the registrar.  The key
thing here is that the manufacturer needs to make the decision for which
devices it wants to do this.  This would also solve [6] in your list of
issues.  However, this mitigation will not always be appropriate,
particularly for devices that may transit from one network to another,
or where it is simply inconvenient to retain a label.

Addressing some more of your LC comments:

> 1) Denial of service against the vendor MASA service. Adversaries could mount 
> an
> attack against the service at a critical time, preventing real-time issuance 
> of
> nonced vouchers. This could for example prevent the deployment of autonomic 
> networks
> during emergencies.

This can be mitigated by onboarding devices in inventory *before* the
emergency.  It could also be mitigated as per the above.

> 2) Compromise of the vendor's public key. This would allow attackers to get
> "ugly ducklings" imprinted in the domain.

Let's be clearer, because there are two separate threats:

 1. A compromised end point inappropriately being onboarded in order to
attack a network; where the registrar is validating the signature
and certificate; and
 2. A perfectly fine endpoint being inappropriately onboarded to an
unauthorized network; where the endpoint is validating the signature
and certificate.

Also, I think you are referring to the *private* key associated with a
vendor certificate.  [1] can be mitigated by the registrar by the vendor
reissuing the voucher signing cert and checking a CRL.  [2] requires a
bit more care and a backup certificate of some form.

> 3) Rotation of the vendor's public key. This could prevent old devices from
> joining the domain, or from verifying the new vouchers.

Old certificates never die.  They just fade away.  More seriously, if
the cert is used, it should be kept available, unless a backup is also
provided.

> 7) The closest to ship and forget is a MASA service configured to always
> issue vouchers, regardless of the device ID and the registrar domain. I would
> expect that to be popular with some manufacturers. It is mentioned in
> section 6.4, which recommend that manufacturers should not do that. What
> are the consequences if they still do? 

In a wireless scenario this could be problematic, since the device could
imprint on the first network seen.  This presumes something like
draft-lear-eap-teap-brski.txt.  We haven't gotten that far, but it is
clearly an issue and something we want to discuss in Bangkok.  In a
wired environment this is less of an issue, although there are still risks.

> 8) Attacks by the device. What happens if a device refuses to be imprinted?

It will not be able to trust the local environment, and may not be able
to retrieve a local certificate.  I presume lots of issues would crop up
from there.
> 11) Attacks by the MASA. What happens if the MASA refuses to provide a 
> voucher,
> or provides a wrong voucher? 

Same as above.  There is a mitigating factor against this behavior: the
cost of a support call.

> 12) Device implementation of random numbers. The draft discusses management 
> of 
> time in a drop ship device, but what about the management of random numbers? 
> For
> example, what if poorly manufactured devices always generated the same nonce,
> or a predictable nonce?

Then we have bigger fish to fry.  The device's crypto is broken.

> 13) Device individualization. The drop ship model assumes that devices are
> shipped with factory default, but BRSKI also assumes that devices come with
> individuals ID and certificate. This requires a specific per device step in
> the manufacturing process. Some makers of inexpensive devices don't do that,
> and ship devices that are all strictly identical. How does that affect the
> BRSKI process?

It's a prerequisite, so...
> 14) Privacy considerations. Third parties will be able to observe traffic
> between domain registrar and service provider MASA. They will at a minimum
> be able to learn that domain X is a customer of provider Y. Can they do more?
> The 

Re: [Anima] Benjamin Kaduk's Discuss on draft-ietf-anima-autonomic-control-plane-16: (with DISCUSS and COMMENT)

[Eliot Lear]

Hi Ben,

With apologies to the WG for adding a late comment. 

On 02.08.18 02:30, Benjamin Kaduk wrote:
> In particular, in its current form, it's not clear to me why this document
> is targeting the standards-track -- there are lots of places where
> determinations of what works best or how to do some things is left for
> future work.  Are there lots of implementations or consumers clamoring for
> this stuff that it makes sense to go for PS as opposed to Experimental (so
> as to figure out what works and nail down a slimmer protocol for the
> standards track)?  I see in A.4 that the choice of RPL was motivated by
> experience with a pre-standard version of ACP; it would have been great to
> hear more about those deployments in an Implementation Status section (per
> RFC 7942) or the Shepherd writeup.

FWIW I do not think experimental is appropriate.  Experiments have
beginnings and endings, and exit conditions.  Nor for PS should an
implementation report be required (quite the opposite).  I think PS is
more appropriate.  This is a pretty big document, and it is
architectural in nature, and there are multiple building blocks in this
document.  How they fit together may change based on operational
experience, and to me that means that a future revised PS of this
document would be considerably firmer.  To require that everything be
spelled out for this PS would be a bit much.

On the other hand, there are no fewer than *44* uses of the word
"future" prior to the appendices.  Some of this is a certain writing
style for a general architecture, but at the end of the day
I was left wondering whether
https://tools.ietf.org/html/draft-thomson-use-it-or-lose-it-01 should be
taken to heart in this instance.  In particular, the following stands
out to me:

>   "rsub" is optional; its syntax is defined in this document,
>but its semantics are for further study.  Understanding the benefits
>of using rsub may depend on the results of future work on enhancing
>routing for the ACP.

Why define rsub now if it has no semantic value?  Is that the garnish
that nobody eats?

I see three different things going on in this document:

  * Some real future proofing with extension mechanisms.
  * Some implicit and explicit forward references to work that is a bit
behind this work.  I think the purpose of this text is to justify
particular functionality as fulfilling some envisioned dependency.
  * Stuff like the above that doesn't seem well justified.

The big concern with all of this is when an extension is used on one
system and no by another, will there be interoperability problems? 
Especially as relates to ACP domain membership.  I don't have a good
feel for that in a few of these cases.

Eliot




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

Re: [Anima] Revision of scope of MASA in the BRSKI - Reg

[Eliot Lear]

Hi Toerless,


On 15.07.18 09:19, Toerless Eckert wrote:
> Note also that we have not defined cloud-registrar behavior. I
> think Eliot wold jus like to add something like WiFi SSID to
> vouchers, but i would rather like to see it as a separate
> "next-step after enrolment" message

There is an ordering problem with 802.11 in particular.  In order to get
the voucher one has to have network connectivity.  In order to have
network connectivity, one needs to be authenticated (e.g., having
received the voucher).  An EAP method seems like a good way to break
that logjam, especially in environments where EAP is already prevalent,
and TEAP has many of the characteristics that are already amenable to
BRSKI.  As to SSID selection, the principle issue is some sort of proof
of ownership to the device.  A blind acceptance solely by a MASA is what
causes our issue.  If we can accept that problem statement, then we have
multiple paths we can take to avoid a deadlock.

There are a few constraints:

  * In an environment with many SSIDs advertised, one doesn't want to
simply round robin, due to power consumption.  Some sort of shortcut
is desirable.
  * The discovery mechanism cannot be "chatty".  This is what Stewart
Cheshire calls the "Stadium Problem".  That is not to say that
devices must be entirely quiescent all the time.

Finding the right balance here is the trick.

Eliot



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

Re: [Anima] Revision of scope of MASA in the BRSKI - Reg

[Eliot Lear]

Brian, is it your contention that 802.11 is beyond the scope of
autonomic computing?


On 14.07.18 01:34, Brian E Carpenter wrote:
> On 13/07/2018 21:26, Owen Friel (ofriel) wrote:
>> I think its more accurate to state:
>>
>> “What a CUSTOMER wants to avoid is a pledge joining a network where the MASA 
>> just does the logging and does no validation, without any other means to 
>> determine that the device is on the correct network.” E.g. I plug in a wi-fi 
>> device and it connects to the SSID of the company on the floor below me.
> That is so far outside the scope of the autonomic networking infrastructure
> application of BRSKI that I don't see why we'd even mention it. It's a case
> that definitely needs to fail hard in the autonomic context.
>
> If we want to extend the scope of BRSKI to cover BYOD on insecure WiFi, I
> think that's for some other WG.
>
>Brian
>
>> The MASA cannot help with this unless there is complex sales channel 
>> integration and the MASA explicitly knows in advance exactly what network 
>> each pledge will be connecting to. A potential option is to also require the 
>> registrar to provide some proof of ownership to the MASA in the 
>> VoucherRequest.
>>
>> From: Anima  On Behalf Of Eliot Lear
>> Sent: Thursday 12 July 2018 17:38
>> To: Michael Richardson ; anima@ietf.org
>> Subject: Re: [Anima] Revision of scope of MASA in the BRSKI - Reg
>>
>>
>> The problem is that the manufacturer doesn't have enough context to make 
>> decisions as to which network to join.  That is the challenge.
>>
>> On 12.07.18 17:12, Michael Richardson wrote:
>>
>>
>>
>> Eliot Lear <mailto:l...@cisco.com> wrote:
>>
>> > involved. What a manufacturer wants to avoid is a pledge joining a
>>
>> > network where the MASA just does the logging and does no validation,
>>
>> > without any other means to determine that the device is on the
>>
>> > correct network. Otherwise, the pledge (we could call it the
>>
>> > "station" in this context) could simply home to the wrong network,
>>
>> > and even resetting the device won't get you to the right network.
>>
>>
>>
>> I don't understand how the "manufacturer" can have a desire ("the pledge
>>
>> avoid joining a network ...") that is different from the MASA's desire.
>>
>>
>>
>> The MASA *is* the expression manufacturer's desire.
>>
>> If the manufacturer has sales channel information that indicates the Pledge
>>
>> is on the wrong network, it should not issue a voucher.
>>
>>
>>
>> So the situation you describe makes no sense to me.
>>
>>
>>
>>
>>
>>
>> ___
>>
>> Anima mailing list
>>
>> Anima@ietf.org<mailto: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




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

Re: [Anima] Revision of scope of MASA in the BRSKI - Reg

[Eliot Lear]

Hi Toerless,


On 10.07.18 10:35, Toerless Eckert wrote:
> Thanks Eliot
>
> Very interesting, but can you explain why you think this is in the
> same ballpark as the issue Anoop raised ?

Yes, the reason I mentioned this is that it seems like we may want some
additional authentication mechanism, such as proof of knowledge *on top*
of the voucher model – in some cases.  This might involve labeling/BoM
aspects.  Also, where the MASA lives is an interesting question.  From
the AN perspective, at least to me, what is important is that the
mechanism be tightly bound in terms of what code needs to be written,
maybe with a few compile-time options.
>
> More inline.
>
> On Tue, Jul 10, 2018 at 08:43:30AM +0200, Eliot Lear wrote:
>> Hi Toerless,
>>
>> When we look at this scenario, we should consider several factors:
>>
>>   * The manufacturer is in a position to control both the MASA and the
>> pledge.  That's useful because it means that there is less
>> interoperability friction if the manufacturer wants to pass
>> additional parameters between the pledge and the manufacturer, so
>> long as the registrar doesn't interfere.
> Haha. I am not sure you want to mention "interoperability friction"
> in a venue whose purpose in life is interoperability (IETF). 
> We discussed during BRSKI design this aspect, and i think
> we can all see good flexiblity reasons for this side-channel, even
> without having to blame ineroperability.
>
> The main issue is that it is a side-channel, and if there is any concerns
> about BRKI it is the mistrust against manufacturers. SO i would hope that
> any use of the side-channel would allow to establish the ability on
> the registrar to passively analyze/observe that side-channel.

Yes, that is an argument for documentation, and maybe some authorization.

>
>>   * In WiFi we have two additional issues: a device needs to do ANIMA,
>> but it needs to be authorized in some manner to do so. 
> You mean we have the issue of getting initial 802.11 credentials to the
> pledge ? If not, then i didn't understand this bullet point.

Yes.
>
>>   * The second issue is one of network selection.  There is a need for
>> the pledge to really *know* that this is The network when 802.11 is
>> involved.  What a manufacturer wants to avoid is a pledge joining a
>> network where the MASA just does the logging and does no validation,
>> without any other means to determine that the device is on the
>> correct network.  Otherwise, the pledge (we could call it the
>> "station" in this context) could simply home to the wrong network,
>> and even resetting the device won't get you to the right network.
> Right. BRSKI is called zero-touch, but there is really one touch left:
> plugging a network cable into a right network port. With WiFi this can
> be automated because selecting the right SSID can be done without
> a human touch. I just wonder how we call it when we take one more touch
> away. BRSKI double zero (with a license to kill) ?  ;-))

Well, that is the work to be done.  Someone else should name the
solution, given how good I am at naming.
>
>> Owen will present something in Montreal that begins the discussion of
>> these issues.
> Great.
>
Eliot


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

Re: [Anima] Revision of scope of MASA in the BRSKI - Reg

[Eliot Lear]

Hi Toerless,

When we look at this scenario, we should consider several factors:

  * The manufacturer is in a position to control both the MASA and the
pledge.  That's useful because it means that there is less
interoperability friction if the manufacturer wants to pass
additional parameters between the pledge and the manufacturer, so
long as the registrar doesn't interfere.
  * In WiFi we have two additional issues: a device needs to do ANIMA,
but it needs to be authorized in some manner to do so. 
  * The second issue is one of network selection.  There is a need for
the pledge to really *know* that this is The network when 802.11 is
involved.  What a manufacturer wants to avoid is a pledge joining a
network where the MASA just does the logging and does no validation,
without any other means to determine that the device is on the
correct network.  Otherwise, the pledge (we could call it the
"station" in this context) could simply home to the wrong network,
and even resetting the device won't get you to the right network.

Owen will present something in Montreal that begins the discussion of
these issues.

Eliot

On 10.07.18 08:29, Toerless Eckert wrote:
> Anoop:
>
> To rephrase from Michaels reply: 
>
> You do not need any BRSKI protocol or voucher changes to do what you want.
>
> The pledge simply needs to locate the voucher locally, and when it
> connects to the registrar, it can skip the step of retrieving
> the voucher because it already does trust the registrar
> as it has the voucher locally.
>
> In fact, you can even use RFC7030. If you already have a voucher locally,
> you do not need BRSKI for voucher signalling. IMHO, you still want
> BRSKI (instead of just RFC7030) because of the proxy and the
> enrolment telemetry.
>
> This just leaves the whole painfull question Michael brings up:
>
> "how the heck do we get vouchers onto devices in the real world" ?
> This is IMHO where everybodies favourite options for managing
> "offline vouchers" come into play. There are a lot of vendor
> solutions where you feed those nodes information such as vouchers
> via USB sticks, or temporarily connected cellphones to the pledge. 
>
> I think those solutions are not ideal because they do introduce
> another new "touch" to the pledge. But there are also simply
> a lot of options how to get the voucher into the registrar
> without having to use an online BRSKI-MASA connection. And then you
> just need to send the voucher from the registrar to the pledge
> using BRSKI: No new "touch" on the pledge, no BRSKI-MASA
> connection!
>
> The BRSKI document does allude to these options but does not
> necessarily detail them well enough for every uninitiated reader
> to understand the options. Followup documents refining individual
> interesting workflows would certainly be useful
> IMHO (contributor, not WG chair hat on).
>
>
> Cheers
> Toerless
>
>
> On Sat, Jul 07, 2018 at 02:58:52PM -0400, Michael Richardson wrote:
>> Anoop Kumar Pandey  wrote:
>> > When a device is purchased in real world, usually an invoice is issued 
>> in the
>> > name of the purchaser with stamp of vendor/manufacturer.
>>
>> > I propose that similarly, a digital invoice can be issued which will 
>> contain
>> > the public key(s) of the  and digitally signed 
>> by the
>> > manufacturer. The digital invoice may be embedded in the pledge along 
>> with
>> > the IDevID.
>>
>> That's an interesting idea, perhaps you could write it up in the form of an
>> Internet-Draft?  Then I could make sure that I fully understand your
>> proposal.
>>
>> It seems very difficult to make digitally signed invoices occur in the real
>> world, given the constrained of the supply chain.  Still, BRSKI makes
>> provisions for higher security if the supply chain is integrated.
>>
>> I once proposed something similar using signed certficates:
>>   
>> https://mailarchive.ietf.org/arch/msg/6tisch-security/2kObJLkLlhuI-HU9s5yqfRm0n00
>>
>> In effect, the voucher artifact that we created in RFC8366 replaces these
>> certificates with purpose built signed artifacts that expresses what the
>> invoice attempts to express.
>>
>> > When a pledge starts the registration process, it will present the 
>> digital
>> > invoice along with IDevID. The JRC can verify the digital signature of 
>> the
>> > manufacturer on the digital invoice and sent a signed note of 
>> acceptance to
>> > the pledge. The pledge can verify the signed note using the public 
>> key(s)
>> > mentioned in the digital invoice, thereby verifying its true owner.
>>
>> A pledge which has sat in a warehouse for a year before being sold to an
>> owner will not have the invoice on it yet.  That's okay, because the invoice,
>> being digitally signed, could be retrieved from another place, and that's
>> effectively what the BRSKI-MASA protocol *does*.
>>
>> If the invoice needs to be loaded into the Pledge via a 

Re: [Anima] references to code ? (was: Re: WG Last Call on draft-ietf-anima-bootstrapping-keyinfra-15)

[Eliot Lear]

On 31.05.18 20:43, Toerless Eckert wrote:
> Thanks, Eliot
>
> Good point, forgot to ask/mention this point in my previous emails.
>
> As an ANIMA contributor, i would love for a draft/->RFC like BRSKI to
> mention known existing implementations, especially open source, even if just 
> PoC. 
>
> But i have no idea if and/or how thats seen to be appropriate by IETF
> standards. Traditionally i think it was not done, but then again,
> with the amount of focus (not to say hype ;-) the IETF does around
> open source and hackathons, it almost sounds absurd to me not to mention such 
> code.
>
> I am only aware of github.com/cisco/libest, but would love to see
> any known code be mentioned. Single sentence with references to
> appropriate URLs to those implementations would suffice IMHO.
> What do others think/know about BCP in IETF protocol RFC re such mentioned of 
> known code ?

I don't mind that pointer being listed, though we should *always* check
with the code developers before doing so.  In this case we can check
with them to be sure.

The 2nd piece of code is not open source and not by Cisco.

Eliot


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

Re: [Anima] WG Last Call on draft-ietf-anima-bootstrapping-keyinfra-15

[Eliot Lear]

I have reviewed the document and we have a PoC.  I am also aware of
others that have done PoC code. I am not aware of any issues.

Eliot


On 31.05.18 03:56, Toerless Eckert wrote:
> Dear ANIMA WG,
>
> After thorough review and discussions on the mailing list and in bootstrap
> meetings, leading to the -15 version the authors and WG chairs think the draft
> is now mature enough for working group last call.
>
> This e-mail starts a two-weeks period for evaluation of this document by the 
> WG.
>
> Please provide your feedback on the ANIMA mailing list by end of June 14th, 
> 2018.
>
> Thanks and best regards
>
> Toerless (for the ANIMA chairs).
>
> ___
> Anima mailing list
> Anima@ietf.org
> https://www.ietf.org/mailman/listinfo/anima
>




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

Re: [Anima] Shepherd review draft-ietf-anima-bootstrapping-keyinfra-09

[Eliot Lear]

Hi,

I'm not Max but I hope you won't mind me commenting in three places:


On 02.03.18 23:59, Michael Richardson wrote:

> Section 2.1
>> a) The term "Request Join" is only used here, and its IMHO not very logical
>> (disclaimer: toerless: en.wikipedia.org/wiki/ESL). It sounds to me like the
>> pledge says "i want to join". And also sounds as if the pledge could be
>> disappointed if rejected. I would rather call it "Domain membership inquiry".
>> Or if you're hooked up on the term "joining", then maybe "Join Inquiry".
> QUESTION?  what do you think?
> Was "Request Voucher" one of the options you were thinking about?

I would very much prefer that we not use "Domain membership inquiry". 
If a change is necessary, I would prefer "Join Inquiry", to avoid
introducing ambiguities about domains.
>
>> Whatever best makes it clear that rejection is a perfect and important
>> outcome option.
>>
>> b) Please see my issue section 5.1 a). If you agree with that statement, 
>> then there
>> should be no "rejected" arrow in Figure 2 coming out of the "Identify"
>> block.
> okay, I'll deal with this in that section.
>
>> I would also suggest that the "Bad Vendor response" arrow does not come out
>> of the "Imprint" block but out of the "Request Join" block. AFAIK, this is
>> an error reply to the Request Voucher, so it happens before imprinting
>> (imprinting happens only when there is a vocker reply. AFAIK).
> [It says, "Bad MASA response" now, just for the reader who is following]
>
>> I don't think "Bad Vendor reply" in Figure 2 is a good term. Most logical
>> to me would
>> be "Error or not member". In any case, the text in section 2 below should
>> mention the exact words used on the labels, the text is missing ll the
>> labels on the left: "Factory reset", "Enroll Failure", "Bad Vendor
>> response",...
> more discussion.
>
>> c)
>>
>>  Point 1 nicely explains how this is done during TLS.
>>
>> Likewise, Point 2 should mention that this is the "Voucher Request", and
>> Point 3 should mention that it is the "Voucher Reply" - so readers can match
>> up section 2.1 with the rest of the document.
>>
>> remove the "e.g." from "protocol, e.g. Enrollment over". Otherwise some text
>> outlining when something else than EST is to be used. (see next comment).
> QUESTION: I couldn't figure out what text this applies to.

I can't be sure.  I think Toerless may be referring to both the Diagram
and the text in Section 2.1, as compared to, say, Figure 3 in Section
2.4.  I think the main change, IMHO is Figure 3, just to change
<---voucher--- to <---voucher reply--.

???

>
>> d)
>>
>> I am missing in the initial chapters a succinct summary how EST enrollment 
>> is optional and
>>  what can be achieved with/without it, there is only some side sentences 
>> later in the
>> EST sections. I would suggest to insert such an explanation here.
>>
>> After point 4 insert (unnumbered) paragraph:
>>
>> | After step 4, the pledge has received  and authenticated an explicit TA 
>> (trust anchor)
>> | (pinned-domain-cert in the Voucher response). In some use cases this may 
>> be sufficient
>> | and the bootstrap can be terminated here. The pledge can now use this TA 
>> to securely
>> | trust domain members, but it can not securely identify itself to them as a 
>> domain member.
>> | Therefore BRSKI usually proceeds with the following steps that support 
>> this via EST
>> | enrollment (see also 5.5.1 for the limitations of the trust feasible 
>> through the imprint).
>>
>> Also maybe insert some dotted line between imprint and enroll in Figure 2 to
>> highlight this distinction. Maybe with "mandatory" / "optional" (EST enroll 
>> part)
>> on the right hand side
> QUESTION: Max?

If it is just a dotted line, ok.  But then use text at the beginning of,
or just before, Step 5 to indicate that the step is optional.

Regards,

Eliot



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

Re: [Anima] BRSKI over 802.11

[Eliot Lear]

Hi Toerless,

On this point:

On 14.02.18 17:56, Toerless Eckert wrote:
> Aka: selecting the best SSID in face of competing offers
> multiple or single AP is the type of work i think we should
> give some tthought to. Ideally something extensible
> where we can in the first spec get away with a most simple
> start but will have forward compatibility with later 
> updates/extensions.

+1.  And I think this needs to be a pretty broad discussion.  We need to
sort, at least in our own minds, at what layer to solve what problem,
and how to do that without driving end users and administrators
absolutely crazy.

Eliot




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

Re: [Anima] BRSKI over 802.11

[Eliot Lear]

Hi Bing,

I think you've got it down, but I want to stress that these are early
days, and I could, perhaps easily, be convinced to go another way.  I
think Michael is trying to do that ;-)  I think the question is this: in
a WiFi environment how can the device know which network to connect with
in the first place, and how does it then send packets to complete the
BRSKI flow?

As a difficult use case, consider a business in an office building on
the 10th floor in New York City or London, where you might hear 2 dozen
different networks.

Eliot


On 11.02.18 10:16, Liubing (Leo) wrote:
> Hi Michael, Eliot and all,
>
> A clarification question: it sounds like there are two approaches proposed, 
> not sure I understood it correctly:
>
> Michael's proposal: there is a dedicated SSID, say "Anima", it is enabled by 
> default, and there is no security. And that SSID can only do BRSKI, no other 
> services permitted (just like the http portal authentication). After getting 
> the certificate, then certificate-based EAP could be run to do the 802.1x 
> authentication; or maybe they just negotiated a key for WPA2. In this case, 
> the BRSKI just works as the bootstrap of WiFi.
>
> Eliot's proposal: we'll have a new EAP method, say "EAP-BRSKI", just treat 
> BRSKI as an option encapsulated in EAP protocol, under the WiFi access 
> framework.
>
> Michael and Eliot: did I get you correctly?
>
> B.R.
> Bing
>
>> -----Original Message-
>> From: Anima [mailto:anima-boun...@ietf.org] On Behalf Of Eliot Lear
>> Sent: Thursday, February 08, 2018 5:51 PM
>> To: Artur Hecker <artur.hec...@huawei.com>; anima@ietf.org
>> Subject: Re: [Anima] BRSKI over 802.11
>>
>> Artur,
>>
>> I suspect much – but not all – of this could be addressed in EAP.
>>
>> Eliot
>>
>>
>> On 08.02.18 10:24, Artur Hecker wrote:
>>> Hi Michael
>>>
>>>
>>> Sorry, maybe I misunderstood the intention. Is your intention to make it
>> "standard" or just to make a demonstration? If the latter, then it's OK. 
>> It's the
>> first that I simply doubt it will work.
>>> I am not claiming that there are better means to do that, let alone that 
>>> what
>> you proposed makes no sense. I actually said that this makes sense. I just 
>> think
>> that we enter the realms of 802.1 and 802.11 at the same time and have no
>> authority there.
>>> It has indeed nothing to do with Wireless access points. Any STA (802.11) 
>>> and
>> any supplicant (802.1X) is subject to standardization and regulation of the 
>> bodies
>> of IEEE, in any mode of operation. WPS should not be limited to any Access
>> Point presence, since it supports WiFi Direct. I agree, the supported 
>> methods are
>> rudimentary. If I remember correctly, something like PIN, the push button you
>> mentioned, NFC and USB.
>>> I guess, a possibility would be to specify an additional ANIMA/ACP/BRSKI
>> method for WPS, why not. All I am saying is that we probably need to do it 
>> there,
>> as any try to do it in the ANIMA WG would require specific 802.11 modes and
>> specific 802.1X functions/behaviours, which I am not sure we can dictate to
>> have.
>>>
>>> Regards
>>> artur
>>>
>>>
>>>
>>>> -Original Message-
>>>> From: Michael Richardson [mailto:mcr+i...@sandelman.ca]
>>>> Sent: 07 February 2018 20:07
>>>> To: Artur Hecker <artur.hec...@huawei.com>
>>>> Cc: anima@ietf.org
>>>> Subject: Re: [Anima] BRSKI over 802.11
>>>>
>>>>
>>>> Artur Hecker <artur.hec...@huawei.com> wrote:
>>>> > Hi Michael,
>>>> > My opinion:
>>>>
>>>> I don't think understood the question :-)
>>>>
>>>> 1) It's not about Wireless Access Points, so all of the Wifi Alliance,
>>>>etc. talk makes no sense to me.  There can be no access points until 
>>>> they
>>>>have been configured.  It's possible that there might NEVER been any
>>>>access points, because the operator actually doesn't want/need any
>>>> enabled.
>>>>Think about inside of a cage in a data center.
>>>>
>>>> 2) It's about *devices* that have 802.11 interfaces.
>>>>You can't use WPS or anything else involving 802.1x until you have
>>>>credentials, which is what BRSKI gets you.
>>>>So you can't use WPS to *bootstrap* WPS.
>>>>(and pushing buttons on the front of the

Re: [Anima] BRSKI over 802.11

[Eliot Lear]

Artur,

I suspect much – but not all – of this could be addressed in EAP.

Eliot


On 08.02.18 10:24, Artur Hecker wrote:
> Hi Michael
>
>
> Sorry, maybe I misunderstood the intention. Is your intention to make it 
> "standard" or just to make a demonstration? If the latter, then it's OK. It's 
> the first that I simply doubt it will work.
>
> I am not claiming that there are better means to do that, let alone that what 
> you proposed makes no sense. I actually said that this makes sense. I just 
> think that we enter the realms of 802.1 and 802.11 at the same time and have 
> no authority there.
>
> It has indeed nothing to do with Wireless access points. Any STA (802.11) and 
> any supplicant (802.1X) is subject to standardization and regulation of the 
> bodies of IEEE, in any mode of operation. WPS should not be limited to any 
> Access Point presence, since it supports WiFi Direct. I agree, the supported 
> methods are rudimentary. If I remember correctly, something like PIN, the 
> push button you mentioned, NFC and USB.
>
> I guess, a possibility would be to specify an additional ANIMA/ACP/BRSKI 
> method for WPS, why not. All I am saying is that we probably need to do it 
> there, as any try to do it in the ANIMA WG would require specific 802.11 
> modes and specific 802.1X functions/behaviours, which I am not sure we can 
> dictate to have.
>
>
> Regards
> artur
>
>
>
>> -Original Message-
>> From: Michael Richardson [mailto:mcr+i...@sandelman.ca]
>> Sent: 07 February 2018 20:07
>> To: Artur Hecker 
>> Cc: anima@ietf.org
>> Subject: Re: [Anima] BRSKI over 802.11
>>
>>
>> Artur Hecker  wrote:
>> > Hi Michael,
>> > My opinion:
>>
>> I don't think understood the question :-)
>>
>> 1) It's not about Wireless Access Points, so all of the Wifi Alliance,
>>etc. talk makes no sense to me.  There can be no access points until they
>>have been configured.  It's possible that there might NEVER been any
>>access points, because the operator actually doesn't want/need any
>> enabled.
>>Think about inside of a cage in a data center.
>>
>> 2) It's about *devices* that have 802.11 interfaces.
>>You can't use WPS or anything else involving 802.1x until you have
>>credentials, which is what BRSKI gets you.
>>So you can't use WPS to *bootstrap* WPS.
>>(and pushing buttons on the front of the AP is by definition not "zero-
>> touch")
>>
>> > Q3: Sorry, I did not quite understand this one. If you meant the ad-hoc
>> > essid based network, my first intuition would be to object, as I
>> > believe that we should not prescribe such modes for ACP, but rather use
>> > the best available one.
>>
>> 3) The ACP is secured inside IPsec over Link-Layer IPv6 (or MACSEC, or
>>a bunch of other possible technologies in the ACP document).
>>It's not about the security of the ACP.
>>
>> Since the point of the ACP is that it's always available, it needs to be 
>> available
>> even when the Wifi Access Point is toast or not yet configured.
>> Of course, once there is a non-adhoc/IBSS network available, the ACP would
>> see this as additional interfaces and make additional mesh links across it 
>> for
>> the ACP to use.  But that's not bootstrap, that's operation.
>>
>> > Q4: As I believe that Q2 is strongly biased, I believe that so is
>> > Q4. The WiFi Alliance already specifies several ways how to bootstrap
>> > wireless access points, including e.g. WPS. We would rather need to
>> > see, how to integrate with such means. And again, I don't believe we
>> > have authority on that.
>>
>> Maybe you could point to specific documents that would permit two devices
>> which have never been touched to communicate over 802.11 without
>> configuration.
>>
>> --
>> Michael Richardson , Sandelman Software Works
>> -= IPv6 IoT consulting =-
>>
>>
> ___
> Anima mailing list
> Anima@ietf.org
> https://www.ietf.org/mailman/listinfo/anima
>




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

Re: [Anima] early allocation for draft-ietf-anima-voucher

[Eliot Lear]

+1.


On 12/5/17 4:29 PM, Michael Richardson wrote:
> Benoit, draft-ietf-anima-voucher asks for an OID arc:
> 8.3.  The SMI Security for S/MIME CMS Content Type Registry
>
> We'd like to do an early allocation for this OID value so that we can update
> our examples earlier rather than later.
>
> --
> Michael Richardson , Sandelman Software Works
>  -= IPv6 IoT consulting =-
>
>
>
>
>
> ___
> Anima mailing list
> Anima@ietf.org
> https://www.ietf.org/mailman/listinfo/anima



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

Re: [Anima] two EST question/suggestions

[Eliot Lear]

On 9/12/17 10:03 PM, Brian E Carpenter wrote:
> On 13/09/2017 02:33, Eliot Lear wrote:
>> Hi,
>>
>>> I agree a statement that HTTP2 etc is ok so long as it doesn’t change the 
>>> possible client state machine…  ?
>> You need an MTI, and it should be the easiest and most compact thing to
>> implement.  While CoAP would be optimal, HTTP/1.1 is more than
>> sufficient, and the features in 2 in this case are not only unnecessary,
>> but undesirable overhead.
> I am a bit bothered by the assumption that all devices of interest can be 
> assumed
> to include X, for whatever value of X we deem to be MTI. Or are you only
> intending MTI to apply at the server end?

Hmm.  Actually, I don't like my own text precisely for the reason you
state.  But I do think we don't want to create a plethora of choices. 
There is an interoperability issue here that has to be addressed.

>
> It seems to me that we want to minimise the requirements for low end pledge
> devices, and every item that we make mandatory works against that.
>
> 

Right, but we need to have something there.

Eliot




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

Re: [Anima] two EST question/suggestions

[Eliot Lear]

Hi,

> I agree a statement that HTTP2 etc is ok so long as it doesn’t change the 
> possible client state machine…  ?

You need an MTI, and it should be the easiest and most compact thing to
implement.  While CoAP would be optimal, HTTP/1.1 is more than
sufficient, and the features in 2 in this case are not only unnecessary,
but undesirable overhead.

Eliot



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

Re: [Anima] What is intent ?

[Eliot Lear]

Hi Toerless,

I've heard MUD called a form of intent, but it's not a perfect fit.  MUD
expresses needs rather than intent.  That is- "I need the network to
allow X."  One could *infer* an intent, but but such inferences get
riskier the higher up the stack one goes.  In your case, though, one
could extend the MUD file to describe the need for a VPN, so long as the
parameters of that VPN are well understood in the terms of the MUD
abstractions at the time of manufacturer ("my-controller",
"same-manufacturer", etc).

As a formalism between ANIs, MUD is not the droid you're looking for, as
currently scoped.

Eliot


On 7/25/17 10:34 PM, Toerless Eckert wrote:
> I have an autonomic network, and i want for another customer another
> L3VPN service instance in it.  How would i tell the network that i want
> this ? Via intent or via something else ?
>
> If it is something else, what is it ? I do not see any other information flow 
> from
> operator to network beside intent in RFC7575 or 
> draft-ietf-anima-reference-model. 
> Maybe i am missing something.
>
> If it is intent, how would it look like ? Could it simply be a definition
> of an L3VPN service instance in the model defined in rfc8049 ? If not, why 
> not ?
>
> IMHO: Intent in ANIMA includes service definitions such as what rfc8049 is,
> except that we would reserve the right to eliminate all parameters of rfc8049
> for which we figure out autonomic ways to determine them. Which alas seems to
> be quite difficult for most parameters. 
>
> Other folks in the IETF clearly think that a service definition is NOT intent,
> but intent can only be some yet unclear high level policy. If thats the
> prevailing opinion/wisdom in the IETF, then IMHO we need to be more explicit 
> about the
> fact that Intent is not the only input into the network but that there is
> also other input. Such as services. And anything else that people do not want 
> to
> call Intent.
>
> Lets assume service and other necessary data operator->network should not
> be called intent. But lets say the superset of intent + services + everything
> else is called eg: "information". I think that draft-du-anima-an-intent
> would equally apply to all information we would want to distribute into
> an autonomic network. 
>
> Cheers
> Toerless
>
> ___
> Anima mailing list
> Anima@ietf.org
> https://www.ietf.org/mailman/listinfo/anima
>




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

Re: [Anima] Is this how BRSKI/IPIP works?

[Eliot Lear (elear)]

Sure. Use normal unicast addresses (ULA or other) if available. 

Eliot

> On Jul 17, 2017, at 9:39 AM, Toerless Eckert <t...@cs.fau.de> wrote:
> 
> Can you propose a stateless proxy model that would not pass the link-local
> addresses on to the registrar and that uses Michaels beloved IPinIP encap ?
> 
> Alas i have fallen in love with UDP encap because i like to see more
> networking software now be build like any othrer application on top of
> UDP/TCP APIs and not mess around with OS kernel features, so all
> my answers would be "the proxy is an app that either statefully proxies TCP
> or stateless proxies UDP".
> 
> If you want to statelessly proxy TCP and on the registrar use some existing 
> TCP stack, then i would begrudgingly agree with Michael, that i also need some
> kerne level handling of the encap so that i get kernel level TCP.
> 
> I am still waiting for some better explanation from Michael about the
> "Linux kernel and overlapping TCP" to fully understand his proposal.
> 
> So, here is one proposal for IPinIP using the current -07 draft ULA 
> addressing:
> 
> A) We assign one of the 8 (3 bit) "T"ype codes to "Subnet Identifier for 
> Encap".
> 
> B) The proxy allocates a separate "Zone" number for every subnet. Zone = 
> Subnet.
>In result it now has for every subnet a separate ULA address for the 
> IPinIP encap.
> 
> C) The registrar announces its ability to support IPinIP BRSKI via GRASP
> 
> D) Each ACP device need to use its ACP DeviceID also as the host-part of its
>link-local address.
> 
> E) The proxy as part of its tunnel functionality also assigns itself the 
> Registrar
>link local address on every subnet. At least logically. Whether it really 
> needs
>to do this physcially is implementation specific.
> 
> F) The proxy announces via GRASP BRSKI-IPIP with the Registrar Link-Local 
> address
>(which it can do because according to E) it owns it on its subnets - GRASP
> DULL does not permit third-party announcements, so E) is to make it legal 
> for
> the proxy to announce this in GRASP).
> 
> G) Any packets sent by pledges to the Registrar link-local address are IPinIP
>encapsulated using the "Subnet Identifier for Encap" as the source IP 
> address and
>the Registrar ULA as the destination address.
> 
> H) The registrar can create a separate IPinIP tunnel per remote proxy, 
> per-subnet-on-proxy.
>It does not need further addresses.
> 
> Some more details might be needed, eg:
> - If a proxy has more than 2^13 interfaces it needs to dynamically allocate
>   subnet encap addresses.
> - A proxy might want to map different subnets to differen registrars for load 
> balancing.
> 
> Cheers
>Toerless
> 
>> On Mon, Jul 17, 2017 at 08:54:46AM +0200, Eliot Lear wrote:
>> On the other hand, maybe it's fundamental, but is relying on LL in this
>> architecture to go beyond LL boundaries the right thing to do?
>> 
>> 
>>> On 7/17/17 8:34 AM, Michael Richardson wrote:
>>> Toerless Eckert <t...@cs.fau.de> wrote:
>>>> I thought i had asked that question already but not sure, and not seen
>>>> an answer: - I have never seen that a device has more than one
>>>> link-local addr on an interface.  Is this permitted by IPv6 arck ? Can
>>>> you configure this in eg: Linux. I thought i tried on linux/cisco-ios
>>>> in the past and i do not quite remember, but i think it failed (only
>>>> one address).
>>> 
>>> dooku-[~](2.3.0) mcr 10879 %sudo ip -6 addr add fe80::1234/64 dev wlan0
>>> 
>>> dooku-[~](2.3.0) mcr 10788 %ifconfig wlan0
>>> wlan0 Link encap:Ethernet  HWaddr 08:11:96:01:81:e0
>>>  inet addr:31.133.129.16  Bcast:31.133.143.255  Mask:255.255.240.0
>>>  inet6 addr: fe80::1234/64 Scope:Link
>>>  inet6 addr: fe80::a11:96ff:fe01:81e0/64 Scope:Link
>>>  UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
>>> 
>>> dooku-[~](2.3.0) mcr 10788 %ip -6 addr ls dev wlan0
>>> 3: wlan0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 state UP qlen 1000
>>>inet6 fe80::1234/64 scope link
>>>   valid_lft forever preferred_lft forever
>>>inet6 fe80::a11:96ff:fe01:81e0/64 scope link
>>>   valid_lft forever preferred_lft forever
>>> 
>>> 
>>> --
>>> ]   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  
>>>   [
>>> 
>>> 
>>> --
>>> Michael Richardson <mcr+i...@sandelman.ca>, Sandelman Software Works
>>> -= IPv6 IoT consulting =-
>>> 
>>> 
>>> 
>>> 
>>> 
>>> ___
>>> 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] Is this how BRSKI/IPIP works?

[Eliot Lear]

On the other hand, maybe it's fundamental, but is relying on LL in this
architecture to go beyond LL boundaries the right thing to do?


On 7/17/17 8:34 AM, Michael Richardson wrote:
> Toerless Eckert  wrote:
> > I thought i had asked that question already but not sure, and not seen
> > an answer: - I have never seen that a device has more than one
> > link-local addr on an interface.  Is this permitted by IPv6 arck ? Can
> > you configure this in eg: Linux. I thought i tried on linux/cisco-ios
> > in the past and i do not quite remember, but i think it failed (only
> > one address).
>
> dooku-[~](2.3.0) mcr 10879 %sudo ip -6 addr add fe80::1234/64 dev wlan0
>
> dooku-[~](2.3.0) mcr 10788 %ifconfig wlan0
> wlan0 Link encap:Ethernet  HWaddr 08:11:96:01:81:e0
>   inet addr:31.133.129.16  Bcast:31.133.143.255  Mask:255.255.240.0
>   inet6 addr: fe80::1234/64 Scope:Link
>   inet6 addr: fe80::a11:96ff:fe01:81e0/64 Scope:Link
>   UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
>
> dooku-[~](2.3.0) mcr 10788 %ip -6 addr ls dev wlan0
> 3: wlan0:  mtu 1500 state UP qlen 1000
> inet6 fe80::1234/64 scope link
>valid_lft forever preferred_lft forever
> inet6 fe80::a11:96ff:fe01:81e0/64 scope link
>valid_lft forever preferred_lft forever
>
>
> --
> ]   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
> [
>
>
> --
> Michael Richardson , Sandelman Software Works
>  -= IPv6 IoT consulting =-
>
>
>
>
>
> ___
> Anima mailing list
> Anima@ietf.org
> https://www.ietf.org/mailman/listinfo/anima



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

Re: [Anima] Is this how BRSKI/IPIP works?

[Eliot Lear]

Hi Brian,


On 7/14/17 12:41 AM, Brian E Carpenter wrote:
>
> That may be true, but for BRSKI as such, the only hard requirement is
> an address that is unique on a given link, which is a requirement anyway.
> IPIP is more of an issue for the node providing the proxy, which is
> hopefully a bit upscale from a light switch.
>

I made my comment in the context of a possible interface collision in
your diagram.  Those had to do with the autonomic nodes, not the
proxies, as I understand things.  To avoid those sorts of collisions, it
seems like using the h/w address remains sensible.  A collision in those
circumstances would be extremely unlikely, whereas relying on poor PRNG
almost assures it of happening.  These devices are likely to have very
little entropy available to them.

Eliot



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

Re: [Anima] dealing with multiple manufacturer services with a single certificate extension

[Eliot Lear]

Hi Max,


On 4/24/17 5:52 PM, Max Pritikin (pritikin) wrote:
>
> I’ve been agitating for a combined form. My thanks to Eliot for
> continuing the conversation. Below I provide some details from the
> current BRSKI draft to flesh out the conversation and then present an
> argument for my position.
>
>> On Apr 23, 2017, at 5:23 AM, Eliot Lear <l...@cisco.com
>> <mailto:l...@cisco.com>> wrote:
>>
>> Hi everyone,
>>
>> Just a quick update on this document.  I am preparing for the next
>> version of the draft.  There is one major change contemplated that is
>> not yet addressed.
>>
>> I received feedback from the IETF Chicago meeting regarding how best
>> to structure URLs in manufacturer certificates.  There are currently
>> two planned, one for MUD and one for ANIMA/BRSKI.  The question is
>> whether these should be combined. 
>>
>> I had said in Chicago that I would ask various manufacturers about
>> whether additional complexity on the backend is worth saving the
>> bytes in the certificate.  There was, as you might imagine, a mixed
>> response.  A number of manufacturers answered, “No, and in fact we
>> want to do our own certificate extensions”.  Others simply answered
>> “No, the code requirements for ANIMA will probably make the cert
>> extension a relatively minimal matter”.  And some manufacturers,
>> said, “yes, every byte counts.”  I am proceeding in a way that
>> accommodates the 3rd group for now, but I seek discussion.
>>
>> If we combine the URLs the way it would work is that there would be a
>> service endpoint along the lines of the following:
>>
>>   * https://example.com/.well-known/mfg/modelname
>>
> Given that the .well-known concept is already well defined the
> approach taken in the BRSKI draft (s2.3) is to include only the
> “manufacturer” authority:
> https://example.com
>
> From here the relying party can use the .well-known constructs to
> access any variety of manufacturer services which I expect to include 
> https://example.com/.well-known/brksi
> https://example.com/.well-known/mud
> etc
>
> This minimizes the information stored within the certificate itself. A
> single extension indicating the “manufacturer services authority”.
> Building a full URL to these services is done using the .well-known
> method.

One challenge here is that we need model information present, and you
may need it as well to route to the correct BRSKI service (presuming
there is more than one for manufacturer example.com).  And so we would
need to add at least the model back, or otherwise reflect the model in
the authority section.  I'm not a big fan of requiring that because it
requires unnecessary interactions with DNS administration.

>> At that point, we would need to deference, introducing some
>> additional complexity somewhere in the system.  We should be mindful
>> of the following issue:
>>
>>  1. Versioning should be supported OUTSIDE of the referenced
>> service.  The more that is done, the more freedom the referenced
>> service has the ability to change.
>>  2. Versioning of services should not be done in lock step.  That is,
>> if we keep the versioning information in the URL, that means that
>> when the MUD version is bumped, so too would the ANIMA version. 
>> It is possible to keep a registry that would indicate URL
>> versioning and then map to all the different versions of whatever
>> is referenced, but that seems ridiculously complex.
>>  3. The resolution mechanism to services should be independent of how
>> the URL is gotten by the various {MUD/ANIMA/...} controllers. 
>> And thus, if a MUD controller receives the URL via LLDP or DHCP,
>> the same processing should occur as if it was received via a
>> certificate.  This simplifies code paths, and will hence reduce
>> risk of bugs.  It will also follow the principle of least
>> astonishment.
>>
>> It seems to me the simplest way to handle this sort of thing is to
>> create a table that MUD/ANIMA controllers simply download when they
>> see the URL.  It might look something like this:
>>
>> {
>>"mfg-services" : [ 
>>  "mud", "v1", "https://mud.example.com/Frobmaster3000.json;,
>>  "anima", "v1", "https://masa.example.com/masa-service;
>>]
>> }
> Using a .well-known to query a host about which possible interfaces
> are available has precedent. For an alternative example also see,
> https://tools.ietf.org/html/rfc6415
> "The client obtains the host-meta document 

[Anima] dealing with multiple manufacturer services with a single certificate extension

[Eliot Lear]

Hi everyone,

Just a quick update on this document.  I am preparing for the next
version of the draft.  There is one major change contemplated that is
not yet addressed.

I received feedback from the IETF Chicago meeting regarding how best to
structure URLs in manufacturer certificates.  There are currently two
planned, one for MUD and one for ANIMA/BRSKI.  The question is whether
these should be combined. 

I had said in Chicago that I would ask various manufacturers about
whether additional complexity on the backend is worth saving the bytes
in the certificate.  There was, as you might imagine, a mixed response. 
A number of manufacturers answered, “No, and in fact we want to do our
own certificate extensions”.  Others simply answered “No, the code
requirements for ANIMA will probably make the cert extension a
relatively minimal matter”.  And some manufacturers, said, “yes, every
byte counts.”  I am proceeding in a way that accommodates the 3rd group
for now, but I seek discussion.

If we combine the URLs the way it would work is that there would be a
service endpoint along the lines of the following:

  * https://example.com/.well-known/mfg/modelname

At that point, we would need to deference, introducing some additional
complexity somewhere in the system.  We should be mindful of the
following issue:

 1. Versioning should be supported OUTSIDE of the referenced service. 
The more that is done, the more freedom the referenced service has
the ability to change.
 2. Versioning of services should not be done in lock step.  That is, if
we keep the versioning information in the URL, that means that when
the MUD version is bumped, so too would the ANIMA version.  It is
possible to keep a registry that would indicate URL versioning and
then map to all the different versions of whatever is referenced,
but that seems ridiculously complex.
 3. The resolution mechanism to services should be independent of how
the URL is gotten by the various {MUD/ANIMA/...} controllers.  And
thus, if a MUD controller receives the URL via LLDP or DHCP, the
same processing should occur as if it was received via a
certificate.  This simplifies code paths, and will hence reduce risk
of bugs.  It will also follow the principle of least astonishment.

It seems to me the simplest way to handle this sort of thing is to
create a table that MUD/ANIMA controllers simply download when they see
the URL.  It might look something like this:

{
   "mfg-services" : [ 
 "mud", "v1", "https://mud.example.com/Frobmaster3000.json;,
 "anima", "v1", "https://masa.example.com/masa-service;
   ]
}

This sort of change would be required in both the ANIMA and MUD
services, but could then be used for any other manufacturer-based
service.  Is this what people want?  For MUD, this amounts to a simple
additional file retrieval.  For ANIMA, the same.  Then one simply
dereferences the table.  Most importantly, all implementations need to
be prepared to handle the case where a particular service is NOT listed
(this might seem like a big duh, but I figured I'd mention it).

Comments?

Eliot



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

Re: [Anima] CRLs in iDevID manufacturer signing certs?

[Eliot Lear]

Thanks, Kent.  Then it seems to me that we have a MAY floating around
for CRL checking on the part of the registrar for BRSKI.  Right?

Eliot


On 3/9/17 7:25 PM, Kent Watsen wrote:
> Hi Elliot,
>
>
>> What is the thinking on including CRL pointer in the manufacturer
>> signing cert?  This question came up in industry discussions.
> 802.1AR says that the IDevID secrets must be stored confidentially and be not 
> available outside the module.  In practice, a crypto processor with 
> tamper-resistant NVRAM is used (e.g., TPM).  As such, the likelihood of the 
> credentials being stolen/discovered are near zero, but it is not zero, as a 
> determined adversary with sufficient resources can still have their way with 
> it.  Still, vendors will likely conclude that protecting against that level 
> of attack isn't necessary.  That said, vendors face a more likely scenario, 
> of issues occurring by contract manufacturers, whether it be accidental or 
> intentional.  And as unlikely this scenario may seem, things happen and the 
> vendor would be without recourse if unable to issue revocations.  To this 
> extent, setting up the infrastructure to support revocations can be compared 
> to insurance - hopefully you never need it, but when you do, you're glad you 
> have it.
>
> Kent
>
>
>
> ___
> Anima mailing list
> Anima@ietf.org
> https://www.ietf.org/mailman/listinfo/anima
>




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