Rafa Marin Lopez writes:
> > Of course the ACL can also be distributed from tje JCE to the JAs, but
> > if the ACL is large, it is better to do the check when the JN joins.
> > This also protects the device association, and the IP address
> > assignments, as all communcation betwee JN-JA is done over 802.15.4
> > frames, and no IP-address is needed yet.
>
> I guess HIP-DEX could be also used alternatively. In any case, how
> does the JCE know the JN is actually there? Because, in the end, the
> JCE does not authenticate the JN. This has been discussed in the
> past ("peer consent”). In my opinion, the JCE should be in charge of
> first-hand authenticating the JN.
HIP-DEX is one of the KMPs which can be used with 802.15.9. I have not
really checked HIP-DEX for the set of features, so you might be right
there.
Of course if the KMP is run only between JN and JA, and the ACL check
is done between JA and JCE, then JCE has to trust JA to check
credentials of the JN before letting it to join. If you do not trust
your JAs enough to do that, then you need to run EAP and run
authentication in the JCE instead of in the JA.
With IKEv2 both options are possible, and which one you want to use
depends on the environment.
> >> Case 1.B: EAP over PANA
> >> - Traffic load: minimum 4 messages for PANA + [ 5 messages for EAP-AKA, 15+
> >> messages for EAP-TLS ] + 1 packet to provision K2
> >> - Implementation requirements: PANA, EAP method
> >> - Notes: JA is a passive relay
> >
> > Good thing here is that it is reusing lots of existing protocols, bad
> > thing is that you need lots of messages. Also I think you need to get
> > IP-address before you can run PANA (unless you run PANA over
> > 802.15.9), so that will add overhead and also consume resources.
>
> My understanding is that IKEv2 was designed to be transported on top
> of UDP. Thus, if IKEv2 can be transported in IEEE 802.15.9,
> similarly PANA or CoAP could be transported as well. In the case of
> CoAP, even there is some study with coapie. In case of PANA, there
> was some proposal about it.
PANA is already defined to be used in the 802.15.9, but PANA defined
in 802.15.9 is used in bootstrapping, i.e. getting LLCs and then you
need to still run some operational KMP over 802.15.9 to use those
credentials to generate the final keying materials. I am not a PANA
expert, so do not know how it is supposed to work... :-)
CoAP could be run over 802.15.9, but as it is not KMP it cannot be
used as KMP for generating keys for 802.15.4... CoAP could use the
Multiplexing layer of the 802.15.9, and it can be used to fragment and
transport messages from one node to another and identify those
messages as CoAP messages instead of KMP messages.
Adding new KMPs to 802.15.9 is quite easy as mostly you need to
allocate number for the KMP and define how the 802.15.4 keying
material is extracted from the KMP.
Using 802.15.9 multiplexing layer is also easy, as there is separate
multiplexing ID, which can be used to multiplex KMP traffic and other
traffic (CoAP or similar) over 802.15.9 IEs. The multiplexing IDs are
ethertypes, so if you already have ethertypes allocated you can use
that directly, or if not, you can allocate one from the reserved
range.
> Btw, in Zigbee IP they already use PANA and the link-local IPv6
> address in the JN, as far as I remember. PANA has also a "PANA
> relay" (RFC 6345) defined for the JA.
If I have understood correctly what is defined in the 802.15.9 Annex D
PANA, is just about what is done in Zigbee IP.
> >> Case 1.C. EAP-PSK over CoAP + DTLS (e.g. draft-marin-ace-wg-coap-eap-02)
> >> - Traffic load: 10 messages between JN-JCE to establish a unique session
> >> key +
> >> 11 messages for DTLS to establish a session with the established key + 1
> >> packet to provision K2
> >> - Implementation requirements: EAP-PSK, (DTLS)
> >> - Notes: JA is a passive relay
> >
> > Same as 1.C. I.e. need IP-address, cannot protect IP-address
> > assignment (and device association, if that is needed before getting
> > IP-address), quite a lot of packets.
>
> As commented above, transporting CoAP in IEs could be a possibility.
Yep.
> >> Case 1.D. EAP-PSK over CoAP + custom protection of CoAP header/payload with
> >> the generated key
> >> - Traffic load: 10 messages between JN-JCE to establish a unique session
> >> key +
> >> 1 packet to provision K2
> >> - Implementation requirements: EAP-PSK, custom CoAP security extension
> >> - Notes: JA is a passive relay
> >
> > Anything that we need to define here as security will be bad idea,
> > i.e. designing KMP is not that easy. There are lots of pitfalls you
> > might trip into, and I would recommend against specifying new KMP here.
>
> I do not think this is referring to a new key management protocol
> (there is no protocol exchanges) but only a way to protect CoAP
> messages at application level with some key material obtained from
> the EAP authentication. For example, OSCOAP could be an example
> (https://tools.ietf.org/html/draft-selander-ace-object-security-03)
That will be very simple key management protocol, but it still will be
key management protocol. EAP is authentication protocol, and how to
derive keys from the secret it generates to protect something is KMP.
Even if it just defines key hierarchy and how to get keys for
different levels.
Also quite soon you will realize that we need to have rekeys, and we
need to be able to distribute group keys, and we need to do group
membership management -> you are adding more and more KMP features...
> >> Option 2: DTLS-based
> >> ———————————
> >> Case 2.A: JN is a DTLS client
> >> - Traffic load: 11 messages between JN-JCE + 1 packet to communicate K2
> >> over
> >> the established session
> >> - Implementation requirements: (DTLS), relay application
> >> - Notes: JA is a passive relay
> >
> > This would allow us to use any DTLS authentication methods, i.e. I
> > tihnk we could use raw public keys etc.
>
> The usage of EAP would also provide all the flexibility in term of
> authentication method. That was the main motivation of the EAP
> design.
But immediately when you move from the built in authentication methods
of the KMPs like DTLS, or IKEv2 to EAP you get more messages, i.e.
more overhead. Thats why IKEv2 do not use EAP all the time, it uses it
only if base shared key, or public key authentication is not enough...
--
[email protected]
_______________________________________________
6tisch mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/6tisch
