Subject: [6tisch] about the secure join process

From: Giuseppe Piro <[email-masked]>
Date: Mon, 7 Sep 2015 09:41:25 +0200

Dear all,

I'm trying to capture assumptions and goals related to the join process, as
discussed during the latest conf call. It is just to verify that everything
is clear in my mind :-)

Please, reply and correct me if I'm wrong.

*Initial assumptions:*
- all nodes known K1.
- each node shares a PSK with the JCE. It is used for authentication
purposes during the join process.
- the join process is handled at the aplication layer through COAP. A
message is sent by the JN, forwarded by the JE and processed by the JCE.
- if the JN is authenticated by the JCE, the JCE sends the K2 (stored and
encrypted with the aforementione PSK in a COAP message).
- JN processes the received COAP message and installs K2.

*Main open issues:*
- messages exchanged between JN and JA must be "protected". For the moment
we can assume to use K1.
- JA does not know JN; it does not have the corresponding Device Descriptor
for JN; it must implemnet a procedure for understanding if the join message
should be forwarded or not (protection against DoS ? ).
- the format of join packets should be defined. Input from COSE. The first
packet sent by JN should also contain the ASN (of course, also this field
is protected by the PSK). This should avoid replay attacks.
- definition of mechanisms for installing K2 in JN.
- the distribution of link layer keys is another problem. Two
possibilities: centralized (JCE distribute keys) or distributed (KMP).
SHould we define procedures/message formats for both of them ?

*Possible extensions:*
- substitute PSK with certificates .

Starting from these premises, it seems that the main action points to
target for the moment are:
- definition of join packets along side COSE inputs
- procedures to implement at the JA side, i.e., before forwarding the join
packet towards the JCE

Does it make sense ?

All the best
Giuseppe

-- 
*Giuseppe Piro, PhD*
Post Doc Researcher
DEI, Politecnico di Bari
via Orabona 4 - 70125 (Bari), Italy.
email: [email-masked]
phone: +39 080 5963301
web: g <http://telematics.poliba.it/piro>iuseppepiro.com

---

From: Tero Kivinen <[email-masked]>
Date: Mon, 7 Sep 2015 13:55:41 +0300

Giuseppe Piro writes:
> Initial assumptions:
> - all nodes known K1.
> - each node shares a PSK with the JCE. It is used for authentication purposes
    	      	     ^^^^^
I assume this means is unique PSK per JN with the JCE, right?

> during the join process.
> - the join process is handled at the aplication layer through COAP. A message
> is sent by the JN, forwarded by the JE and processed by the JCE.
     	     	     	       	      ^^
I assume this is JA?

> Main open issues:
> - messages exchanged between JN and JA must be "protected". For the moment we
> can assume to use K1.

If K1 is known by all nodes, does not protect, or even "protect" the
exchanges. There is no benefit in security for using well known key
for joining. There is little benefit for using widely known group
shared key K1 in security. There is bit of security if you use group
shared key which is rekeyed every now and then. There is bit more
security if the group shared key is rekeyed every time anybody leaves
the group.

I assume you put word protected in quotes to trying to indicate that
it offers less security than real key, but as it offers NO security
benefit, it is better not to claim that those messages are secured or
protected or "protected" in any way.

> should be forwarded or not (protection against DoS ? ).

It could use 802.15.9 and create pairwise key between JA and JN using
authentication that is forwarded to the JCE. In that case only the
authentication requests and replies needs to be forwarded, not full
joining exchanges.

This does not really protect against DoS, as if you do not know who
the other end is, and you have not authenticated, there is not really
that much you can do. You can blacklist the address after first fail,
but attacker can use different address for each attack, you can rate
limit the requests, but that will cause DoS anyways, as legitimate
devices cannot now join anymore etc.

If you do KMP between JN ja JA, then at least the attack is localized,
and load is distributed. I.e. JN and JA does about same amount of
work, but rest of the network and JCE does much less work, than if all
joining messages are always forwarded to the JCE.

> packet sent by JN should also contain the ASN (of course, also this field is
> protected by the PSK). This should avoid replay attacks.

With ASN you need to define the timing constraints, i.e. how old ASNs
you are willing to accept? It might take quite a few ASNs before the
message from JN reaches JCE. Actually simple counter might be easier,
as you can simply assume that valid JN always increments the counter
before trying to join, so if you see same (or smaller) counter later,
you know it is replay. 

> - definition of mechanisms for installing K2 in JN.

802.15.9?

> - the distribution of link layer keys is another problem. Two possibilities:
> centralized (JCE distribute keys) or distributed (KMP). SHould we define
> procedures/message formats for both of them ?

802.15.9?

> Possible extensions:

802.15.9... 
-- 
[email-masked]

---

From: Alexander Pelov <[email-masked]>
Date: Mon, 7 Sep 2015 14:31:27 +0200

Dear all,

