* WGs marked with an * asterisk has had at least one new draft made available during the last 5 days

Lake Status Pages

Lightweight Authenticated Key Exchange (Active WG)
Sec Area: Roman Danyliw, Benjamin Kaduk | 2019-Oct-19 —  

IETF-106 lake minutes

Session 2019-11-20 1520-1650: Sophia - Audio stream - lake chatroom


minutes-106-lake-01 minutes

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

Generated from PyHt script /wg/lake/minutes.pyht Latest update: 24 Oct 2012 16:51 GMT -