suggestions for text

[petervanderstok]

A bit late in the process, but triggered by implemenatation experience.

At the end of section 3.1: For clarification, consider a client and server equipped with identical common- sender- and recipient- contexts. The client encrypts the request payload with the key from the sender context using the contents of the sender context. On reception of the request, the server decrypts the request payload with the key from the sender context using the contents of the sender context. The server encrypts the response payload with the key from the recipient context using the contents of the sender context. On reception of the response, the dlient decrypts the response payload with the key from the recipient context using the contents of the sender context.

At the end of section 6.1: In a response message without observe, the value of the coap option can be only one byte with all bits set to zero.

[rikard-sics]

Regarding your second point. For a response with no partial IV, no KID and no KID context (which should be the most common case except for observe) the flag byte will end up with all bits set to 0.

In this case since the OSCORE option would become 1 byte with value 0x00 the option should in fact be of length 0 and be an empty option. See the following: https://tools.ietf.org/html/draft-ietf-core-object-security-16#section-2

If the OSCORE flag bits are all zero (0x00) the Option value SHALL be empty (Option Length = 0).

See also these sections for examples: https://tools.ietf.org/html/draft-ietf-core-object-security-16#appendix-C.7 https://tools.ietf.org/html/draft-ietf-core-object-security-16#page-33

[petervanderstok]

Then possibly: In a response message without observe, the value of the coap option can be empty.

[fpalombini]

Hi Peter, thank you for the feedback.

The client encrypts the request payload with the key from the sender context using the contents of the sender context.

That is right, with a little imprecision, as it is not the request (CoAP) payload that is encrypted but the payload + other data defined in section 4.

On reception of the request, the server decrypts the request payload with the key from the sender context using the contents of the sender context.

That is not correct. The server decrypts the request using its own recipient context (which mirrors the values of the client's sender context). In particular, it uses its recipient key, and some data extracted from the message itself (such as the AEAD nonce, constructed from the Partial IV received in the message + recipient and common context).

The server encrypts the response payload with the key from the recipient context using the contents of the sender context.

This is also not correct. The server encrypts the response using its own sender context (in particular its sender key), + some data extracted from the request (AEAD nonce, if nonce reuse) or constructed from the sender and common context (AEAD nonce, if no nonce reuse, such as in observe)

On reception of the response, the dlient decrypts the response payload with the key from the recipient context using the contents of the sender context.

Yes, the client uses the key from the recipient context, but the rest of the contents are not from the sender context (the sequence number should now be increased), but rather content cached from the request (if nonce reuse) or received in the message (no nonce reuse).

The point is that the client and server should in fact use the sender context to send, and recipient context to receive, and the AEAD nonce is in fact the "odd ball", which is either computed new from sender + common context (client processing of request and optionally server processing of response (e.g. if observe)), or retrieved from the message (sender processing of request and optionally client processing of response (e.g. if observe)) or retrieved from cache (client processing of response). We thought it would be complicated to be this precise about the nonce this early in the draft, and left to section 8. to clearly point out all the processing rules (based on request / response, observe / no observe). Do you think we need to clarify how the nonce is used in Section 3.1? Could we improve the text in a more general way? (In particular, we try to explain that without going into details about the nonce in Fig 4 and previous text).

[fpalombini]

About the second comment, we can definitely repeat that at the end of section 6.1. Thanks!

[petervanderstok]

This misunderstanding comes from the interpretation of mirroring. In my implementation I use only one context, and you seem to suggest that two contexts are needed per endpoint; where the mirroring happens at the endpoint.

For my approach with only one context, client and server make more sense than recipient and sender. Earlier I suggested to describe two abstraction levels: (1) sender-receiver and (2) client and server. And explain how client and sender have to handle the sender-recipient contexts. Otherwise misunderstandings remain for fresh readers.

fpalombini schreef op 2019-03-27 05:09:

Hi Peter, thank you for the feedback.

The client encrypts the request payload with the key from the sender context using the contents of the sender context.

That is right, with a little imprecision, as it is not the request (CoAP) payload that is encrypted but the payload + other data defined in section 4.

On reception of the request, the server decrypts the request payload with the key from the sender context using the contents of the sender context.

[rikard-sics]

This misunderstanding comes from the interpretation of mirroring. In my implementation I use only one context, and you seem to suggest that two contexts are needed per endpoint; where the mirroring happens at the endpoint.

In the Java implementation the application will have one security context associated to a particular other host to communicate with. The security context is composed of a sender context, recipient context and common context.

For two entities A & B that are communicating with each other the common context will be the same. The recipient context for A will match the sender context for B. Likewise the sender context for A will match the recipient context for B. I think this section shows it well: https://tools.ietf.org/html/draft-ietf-core-object-security-16#section-3.1

When transmitting a request the application looks up which security context to use from the URI of the target resource. It then uses the sender context information to secure this outgoing request. When receiving responses it can identify which context to use from the saved information like the token of the original outgoing request. It then uses the recipient context to decrypt and parse the incoming response.

For handling incoming requests it can look up which security context to use from the KID included in the OSCORE option of the request. It then uses the recipient context to handle the incoming request. For outgoing responses it will use the same security context as the request used and use the sender context to secure the outgoing response.

So in essence there are 4 cases: Incoming request, incoming response, outgoing request and outgoing response. The first 2 will use the recipient context of the security context and the last 2 will use the sender context of the security context.

[petervanderstok]

Hi Rikard,

thanks for the answer. "So in essence there are 4 cases: Incoming request, incoming response, outgoing request and outgoing response. The first 2 will use the recipient context of the security context and the last 2 will use the sender context of the security context."

If I understand correctly: For incoming request and outgoing response the recipient of the incoming request is equal to the sender of the outgoing response

In other words: given a client and a server. for incoming request: the recipient context describes the server; For outgoing response the sender context describes the server. Putting them in one context in the server results in a sender context and a recipient context both describing the server. Conclusion you need two contexts for the mirroring. Where do I make the mistake. BTW. One context works perfectly for me, it is just that the description in oscore draft has multiple interpretations. Rikard Höglund schreef op 2019-04-01 05:08:

This misunderstanding comes from the interpretation of mirroring. In my implementation I use only one context, and you seem to suggest that two contexts are needed per endpoint; where the mirroring happens at the endpoint.

In the Java implementation the application will have one security context associated to a particular other host to communicate with. The security context is composed of a sender context, recipient context and common context.

For two entities A & B that are communicating with each other the common context will be the same. The recipient context for A will match the sender context for B. Likewise the sender context for A will match the recipient context for B. I think this section shows it well: https://tools.ietf.org/html/draft-ietf-core-object-security-16#section-3.1

When transmitting a request the application looks up which security context to use from the URI of the target resource. It then uses the sender context information to secure this outgoing request. When receiving responses it can identify which context to use from the saved information like the token of the original outgoing request. It then uses the recipient context to decrypt and parse the incoming response.

For handling incoming requests it can look up which security context to use from the KID included in the OSCORE option of the request. It then uses the recipient context to handle the incoming request. For outgoing responses it will use the same security context as the request used and use the sender context to secure the outgoing response.

So in essence there are 4 cases: Incoming request, incoming response, outgoing request and outgoing response. The first 2 will use the recipient context of the security context and the last 2 will use the sender context of the security context.

-- You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub [1], or mute the thread [2].

Links:

[1] https://github.com/core-wg/oscoap/issues/257#issuecomment-478552720 [2] https://github.com/notifications/unsubscribe-auth/AMWTQTADQ3nbx9MtSxdGt1sqhQQU9zHuks5vcfazgaJpZM4cKxYT

[rikard-sics]

In other words: given a client and a server. for incoming request: the recipient context describes the server; For outgoing response the sender context describes the server.

For an incoming request to the server, the sending client will use its sender context to secure the request. The server will then use the recipient context to decrypt the incoming request.

For an outgoing response from the server, the server uses its sender context to secure it. The sender context of the server is equivalent to the recipient context of the client. So the client will use the recipient context to decrypt the incoming response.

Putting them in one context in the server results in a sender context and a recipient context both describing the server. Conclusion you need two contexts for the mirroring.

For a server it can have 1 security context consisting of a sender context, recipient context and common context. This security context will be associated with communication with a certain other host (like the client). (So it should have 1 security context per host it wants to communicate with.)

For the client in turn it can have 1 security context and this security context will be associated with communication with the server.

The client and server do have different security contexts in the sense that the recipient and sender contexts inside are mirrored. So the sender context of the client will match the recipient context of the server. The recipient context of the client will match the sender context of the server.

[gselander]

I noted some errors in Rikard's text: "For an outgoing response from the client, the client uses its sender context to secure it. The sender context of the client is equivalent to the recipient context of the server. So the server will use the recipient context to decrypt the incoming response."

Since this is about the response, "client" and "server" should be interchanged:

"For an outgoing response from the server, the server uses its sender context to secure it. The sender context of the server is equivalent to the recipient context of the client. So the client will use the recipient context to decrypt the incoming response."

@petervanderstok: Please let us know if this is still not clear.

[fpalombini]

What Rikard said is correct, and maybe the misunderstanding is that the full "Security Context" is composed of several parts, and that 2 of these parts are mirrored (Sender / Recipient).

I think the clearest way to explain how the Sender and Recipient contexts are used is really in Section 3.1 and following figure 4 (reported below).

          .-----------------------------------------------.
          |                Common Context                 |
          +---------------------.---.---------------------+        
          |    Sender Context   | = |  Recipient Context  |
          +---------------------+   +---------------------+ 
          |  Recipient Context  | = |    Sender Context   |
          '---------------------'   '---------------------'
                   Client                   Server
                      |                       |
Retrieve context for  | OSCORE request:       |
 target resource      |   Token = Token1,     |
Protect request with  |   kid = SID, ...      |
  Sender Context      +---------------------->| Retrieve context with
                      |                       |  RID = kid
                      |                       | Verify request with
                      |                       |  Recipient Context
                      | OSCORE response:      | Protect response with
                      |   Token = Token1, ... |  Sender Context
Retrieve context with |<----------------------+
 Token = Token1       |                       |
Verify request with   |                       |
 Recipient Context    |                       |

Let us know what is missing or unclear, if we need to fix anything!

[rikard-sics]

I noted some errors in Rikard's text: "For an outgoing response from the client, the client uses its sender context to secure it. The sender context of the client is equivalent to the recipient context of the server. So the server will use the recipient context to decrypt the incoming response."

Since this is about the response, "client" and "server" should be interchanged:

Yes, sorry. The client should not be sending a response. I have changed my post according to your suggestion.

[petervanderstok]

What is not clear if the common context with the 2 sender and and 2 recipient contexts are stored in both the server and the client. leading to two sender contexts and 2 recipient contexts in both client and server.

Wanting to reduce this unnecessary number of recipient and sender contexts, I suggest to separate the common contexts in two parts: one in client and one in server, with an equal sign in between.

From then on it is probably better to talk about client-xxx-context and server-xxx-context where xxx is either sender of recipient.

Given a clarification on the choices above, I am happy to suggest modifications for:

Verify request with | | Recipient Context | | Protect response with | | Sender Context The word "protect" is ambiguous because it uses the key of one context and the nonce of the other

Thanks for correcting me.

Peter fpalombini schreef op 2019-04-04 06:09:

What Rikard said is correct, and maybe the misunderstanding is that the full "Security Context" is composed of several parts, and that 2 of these parts are mirrored (Sender / Recipient).

I think the clearest way to explain how the Sender and Recipient contexts are used is really in Section 3.1 and following figure 4 (reported below).

.-----------------------------------------------.	Common Context	+---------------------.---.---------------------+	Sender Context	=	Recipient Context	+---------------------+ +---------------------+	Recipient Context	=	Sender Context	'---------------------' '---------------------' Client Server
Retrieve context for	OSCORE request:
target resource	Token = Token1,
Protect request with	kid = SID, ...
Sender Context +---------------------->	Retrieve context with
	RID = kid
	Verify request with
	Recipient Context
OSCORE response:	Protect response with
Token = Token1, ...	Sender Context
Retrieve context with	<----------------------+
Token = Token1
Verify request with
Recipient Context

Let us know what is missing or unclear, if we need to fix anything!

-- You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub [1], or mute the thread [2].

Links:

[1] https://github.com/core-wg/oscoap/issues/257#issuecomment-479890099 [2] https://github.com/notifications/unsubscribe-auth/AMWTQe6663glxIN-43tIlgV5tL6Ybm1Xks5vdfmagaJpZM4cKxYT

[gselander]

Each endpoint only needs to store one Sender Context and (in unicast OSCORE) one Recipient Context. Therefore "Sender Context" etc. is well defined as long as it is qualified what is the endpoint and in what role (client or server). For this reason I don't think we need to use "client-xxx-context" etc. If there is some text in the specification which mentions "Sender Context" or "Recipient Context" without this qualifying information we should fix that.

However, as you emphasize, in the default case the response is protected with the nonce of the request, which strictly speaking is not part of the Recipient Context, but is available via the Partial IV of the request so does not have to be stored. Was this the reason for the confusion?

I agree that in the figure we could split the box with Common Context in two and put an equality sign between.

[petervanderstok]

Hi

just a small addition to the confusion. In draft ietf-ace-oscore-profile section 3.2 figure 4: the terms clientid and serverid, and NOT senderid and recipientid are used.

It would be nice if terminology was aligned. I maintain that the text in oscore and oscore-group about sender and recipient contexts is confusing. Even goran made a mistake.

Cheerio.

peter fpalombini schreef op 2019-04-04 06:09:

What Rikard said is correct, and maybe the misunderstanding is that the full "Security Context" is composed of several parts, and that 2 of these parts are mirrored (Sender / Recipient).

I think the clearest way to explain how the Sender and Recipient contexts are used is really in Section 3.1 and following figure 4 (reported below).

.-----------------------------------------------.	Common Context	+---------------------.---.---------------------+	Sender Context	=	Recipient Context	+---------------------+ +---------------------+	Recipient Context	=	Sender Context	'---------------------' '---------------------' Client Server
Retrieve context for	OSCORE request:
target resource	Token = Token1,
Protect request with	kid = SID, ...
Sender Context +---------------------->	Retrieve context with
	RID = kid
	Verify request with
	Recipient Context
OSCORE response:	Protect response with
Token = Token1, ...	Sender Context
Retrieve context with	<----------------------+
Token = Token1
Verify request with
Recipient Context

Let us know what is missing or unclear, if we need to fix anything!

-- You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub [1], or mute the thread [2].

Links:

[1] https://github.com/core-wg/oscoap/issues/257#issuecomment-479890099 [2] https://github.com/notifications/unsubscribe-auth/AMWTQe6663glxIN-43tIlgV5tL6Ybm1Xks5vdfmagaJpZM4cKxYT