Consider using encrypted CWT access tokens

[jimsch]

Consider case where rather than sending an encrypted CWT access token rather than a shared secret identifier. (Maybe also for the asymmetric key identifier? I have not thought this case through.)

[fpalombini]

We think the application could define this over the top.

[jimsch]

It could, however thinking this through means that there are things that do not need to be sent as part of the protocol because they are in the access token. For example, there may not be a key id for the symmetric case as it is implicit from the access token being sent. In this case it needs to be encoded into the protocol itself as oppose to the case of sending the access token which has a key id and that key id is duplicated. It may be much more efficient to omit fields that are duplicated in the token

[fpalombini]

Yes, that's right, but we think the application that defines how to use the encrypted CWT with EDHOC should do this type of considerations for efficiency, and not EDHOC itself.

I'll close this unless objection.

[jimsch]

As long as you do not believe that the application should change the fields of EDHOC and the way that key derivation is done, I have no objections

[emanjon]

I think that even if no changes are made to EDHOC, the EDHOC document should say at least something about the possiblity to use a token and shortly describe how. Right now there is no information whatsoever.

[emanjon]

The next version now says

"EDHOC allows opaque application data (UAD and PAD) to be sent in the EDHOC messages. Unprotected Application Data (UAD_1, UAD_2) may be sent in message_1 and message_2 and can be e.g. be used to transfer authorization tokens that are protected outside of EDHOC. Protected application data (PAD_3) may be used to transfer any application data in message_3."

The text should probably say something about omitting KID, and the COSE_Sign1 protected headers when the respective token only contains a single credential. This would be similar to the situation with C_U that can be omitted if CoAP is used.

[emanjon]

The draft should say a little bit more about how to use UAD_1 / UAD_2 / UAD_3 to transfer access tokens.

Are access tokens with several keys inside them an import use case that we want to support in EDHOC? Otherwise KID and UAD_1 could potentialy be merged.

[emanjon]

@jimsch How would you send an access token in COSE? Shouldn't there be header parameters defined similar to the header parameters for X.509? i..e, like x5bag, x5chain, x5t, x5u

[emanjon]

The asymmetric and symmetric versions are a bit different when it comes to identifying the credential...

The symmetric version always sends a bstr ('kid') and the asymmetric always sends a map.

"KID may optionally contain information about how to retrieve the PSK" does not feel optimal as it means that Party V needs to now beoforehand if the bstr in KID contains any deeper structure.

I suggest the following:

• Rename KID to ID_CRED or ID_PSK
• Define them all (ID_CRED_U, ID_CRED_V, and ID_CRED) as a map { abc : xyz }
• Define that when the label 'abc' is 'kid' only the bstr is send, i.e what is sent on the wire is bstr / { abc : xyz }.
• I think this have three benefits: It would harmonize asymmetrical and symmetrical, save a total of 4 bytes for RPK, and enable future COSE extensions where the PSK is identified in some more complex way.