Re: [6tisch-security] EALS and how to go from 6tisch-minimal-security to zero-touch enrollment

[Göran Selander <[e-mail]>]

On 2017-03-10 01:35, "Michael Richardson" <[e-mail]> wrote:

>
><#secure method=pgpmime mode=sign>
>
>reply set to list.
>
>Goran and co have produced a version/profile of EDHOC for use with the
>zero-touch join process.  It is presently at:
>           https://ericssonresearch.github.io/EALS/
>    [Annoyingly, not posted as draft-selander-ace-eals-00 yet.]

:-)

So now we all know one source of Michael’s recent thread on ietf.org.
Thanks for presenting the content to 6tisch security. One comment inline.

>
>I had previously written privately that in trying to merge 6tisch-minimal
>and
>zero-touch secure join that I am now considering a compromise where the
>zero-touch process would simply start with the 6tisch-minimal EDHOC
>transaction.  This is described in
>draft-ietf-6tisch-dtsecurity-secure-join-01.
>
>In order for the pledge to be passive, and the JRC to manage the bulk
>(certificates and vouchers take a dozen fraglets, sadly), I would like
>the zero-touch process to be driven by the JRC.
>
>In draft-ietf-6tisch-dtsecurity-secure-join-00, I had suggested that the
>security protocol be initiated from the JRC. The JRC would become aware of
>the pledge through a combination of the pledge doing a DAD process, and
>the Join Proxy running a query to the JRC.  In -00 that query was
>implemented in GRASP, but that could be replaced with some other
>query/response protocol, built upon CoAP if desired.  This was described
>in
>    
>https://tools.ietf.org/html/draft-ietf-6tisch-dtsecurity-secure-join-00#se
>ction-2.2.4
>
>This was removed in -01: in -01 the "notification" of the JRC of the new
>pledge is when the pledge performs the EDHOC process which is common to
>zero-touch and one-touch.
>
>But, EALS suggests something slightly different again.
>
>Figure 5, reproduced below from:
>       https://ericssonresearch.github.io/EALS/#rfc.section.3.2
>
> EALS                                     EALS
>client                                   server
>
>  |                                        |
>  |      MESSAGE TO BE DETERMINED          |
>  +--------------------------------------->|
>  |                                        |
>  |             EDHOC message_1            |
>  |<---------------------------------------+
>  |                                        |
>  |            EDHOC message_2             |
>  +--------------------------------------->|    Third party
>  |                                        | < - - - - - - - - >
>  |  EDHOC message_3 (EXT_3 = Authz info)  |    authorization
>  |<---------------------------------------+
>  |                                        |
>
>
>EALS also proposes to move the voucher nonce and ownership voucher into
>the
>protocol itself, eliminating the provisional state, and ownership voucher.
>
>This moves the entire exchange control back to the JRC.
>No CoMI interface would be needed for communicating the voucher.
>
>EALS suggests that the enrollment occur over CoAP, driven by the pledge.

Actually, we mention that the EDHOC protocol may be reversed, and it may
be driven by the JRC, but first authenticating the pledge enables the
authorization step to come earlier.

Göran


>The initial network key(s) can be returned by the EALS server just as in
>the
>6tisch-minimal-security case, so the pledge will be full on the network
>when
>it performs certificate enrollment.
>It is much closer to
>https://datatracker.ietf.org/doc/draft-vanderstok-ace-coap-est/
>
>
>
>--
>Michael Richardson <[e-mail]>, Sandelman Software Works
> -= IPv6 IoT consulting =-
>
>
>