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 <john.matts...@ericsson.com>
Date: Saturday, 5 September 2020 at 14:51
To: "ace@ietf.org" <ace@ietf.org>
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
_______________________________________________
Ace mailing list
Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace
