I agree we need to distinguish between managed id-spaces, like groupcomm, and
cases where we do not strictly need to manage the ids.
Given the discussion we are having here, a recommendation for to add to RFC8613
would be "Each endpoint SHOULD assign its recipient identifiers." This is what
EDHOC does and, with hindsight, this is what the ACE-OSCORE profile should have
done. There is no security issue with the current draft, it is about
simplifying the identification of security contexts in various situations by
removing the need for special considerations due to identifiers allocated by
different parties. I see no drawbacks in allowing the endpoints make the
assignment (an OSCORE protected resource request must complete before parties
are authenticated but this is also required in the current version,
Sender/Recipient ID may be reused for updated access rights between the same
endpoints, Client/Server ID terminology becomes redundant, ... ) except that we
are very late in the process. And this is the authors' fault, Jim has been
raising issues on this topic and we have not been responsive.
Göran
On 2020-09-09, 08:52, "John Mattsson" <john.matts...@ericsson.com> wrote:
The question in my view is if this draft should create collisions. All
other drafts assigning identities to RFC 8613 that have ever been discussed in
the IETF takes efforts to not create any collisions in the first place
https://tools.ietf.org/html/draft-selander-lake-edhoc-01
https://tools.ietf.org/html/draft-mattsson-ace-tls-oscore-00
https://tools.ietf.org/html/draft-friel-tls-atls-04
All these assignment mechanism can be used together collision-free without
ID Context and with minimal length Sender ID / Recipient ID. So I don’t think
the statement that “Collisions are going to be a common problem across all of
these different ways of getting OSCORE contexts established.” is correct.
Group OSCORE is a different story, there the assignment mechanism have to
handle collisions with ID Contexts (unless the deployment is strictly local,
e.g. when used only over a local radio technology).
One option is that this draft recommends the use of an ID context unless
the draft is uses in a local closed system, and that a bis version of the draft
makes the simple changes to not get collisions in the first place.
It would as you say have been very good if RFC 8613 discussed how to
negotiate Sender ID / Recipient ID. If there is ever a bis version, this should
definitly be added.
John
-----Original Message-----
From: Jim Schaad <i...@augustcellars.com>
Date: Tuesday, 8 September 2020 at 21:14
To: John Mattsson <john.matts...@ericsson.com>, Göran Selander
<goran.selan...@ericsson.com>, "ace@ietf.org" <ace@ietf.org>
Subject: RE: [Ace] Review of draft-ietf-ace-oscore-profile
John,
I am wondering if this is really the document that should be dealing with
this collision problem. A number of the collisions that might occur are going
to be out of the ACE scope and a more general discussion of the problem should
probably occur in a BIS version of the CoRE OSCORE document itself. Memory
says that the document does not claim to deal with how names are assigned to
contexts, but I think that having a centralized location that LAKE, ACE (AS,
Groupcomm and pub-sub) and perhaps other methods that we don’t currently have
in our radar. Collisions are going to be a common problem across all of these
different ways of getting OSCORE contexts established.
Jim
-----Original Message-----
From: Ace <ace-boun...@ietf.org> On Behalf Of John Mattsson
Sent: Tuesday, September 8, 2020 12:40 AM
To: Göran Selander <goran.selander=40ericsson....@dmarc.ietf.org>;
ace@ietf.org
Subject: Re: [Ace] Review of draft-ietf-ace-oscore-profile
Hi,
Just want to say that I don't have any strong opinions on how to proceed. I
just wanted to point out the collision problems with the draft are more severe
that the group have discussed. Ignoring collisions seems like a mistake, and to
my understanding there seems to be no benefits of the AS dictating Sender and
Recipient IDs.
I think Jim has a good point in that the solution with symmetric key
authentication comes with a lot of limitations anyway.
/John
-----Original Message-----
From: Göran Selander <goran.selander=40ericsson....@dmarc.ietf.org>
Date: Monday, 7 September 2020 at 17:05
To: John Mattsson <john.matts...@ericsson.com>, "ace@ietf.org"
<ace@ietf.org>
Subject: Re: [Ace] Review of draft-ietf-ace-oscore-profile
Hi,
Just want to acknowledge, as was discussed in the WG meeting today, that
the major comment below is alternatively a possible -bis update. I think this
is good functionality, and even though related problem statements have been
discussed before, this solution has not. And although the change is small it
comes at a late stage. But if it doesn't make it for this version then let's
make it in an update soon.
Göran
On 2020-09-05, 14:51, "Ace on behalf of John Mattsson"
<ace-boun...@ietf.org on behalf of john.mattsson=40ericsson....@dmarc.ietf.org>
wrote:
Hi,
I have reviewed the latest GitHub version of
draft-ietf-ace-oscore-profile
https://protect2.fireeye.com/v1/url?k=cd0dd5df-93bc0ebf-cd0d9544-86e2237f51fb-51fc8fb4bf065a0f&q=1&e=5ecc1a37-faa1-4082-857b-150aa2dc3b9a&u=https%3A%2F%2Face-wg.github.io%2Face-oscore-profile%2Fdraft-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
_______________________________________________
Ace mailing list
Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace
_______________________________________________
Ace mailing list
Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace
