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]> 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] >> https://www.ietf.org/mailman/listinfo/6tisch > > _______________________________________________ > 6tisch mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/6tisch _______________________________________________ 6tisch mailing list [email protected] https://www.ietf.org/mailman/listinfo/6tisch
