Subject: [Lake] LAKE Requirements

From: Karthikeyan Bhargavan <[email-masked]>
Date: Mon, 18 Nov 2019 10:55:27 +0100

Hello All,

I have been reading through the requirements draft 3 [1].
Here are some comments and questions.

Section 2.1 talks of a shared secret with PFS.
It would be good to make this more precise.
PFS against the compromise of which key material?
I am guessing the answers are:
- we want to protect against the loss of long-term keys at the initiator
- we want to protect against the loss of long-term keys at the responder
- we may or may not want to protect against the loss of ephemeral keys
- we may or may not want to protect against a bad RNG at initiator or responder

This talk of PFS also raises the question of what we can assume about the device.
Does it have state? E.g. can we assume it has a increment-only counter and an associated key it can store in persistent storage?
If yes, then PFS can be obtained in a cheaper way by simply hashing forward a symmetric key.

Section 2.2 talks of credentials.

It is not entirely clear why a PKI allows you to omit key provisioning compared to RPK.
In both cases, the device needs to have a private key, whether attached to a certificate or not.
Furthermore, to validate other devices’ public keys, each device will need to know the public key of a CA.
Can you explain better why we may want a PKI at all?
I suspect it is so that each device needs to keep only one RPK for the CA instead of an RPK for each other device it speaks to?

On the other hand, I think defining a protocol for refreshing the RPK would be quite useful.
Is that a requirement for the architecture?

Section 2.3: identity protection

I agree that there are limits to what we can protect with current protocols.
But it would be good to have a sequence of desired goals where we may only be able to meet some level:
0: all identifying information should be protected against passive network adversaries
1: the identifying information of one device (say the initiator) must be protected from an active network attacker
2: the identifying information of both devices must be protected from an active network attacker
3: the identifying information of both devices must be deniable/repudiable, even if the peer is malicious

Section 2.4 speaks about crypto agility

The first paragraph speaks about OSCORE algorithms but not about the AKE algorithms themselves.
Maybe you want to add a second paragraph about the scope of agility in LAKE:
- the protocol should support both PSK and asymmetric key authentication
- the protocol should support multiple elliptic curves for asymmetric keys
- the protocol should support post-quantum algorithms?

The paragraph beginning “Compromise of the long-term keys…” should go into Section 2.5 (it is about authentication, not agility)
The next paragraph beginning “The AKE shall protect against …” should also go into Section 2.5

Section 2.5: mutual authentication

"mutual authentication” is a different idea than “injective agreement”, although both are useful concepts.
It would be good to explain both. E.g. “At the end of the AKE, both devices must have authenticated the peer’s identity….”
And then describe attacks it should prevent: No replays (injective), no identity misbinding, no reflection, no KCI.

I don’t understand this bit from Sec 2.4:  Compromise of the long-term keys shall not enable an attacker to ... compromise future session keys.
What do you mean by this? How can we protect future session keys?

Section 2.6 provides functional constraints on LAKE. 
I did not review these in detail but certainly they are very useful to have fleshed out here.

However, I think there is something missing here about Denial of Service.
In Section 2.1, the document requires that the underlying transport for the AKE should protect against message loss and DoS-style attacks.
On the other hand, Section 2.6 describes a number of situations where the underlying transport may not be able to provide very strong guarantees
against network attacks. 

This raises two questions
1) Can a network attacker cheaply prevent the AKE from ever succeeding, forcing devices to fall back to insecure communication protocols?
2) Does the AKE itself introduce a larger surface for DoS compared to raw COSE? 
    I.e. by introducing a new protocol that requires multiple messages, are we introducing a new DoS risk that will brick devices, a risk that did not exist before?

Looking forward to your responses.

Best,
Karthik

[1] https://tools.ietf.org/html/draft-selander-lake-reqs-03 <https://tools.ietf.org/html/draft-selander-lake-reqs-03>

---

From: Göran Selander <[email-masked]>
Date: Tue, 19 Nov 2019 11:34:11 +0000

Hi Karthik,

Thanks for good comments, some responses and thoughts inline.

From: Lake <[email-masked]> on behalf of Karthikeyan Bhargavan <[email-masked]>
Date: Monday, 18 November 2019 at 10:56
To: "[email-masked]" <[email-masked]>
Subject: [Lake] LAKE Requirements

Hello All,

GS: Protection against loss of long-term keys at the initiator and responder is assumed. The other properties have not been made explicit. It would be good if they could be discussed in the context of cost, such as additional processing, messages/message sizes etc., so the trade-offs are understood. Perhaps we should make some examples of how to address them?

GS: So far, it has not been assumed that initiator/responder roles can be mapped to capabilities, e.g. that the initiator is a constrained device. This does not mean that both roles necessarily need to be protected against certain issues, since we may add deployment constraints to the protocol, e.g. (hypothetically) "if potentially bad RNG then assign initiator role". (The same argument as for identity protection where potentially only one party gets protection.)

