Subject: Re: [6tisch] PANA clarifications (was Re: Directions on the join process)

From: Rafa Marin Lopez <[email-masked]>
Date: Sun, 1 Nov 2015 19:17:48 +0100

Hi Malisa:

As additional comment:

In http://sourceforge.net/projects/panatiki/ you can find an PANA client we implemented for Contiki OS that we have tested in different platforms. We have also an implementation for mbed platform. I’ll soon provide a link for EAP over CoAP implementation for Contiki OS and mbed too.

Additionally it has been mentioned the "EAP overhead”, as something that may sound like an insurmountable obstacle. However, for example, EAP-AKA implies three messages, two related with EAP-AKA and the final EAP Success which is four byte length. EAP Req/id and Resp/id is not mandatory in EAP. The overhead in this example is 14 bytes with respect to the KMP without EAP, which, a priori, does not seem to me a terrible thing.

Best Regards.

> El 31 oct 2015, a las 22:10, Malisa Vucinic <[email-masked]> escribió:
> 
> 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,
>> 
>> 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
>> 
>> 
>> 
>> 
>> _______________________________________________
>> 6tisch mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/6tisch
> 
> _______________________________________________
> 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: Michael Richardson <[email-masked]>
Date: Mon, 02 Nov 2015 11:14:34 +0900

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.

    > 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

The JN would have to get some kind of ACK so that it can stop retransmitting.
Just waiting on the reponse to ClientHello won't work.

In draft-richardson-6tisch--security-6top-04, I suggested that the JN would
join a special DODAG just for joining nodes, and the presents of the JN's
serialNumber in the (E)ARO ND DAD that needs to be sent would signal to the
JCE that it exists.  This piggybacks upon a transaction which already
happens (no new code, no new state, no additional transactions), is
acknowledged on a hop-by-hop basis, but is not end-to-end. 

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

---

From: Michael Richardson <[email-masked]>
Date: Mon, 02 Nov 2015 11:19:06 +0900

Rafa Marin Lopez <[email-masked]> wrote:
    > that may sound like an insurmountable obstacle. However, for example,
    > EAP-AKA implies three messages, two related with EAP-AKA and the final
    > EAP Success which is four byte length. EAP Req/id and Resp/id is not

EAP-AKA is nice because it provides authentication of the network to the
device.  In the context of a vendor (manufacturer) which sells devices (with
the same SKU, same firmware, same set of trust roots) to different operators,
I think that a complete EAP transaction back to the manufacturer would be
required to authorize things.

EAP-AKA being based upon shared-secrets installed at manufacturer time (in
the mobile phone case, it's just the "SIM" card, but I assume it's just
built-in AKA functionality, not a physical SIM), the manufacturer has no
asymmetric mechanism to delegate authorization through a supply chain, and so
has to do it online.

I'm not complaining about doing it online: I just want to be sure that we all
understand the shape of this solution.

---

From: Malisa Vucinic <[email-masked]>
Date: Mon, 2 Nov 2015 12:00:55 +0100

Hello Rafa,

Thanks for your pointer. I am not sure though that we are fully aligned on the meaning of ‘code reuse’. What I mean there is that we ideally want to reuse the code that already makes part of the firmware image, i.e. is part of the network stack, in order to minimize portions of the code that end up in firmware but get used only once.

Also, I am not sure how you got the impression that “EAP overhead” implies an insurmountable obstacle when it clearly depends on the method. Could you elaborate on the 14-byte figure, I am not sure I follow you there?

Regards,
Mališa

> On 01 Nov 2015, at 19:17, Rafa Marin Lopez <[email-masked]> wrote:
> 
> Hi Malisa:
> 
> As additional comment:
> 
> In http://sourceforge.net/projects/panatiki/ <http://sourceforge.net/projects/panatiki/> you can find an PANA client we implemented for Contiki OS that we have tested in different platforms. We have also an implementation for mbed platform. I’ll soon provide a link for EAP over CoAP implementation for Contiki OS and mbed too.
>

---

From: Rafa Marin Lopez <[email-masked]>
Date: Mon, 2 Nov 2015 12:30:16 +0100

Hello Malisa:

Thanks for the answer! Please see my comments inline.
> El 2 nov 2015, a las 12:00, Malisa Vucinic <[email-masked]> escribió:
> 
> Hello Rafa,
> 
> Thanks for your pointer. I am not sure though that we are fully aligned on the meaning of ‘code reuse’.

> What I mean there is that we ideally want to reuse the code that already makes part of the firmware image, i.e. is part of the network stack, in order to minimize portions of the code that end up in firmware but get used only once.

Yes, I think we are aligned. That is why we proposed EAP over CoAP (you reuse CoAP). And as Robert mentioned certain EAP methods can re-use source code.

On the other hand, I have some doubts this source code will be used only once.

> 
> Also, I am not sure how you got the impression that “EAP overhead” implies an insurmountable obstacle when it clearly depends on the method.

I felt from the comments (my apologies if I was wrong) that EAP was somehow discarded due to the “EAP overhead”. That is why I made this clarification. But I agree with you, it depends on the method.

> Could you elaborate on the 14-byte figure, I am not sure I follow you there?

EAP-AKA has two messages + EAP Success : EAP-Req/AKA (4 bytes header EAP + 1 the type) +  EAP-Resp/AKA (4 bytes header EAP +1 the type) + EAP success(4 bytes) = 14 overhead with respect to running “AKA" without EAP. 

Hope this helps.

Best Regards.

---

From: Alper Yegin <[email-masked]>
Date: Tue, 3 Nov 2015 09:52:01 +0200

Hi Malisa,

On Oct 31, 2015, at 11:10 PM, Malisa Vucinic wrote:

> Thanks for the clarification. We are trying to maximize code reuse

Then please note that PANA is RFC, has multiple implementations, adopted by other standards (Zigbee and Wi-Sun), and already getting deployed (Wi-Sun).

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

OK. 
Note that, though, any solution you'd have would need to have the equivalent of that one message where the client says "hello, let's start auth".

> I suppose that we are then left with EAP overhead plus an extra discovery message.
> 

I see the EAP overhead is being debated already.
But like I said above, discovery message needs to be supported by any other solution as well, hence I don't think it's extra for "EAP/PANA"

Alper

---

From: Alper Yegin <[email-masked]>
Date: Tue, 3 Nov 2015 09:58:22 +0200

Hi Carsten,

I thought the discussion centered more around the transport stack for the "authentication method" and key management. Hence the discussion about using EAP/PANA, CoAP, etc.

Whether the auth method will be cert based, or PSK based, etc. is indeed very important. But whatever it is determined to be, there'd already be an existing EAP method, or one can define an alternative encapsulation/transport if using a non-EAP solution.

I recommend we open another thread just to discuss the type of credentials and the associated auth method to be used. 
Once we converge on that, we can come back and discuss how to transport that.

Alper

On Nov 1, 2015, at 12:17 AM, Carsten Bormann wrote:

> 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: Carsten Bormann <[email-masked]>
Date: Tue, 03 Nov 2015 16:28:48 +0900

> Whether the auth method will be cert based, or PSK based, etc. is indeed very important. But whatever it is determined to be, there'd already be an existing EAP method, or one can define an alterna…

Right.  I was trying to understand how much overhead PANA+EAP+EAPmethodX
would add to what is needed in the abstract exchanges for auth method Y.

> Once we converge on that, we can come back and discuss how to transport that.

That is probably also a useful exercise.

Grüße, Carsten

---

From: Tero Kivinen <[email-masked]>
Date: Tue, 3 Nov 2015 09:36:30 +0200

Malisa Vucinic writes:
> 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.

If sending/receiving 10 frames deplates a quarter of the battery of
nodes, then you do have problem. Also if your network is so that the
node #100 needs to go through all nodes #2-#99 to get to the
coordinator, then the node #2 needs to indeed pass huge amount of
frames through.

It we assume that we have network where we have 100 nodes, and those
100 nodes are split in 2 levels of interaction, i.e. coordinator talks
to 10 nodes, and each of those nodes have 10 "child" neighbors, then
the traffic between those JA nodes need to pass 10*10 frames, i.e. 100
frames. That should not be problem in TSCH network, as TSCH nodes
cannot be silent for long time. They need to transmit frame every few
beacon intervals, thus they are sending frame every few seconds just
to stay in the network.

I have no idea why you are thinking that situation would be as bad as
you assume above.
-- 
[email-masked]

---

From: Malisa Vucinic <[email-masked]>
Date: Tue, 3 Nov 2015 14:57:49 +0100

You are ignoring the facts that 1) nodes do not efficiently duty-cycle during the join process as they are not yet provisioned with schedule; 2) that overall consumption of a node during join will depend on the time it spends at a high duty cycle, i.e., time it takes until it is provisioned with the schedule. So IMO the key metric is the duration of the overall process, network-wise. Percentage of battery consumed was not the best metric to consider as it clearly depends on the capacity of your battery. The duty cycle with minimal schedule during joining will probably be on the order of 10-15% (1/11, 1/7 cells). That means that 10-15% of time you will be wasting energy listening to the transmissions of others, collisions, retransmissions, the duration of which depends on the number of nodes contending for the minimal cell and obviously the traffic load per node. 

The only factor that we can affect in this working group is the traffic load and you seem to be suggesting to just not care about it. To your point that a node "needs to send a frame every few seconds just to stay in the network", this happens at a duty cycle that can be bellow 0.1% and so doesn’t have much in common with the join process.

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

---

From: Malisa Vucinic <[email-masked]>
Date: Tue, 3 Nov 2015 15:08:04 +0100

> On 03 Nov 2015, at 08:52, Alper Yegin <[email-masked]> wrote:
> 
> Hi Malisa,
> 

Thanks, other people have pointed that out too. Other discussed solutions also seem to be adopted elsewhere so I am not sure if this helps us in narrowing our choice. 

> Note that, though, any solution you'd have would need to have the equivalent of that one message where the client says "hello, let's start auth”.

Yes, I agree, unless that message already piggybacks a part of the auth exchange but for that to happen it seems we would need to define something of our own.

---

From: Malisa Vucinic <[email-masked]>
Date: Tue, 3 Nov 2015 15:19:55 +0100

> On 02 Nov 2015, at 12:30, Rafa Marin Lopez <[email-masked]> wrote:

> On the other hand, I have some doubts this source code will be used only once.

Could you elaborate? 

> EAP-AKA has two messages + EAP Success : EAP-Req/AKA (4 bytes header EAP + 1 the type) +  EAP-Resp/AKA (4 bytes header EAP +1 the type) + EAP success(4 bytes) = 14 overhead with respect to running…

Ok thanks. So, am I right if I say that this will trigger 3 additional frames at L2 with additional CoAP / UDP-6LoWPAN-IPv6 / 15.4 overhead?

---

From: Tero Kivinen <[email-masked]>
Date: Wed, 4 Nov 2015 04:34:57 +0200

Malisa Vucinic writes:
> You are ignoring the facts that 1) nodes do not efficiently
> duty-cycle during the join process as they are not yet provisioned
> with schedule;

I have assumed that during the joining they will be using the minimal
and they do get the schedule in the EBs and will be sleeping most of
the schedule.

Why do you think they cannot do that?

> 2) that overall consumption of a node during join will depend on the
> time it spends at a high duty cycle, i.e., time it takes until it is
> provisioned with the schedule.

It will have minimal schedule immediately after it has seen one EB and
parsed the TSCH Slotframe and Link IE. Before they see the EB they
might need to do active scanning for minutes to find the correct
channels and EBs.

I.e. if you are using 10 ms timeslot length, with slotframe size of
100, that will mean that slotframe repeats every second. If send
beacon in every 10th slotfrmae, that means you send beacon for every
10 seconds on some channel. As the joining device does not know your
timing, and he might actally miss few beacons because of random noise,
he might need to listen each channel for example 3 beacon intervals,
i.e. 30 seconds.

30 seconds * 16 channels = 8 minutes... I.e. after 8 minutes it knows
which networks there are, and can pick one.

After that the actual listening time for 10 ms every second is quite a
lot less than what was used for passive scanning, even if the joining
process takes few minutes more.

> So IMO the key metric is the duration of the overall process,
> network-wise. Percentage of battery consumed was not the best metric
> to consider as it clearly depends on the capacity of your battery.
> The duty cycle with minimal schedule during joining will probably be
> on the order of 10-15% (1/11, 1/7 cells). That means that 10-15% of
> time you will be wasting energy listening to the transmissions of
> others, collisions, retransmissions, the duration of which depends
> on the number of nodes contending for the minimal cell and obviously
> the traffic load per node.

But I do not think that really changes after you get schedule, as you
still listen the same slots, as they are broadcast slots which might
contain information for you too.

Also depending on your keepalive period you need to send packet every
now and then, and that consumes much more power. 

> The only factor that we can affect in this working group is the
> traffic load and you seem to be suggesting to just not care about
> it.

I am not suggesting that we do not care it, I am saying that as
joining process is done only once, it is so small amount of actual
network lifetime, that it does not matter. I mean if joining process
takes for example an hour for the 100 node network, and the network is
then up and running for a year, before next maintenance cycle, that is
0.01% of the lifetime of the network. 

> To your point that a node "needs to send a frame every few
> seconds just to stay in the network", this happens at a duty cycle
> that can be bellow 0.1% and so doesn’t have much in common with the
> join process.

It depends what your keepalive period is. If you use maximum amout
possible, you need to send frame every 655.35 seconds (assume 10 ms
timeslot length). I have understood that cheap devices do not have
that good clocks, thus they want to do keepalives more often. I have
no idea how much more often.
-- 
[email-masked]

---

From: Alper Yegin <[email-masked]>
Date: Wed, 4 Nov 2015 09:40:38 +0200

> Thanks, other people have pointed that out too. Other discussed solutions also seem to be adopted elsewhere so I am not sure if this helps us in narrowing our choice. 

I wonder which other solution made this much progress on 802.15.4.

Alper

---

From: Michael Richardson <[email-masked]>
Date: Thu, 05 Nov 2015 08:18:41 +0900

It seems to me that we need to write a document that explains the join
*environment* in terms of radio and energy considerations.
Some of this discussion happened orally in security design team discussions,
but was perhaps assumed to be well known, or was simply assumed.

Pascal: should this be a new milestone?

---

From: Malisa Vucinic <[email-masked]>
Date: Thu, 5 Nov 2015 01:06:34 +0100

> On 05 Nov 2015, at 00:18, Michael Richardson <[email-masked]> wrote:
> 
> 

Some of the information is available in the introduction section of minimal, but I definitely agree that it would be useful to spell out somewhere the repercussions this has on the energy consumption during the join. 

> One goal of this document is to define the simplest set of rules for
>    building a TSCH-compliant network, at the necessary price of lesser
>    efficiency.  Yet, this minimal mode of operation MAY also be used
>    during network bootstrap before any schedule is installed into the
>    network so nodes can self-organize and the management and
>    configuration information be distributed.  In addition, the minimal
>    configuration MAY be used as a fall-back mode of operation, ensuring
>    connectivity of nodes in case that dynamic scheduling mechanisms fail
>    or are not available.

---

From: Rafa Marin Lopez <[email-masked]>
Date: Thu, 5 Nov 2015 14:01:27 +0100

Hi Malisa:

Thanks for the discussion and sorry for my late answer. See inline.

> El 3 nov 2015, a las 15:19, Malisa Vucinic <[email-masked]> escribió:
> 
> 

What I meant is that for security reasons we will have to refresh the keying material. For example, EAP Key Management Framework recommends 8 hours as default lifetime (this might be modified in this type of networks). Thus, I do not think the source code will be used only once. 

> Ok thanks. So, am I right if I say that this will trigger 3 additional frames at L2 with additional CoAP / UDP-6LoWPAN-IPv6 / 15.4 overhead?

Not sure about what you mean with 3 “additional" frames at L2. Additional to what else?. You also mention additional CoAP/UDP...? Are you assuming CoAP-EAP?

Best Regards.

---

From: Malisa Vucinic <[email-masked]>
Date: Thu, 5 Nov 2015 16:19:17 +0100

> On 05 Nov 2015, at 14:01, Rafa Marin Lopez <[email-masked]> wrote:
> 

Ok, I see what you mean. So, yes, if we go for the EAP approach, we would be using it for rekeying as well.  The problem I have there is that we will in any case need to use DTLS, and even maybe the object security mechanism ACE comes up with for application session security so I don’t think this would be optimal from code point of view. 

> Not sure about what you mean with 3 “additional" frames at L2. Additional to what else?. You also mention additional CoAP/UDP...? Are you assuming CoAP-EAP?

I was referring to the 14-byte overhead you referenced above in case we use CoAP for EAP transport. Is my understanding wrong?

---

From: Paul Duffy <[email-masked]>
Date: Thu, 5 Nov 2015 11:23:14 -0500

Re: PANA traction in the market.

AFAIK Zigbee IP has no deployed footprint and none are pending.

Wi-SUN consists of several profiles.  EchoNet and Field Area Network 
being prominent.  FAN is using 802.1X / EAP-TLS.

On 11/3/2015 2:52 AM, Alper Yegin wrote:
> .

---

From: "Turner, Randy" <[email-masked]>
Date: Thu, 5 Nov 2015 16:39:47 +0000

There are very large TSCH/RPL/LoWPAN PANA deployments in the market as well…it’s well past the experimental stage.

R.

> On Nov 5, 2015, at 10:23 AM, Paul Duffy <[email-masked]> wrote:
>
> Wi-SUN consists of several profiles.  EchoNet and Field Area Network being prominent.  FAN is using 802.1X / EAP-TLS.
>
>

P PLEASE CONSIDER OUR ENVIRONMENT BEFORE PRINTING THIS EMAIL.

This e-mail (including any attachments) is confidential and may be legally privileged. If you are not an intended recipient or an authorized representative of an intended recipient, you are prohibited from using, copying or distributing the information in this e-mail or its attachments. If you have received this e-mail in error, please notify the sender immediately by return e-mail and delete all copies of this message and any attachments. Thank you.

---

From: Robert Cragie <[email-masked]>
Date: Fri, 6 Nov 2015 15:43:10 +0000

Some comments on some of the items raised in the thread so far:

* It is not about messages, it is more about how many flights occur between
initiator and responder. For example, with (D)TLS, it is normal to
incorporate a number of records in a single flight.

* The concept of an initial phase of PANA (PCI, PAR) is often needed for
DoS and rate-limiting purposes. If DTLS were used, you would still want to
use HelloVerifyRequest for the reasons it was developed for DTLS, there is
no overhead using PANA in this case.

* Whilst it seems straightforward to use DTLS, it may not be the case where
a JA is involved and it is likely that the DTLS records will need to be
relayed via the JA. The only IP address which can be effectively
autoconfigured at this stage is a link local address and therefore it can
only go one hop to the JA (or possibly JCE direct).

* Note that autoconfiguration of a link local address is pretty much zero
cost as it is simply forming an IID from the L2 address and prepending
fe80::/64. There may be some concerns about the privacy aspects but I think
privacy concerns are much more significant for global addresses and if L2
addresses have some sort of treatment for privacy, that it probably
adequate for link local addresses.

* Conceptually, all these mechanisms are fundamentally the same and when it
comes down to it, there is often little to choose between them. The weight
of the exchanges is based on the credentials and underlying crypto used for
authentication.

* Agree with the comment re. 1.C and 1.D - it is not just EAP-PSK. EAP by
definition requires and EAP transport and an EAP method. An EAP transport
can be PANA, 802.15.9 (i.e. IEs). EAPOL, RADIUS etc. and there are numerous
EAP methods (EAP-TLS, EAP-PSK, EAP-AKA, EAP-IKEV2). Therefore, I would
focus on those three layers as that is fundamentally what it comes down to:

  1. Transport
  2. Protocol
  3. Crypto

To summarise the two authentication schemes I am familiar with:

ZigBee IP:
Transport: PANA/PANA relay
Protocol: EAP/EAP-TLS
Crypto: ECDHE-ECDSA, PSK

Thread:
Transport: Direct/CoAP relay
Protocol: DTLS
Crypto: ECJPAKE

One might ask why a different approach was taken for Thread. The main
reasons are that DTLS is considered a key protocol for Thread applications
(which will likely use CoAP) and thus reuse of DTLS was considered
paramount. Also, the Commissioner model is substantially different to the
Authenticator model for ZigBee IP and it was considered more appropriate to
use protocols a phone/tablet app. would be more familiar with, i.e. CoAP
and DTLS as opposed to PANA/EAP/EAP-TLS. I would imagine the 6tisch
architecture is closer to ZigBee IP than Thread.

* The simplicity of PSK is offset by the need to manage confidential
information across the devices. It is always IMHO worth including PSK as a
minimal level, as it is very useful for testing purposes if nothing else

* In my experience, using EAP-TLS as an EAP method in conjunction with PANA
and EAP (i.e. ZigBee IP approach) allows for reuse of TLS library with
application layer, thus potentially saving code.

* EAP-TLS has a lot of functionality that DTLS has so one could consider
using DTLS in conjunction with an appropriate transport. That transport
could be PANA, CoAP or a combination of L2/L3 based.

* Whatever solution is proposed for transport MUST take into consideration
the JN-JA-JCE architecture, i.e. need to consider a point-to-point
communication between JN and JA (unauthenticated network) and normal
communication between JN and JCE.

* If CoAP is used as a transport, it must be distinguishable from other
CoAP traffic. This could either be through port or URI.

* Whilst PANA is an additional protocol, it is pretty lightweight and is
purely an authentication transport. The main issue I heard regarding PANA
is the fact it uses UDP and this can cause issues for stacks (especially
Linux-based stacks)

* Using PANA in 802.15.9 is a case of transporting the data in IEs. We took
a different (IMHO simpler) approach in ZigBee IP and transported the PANA
UDP datagrams using 6LoWPAN over unsecured 802.15.4 packets. However, note
comment above re. use of UDP.

* One bonus of using PANA is the resultant PANA session, which is basically
a secure session between PAC and PAA, where the PAC (PANA client) is the
device requiring network access. This can be used for securely configuring
network parameters on the device, for example, in ZigBee IP it was used to
securely deliver the network key. There was an idea for it to deliver other
parameters as well but this was considered "treading on the toes" of
6LowPAN ND's address registration and DHCP, although in both those cases,
there is no way to provide the secure session with which to transport the
data. So I think Tero has this wrong - PANA definitely can be used to
distribute keys and be used for rekeying, however I mean this independent
of the pairwise key established as part of the authentication between JN
and JCE.

* I agree with Rafa's point that the JCE and JN should mutually
authenticate each other.

Robert

On 5 November 2015 at 00:06, Malisa Vucinic <[email-masked]> wrote:

> Some of the information is available in the introduction section of
> minimal, but I definitely agree that it would be useful to spell out
> somewhere the repercussions this has on the energy consumption during the
> join.
>

---

From: Alper Yegin <[email-masked]>
Date: Sat, 7 Nov 2015 13:00:32 +0200

Hello Robert,

Thanks for this detailed insight.
One question below:

On Nov 6, 2015, at 5:43 PM, Robert Cragie wrote:

> * It is not about messages, it is more about how many flights occur between initiator and responder. For example, with (D)TLS, it is normal to incorporate a number of records in a single flight.
> 
> * The concept of an initial phase of PANA (PCI, PAR) is often needed for DoS and rate-limiting purposes. If DTLS were used, you would still want to use HelloVerifyRequest for the reasons it was developed for DTLS, there is no overhead using PANA in this case.
> 
> * Whilst it seems straightforward to use DTLS, it may not be the case where a JA is involved and it is likely that the DTLS records will need to be relayed via the JA. The only IP address which can be effectively autoconfigured at this stage is a link local address and therefore it can only go one hop to the JA (or possibly JCE direct).
> 
> * Note that autoconfiguration of a link local address is pretty much zero cost as it is simply forming an IID from the L2 address and prepending fe80::/64. There may be some concerns about the privacy aspects but I think privacy concerns are much more significant for global addresses and if L2 addresses have some sort of treatment for privacy, that it probably adequate for link local addresses.
> 
> * Conceptually, all these mechanisms are fundamentally the same and when it comes down to it, there is often little to choose between them. The weight of the exchanges is based on the credentials and underlying crypto used for authentication.
> 
> * Agree with the comment re. 1.C and 1.D - it is not just EAP-PSK. EAP by definition requires and EAP transport and an EAP method. An EAP transport can be PANA, 802.15.9 (i.e. IEs). EAPOL, RADIUS etc. and there are numerous EAP methods (EAP-TLS, EAP-PSK, EAP-AKA, EAP-IKEV2). Therefore, I would focus on those three layers as that is fundamentally what it comes down to:
> 
>   1. Transport
>   2. Protocol
>   3. Crypto
>   
> One might ask why a different approach was taken for Thread. The main reasons are that DTLS is considered a key protocol for Thread applications (which will likely use CoAP) and thus reuse of DTLS was considered paramount. Also, the Commissioner model is substantially different to the Authenticator model for ZigBee IP and it was considered more appropriate to use protocols a phone/tablet app. would be more familiar with, i.e. CoAP and DTLS as opposed to PANA/EAP/EAP-TLS. I would imagine the 6tisch architecture is closer to ZigBee IP than Thread.
> 
> * The simplicity of PSK is offset by the need to manage confidential information across the devices. It is always IMHO worth including PSK as a minimal level, as it is very useful for testing purposes if nothing else
> 
> * In my experience, using EAP-TLS as an EAP method in conjunction with PANA and EAP (i.e. ZigBee IP approach) allows for reuse of TLS library with application layer, thus potentially saving code.
> 
> * EAP-TLS has a lot of functionality that DTLS has so one could consider using DTLS in conjunction with an appropriate transport. That transport could be PANA, CoAP or a combination of L2/L3 based.
> 
> * Whatever solution is proposed for transport MUST take into consideration the JN-JA-JCE architecture, i.e. need to consider a point-to-point communication between JN and JA (unauthenticated network) and normal communication between JN and JCE.
> 
> * If CoAP is used as a transport, it must be distinguishable from other CoAP traffic. This could either be through port or URI.
> 
> * Whilst PANA is an additional protocol, it is pretty lightweight and is purely an authentication transport. The main issue I heard regarding PANA is the fact it uses UDP and this can cause issues for stacks (especially Linux-based stacks)
> 

What exactly is the issue there?

> * Using PANA in 802.15.9 is a case of transporting the data in IEs. We took a different (IMHO simpler) approach in ZigBee IP and transported the PANA UDP datagrams using 6LoWPAN over unsecured 802.15.4 packets. However, note comment above re. use of UDP.
> 
> * One bonus of using PANA is the resultant PANA session, which is basically a secure session between PAC and PAA, where the PAC (PANA client) is the device requiring network access. This can be used for securely configuring network parameters on the device, for example, in ZigBee IP it was used to securely deliver the network key. There was an idea for it to deliver other parameters as well but this was considered "treading on the toes" of 6LowPAN ND's address registration and DHCP, although in both those cases, there is no way to provide the secure session with which to transport the data. So I think Tero has this wrong - PANA definitely can be used to distribute keys and be used for rekeying, however I mean this independent of the pairwise key established as part of the authentication between JN and JCE.
> 
> * I agree with Rafa's point that the JCE and JN should mutually authenticate each other.
> 

Alper

---

From: Robert Cragie <[email-masked]>
Date: Sat, 7 Nov 2015 15:40:41 +0000

Paul,

Whatever the state of ZigBee IP, it doesn't alter the fact that it
successfully completed after an extensive specification, implementation and
test program, demonstrating interoperability across 7 independent
platforms, so the solution is certainly proven.

Robert
On 5 Nov 2015 16:23, "Paul Duffy" <[email-masked]> wrote:

> Wi-SUN consists of several profiles.  EchoNet and Field Area Network being
> prominent.  FAN is using 802.1X / EAP-TLS.
>
>
>> Then please note that PANA is RFC, has multiple implementations, adopted
>> by other standards (Zigbee and Wi-Sun), and already getting deployed
>> (Wi-Sun).
>>
>>
>> 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.
>>>
>> OK.
>> Note that, though, any solution you'd have would need to have the
>> equivalent of that one message where the client says "hello, let's start
>> auth".
>>
>>
>> But like I said above, discovery message needs to be supported by any
>> other solution as well, hence I don't think it's extra for "EAP/PANA"
>>
>> Alper
>>
>>
>>
>>
>> Regards,
>>> Mališa
>>>
>>>
>>>> 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?
>>>>
>>>>
>>>> (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.
>>>>
>>>> - 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.

---

From: Robert Cragie <[email-masked]>
Date: Sat, 7 Nov 2015 17:42:22 +0000

Hi Alper,

The perceived issue is that, in ZigBee IP, the authentication traffic over
PANA on the single hop between the unauthenticated joiner and the relay (or
authenticator) has to be sent at the MAC layer without any protection. This
is because MAC layer protection is used for all authenticated nodes sending
and receiving traffic in the mesh and the key used is delivered at the end
of the authentication process over the established secure session. Note
there is no particular issue with having no MAC layer protection as the
only traffic carried is for authentication purposes and thus does not carry
any confidential information and is checked using verify exchanges at the
end.

This means there is effectively a "side stack" alongside the normal stack,
which is used to handle the PANA traffic on an enforcement point. On one
hand, some perceive the necessity for this side stack as layer violation,
although I view this more as control plane traffic, where cross-layer
interactions are not uncommon (look at what they are doing in anima with
the ASAs, for example). It is also perceived as complicating the use of a
typical IP stack, which is normally used for data plane traffic.
Specifically, having to provide an extra parameter at the socket layer to
indicate whether it should be transmitted unprotected or protected (and
similar for receive) is viewed as problematic.

In practice, given the fact that the 7 platform implementers managed to
successfully implement PANA-based authentication, I am not sure actually
how much of an issue it really is.

Robert

On 7 November 2015 at 11:00, Alper Yegin <[email-masked]> wrote:

> * It is not about messages, it is more about how many flights occur
> between initiator and responder. For example, with (D)TLS, it is normal to
> * Whilst it seems straightforward to use DTLS, it may not be the case
> where a JA is involved and it is likely that the DTLS records will need to
> be relayed via the JA. The only IP address which can be effectively
> * Conceptually, all these mechanisms are fundamentally the same and when
> it comes down to it, there is often little to choose between them. The
> weight of the exchanges is based on the credentials and underlying crypto
> used for authentication.
>
> * In my experience, using EAP-TLS as an EAP method in conjunction with
> PANA and EAP (i.e. ZigBee IP approach) allows for reuse of TLS library with
> * Using PANA in 802.15.9 is a case of transporting the data in IEs. We
> took a different (IMHO simpler) approach in ZigBee IP and transported the
> PANA UDP datagrams using 6LoWPAN over unsecured 802.15.4 packets. However,
> note comment above re. use of UDP.
>
> * One bonus of using PANA is the resultant PANA session, which is
> basically a secure session between PAC and PAA, where the PAC (PANA client)
> is the device requiring network access. This can be used for securely
> configuring network parameters on the device, for example, in ZigBee IP it
> was used to securely deliver the network key. There was an idea for it to
> deliver other parameters as well but this was considered "treading on the
> toes" of 6LowPAN ND's address registration and DHCP, although in both those
> cases, there is no way to provide the secure session with which to
> transport the data. So I think Tero has this wrong - PANA definitely can be
> used to distribute keys and be used for rekeying, however I mean this
> independent of the pairwise key established as part of the authentication
> between JN and JCE.
>

---

From: Alper Yegin <[email-masked]>
Date: Sat, 7 Nov 2015 23:26:03 +0200

Hi Robert,

The MAC has the ability to carry both encrypted traffic and also unencrypted traffic, right?
If so, it's just about telling the MAC which traffic uses encrypted path and which does not. 
I don't see anything to do with layer violation here.

I'd not call it a "side stack" either. It's just demultiplexing. Same stack, different code path executed depending on the characteristic of the traffic, which is explicitly conveyed by the upper layer to the lower layer.

Btw, this has to be done for any above-MAC solution.

Alper

Given that the MAC can support transporting IP (with whatever payload it carries, be it PANA/UDP, or anything else), it should be able to carry both encrypted traffic and unencrypted traffic. 

On Nov 7, 2015, at 7:42 PM, Robert Cragie wrote:

> Hi Alper,
> 
> The perceived issue is that, in ZigBee IP, the authentication traffic over PANA on the single hop between the unauthenticated joiner and the relay (or authenticator) has to be sent at the MAC layer without any protection. This is because MAC layer protection is used for all authenticated nodes sending and receiving traffic in the mesh and the key used is delivered at the end of the authentication process over the established secure session. Note there is no particular issue with having no MAC layer protection as the only traffic carried is for authentication purposes and thus does not carry any confidential information and is checked using verify exchanges at the end.
> 
> This means there is effectively a "side stack" alongside the normal stack, which is used to handle the PANA traffic on an enforcement point. On one hand, some perceive the necessity for this side stack as layer violation, although I view this more as control plane traffic, where cross-layer interactions are not uncommon (look at what they are doing in anima with the ASAs, for example). It is also perceived as complicating the use of a typical IP stack, which is normally used for data plane traffic. Specifically, having to provide an extra parameter at the socket layer to indicate whether it should be transmitted unprotected or protected (and similar for receive) is viewed as problematic.
> 
> In practice, given the fact that the 7 platform implementers managed to successfully implement PANA-based authentication, I am not sure actually how much of an issue it really is.
> 
> Robert
> 
> 
>

---

From: "Turner, Randy" <[email-masked]>
Date: Sat, 7 Nov 2015 20:47:40 +0000

Hi Alper,

Ideally, you would need some type of multiplexing of layer-2 to cleanly pull this off…maybe the upcoming LLC work for 802.15.4 will make this kind of thing easier.

R.

On Nov 7, 2015, at 4:26 PM, Alper Yegin <[email-masked]<mailto:[email-masked]>> wrote:

Hi Robert,

Alper

Hi Alper,

Robert

On 7 November 2015 at 11:00, Alper Yegin <[email-masked]<mailto:[email-masked]>> wrote:
Hello Robert,

  1. Transport
  2. Protocol
  3. Crypto

ZigBee IP:

Thread:

Alper

Robert

On 5 November 2015 at 00:06, Malisa Vucinic <[email-masked]<mailto:[email-masked]>> wrote:

> On 05 Nov 2015, at 00:18, Michael Richardson <[email-masked]<mailto:[email-masked]>> wrote:
>
>

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

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

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

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

---

From: Robert Cragie <[email-masked]>
Date: Sun, 8 Nov 2015 23:01:07 +0000

Hi Alper,

PANA is UDP traffic, which is typically sent using sockets. There is no
defined socket option (in e.g Linux socket API) to specify options for
sending the packet when it is processed 2 layers down at the MAC layer. So
some might say that specifying a layer 2 concept at layer 4 is layer
violation. Also, the unprotected PANA only goes one hop and should not be
routed, therefore it is treated differently from other IP packets. This is
in addition to the enforcement point policing for unprotected MAC traffic.
Hence thinking about it like a "side stack".

Other comments inline.

Robert

On 7 November 2015 at 21:26, Alper Yegin <[email-masked]> wrote:

> I'd not call it a "side stack" either. It's just demultiplexing. Same
> stack, different code path executed depending on the characteristic of the
> traffic, which is explicitly conveyed by the upper layer to the lower layer.
>

<RCC>Some stacks don't work like that though. Sure, if you have control
over the stack, it is easy enough to implement and as you say, it is simply
demultiplexing and conceptually quite easy to understand but there are
certain points in the layer traversal that do have to be treated
differently</RCC>

> Given that the MAC can support transporting IP (with whatever payload it
> carries, be it PANA/UDP, or anything else), it should be able to carry both
> encrypted traffic and unencrypted traffic.
>
>> * Whatever solution is proposed for transport MUST take into
>> consideration the JN-JA-JCE architecture, i.e. need to consider a
>> point-to-point communication between JN and JA (unauthenticated network)
>> and normal communication between JN and JCE.
>>

---

From: Alper Yegin <[email-masked]>
Date: Mon, 9 Nov 2015 01:28:31 +0200

Robert,

Right. Even though PANA is a UDP-based protocol, one cannot assume it shall be implementable just like any "UDP-based user-land application".  Like you said it's a control plane traffic/application, and it needs some hooks from the stack. This is very much similar to other UDP-based protocols like Mobile IPv4 and DHCP. They also need hooks with lower layers.

Alper

On Nov 9, 2015, at 1:01 AM, Robert Cragie wrote:

> Hi Alper,
> 
> PANA is UDP traffic, which is typically sent using sockets. There is no defined socket option (in e.g Linux socket API) to specify options for sending the packet when it is processed 2 layers down at the MAC layer. So some might say that specifying a layer 2 concept at layer 4 is layer violation. Also, the unprotected PANA only goes one hop and should not be routed, therefore it is treated differently from other IP packets. This is in addition to the enforcement point policing for unprotected MAC traffic. Hence thinking about it like a "side stack".
> 
> Other comments inline.
> 
> Robert
> 
> 
> <RCC>Some stacks don't work like that though. Sure, if you have control over the stack, it is easy enough to implement and as you say, it is simply demultiplexing and conceptually quite easy to understand but there are certain points in the layer traversal that do have to be treated differently</RCC>
> 
>

---

From: Tero Kivinen <[email-masked]>
Date: Mon, 9 Nov 2015 03:06:09 +0200

Robert Cragie writes:
> provide the secure session with which to transport the data. So I think Tero
> has this wrong - PANA definitely can be used to distribute keys and be used
> for rekeying, however I mean this independent of the pairwise key established
> as part of the authentication between JN and JCE.

That might be true for general case, but in the 802.15.9 annex D says:

D.2 Use Cases

The main use of PANA in 802.15.9 is for provisioning the link-layer
credentials (LLCs) to the joining node, where the LLCs can be of any
type including shared key and public key credentials. LLCs are used
for secure link establishment between adjacent 802.15.9-capable nodes.
The process of provisioning the LLCs is also referred to as
bootstrapping. Bootstrapping can also be used for renewing the LLCs. A
KMP used for bootstrapping is referred to as a bootstrapping KMP. A
KMP used to secure link establishment is referred to as a
link-establishment KMP. While PANA can be used for both bootstrapping
and link-establishment, this document provides the guidelines for
the use of PANA as a bootstrapping KMP.

I.e. for some reason 802.15.9 annex was written in a way where it only
describes how it is used as a bootstrapping KMP. And no, I do not know
why it was written that way.
-- 
[email-masked]

---

From: Robert Cragie <[email-masked]>
Date: Tue, 10 Nov 2015 11:00:00 +0000

Alper - I completely agree with what you say and did note earlier that,
given the 7 independent implementations for ZigBee IP, it clearly isn't a
serious obstacle. However, it is useful to understand potential issues with
any given solution; any solution will have certain issues which have to be
addresses.

Robert

On 8 November 2015 at 23:28, Alper Yegin <[email-masked]> wrote:

> Robert,
>
> Right. Even though PANA is a UDP-based protocol, one cannot assume it
> shall be implementable just like any "UDP-based user-land application".
> Like you said it's a control plane traffic/application, and it needs some
> hooks from the stack. This is very much similar to other UDP-based
> protocols like Mobile IPv4 and DHCP. They also need hooks with lower layers.
>
> Alper
>
>
>
>> The perceived issue is that, in ZigBee IP, the authentication traffic
>> over PANA on the single hop between the unauthenticated joiner and the
>> relay (or authenticator) has to be sent at the MAC layer without any
>> protection. This is because MAC layer protection is used for all
>> authenticated nodes sending and receiving traffic in the mesh and the key
>> used is delivered at the end of the authentication process over the
>> established secure session. Note there is no particular issue with having
>> no MAC layer protection as the only traffic carried is for authentication
>> purposes and thus does not carry any confidential information and is
>> checked using verify exchanges at the end.
>>
>> This means there is effectively a "side stack" alongside the normal
>> stack, which is used to handle the PANA traffic on an enforcement point. On
>> one hand, some perceive the necessity for this side stack as layer
>> violation, although I view this more as control plane traffic, where
>> cross-layer interactions are not uncommon (look at what they are doing in
>> anima with the ASAs, for example). It is also perceived as complicating the
>> use of a typical IP stack, which is normally used for data plane traffic.
>>> * Note that autoconfiguration of a link local address is pretty much
>>> zero cost as it is simply forming an IID from the L2 address and prepending
>>> * Agree with the comment re. 1.C and 1.D - it is not just EAP-PSK. EAP
>>> by definition requires and EAP transport and an EAP method. An EAP
>>> transport can be PANA, 802.15.9 (i.e. IEs). EAPOL, RADIUS etc. and there
>>> are numerous EAP methods (EAP-TLS, EAP-PSK, EAP-AKA, EAP-IKEV2). Therefore,
>>> I would focus on those three layers as that is fundamentally what it comes
>>> down to:
>>>
>>>   1. Transport
>>>   2. Protocol
>>>   3. Crypto
>>>

---

From: Robert Cragie <[email-masked]>
Date: Tue, 10 Nov 2015 11:03:23 +0000

Hi Tero,

Unfortunately, 802.15.9 is not generally available so it is difficult for
those who don't attend IEEE 802 meetings to fully understand the solution.
Do you know when it might be available under the Get IEEE program?

Robert

---

From: <[email-masked]>
Date: Tue, 10 Nov 2015 15:41:08 +0000

Actually LLCs for PANA in 802.15.9 section D.2 can be link-layer keys that are independent of pair-wise key established between JN and JCE.  In this case, we might need a key confirmation protocol (such as MLE 3-way handshake ) used as an 802.15.9 KMP between JN and JA.  

Yoshihiro Ohba

-----Original Message-----
From: 6tisch [mailto:[email-masked]] On Behalf Of Tero Kivinen
Sent: Monday, November 09, 2015 9:06 AM
To: [email-masked]
Cc: Malisa Vucinic; Michael Richardson; [email-masked]; Rafa Marin Lopez
Subject: Re: [6tisch] Directions on the join process

Robert Cragie writes:
> provide the secure session with which to transport the data. So I 
> think Tero has this wrong - PANA definitely can be used to distribute 
> keys and be used for rekeying, however I mean this independent of the 
> pairwise key established as part of the authentication between JN and JCE.

D.2 Use Cases

The main use of PANA in 802.15.9 is for provisioning the link-layer credentials (LLCs) to the joining node, where the LLCs can be of any type including shared key and public key credentials. LLCs are used for secure link establishment between adjacent 802.15.9-capable nodes.
The process of provisioning the LLCs is also referred to as bootstrapping. Bootstrapping can also be used for renewing the LLCs. A KMP used for bootstrapping is referred to as a bootstrapping KMP. A KMP used to secure link establishment is referred to as a link-establishment KMP. While PANA can be used for both bootstrapping and link-establishment, this document provides the guidelines for the use of PANA as a bootstrapping KMP.

I.e. for some reason 802.15.9 annex was written in a way where it only describes how it is used as a bootstrapping KMP. And no, I do not know why it was written that way.
--
[email-masked]

---

From: Jonathan Hui <[email-masked]>
Date: Tue, 10 Nov 2015 09:24:47 -0800

I agree with Robert that PANA needs to be viewed as a side stack.  It
involves more than just restricted forwarding rules and hooks for the upper
layers.  It also involves resource isolation at the lower layers to help
ensure that unauthorized traffic cannot interfere with authorized traffic.
Logically they need to be separate, isolated stacks.  Although, an
implementation may choose to share a bunch of components.

Also, I'd caution that specification and basic functional testing alone
does not prove a robust solution.  How much security or penetration testing
has been done on existing implementations?  I would argue large-scale
deployment certainly helps build confidence beyond what specification and
basic functional testing can do.

--
Jonathan Hui

On Tue, Nov 10, 2015 at 3:00 AM, Robert Cragie <[email-masked]>
wrote:

>>>> * The concept of an initial phase of PANA (PCI, PAR) is often needed
>>>> for DoS and rate-limiting purposes. If DTLS were used, you would still want
>>>> to use HelloVerifyRequest for the reasons it was developed for DTLS, there
>>>> is no overhead using PANA in this case.
>>>>
>>>> * Conceptually, all these mechanisms are fundamentally the same and
>>>> when it comes down to it, there is often little to choose between them. The
>>>> * EAP-TLS has a lot of functionality that DTLS has so one could
>>>> consider using DTLS in conjunction with an appropriate transport. That
>>>> transport could be PANA, CoAP or a combination of L2/L3 based.
>>>>
>>>> * Whilst PANA is an additional protocol, it is pretty lightweight and
>>>> is purely an authentication transport. The main issue I heard regarding
>>>> PANA is the fact it uses UDP and this can cause issues for stacks
>>>> (especially Linux-based stacks)
>>>>
>>>>

---

From: Tero Kivinen <[email-masked]>
Date: Tue, 10 Nov 2015 21:57:54 +0200

Robert Cragie writes:
> Unfortunately, 802.15.9 is not generally available so it is
> difficult for those who don't attend IEEE 802 meetings to fully
> understand the solution. Do you know when it might be available
> under the Get IEEE program?

IEEE 802.15.9 is now in the sponsor ballot, meaning you can by the
current draft from the IEEE SA shop:

http://www.techstreet.com/ieee/searches/10362577?per_page=50&sort_direction=desc&sort_order=publication_date

Relevant drafts:

P802.15.9/D04: http://www.techstreet.com/ieee/products/1902465
P802.15.4-REVc/D01: http://www.techstreet.com/ieee/products/1894072

The 802.15.4 will be going to revcom in December, so it will most
likely be published early next year. The 802.15.9 will go to revcom at
earliest in March, so it will then be published perhaps during summer
or so.

The 802.15.4-REVc/D01 is mostly stable, i.e. there will be editorial
changes, but no technical changes will be done.

The 802.15.9/D04 will still get some technical changes, most likely
next week, so there will be 802.15.9/D05 version available most likely
in two weeks, and you might want to wait for that before buying the
draft...

If I have understood correctly the documents will be available without
having to pay for them after 6 months from the publication, i.e. late
summer for 802.15.4-2015, and most likely end of 2016 or beginning of
2017 for 802.15.9 (provided there is no suprises or delays in the
sponsor ballot).
-- 
[email-masked]

---

From: "rturner amalfisystems.com" <[email-masked]>
Date: Tue, 10 Nov 2015 14:58:27 -0500 (EST)

Hi Guys,

I think the LLC work going on in (what will probably be) 802.15.12 will allow multiple clients of the 802.15.4 MAC/PHY, including PANA.

At the moment, vendors have coded proprietary forms of "side stacks"...for PANA and other protocols.  I'm hoping there's a cleaner way to reuse the 802.15.4 MAC/PHY through a nice LLC layer (and API).

Also, the use of PANA to bootstrap secure joins to an 802.15.4 network is way past specification and functional testing - there are thousands (soon to be millions) of deployed 802.15.4/PANA/6LowPAN/RPL devices that are deployed in real networks...specifically in the Automated Meter Infrastructure (AMI) market.

Randy

On November 10, 2015 at 12:24 PM Jonathan Hui <[email-masked]> wrote:

I agree with Robert that PANA needs to be viewed as a side stack.  It involves more than just restricted forwarding rules and hooks for the upper layers.  It also involves resource isolation at the lower layers to help ensure that unauthorized traffic cannot interfere with authorized traffic.  Logically they need to be separate, isolated stacks.  Although, an implementation may choose to share a bunch of components.

Also, I'd caution that specification and basic functional testing alone does not prove a robust solution.  How much security or penetration testing has been done on existing implementations?  I would argue large-scale deployment certainly helps build confidence beyond what specification and basic functional testing can do.

--
Jonathan Hui

On Tue, Nov 10, 2015 at 3:00 AM, Robert Cragie <[email-masked]> wrote:

Alper - I completely agree with what you say and did note earlier that, given the 7 independent implementations for ZigBee IP, it clearly isn't a serious obstacle. However, it is useful to understand potential issues with any given solution; any solution will have certain issues which have to be addresses.

Robert

Robert,

Alper

Hi Alper,

Other comments inline.

Robert

Hi Robert,

Alper

Hi Alper,

Robert

Hello Robert,

One question below:

1. Transport

2. Protocol

3. Crypto

ZigBee IP:

Protocol: EAP/EAP-TLS

Crypto: ECDHE-ECDSA, PSK

Thread:

Protocol: DTLS

Crypto: ECJPAKE

Alper

Robert

---

From: Rafa Marin Lopez <[email-masked]>
Date: Tue, 10 Nov 2015 23:19:54 +0100

Hi Malisa:

(Changing the subject to "EAP clarifications" since this thread is about EAP only)

> El 5 nov 2015, a las 16:19, Malisa Vucinic <[email-masked]> escribió:
> 
> 

Precisely the key material after the EAP authentication is useful to bootstrap key material either DTLS or any object security mechanism.

> I was referring to the 14-byte overhead you referenced above in case we use CoAP for EAP transport. Is my understanding wrong?

The 14-byte overhead is the EAP overhead (EAP header and type) in a particular EAP method as the case of EAP-AKA. My point is that the important part is the KMP in the EAP method and not EAP itself. Thus, the KMP used in the EAP method needs to be reduced. But EAP allows to select a suitable EAP method for these cases.

Best Regards.

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Wed, 11 Nov 2015 13:25:54 +0000

Hello Michael:

This could be a separate milestone but ultimately the text will be useful in the security piece of the architecture.
Why wouldn't we write it that way as opposed to separately? 

Cheers,

Pascal

> From: 6tisch [mailto:[email-masked]] On Behalf Of Michael Richardson
> Sent: jeudi 5 novembre 2015 00:19
> To: [email-masked]
> Cc: Malisa Vucinic <[email-masked]>; Rafa Marin Lopez <[email-masked]>;
> Tero Kivinen <[email-masked]>
> Some of this discussion happened orally in security design team discussions, but
> was perhaps assumed to be well known, or was simply assumed.
> 
> Michael Richardson <[email-masked]>, Sandelman Software Works  -=
> IPv6 IoT consulting =-
> 
>

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Wed, 11 Nov 2015 13:26:55 +0000

Could we write up some text, maybe on a separate thread?

Cheers,

Pascal

> From: 6tisch [mailto:[email-masked]] On Behalf Of Malisa Vucinic
> Sent: jeudi 5 novembre 2015 01:07
> To: Michael Richardson <[email-masked]>
> Cc: [email-masked]; Rafa Marin Lopez <[email-masked]>; Tero Kivinen
> <[email-masked]>
> > Some of this discussion happened orally in security design team
> > discussions, but was perhaps assumed to be well known, or was simply
> assumed.
> 
> Some of the information is available in the introduction section of minimal, but I
> definitely agree that it would be useful to spell out somewhere the
> repercussions this has on the energy consumption during the join.
>

---

From: Robert Cragie <[email-masked]>
Date: Wed, 11 Nov 2015 17:03:53 +0000

My main concern with the LLC work is that it is not clear to me how it can
be compatible with existing 802.15.4 deployments if, say, an Ethertype is
mandated as part of the LLC. 6LoWPAN already (albeit rather crudely,
although the proposed paging mechanism could fix this) allows for
multiplexing through the use of the NALP type. Whatever would be done for
the LLC is already being done in existing adaptation layers.

Robert

On 10 November 2015 at 19:58, rturner amalfisystems.com <
[email-masked]> wrote:

> Hi Guys,
>
> I think the LLC work going on in (what will probably be) 802.15.12 will
> allow multiple clients of the 802.15.4 MAC/PHY, including PANA.
>
> At the moment, vendors have coded proprietary forms of "side stacks"...for
> PANA and other protocols.  I'm hoping there's a cleaner way to reuse the
> 802.15.4 MAC/PHY through a nice LLC layer (and API).
>
> Also, the use of PANA to bootstrap secure joins to an 802.15.4 network is
> way past specification and functional testing - there are thousands (soon
> to be millions) of deployed 802.15.4/PANA/6LowPAN/RPL devices that are
> deployed in real networks...specifically in the Automated Meter
> Infrastructure (AMI) market.
>
> Randy
>
>
> discussions,

---

From: Robert Cragie <[email-masked]>
Date: Wed, 11 Nov 2015 17:21:08 +0000

Hi Jonathan,

The side stack concept also applies to MLE as well as PANA, in
implementations which use it and I agree the general isolation between the
side stack used for control plane traffic and data plane traffic is
important. However, the sharing of components is indeed an important
feature. Using UDP over 6LoWPAN over 802.15.4 over one hop for e.g. PANA is
really quite efficient and the libraries used in the data plane can also be
used in the control plane. As mentioned before this is control plane, so
with regard to "layer violation", I would say "get over it" - cross layer
interaction happens all the time in the control plane.

With regard to your second point on robust solutions: There is a difference
between a specified solution and a subsequent implementation of that
solution. An implementation may be weak but that does not imply the
solution it is implementing is weak. Of course large scale deployment can
build confidence but it can also build lack of confidence if a large number
of those deployments are based on weak implementations. One key requirement
for ZigBee IP was to use existing solutions as much as possible, hence EAP
and EAP-TLS as a starting point (already tried and tested). Whilst PANA was
acknowledged to be not as tried and tested as EAP and EAP-TLS, it was
chosed for the reason in the paragraph above and the relay and encryption
additions were specified for mesh networks. Even then, as the EAP
transport, PANA is a relatively small (but important) part of the network
access solution.

Robert

On 10 November 2015 at 17:24, Jonathan Hui <[email-masked]> wrote:

>>>> Given that the MAC can support transporting IP (with whatever payload
>>>> it carries, be it PANA/UDP, or anything else), it should be able to carry
>>>> both encrypted traffic and unencrypted traffic.
>>>>
>>>>> * If CoAP is used as a transport, it must be distinguishable from
>>>>> other CoAP traffic. This could either be through port or URI.
>>>>>

---

From: Jonathan Hui <[email-masked]>
Date: Wed, 11 Nov 2015 09:54:24 -0800

Hi Robert,

If we view the unprotected and protected paths as logically separate
stacks, then I don't think the concept of "layer violation" even applies.
The two stacks just happen to share a lot of the concepts and encodings.  I
agree that using UDP/IPv6 makes it possible to share code, but it's
important to ensure that implementations enforce the proper isolation.  My
only worry would be that it encourages poor implementation choices, such as
using a single UDP/IPv6/6LoWPAN stack without proper isolation between the
protected and unprotected channels at every layer.

Again, I think it can be made to work technically, we just have to make it
obvious that it requires more than just passing a secured/unsecured option
between the application and link layers - the transport, network, and
adaptation layers needs to have appropriate isolation as well.  Large scale
deployment will only help identify any pitfalls in both specification and
implementation that exist.  It's good that we will soon be able to
accumulate soak time on real-word deployments that are beyond pilot stage.

--
Jonathan Hui

On Wed, Nov 11, 2015 at 9:21 AM, Robert Cragie <[email-masked]>
wrote:

> With regard to your second point on robust solutions: There is a
> difference between a specified solution and a subsequent implementation of
> that solution. An implementation may be weak but that does not imply the
>>>>> In practice, given the fact that the 7 platform implementers managed
>>>>> to successfully implement PANA-based authentication, I am not sure actually
>>>>>> * Agree with the comment re. 1.C and 1.D - it is not just EAP-PSK.
>>>>>> EAP by definition requires and EAP transport and an EAP method. An EAP
>>>>>> * In my experience, using EAP-TLS as an EAP method in conjunction
>>>>>> with PANA and EAP (i.e. ZigBee IP approach) allows for reuse of TLS library
>>>>>> with application layer, thus potentially saving code.
>>>>>>
>>>>>> * Using PANA in 802.15.9 is a case of transporting the data in IEs.
>>>>>> We took a different (IMHO simpler) approach in ZigBee IP and transported
>>>>>> the PANA UDP datagrams using 6LoWPAN over unsecured 802.15.4 packets.
>>>>>> However, note comment above re. use of UDP.
>>>>>>

---

From: Randy Turner <[email-masked]>
Date: Wed, 11 Nov 2015 16:33:15 -0500

I agree, the introduction of an LLC-enabled 802.15.4 will naturally cause issues because of the additional LLC header on the network — but for a traditional, clean way to mux/demux the MAC I’ll pay a small price.  It’s much better than the implementations I’ve seen that roll this by hand…at least what I’ve seen, the code isn’t too elegant, and it doesn’t link up with traditional MAC interface code found in portable IP stacks which expect something like an LLC registration API ( “I want to register an ether type with the LLC layer”)

R.

> On Nov 11, 2015, at 12:03 PM, Robert Cragie <[email-masked]> wrote:
> 
> My main concern with the LLC work is that it is not clear to me how it can be compatible with existing 802.15.4 deployments if, say, an Ethertype is mandated as part of the LLC. 6LoWPAN already (albeit rather crudely, although the proposed paging mechanism could fix this) allows for multiplexing through the use of the NALP type. Whatever would be done for the LLC is already being done in existing adaptation layers.
> 
> Robert
> 
> On 10 November 2015 at 19:58, rturner amalfisystems.com <http://amalfisystems.com/> <[email-masked] <mailto:[email-masked]>> wrote:
> Hi Guys,
> 
>> On November 10, 2015 at 12:24 PM Jonathan Hui <[email-masked] <mailto:[email-masked]>> wrote:
>> 
>> On Tue, Nov 10, 2015 at 3:00 AM, Robert Cragie <[email-masked] <mailto:[email-masked]>> wrote:
>> On 8 November 2015 at 23:28, Alper Yegin <[email-masked] <mailto:[email-masked]>> wrote:
>> Robert,
>> 
>>> On 7 November 2015 at 21:26, Alper Yegin <[email-masked] <mailto:[email-masked]>> wrote:
>>> Hi Robert,
>>> 
>>>> On 7 November 2015 at 11:00, Alper Yegin <[email-masked] <mailto:[email-masked]>> wrote:
>>>> Hello Robert,
>>>> 
>>>>> On 5 November 2015 at 00:06, Malisa Vucinic <[email-masked] <mailto:[email-masked]>> wrote:
>>>>> 
>>>>> > On 05 Nov 2015, at 00:18, Michael Richardson <[email-masked] <mailto:[email-masked]>> wrote:
>>>>> >
>>>>> >
>>>>> [email-masked] <mailto:[email-masked]>
>>>>> https://www.ietf.org/mailman/listinfo/6tisch <https://www.ietf.org/mailman/listinfo/6tisch>
>>>>> 
>>>>> [email-masked] <mailto:[email-masked]>
>>>>> https://www.ietf.org/mailman/listinfo/6tisch <https://www.ietf.org/mailman/listinfo/6tisch>
>>>> 
>>>> 
>>>> [email-masked] <mailto:[email-masked]>
>>>> https://www.ietf.org/mailman/listinfo/6tisch <https://www.ietf.org/mailman/listinfo/6tisch>
>>> 
>>> 
>>> [email-masked] <mailto:[email-masked]>
>>> https://www.ietf.org/mailman/listinfo/6tisch <https://www.ietf.org/mailman/listinfo/6tisch>
>> 
>> 
>> [email-masked] <mailto:[email-masked]>
>> https://www.ietf.org/mailman/listinfo/6tisch <https://www.ietf.org/mailman/listinfo/6tisch>
>> 
>> 
>> 
>> [email-masked] <mailto:[email-masked]>
>> https://www.ietf.org/mailman/listinfo/6tisch <https://www.ietf.org/mailman/listinfo/6tisch>
>> 
>> 
>> [email-masked] <mailto:[email-masked]>
>> https://www.ietf.org/mailman/listinfo/6tisch <https://www.ietf.org/mailman/listinfo/6tisch>
> 
>  
> 
>

---

From: Paul Duffy <[email-masked]>
Date: Wed, 11 Nov 2015 17:34:41 -0500

On 11/7/2015 10:40 AM, Robert Cragie wrote:
> successfully completed after an extensive specification, 
> implementation and test program, demonstrating interoperability across 
> 7 independent platforms,
>

Agreed.

> so the solution is certainly proven.
>

There is no way I would designate a solution as proven w/o a significant 
field deployment.

> Robert
>
> On 5 Nov 2015 16:23, "Paul Duffy" <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>     Wi-SUN consists of several profiles.  EchoNet and Field Area
>     Network being prominent.  FAN is using 802.1X / EAP-TLS.
>
>
>         Then please note that PANA is RFC, has multiple
>         implementations, adopted by other standards (Zigbee and
>         Wi-Sun), and already getting deployed (Wi-Sun).
>
>
>             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.
>
>         OK.
>         Note that, though, any solution you'd have would need to have
>         the equivalent of that one message where the client says
>         "hello, let's start auth".
>
>
>         But like I said above, discovery message needs to be supported
>         by any other solution as well, hence I don't think it's extra
>         for "EAP/PANA"
>
>         Alper
>
>
>
>
>             Regards,
>             Mališa
>
>
>                 On 31 Oct 2015, at 22:43, Alper Yegin
>                 <[email-masked] <mailto:[email-masked]>>
>                 wrote:
>
>                 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?
>
>
>                 (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:
>                     - 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.
>
>                 - 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: Robert Cragie <[email-masked]>
Date: Wed, 11 Nov 2015 23:51:10 +0000

Well, I guess we can argue about what we mean by "proven" here. I agree
that the ultimate test of the worthiness of a solution is a successful and
significant field deployment. However, achieving that level of
interoperability certainly proves the solution with regard to the original
requirements.

Robert

On 11 November 2015 at 22:34, Paul Duffy <[email-masked]> wrote:

> platforms,
> On 5 Nov 2015 16:23, "Paul Duffy" < <[email-masked]>[email-masked]>
> wrote:
>
>>>> On 31 Oct 2015, at 22:43, Alper Yegin < <[email-masked]>
>>>>> [email-masked]> wrote:
>>>>>
>>>>> Hello,
>>>>>
>>>>> 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
>>>>> - Traffic load: minimum 4 messages for PANA + [ 5 messages for
>>>>>> EAP-AKA, 15+ messages for EAP-TLS ] + 1 packet to provision K2
>>>>>>
>>>>> Also that last 1 packet is not needed either. The last packet sent
>>>>> from the authenticator can deliver that payload.
>>>>>

---

From: Alper Yegin <[email-masked]>
Date: Thu, 12 Nov 2015 09:15:37 +0200

Hi Yoshi,

Unlike legacy EAP transports, the final EAP result delivery in PANA is two-way (acknowledged) and also crypto-protected using the key generated from successful EAP authentication. Therefore, I don't think we need an additional step of key confirmation. 

Alper

---

From: <[email-masked]>
Date: Fri, 13 Nov 2015 01:00:07 +0000

There are significant field deployment efforts ongoing for smart meters in Japan.

In Japan, there is an operational guideline for smart meters supporting so called “B-Route” which is a communication interface between smart meter and HEMS (Home Energy Management System) controller.  B-route is a part of HAN (Home Area Network).

The operational guideline is available at:
http://www.meti.go.jp/committee/kenkyukai/shoujo/smart_house/pdf/006_s03_00.pdf
(the document is written in Japanese)

In the guideline, smart meters and HEMS controllers need to obtain three types of certification: B-route media certification, ECHONET-Lite certification and SMA certification.  B-route media certifications for 920MHz band is based on “Wi-SUN profile for ECHONET-Lite” which mandates PANA for network access authentication over 6LoWPAN over IEEE 802.15.4e/g (see the protocol stack diagram in page 36 of the guideline). BTW, “Wi-SUN profile for ECHONET-Lite” defines not only B-route interface but also the entire ECHONET HAN interface for 920MHz band.

All Japanese electric power companies follow the guideline and  have chosen Wi-SUN as their primary communication interface for B-route as indicated in page 8 of the guideline.

There is also data on how many smart meters are planned for deployment in Japan.  See the table in page 6 of the following document:
http://www.meti.go.jp/committee/summary/0004668/pdf/015_03_00.pdf
(the document is written in Japanese)

The table shows number of smart meters to be deployed in each year by each regional electric power company in Japan (unit: 10K).   According to the table, more than 80 million of smart meters will be deployed by Y2024 (and
all of them will use PANA for B-route primary interface).   As of today, there are more than 50 Wi-SUN-certified products in Wi-SUN B-Route category.

Regards,
Yoshihiro Ohba

From: 6tisch [mailto:[email-masked]] On Behalf Of Paul Duffy
Sent: Thursday, November 12, 2015 6:35 AM
To: [email-masked]
Cc: [email-masked]
Subject: Re: [6tisch] PANA clarifications (was Re: Directions on the join process)

Paul,

Whatever the state of ZigBee IP, it doesn't alter the fact that it successfully completed after an extensive specification, implementation and test program, demonstrating interoperability across 7 independent platforms,

Agreed.

There is no way I would designate a solution as proven w/o a significant field deployment.

Robert
On 5 Nov 2015 16:23, "Paul Duffy" <[email-masked]<mailto:[email-masked]>> wrote:
Re: PANA traction in the market.

Alper

Regards,
Mališa

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

Hello,

I hope these help.

Alper