Re: [Ace] Review of draft-ietf-ace-oscore-profile

[John Mattsson <[e-mail]>]

Hi,

Additional comments on the draft. Some of these require technical changes. 

-------------------------
 
- "(as opposed to, e.g., a counter, that might leak some information about the client)"
 
Using counters for N1 and N2 is not secure with the current Master Salt construction as an attacker can trick the client to do a two-time pad.

-> "1"
<- "11"

and

-> "11"
<- "1"

To mitigate these kind of attacks the master salt need to include lengths, e.g. by using a CBOR array. I commented before that I found the master salt construction for JSON is unclear. I think the same apply for CBOR. Assuming the client used the random nonce 0x36f6

In case of CBOR, is the master salt then constructed with the value or the CBOR encoding?

0x36f6 or 0x4236f6

And in case of JSON, is the master salt then constructed with the binary value, the base64 encoding, or the JSON value sent on the wire?

0x36f6, or 0x4e76593d (NvY=), or 0x224e76593d22 ("NvY=")

All of the JSON alternatives and the first CBOR alternative are not secure when used with counters.

The security issues clearly need to be fixed. The master salt construction need to be well-specified also to avoid interoperability between different implementations.

-------------------------
 
"The response code must be 4.01 (Unauthorized) in case the client has a valid token associated with that Security Context, but the Security Context has not been used before, as the proof-of-possession in this profile is performed by both parties verifying that they have established the same Security Context."
 
Sending unauthorized, achieves nothing compared to sending a successful response and wastes a complete round-trip. RS has no reason to consider C unauthorized. RS has proof-of-possesion at this point. RS has no reason to send Unauthorized, a successful answer achieves the same thing. After receiving any response, C gets proof-of-possesion.

This should be fixed, even if it is not a security issue.

Suggestion: Remove this paragraph. Note that this is the only place in the draft where the profile mandates an OSCORE response. CoAP responses are in general optional. So if you want proof-of-possesion in both directions, you need to mandate a response, but there is no reason to mandate 4.01.
 
-------------------------
 
- "We assume in this document that a resource is associated to one single AS, which makes it possible for the AS to enforce uniqueness of identifiers for each client requesting a particular resource to a RS."

"enforce uniqueness of identifiers for each client requesting a particular resource" is not a meaningful thing to do. You probably want to say:

- "We assume in this document that a RS is associated to one single AS, which makes it possible for the AS to enforce uniqueness of identifiers for each client sending requests to a RS."
 
-------------------------
 
As far as I can tell, the draft does not say anything about the AS reusing a token/OSCORE_Input_Material/master key. An AS reusing the same token to several C seem in general like a ok thing to do if a RS only wants to know that the requests is authorized and does not need info on who C is. This can also severely limit the amount of storage/memory in the RS. Requiring RS to save a new token / object for many C is not suitable for a constained RS.
 
If AS cannot reuse a token/object/ms you need to explicitly forbid that.
 
-------------------------
 
"so if a client uses the same single token from multiple locations with multiple Resource Servers, it can risk being tracked by the token's value even when the access token is encrypted."
 
The corresponsing security risks of this is missing. These security implication of using symmetric keys was pointed out by Jim on the list. Suggestion:
 
"If a single OSCORE_Input_Material object is used with multiple RSs, the RSs can impersonate C to one of the other RS, and impersonate another RS to the client. If a master key is used with several clients, the Cs can impersonate RS to one of the other C. Similarly if symmetric keys are used to integrity protect the token between AS and RS and the token can be used with multiple RSs, the RSs can impersonate AS to one of the other RS. If the token key is used for any other communication between the RSs and AS, the RSs can impersonate each other to the AS."

Alternatively, things can be forbidden.
 
-------------------------
 
- "occurs implicitly"

The use of "implicitly" is a bit unfortunate here as implicit is very commonly used to describe level of key confirmation and this draft provides explicit key confirmation.

Suggestion: Rewrite with something not using the word "implicit"
 
-------------------------

- Figure 1.
 
"[ ]" is not defined

But even better would be if the profile did not talk about any specific AS discovery mechnism.
 
-------------------------

 





Editorial suggestions:

-------------------------

- "bound to a key" -> "bound to a symmetric key"
 
-------------------------
 
- "This situation might occur " -> "two-time pad might otherwise occur"
 
-------------------------

- Figure 1.
 
I think it would be very good if you added a little bit more text in the Figure to show when proof-of-possession achieved.
 
/Sec Context             /Sec Context                |
   Derivation/              Derivation/               |
   |                            |                     |
   | ---- OSCORE Request -----> |                     |
 
                                                proof-of-possession
                                                context storage
   |                            |                     |
   | <--- OSCORE Response ----- |                     |
 
proof-of-possession
context storage
   |                            |                     |
   | ---- OSCORE Request -----> |                     |
   |                            |                     |
   | <--- OSCORE Response ----- |                     |
   |           ...              |                     |
 
-------------------------

Cheers,
John