In our proposal for managing long-range radio networks with CoAP ( https://tools.ietf.org/html/draft-pelov-core-cosol-00 <https://tools.ietf.org/html/draft-pelov-core-cosol-00> ) we’re using EAP-over-CoAP. The use of CoAP as signaling protocol, makes it natural to go to this solution, as this way we can reuse the whole EAP framework that’s already in place. 

Afterwards, you could use of your choosing either EAP-PSK or any other mechanism which would be deemed fit (e.g. certificates, USIM cards, …).

EAP is already used for authentication and authorization in WiFI with WPA/WPA2, WiMax (maybe not the best example..), UMTS, LTE, … and for me is one of the few truly extensible ways for doing it (I’m still looking at OAuth for that, but for me the two are complementary solutions).

I’m sorry to have been absent in the last conf call, but if you want we can discuss this in the next one.

Best,
Alexander

> Le 7 sept. 2015 à 09:41, Giuseppe Piro <[email-masked]> a écrit :
> 
> Dear all, 
> 
> I'm trying to capture assumptions and goals related to the join process, as discussed during the latest conf call. It is just to verify that everything is clear in my mind :-) 
> 
> - each node shares a PSK with the JCE. It is used for authentication purposes during the join process.
> - the join process is handled at the aplication layer through COAP. A message is sent by the JN, forwarded by the JE and processed by the JCE.
> - if the JN is authenticated by the JCE, the JCE sends the K2 (stored and encrypted with the aforementione PSK in a COAP message).
> - messages exchanged between JN and JA must be "protected". For the moment we can assume to use K1. 
> - JA does not know JN; it does not have the corresponding Device Descriptor for JN; it must implemnet a procedure for understanding if the join message should be forwarded or not (protection against DoS ? ).
> - the format of join packets should be defined. Input from COSE. The first packet sent by JN should also contain the ASN (of course, also this field is protected by the PSK). This should avoid replay attacks.
> - the distribution of link layer keys is another problem. Two possibilities: centralized (JCE distribute keys) or distributed (KMP). SHould we define procedures/message formats for both of them ?
> 
> Possible extensions:
> Starting from these premises, it seems that the main action points to target for the moment are:
> - procedures to implement at the JA side, i.e., before forwarding the join packet towards the JCE
> 
> 
> Does it make sense ? 
> 
> All the best
> Giuseppe
> 
> 
> -- 
> Giuseppe Piro, PhD
> Post Doc Researcher
> DEI, Politecnico di Bari
> email: [email-masked] <mailto:[email-masked]>
> phone: +39 080 5963301
> web: g <http://telematics.poliba.it/piro>iuseppepiro.com <http://iuseppepiro.com/>_______________________________________________
> 6tisch mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/6tisch

---

From: Malisa Vucinic <[email-masked]>
Date: Mon, 7 Sep 2015 19:44:59 +0200

> On 07 Sep 2015, at 12:55, Tero Kivinen <[email-masked]> wrote:
> 
> for joining.

I think we all agree on this. Since JN and JA do not share any pre-existing crypto material, we rely on leap-of-faith for the initial exchange(s).

> authentication requests and replies needs to be forwarded, not full

I think we agree that only JCE can authenticate JN based on a PSK and that this ends up at JCE in any case. What do you mean by full joining exchanges? How many packets between JN <-> JA <-> JCE do you consider necessary, strictly from a security perspective?

> joining messages are always forwarded to the JCE.

How can JN and JA run a KMP when they don’t share any crypto material? Are you assuming certificates for mutual authentication here? 

> before trying to join, so if you see same (or smaller) counter later,

I am not sure the management of per-node, join-specific replay counters in a large network is simpler than comparing if ASN_received > ASN_now - window.
But since JCE may not necessarily know the topology, I agree that estimating the window size would add additional complexity, when PCE and JCE are not collocated.
An important point there is that JN must write the counter in non-volatile memory after each join re-try.

Regards,
Mališa

---

From: Michael Richardson <[email-masked]>
Date: Mon, 07 Sep 2015 21:14:35 -0400

Alexander Pelov <[email-masked]> wrote:
    > In our proposal for managing long-range radio networks with CoAP (
    > https://tools.ietf.org/html/draft-pelov-core-cosol-00 ) we’re using
    > EAP-over-CoAP. The use of CoAP as signaling protocol, makes it natural
    > to go to this solution, as this way we can reuse the whole EAP
    > framework that’s already in place.

EAP-over-CoAP is probably a better choice than over PANA :-)

But, it seems to me that it ought to be EAP-over-DTLS-over-CoAP,
with the result being creation of a CoAPS context.

In either case, if you are really doing EAP-TLS, then you wind up with
a ridiculous number of layers.

One can then run EST or something similar over it.

Your document seems to intersect with a bunch of other work, I hope to get
back to you with some additional comments.

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

---

From: Alexander Pelov <[email-masked]>
Date: Tue, 8 Sep 2015 10:11:45 +0200

Dear Michael,

> Le 8 sept. 2015 à 03:14, Michael Richardson <[email-masked]> a écrit :
> 
> 

I think that you don’t really need DTLS, just the same way you don’t have encryption in 802.1X. 

You’re only transporting the EAP messages. If you want, you could do EAP-TLS, but I would be more interested in EAP-PSK and EAP-AKA.

> back to you with some additional comments.

I would be happy to discuss the different points on which we can collaborate and discuss.

Best,
Alexander

---

From: Tero Kivinen <[email-masked]>
Date: Tue, 8 Sep 2015 14:03:39 +0300

Malisa Vucinic writes:
> I think we agree that only JCE can authenticate JN based on a PSK
> and that this ends up at JCE in any case. What do you mean by full
> joining exchanges? How many packets between JN <-> JA <-> JCE do you
> consider necessary, strictly from a security perspective?

If you use 802.15.9 with IKEv2 (I use that as an example as I know it
best), and you use mutual EAP-AKA for IKEv2 authentication the
exchange would be as follows:

JN	       	  JA			   JCE/AAA
==		  ==			   =======

IKE_SA_INIT ------>

<------ IKE_SA_INIT

IKE_AUTH ---------> (1)

		    EAP-Response/Identity --> (2)

		    <----- EAP-Request/AKA-Challenge

<---------- IKE_AUTH (3)

IKE_AUTH ---------> (4)

	 	    EAP-Response/AKA-Challenge --> (5)

		    <----- EAP-Success

<---------- IKE_AUTH (6)

After that exchange the JN and JA share key generated by IKEv2, and JN
has been authenticated using EAP-AKA, and the JN can trust that JA is
someone who can connect to JCE and that authenticates network for him.

(1) This message already contains the ID, so the EAP Identity request
and response messages are omitted.

(2) This EAP-Response/Identity is generated based on the IKEv2 ID
inside the IKE_AUTH, and it is transmitted using whatever protocol
that is there for JA to talk to JCE. The protocol could be RADIUS,
Diameter, or EAP over CoAP or whatever. This authentication needs to
be secured, so that nobody not in the network cannot do authentication
requests, but as JA is already part of the network and shares key with
JCE this should be easy.

(3) This IKE_AUTH contains the AKA-Challenge request received from
JCE.

(4) This IKE_AUTH contains the AKA-Challenge response generated by JN.

(5) JA takes the AKA-Challenge response from IKE_AUTH and forwards it
to the JCE. If JCE verifies the response, it will send EAP-Success
indicating that JN should be allowed to join.

(6) this IKE_AUTH will contain the EAP-Success, and it will finish
creating the keying material used between JN and JA. The JA will
already at that point know that JN is authenticated, so it can also
send all group shared keys inside that IKEv2 message to distribute
group keys to the JN.

After that the JN can start TSCH related joining process, i.e.
associate itself to the network to get short address, and allocate
required transmission slots. All this is already secured by either the
link key shared between JN and JA, or group key sent by the JA to the
JN after JN has been authenticated.

Instead of IKEv2, you can most likely use also other KMPs specified in
the 802.15.9 (802.1X, IKEv2, HIP, PANA, Dragonfly).

> How can JN and JA run a KMP when they don’t share any crypto
> material? Are you assuming certificates for mutual authentication
> here?

They could use certificates, but they can also use EAP or similar to
delegate the authentication step to the JCE, as explained above.

> I am not sure the management of per-node, join-specific replay
> counters in a large network is simpler than comparing if
> ASN_received > ASN_now - window.

Only the JCE needs to keep track of that counter for everbody in the
network, and JCE already stores keying material and other information
about all possible JNs that might join, so adding 4-octet counter
there is not that big increase. Then all nodes need to store their own
counter and increment it every time they join the network. 

> But since JCE may not necessarily know the topology, I agree that
> estimating the window size would add additional complexity, when PCE
> and JCE are not collocated.

You also have to take in to account that some of the frames from JA to
JCE might need to be retransmitted, and you have to wait for links
between each nodes the frame might go through etc. If you know the
network topology completely, and know their retranmission counters,
you might estimate the number, but easier might be just to use
something like 30 seconds for it, and convert that to ASNs. 

> An important point there is that JN must write the counter in
> non-volatile memory after each join re-try. 

Yes. Usually nodes do not join the network that often. As the joining
process most likely will take several tens of seconds, you might need
to increment joining counter once per minute, but after few tens of
tries you should really give up and realize you are not
authenticated... Of course if you use for example EAP-AKA challenge
response style, then there is no point of having such counter, or
actually if you use KMP betwen the JN and JA, that will also protect
against replays (at least most of the KMPs will provide that feature). 
-- 
[email-masked]

---

From: Giuseppe Piro <[email-masked]>
Date: Wed, 9 Sep 2015 17:39:02 +0200

Dear Tero,

many thanks for your feedbacks: somethings are more clear now and other
suggestions helped me to identify issues and/or solutions.

More comments below.

On Mon, Sep 7, 2015 at 12:55 PM, Tero Kivinen <[email-masked]> wrote:

> purposes

​Yes
​

> message
​Yes
​

> protected or "protected" in any way.

​I agree with you. "protect" (protect with quotes) means that messages are
encrypted and authenticated through CCM* primitives, even if the well-know
key K1 is used (=no protection).
For the moment this assumption is needed for reaching a preliminary
configuration that may run on real devices and is fully compatible with
IEEE 802.15.4e-2012. For what I've understood, this follows the same
approach followed in the 6tisch-minimal. Please, correct me if I'm wrong.

​

> joining messages are always forwarded to the JCE.
​I agree. A local authentication (i.e., between JN and JA) could ​isolate
the attack. I've already highlighted this aspect during the previous con
call.

> before trying to join, so if you see same (or smaller) counter later,

​Totally agree.
​

> possibilities:

​Yes, ok. 802.15.9 is now on the list (... my list ...) of mechanisms to
integrate in the join process.​

​Giuseppe​

-- 
*Giuseppe Piro, PhD*
Post Doc Researcher
DEI, Politecnico di Bari
via Orabona 4 - 70125 (Bari), Italy.
email: [email-masked]
phone: +39 080 5963301
web: telematics.poliba.it/piro

---

From: Malisa Vucinic <[email-masked]>
Date: Fri, 11 Sep 2015 13:05:47 +0200

It seems that this would trigger the exchange of:

(1) 6 packets between JN and JA,
(2) 4 packets between JA and JCE on a multi hop path.

Communication of (1) happens in the shared slot so collisions are likely. Communication of (2) happens over multiple hops so it affects the network.

I am skeptical how this would look like in terms of delay for the initial formation of a large network and in your example bellow JA learns that JN is valid only in step (6) at the end of the exchange, when 4 packets have already traversed the whole network. In that sense, I don’t see any benefit from JA there, except that we can get rid of one packet, EAP identity request… Am I missing something?

What do we loose in terms of security if JN simply uses its PSK to generate a MAC protected COSE object that can fit in one radio frame that JA forwards to JCE? We said that we can protect from replay either using ASN or a monotonic counter local to JN. In that case, it would suffice that JCE verifies the object and creates a new one that JN can accept, encapsulating whatever domain-specific keys are necessary… 

This would result in:

(1) 2 packets between JN and JA,
(2) 2 packets between JA and JCE on a multi hop path.

This roughly reduces the latency by a factor of 3 for the most critical stochastic part, and by a factor of 2 for the deterministic part…
I realize that we are not doing challenge-response there but I am not clear what do we really loose since JCE takes care of replay protection from a rogue JN, and JN can make sure that it does not use the PSK with the same IV more than once?

Regards,
Mališa

> On 08 Sep 2015, at 13:03, Tero Kivinen <[email-masked]> wrote:
>

---

From: Tero Kivinen <[email-masked]>
Date: Fri, 11 Sep 2015 15:20:26 +0300

Malisa Vucinic writes:
> Communication of (1) happens in the shared slot so collisions are likely.
> Communication of (2) happens over multiple hops so it affects the network.
> 
> I am skeptical how this would look like in terms of delay for the initial
> formation of a large network and in your example bellow JA learns that JN is
> valid only in step (6) at the end of the exchange, when 4 packets have already
> traversed the whole network. In that sense, I don’t see any benefit from JA
> there, except that we can get rid of one packet, EAP identity request… Am I
> missing something?

After this exchange we have following things set up:

1) JN and JA share unique link key that can be used to encrypt and
   aute authenticate traffic between them.
2) JN has received group key information from the JA.
3) JA has received authorization from the JCE, that JN can join the
   network, and that his credentials match.
4) JN will know that network he is joining is authenticated.
5) JN, JA, and JCE are sure the exchange is fresh, and cannot be
   replayed.
6) JN and JA also share KMP connection that can be used to add, delete
   or modify existing keys between them, i.e. do rekey etc.

> What do we loose in terms of security if JN simply uses its PSK to
> generate a MAC protected COSE object that can fit in one radio frame
> that JA forwards to JCE? We said that we can protect from replay
> either using ASN or a monotonic counter local to JN. In that case,
> it would suffice that JCE verifies the object and creates a new one
> that JN can accept, encapsulating whatever domain-specific keys are
> necessary…

It depends what kind of authentication protocol you are going to
create to run between JN, JA and JCE. You are talking about creating
new protocol, and claiming that it would be just "simply using PSK to
generate MAC protected COSE object", and that we somehow use ASN or
monotonic counter to protect replays. And then just sending some
encapsulated keys back...

This is not as easy as it sounds. The devil is in the details, i.e.
actually specifying this new authentication protocol so it is actually
secure and offers the features we need is not that simple.

You most likely need some kind of challenge response system so JN can
know that JCE really answered to the request he send, and attacker
cannot use old reply from JCE. JA needs to know the result of the
exchange between JCE and JN so it can know whether JN is valid. Doing
that all in messages that are less than 100 bytes is even harder.

This is the reason why 802.15.9 decided AGAINST making their own key
management protocols. All key management protocols in 802.15.9 are
already specified somewhere else. I think it would be bad idea to
start designing this kind of protocol here in this WG.  

> This roughly reduces the latency by a factor of 3 for the most critical
> stochastic part, and by a factor of 2 for the deterministic part…
> I realize that we are not doing challenge-response there but I am not clear
> what do we really loose since JCE takes care of replay protection from a rogue
> JN, and JN can make sure that it does not use the PSK with the same IV more
> than once?

To be able to see what we loose and what kind of attacks are possible,
we would first need to see the actual protocol between JN and JA, and
between JA and JCE. Before we see the protocol we do not know what we
loose... 
-- 
[email-masked]

---

From: Giuseppe Piro <[email-masked]>
Date: Fri, 11 Sep 2015 14:28:32 +0200

Hello Malisa,

The traffic load generated during the join process could be an
important aspect to consider. Thanks for the mail.

However, if you use only PSK + COSE, you are imposing that a message
received by the JA must be forwarded towards the JCE.  Is the network
vulnerable against DoS and DDoS attacks (same comment discussed during
the last phone conf) ?

Please, have a look to the following examples.

If you have a legitimate JN, the exchange of messages is simple:

         legitimate JN ---(1)--> JA ---(2)--> X ---(2) --> JCE

         legitimate JN <---(4)-- JA <---(3)-- X <---(3) -- JCE

