Subject: [6tisch] Directions on the join process

From: Malisa Vucinic <[email-masked]>
Date: Thu, 22 Oct 2015 14:55:41 +0200

Dear all,

Here is an attempt to summarize the recent discussions regarding the problem of 6tisch join and provisioning of K2 to JN. See bellow. Implementation components that can be reused are enclosed in the parentheses. Traffic load is expressed as the number of messages, rather than number of exchanges, as this better reflects the nature of the link we will be using: a single shared communication slot carrying ~100 bytes of data (cf. draft-ietf-6tisch-minimal).

It seems there are three main directions the WG can take: 1) EAP over foo; 2) DTLS; 3) 6tisch-specific solution. 

Option 1 seems the most extensible and generic but I dislike the fact that there would be a lot of join-specific code. We are already having difficulties fitting the stack into certain IoT MCUs due to the flash constraints and having 2-3 protocol implementations that are used only once certainly does not help. Cases 1.C and 1.D that seem to require less join-specific code have either prohibitively large traffic load (1.C) or rely on session security that is not standardized, in which case a 6tisch-specific solution with 4x improvement factor in traffic would IMO be a better option.

Option 2 leverages the DTLS implementation that is in any case mandated by CoAP so it does not necessitate much additional implementation effort, other than the JA relay application. Another advantage here is that one can pass from PSK to certificate-based authentication transparently. The traffic load remains a significant concern. See http://arxiv.org/pdf/1507.05810 <http://arxiv.org/pdf/1507.05810> for some figures on duration of DTLS PSK handshake with *dedicated* cells (e.g. ~5 seconds per hop per JN with 101-long slotframe, and this is in the *best* case tripled with many nodes joining and slotted Aloha behavior).

Option 3 would imply designing a minimal 6tisch solution to provision K2, compatible with the existing 6tisch architecture and mechanisms (6top, CoAPie). In short, we discussed a simple protocol where JCE keeps track of JN-specific join counter used for replay detection, that JN advertizes in the hello message including information like its EUI-64, random challenge for JCE, all protected with PSK. The JCE sends K2 encrypted with  PSK and transfers that over the network to JN. Advantage of this direction would be minimized traffic load (3 messages vs 11+) and possibly implementation requirements as we can do this extending 6top and re-using CBOR implementation. A disadvantage would be the fact that we are not using a standardized solution.

It would be useful if we could discuss some of these aspects tomorrow during the call. Also, it would be great if people with benchmarks on join duration without any security would post these to the list. 

Regards,
Mališa

Option 1: EAP-based
———————————
Case 1.A: IKEv2 over 802.15.9 + EAP (e.g. -AKA) (http://mailarchive.ietf.org/arch/msg/6tisch/fPmwtSOL-v0FDNcU3sWwHAdeyTs) 
- Traffic load: 6 messages between JN-JA, 4 messages between JA-JCE
- Implementation requirements: minimal IKEv2, 802.15.9, EAP-AKA
- Notes: JA takes active role during join, could be useful for DoS protection with certificate-based authentication

Case 1.B: EAP over PANA
- Traffic load: minimum 4 messages for PANA + [ 5 messages for EAP-AKA, 15+ messages for EAP-TLS ] + 1 packet to provision K2
- Implementation requirements: PANA, EAP method
- Notes: JA is a passive relay

Case 1.C. EAP-PSK over CoAP + DTLS (e.g. draft-marin-ace-wg-coap-eap-02)
- Traffic load: 10 messages between JN-JCE to establish a unique session key + 11 messages for DTLS to establish a session with the established key + 1 packet to provision K2
- Implementation requirements: EAP-PSK, (DTLS)
- Notes: JA is a passive relay

Case 1.D. EAP-PSK over CoAP + custom protection of CoAP header/payload with the generated key
- Traffic load: 10 messages between JN-JCE to establish a unique session key + 1 packet to provision K2
- Implementation requirements: EAP-PSK, custom CoAP security extension
- Notes: JA is a passive relay

Option 2: DTLS-based
———————————
Case 2.A: JN is a DTLS client
- Traffic load: 11 messages between JN-JCE + 1 packet to communicate K2 over the established session
- Implementation requirements: (DTLS), relay application
- Notes: JA is a passive relay

Option 3: 6TiSCH-specific 
———————————
Case 3.A: Explicit provisioning of K2 using 6top+CoAP, protected with JN’s PSK (e.g. http://mailarchive.ietf.org/arch/msg/6tisch/Obm-_ehdAeGXKXOEwzpdeB5diq8)
- Traffic load: 3 messages between JN - JCE
- Implementation requirements: (CBOR) + COSE
- Notes: JA is a passive relay

---

From: Rafa Marin Lopez <[email-masked]>
Date: Fri, 23 Oct 2015 00:44:27 +0200

Hi Malisa:

Thanks a lot of for this analysis. I would like to make some clarifications regarding the option 1.C/D. related with draft-marin-ace-wg-coap-eap-02 and other aspects.

1) EAP-PSK is just an example in our draft (maybe it is not clear in the current version so we will try to clarify it). So saying EAP-PSK over CoAP is not accurate. It is just EAP over CoAP. You can use any EAP method you want. In fact the usage of EAP is to give flexibility for the authentication mechanism. Moreover it opens the door to scalability. 

2) The establishment of DTLS is required if you want to protect CoAP messages (e.g. for other services) after the EAP authentication happens. In fact EAP over CoAP goes through unprotected port. The question is: do you need to protect CoAP messages after the bootstrapping happens? If yes any solution will require to DTLS unless you protect the CoAP messages at application level (like option 1.D) or if the link-layer is protected with the keys generated after EAP authentication.

Having said that I have some additional comments inline.

> El 22 oct 2015, a las 14:55, Malisa Vucinic <[email-masked]> escribió:
> 
> Dear all,
> 

Here you can find a study about the usage of PANA in constrained devices (in particular, Contiki OS).

http://www.mdpi.com/1424-8220/13/11/14888

We are doing same study related with EAP over CoAP, with implementations we have of our service for Contiki OS and mbed. In fact, EAP over CoAP was born precisely for your comment ("having 2-3 protocol implementations that are used only once certainly does not help”). EAP over CoAP re-use source code related with CoAP (that is assumed to be used for other purposes as well) and it only adds EAP, which is not too complex.

> 
> Option 2 leverages the DTLS implementation that is in any case mandated by CoAP so it does not necessitate much additional implementation effort,

Thus, we assume in this option we have CoAP anyway, right?. Then, EAP over CoAP assumes that you can built an authentication/bootstrapping service based on CoAP.

> other than the JA relay application. Another advantage here is that one can pass from PSK to certificate-based authentication transparently.

This advantage is also possible in EAP-based solutions for, precisely, the usage of EAP.

> The traffic load remains a significant concern. See http://arxiv.org/pdf/1507.05810 for some figures on duration of DTLS PSK handshake with *dedicated* cells (e.g. ~5 seconds per hop per JN with 101-long slotframe, and this is in the *best* case tripled with many nodes joining and slotted Aloha behavior).

This is a great paper indeed. That is why I think it might be worthy considering protection at application level (maybe OSCOAP)

> Option 3 would imply designing a minimal 6tisch solution to provision K2, compatible with the existing 6tisch architecture and mechanisms (6top, CoAPie). In short, we discussed a simple protocol wh…

Sorry for not knowing the details of this option, but I understand that JN is authenticated with the PSK, right?. 

> It would be useful if we could discuss some of these aspects tomorrow during the call. Also, it would be great if people with benchmarks on join duration without any security would post these to th…

So some final comments to your analysis… below...

> Option 1: EAP-based

Btw, Zigbee IP already uses this option.
> - Notes: JA is a passive relay

In 1.C/D the idea of using CoAP in EAP over CoAP is to re-use source code and providing shorter messages to transport EAP. As I said, adding DTLS is necessary if you want to protect further CoAP messages after the bootstrapping unless you want to use protection at CoAP level (e.g. OSCOAP) or link-layer protection that is bootstrapped after the EAP authentication.

Btw, I am thinking that a little re-design of EAP over CoAP service with a proper EAP method could allow to generate a fresh pre-shared key in less messages. Nevertheless, this is just a preliminary thought that needs to be discussed of course.

> Option 2: DTLS-based

And considering protection at application level to avoid DTLS?

> Option 3: 6TiSCH-specific 

I still need to check more carefully this link (the flow is difficult to read) but if we assume that a PSK is used as credential for the JN there are several handshake protocols in the literature (e.g. AKEP2, HIP-DEX,...) that may be adapted for this case. In any case, somehow that is not “bootstrapping" to me because it is just assuming you configure “manually” a PSK and run the handshake protocol. Although I might be wrong.

Let’s talk tomorrow in the call if time is available. 

Best Regards and thank you again!

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

-------------------------------------------------------
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: Tero Kivinen <[email-masked]>
Date: Mon, 26 Oct 2015 14:04:29 +0200

Malisa Vucinic writes:
> Option 3 would imply designing a minimal 6tisch solution to provision K2,
> compatible with the existing 6tisch architecture and mechanisms (6top,
> CoAPie). In short, we discussed a simple protocol where JCE keeps track of
> JN-specific join counter used for replay detection, that JN advertizes in the
> hello message including information like its EUI-64, random challenge for JCE,
> all protected with PSK. The JCE sends K2 encrypted with  PSK and transfers
> that over the network to JN. Advantage of this direction would be minimized
> traffic load (3 messages vs 11+) and possibly implementation requirements as
> we can do this extending 6top and re-using CBOR implementation. A disadvantage
> would be the fact that we are not using a standardized solution.

PSK only solution is not going to work, as it would require some kind
of userinterface in all devices, which is used to change the PSK when it
leaks out, or when the device is recomissioned to new environment.

So I would rule all PSK ONLY solutions out of question. The solution
needs to support at least some kind of raw public key or similar
method to be scalable.

Because of this I think the option 3 is not good idea, as we would
need to define more complicated protocol than what you express, there
and immediately when we start to go towards that path, it is better to
start to use already existing real KMPs.

In 802.15.9 we realized this, and our PAR explictly said that we
will not create new KMP. We just use existing KMPs. 

> Option 1: EAP-based
> ———————————
> Case 1.A: IKEv2 over 802.15.9 + EAP (e.g. -AKA) (
> http://mailarchive.ietf.org/arch/msg/6tisch/fPmwtSOL-v0FDNcU3sWwHAdeyTs) 

You can also run IKEv2 over 802.15.9 using raw public keys, which will
simply be 4 messages between JN-JA, and then you do need to run some
protocol between JA-JCE, where the JA sends the hash of public key +
EUI-64 to the JCE, and JCE says whether that device should be allowed
to connect (i.e. ACL check done on the JCE).

Of course the ACL can also be distributed from tje JCE to the JAs, but
if the ACL is large, it is better to do the check when the JN joins.
This also protects the device association, and the IP address
assignments, as all communcation betwee JN-JA is done over 802.15.4
frames, and no IP-address is needed yet.

This would drop the traffic load to 4 message between JN-JA and 2
messages between JA-JCE.

This would be my preferred way of solve this problem. 

> Case 1.B: EAP over PANA
> - Traffic load: minimum 4 messages for PANA + [ 5 messages for EAP-AKA, 15+
> messages for EAP-TLS ] + 1 packet to provision K2

Good thing here is that it is reusing lots of existing protocols, bad
thing is that you need lots of messages. Also I think you need to get
IP-address before you can run PANA (unless you run PANA over
802.15.9), so that will add overhead and also consume resources.

> - Traffic load: 10 messages between JN-JCE to establish a unique session key +
> 11 messages for DTLS to establish a session with the established key + 1
> packet to provision K2

Same as 1.C. I.e. need IP-address, cannot protect IP-address
assignment (and device association, if that is needed before getting
IP-address), quite a lot of packets. Good thing again is that we reuse
lots of things, and we can use different authentication methods (i.e.
EAP-PSK is not something we should use in real world). 

> - Notes: JA is a passive relay

Anything that we need to define here as security will be bad idea,
i.e. designing KMP is not that easy. There are lots of pitfalls you
might trip into, and I would recommend against specifying new KMP here.

> Option 2: DTLS-based

This would allow us to use any DTLS authentication methods, i.e. I
tihnk we could use raw public keys etc.

> Case 3.A: Explicit provisioning of K2 using 6top+CoAP, protected with JN’s PSK
> (e.g. http://mailarchive.ietf.org/arch/msg/6tisch/Obm-_ehdAeGXKXOEwzpdeB5diq8)

PSK only solution is not really acceptable, and we would need to
provide something that supports something that can be used in real
world. In lot of situations we do not want to give the PSK of the
device to the all networks we might join into.

I have used an example of key token earlier. If I have one key token
in my keyring, and I want to use it to open different doors, like
home, and office. I do not want to give the PSK from the key token to
the office manager, as then if someone steals the PSK from the office,
they will be able to open my home door. Also the office manager might
not trust that my home server is so well protected that nobody can
break in, thus they do not want to allow my PSK to be used to open
office doors, as anybody breaking to my home server, will be able to
open office doors.

So we do need some public key based system, and specifying new KMP
here is bad idea.
-- 
[email-masked]

---

From: Rafa Marin Lopez <[email-masked]>
Date: Mon, 26 Oct 2015 21:16:45 +0100

Hi Tero:

Some comment inline.

> El 26 oct 2015, a las 13:04, Tero Kivinen <[email-masked]> escribió:
> 
> Malisa Vucinic writes:

> frames, and no IP-address is needed yet.

I guess HIP-DEX could be also used alternatively. In any case, how does the JCE know the JN is actually there? Because, in the end, the JCE does not authenticate the JN. This has been discussed in the past ("peer consent”). In my opinion, the JCE should be in charge of first-hand authenticating the JN. 

> 802.15.9), so that will add overhead and also consume resources.

My understanding is that IKEv2 was designed to be transported on top of UDP. Thus, if IKEv2 can be transported in IEEE 802.15.9, similarly PANA or CoAP could be transported as well. In the case of CoAP, even there is some study with coapie. In case of PANA, there was some proposal about it.

Btw, in Zigbee IP they already use PANA and the link-local IPv6 address in the JN, as far as I remember. PANA has also a "PANA relay" (RFC 6345) defined for the JA.

> IP-address), quite a lot of packets.

As commented above, transporting CoAP in IEs could be a possibility.

> Good thing again is that we reuse

Agreed. As I mentioned in a previous e-mail, the usage of EAP-PSK is not mandatory in CoAP-EAP. Any EAP method can be used.

https://mailarchive.ietf.org/arch/msg/6tisch/CxWuc_56Q8PmFx38xvCHfs9FzpY

In fact, as I stated the number of exchanges can be reduced with a proper EAP method and some optimizations in the original EAP over CoAP draft.

>> 1 packet to provision K2

I do not think this is referring to a new key management protocol (there is no protocol exchanges) but only a way to protect CoAP messages at application level with some key material obtained from the EAP authentication. For example, OSCOAP could be an example (https://tools.ietf.org/html/draft-selander-ace-object-security-03)

> tihnk we could use raw public keys etc.

The usage of EAP would also provide all the flexibility in term of authentication method. That was the main motivation of the EAP design. 

Best Regards.

---

From: Tero Kivinen <[email-masked]>
Date: Tue, 27 Oct 2015 00:19:00 +0200

Rafa Marin Lopez writes:
> I guess HIP-DEX could be also used alternatively. In any case, how
> does the JCE know the JN is actually there? Because, in the end, the
> JCE does not authenticate the JN. This has been discussed in the
> past ("peer consent”). In my opinion, the JCE should be in charge of
> first-hand authenticating the JN.

HIP-DEX is one of the KMPs which can be used with 802.15.9. I have not
really checked HIP-DEX for the set of features, so you might be right
there.

Of course if the KMP is run only between JN and JA, and the ACL check
is done between JA and JCE, then JCE has to trust JA to check
credentials of the JN before letting it to join. If you do not trust
your JAs enough to do that, then you need to run EAP and run
authentication in the JCE instead of in the JA.

With IKEv2 both options are possible, and which one you want to use
depends on the environment. 

> My understanding is that IKEv2 was designed to be transported on top
> of UDP. Thus, if IKEv2 can be transported in IEEE 802.15.9,
> similarly PANA or CoAP could be transported as well. In the case of
> CoAP, even there is some study with coapie. In case of PANA, there
> was some proposal about it.

PANA is already defined to be used in the 802.15.9, but PANA defined
in 802.15.9 is used in bootstrapping, i.e. getting LLCs and then you
need to still run some operational KMP over 802.15.9 to use those
credentials to generate the final keying materials. I am not a PANA
expert, so do not know how it is supposed to work... :-)

CoAP could be run over 802.15.9, but as it is not KMP it cannot be
used as KMP for generating keys for 802.15.4... CoAP could use the
Multiplexing layer of the 802.15.9, and it can be used to fragment and
transport messages from one node to another and identify those
messages as CoAP messages instead of KMP messages.

Adding new KMPs to 802.15.9 is quite easy as mostly you need to
allocate number for the KMP and define how the 802.15.4 keying
material is extracted from the KMP.

Using 802.15.9 multiplexing layer is also easy, as there is separate
multiplexing ID, which can be used to multiplex KMP traffic and other
traffic (CoAP or similar) over 802.15.9 IEs. The multiplexing IDs are
ethertypes, so if you already have ethertypes allocated you can use
that directly, or if not, you can allocate one from the reserved
range. 

> Btw, in Zigbee IP they already use PANA and the link-local IPv6
> address in the JN, as far as I remember. PANA has also a "PANA
> relay" (RFC 6345) defined for the JA.

If I have understood correctly what is defined in the 802.15.9 Annex D
PANA, is just about what is done in Zigbee IP. 

> As commented above, transporting CoAP in IEs could be a possibility.

Yep.

> I do not think this is referring to a new key management protocol
> (there is no protocol exchanges) but only a way to protect CoAP
> messages at application level with some key material obtained from
> the EAP authentication. For example, OSCOAP could be an example
> (https://tools.ietf.org/html/draft-selander-ace-object-security-03)

That will be very simple key management protocol, but it still will be
key management protocol. EAP is authentication protocol, and how to
derive keys from the secret it generates to protect something is KMP.
Even if it just defines key hierarchy and how to get keys for
different levels.

Also quite soon you will realize that we need to have rekeys, and we
need to be able to distribute group keys, and we need to do group
membership management -> you are adding more and more KMP features...

> The usage of EAP would also provide all the flexibility in term of
> authentication method. That was the main motivation of the EAP
> design.

But immediately when you move from the built in authentication methods
of the KMPs like DTLS, or IKEv2 to EAP you get more messages, i.e.
more overhead. Thats why IKEv2 do not use EAP all the time, it uses it
only if base shared key, or public key authentication is not enough...
-- 
[email-masked]

---

From: Michael Richardson <[email-masked]>
Date: Mon, 26 Oct 2015 19:08:19 -0400

> to connect (i.e. ACL check done on the JCE).

Yes, that's good, but how does the device authenticate the JCE?

Do you think the EUI-64 should be signed by the public key?
Would you include some nonce from the JCE to assure freshness?

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

---

From: Tero Kivinen <[email-masked]>
Date: Tue, 27 Oct 2015 12:36:19 +0200

> Yes, that's good, but how does the device authenticate the JCE?

Same way as how the JCE authenticates JN. I.e. there is ACL in the JN.
When using pre-shared keys you configure shared secret between the JN
and JCE. With raw public keys you configure hash of the public keys to
be allowed to connect.

The JCE quite often have some kind of user interface which allows it
to be configured, i.e. how you can add new allowed JNs to it. The JN
might not have real UI, but quite often you do the bootstrap /
provision step in such way that when you first time boot up the
device, it will trust the first JCE it will see, and it will then take
that public key and start trusting that.

> Do you think the EUI-64 should be signed by the public key?

Another question is, how the JN then starts trusting to JA when the
KMP is run directly between JN and JA. In this case the JA only does
ACL checks from JCE, and JN does not know anything about JA
beforehand. For that you most likely need some kind of certificates
generated by JCE, i.e. JCE can give JA a certificate which is signed
by JCE and which has public key of JA in it, and when JN sees that and
it knows from bootstrap / provision step that it can trust JCE, it
then knows it can trust JA also, when the certificate has EUI-64 in it
too... In this case JCE can act as very simple local CA with short
lived certificates.

Perhaps it could even use ASN instead of timestamp to tell when the
certificate expires, i.e. it could give JA a certificate which is
valid for 8 hours, and tell that this means it will expire at ASN
number 0x1251451244. One way to do that would be to define certificate
extension which maps the real time to ASN inside the certificate. I.e.
the certificate could say that the Issue time of this certificate in
ASNs is 0x1251400000 and ASN is incremented every 0.01 seconds. Using
that the JN can calculate the last ASN when the certificate is still
valid. Or we can just assume that clock chips are so cheap and as tsch
requires devices to keep track of time even when they are sleeping,
they can also keep track of real time too, thus no need to do anything
like that, just use normal certificate validity times.

All of these will depend on the environment, and what kind of features
is needed in the devices. As I explained earlier, quite often the JN
is not really even interested on the authentication of JCE. For
example for temperature sensor, it does not care to whom it sends the
information. JCE is interested to authenticate JN as it wants to know
it can trust the sensor reading.

Thermostat of course will want to authenticate the commands that are
sent to it, but that might be better done using authenticated
commands, and not link level security.

So what we want out from the KMP is that JCE can limit who can
consume resources from his network, i.e. he wants to limit who can
join by using ACL. JA wants to verify the from the JCE that JN is
allowed to connect before using too much resources. JN can just try to
connect all networks, and see which one of them has the services it
needs, and quite often those services do require upper layer
authentication, and if that authentication fails, it might try to do
corrective actions.

> Would you include some nonce from the JCE to assure freshness?

I assume the KMP is properly defined, and it provides freshness, i.e.
if KMP is run between JN and JA that will be fresh. The JCE already
trusts JA and I do not think there is need to provide freshness
information in the ACL check from JA to JCE. If the JCE wants to allow
JA to cache ACL results, it will need to provide information how long
the JA can cache the ACL check results received from JCE. 
-- 
[email-masked]

---

From: Rafa Marin Lopez <[email-masked]>
Date: Tue, 27 Oct 2015 13:42:00 +0100

Hi Tero:

Thanks for this interesting discussion. Please see other comments inline
> El 26 oct 2015, a las 23:19, Tero Kivinen <[email-masked]> escribió:
> 
> Rafa Marin Lopez writes:

Running EAP is not related with either you trust the JA or not. You can run EAP in standalone mode between the JN and JA and follows the same schema you mention. There, the EAP authenticator is the JA. Or it can be placed on the JCE.  I think the problem where you place the EAP authenticator (either in the JA or in the JCE). Or, in general, what is the entity that really authenticates the JN. 

I personally do not feel too much comfortable with the fact JN does not authenticate the JCE and vice-versa. But it is fine with me if the WG wants to go that way. 

> credentials to generate the final keying materials.

Btw, to avoid any confusion, from your comment it seems that you have made a distinction of a solution for bootstrapping and for the KMP. EAP over CoAP would be for bootstrapping as well. Thus, are we talking about the bootstrapping or the KMP (the security association protocol) after the bootstrapping? 

> I am not a PANA
> used as KMP for generating keys for 802.15.4…

It is the EAP over CoAP service that bootstraps the keys.

> CoAP could use the

This is interesting.

> derive keys from the secret it generates to protect something is KMP.

The EAP Key Management Framework talks about (unicast or multicast) "security association protocol", and that is the assumption after the EAP authentication. So to me EAP is useful to “bootstrap" key material. Having said that, it is fine to me consider everything as a KMP. In fact, there was an old draft https://tools.ietf.org/html/draft-ohba-6tisch-security-01 with the description of several KMPs that can be used in different phases. 

> membership management -> you are adding more and more KMP features…

> more overhead.
> Thats why IKEv2 do not use EAP all the time, it uses it
> only if base shared key, or public key authentication is not enough…
> -- 
> [email-masked]
>

---

From: Tero Kivinen <[email-masked]>
Date: Tue, 27 Oct 2015 15:10:55 +0200

Rafa Marin Lopez writes:
> Running EAP is not related with either you trust the JA or not. You
> can run EAP in standalone mode between the JN and JA and follows the
> same schema you mention. There, the EAP authenticator is the JA. Or
> it can be placed on the JCE.  I think the problem where you place
> the EAP authenticator (either in the JA or in the JCE). Or, in
> general, what is the entity that really authenticates the JN.

Yep. On the other hand with IKEv2 you can also use multiple
authentication methods (RFC4739) where you first run authentication
between the JN and JA using raw public keys, and then run second
authentication using EAP, where the JA forward the EAP messages to the
JCE, i.e. the EAP authenticator is in the JCE. That will provide a way
to authenticate both JA and JCE to JN, and JN to both JA and JCE.

But that will mean there is around 10 messages instead of 4...

> I personally do not feel too much comfortable with the fact JN does
> not authenticate the JCE and vice-versa. But it is fine with me if
> the WG wants to go that way.

It depends what your environment is. If the joining process is
happening only once when the network is set up, then running 10
messages during that is not a problem. If it happens every time you
move from one room to another (i.e your remote controller joins the
6tisch network in the room to control the lights), then doing it
quickly with 4 messages might be better.

> Btw, to avoid any confusion, from your comment it seems that you
> have made a distinction of a solution for bootstrapping and for the
> KMP. EAP over CoAP would be for bootstrapping as well. Thus, are we
> talking about the bootstrapping or the KMP (the security association
> protocol) after the bootstrapping?

As far as I understand PANA is really for bootstrapping or at least
that is how the authors of those parts of the 802.15.9 defined things.
I.e. PANA does not really create dynamic link-keys and negotiate SAs
between devices, nor it can do rekeys etc. Or that is at least what I
have understood. I might of course be misunderstanding what PANA does,
as I have not really looked at it, but currently in 802.15.9 PANA is
defined to be used for bootstrapping and then you need some other KMP
to do negotiate link keys, and distribute group keys.

I have been talking about the KMP, I just pointed out that PANA is
already defined for 802.15.9, but it is not really KMP, so in addition
to that you need real KMP too.

> It is the EAP over CoAP service that bootstraps the keys.

Which is not KMP, thus it cannot generate pairwise link keys between
two devices, and distribute different group keys with KeyIndexes,
KeySources etc to each other.

Bootstrapping is separate problems and I think we should more
concentrate on the KMP issue. I.e. how do we get the pairwise keys
between device A and B, and how do we distribute the group key using
KeyIndex 0x02 and KeySource of 0xdcac000000000002 to joining device.

> The EAP Key Management Framework talks about (unicast or multicast)
> "security association protocol", and that is the assumption after
> the EAP authentication. So to me EAP is useful to “bootstrap" key
> material. Having said that, it is fine to me consider everything as
> a KMP. In fact, there was an old draft
> https://tools.ietf.org/html/draft-ohba-6tisch-security-01 with the
> description of several KMPs that can be used in different phases.

Actually EAP only authenticates the endpoints, and certain EAP methods
can also generate keying material. Not all EAP methods are key
generating. On the other hand using non-keygenerating EAP methods is
usually not safe.
-- 
[email-masked]

---

From: Michael Richardson <[email-masked]>
Date: Tue, 27 Oct 2015 15:19:27 -0400

What I'm interested here is the ability to leverage the 802.15.9 KMP *code*
to assist with the join process.  While I love IKEv2 and HIPDEX, I'm not
convinced that there is code+ram space for those KMPs as well as the DTLS
that 6top/CoAP is going to require.  I'd like it to all converge :-)

    > Same way as how the JCE authenticates JN. I.e. there is ACL in the JN.

That's just not workable.

    > and JCE. With raw public keys you configure hash of the public keys to

When using pre-shared keys, the JN comes with a secret on some media
(XLS file with packing slip, QR code, etc.). It's a bearing key. Anyone with
that key can cause that JN to join.  It's not great, but how bad it is
depends upon the security of the container of the key.

One can also imagine online systems where the PSK is returned to an
authorized host (the JCE) upon presentation of some other token. But, if you
are going to do that, you might as well return a certificate (signed by the
vendor, perhaps via a chain) that the JN can verify.

    > that public key and start trusting that.

That's been deemed unacceptable by many.

    > KMP is run directly between JN and JA.

Yes, that definitely another question I had, but I hadn't gotten to it yet.

    > In this case the JA only does

Yes, this is definitely doable.

    > number 0x1251451244. One way to do that would be to define certificate

That's a really good idea!

    > it can trust the sensor reading.

Sometimes that's true, but the problem is that if the temperature sensor is
not on the correct network, then it's broken, and has to be replaced.

    > the JA can cache the ACL check results received from JCE.

This nonce is not used in the KMP, but rather, in the protocol where the
JA sends the JN's (signed) EUI-64 to the JCE.  The nonce would be included
by the JN into that signature, so that the JCE would know that the JN did
the signature now, and wasn't being subject to some kind of tunneling
attack. (that's not the right term)

---

From: Malisa Vucinic <[email-masked]>
Date: Wed, 28 Oct 2015 21:58:50 +0100

From the point of view of code reuse, DTLS seems to make sense but I think we would really need to find a way of getting rid of 10+ packets to get things going, particularly when we can leverage PSKs. Looking at draft-ietf-dice-profile, it seems that session resumption could help us for that. I am thinking whether it would make sense for the JN to initiate the handshake using session resumption without server-side state (RFC 5077) and get the handshake done in 1.5 exchanges when PSK is in place. Or in case we decide that JN should be a DTLS server and make itself visible by some other method, JCE would be initiating the abbreviated handshake with the ticket that JN is able to access locally as it is in possession of the PSK. Would that be any reasonable?

Regards,
Mališa

> On 27 Oct 2015, at 20:19, Michael Richardson <[email-masked]> wrote:
>

---

From: Michael Richardson <[email-masked]>
Date: Fri, 30 Oct 2015 11:47:28 -0400

Malisa Vucinic <[email-masked]> wrote:
    > From the point of view of code reuse, DTLS seems to make sense but I
    > think we would really need to find a way of getting rid of 10+ packets
    > to get things going, particularly when we can leverage PSKs. Looking at
    > draft-ietf-dice-profile, it seems that session resumption could help us
    > for that. I am thinking whether it would make sense for the JN to
    > initiate the handshake using session resumption without server-side
    > state (RFC 5077) and get the handshake done in 1.5 exchanges when PSK
    > is in place. Or in case we decide that JN should be a DTLS server and

It's something that I considered as well, except that I would reverse the
negotiation.   Have the JCE initiate to the JN (the JA relays packets).

The process could look like this:
    1) JA lets the JCE know of it's existence (TBD)
    2) JCE talks to vendor, gets stateless session-resumption token from
       vendor.  That's an entire protocol, but it's a protocol that doesn't
       need to run over the LLN... and the data could instead be delivered
       by USB key, or QR code... clearly it needs to be remain confidential.
    3) JCE initiates to JN, JN decrypts state.

There are some issues with this.  Essentially,  the entire process is really
protected by the symmetric key that the JN uses to create it's stateless
token.  And the tokens wind up being bearer tokens... whether the tickets are
resuable depends upon how they are made, I think.  If there is more than one
of them, that's another question, but they can be produced by the
manufacturer in a situation where there is lot of power, or the key is
available, etc.

-- 
Michael Richardson
-on the road-

---

From: Michael Richardson <[email-masked]>
Date: Fri, 30 Oct 2015 10:51:05 -0400

{please forgive the lateness of this email. Illness, etc.}
As others have said this is a great analysis.  Thank you so much!
see inline.

case 1A potentially has a significant code-reuse if either MLE or 802.15.9
will be used to establish per-link keys.  Despite the conversation in
subsequent thread, I'm not convinced that a mere 4 messages will suffice
between JA/JCE to perform the mutual authorization required between JCE and
JN.   
Case 1A, might have significant overlaps with the ACP of ANIMA.

Malisa Vucinic <[email-masked]> wrote:
    > Option 2 leverages the DTLS implementation that is in any case mandated
    > by CoAP so it does not necessitate much additional implementation
    > effort, other than the JA relay application. Another advantage here is

So there are several options here, one of which has the JN as a client,
a different one would have the JN as a responder.  There is additionally
a question of whether the DTLS Client/Server direction needs to match
the the CoAP direction.
I think there is a significant need to permit the JCE to manage the order
and bandwidth from the join process.  

This method is also most in-line with the work the Thread Group has done, but
I do not yet know enough about the DTLS extensions they created to make the
work the JA does stateless.    Maybe once I finish reading (2hr more on this
flight, 10h on next one...) I'll be able to say more.

-- 
Michael Richardson
-on the road-

---

From: Michael Richardson <[email-masked]>
Date: Fri, 30 Oct 2015 11:06:08 -0400

> authentication in the JCE instead of in the JA.

It's not really about trusting the JA exactly, but that is an issue.

It is, in my opinion, about cost (RAM/battery) of state (DDoS on JA).
The other side of the question is what does the JCE provide the JA
that it can use to authenticate the network to the JN, and which the JN can
validate.  That's where the trust issue is really. 

It would be useful for the 6tisch *SPECIFIC* situation if we could better
understand what the power/connectivity of the JA might be.   If in a typical
6tisch industrial setting, if we could assume the JA were more powerful, that
would change things.  In a generic LLN things would be different.

    > membership management -> you are adding more and more KMP features...

I agree here: having a good KMP is really useful.

-- 
Michael Richardson
-on the road-

---

From: Michael Richardson <[email-masked]>
Date: Fri, 30 Oct 2015 11:30:49 -0400

> quickly with 4 messages might be better.

The joining process runs once.
This is in the architecture document.

6tisch is not, btw, about remote controllers in a home, so it's important to
use reasonable use cases.

But, in that case, the remote control would have been provisioned with a
locally significant certificate (not RPK) which a 802.15.9 KMP could use
(with a 4 message exchange) to establish new per-peer pairwise (does 802.15.9
have a better word for that, btw?) keys.  

(However, I don't know if I'd care to do per-peer pairwise keying for a
homenet: I'd might prefer a network-wide K2, and a protocol to rekey K2
weekly, or whenever my house guests leave.)

    > between devices, nor it can do rekeys etc. Or that is at least what I

PANA is mostly just a container for EAP, and one can use some MSK parts to
secure the PANA channel.

    > KeyIndex 0x02 and KeySource of 0xdcac000000000002 to joining device.

I agree.  The problem is transitive trust and authorization during enrollment.

-- 
Michael Richardson
-on the road-

---

From: Tero Kivinen <[email-masked]>
Date: Sat, 31 Oct 2015 11:09:52 +0200

> The joining process runs once.

Once per which timeframe? Once per lifetime of the device? Once per
while the device is connected to the same network? Once per while
being synced to the network? 

> This is in the architecture document.

Really? Where? 

> 6tisch is not, btw, about remote controllers in a home, so it's
> important to use reasonable use cases.

It would be, but where are those defined. It seems that every time I
talk with people I get different use case requirements.

For example if the joining process is run once by the lifetime of the
device, it does not matter how many frames we send and receive. If you
run joining process every time you join the network, for example after
you were out of radio range, or after power outage, or even after
sleeping so long, that you lost sync, then frame countes are much more
important. 

> have a better word for that, btw?) keys.  

802.15.9 uses the 802.15.4 terminology, i.e. link keys, vs group keys:

link key: A secret key that is shared between precisely two devices.

group key: A key that is known only to a set of devices.

> weekly, or whenever my house guests leave.)

