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

From: Michael Richardson <[email-masked]>
Date: Thu, 09 Mar 2017 19:35:36 -0500

<#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.]

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#section-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.
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 <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-

---

From: Göran Selander <[email-masked]>
Date: Fri, 10 Mar 2017 05:07:52 +0000

>    [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.

>transaction.  This is described in
>draft-ietf-6tisch-dtsecurity-secure-join-01.
>

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

>It is much closer to
>https://datatracker.ietf.org/doc/draft-vanderstok-ace-coap-est/
>
>
>
>--

---

From: Mališa Vučinić <[email-masked]>
Date: Fri, 10 Mar 2017 11:28:59 +0100

Hi Michael,

Note that the bitbucket version of minimal-security now implements your idea of JRC-initiated security handshake in case asymmetric keys are used. The discovery of the pledge is triggered by a “Discovery Message” that maps to CoAP and is sent from the pledge to the JRC. Upon reception of the Discovery Message, JRC can respond with an optional ack and some time later with a prolonged response that initiates the EDHOC handshake. It can also immediately respond with the initiated EDHOC handshake. I think this is a fine compromise between all the subtle versions that have been discussed so far. Let me know what do you think.

In case of PSKs, everything stays the same and we have a single join request/join response exchange.

Mališa

> On 10 Mar 2017, at 01:35, Michael Richardson <[email-masked]> wrote:
> 
>    https://tools.ietf.org/html/draft-ietf-6tisch-dtsecurity-secure-join-00#section-2.2.4 <https://tools.ietf.org/html/draft-ietf-6tisch-dtsecurity-secure-join-00#section-2.2.4>
> 
>       https://ericssonresearch.github.io/EALS/#rfc.section.3.2 <https://ericssonresearch.github.io/EALS/#rfc.section.3.2>
> 
> EALS                                     EALS
> client                                   server
> 
>  |                                        |

---

From: Michael Richardson <[email-masked]>
Date: Fri, 10 Mar 2017 13:59:53 -0500

>> the zero-touch process to be driven by the JRC.

...

    >> 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.
    >>

    > 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.

Yes, EDHOC is reversed, and so the JRC can control when each pledge enrolls.
The JRC would not initiate a message_1 until it is ready for that pledge to
enroll.   Once it has received message_2, the JRC will know securely exactly
who is trying to connect, and if it still has concerns, or there just isn't
network bandwidth yet, it could delay sending message_3 until it is ready.

What we need to do is figure out is how the JRC inserted delays might affect
retransmission timers.  I think that the messages are all CoAP transactions
initiated from the EDHOC initiator.

>  +--------------------------------------->|    Third party

how does the initatior know that message_3 arrived okay?
I seem to be missing an ACK for this message.

---

From: Michael Richardson <[email-masked]>
Date: Sat, 11 Mar 2017 16:06:16 -0500

Mališa Vučinić <[email-masked]> wrote:
    > Note that the bitbucket version of minimal-security now implements your
    > idea of JRC-initiated security handshake in case asymmetric keys are
    > used. The discovery of the pledge is triggered by a “Discovery Message”
    > that maps to CoAP and is sent from the pledge to the JRC.  Upon

I will read it now.

I have rebased my other changes, and updated the pull request.

Let's post!

---

From: Michael Richardson <[email-masked]>
Date: Sat, 11 Mar 2017 16:39:51 -0500

> that maps to CoAP and is sent from the pledge to the JRC.  Upon

I have read now:
  It's in section Security Handshake, right?

Your description is too simple, and I don't think it makes any sense to put
it here. I think it should simply refer to dtsecurity-secure-join.

As for the Discovery Message, this seems reasonable.
Is this process optional, or is it caused by the init bit in the EB being
clear?

It needs to have a mandatory reply so that the pledge knows that it has
succeeded in reaching the JRC.  A reply from the JRC might also need to
indicate that the pledge should proceed to initiate?

---

From: Mališa Vučinić <[email-masked]>
Date: Mon, 20 Mar 2017 14:13:33 +0100

> On 11 Mar 2017, at 22:39, Michael Richardson <[email-masked]> wrote:
> 

I think that we definitely need to expand somewhere on the security handshake in minimal-security document, it is a matter of preference where the section should exactly go. The overview sections only show the security handshake as a single transaction between JRC and the pledge. I’ve put the expanded security handshake in the current place in order to precede the simple join protocol section that similarly expands on the join request/response exchange. What part do you find too simple? The paragraph on special certificate being issued to JRC? If so, what text do you propose to replace that?

> Is this process optional, or is it caused by the init bit in the EB being

To my understanding, init bit is there to differentiate between the minimal-security and NS DAD dtsecurity-secure-join processes. Ideally, I think it would be great if we could converge on the initiation process between the two documents with the Discovery Message, therefore removing the need for the init bit. In minimal-security, Discovery Message is mandatory *when* performing the security handshake. The security handshake, however, is optional and is performed in case the pledge was provisioned with asymmetric keys. The decision what message to send first, i.e. the Discovery Message or the Join Request, is internal to the pledge and depends on the credential it has been provisioned with. 

> succeeded in reaching the JRC.  

The reply to the Discovery Message is either an empty CoAP ACK signaling to the pledge it has reached the JRC but needs to wait, or an immediate response from JRC initiating the EDHOC handshake. Either way, pledge knows it has succeeded in reaching JRC. Which response JRC opts for could be dependent on how many pledges are currently enrolling.

> A reply from the JRC might also need to

I don’t understand, could you elaborate?

---

From: Michael Richardson <[email-masked]>
Date: Mon, 20 Mar 2017 17:26:54 -0400

Mališa Vučinić <[email-masked]> wrote:
    mcr>     Your description is too simple, and I don't think it makes any
    mcr> sense to put it here. I think it should simply refer to
    mcr> dtsecurity-secure-join.

    > I think that we definitely need to expand somewhere on the security
    > handshake in minimal-security document, it is a matter of preference
    > where the section should exactly go. The overview sections only show
    > the security handshake as a single transaction between JRC and the
    > pledge.

okay.

    > I’ve put the expanded security handshake in the current place
    > in order to precede the simple join protocol section that similarly
    > expands on the join request/response exchange. What part do you find
    > too simple? The paragraph on special certificate being issued to JRC?
    > If so, what text do you propose to replace that?

Yes, that's the text: it is too vague to be useful, but expanding it in that
document is wrong.

    mcr>     As for the Discovery Message, this seems reasonable.  Is this
    mcr> process optional, or is it caused by the init bit in the EB being
    mcr> clear?

    > To my understanding, init bit is there to differentiate between the
    > minimal-security and NS DAD dtsecurity-secure-join processes.

Yes, but I think the distinction could be more subtle.
There could be more possibilities resulting from hybridizing the two ideas.

We have a number of different possibilities, and I don't think people have
had a chance to fully consider the possibilities.

I'm trying to capture this into slides for next week.

    > Ideally,
    > I think it would be great if we could converge on the initiation
    > process between the two documents with the Discovery Message, therefore
    > removing the need for the init bit.

    > In minimal-security, Discovery
    > Message is mandatory *when* performing the security handshake. The
    > security handshake, however, is optional and is performed in case the
    > pledge was provisioned with asymmetric keys. The decision what message
    > to send first, i.e. the Discovery Message or the Join Request, is
    > internal to the pledge and depends on the credential it has been
    > provisioned with.

Agreed.

    >     It needs to have a mandatory reply so that the pledge knows that it
    > has succeeded in reaching the JRC.

Agreed.

    > The reply to the Discovery Message is either an empty CoAP ACK
    > signaling to the pledge it has reached the JRC but needs to wait, or an
    > immediate response from JRC initiating the EDHOC handshake. Either way,
    > pledge knows it has succeeded in reaching JRC. Which response JRC opts
    > for could be dependent on how many pledges are currently enrolling.

I had the same thought: if we always send message_1 of minimal-security,
and we have some way to get an ACK that isn't message_2, but that tells the
pledge that it can stop sending, then that accomplishes the goal of the init
bit, and communicates the existence of the pledge to the JRC.

I think that I said this in another email, but perhaps it was wrapped into
the EALS discussion...

    mcr>     A reply from the JRC might also need to indicate that the pledge
    mcr> should proceed to initiate?

    > I don’t understand, could you elaborate?

I think you got it above :-)

---

From: Mališa Vučinić <[email-masked]>
Date: Tue, 21 Mar 2017 14:41:11 +0100

Do you mean pledge-initiated message_1 (pledge being the party U)? What you describe can be done with the same mechanism as currently done in minimal-security and the Discovery Message — empty CoAP ACK. One issue there is that identity of U is not sent until message_3. We could piggyback the identity of U in EXT_1 but that would break identity protection of Sigma-I though.

> On 20 Mar 2017, at 22:26, Michael Richardson <[email-masked]> wrote:
>

---

From: Michael Richardson <[email-masked]>
Date: Tue, 21 Mar 2017 10:40:05 -0400

Mališa Vučinić <[email-masked]> wrote:
    > Do you mean pledge-initiated message_1 (pledge being the party U)?
    > What you describe can be done with the same mechanism as currently done
    > in minimal-security and the Discovery Message — empty CoAP ACK.

Yes, I was thinking of this exactly.
I was thinking that CoAP ACK, with a unique code.

    > One
    > issue there is that identity of U is not sent until message_3. We could
    > piggyback the identity of U in EXT_1 but that would break identity
    > protection of Sigma-I though.

Yes, I was also thinking that this is a concern.  The identity could be
subtly masked in a variety of ways.

If we do this, then we combine the notification by pledge with the first
message, and eliminate the need for the "init" bit.