GS: We cannot assume in general that both parties have state, but there may be cases where at least one party for practical purposes can be assumed to have persistent storage. Even if both parties have state, it is not necessarily synchronized. It wasn’t clear to me how PFS can be obtained with your example (if not synchronized state is assumed). Could you please expand on that?

GS: I agree that the text on PKI is very brief and should be expanded. Clearly, each party needs to have its own credential provisioned beforehand (say in factory or generated on-board). Also, each party needs something to base authentication of the other. For the PKI settings we assume that also this is provisioned beforehand, say a public key of an appropriate root CA. The point is that those credentials can be independent on which particular legitimate other party that is being authenticated (so that they actually can be provisioned beforehand). As a consequence devices may be able to securely join a network without additional provisioning during commissioning, which is desirable e.g. for zero-touch deployments. One way of doing this is that devices are provided with manufacturer certificates (and private key and trusted public CA key) in factory, and these credentials are used to enable authentication and authorization of enrolment of local certificates issued in the network which the device joins. (This procedure is out of scope for LAKE, but is one application we may use to sanity check the solution.) Does it make more sense?

GS: It wasn’t clear to me which RPK is being replaced, the device’s own RPK or the other party’s RPK? Please elaborate. In case of the former, can we consider this an application of the AKE (similar to the enrolment during commissioning mentioned above) or otherwise independent from the AKE design (and potentially used as a sanity check as above)?

GS: I find this reasoning and listing of different levels of goals helpful at least on the conceptual level. In order to fully understand the different options it needs to be complemented with the cost (in terms of added weight) as well as conflicting security requirements, so that the trade-offs are clear. We have already discussed one example of trade-off between identity protection of the symmetric protocol and authentication of responder/no. of messages. Another trade-off is between disclosure of supported cipher suites (which may reveal information of the device) vs. crypto agility. Connection identifier could reveal information about the size of the server. This leads to modification of the levels listed above which exempts some information from this list. Since the main ambition with this work is to design an AKE that can run on a very constrained device but still maintain a decent security and privacy, it may be too limiting to hide all identifying information against passive adversaries. Does this make sense?

GS: In particular we should consider whether or not protecting information that is anyway revealed by subsequent processing or lower layer. In summary, I agree we should try to clarify different potential goals and the trade-offs that they incur.

GS: I don’t disagree with your proposal below, but the first paragraph does speak of AKE algorithms, doesn’t it?
“the AKE is required to support crypto agility, including modularity of COSE crypto algorithms and negotiation of preferred crypto algorithms for OSCORE and the AKE”

GS: Agree on both.

GS: I would argue that the AKE should be expandable to support PQC algorithms. COSE is in the process of supporting hash-based signature algorithms. Again, since the main objective is to be able to run on a very constrained device, an efficient mode of the AKE must not be forbidden because it is not post-quantum. So far we have assumed that post-quantum key exchange is out of scope.

GS: Agree.

GS: Agree.

GS: Fine, just on identity misbinding: In some cases the identity may be just the public key. Is the term “identity misbinding” used also for that case?

I don’t understand this bit from Sec 2.4:  Compromise of the long-term keys shall not enable an attacker to ... compromise future session keys.
What do you mean by this? How can we protect future session keys?
  GS: The emphasis in the quoted sentence is on passive attackers, which should not be able to compromise any session key. Is there some misunderstanding here?

GS: I agree that DoS should be listed in the security properties of the AKE.  One thing I thought about when editing this point: Just because the underlying layer is assumed to provide certain DoS mitigation -- like congestion control and backoff, which is therefore out of scope for LAKE -- it should not be interpreted as if the AKE does not have to consider DoS. Is that one reason for your comment?

GS: Avoiding cheap attacks should be in scope to the extent that they can be impacted by the actual security protocol. I didn’t understand the last part: how the AKE not succeeding is forcing a device to use an insecure communication protocol, unless the communication policy allows that, which should be questioned.

2) Does the AKE itself introduce a larger surface for DoS compared to raw COSE?
    I.e. by introducing a new protocol that requires multiple messages, are we introducing a new DoS risk that will brick devices, a risk that did not exist before

GS: COSE in itself only defines 1-pass protocols - how to process before and after message transport - so I believe any AKE does introduce a larger DoS surface. And during a DoS attack the device availability may be significantly affected, so that it is effectively offline, e.g. a jamming attack. This may be very hard to protect against, and I’m not sure if requirement or non-requirement is the right formulation for stating the assumptions in this respect.

GS: What we certainly want to consider is the case when an attacker injects a message or otherwise disturbs communication that changes state in a peer such that it prevents communication between two peers even when the effort has stopped from the attacker. Is that what you are thinking of in terms of "bricking"?  Any proposal for how to formulate such a requirement?

Thanks,
Göran

[1] https://tools.ietf.org/html/draft-selander-lake-reqs-03