Subject: [Anima] CoAP et al

From: Eliot Lear <[email-masked]>
Date: Wed, 3 Aug 2016 15:55:36 +0200

Dear authors of draft-ietf-anima-bootstrapping-keyinfra and WG,

The Fairhair alliance focuses on lighting and building automation.  Our
security team has been reviewing your draft, and we appreciate the
effort that you are devoting in this direction.  We would just like to
highlight at this junction that there is a preference for device
communications from the autonomic device to the registrar to be via COAP
over DTLS rather than HTTP over TLS, primarily because the devices that
we are working with will already have a CoAP implementation.  As such,
there is some interest in draft-pritikin-coap-bootstrap-03.txt.  We look
forward to seeing that work further developed.

On behalf of the Fairhair security subgroup,

Eliot

ps: as usual, I will encourage fairhair members to directly chime in
with their own views on this matter.

---

From: "Joel M. Halpern" <[email-masked]>
Date: Wed, 3 Aug 2016 10:14:31 -0400

COuld any of the folks involved with low power answer one question this 
note suggests?

As I understqnd it, low power devices are usually viewed as having 
limited capabilities.
Thus, I would normally expect to see their autonomic functions handled 
by a proxy, much as a COAP gateway provides connectivity to the rest of 
the Internet for such devices.

If that is the case, then I would not expect to run GRASP or ANIMA 
bootstrap  on the low end devices, but rather on the proxy.
I would instead expect a more specialized protocol (presumabvly over 
CoAP) for the last leg.  Without ANIMA discovery, etc.

What am I missing?
Yours,
Joel

On 8/3/16 9:55 AM, Eliot Lear wrote:
> _______________________________________________
> Anima mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/anima
>

---

From: peter van der Stok <[email-masked]>
Date: Wed, 03 Aug 2016 16:33:41 +0200

Hi Joel,

There are many scenarios with low power devices that depend on their 
application area.
Life for homenet devices is very different from life of devices in a 
well structured lighting installation.
In the latter case, the devices will follow one industry standard to 
provide interoperability between devices.
This standard can include many IETF standards.

I will expect that the devices in the installation will follow their own 
favored discovery mechanism.
Therefore, in their context the discovery is not essential.
The bootstrapping protocol after discovery can be adhered to, although 
none of the recommended discovery mechanisms were followed.

However, in the home context, or campus context, I can imagine that mDNS 
is important.

Hope this answers your question,

Peter

Joel M. Halpern schreef op 2016-08-03 16:14:
> COuld any of the folks involved with low power answer one question
> this note suggests?
> 
> by a proxy, much as a COAP gateway provides connectivity to the rest
> of the Internet for such devices.
>

---

From: Paul Duffy <[email-masked]>
Date: Wed, 3 Aug 2016 10:41:41 -0400

This is not just a constrained device issue.

Open Connectivity Foundation is also using CoAP across a wide range of 
platform capabilities.

On 8/3/2016 10:14 AM, Joel M. Halpern wrote:
> .

---

From: "Joel M. Halpern" <[email-masked]>
Date: Wed, 3 Aug 2016 11:04:28 -0400

That is interesting and helpful.

It does bring us to the problem of what we should require as mandatory 
to implement.  But that can wait while we work out what the important 
cases are.

Yours,
Joel

---

From: Michael Richardson <[email-masked]>
Date: Wed, 03 Aug 2016 12:33:35 -0400

Joel M. Halpern <[email-masked]> wrote:
    > As I understqnd it, low power devices are usually viewed as having limited
    > capabilities.
    > by a
    > proxy, much as a COAP gateway provides connectivity to the rest of the
    > Internet for such devices.

    > bootstrap on the low end devices, but rather on the proxy.

The goal is not to run GRASP or ACP on the low-end devices (the lightbulbs),
but rather to be able to use common infrastructure for bootstrapping.

    > What am I missing?

It's not about running GRASP over an ACP between lightbulbs, it's about
enrollment/bootstrap.   It might be about running GRASP over an ACP
between lighting controllers, and that may well involve the proxies you
mention.

