Code change:
3.8. <del> In order to reduce round trips and the number of messages or to </del> <ins> In order to reduce round trips and the number of messages, or to </ins> simplify processing, external security applications may be integrated into EDHOC by transporting authorization related data in the messages. <del> EDHOC allows opaque external authorization data (EAD) to be sent in each of the four EDHOC messages (EAD_1, EAD_2, EAD_3, EAD_4). </del> <ins> EDHOC allows processing of external authorization data (EAD) to be defined in a separate specification, and sent in dedicated fields of the four EDHOC messages (EAD_1, EAD_2, EAD_3, EAD_4).  EAD is opaque data to EDHOC. </ins> <del> External authorization data is a CBOR sequence (see CBOR) consisting of one or more (ead_label, ead_value) pairs as defined below: </del> <ins> Each EAD field is a CBOR sequence (see CBOR) consisting of one or more EAD items (ead_label, ead_value) as defined below: </ins> A security application using external authorization data need to <del> register an ead_label, specify the ead_value format for each message (see iana-ead), and describe processing and security considerations. </del> <ins> register a positive ead_label and the associated ead_value format for each EAD item it uses (see iana-ead), and describe processing and security considerations.  Each application registers their own EAD items and defines associated operations.  The application may define multiple uses of certain EAD items, e.g., the same EAD item may be used in different EDHOC messages with the same application. An EAD item can be either critical or non-critical, determined by the sign of the ead_label in the transported EAD item included in the EDHOC message.  Using the registered positive value indicates that the EAD item is non-critical.  The corresponding negative value indicates that the EAD item is critical. ead_label = 0 MUST NOT be used. If an endpoint receives a critical EAD item it does not recognize or a critical EAD item that contains information that it cannot process, the EDHOC protocol MUST be discontinued.  A non-critical EAD item can be ignored. The specification registring a new EAD label needs to describe under what conditions the EAD item is critical or non-critical. </ins> The EAD fields of EDHOC must not be used for generic application <del> data.  Examples of the use of EAD is provided in ead-appendix. </del> <ins> data.  Examples of the use of EAD are provided in ead-appendix. </ins> 3.9.

Related discussion:
text: For a practical example, a vulnerable service (say, anything civil rights related) might be operated at the same IP address as a more wide-spread service (say, a large public LwM2M provider). The civil rights service would publish its address together with the public key GE and its service name in DNS records similar to . A client contacting it would start an EDHOC exchange with the public address and encrypt the service name with GEX in the EAD1. The server would respond with credentials for the civil rights service, to which the client then may either present an anonymous (CCS) identity, or (now that it knows it's speaking to the right peer) its own CREDI / IDCREDI. If the CRED sizes are always the same, this exchange should be indistinguishable from an exchange done between an LwM2M client and the LwM2M backend when the client has chosen to send some more garbage bytes. (For application such as eighthalve's, it should be noted that there is probably no need for any further proof of identity inside the EAD1 plaintext: Possession of GE in combination with the suitable plaintext should suffice to open the present alternative server credentials, any secret whose possession is proven in the plaintext part would be exactly as secret as GE, as no attacker without E can obtain the plaintext.). To condense this all into a few actionable points: We should have a code point in eadlabel for "encrypted EAD" data. (We may not even have to specify how it works, that can be specified later or even be guided by the out-of-band information that needs to be present for all of this anyway). That code point either needs to be described explicitly as "MUST ignore if not supported / content not understood" for all of EDHOC from the start, or there needs to be general wording about which ead_labels are to be ignored if unprocessable. We should encourage initiators to send some random garbage there if they can afford it. (A LoRA device certainly can't, a 6lo device probably neigther, but a guard proxy establishing a connection probably can). This is not only to protect initiators that need it, but also to ensure that it is not being blocked, and that responders don't reveal whether they support it.
This has parallels to , which will take some work to pick out in detail.