where
X is a generic intermediate node (we have a multihop network)
(1) join request message containing COSE object and processed at the
MAC layer through K1
(2) join request message forwarded by JA or intermediate node X
towards JCE. It can be protected at the MAC layer through network-wide
keys or unicast layer-2 keys.
(3) join response message forwarded by JCE or intermediate node X
towards JN. It can be protected at the MAC layer through network-wide
keys or unicast layer-2 keys. It contains network-wide keys or any
other key materials (in a COSE object, I guess)
(4) join response message sent by JA to JN. It is processed at the mac
layer through K1. It contains network-wide keys or any other key
materials (in a COSE object, I guess)

If you have a malicious JN (or more malicious JNs), the exchange of
messages could be:

         malicious JN ---(1)--> JA ---(2)--> X ---(2) --> JCE

         malicious JN              JA <---(3)-- X <---(3) -- JCE

where
(1) malicious join request message containing malicious COSE object
and processed at the MAC layer through K1
(2) malicious join request message forwarded by JA or intermediate
node X towards JCE. It can be protected at the MAC layer through
network-wide keys or unicast layer-2 keys.

--- in the middle time JCE verifies that the request is not legitimate
and stores somethings in its database and announces this to the JA ---

(3) join response message forwarded by JCE to _only_ JA. It can be
protected at the MAC layer through network-wide keys or unicast
layer-2 keys. IMPORTANT: It contains details about the fail of the
join process.

-- details stored in (3) are used by JA for avoid to accept any other
packets from that malicious JN ---

Now, what happens if you have many malicious JNs ? What happens if JS
moves and try to join from different JAs ?  Therefore, PSK +COSE
reduces the number of messages... but makes the network vulnerable
against DoS and DDoS.

Does it make sense ?  What do you think ? How do you suggest to handle
this aspect ?  Probably I did not understand well what you have in
mind... so, please, clarify this aspect.

All the best,
Giuseppe

On Fri, Sep 11, 2015 at 1:05 PM, Malisa Vucinic <[email-masked]> wrote:
> valid only in step (6) at the end of the exchange, when 4 packets have
> already traversed the whole network. In that sense, I don’t see any benefit
> from JA there, except that we can get rid of one packet, EAP identity
> request… Am I missing something?
>
> What do we loose in terms of security if JN simply uses its PSK to generate
> a MAC protected COSE object that can fit in one radio frame that JA forwards
> to JCE? We said that we can protect from replay either using ASN or a
> monotonic counter local to JN. In that case, it would suffice that JCE
> verifies the object and creates a new one that JN can accept, encapsulating
> whatever domain-specific keys are necessary…
>
> This would result in:
>
> what do we really loose since JCE takes care of replay protection from a
> rogue JN, and JN can make sure that it does not use the PSK with the same IV
> more than once?

web: giuseppepiro.com

---

From: Giuseppe Piro <[email-masked]>
Date: Fri, 11 Sep 2015 16:20:03 +0200

Hello Malisa,

just another little consideration.

In the case we would still consider PSK + COSE for handling the join
procedure at the application layer, can we introduce a pre-join phase
between JN and JA, useful for  authenticating JN locally ?

It can be done by 6top, for example.

Some possibilities may exist.

- JN sends a certificate. JA knowns that CA and verifies the
certificate. Then JA assists JN in the join process.
- JN sends a certificate. JA does not known that CA and it cannot
verify the certificate. JA may be configured for running different
behaviors (i.e., accept the request and postpone the authentication to
the JCE; discard the join request, ... other ? )
- JN does not have a certificate. JA may follow the same decisions as
in the previous point.
- other ?

Hence, we may have join procedure at the application layer (COSE) and
a pre-join process at the MAC/6top layer.

Does it make sense ?

Giuseppe

---

From: Malisa Vucinic <[email-masked]>
Date: Fri, 11 Sep 2015 22:03:11 +0200

> On 11 Sep 2015, at 14:28, Giuseppe Piro <[email-masked]> wrote:
> 
> Hello Malisa,
> 
> packets from that malicious JN —

Malicious JN can always change its address for the new request and there’s nothing in (3) that can prevent this. More importantly, there is nothing we can do about that - it will no matter what result in DoS as JA will be unavailable to handle requests from legitimate JNs. Tero detailed on this in one of his previous emails.

The question is whether we will exchange 1 packet between JA and JCE or 4. This exchange *has* to end up at JCE as JA does not have any means to authenticate JN at that point. We are talking about the case where each JN has a different PSK imprinted, and only JCE knows the corresponding address/PSK binding. Intermediate nodes, i.e. JAs do *not* know the key of JN and thus cannot authenticate it… 

> reduces the number of messages... but makes the network vulnerable

See above, I think you are assuming that JA can authenticate JN by some means. This may not be possible even with certificates as JN and JA may not share the CA when they first join. Imagine two devices from two different manufacturers, each one has a certificate signed with manufacturer’s CA. How will JA verify the certificate issued by JN’s CA that it has never heard of… Even if devices share the common CA, JA would need to communicate with JCE for every JN in order to decide if node XYZ should be allowed to join the network, and then you have a similar problem of DoS as above. Note that although JN is authenticated, it is not yet authorized to join. JA is just one of the nodes in the network, it cannot decide which devices should be allowed to join and which shouldn’t. JCE will likely have an ACL with all the nodes it physically owns but you cannot expect each potential JA in the network to have the same list… 