-----Original Message-----
From: John Mattsson <[e-mail]>
Date: Saturday, 5 September 2020 at 14:51
To: "[e-mail]" <[e-mail]>
Subject: Review of draft-ietf-ace-oscore-profile

Hi,

I have reviewed the latest GitHub version of draft-ietf-ace-oscore-profile
https://ace-wg.github.io/ace-oscore-profile/draft-ietf-ace-oscore-profile.html

In general this draft looks very good. I have one major comments, and several more minor comments.

Major comment
-------------------

- Asignment of OSCORE Sender and Recipient IDs

I think the specified mechanism where the AS dictates the OSCORE connection parameters is unfortunate. It introduces several current and future limitations. The current assignment mechanisms only works without problems in close systems where the RS does not have any other non-AS OSCORE connections, where the CoAP client and CoAP server roles are fixed and cannot be switched, and where only draft-ietf-ace-oscore-profile is used. In systems where the OSCORE nodes can switch between CoAP client and CoAP server (a feature explicitly supported by OSCORE) the current mechanism is likely to lead to RecipientID collisions. Also in future systems where the AS also supports a more modern key management with PFS using e.g. a future draft-ace-edhoc-oscore-profile, the mechanism would not work together in an efficient way. My understanding is that the authors would like the solution to work with both role switching and EDHOC.

How to negotiate these type of connection identifiers (in this case OSCORE Sender and Recipient IDs) have been studied and specified several times in e.g. draft-selander-lake-edhoc, draft-ietf-tls-dtls-connection-id. A solution where each party choses its OSCORE recipient ID for the connection always work without collisions. Such a negotiation could quite easily be added to the roundtrip with the nonces N1 and N2. My feeling is that it would be worthwhile to do such a change. This would also require a new identifier for the OSCORE_Security_Context Object, either a new objectID or a hash of the object could be used. I think this would be a good change as the current "hack" of using the ACE client sender Id and and ID context to identify the object might lead to other future limitations.

The suggested changes would lead quite equal message sizes and storage requirements, they might even lead to some small improvements.

Minor comments
-------------------

- "server authentication"

My understanding is that server authentication with this draft requires two additional things. That C trusts AS and that RS sends an OSCORE response back. The draft should point this out similarly to the way it points out that a OSCORE request is required for proof-of-possession. As C trust in AS, and RS sending an OSCORE response back are both optional, I would recommend to maybe remove "server authentication" from the abstract and intro.

- "The nonces are encoded as CBOR bstr if CBOR is used, and as Base64 string if JSON is used"

Would be good to define exactly how the Master salt is created when JSON is used. I.e. is the Base64 encoded strings used, or are the byte strings after Base64 decoding used.

- "the authz-info endpoint is not a protected resource, so there is no cryptographic protection to this request."

I do not think this follows from the OAuth ACE term “protected resource”. Most resources on the web are not protected resources, but use cryptographic protection (https:// HTTPS)

- "An OSCORE_Security_Context is an object that represents part or all of an OSCORE Security Context"

The object cannot represent all of an RFC 8613 OSCORE Security Context as sequence number, replay window, and Master salt are missing. I would also strongly recommend removing "context" from the name of the object so that it is not confused with an RFC 8613 context. Maybe OSCORE input keying material or something similar.

- "CBOR type"

The types listed are CDDL types. Should at least mention CDDL or change to actual CBOR types.

- "Security Context identified by "kid""

This message has two different "kid", one on the ACE level and one on the OSCORE level, would be good to clarify which "kid" this refers to.

- "client" "server"

I think the draft should have a sentence saying that the terms "client" "server" when used without specification refer to the ACE client C and the ACE resource server RS. There is another server in the ACE architecture, and on the CoAP level the nodes can switch roles.

- "input salt"

input salt is not defined when it is used in section 2.

- "clientID", "serverID", "contextID"

I am not fond of these new abbreviations for the OSCORE parameters for several reasons. The draft uses the term "clientID" for "ACE client sender ID" = "ACE resource server recipient ID", the term "serverID" for "ACE client recipient ID" = "ACE resource server sender ID", and the term "contextID" for "ID context". "clientID" and "contextID" is also together used as an identifier for the "OSCORE_Security_Context Object".

The problems I have with these terms are that "client ID" and "serverID" give the impression that they are identifiers for the nodes C and RS, which they are not. In two-party OSCORE, the identifiers (senderID and recipientID) are not connected to any of the parties more than the other. In fact, a node needs to be in control of its recipient IDs but does not really need to care much about its sender IDs.

- RFC 8613 Appendix B.2

To me it does not seem clear if draft-ietf-ace-oscore-profile can be used together with the mechanism in Appendix B.2 of RFC 8613. The mechanism in Appendix B.2 leads to a new Context ID. Is it allowed to use that mechanism after using draft-ietf-ace-oscore-profile? In draft-ietf-ace-oscore-profile, the AS dictates a specific “ID Context”?

Cheers,
John