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

From: Jim Schaad <[email-masked]>
Date: Mon, 7 Sep 2020 13:14:02 -0700

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

---

From: John Mattsson <[email-masked]>
Date: Tue, 8 Sep 2020 07:33:54 +0000

Hi Jim,

I agree with most of what you say. Below are some additional comments on some of the bullets.

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

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

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

/John

-----Original Message-----
From: Jim Schaad <[email-masked]>
Date: Monday, 7 September 2020 at 22:14
To: John Mattsson <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Assignment of OSCORE Sender and Recipient IDS - was RE: [Ace] Review of draft-ietf-ace-oscore-profile

-----Original Message-----
From: Ace <[email-masked]> On Behalf Of John Mattsson
Sent: Saturday, September 5, 2020 5:51 AM
To: [email-masked]
Subject: [Ace] Review of draft-ietf-ace-oscore-profile

Major comment
-------------------

[/JLS]

Cheers,
John

---

From: Christian Amsüss <[email-masked]>
Date: Tue, 8 Sep 2020 15:32:16 +0200

Hello John, Jim,
and ACE in general,

I agree with Jim that namespacing is the obvious solution to this
problem; we've had a brief discussion in a WG meeting shared with OCF
earlier this year.

However, the namespacing of KIDs is a difficult matter[1] and moreover
little understood so far. I'm unaware of any document describing how the
association between a device and an AS comes to be, let alone how the
device indicates to the AS which shard of its recipient IDs it may use.
(And is that a prefix or a suffix to the KID? Is it by bits or by
bytes?)

Having multiple AS involved with a device is a situation we should be
prepared for, especially when considering that even in a closed system
under single administration, the AS may be distributed for reasons of
reliability. Managing those (as well as other sources of OSCORE contexts
like LAKE) would be easier if the device didn't have to think through
its namespacing, especially given that there might be ad-hoc decisions
to be made: A server may be OK with giving out a short recipient ID to a
device on the network (where it can use the source IP to pick the right
context), but would pick a longer KID for a client ringing in through a
proxy that has no information in its source address.

At the same, time, getting endpoint chosen KIDs right is a bit harder
than it is with AS-provided ones: An scenario that came up in a recent
chat with John showed that if RS and C would happen to both pick the
same KID and a MITM modifies the token POST, both would derive identical
security contexts. Then, it suddenly becomes crucial for the security of
the whole construct that the RS first verifies a request coming from C
before sending any message whatsoever with that context.

So to summarize, I like the idea, and I'd like to see it thought through
(preferably before we even have to work out how that namespacing is
manged precisely), but I'm not sure that that all the questions that'd
come up in the process are realistic to address at this stage.

KR
Christian

[1]: See https://tools.ietf.org/html/draft-amsuess-lwig-oscore-00#section-4
  for a poem and some notes

-- 
To use raw power is to make yourself infinitely vulnerable to greater powers.
  -- Bene Gesserit axiom

---

From: Jim Schaad <[email-masked]>
Date: Tue, 8 Sep 2020 15:47:22 -0700

Hey John, comments in line commented with JLS2

-----Original Message-----
From: John Mattsson <[email-masked]> 
Sent: Tuesday, September 8, 2020 12:34 AM
To: Jim Schaad <[email-masked]>; [email-masked]
Subject: Re: Assignment of OSCORE Sender and Recipient IDS - was RE: [Ace] Review of draft-ietf-ace-oscore-profile

Hi Jim,

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

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

[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 <[email-masked]>
Date: Monday, 7 September 2020 at 22:14
To: John Mattsson <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Assignment of OSCORE Sender and Recipient IDS - was RE: [Ace] Review of draft-ietf-ace-oscore-profile

-----Original Message-----
From: Ace <[email-masked]> On Behalf Of John Mattsson
Sent: Saturday, September 5, 2020 5:51 AM
To: [email-masked]
Subject: [Ace] Review of draft-ietf-ace-oscore-profile

Major comment
-------------------

[/JLS]

Cheers,
John

---

From: John Mattsson <[email-masked]>
Date: Wed, 9 Sep 2020 08:42:54 +0000

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: John Mattsson <[email-masked]> 
Sent: Tuesday, September 8, 2020 12:34 AM
To: Jim Schaad <[email-masked]>; [email-masked]
Subject: Re: Assignment of OSCORE Sender and Recipient IDS - was RE: [Ace] Review of draft-ietf-ace-oscore-profile

Hi Jim,

/John

-----Original Message-----
From: Jim Schaad <[email-masked]>
Date: Monday, 7 September 2020 at 22:14
To: John Mattsson <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Assignment of OSCORE Sender and Recipient IDS - was RE: [Ace] Review of draft-ietf-ace-oscore-profile

-----Original Message-----
From: Ace <[email-masked]> On Behalf Of John Mattsson
Sent: Saturday, September 5, 2020 5:51 AM
To: [email-masked]
Subject: [Ace] Review of draft-ietf-ace-oscore-profile

Major comment
-------------------

[/JLS]

Cheers,
John