Once JCE admits JN to the network, it shares with it some locally significant material, like a new certificate from network’s CA or a symmetric key. This locally-significant material can be an input for the following phases and just then we can assume that JN, JA  and other JN’s radio neighbors can mutually authenticate themselves, derive keys, negotiate keys, etc...

Does that make sense? 

Mališa

---

From: Malisa Vucinic <[email-masked]>
Date: Fri, 11 Sep 2015 22:36:21 +0200

> On 11 Sep 2015, at 16:20, Giuseppe Piro <[email-masked]> wrote:
> 
> Hello Malisa,
> 

Sorry, did not read this email before sending the previous one.

I don’t understand what do you consider as a start state of JN here, when it first tries to join. Is it a certificate or a PSK?

I think we agree that with PSKs, JA cannot help much?

With certificates, I agree with you that *if* JA could authenticate the JN before forwarding the message, it would reduce the risk but still wouldn’t completely eliminate it, as JN needs to be authorized by JCE to join. The details would depend on the exact forwarding mechanism and if/how we decide to use COSE…

Regards,
Mališa

---

From: Giuseppe Piro <[email-masked]>
Date: Fri, 11 Sep 2015 23:03:58 +0200

> I don’t understand what do you consider as a start state of JN here, when it
> first tries to join. Is it a certificate or a PSK?
>
> With certificates, I agree with you that *if* JA could authenticate the JN
> before forwarding the message, it would reduce the risk but still wouldn’t
> completely eliminate it, as JN needs to be authorized by JCE to join. The
> details would depend on the exact forwarding mechanism and if/how we decide
> to use COSE…
>

With PSK, JA cannot help. I believe this is true.  I also agree that
JCE may authorize JN.

I'm just thinking to a mechanism that may help JA to authenticate
locally JN. I've called this mechanism "pre-join" scheme. The name
could be not correct at all, let's just try to understand if it could
be useful or not :-)

JN sends its certificate to JA ... and other fields that demonstrates
the posses of the private key associate to the certificate, like the
sign of the (ASN + Mac address).. or something like that.

If JA knows the CA, it is simple to find the end of the story. If
not... we can define multiple behaviors:
- accept anyway the initialization of the join process and give the
change to authorize JN to the JCE
- discard the message (this cannot be acceptable for networks made up
by nodes provided by different vendors, as you said in your mail)
- retrieve the CA's public key elsewhere and then come back to JN

What do you think ?

Giuseppe

---

From: Malisa Vucinic <[email-masked]>
Date: Fri, 11 Sep 2015 23:34:34 +0200

> On 11 Sep 2015, at 14:20, Tero Kivinen <[email-masked]> wrote:
> 
> cannot use old reply from JCE.

This scenario would correspond to ‘hijacking’ a JN and installing it in a different network than the one it was programmed to join, I suppose?

> JA needs to know the result of the
> exchange between JCE and JN so it can know whether JN is valid.

Not sure I agree with this, why couldn’t JN and JA authenticate themselves once JCE has shared network keys/certificates to JN. Or you are considering DoS attack on JA by a rogue JN? 

Consider for instance K1 and K2 from minimal, where JCE shares K2 with JN as a result of the join. As soon as JN has K2, it can start exchanging securely with JA (or any other neighbor) through the knowledge of ASN. I don’t see the need to do anything else there, do you? Of course, JCE then needs to handle updates of K2 but that’s another story.

> Doing

That, I agree :-). 

> start designing this kind of protocol here in this WG.  

Ok, I see your point. If you don’t think we should design a new one, is there something already specified that does not require 10+ exchanges that we could use?

Regards,
Mališa

---

From: Tero Kivinen <[email-masked]>
Date: Mon, 14 Sep 2015 04:14:32 +0300

Malisa Vucinic writes:
> With certificates, I agree with you that *if* JA could authenticate
> the JN before forwarding the message, it would reduce the risk but
> still wouldn’t completely eliminate it, as JN needs to be authorized
> by JCE to join. The details would depend on the exact forwarding
> mechanism and if/how we decide to use COSE…

Note, that using IKEv2 and 802.15.9, it would be possible to use
multiple authenticatiom rounds (rfc 4739), i.e. where the JN first
authenticates himself to the JA by using for example certificates
generated by manufacturerer. Before this step the JA will be
configured with all CAs for all manufacturers who can connect.

After this step JA will know that JA is device which is created by one
of the allowed manufacturers, and if that manufacturer certificate
includes the 64-bit extended address, JA will know that JN has that
extended address.

Then on step 2 it can use multiple authentication to forward the
authentication and authorization to the JCE using suitable EAP method
or similar.

This will solve the problem that attacker cannot just change it
address to do another attack agains JCE, the JA has already verified
that the manufacturer certificate was used in authentication before it
even connects JCE, and if that authentication or authrozation fails,
it can blacklist that extended address to protect himself against
further attacks from that JA.

This is one of the reasons I think we need to use proper external key
management protocol, as they have these features already standardized,
and we just need to pick and choose which of those features we want to
use.

In one environment this would not be needed, on other environment it
might be very important. If we just start rolling our own KMP then we
end up some thing that might work with some setups, but might miss
features we need for another setup, and to add that feature would
require us to extended the protocol taking few years...
-- 
[email-masked]

---

From: Tero Kivinen <[email-masked]>
Date: Mon, 14 Sep 2015 04:29:27 +0300

