Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Encoding of kid_context in OSCORE option conflicts in RFC8613 #22

Open
mrdeep1 opened this issue Apr 13, 2022 · 8 comments
Open

Encoding of kid_context in OSCORE option conflicts in RFC8613 #22

mrdeep1 opened this issue Apr 13, 2022 · 8 comments

Comments

@mrdeep1
Copy link

mrdeep1 commented Apr 13, 2022

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
Copy link
Member

rikard-sics commented Apr 13, 2022

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
Copy link
Author

mrdeep1 commented Apr 13, 2022

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
Copy link
Author

mrdeep1 commented Apr 13, 2022

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 protected with 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 aad that is used for deriving the Sender Key has R1 (as the ID Context) wrapped in a CBOR str?

@rikard-sics
Copy link
Member

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
Copy link
Author

mrdeep1 commented Apr 14, 2022

  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

  1. 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.
  2. 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
Copy link
Author

mrdeep1 commented Apr 14, 2022

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
Copy link
Member

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
Copy link
Member

rikard-sics commented May 5, 2022

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.

@cabo cabo transferred this issue from core-wg/corrclar-old Jul 22, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants