# IETF106 Lightweight Authenticated Key Exchange (LAKE)

Wednesday November 20th, 1520-1650, Sophia

Chairs: Mališa Vučinić, Stephen Farrell
Charter: https://datatracker.ietf.org/group/lake/about
Mailing list: https://www.ietf.org/mailman/listinfo/Lake
Jabber room: lake@jabber.ietf.org
Etherpad: https://etherpad.ietf.org/p/notes-ietf-106-lake?useMonospaceFont=true

Agenda
----------
- Administrivia and agenda bash (chairs, 10 mins)
- Requirements draft (John Mattsson, 20 mins)
    - Present changes, open items
    - https://tools.ietf.org/html/draft-selander-lake-reqs
- Hum to check if room happy to adopt (after "yes": do-adoption-call on list)
- If room doesn't want to adopt reqs draft:
    - DISCUSS that
- If room seems to want to adopt reqs draft:
    - Initial discussion of static-DH requirements (John Mattsson, 10 mins)
    - Identity protection of the PSK and related tradeoffs (John Mattsson, 5 mins)
    - Expected security properties of the application data (John Mattsson, 5 mins)
    - 6tisch requirements (Michael Richardson, 5 mins)
- Next steps (chairs, 5 mins)
- AOB

Volunteers
----------
- notetaker 1: Marco Tiloca
- notetaker 2: Tero Kivinen
- jabber scribe: Francesca Palombini

Action items
----------
- Chairs to issue call for adoption of draft-selander-lake-reqs
- Chairs to set up a github repository for the working group
- Chairs to schedule a virtual interim meeting in January

Summary
----------
The lake wg met for the first time to work on lightweight authenticated key exchange.
Initial work is focused on requirements.
The people in the room seemed happy to adopt a draft [1] and there was constructive discussion of some issues that were previously raised on the list.
We'll confirm that on the list and go from there.

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

Minutes
----------

- Administrivia and agenda bash (chairs, 10 mins)
    - chairs go through the note well
    - agenda

- Requirements draft (John Mattsson, 20 mins)
    - https://tools.ietf.org/html/draft-selander-lake-reqs
    - Two updates since the BOF.
    - Part of early discussions (ACE, SecDispatch, interim March 5)
    - Requirements made more strict and under clear categories.
    - OSCORE related requirements: the final goal is establishing keying material for OSCORE (security protocol for CoAP), this brings PFS compared to alternative methods that don't. Reusing OSCORE building blocks, e.g. COSE and its algorithm identifiers. Should not duplicate functionalities available e.g. from CoAP.
    - Hannes: an OSCORE Sender ID is associated to a security context.
    - John: similar to a connection ID
    - Mohit: do you plan to support RPK/PSK/certificate for authentication?
    - John:  Yes, more on that later.
    - Authentication, credential, crypto properties. Support for PSK/RPK/Certificate authentication, and different identification of credentials. Shall support identity protection, i.e. public keys and symmetric keys, more to discuss today. Shall support algorithm negotiation for OSCORE and AKE, to change algorithm during the device lifetime, w/ protection against downgrade attacks.
    - Hannes: CFRG considered password-based authenticated key exchange. Is this considered?
    - John: has not come up in the discussion. Maybe used in some deployments, not in the requirements document now.
    - Harkins: Can you do LAKE with just DH?
    - John: It's in a discussion in the end, but I think so.
    - Richard: It is possible.
    - Compromise of long-term keys. Shall ensure PFS and passive attackers to compromise future, keys; resistance to KCI; protect against misbinding and reflection attacks.
    - Ekr: Both or just one party benefit of protection? Is there symmetry?
    - John: You can check that reflected messages are not the same.
    - Mohit: Better be specific on who we are protecting and for which exact attacks.
    - Application data. Keep the roundtrips and number of messages low. More details later. Request for strict requirements on this to help formal verification.
    - Ekr: This is quite a selling point.
    - Lightweight. As few round trips/message as possible. Messages as small as reasonably achievable. New added code in an as small as reasonably achievable amount.
    - Julien Catalano from Jabber: LoRaWAN can go down to 11 bytes (US regulation).
    - Richard: you should be more specific on this.
    - John: this refers to low-layer messages after fragmentation.
    - Mohit: if you are not using something reliable like TCP this is tough to implement.
    - Ekr: not really a problem.
    - Mohit: so you do retransmission at the layer of the AKE then.
    - Ekr: yes, think of DTLS 1.2, it's possible.
    - Richard: you can add a distinction of (type of) layers you are pointing at.
    - Mohit: agree.
    - Valery: keep in mind it's about keeping implementations simple.
    - John: this is all part of the discussions, there are trade-offs to consider.
    - Malisa (no-chair): in 6tisch fragmentation plays a big role to consider. may prefer 4-pass protocol to a 3-pass if there's no fragmentation involved.
    - AKE frequency. How often is it expected to run? Hard to have a general answer. In extreme use case, it may have sense to just have OSCORE with no AKE. Overall, it must be possible to form a network fast, device must be able to re-establish security quickly in case of reboot.
    - Hannes: devices with no persistent storage may have issues; pay attention to where keys are stored.
    - Ekr: this is a sec requirement to struggle with
    - Richard: distinguish if we need an analogous to session resumption in TLS or a key update
    - Ekr: is the OSCORE Master Secret eligible to use for something like session resumption? more to discuss.
    - Ekr: key renewal seems something important enough to considered of its own as a feature of the AKE.
    - Mohit: if the server knows info about the device (e.g. battery-operated, key refresh up to once per week) this can help.
    - Tero: In some deployments a rekeying would happen very seldom. It depends what we are protecting against. There is very little traffic here usually also the rekey might be network wide, which is much more expensive than just one diffie-hellman.
    - John: a policy of this kind is not necessarily in terms of time interval, but e.g. of exchanged data.

