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

[John Mattsson <[e-mail]>]

I agree very much with you Jim regarding the use on symmetric keys, and I think this is something IETF needs to work with in the future. I think a lot of IETF groups and drafts are using way too much symmetric keys for authentication and key exchange. There seems to be a belief that symmetric keys are needed for constrained IoT, which is not the case. Asymmetric authentication and key exchange can be achieved in similar message sizes to PSK authentication. E.g.

- method type 3 (static DH Key + static DH Key) in https://tools.ietf.org/html/draft-ietf-lake-edhoc-01

- static-static Diffie-Hellman shared secret in https://tools.ietf.org/html/draft-ietf-core-oscore-groupcomm-09

There are also very efficient ECC implementations taking up just a few kB.

Two-party authentication with symmetric keys comes with privacy problems, and symmetric groups keys does not provide authentication of the peer, just group membership. Symmetric key exchange does not provide PFS. Symmetric keys also comes with severe deployment problems.

While there are cases where asymmetric cryptography requires too much storage, memory, message sizes, or processing (latency), these are exceptions and should not be the default.

I see a limited need for symmetric authentication or key exchange in new systems, and I think the use should be clearly motivated. The main reason to use symmetric keys is in my view legacy interop.

John

-----Original Message-----
From: Jim Schaad <[e-mail]>
Date: Wednesday, 9 September 2020 at 00:48
To: John Mattsson <[e-mail]>, "[e-mail]" <[e-mail]>
Subject: RE: Assignment of OSCORE Sender and Recipient IDS - was RE: [Ace] Review of draft-ietf-ace-oscore-profile

Hey John, comments in line commented with JLS2

-----Original Message-----
From: John Mattsson <[e-mail]> 
Sent: Tuesday, September 8, 2020 12:34 AM
To: Jim Schaad <[e-mail]>; [e-mail]
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] 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 <[e-mail]>
Date: Monday, 7 September 2020 at 22:14
To: John Mattsson <[e-mail]>, "[e-mail]" <[e-mail]>
Subject: Assignment of OSCORE Sender and Recipient IDS - was RE: [Ace] Review of draft-ietf-ace-oscore-profile



-----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