Usually to be able to rekey group keys, you need to have pairwise key,
which can be used to protect the group keys when you send them to
devices which are still part of the network.

And you actually still need to rekey K1 also, as anybody who knows it,
can mess up the network completely. As the TSCH IEs are only sent
inside the EBs, if you want to change them while network is running,
everybody must listen EBs and act if they change. If attacker knows K1
he can send fake EBs which will for example change the slotframe
length or channel offset, causing devices not to hear each other (if
sent to some devices, not everybody).

Slotframes can be added and removed while the TSCH network is running,
so this is expected to work. I do not think timing information (TSCH
Timeslot IE) or the channel hopping information (Channel hopping IE)
should be changed while the network is running, even though I do not
think 802.15.4 or the 6tisch documents forbid that...
-- 
[email-masked]

---

From: Malisa Vucinic <[email-masked]>
Date: Sat, 31 Oct 2015 17:09:55 +0100

It does matter because if the forming a 100-node network takes several hours and depletes a quarter of the battery as nodes cannot efficiently duty-cycle, then the solution we are designing here becomes useless.

> On 31 Oct 2015, at 10:09, Tero Kivinen <[email-masked]> wrote:
>

---

From: Malisa Vucinic <[email-masked]>
Date: Sat, 31 Oct 2015 18:50:36 +0100