(It's also worth making a comparison to what we consider "limited
capabilities" to what we had as control plane CPUs 20 years years ago)

--
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 4 Aug 2016 08:49:36 +1200

I assume people have looked at draft-pritikin-coap-bootstrap.
I don't see any discrepancy between that and Eliot's message.

   Brian

---

From: Rafa Marin Lopez <[email-masked]>
Date: Sun, 14 Aug 2016 14:05:14 +0200

Dear all:

Related with the usage of CoAP for bootstrapping in constrained devices (using EAP and AAA infrastructures) we wrote this I-D:

https://tools.ietf.org/html/draft-marin-ace-wg-coap-eap-03

and wrote this paper that may be of your interest:

http://www.mdpi.com/1424-8220/16/3/358

Comments are welcome.

Best Regards.

> El 3 ago 2016, a las 15:55, Eliot Lear <[email-masked]> escribió:
> 

-------------------------------------------------------
Rafael Marin Lopez, PhD
Dept. Information and Communications Engineering (DIIC)
Faculty of Computer Science-University of Murcia
30100 Murcia - Spain
Telf: +34868888501 Fax: +34868884151 e-mail: [email-masked]
-------------------------------------------------------

---

From: Behcet Sarikaya <[email-masked]>
Date: Mon, 15 Aug 2016 11:18:47 -0500

Hi Rafa,

> http://www.mdpi.com/1424-8220/16/3/358

Thanks for your work.

One thing I would like to clarify:
IoT bootstrapping should be done before the device gets an IP address.
I think that CoAP works over IP, i.e.e the device already has been
assigned an IP address.

So whatever you do can not be called bootstrapping maybe something
else which is security related, maybe some application layer key
establishment.

Regards,

Behcet

---

From: Rafa Marin Lopez <[email-masked]>
Date: Tue, 16 Aug 2016 01:58:16 +0200

Hi Behcet:

> El 15 ago 2016, a las 18:18, Behcet Sarikaya <[email-masked]> escribió:
> 
> Hi Rafa,
> 

[Rafa] Thanks for your comments.
> IoT bootstrapping should be done before the device gets an IP address.

[Rafa] As you may know IPv6 link-local address may be used. I may agree with your statement in a “global” or “routable" IP address. But, I guess, it will depend on the scenario. In any case, I think we should first agree in what IoT bootstrapping means and what are the requirements (MAY, MUST, SHOULD, …)

> I think that CoAP works over IP, i.e.e the device already has been

[Rafa] CoAP is being considered to be transported over the link-layer directly (e.g. draft-bormann-6lo-coap-802-15-ie-00 or draft-wang-6tisch-6top-coapie-01). Another example in LP-WAN (draft-pelov-core-cosol-01)

Btw there are also other protocols working on top of UDP (as CoAP) considered to be transported directly over the link-layer (e.g. IKEv2) as you may know. 

> else which is security related, maybe some application layer key

[Rafa] For the reasons mentioned above, I still call it bootstrapping

Best Regards.

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 16 Aug 2016 12:48:04 +1200

Let's be clear about the Anima context for "bootstrapping". You don't have
to look beyond the document abstract:

"  This document specifies automated bootstrapping of a remote secure
   key infrastructure (BRSKI) using vendor installed IEEE 802.1AR
   manufacturing installed certificates, in combination with a vendor
   based service on the Internet."

Obviously it's assumed that there is some kind of *insecure* connectivity
first. Which obviously implies a preceding insecure bootstrap of
some kind, but that is not the topic.

And, repeating myself I think, Anima is primarily aimed at nodes that
manage devices, not at the devices themselves. However, we'd like BRSKI
to be available to all devices, hence Max wrote draft-pritikin-coap-bootstrap.
Again, please read the abstract:

"  This document provides an initial discussion of Bootstrapping of
   Remote Secure key infrastructures (BRSKI) when the device being
   bootstrapped speaks CoAP."

Regards
   Brian

---

From: Toerless Eckert <[email-masked]>
Date: Mon, 15 Aug 2016 22:26:55 -0700

Thanks, Rafa

The combination of CoAP and EAP is certainly interesting. Let me
quickly summarize how in ANIMA we got to not consider EAP when we
looked at it without CoAP in the picture:

1. We did earlier in Anima investigate if/how we could/should use
EAP to perform ANIMA bootstrap. It turned out that transporting
all the desired key-infrastructure bootstrap messages across EAP
would have been quite cumbersome. It would have been necesssary to
use eg: EAP-TTLS which seems not to have seen wider use, and which would
have required to much around with the client side TLS stack (those
where the salient points if memory serves me right on this discussion).

2. Likewise, it seemed more appropriate for us to rely simply on IPv6
link-local addressing to first exist on clients than to figure out how to
make sure L2-only solutions like EAPoL exist everywhere and would
work across all L2 media - and having to tie ANIMA code into
such L2 code.  I can see how different industry groups that
specifically work only with one particular L2 technology are happy to
base more design on direct L2 layered protocols, but for ANIMA trying
to be easily applicable across any L2 technology, IPv6-LL seemed like
the best first approach. If specific L2 technologies have reasons
not to use it, i think we could add-on optimizations for those link technologies.

Cheers
    Toerless

---

From: Toerless Eckert <[email-masked]>
Date: Mon, 15 Aug 2016 22:43:01 -0700

Rafa,

I have not managed to figure out from your draft what exactly
you consider to be bootstrapping. It seems you primarily refer
to draft-ohba-core-eap-based-bootstrapping, which seems to be expired.

To quickly summarize what in anima we call bootstrap:

The ANIMA key bootstrap protocol primarily tries to get a credential
installed on a device. This is based on RFC7030 (eg: cert enrolment)
and adds all the functions we have identified as being necessary on top of this:

  1. Initial signaling so the client can trust the server from which
     it gets the credential - server can be from some owner of the
     device and it's producing a credential from the vendor of the
     device that makes the device trust the server.  As a result
     for example the client install the servers CA cert into its
     cert trustpool list.
  
  2. Requesting parameters to be associated with the credential. These
     parameters are then useable by next steps. In Anima, these
     credentials are parameters to the client cert, and those are
     then used in building the ACP after bootstrap.

  3. Installing the credential - in ANIMA devices the AN Certificate.
  
     Note: We did discuss but have not decided on options where
     for example this step could be optional, eg: where in very low-end
     devices the vendor installed credential is sufficient, and no new credential is
     desired, but instead only 1., 2., 4., 5. are performed.
  
  4. Diagnostics so the server side will know if/how steps 1..3 where
     successful.
  
  5.  Next step to take by the device - eg: build ACP or for non
      ANIMA devices, maybe "here is your next provisioning connection
      to build". (we're just discussing this step).

So, i am not aware that existing EAP mechanisms offer any such bootstrap
functionality. I am not even aware they offer an equivalent of rfc7030 with
EAP.

-- 
---
Toerless Eckert, [email-masked]

---

From: Michael Richardson <[email-masked]>
Date: Tue, 16 Aug 2016 09:27:18 -0400

Toerless Eckert <[email-masked]> wrote:
    > 1. We did earlier in Anima investigate if/how we could/should use EAP
    > to perform ANIMA bootstrap. It turned out that transporting all the
    > desired key-infrastructure bootstrap messages across EAP would have

There are two other key issues with the 1x-architecture of supplicants,
authenticators and authorization servers (AS).

The architecture usually looks like: (nice picture at:
https://en.wikipedia.org/wiki/IEEE_802.1X )

 S<--EAP-TLS over EAP over 1x/PANA->Authenticator<--EAP-over-radius-->AS

The problem with this architecture is that it:
  a) always creates state on the authenticator

  b) requires a secure relationship between Authenticator and Radius Server.
  (a radius secret, and an entry in the Radius Server's client table)

  c) And we'd then have to run EST over the EAP/TLS connection, and do it
     not with the radius server, but with the Registar.

(a) is a cost to absorb.
(b) could be mitigated by changing the Authenticator to really be:

   Authenticator . o O ( <Proxy>-----EAP-over-GRASP---<Registar> )

and having no radius server at all.   Of course, having got rid of that
compoennt, the commonality with the various 1x infrastructures is really
non-existant.  All we've done is introduce EAP fragmentation (and code paths)
in a place where it will get used only once.

Instead, a good way to think about ANIMA bootstrap is that it's the way in
which you get credentials which you can *then* use for 1x, if that's what
your infrastructure wants.  Today, those credentials are distributed
out-of-band.   Seperating bootstrap from the 1x process not only simplifies
the bootstrap process, but it also simplifies the 1x code base, as it doesn't
have to figure out if the new pledge is trying to join the network, or trying
to bootstrap.

(I'm reminded of the Robert Frost poem about The Road Not Taken. Often
it is thought to be about taking chances in life.  I tend to think that
when it comes to security, that it's best not have divergent paths in code,
unless both have regularly used test cases: "I doubted if I should ever come
back")

---

From: Rafa Marin Lopez <[email-masked]>
Date: Wed, 17 Aug 2016 00:28:21 +0200

Hi Brian:

Thanks for the clarification. The only intention of my e-mail was to show that the usage of CoAP for bootstrapping (in constrained devices) was also considered in our work.

The abstract you mention and the work you are doing in ANIMA are both fine with me. 

Best Regards.

> El 16 ago 2016, a las 2:48, Brian E Carpenter <[email-masked]> escribió:
>

---

From: Rafa Marin Lopez <[email-masked]>
Date: Wed, 17 Aug 2016 01:00:43 +0200

Hi Toerless:

> El 16 ago 2016, a las 7:26, Toerless Eckert <[email-masked]> escribió:
> 
> Thanks, Rafa
> 
> The combination of CoAP and EAP is certainly interesting.

[Rafa] Thank you.

> Let me

[Rafa] EAP can be used for authentication and because its well established key management framework (RFC 5247). However, the transport of additional information could be performed also by using the EAP lower-layer (e.g. CoAP), which makes the solution EAP method independent (e.g. EAP—TTLS is an EAP method). 

Having said this, I remember this was deeply discussed long time ago in the context of MIPv6 bootstrapping (RFC 4640): that is,  1) distributing bootstrapping information inside the EAP method, as you mention in EAP-TTLS (in general, a tunneled EAP method), or using another protocol after EAP authentication. In any case, in that time, the usage of AAA infrastructures for bootstrapping was considered.

> not to use it, i think we could add-on optimizations for those link technologies.

[Rafa] I agree with this.

---

From: Rafa Marin Lopez <[email-masked]>
Date: Wed, 17 Aug 2016 01:21:56 +0200

Hi Toerless:

> El 16 ago 2016, a las 7:43, Toerless Eckert <[email-masked]> escribió:
> 
> 
> Rafa,
> 

Just a clarification,  draft-marin-ace-wg-coap-eap-03 is just presenting a transport of EAP in CoAP (CoAP used as EAP lower-layer). The bootstrapping service is in the paper.
	
> functionality. I am not even aware they offer an equivalent of rfc7030 with

[Rafa] Thanks for this clear summary. I have to say that EAP is a protocol for authentication and key management mainly. You have several "EAP methods” that define the authentication mechanisms in EAP. As I mentioned, previous work about MIPv6 bootstrapping used tunneling capabilities in certain EAP methods to “inject” that configuration information (e.g. draft-giaretta-mip6-authorization-eap-04 , old draft but interesting). Other alternative is just to use EAP for authentication key material generation to protect the signaling of other protocol/s that allows to transfer the information you need. 

In the context of "IoT bootstrapping", I must say that we are not the only one proposing the usage of EAP (the novelty of our solution is the usage of CoAP as EAP lower-layer). 

Best Regards.

---

From: Rafa Marin Lopez <[email-masked]>
Date: Wed, 17 Aug 2016 01:51:47 +0200

Hi Michael:

Just a clarification. If you are referring to IEEE 802.1X with 1x , then I have to say that IEEE 802.1X is not EAP but it is using EAP. More specifically, IEEE 802.1X is an EAP lower-layer. More comments inline.

> El 16 ago 2016, a las 15:27, Michael Richardson <[email-masked]> escribió:
> 
> 

[Rafa] How do you perform an authentication exchange otherwise? Unless you are thinking something like Kerberos where the KDC is stateless.

>  (a radius secret, and an entry in the Radius Server's client table)

[Rafa] I think we should talk about AAA server in general because other protocols as Diameter can be used. Moreover the authenticator has to have a secure relationship with the next hop AAA server (AAA proxy) not with the (home) AAA server. Hence, the scalability.

>     not with the radius server, but with the Registar.

[Rafa] That is why I mentioned that, perhaps, the assistance of the EAP lower-layer (e.g. CoAP) could help with this task.
> and having no radius server at all.

[Rafa] That is called in EAP: EAP Stand-Alone authenticator. 

>   Of course, having got rid of that
> out-of-band.

[Rafa] Precisely this is the kind of separation we are proposing in our work for IoT bootstrapping.

Best Regards.

>   Seperating bootstrap from the 1x process not only simplifies