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