> On 30 Oct 2015, at 15:51, Michael Richardson <[email-masked]> wrote:

> and bandwidth from the join process.  

So, the idea in case JN is a DTLS client was that JCE can simply wait with the response to ClientHello, according to its policy and different priorities. But it would be necessary to require differentiation of ClientHello retransmission timeout from other DTLS retransmissions. The main advantage would be that the discovery mechanism of JN is simply a ClientHello, possibly including the session resumption ticket, and no other packets involved.

---

From: Alper Yegin <[email-masked]>
Date: Sat, 31 Oct 2015 23:43:01 +0200

Hello,

I've read the thread. I see there are some PANA-related questions. Let me clarify them.

Like Rafa said, PANA is already adopted and fully defined by Zigbee IP. Hence I'd expect it's ready to be used for 6tisch as well. Are there anything special here in 6tisch that'd make a difference with respect to network access authentication and key management?

PANA assumes the JN has an IP address. That IP address can be a link-local IP address.
(Not sure if this work really needs a solution that operates before *any* IP address is configured on the JN. But if it does, then here's an expired work on that front: https://tools.ietf.org/html/draft-yegin-pana-unspecified-addr-06)

> - Traffic load: minimum 4 messages for PANA + [ 5 messages for EAP-AKA, 15+ messages for EAP-TLS ] + 1 packet to provision K2

Not sure where that "4 messages" come from. It can be "0". See Q16 and Q17 in http://www.panasec.org/docs/PANA-FAQ.txt.
Also that last 1 packet is not needed either. The last packet sent from the authenticator can deliver that payload.

I don't think a separate KMP is needed when we use PANA.
Because:
- EAP/PANA authentication generates PANA SA between the JCE and JN. Which can used for further key derivation. Given the PANA is extensible thru AVPs, additional parameters can be delivered between the end-points if necessary.
- RFC 6786 defines how PANA can carry encrypted payloads, which can be used for delivering keys.

I hope these help.

Alper

---

From: Malisa Vucinic <[email-masked]>
Date: Sat, 31 Oct 2015 22:10:46 +0100

Thanks for the clarification. We are trying to maximize code reuse and minimize number of exchanges. In Q17 I see that Client Initiation message is omitted if network can detect on its own the presence of JN, which is not the case in 6tisch. I suppose that we are then left with EAP overhead plus an extra discovery message.

Regards,
Mališa

> On 31 Oct 2015, at 22:43, Alper Yegin <[email-masked]> wrote:
> 
> Hello,
>

---

From: Carsten Bormann <[email-masked]>
Date: Sun, 01 Nov 2015 07:17:03 +0900

Alper,

I have not read the thread, but I'm trying to understand your suggestion.

PANA and EAP are only carriers for EAP methods.
So the real question is: Which EAP method is going to be used?

If an existing method fits the bill, that would be interesting to know.

If a new method has to be designed, I would like to understand what the
effect is of having to phrase that method in EAP terms (e.g., as opposed
to directly using that exchange e.g. via 6top).

Grüße, Carsten

---

From: Robert Cragie <[email-masked]>
Date: Sun, 1 Nov 2015 00:39:40 +0000

In ZigBee IP, using EAP-TLS allowed potential re-use of TLS library for
both network access and application security. Some perceive it as a
"heavyweight" solution but I have yet to come across anything significantly
lighter weight, taking into consideration all aspects of the initial
exchange, including discovery, relay etc.

Robert