[Lake] Re: Advertising lake-authz support

[Geovane Fedrecheski <[e-mail]>]

Hi all,

Here are some relevant updates after my presentation at the IETF 120 LAKE session. Towards the end of this email I pose a question to the working group.

Recap: we discussed Approaches A1 and A2 in the meeting (for details see this page <https://notes.inria.fr/s/diU-pf1Er#advertising-lake-authz-support> or the preceding email).

After the presentation,

Marco Tiloca proposed a new advertisement approach that protects the identity of U at the cost of sending periodic multicasts (see Approach A3 <https://notes.inria.fr/s/diU-pf1Er#approach-a3-coap-advertisement-marco%E2%80%99s-proposal>)
Christian Amsüss (re-)proposed yet another option, that eliminates need for advertisement but involves broadcasting EDHOC message_1 (see Approach A4 <https://notes.inria.fr/s/diU-pf1Er#approach-a4-no-advertisement-just-broadcast-message_1-christian%E2%80%99s-proposal>)
So far we agree that A3 is fine.

I am now interested in whether we could also adopt/recommend approach A4, mainly because it is more economic in terms of messages sent.

The question is: could we use Approach A4, or does it lead to unavoidable security concerns?
Here is a summary of points raised and potential responses:

re-use of G_X: it has been pointed as a security issue <https://github.com/lake-wg/authz/pull/36#issuecomment-2098403419>. This can be overcome by the criticality field of lake-authz’s EAD1 and specific rules on W processing (see [Approach 4] linked above).
double processing of message_2: it has been argued that EDHOC clients might receive and process message_2 more than once. On the other hand, correct implementations should maintain a state machine and avoid processing messages in unexpected states (note: maybe this point could be added as an implementation consideration in Marco’s draft).
What is the opinion of the working group on this topic? 

If you have questions or need clarifications, please let me know.

Best regards,
Geovane.




> On 18 Jul 2024, at 18:27, Geovane Fedrecheski <[e-mail]> wrote:
> 
> 
> Hi all,
> 
> This is to share a proposal sketch for the lake-authz draft <https://datatracker.ietf.org/doc/draft-ietf-lake-authz/>, which I will also be presenting during my slot at the IETF 120.
> Looking forward to hearing feedback from the working group, here in the mailing list or during the event next week.
> 
>  <https://notes.inria.fr/BtcQjtZCRf-FIv84xPes_w?both#proposal-advertising-lake-authz-support>Proposal: Advertising lake-authz support
> 
> One issue with the current state of the protocol is that the device may have to attempt enrollment several times until it finds a suitable V.
> We previously tried to address this by using enrollment hints <https://www.ietf.org/archive/id/draft-ietf-lake-authz-01.html#name-enrollment-hints>, but the approach had privacy issues <https://github.com/lake-wg/authz/issues/27> and would lead to larger message sizes <https://github.com/lake-wg/authz/pull/29/files>.
> 
> So now we turned to the possibility of using optional advertisement information that could be sent by V to inform U about lake-authz support.
> This could solve the performance/scalability issue as devices are more well-informed to make enrollment attempts.
> Furthermore, it minimizes the amount of additional information exchanged, resulting in better privacy and smaller message footprints.
> 
> We found that advertisement in lake-authz could be implemented in two levels:
> advertising protocol support, where V lets U know that it supports lake-authz. This is analogous to the EAPOL/IEEE 802.1X flag present in Wi-Fi beacons.
> advertising instance/system/domain support, where V lets U know that it is part of a given deployment. This is analogous to the “eduroam” SSID used in RFC 7593 <https://datatracker.ietf.org/doc/html/rfc7593>. Note that by advertising system/domain support, protocol support may also be inferred, since only V’s that do implement lake-authz will send a system/domain identifier.
> We discussed several possibilities <https://github.com/lake-wg/authz/pull/36> and, during design meetings, narrowed them down to two approaches that we found promising.
> In both approaches, we assume that V has some information (let’s call it V_INFO) that, if shared with U, could help U to decide whether or not to attempt enrollment.
> V_INFO could be a URI that identifies the system/domain to which V belongs, e.g., mydeploy.com.
> 
> For example, consider one device (U) which has two domain authenticators (V1 and V2) in its radio range:
> U is part of the system acme.com
> V1 is part of the system acme.com, and V2 is part of wayne.com
> prior to sending Voucher_Info, U discovers the available Vs and their respective V_INFO’s, which contain their system’s names
> U decides to send the request with Voucher_Info to V1, since it has a matching system name
> This allows U to select suitable V’s early on, and has similar data sharing properties as those found in EAP and Wi-Fi.
> 
> We designed two possible approaches on how to have U obtain V_INFO.
>  <https://notes.inria.fr/BtcQjtZCRf-FIv84xPes_w?both#approach-a1-l2-beacons-and-edhoc-forward-flow>Approach A1: L2 beacons and EDHOC forward flow
> 
> Approach A1, shown in Figure 1 below, is characterized by:
> use of L2 beacons to carry V_INFO
> this assumes that L2 is extensible at the beacon level. (this includes: IEEE 802.15.4, raw BLE.)
> depending on the L2, a solicitation packet MAY need to be sent to trigger the beacon. (this is the case in: non-beaconed IEEE 802.15.4, BLE with GATT; the trigger is not needed in: TSCH)
> execution of the EDHOC forward message flow
> U acts as EDHOC Initiator and CoAP Client, and V as Responder and Server
> this is just like the current state of the draft, with the addition of a prior discovery phase
> the CoJP appendix already considers an optional discovery phase; the difference here is the addition of V_INFO
> ┌──────┬──────┐              ┌──────┬──────┐        
> │ Init │Client│              │ Resp │Server│        
> ├──────┴──────┤              ├──────┴──────┤        
> │      U      │              │      V      │        
> └──────┬──────┘              └──────┬──────┘        
>        │                            │               
>        │                            │               
>        ├--------------------------->|               
>        │  L2 discovery/solicitation │               
>        │                            │               
>        │            V_INFO          │               
>        |<───────────────────────────┤               
>        │   L2 beacon/advertisement  │               
>        │                            │               
>        │                            │               
>        │  msg_1  EAD1=Voucher_Info  │               
>        ├───────────────────────────>|               
>        │                            │ Talk to W and get Voucher...
>        │   msg_2  EAD2=Voucher      │               
>        |<───────────────────────────┤               
>        │                            │               
>        │      msg_3                 │               
>        ├───────────────────────────>|               
>        │                            │               
> Figure 1. U obtains V_INFO from a beacon sent by V. U may need to first send a solicitation message to trigger the beacon.
>  <https://notes.inria.fr/BtcQjtZCRf-FIv84xPes_w?both#approach-a2-coap-anycastresponse-and-edhoc-reverse-flow>Approach A2: CoAP anycast/response and EDHOC reverse flow
> 
> Approach A2, shown in Figure 2, is characterized by:
> use of CoAP to carry V_INFO, as part of an anycast/response exchange
> one assumption here is that L2 allows transporting such packets before enrollment takes place. I think this can work in: BLE with GATT (TODO: and which others?).
> note that V’s that do not support lake-authz will simply drop the anycast request, which serves as a protocol support filter: U will only receive responses from lake-authz -enabled gateways.
> execution of the EDHOC reverse message flow (Appendix A.2.2. of RFC 9528)
> U is the EDHOC Responder, and V is the Initiator (Cliend and Server roles are the same as in A1)
> this allows carrying msg_1 in the CoAP response
> V_INFO is sent in EAD1
> as a consequence, Voucher_Info is carried in EAD2 and Voucher in EAD3
> ┌──────┬──────┐              ┌──────┬──────┐        
> │ Resp │Client│              │ Init │Server│        
> ├──────┴──────┤              ├──────┴──────┤        
> │      U      │              │      V      │        
> └──────┬──────┘              └──────┬──────┘        
>        │                            │               
>        │                            │               
>        ├───────────────────────────>|               
>        │ CoAP discovery/solicit.    │               
>        │         (anycast)          │               
>        │                            │               
>        │                            │               
>        │     msg_1  EAD1=V_INFO     │               
>        |<───────────────────────────┤               
>        │       CoAP response        │               
>        │                            │               
>        │ msg_2  EAD2=Voucher_Info   │               
>        ├───────────────────────────>│               
>        │                            │ Talk to W and get Voucher...
>        │    msg_3  EAD3=Voucher     │               
>        │<───────────────────────────┤               
>        │                            │               
> Figure 2. U obtains V_INFO from a CoAP response sent by V. U needs to first send an anycast message that acts as a V_INFO solicitation. Since V_INFO is carried in EDHOC msg_1, the EDHOC roles are reversed. Voucher_Info and Voucher are carried in subsequent messages.
> Discussion and impacts
> 
> L2 profiling:
> A1: requires updates in beacons to carry V_INFO, one profile per L2 technology
> A2: may or may not require L2 profiling, as CoAP messages can be just sent as payloads (depends if the L2 allows transporting data before authorization). All the remaining signaling can be expressed in terms of CoAP messages.
> A1 is very similar to the current state of the protocol, so the change to the draft is small
> A2 has the benefit of using a single packet to transfer both EDHOC msg_1 and V_INFO
> A2 uses the EDHOC reverse flow
> is it as commonly deployed as the forward flow? what is the impact on available implementations?
> stronger identity protection for V than for U (RFC 9528)
> A2 offers better protection for some fields:
> Voucher_Info: sent in the clear in A1, but confidentiality-protected in A2
> Voucher: confidentiality-protected in A1, but confidentiality and integrity -protected in A2
> Which version should we use? A1 or A2? Or should we keep both? Maybe one of them in the appendix?
> Any other comment?
> 
> 
> Regards,
> Geovane Fedrecheski
> Research Engineer at Inria Paris.
>