[Ace] Assignment of OSCORE Sender and Recipient IDS - was RE: Review of draft-ietf-ace-oscore-profile

[Jim Schaad <[e-mail]>]

-----Original Message-----
From: Ace <[e-mail]> On Behalf Of John Mattsson
Sent: Saturday, September 5, 2020 5:51 AM
To: [e-mail]
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
[e-mail]
https://www.ietf.org/mailman/listinfo/ace