On 11/7/2015 10:40 AM, Robert Cragie wrote:
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.
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 protected]
<mailto:[email protected]>> wrote:
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:
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
Regards,
MaliĊĦa
On 31 Oct 2015, at 22:43, Alper Yegin
<[email protected] <mailto:[email protected]>>
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 protected] <mailto:[email protected]>
https://www.ietf.org/mailman/listinfo/6tisch
_______________________________________________
6tisch mailing list
[email protected] <mailto:[email protected]>
https://www.ietf.org/mailman/listinfo/6tisch
_______________________________________________
6tisch mailing list
[email protected] <mailto:[email protected]>
https://www.ietf.org/mailman/listinfo/6tisch
.
_______________________________________________
6tisch mailing list
[email protected] <mailto:[email protected]>
https://www.ietf.org/mailman/listinfo/6tisch
_______________________________________________
6tisch mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/6tisch