Malisa Vucinic writes:
> Ok, I see your point. If you don’t think we should design a new one,
> is there something already specified that does not require 10+
> exchanges that we could use?

Depends on your requirements and what kind of authentication and
authorization you are doing.

The example I gave with IKEv2 + EAP-AKA is 3 exchanges between JN and
JA (exchange = message pair, i.e. one request and one reply) and 2
exchanges between JA and JCE.

The exchanges between JN and JA would most likely be fragmented as
they will not fit 100 bytes, so actual 802.15.4 frames count is even
higher. The exchanges between JA and JCE can most likely be fit in
802.15.4 frames, so they are single frames.

I am not expert in EAP methods, so I have not really checked what can
be done there, but they usually do require two exchanges between JA
and JCE, as there needs to be some kind of challenge from JCE to be
sent to the JN through JA, and JN needs to reply to that, and only
after that JCE can signal JA and JN that authentication and
authorization is successful.

There might be some method where the challenge might be generated in
such way that JA could generate it and forward both the challenge it
generated and the reply from JN to the JCE, but in that case I think
that puts more trust on the JA by the JCE, and I do not know if there
us such EAP method, and how secure it is.
-- 
[email-masked]

---

From: Michael Richardson <[email-masked]>
Date: Mon, 14 Sep 2015 12:48:00 -0400

> includes the 64-bit extended address, JA will know that JN has that

This would be a very good idea.

I hadn't thought of using IKEv2's ability, but I really like it,
and it integrates so nicely into the 15.9 mechanism already.

    > and we just need to pick and choose which of those features we want to

:-)

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

---

From: Michael Richardson <[email-masked]>
Date: Mon, 14 Sep 2015 13:52:34 -0400

Malisa Vucinic <[email-masked]> wrote:
    > I think we all agree on this. Since JN and JA do not share any
    > pre-existing crypto material, we rely on leap-of-faith for the initial
    > exchange(s).

I guess it depends upon whether you expect JN/JA to for a secure
per-host-pair adjancy during the bootstrap process.  I don't see the point.

    > I think we agree that only JCE can authenticate JN based on a PSK and
    > that this ends up at JCE in any case. What do you mean by full joining
    > exchanges? How many packets between JN <-> JA <-> JCE do you consider
    > necessary, strictly from a security perspective?

All the relevant protocols require between 2 and 3 round trips to get
things working.  How many fraglets that works out depends upon how big
the certificate chains (if any) are sent.

---

From: Michael Richardson <[email-masked]>
Date: Mon, 14 Sep 2015 13:55:05 -0400

> exchange would be as follows:

I think you are suggesting EAP-AKA because it's a good secure way to leverage
what are essentially pre-shared keys (using "soft-SIMs") using EAP, not
because you imagine having a SIM (AKA) card in the end points.

---

From: Michael Richardson <[email-masked]>
Date: Mon, 14 Sep 2015 14:22:04 -0400

> could be not correct at all, let's just try to understand if it could

It would be valuable if the JA had a way to either recognize potentially
legitimate nodes (and prioritize their traffic), or alternately, could find a
way to stop talking to malicious nodes.

    > sign of the (ASN + Mac address).. or something like that.

So there is a tension between a number of factors:

1) how much work can we insist that a JN do before joining?
   (signing the ASN implies freshness, but if can do that, then maybe
   you can sign some other challenge that comes from the JCE)

2) how much work can the JA be asked to do in order to validate this pre-join
   token?

3) how expensive is bandwidth at various depths of the tree vs computation
   power?

4) given that we are going to bandwidth (energy-limit) the joining process,
   how long does the process take even in the absense of attackers?

This problem is very much like what the IPSECME WG has been discussing
in http://datatracker.ietf.org/doc/draft-ietf-ipsecme-ddos-protection/

An attacker are able to leverage significant amounts of computational power
From a relative point of view, and usually has an unlimited power budget.

That's why I felt that the JA should do as little as possible (and have as
little custom code for the join processing: i.e. reuse existing mechanisms).
That the join process should be driven/managed by the JCE as it potentially
has resources similar to the attacker.

---

From: Tero Kivinen <[email-masked]>
Date: Tue, 15 Sep 2015 07:37:00 +0300

> because you imagine having a SIM (AKA) card in the end points.

Actually I was talking about the EAP-AKA as someone used it as an
example that we could just use EAP, and then I said you could use
IKEv2 and used same EAP method. Also it was one of those where I knew
how many exchanges there is and that it do support mutual
authentication...

There would be other EAP methods that would be usable too, but as I am
not expert on them, I cannot say which would be best.

So soft-SIMs would be it, and no I do not expect there to be actual
SIM card in there.
-- 
[email-masked]

---

From: Robert Cragie <[email-masked]>
Date: Tue, 15 Sep 2015 09:45:02 +0100

Hi Michael,

I think you have outlined the factors well and I agree with what you say
about the JA doing as little as possible. It could be a lot to ask of these
peripheral devices to perform asymmetric crypto operations as they will
generally have less processing power than the JCE (maybe considerably
less) and could be overwhelmed by an array of attackers asking them to
authenticate. It makes more sense to me to make the JA as stateless and as
dumb as possible with regard to authenticating the JN. Therefore, it would
just relay authentication traffic to and from the JCE.

