Hey John, comments in line commented with JLS2
-----Original Message-----
From: John Mattsson <john.matts...@ericsson.com>
Sent: Tuesday, September 8, 2020 12:34 AM
To: Jim Schaad <i...@augustcellars.com>; ace@ietf.org
Subject: Re: Assignment of OSCORE Sender and Recipient IDS - was RE: [Ace]
Review of draft-ietf-ace-oscore-profile
Hi Jim,
I agree with most of what you say. Below are some additional comments on some
of the bullets.
[JLS] I'll start with what I said on the mailing list - this problem was
discussed previously on the mailing list and in person and it was decided that
it did not need to be fixed.
[JM] My understanding from Francesca and Göran is that neither migration path
to e.g. EDHOC nor systems where the nodes change roles have been discussed
before. Both have additional collision probems. How important the use cases are
and how bad the collision problem would be can be discussed.
[JLS2] This may be a case of people not hearing things that they don't think
are of immediate importance. I spent a couple of years arguing about much of
this. I did not deal with the reversing situation because I am not sure that
this really makes a great deal of sense for ACE in general. The one exception
would be things like revocation, but that is always going to be a single RS.
[JLS] 1) The use of the same token on multiple RS has security problems on its
own that cannot be overlooked. It is possible that we need to say that this
just should not be done. If you are using symmetric keys all around, then RS1
an impersonate C to RS2 because it has all of the necessary keying material to
post the token and setup a security context. RS1 can go farther and
potentially impersonate the AS to RS2 gaining additional privileges when it
impersonates C if the AS is using symmetric keys to validate tokens to RS1 and
RS2. This indicates that generally one does not want to use the same token
with multiple devices.
[JM] Yes, using symmetric keys for authentication in groups is in general a
very bad idea. Forbidding use of the token to several servers would forbid the
use of multiple resource servers for redundancy. Alternatively several RS
accepting the same token could be allowed in certain circumstances.
[JLS2] I agree that this is true, and it is one of the things that I was
arguing with Ludwig about it being a reasonable thing to do. It is also
something that one wants to have for things like anycast where you don't know
which of the servers you are going to end up with. This however does not
change the security problems with it.
[JLS] 3) You seem to be ignoring the most practical solution to the problem,
use the context identifier for name space separation. If you have five
different ASs, then simply assign a one byte context to each of them and you
now have no problems with name collisions unless somebody is going to be
knowingly difficult. Similarly, you assign each of the group key managers a
one byte value which is used as the prefix to the contexts assigned by that key
manager for all of the groups it manages. I would have to look to see if one
can specify a context for LAKE, but being able to do so would provide a
separation for that space as well.
[JM] Yes, that is definitely a solution, but I don't think it matters if you
use ID context or longer Sender IDs, it's the sum of the lengths that matter
for the collision probability. I agree that you can definitely solve the
collision problem by randomly assigning longer ID Context + Sender ID,
potentially combined with a mechanism (as you mentioned during the interim)
where the client rejects tokens that lead to collisions. This solves collision
problems on with the cost of additional roundtrips and/or larger OSCORE message
sizes. Both could be acceptable, but unfortunate as collision free and optimal
(in terms of message size) are well-known and there seems to be no benefits of
the AS dictating Sender and Recipient IDs. Both RFC 7252 and RFC 8613 is very
careful to not waste a single byte.
[JLS2] Please re-read what I outlined. I was suggesting the use of very short
ID contexts which are assigned in a non-random method. This means that the
collision probability can be highly controlled and you are not using longer
sender IDs that you would otherwise.
[JLS2] One of the big advantages of the AS assigning client ids is that updated
tokens will have the same client IDs so that you don't end up with having to
change these because you do not recognize that it should be the same security
conversation. There are also advantages because neither party needs to make
decisions about how long an ID should be good for. The server can make those
decisions for you.
/John
-----Original Message-----
From: Jim Schaad <i...@augustcellars.com>
Date: Monday, 7 September 2020 at 22:14
To: John Mattsson <john.matts...@ericsson.com>, "ace@ietf.org" <ace@ietf.org>
Subject: Assignment of OSCORE Sender and Recipient IDS - was RE: [Ace] Review
of draft-ietf-ace-oscore-profile
-----Original Message-----
From: Ace <ace-boun...@ietf.org> On Behalf Of John Mattsson
Sent: Saturday, September 5, 2020 5:51 AM
To: ace@ietf.org
Subject: [Ace] Review of draft-ietf-ace-oscore-profile
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.
[JLS] I'll start with what I said on the mailing list - this problem was
discussed previously on the mailing list and in person and it was decided that
it did not need to be fixed.
1) The use of the same token on multiple RS has security problems on its own
that cannot be overlooked. It is possible that we need to say that this just
should not be done. If you are using symmetric keys all around, then RS1 an
impersonate C to RS2 because it has all of the necessary keying material to
post the token and setup a security context. RS1 can go farther and
potentially impersonate the AS to RS2 gaining additional privileges when it
impersonates C if the AS is using symmetric keys to validate tokens to RS1 and
RS2. This indicates that generally one does not want to use the same token
with multiple devices.
2) I mentioned that one could use trial decryption to distinguish between
multiple RS senders. This is normally only going to require one trial due to
the fact that one can use the source IP address for sorting the different
security contexts for trial. As long as you do not have address collisions or
changing addresses this makes things much easier to distinguish them.
3) You seem to be ignoring the most practical solution to the problem, use the
context identifier for name space separation. If you have five different ASs,
then simply assign a one byte context to each of them and you now have no
problems with name collisions unless somebody is going to be knowingly
difficult. Similarly, you assign each of the group key managers a one byte
value which is used as the prefix to the contexts assigned by that key manager
for all of the groups it manages. I would have to look to see if one can
specify a context for LAKE, but being able to do so would provide a separation
for that space as well.
4) I am not clear why Francesca thinks that doing the bis would make this a
difficult thing to add. You add two new items and then you get following
cases:
a) The client does not use the new item: The ids in the token are
going to be used
b) The client sends the item:
The server errors back because it does not support it and is
strict - client goes to a)
The server does not return a new item because it does not
support it and is lax, the ids in the token are going to be used
The server does return it's new item, the ids in the messages
are going to be used.
5) I don't understand the case you are trying to make about reversing roles.
First see point 1 above as the RS is not going to know who it is talking to, it
could be C or it could be RS2 acting as an on-path attacker.
[/JLS]
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
