Encoding of kid_context in OSCORE option conflicts in RFC8613

[mrdeep1]

Is the kid_context in the OSCORE option encoded as a bstr, or just simply data with a length?

https://datatracker.ietf.org/doc/html/rfc8613#appendix-C.6

… Common Context: … o ID Context: 0x37cbf3210017a2d3 (8 bytes) … The following COSE and cryptographic parameters are derived: … o kid context: 0x37cbf3210017a2d3 (8 bytes) … From the previous parameter, the following is derived: o OSCORE option value: 0x19140837cbf3210017a2d3 (11 bytes)

which breaks down to 19 14 08 37cbf3210017a2d3 (“h k partial_iv_len 1” pIV 0x14 kid_context_len 8 kid_context 0x37cbf3210017a2d3)

yet, if kid_context was encoded as a bstr, it would be 19 14 09 4837cbf3210017a2d3

---

https://datatracker.ietf.org/doc/html/rfc8613#section-6.3 is ambiguous in

3. Request with ciphertext = 0xaea0155667924dff8a24e4cb35b9, kid = empty string, Partial IV = 0x05, and kid context = 0x44616c656b

Where it does imply that kid_context is a bstr.

---

https://datatracker.ietf.org/doc/html/rfc8613#appendix-B.2 has

1. (Optional) If the client does not have a valid security context with the server, e.g., because of reboot or because this is the first time it contacts the server, then it generates a random string R1 and uses this as ID Context together with the input parameters shared with the server to derive a first security context. The client sends an OSCORE request to the server protected with the first security context, containing R1 wrapped in a CBOR bstr as 'kid context'. The request may target a special resource used for updating security contexts.

Where R1 (kid_context) definitely has to be wrapped as a bstr – conflicting with test Appendix C.6.

---

However, kid_context is definately encoded as a bstr when setting up the info for deriving Sender Key, Recipient Key and Common IV.

Is it just RFC 8613 Appendix C.6 that is broken?

[rikard-sics]

My understanding is that on the wire the kid_context is always just a sequence of bytes (not CBOR encoded), except for in Appendix B.2 where it is in fact a CBOR byte string.

It is true that 0x44616c656b decodes as a valid CBOR byte string, but I don't think the intent is for it to be a CBOR byte string. The plain ASCII value is "Dalek", while as a CBOR byte string it becomes h'616C656B' which is "alek".

EDIT: Add tag @gselander

[mrdeep1]

I really do not like the concept of ID Context being encoded in the OSCORE option as a sequence of bytes or CBOR encoded depending on whether Appendix B.2 is in use or not.

How does the B.2 capable server determine that a client is trying to invoke B.2 or not with a kid context of 0x44616c656b?

Separately, https://datatracker.ietf.org/doc/html/draft-ietf-core-oscore-groupcomm-14#section-5.1.1 has

   *  Request with ciphertext = 0xaea0155667924dff8a24e4cb35b9, kid =
      0x25, Partial IV = 5 and kid context = 0x44616c.

so here the kid context is definately not CBOR wrapped, helping confirm https://datatracker.ietf.org/doc/html/rfc8613#section-6.3 kid context of 0x44616c656b is not intended to be a CBOR wrap.

[mrdeep1]

Have I misunderstood

https://datatracker.ietf.org/doc/html/rfc8613#appendix-B.2 has

(Optional) If the client does not have a valid security context with the server, e.g., because of reboot or because this is the first time it contacts the server, then it generates a random string R1 and uses this as ID Context together with the input parameters shared with the server to derive a first security context. The client sends an OSCORE request to the server protected with the first security context, containing R1 wrapped in a CBOR bstr as 'kid context'. The request may target a special resource used for updating security contexts.

In that it states the request is protectedwith the first security context, containing R1 wrapped in a CBOR str. However, the OSCORE option is unprotected, so there is a disconnect here. Or is it trying to say the aadthat is used for deriving the Sender Key has R1 (as the ID Context) wrapped in a CBOR str?

[rikard-sics]

How does the B.2 capable server determine that a client is trying to invoke B.2 or not with a kid context of 0x44616c656b?

The approximate steps I follow in the OSCORE Java code in Californium:

1. Check if the KID and KID Context in the incoming request matches a context on the server.
   • If so unprotect the request as normal with that context, no Appendix B.2 involved.
   • (The KID Context may also be not included in the request, if so find a matching context based on KID. No Appendix B.2 for sure since the KID Context is empty.)
2. If no context matched in 1. look for a context with matching KID
   • If none is found abort the message processing.
3. If a context is found in 2. check if the KID Context of the request is a valid CBOR byte string
   • If it is not, abort the processing.
4. Generate a new OSCORE security context with parameters from the context in 2. but with the KID Context in the request unwrapped from its CBOR byte string.
5. Attempt to unprotect the request with this new context
   • If this works continue the Appendix B.2 procedure by preparing and sending Response 1.
   • If the unprotection fails abort the message processing.

[mrdeep1]

1. Check if the KID and KID Context in the incoming request matches a context on the server. o If so unprotect the request as normal with that context, no Appendix B.2 involved.

So, with a KID Context of 0x44616c656b, we can match a ID Context of 0x44616c656b at this point

3. If a context is found in 2. check if the KID Context of the request is a valid CBOR byte string o If it is not, abort the processing.
4. Generate a new OSCORE security context with parameters from the context in 2. but with the KID Context in the request unwrapped from its CBOR byte string.

Now we can match on a ID context of 0x616c656b to continue decrypting.

In other words, there is the potental to match on 2 different ID Contexts for a single request. Not convinced that is a good idea.

[mrdeep1]

For the client, it has to decide/be told whether it is trying B.2 or not - which affects how the KID Context is formatted in the OSCORE option if R1 etc. have to be wrapped as a CBOR Byte string.

Given that the OSCORE option is supposed to be compressed, adding in the CBOR wrapping overhead of one or more bytes to me does not follow the spirit of the compression.

[rikard-sics]

So, with a KID Context of 0x44616c656b, we can match a ID Context of 0x44616c656b at this point

Now we can match on a ID context of 0x616c656b to continue decrypting.

In other words, there is the potental to match on 2 different ID Contexts for a single request. Not convinced that is a good idea.

Practically in my code that can never happen as if a context with matching KID and KID Context is found initially it never progresses beyond point 1 or even considers Appendix B.2.

Also there is no second matching after the CBOR unwrapping of the KID Context, just generation of a brand new OSCORE security context with that ID Context.

[rikard-sics]

I just wanted to mention here that we are currently working on a draft to define a procedure that is intended to obsolete the current OSCORE Appendix B.2. The draft related to it can be found here: Key Update for OSCORE (KUDOS)

Comments and feedback on the design of this new procedure is very welcome.