[core] key provisioning and device association

["Garcia Morchon, Oscar" <[e-mail]>]

Dear all,

Yesterday afternoon Yoshi, Subir and myself had a good discussion
about approaches related for key provisioning and device association.

We would like to create a forum to discuss this all together. Next we
wanted to briefly share with you some of the main points (comments/
additions are welcome):

- We think that this is an important aspect that should be considered
within the working group.
- we have to align and discuss different approaches.
        - approach in https://datatracker.ietf.org/doc/draft-ohba-core-eap-based-bootstrapping/
        is a particular approach. We believe that it can work in many use
        cases; however, it really needs to be analyzed how well it fits, e.g., very
        resource-constrained devices/networks. At the end of this email you
        find a description of the involved messages.
        - as described in Section 6 in https://datatracker.ietf.org/doc/draft-garcia-core-security/ ,
        different applications might have different needs, in particular:
                - some approaches might be required due to legacy systems (e.g., AAA
                architectures usually rely on EAP methods)
                - some (new) lightweight approaches might be needed to fit in small
                devices/constrained networks.
                        - In particular, in Prague was discussed the possibility of a very
                        lightweight " Duckling and Mother " approach and I believe that Carsten had started to
                        write an I-D in that direction based on DTLS. In this approach, DTLS was used
                        to set up a common key to be used by a pair of devices.
                        - I think it would be good to recover/think about Carsten's approach.
- different approaches can/should be evaluated in: # messages/code size/security/flexibility

-------------------------

A few ideas/steps to make next steps more concrete:

a) it would be good to create a group "flexible bootstrapping" I-D which includes
methods addressing key use cases.

b) in particular, it would be good to create an extensible bootstrapping fitting
different use cases. Two main needs are as follows (others?)
        case 1: lightweight applications that have to reuse as much as possible
                existing code and limit number of exchanged messages bytes
                (e.g., reuse of operational security protocols (e.g., DTLS) for key provisioning
                Device association to a security domain)
        case 2: legacy systems in which protocol reuse is needed.
                (use of specialized protocols)
c) a particular approach - that might be included in the I-D - would be a modular
method in which starting with a very basic method valid for resource-constrained
devices, the method can be extended in such a way that might also cover legacy
systems. This is just a first thought, but that might be good to further analyze
it. The approach might have three levels of complexity:
        - Level 1: very basic "local" approach based on DTLS (as described by Carsten)
                and allowing for "Duckling and Mother" key provisioning between two devices.
                (two devices that are close by can setup a common key that can be used with
                DTLS later. For the ""Duckling and Mother" DTLS is reused so that
                No additional source code is needed")
        - Level 2: very basic "centralized" (D)TLS approach in which (D)TLS is used for
                key provisioning from a central device in the Internet. The key provisioning
                Might distribute in a secure way some keys to be used in a given security domain).
                (here DTLS is reused so no additional code is required)
        - Level 3: TLS can be reused as lower layer for EAP (http://tools.ietf.org/html/draft-nir-tls-eap-12 ).
                If the same could be done with DTLS, EAP might be transported and CoAP
                devices could interact with existing AAA infrastructures. This approach
                however increases the requirements in source code in the devices and
                might involve a higher overhead.

d) the above approach allows for fully interoperability, in the sense that the methods
can be extended to address different use cases, but it also requires more standardization.
Another approach would be to keep Step 1 and Step 2 based on DTLS as described above, and
also have https://datatracker.ietf.org/doc/draft-ohba-core-eap-based-bootstrapping/.

e) Last week I did some research helped by University of Murcia (Spain) where an open
implementation of PANA has been developed (http://sourceforge.net/projects/openpana/).
Below you find a summary of exchanged messages for the PANA/EAP approach (EAP method based
on certificates, PSK would be more lightweight).

--------------------------------

I hope this helps,

Comments/ideas are very welcome,

Regards,

        Oscar.


===================================================================================================
===================================================================================================
>From OpenPana (http://sourceforge.net/projects/openpana/) developed by University of Murcia (Spain)

PANA CLIENT INITIATION: 16 bytes
PANA AUTH REQUEST (PRF & INTEGRITY Algorithms exchange): 40 bytes PANA AUTH ANSWER (PRF & INTEGRITY Algorithms exchange): 40 bytes
PANA AUTH REQUEST (Carrying EAP Packet & NONCE AVP): 60 bytes PANA AUTH ANSWER (Carrying NONCE AVP): 44 bytes
PANA AUTH REQUEST (Carrying EAP Packet only (EAP RESPONSE)): 36 bytes PANA AUTH ANSWER (Without AVP): 16 bytes
PANA AUTH REQUEST (Carrying EAP Packet only (EAP REQUEST)): 32 bytes PANA AUTH ANSWER (Without AVP): 16 bytes
PANA AUTH REQUEST (Carrying EAP Packet only (CLIENT HELLO)): 88 bytes PANA AUTH ANSWER (Without AVP): 16 bytes
PANA AUTH REQUEST (Carrying EAP Packet only (SERVER HELLO)): 1324 bytes PANA AUTH ANSWER (Without AVP): 16 bytes
PANA AUTH REQUEST (Carrying EAP Packet only (EAP RESPONSE)): 32 bytes PANA AUTH ANSWER (Without AVP): 16 bytes
PANA AUTH REQUEST (Carrying EAP Packet only (TLSV1)): 1112 bytes PANA AUTH ANSWER (Without AVP): 16 bytes
PANA AUTH REQUEST (Carrying EAP Packet only (SSL)): 1432 bytes PANA AUTH ANSWER (Without AVP): 16 bytes
PANA AUTH REQUEST (Carrying EAP Packet only (EAP REQUEST)): 32 bytes PANA AUTH ANSWER (Without AVP): 16 bytes
PANA AUTH REQUEST (Carrying EAP Packet only (TLSV1)): 1364 bytes PANA AUTH ANSWER (Without AVP): 16 bytes
PANA AUTH REQUEST (Carrying EAP Packet only (TLSV1)): 96 bytes PANA AUTH ANSWER (Without AVP): 16 bytes
PANA AUTH REQUEST (Carrying EAP Packet only (EAP RESPONSE)): 32 bytes PANA AUTH ANSWER (Without AVP): 16 bytes
PANA AUTH REQUEST (Carrying EAP Packet (EAP SUCCESS), Key-Id, Result-Code, Session-Lifetime & Auth AVPS): 92 bytes PANA AUTH ANSWER (Carrying Key-Id & Auth Avps): 56 bytes

(Three short comments: (i) message sizes require fragmentation so that the # of packets in the air will be higher; (ii) PANA-AUTH-REQUEST are PANA-AUTH-ANSWER small (16 B) because EAP piggybacking is not active; (iii) if EAP piggybacking is active, the # of messages would decrease.)

The information contained in this message may be confidential and legally protected under applicable law. The message is intended solely for the addressee(s). If you are not the intended recipient, you are hereby notified that any use, forwarding, dissemination, or reproduction of this message is strictly prohibited and may be unlawful. If you are not the intended recipient, please contact the sender by return e-mail and destroy all copies of the original message.