- Hum to check if room happy to adopt
    - Ekr: is the hum about the discussion is done? Then I am against. It's fine if it's about getting this doc as starting point.
    - Ben K.: The latter
    - Stephen: A dozen have read the last version.
    - Roman: 2 more on jabber.
    - Stephen: do we want to adopt now? (Several hums)
    - Francesca: 3 for adopting on jabber
    - Stephen: are you against adoption?
    - (silence)
    - Stephen: how do you plan to track issues? Github?
    - John, Richard, Ekr supporting Github

- Initial discussion of static-DH requirements (John Mattsson, 10 mins)
    - Admit static DH keys? How to use them? There was support on the list, EDHOC updated accordingly. This can significantly reduce overhead, especially with RPK authentication. Shown example from the EDHOC document, MAC instead of signature, message size comparable to the ones with PSK. Wish to support also mixed public key credentials, i.e. RPK/Certificate and DH keys / public signature keys.
    - Ekr: Are you assuming CCM8
    - John: No particular assumption
    - Ekr: In this mode the only protection comes from the ciphersuite. We should think of the MAC size.
    - John: This might be a reason to allow for different MAC sizes. But it may not be worthy having some sizes with some technologies.
    - Ekr: agree on the mixed public key credentials support.
    - Richard: yes, something to cover.

- Identity protection of the PSK and related tradeoffs (John Mattsson, 5 mins)
    - Confidentiality protection of PSK identifier, may be protected in message 3.
    - Ekr: you risk to lose authentication of the content in message 1.
    - Got a review of the requirement document; suggestion for different levels of identity protection, e.g. 0 for all information protected from a passive adversary.
    - Ekr: Let's define more in detail the properties we want, no need to stick to this exact hierarchy or something similar.

- Expected security properties of the application data (John Mattsson, 5 mins)
    - Request from academia to specify this better. Cover PFS in case different kind of key material is compromised, now assumed loss of long-term keys at both sides.
    - Worth protecting against loss of ephemeral keys? Cost?
    - Ekr: we should worry especially of the loss of long-term key.
    - Hannes: key exchange is often decoupled from key storage in implementations. Better to consider deployment experience.
    - Stephan: is this about the document content or about implementations?
    - Hannes: just having many different APIs around can be tedious.
    - Important to explicitly say how application data conveyed by the AKE are possibly protected; increasing protection as the AKE goes on.
    - Ekr: does not seem right to claim that application data in message 2 is actually confidentiality/integrity protected against a passive attacker.
    - Hannes: what's in message 2 when conveying information like an Access Token? There is more than that there.
    - John: this is just an example. 6tisch wants to send a token containing the actual keys to use.
    - Hannes: so this is not like the Access Token of OAuth?
    - John: No
    - Malisa: we discussed the exchange of AD1 with a voucher request and providing a voucher in AD2.
    - John: what really matters is to not break the AKE security, this has to be clarified.
    - Ekr: in message 2 especially you want to use different keys
    - John: it makes sense, but it would lead to two MACs, which is probably not ideal
    - Ekr: not sure "as small as possible" is good to express requirements, e.g. on size. That might be interpreted as "we're in WGLC, but wait, we can save 1 byte more, let's get back to design".
    - John: now the document talks a lot about radio technologies, but we can add numbers
    - Göran (from Jabber): one question from Ekr was possible quantum resistance as requirement. Should this be covered?
    - John: it may be something possible to add in the future, not necessary to cover it now.
    - Ekr: agree.

- 6tisch requirements (Michael Richardson, 5 mins)
    - (Malisa presents due to Michael's absence)
    - Points raised several times in the past. In 6tisch there is a zero-touch document describing an enrolment procedure, profiling a number of other documents. The goal is to minimize the overhead of the joining process in a 6tisch network. This does not want to have the DTLS frame overhead.
    - Hannes: the ace-est-coaps you are pointing at here uses DTLS itself, so perhpas not to be considered in the picture.
    - Malisa: [more on 6tisch requirements]. An IDevID is involved (ideally by reference) that would be better to possibly encrypt for the sake of privacy.
    - Ekr: what does it mean that "a raw public key is sent to the client so that it can put it into a voucher request"?
    - Malisa: [clarifying]
    - Ekr: not sure what network topology you have in mind, that may have an impact on this
    - Malisa: 6tisch minimal security considers CoJP for joining, which needs an OSCORE key to be setup.

- Next steps (chairs, 5 mins)
    - Stephen: just go ahead with adoption or one more revision needed? --> Just adopt
    - Stephen: preference for virtual interim meetings or what?
    - Roman: yes, virtual interim
    - Stephen: will you attend or just it's a good idea?
    - Roman: it's a good idea
    - Göran (from Jabber): we progressed a lot today, let's have one in december
    - Jim (from Jabber): let's have one, january or february
    - Stephen: january sounds better
    - Roman: january sounds better
    - Göran (from jabber): let's set a doodle to check if december is possible
    - Ekr: december is not a good option
    - Stephen: let's move on things on the list, let's have an interim in January

- AOB
    - None
    
- meeting ends