From 96416963e8b05a767f1c3d93d819db51cc502e32 Mon Sep 17 00:00:00 2001 From: Geovane Fedrecheski Date: Thu, 10 Oct 2024 17:57:22 +0200 Subject: [PATCH 1/9] Add section Optimization Strategies --- draft-ietf-lake-authz.md | 59 ++++++++++++++++++++++++++++++++++++++++ 1 file changed, 59 insertions(+) diff --git a/draft-ietf-lake-authz.md b/draft-ietf-lake-authz.md index cd7ca30..16fbcae 100644 --- a/draft-ietf-lake-authz.md +++ b/draft-ietf-lake-authz.md @@ -80,6 +80,7 @@ informative: RFC5280: RFC6761: RFC7228: + RFC7593: RFC8174: RFC8446: RFC8610: @@ -92,6 +93,11 @@ informative: title: "IEEE Std 802.15.4 Standard for Low-Rate Wireless Networks" author: ins: "IEEE standard for Information Technology" + IEEE802.1X: + title: "IEEE Standard for Local and metropolitan area networks - Port-Based Network Access Control" + date: February 2010 + author: + ins: "IEEE standard for Information Technology" venue: group: "Lightweight Authenticated Key Exchange" @@ -697,6 +703,57 @@ where * H_message_1 is the hash of EDHOC message_1, calculated from the associated voucher request, see {{voucher_request}}. +# Optimization Strategies + +When ELA is used for zero-touch enrollment, U normally has little to no knowledge of the available V's. +This may lead to situations where U has to retry several times at different V's until it finds one that works. +This section presents two optimization strategies for such cases. +They were developed to address scenarios where V's are radio gateways to which U wants to enroll. + +## U anycasts message_1 {#strat-anycast} + +This strategy consists in U disseminating EDHOC message_1 as anycast (a broadcast from which only one successful message_2 response is expected). +When each of the V's in radio range of U receive message_1, one of the following can happen: + +- V does not implement EDHOC, and drops the message +- V does not implement ELA, and since EAD_1 is critical, it either responds with an error or drops the message (preferred) +- V forwards message_1 to W as VREQ, but W does not authorize it, and error handling is applied +- V forwards message_1 to W as VREQ, W authorizes it, and the protocol flows normally + +U is expected to receive at most one message_2 as response, which contains the Voucher. +In case U receives additional message_2's, they MUST be silently dropped. + +This strategy may increase the number of messages that need to be processed by V and W, in exchange for reducing resource usage in U. + +Security concerns related to this strategy, including potential reuse of G_X and double processing of message_2, are discussed in Section {{sec-cons}}. + +## V advertises support for ELA + +In this strategy, V shares some information (V_INFO) with a potential U, that can help it decide whether to try to enroll in that V. +For example, V may send a V_INFO stating that: + +- V implements ELA -- similarly to how EAPOL {{IEEE802.1X}} frames state support for IEEE 802.1X +- V is part of a certain domain -- similarly to how Eduroam {{RFC7593}} is used in the SSID field for IEEE 802.11 networks + +The mechanism used to transport V_INFO will depend on the underlying communication technology and also on application needs. + +As a guideline for implementers, we define the following fields that can be included in a V_INFO structure: + +~~~~~~~~~~~ cddl +ELA_ID: int +DOMAIN_ID: bstr +~~~~~~~~~~~ + +Where: + +- ELA_ID identifies the ELA protocol (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. + +Examples of how the advertisement strategy may be applied according to different application needs are presented in {{example-strat}}. + + # REST Interface at W {#rest_interface} The interaction between V and W is enabled through a RESTful interface exposed by W. @@ -849,6 +906,8 @@ IANA has added the following Content-Format number in the "CoAP Content-Formats" --- back +# Example Optimization Strategies {#example-strat} + # Use with Constrained Join Protocol (CoJP) This section outlines how ELA is used for network enrollment and parameter provisioning. From 88a1fec68270b9a9e3c23bb2a97e9fe7453aab6c Mon Sep 17 00:00:00 2001 From: Geovane Fedrecheski Date: Fri, 11 Oct 2024 13:33:03 +0200 Subject: [PATCH 2/9] Add appendix reverse flow and related advertisement strategy --- .gitignore | 2 ++ draft-ietf-lake-authz.md | 73 ++++++++++++++++++++++++++++++++++++++-- 2 files changed, 72 insertions(+), 3 deletions(-) diff --git a/.gitignore b/.gitignore index f01c7e9..bcb105b 100644 --- a/.gitignore +++ b/.gitignore @@ -22,3 +22,5 @@ draft-ietf-lake-authz.xml package-lock.json report.xml !requirements.txt +*.code-workspace +.vscode/ diff --git a/draft-ietf-lake-authz.md b/draft-ietf-lake-authz.md index 16fbcae..2e0c93e 100644 --- a/draft-ietf-lake-authz.md +++ b/draft-ietf-lake-authz.md @@ -89,6 +89,7 @@ informative: RFC9031: I-D.ietf-core-oscore-edhoc: I-D.ietf-lake-reqs: + I-D.amsuess-core-coap-over-gatt: IEEE802.15.4: title: "IEEE Std 802.15.4 Standard for Low-Rate Wireless Networks" author: @@ -703,7 +704,7 @@ where * H_message_1 is the hash of EDHOC message_1, calculated from the associated voucher request, see {{voucher_request}}. -# Optimization Strategies +# Optimization Strategies {#optimization-strat} When ELA is used for zero-touch enrollment, U normally has little to no knowledge of the available V's. This may lead to situations where U has to retry several times at different V's until it finds one that works. @@ -751,7 +752,7 @@ Where: Details on how exatcly these fields are structured are left to the application. -Examples of how the advertisement strategy may be applied according to different application needs are presented in {{example-strat}}. +Examples of how the advertisement strategy may be applied according to different application needs are presented in {{example-advert}}. # REST Interface at W {#rest_interface} @@ -906,7 +907,73 @@ IANA has added the following Content-Format number in the "CoAP Content-Formats" --- back -# Example Optimization Strategies {#example-strat} +# Use with EDHOC reverse flow {#edhoc-reverse} + +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. +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 | | | ++-------+--------+ +----------------+ | W | +| U | | V | | | ++----------------+ +----------------+ +---------------+ + | | | + | EDHOC message_1 | | + +<--------------------------| | + | | | + | EDHOC message_2 | | + +-------------------------->| | + | (EAD_2 = Voucher_Info) | | + | +------------------------->| + | | Voucher Request (VREQ) | + | |<-------------------------+ + | | Voucher Response (VRES) | + | EDHOC message_3 | | + +<--------------------------| | + | (EAD_3 = Voucher) | | +~~~~~~~~~~~ +{: #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) From 2f2346dd0eab1fbddad3c730b462b8dbaebe10a8 Mon Sep 17 00:00:00 2001 From: Geovane Fedrecheski Date: Fri, 11 Oct 2024 17:32:16 +0200 Subject: [PATCH 3/9] Consider two cases for reverse flow --- draft-ietf-lake-authz.md | 116 +++++++++++++++++++++++++-------------- 1 file changed, 74 insertions(+), 42 deletions(-) diff --git a/draft-ietf-lake-authz.md b/draft-ietf-lake-authz.md index 2e0c93e..29c6309 100644 --- a/draft-ietf-lake-authz.md +++ b/draft-ietf-lake-authz.md @@ -747,7 +747,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. @@ -909,18 +909,50 @@ 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. -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). +## 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. + +~~~~~~~~~~~ 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 | | +<--------------------------| | @@ -938,43 +970,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 ELA is used for network enrollment and parameter provisioning. @@ -1079,6 +1074,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. From 16bb94713adabfada25b9c176a6bacba9c159690 Mon Sep 17 00:00:00 2001 From: Geovane Fedrecheski Date: Tue, 15 Oct 2024 10:54:48 +0200 Subject: [PATCH 4/9] Mention BLE use case for reverse flow --- draft-ietf-lake-authz.md | 2 ++ 1 file changed, 2 insertions(+) diff --git a/draft-ietf-lake-authz.md b/draft-ietf-lake-authz.md index 29c6309..0b95c0d 100644 --- a/draft-ietf-lake-authz.md +++ b/draft-ietf-lake-authz.md @@ -939,6 +939,8 @@ Next, U replies with an EDHOC message_1, thus executing the protocol normally. ~~~~~~~~~~~ {: #fig-reverse-u-init title="ELA with EDHOC reverse mesasge flow when U is initiator." artwork-align="center"} +One use case is to perform ELA over Bluetooth Low Energy, as discussed in {{I-D.amsuess-core-coap-over-gatt}}. + ## U is the Responder {#reverse-u-resp} U may implement a CoAP client, but act as a Responder, as illustrated in {{fig-reverse}}. From d86d6e084ead9de98c25c22ecf949767ac87243a Mon Sep 17 00:00:00 2001 From: Geovane Fedrecheski Date: Tue, 15 Oct 2024 14:48:43 +0200 Subject: [PATCH 5/9] Add CoAP multicast strategy and other improvements --- draft-ietf-lake-authz.md | 108 +++++++++++++++++++++++++++++++++++---- 1 file changed, 97 insertions(+), 11 deletions(-) diff --git a/draft-ietf-lake-authz.md b/draft-ietf-lake-authz.md index 0b95c0d..cc8c4f6 100644 --- a/draft-ietf-lake-authz.md +++ b/draft-ietf-lake-authz.md @@ -81,6 +81,7 @@ informative: RFC6761: RFC7228: RFC7593: + RFC8137: RFC8174: RFC8446: RFC8610: @@ -257,9 +258,9 @@ Authentication credentials and communication security with V is described in {{d W needs to be available during the execution of the protocol between U and V. -# The Protocol +# The Protocol {#protocol} -## Overview +## Overview {#protocol-overview} The ELA protocol consist of three security sessions going on in parallel: @@ -728,7 +729,7 @@ This strategy may increase the number of messages that need to be processed by V Security concerns related to this strategy, including potential reuse of G_X and double processing of message_2, are discussed in Section {{sec-cons}}. -## V advertises support for ELA +## V advertises support for ELA {#strat-advertise} In this strategy, V shares some information (V_INFO) with a potential U, that can help it decide whether to try to enroll in that V. For example, V may send a V_INFO stating that: @@ -911,7 +912,7 @@ IANA has added the following Content-Format number in the "CoAP Content-Formats" 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. +This appendix describes how the protocol can be used with the EDHOC 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} @@ -943,7 +944,7 @@ One use case is to perform ELA over Bluetooth Low Energy, as discussed in {{I-D. ## U is the Responder {#reverse-u-resp} -U may implement a CoAP client, but act as a Responder, as illustrated in {{fig-reverse}}. +The reverse flow can also be used when U implements a CoAP client, but acts 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 @@ -970,7 +971,7 @@ The main change in this case is that the values of the Voucher_Info and Voucher +<--------------------------| | | (EAD_3 = Voucher) | | ~~~~~~~~~~~ -{: #fig-reverse title="Use with EDHOC reverse mesasge flow." artwork-align="center"} +{: #fig-reverse title="ELA with EDHOC reverse mesasge flow when U is responder." artwork-align="center"} # Use with Constrained Join Protocol (CoJP) @@ -1078,16 +1079,56 @@ 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 +This appendix presents three example strategies that can be used to advertise the presence of a V. +It includes sending V_INFO in network beacons, as part of EAD_1 in reverse message flow, or as part of a periodic CoAP multicast packet. +It also presents the advantages, costs, and security impacts of each strategy. + +## V_INFO in network beacons + +_PR editor's note: this is approach A1_ + +This approach allows carrying V_INFO in beacons sent over the network layer, as shown in {{fig-adv-a1}}. +It requires that the network layer offers a mechanism to configure its beacon packets. +Depending on the network type, a solicitation packet may also be needed, as is the case of non-beaconed IEEE 802.15.4 and BLE with GATT. + +~~~~~~~~~~~ aasvg ++-------+--------+ +-------+--------+ +| Init | Client | | Resp | Server | ++-------+--------+ +----------------+ +| U | | V | ++----------------+ +----------------+ + | | + + - - - - - - - - - - - - - - - - - - -->| + | Optional network solicitation | + | | + |<---------------------------------------+ + | Network discovery (contains V_INFO) | + | | + | EDHOC message_1 | + +--------------------------------------->| + | (?EAD_1 = Voucher_Info) | + | | + + ( ... protocol continues normally ... ) +~~~~~~~~~~~ +{: #fig-adv-a1 title="Advertising ELA using V_INFO in network-layer beacons." artwork-align="center"} + +This strategy can be used, for example, in IEEE 802.15.4, where an Enhanced Beacon {{IEEE802.15.4}} can be used to transmit V_INFO. +Specifically, a new information element for carrying V_INFO can be defined according to {{RFC8137}}. + +This approach has the advantage of requiring minimal changes to the default protocol as presented in {{protocol-overview}}, i.e., no reverse flow. +It requires, however, some profiling of the lower layer beacons. + +## V_INFO in EAD_1 _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. +ELA with EDHOC in the reverse flow allows implementing advertising where U first sends a trigger packet, in the format of a CoAP request 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 | +| Resp | Server | | Init | Client | +-------+--------+ +----------------+ | U | | V | +----------------+ +----------------+ @@ -1100,9 +1141,9 @@ When a suitable V receives the solicitation, if it implements ELA, it should res | (?EAD_1 = V_INFO) | | | - ( ... protocol continues normally ... ) + ( ... reverse flow continues normally ... ) ~~~~~~~~~~~ -{: #fig-reverse-adv title="Advertisement of ELA support with EDHOC reverse mesasge flow." artwork-align="center"} +{: #fig-adv-a2 title="Advertising ELA using V_INFO in EAD_1, eploying the EDHOC reverse flow with U as responder." 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: @@ -1113,6 +1154,51 @@ V_INFO = ( ) ~~~ +This approach enables a simple filtering mechanism, where only V's that support ELA will reply. +It also encrypts Voucher_Info (as part of EAD_2), wehereas it is sent in the clear in the original flow. +In addition, it may not require layer-two profiling (in case the network allows transporting data before authorization). +Finally, note that the reverse flow with U as Responder protects the identity of V (instead of U's as in the forward flow). + +## V_INFO in a CoAP Multicast Packet + +_PR editor's note: this is approach A3_ + +In this approach, V periodically multicasts a CoAP packet containing V_INFO, see {{fig-adv-a3}}. +Upon receiving one or more CoAP messages and processing V_INFO, U can decide whether or not to initiate the ELA protocol with a given V. +Next, the application can either keep U acting as a server, and thus employ the EDHOC reverse flow, or implement a CoAP client and use the forward flow. + +~~~~~~~~~~~ aasvg ++--------+---------+ +--------+---------+ +| Init | Cli/Ser | | Resp | Cli/Ser | ++--------+---------+ +------------------+ +| U | | V | ++------------------+ +------------------+ + | | + |<-----------------------------------------+ + | CoAP multicast (contains V_INFO) | + | | + | EDHOC message_1 | + +----------------------------------------->| + | (?EAD_1 = Voucher_Info) | + | | + + ( ... protocol continues normally ... ) +~~~~~~~~~~~ +{: #fig-adv-a3 title="Advertising ELA using the network layer." artwork-align="center"} + +The V_INFO structure is sent as part of the CoAP payload. +It is encoded as a CBOR sequence: + +~~~ cddl +V_INFO = ( + ELA_ID: int, + ?DOMAIN_ID: bstr, +) +~~~ + +One advantage of this approach is that, since U is the initiator, it's identity is protected in the context of the EDHOC handshake. +On the other hand, the periodic multicast may have resource usage impacts in the network. + # 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. From 2156e1f39b93145b4fa6f19d7f4665a9aecf8313 Mon Sep 17 00:00:00 2001 From: Geovane Fedrecheski Date: Tue, 15 Oct 2024 15:57:58 +0200 Subject: [PATCH 6/9] Small improvements on advertisement strategies --- draft-ietf-lake-authz.md | 57 ++++++++++++++++++++-------------------- 1 file changed, 28 insertions(+), 29 deletions(-) diff --git a/draft-ietf-lake-authz.md b/draft-ietf-lake-authz.md index cc8c4f6..5694c58 100644 --- a/draft-ietf-lake-authz.md +++ b/draft-ietf-lake-authz.md @@ -710,7 +710,7 @@ where When ELA is used for zero-touch enrollment, U normally has little to no knowledge of the available V's. This may lead to situations where U has to retry several times at different V's until it finds one that works. This section presents two optimization strategies for such cases. -They were developed to address scenarios where V's are radio gateways to which U wants to enroll. +They were developed to address scenarios where V's are radio gateways to which U wants to enroll, but may also be applicable to other use cases. ## U anycasts message_1 {#strat-anycast} @@ -720,22 +720,22 @@ When each of the V's in radio range of U receive message_1, one of the following - V does not implement EDHOC, and drops the message - V does not implement ELA, and since EAD_1 is critical, it either responds with an error or drops the message (preferred) - V forwards message_1 to W as VREQ, but W does not authorize it, and error handling is applied -- V forwards message_1 to W as VREQ, W authorizes it, and the protocol flows normally +- V forwards message_1 to W as VREQ, W authorizes it, and the protocol continues normally U is expected to receive at most one message_2 as response, which contains the Voucher. In case U receives additional message_2's, they MUST be silently dropped. This strategy may increase the number of messages that need to be processed by V and W, in exchange for reducing resource usage in U. -Security concerns related to this strategy, including potential reuse of G_X and double processing of message_2, are discussed in Section {{sec-cons}}. +Security concerns related to this strategy, including potential reuse of G_X and double processing of message_2, are discussed in {{sec-cons}}. ## V advertises support for ELA {#strat-advertise} -In this strategy, V shares some information (V_INFO) with a potential U, that can help it decide whether to try to enroll in that V. +In this strategy, V shares some information (V_INFO) with a potential U, that can help it decide whether to try to enroll with that V. For example, V may send a V_INFO stating that: - V implements ELA -- similarly to how EAPOL {{IEEE802.1X}} frames state support for IEEE 802.1X -- V is part of a certain domain -- similarly to how Eduroam {{RFC7593}} is used in the SSID field for IEEE 802.11 networks +- V is part of a certain domain -- similarly to how Eduroam {{RFC7593}} is used in the SSID field of IEEE 802.11 packets The mechanism used to transport V_INFO will depend on the underlying communication technology and also on application needs. @@ -753,8 +753,7 @@ Where: Details on how exatcly these fields are structured are left to the application. -Examples of how the advertisement strategy may be applied according to different application needs are presented in {{example-advert}}. - +{{example-advert}} presents three examples of how the advertisement strategy may be applied according to different application needs. # REST Interface at W {#rest_interface} @@ -948,28 +947,28 @@ The reverse flow can also be used when U implements a CoAP client, but acts as a 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 -+-------+--------+ +-------+--------+ +---------------+ -| Resp | Client | | Init | Server | | | -+-------+--------+ +----------------+ | W | -| U | | V | | | -+----------------+ +----------------+ +---------------+ - | | | - | CoAP request | | - +-------------------------->| | - | | | - | EDHOC message_1 | | - +<--------------------------| | - | | | - | EDHOC message_2 | | - +-------------------------->| | - | (EAD_2 = Voucher_Info) | | - | +------------------------->| - | | Voucher Request (VREQ) | - | |<-------------------------+ - | | Voucher Response (VRES) | - | EDHOC message_3 | | - +<--------------------------| | - | (EAD_3 = Voucher) | | ++-------+--------+ +-------+--------+ +| Resp | Client | | Init | Server | ++-------+--------+ +----------------+ +| U | | V | ++----------------+ +----------------+ + | | + | CoAP request | + +-------------------------->| + | | + | EDHOC message_1 | + +<--------------------------| + | | + | EDHOC message_2 | W + +-------------------------->| | + | (EAD_2 = Voucher_Info) | | + | +-------------->| + | | VREQ / VRES | + | |<------------->| + | | | + | EDHOC message_3 | | + +<--------------------------| + | (EAD_3 = Voucher) | ~~~~~~~~~~~ {: #fig-reverse title="ELA with EDHOC reverse mesasge flow when U is responder." artwork-align="center"} From dbc46a837be2f81127ced367b1cbc97ec45c9be5 Mon Sep 17 00:00:00 2001 From: Geovane Fedrecheski Date: Thu, 17 Oct 2024 10:53:43 +0200 Subject: [PATCH 7/9] Fix client/server sides in appendix --- draft-ietf-lake-authz.md | 9 ++++++--- 1 file changed, 6 insertions(+), 3 deletions(-) diff --git a/draft-ietf-lake-authz.md b/draft-ietf-lake-authz.md index 5694c58..554b0d7 100644 --- a/draft-ietf-lake-authz.md +++ b/draft-ietf-lake-authz.md @@ -944,7 +944,10 @@ One use case is to perform ELA over Bluetooth Low Energy, as discussed in {{I-D. ## U is the Responder {#reverse-u-resp} The reverse flow can also be used when U implements a CoAP client, but acts 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). +The main changes in this case are: + +- Instead of sending EDHOC message_1, U sends an initial trigger packet to V, e.g., a CoAP request, which then initiates the handshake by replying with an EDHOC message_1. +- The Voucher_Info and Voucher structs are sent over EAD_2 and EAD_3, respectively (instead of over EAD_1 and EAD_2). ~~~~~~~~~~~ aasvg +-------+--------+ +-------+--------+ @@ -1127,12 +1130,12 @@ When a suitable V receives the solicitation, if it implements ELA, it should res ~~~~~~~~~~~ aasvg +-------+--------+ +-------+--------+ -| Resp | Server | | Init | Client | +| Resp | Client | | Init | Server | +-------+--------+ +----------------+ | U | | V | +----------------+ +----------------+ | | - +- - - - - - - - - - - - - - - -->| + +-------------------------------->| | CoAP discovery/solicitation | | | | EDHOC message_1 | From 8f7244801a58121eb3499f53486c364afcdcc1bf Mon Sep 17 00:00:00 2001 From: Geovane Fedrecheski Date: Fri, 18 Oct 2024 11:23:29 +0200 Subject: [PATCH 8/9] Add note on EAD criticality for anycast optimization --- draft-ietf-lake-authz.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/draft-ietf-lake-authz.md b/draft-ietf-lake-authz.md index 554b0d7..7ddba83 100644 --- a/draft-ietf-lake-authz.md +++ b/draft-ietf-lake-authz.md @@ -718,7 +718,7 @@ This strategy consists in U disseminating EDHOC message_1 as anycast (a broadcas When each of the V's in radio range of U receive message_1, one of the following can happen: - V does not implement EDHOC, and drops the message -- V does not implement ELA, and since EAD_1 is critical, it either responds with an error or drops the message (preferred) +- V does not implement ELA, and since EAD_1 is critical, it either responds with an error or drops the message (Editor's note: dropping actually conflicts with the EAD field being critical) - V forwards message_1 to W as VREQ, but W does not authorize it, and error handling is applied - V forwards message_1 to W as VREQ, W authorizes it, and the protocol continues normally From e311b336c8b6b20ee89f5346c1f71c9f8189a049 Mon Sep 17 00:00:00 2001 From: Geovane Fedrecheski Date: Fri, 18 Oct 2024 13:54:46 +0200 Subject: [PATCH 9/9] Improve description of advertisement strategy --- draft-ietf-lake-authz.md | 38 ++++++++++++++++++-------------------- 1 file changed, 18 insertions(+), 20 deletions(-) diff --git a/draft-ietf-lake-authz.md b/draft-ietf-lake-authz.md index 7ddba83..adb9956 100644 --- a/draft-ietf-lake-authz.md +++ b/draft-ietf-lake-authz.md @@ -732,26 +732,24 @@ Security concerns related to this strategy, including potential reuse of G_X and ## V advertises support for ELA {#strat-advertise} In this strategy, V shares some information (V_INFO) with a potential U, that can help it decide whether to try to enroll with that V. -For example, V may send a V_INFO stating that: -- V implements ELA -- similarly to how EAPOL {{IEEE802.1X}} frames state support for IEEE 802.1X +The exact contents of the V_INFO structure, as well as the mechanism used to transport it, will depend on the underlying communication technology and also on application needs. +For example, V_INFO may state that: + +- V implements ELA -- similarly to how EAPOL {{IEEE802.1X}} frames state support for IEEE 802.1X. + - V is part of a certain domain -- similarly to how Eduroam {{RFC7593}} is used in the SSID field of IEEE 802.11 packets -The mechanism used to transport V_INFO will depend on the underlying communication technology and also on application needs. +V_INFO can be sent over a network beacon (see {{adv-beacon}}), which may require technology specific profiling, e.g., the IEEE 802.15.4 enhanced beacon may be extended according to {{RFC8137}}. +Alternatively, V_INFO can be sent as part of an EAD field, as shown in {{adv-ead1}}. -As a guideline for implementers, we define the following fields that can be included in a V_INFO structure: +As a guideline for implementers, we define the following field that can be included in a V_INFO structure: ~~~~~~~~~~~ cddl -ELA_ID: int DOMAIN_ID: bstr ~~~~~~~~~~~ -Where: - -- 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. +The DOMAIN_ID field identifies the domain to which V belongs to, for example an URL or UUID. {{example-advert}} presents three examples of how the advertisement strategy may be applied according to different application needs. @@ -1085,11 +1083,11 @@ This appendix presents three example strategies that can be used to advertise th It includes sending V_INFO in network beacons, as part of EAD_1 in reverse message flow, or as part of a periodic CoAP multicast packet. It also presents the advantages, costs, and security impacts of each strategy. -## V_INFO in network beacons +## V_INFO in network beacons {#adv-beacon} _PR editor's note: this is approach A1_ -This approach allows carrying V_INFO in beacons sent over the network layer, as shown in {{fig-adv-a1}}. +This approach allows carrying V_INFO in beacons sent over the network layer, as shown in {{fig-adv-beacon}}. It requires that the network layer offers a mechanism to configure its beacon packets. Depending on the network type, a solicitation packet may also be needed, as is the case of non-beaconed IEEE 802.15.4 and BLE with GATT. @@ -1113,7 +1111,7 @@ Depending on the network type, a solicitation packet may also be needed, as is t ( ... protocol continues normally ... ) ~~~~~~~~~~~ -{: #fig-adv-a1 title="Advertising ELA using V_INFO in network-layer beacons." artwork-align="center"} +{: #fig-adv-beacon title="Advertising ELA using V_INFO in network-layer beacons." artwork-align="center"} This strategy can be used, for example, in IEEE 802.15.4, where an Enhanced Beacon {{IEEE802.15.4}} can be used to transmit V_INFO. Specifically, a new information element for carrying V_INFO can be defined according to {{RFC8137}}. @@ -1121,7 +1119,7 @@ Specifically, a new information element for carrying V_INFO can be defined accor This approach has the advantage of requiring minimal changes to the default protocol as presented in {{protocol-overview}}, i.e., no reverse flow. It requires, however, some profiling of the lower layer beacons. -## V_INFO in EAD_1 +## V_INFO in EAD_1 {#adv-ead1} _PR editor's note: this is approach A2_ @@ -1145,7 +1143,7 @@ When a suitable V receives the solicitation, if it implements ELA, it should res ( ... reverse flow continues normally ... ) ~~~~~~~~~~~ -{: #fig-adv-a2 title="Advertising ELA using V_INFO in EAD_1, eploying the EDHOC reverse flow with U as responder." artwork-align="center"} +{: #fig-adv-ead1 title="Advertising ELA using V_INFO in EAD_1, eploying the EDHOC reverse flow with U as responder." 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: @@ -1161,11 +1159,11 @@ It also encrypts Voucher_Info (as part of EAD_2), wehereas it is sent in the cle In addition, it may not require layer-two profiling (in case the network allows transporting data before authorization). Finally, note that the reverse flow with U as Responder protects the identity of V (instead of U's as in the forward flow). -## V_INFO in a CoAP Multicast Packet +## V_INFO in a CoAP Multicast Packet {#adv-coap-mult} _PR editor's note: this is approach A3_ -In this approach, V periodically multicasts a CoAP packet containing V_INFO, see {{fig-adv-a3}}. +In this approach, V periodically multicasts a CoAP packet containing V_INFO, see {{fig-adv-coap-mult}}. Upon receiving one or more CoAP messages and processing V_INFO, U can decide whether or not to initiate the ELA protocol with a given V. Next, the application can either keep U acting as a server, and thus employ the EDHOC reverse flow, or implement a CoAP client and use the forward flow. @@ -1176,6 +1174,7 @@ Next, the application can either keep U acting as a server, and thus employ the | U | | V | +------------------+ +------------------+ | | + | POST /ela-advertisement | |<-----------------------------------------+ | CoAP multicast (contains V_INFO) | | | @@ -1186,14 +1185,13 @@ Next, the application can either keep U acting as a server, and thus employ the ( ... protocol continues normally ... ) ~~~~~~~~~~~ -{: #fig-adv-a3 title="Advertising ELA using the network layer." artwork-align="center"} +{: #fig-adv-coap-mult title="Advertising ELA using the network layer." artwork-align="center"} The V_INFO structure is sent as part of the CoAP payload. It is encoded as a CBOR sequence: ~~~ cddl V_INFO = ( - ELA_ID: int, ?DOMAIN_ID: bstr, ) ~~~