Skip to main content

Minutes IETF106: lake
minutes-106-lake-01

Meeting Minutes Lightweight Authenticated Key Exchange (lake) WG
Date and time 2019-11-20 07:20
Title Minutes IETF106: lake
State Active
Other versions plain text
Last updated 2019-12-04

minutes-106-lake-01
# 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