Skip to content

Commit

Permalink
Consider two cases for reverse flow
Browse files Browse the repository at this point in the history
  • Loading branch information
@geonnave
geonnave committed Oct 15, 2024
1 parent 0d2e147 commit 820bf47
Showing 1 changed file with 75 additions and 41 deletions.
116 changes: 75 additions & 41 deletions draft-ietf-lake-authz.md
View file
Original file line number Diff line number Diff line change
Expand Up @@ -744,7 +744,7 @@ DOMAIN_ID: bstr

Where:

- ELA_ID identifies the ELA protocol (NOTE: can we register such an identifier at IANA?)
- ELA_ID identifies the ELA protocol (Editor's note: can we register such an identifier at IANA?)
- DOMAIN_ID identifies the domain to which V belongs to, for example an URL or UUID

Details on how exatcly these fields are structured are left to the application.
Expand Down Expand Up @@ -906,18 +906,52 @@ IANA has added the following Content-Format number in the "CoAP Content-Formats"

# Use with EDHOC reverse flow {#edhoc-reverse}

Editor's note: I am not sure if this should be an appendix or an actual section in the main document.

This appendix describes how the protocol can be used with the reverse message flow defined in {{Appendix A.2.2 of RFC9528}}, where the CoAP client is the Responder and the CoAP server is the initiator.

## U is the Initiator {#reverse-u-init}

The reverse flow can be applied when U implements a CoAP server, but acts as an EDHOC Initiator.
In this case, U awaits for a CoAP request to be sent from V, which will act as a trigger message to start the EDHOC handshake with ELA.
Next, U replies with an EDHOC message_1, thus executing the protocol normally.

One use case is to perform ELA over Bluetooth Low Energy, as discussed in {{I-D.amsuess-core-coap-over-gatt}}.

{{fig-reverse}} illustrates the reverse flow for ELA.
The main change is that the values of the Voucher_Info and Voucher structs are sent over EAD_2 and EAD_3, respectively (instead of over EAD_1 and EAD_2).
~~~~~~~~~~~ aasvg
+-------+--------+ +-------+--------+
| Init | Server | | Resp | Client |
+-------+--------+ +----------------+
| U | | V |
+----------------+ +----------------+
| |
| CoAP request |
|<--------------------------------|
| |
| EDHOC message_1 |
+-------------------------------->|
| (EAD_1 = Voucher_Info) |
| |

( ... protocol continues normally ... )

~~~~~~~~~~~
{: #fig-reverse-u-init title="ELA with EDHOC reverse mesasge flow when U is initiator." artwork-align="center"}

## U is the Responder {#reverse-u-resp}

U may implement a CoAP client, but act as a Responder, as illustrated in {{fig-reverse}}.
The main change in this case is that the values of the Voucher_Info and Voucher structs are sent over EAD_2 and EAD_3, respectively (instead of over EAD_1 and EAD_2).

~~~~~~~~~~~ aasvg
+-------+--------+ +-------+--------+ +---------------+
| Init | Server | | Resp | Client | | |
| Resp | Client | | Init | Server | | |
+-------+--------+ +----------------+ | W |
| U | | V | | |
+----------------+ +----------------+ +---------------+
| | |
| CoAP request | |
+-------------------------->| |
| | |
| EDHOC message_1 | |
+<--------------------------| |
Expand All @@ -935,43 +969,6 @@ The main change is that the values of the Voucher_Info and Voucher structs are s
~~~~~~~~~~~
{: #fig-reverse title="Use with EDHOC reverse mesasge flow." artwork-align="center"}

# Example Advertisement Strategies {#example-advert}

## Advertisement in the EDHOC reverse flow

ELA with EDHOC in the reverse flow allows implementing advertising where U first sends a trigger packet, in the format of a CoAP solicitation packet that is broadcasted to the newtork.
When a suitable V receives the solicitation, if it implements ELA, it should respond with an EDHOC message_1 whose EAD_1 contains some information about V (V_INFO as described in Section {{optimization-strat}}).
In this case, EAD_1 uses label TBD1 and value V_INFO.

~~~~~~~~~~~ aasvg
+-------+--------+ +-------+--------+
| Init | Server | | Resp | Client |
+-------+--------+ +----------------+
| U | | V |
+----------------+ +----------------+
| |
+- - - - - - - - - - - - - - - -->|
| CoAP discovery/solicitation |
| |
| EDHOC message_1 |
+<--------------------------------|
| (?EAD_1 = V_INFO) |
| |

( ... protocol continues normally ... )

~~~~~~~~~~~
{: #fig-reverse-adv title="Advertisement of ELA support with EDHOC reverse mesasge flow." artwork-align="center"}

Note that V will only reply if it supports ELA, therefore in this strategy there is no need to transport ELA_ID as part of V_INFO.
V_INFO can then be structured to contain only the optional domain identifier:

~~~ cddl
V_INFO = (
?DOMAIN_ID: bstr,
)
~~~

# Use with Constrained Join Protocol (CoJP)

This section outlines how the protocol is used for network enrollment and parameter provisioning.
Expand Down Expand Up @@ -1076,6 +1073,43 @@ The authenticator playing the role of the {{RFC9031}} JRC obtains the device ide
Flight 4 is the OSCORE response carrying CoJP response message.
The message is processed as specified in {{Section 8.4.2 of RFC9031}}.

# Example Advertisement Strategies {#example-advert}

## EDHOC reverse flow when U is Initiator and CoAP Server

_PR editor's note: this is approach A2_

ELA with EDHOC in the reverse flow allows implementing advertising where U first sends a trigger packet, in the format of a CoAP solicitation packet that is broadcasted to the newtork.
When a suitable V receives the solicitation, if it implements ELA, it should respond with an EDHOC message_1 whose EAD_1 has label TBD1 and value V_INFO (see Section {{optimization-strat}}).

~~~~~~~~~~~ aasvg
+-------+--------+ +-------+--------+
| Init | Server | | Resp | Client |
+-------+--------+ +----------------+
| U | | V |
+----------------+ +----------------+
| |
+- - - - - - - - - - - - - - - -->|
| CoAP discovery/solicitation |
| |
| EDHOC message_1 |
+<--------------------------------|
| (?EAD_1 = V_INFO) |
| |

( ... protocol continues normally ... )
~~~~~~~~~~~
{: #fig-reverse-adv title="Advertisement of ELA support with EDHOC reverse mesasge flow." artwork-align="center"}

Note that V will only reply if it supports ELA, therefore in this strategy there is no need to transport ELA_ID.
V_INFO can then be structured to contain only the optional domain identifier:

~~~ cddl
V_INFO = (
?DOMAIN_ID: bstr,
)
~~~

# Enrollment Hints {#hints}
This section defines items that can be used in the OPAQUE_INFO field of either EAD_1 or the Access Denied error response.
The purpose of the proposed items is to improve protocol scalability, aiming to reduce battery usage and enrollment delay.
Expand Down

0 comments on commit 820bf47

Please sign in to comment.