Now to the protocols. EAP over CoAP, EAP over PANA, DTLS over foo; at the
end of the day, there is little to choose between the amount of actual
traffic in the process or the actual fundamental process itself. It comes
down to what approach you prefer and if you have a particular protocol you
prefer. One advantage of using say, PANA and EAP with an EAP method (e.g.
EAP-TLS) is that the authentication mechanism is very well bounded. PANA
works well as it can be used on both the unauthenticated point-to-point
network between the JN and JA and the authenticated mesh network between JA
and JCE, i.e. a common protocol. EAP-TLS is a good choice if you are also
using TLS or DTLS at the application layer as the library can be shared.
This was the approach in ZigBee IP. The main criticism of this approach is
the use of UDP in the unauthenticated point-to-point network and thus
having to have effectively two virtual network interfaces and thus stacks
on the JA for the unauthenticated point-to-point network and
the authenticated mesh network respectively. 802.15.9 would simplify
the unauthenticated point-to-point network network part somewhat but
doesn't address which protocol you would then use in the authenticated mesh
network; RADIUS would be a possibility but is more suited to dial-in modems.

An alternative approach is the one we took in Thread, where we assumed
there was no end-to-end authentication transport protocol as such and DTLS
is the fundamental protocol used for authentication of joining devices.
This reduces the layering somewhat, as EAP is no longer required (DTLS
performs some of the same functionality as EAP-TLS from a transport
perspective), This still requires a means to transport the authentication
through the mesh and CoAP is used for that purpose, effectively becoming
the authentication transport in lieu of e.g. PANA/RADIUS. This in itself
can get carried over DTLS records as application data. The advantages of
this approach are DTLS used everywhere and a slightly simpler
unauthenticated point-to-point network virtual network interface and stack.
The possible disadvantage is now having to treat authentication transport
as an application and thus having to specify and write that application.
See
http://threadgroup.org/Portals/0/documents/whitepapers/Thread%20Commissioning%20white%20paper_v2_public.pdf
for more details.

However, don't be under any misconception that any particular approach is
easier or simpler as any solution has to meet the same fundamental
requirements.

Robert

On 14 September 2015 at 19:22, Michael Richardson <[email-masked]>
wrote:

> _______________________________________________
> 6tisch mailing list
> [email-masked]

---

From: "Lijo Thomas" <[email-masked]>
Date: Thu, 17 Sep 2015 18:32:48 +0530

Hi,

The PSK method sounds better during the joining process.

Probably JA acts as dummy agent for transferring the joining messages.

Case 1 : minimal

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

JN                                                       JA                                                                    JCE                                                                                        

  |                                                        |                                                                         |                                                                         

  |                                                        |                                                                         |                                                                                 

Join Request (JR)    ------------->   JR          -------------------------->       Join Request

                                   (Using Key1)                    (K2 key/layer2 key)

  |                                                        |                                                                         |                                                                         

  |                                                        |                                                                         |             

Join Success        <--------------     Join Success    <---------------------  Join Success 

                          (Key2 encrypted                                 (K2 key/layer2 key)        (Made an entry for the new node)

                              using Key1)

Case 2 :  secure 

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

JN                                                        JA                                                            JCE/PCE/NME                                                                    

  |                                                        |                                                                         |                                                                         

  |                                                        |                                                                         |                                                                         

Join Request (JR)   ---------------> JR -------------------------->       Check for Pre shared key 

                                   (Using Key1)              (K2 key/layer2 key)

  |                                                        |                                                                         |                                                                         

  |                                                        |                                                                         |                                                                         

Join Check <------------------   Join Check  <-------------------------             Join Check  

 ( K2 key            (Using Key1)                           (K2 key/layer2 key )       (K2 key encrypted 

  decrypted                                                                                                         using PSK)

  using PSK )

  |                                                        |                                                                         |                                                                         

  |                                                        |                                                                         |                                                                         

Join Confirm ----------------->  Join Confirm ---------------------------->   Join Success

                         (Using Key2)                                  (K2 key/layer2 key)

Pre shared Key (PSK) should be there in the JCE /PCE/NME; if not,  the node is denied to join the network;

Does case2  make sense ?  Minimum 6 exchanges required in this scenario.

Is it possible to get the private keys of different manufacturers? Also how the interoperability issue to be addressed .

Regards,

Lijo Thomas 

-------------------------------------------------------------------------------------------------------------------------------
[ C-DAC is on Social-Media too. Kindly follow us at:
Facebook: https://www.facebook.com/CDACINDIA & Twitter: @cdacindia ]

This e-mail is for the sole use of the intended recipient(s) and may
contain confidential and privileged information. If you are not the
intended recipient, please contact the sender by reply e-mail and destroy
all copies and the original message. Any unauthorized review, use,
disclosure, dissemination, forwarding, printing or copying of this email
is strictly prohibited and appropriate legal action will be taken.
-------------------------------------------------------------------------------------------------------------------------------

---

From: Michael Richardson <[email-masked]>
Date: Thu, 17 Sep 2015 10:37:25 -0400

Robert Cragie <[email-masked]> wrote:
    > See
    > http://threadgroup.org/Portals/0/documents/whitepapers/Thread%20Commissioning%20white%20paper_v2_public.pdf for
    > more details.

Thank you posting this link.
I haven't finished reading it all, but I suggest that all people here do read
it.  Nice diagrams, nice use case, and I like the term "Commissioning"