Re: [Lake] January lake wg virtual interim webex details

[Göran Selander <[e-mail]>]

Hi,

To stimulate further discussion, here are some things that have been discussed and are addressed in latest version of the requirements draft [00].


1. Public key credentials
    
Both public key certificates and raw public keys need to be supported. Certificates are needed for generic zero-touch deployment. Raw public key is a significant message size optimization if the public key is already trusted. Two different public key types have been discussed: public signature keys and static Diffie-Hellmann keys. In the latter case signatures are replaced with MACs leading to a significant reduction of message size. Hence static DH keys are desirable to support.
    
Working assumption: support for signature based and static DH based authentication.


2. Mixed credentials
  
Mixed credentials, one party certificate and the other RPK, are motivated by a use case. Because of 1 we also need to support mixed types of public key credentials.

Working assumption: support for mixed signature and static DH based authentication.

    
    
3. PFS against compromise of which key material?
    
Examples:
    - protection against the loss of long-term keys at the initiator
    - protection against the loss of long-term keys at the responder
    - protection against the loss of ephemeral keys
    - protection against a bad RNG at initiator or responder
    
Working assumptions:
    - Protection against loss of long-term keys at initiator and responder.
    - Protection against bad RNG using randomness improvements such as draft-irtf-cfrg-randomness-improvements and analogously for symmetric keys
    
    
4. Number of round trips/messages and frame sizes
    
Mutual authentication requires at least 3 AKE messages. In radio technologies such as 6TiSCH and LoRaWAN performance is affected by AKE messages fitting into radio frames. The amount of data available for AKE messages is not fixed but depend on radio configuration such as scattering factors, data rates, number of hops etc.

    - The AKE could be spread out over 4 messages of smaller size (compare SIGMA-I and SIGMA-R). In principle, for certain AKE message sizes and radio configuration, the number of radio frames could be smaller with 4 AKE messages instead of 3. In practice, the number of radio frames may be either smaller or larger with 4 AKE messages instead of 3. 

    - With 3 AKE messages, the OSCORE request may be sent together with AKE message 3 resulting in 1 round trip before sending encrypted traffic data. If the AKE has 4 messages, then the protocol is never 1 RTT before traffic data, which increases the time for completing the protocol.
    
    - Experience from IKE shows that 4 messages are preferred for unreliable transport such as UDP. For LAKE, however, we assume transport over CoAP or other reliable transport.
    
Working assumption: The AKE shall have 3 messages.

    
5. Number of round trips/messages and identity protection
    
What identifying information shall be protected against what adversaries? As much as possible of the identifying information should be protected, but protecting all identifying information has impact on the properties, in particular number of messages/round trips.
    
    - Encrypting PSK identity with DH shared secret protects against passive network adversaries, but does not allow authentication of responder within 3 messages
    
    - Encrypting crypto algorithms does not allow negotiation of cipher suite within 3 messages
    
   - Encryption of connection identifier only works in asymmetric case and does not results in arbitrarily short identifiers
    
 Working assumption: The following data need not be encrypted:
    - PSK identifier
    - cipher suite
    - connection identifier
    
    
6. Application data
    
Applications may want to transport application data within the AKE to reduce round trips and number of messages. 

Working assumptions: 
   - The protection properties of the application data provided by the AKE depends on which protocol message (see Section 2.6 of [00])
   - The application data must not violate the AKE security properties. The assumptions on the application data needs to be detailed by the specification.
  
    
    
7. PAKE support
    
LAKE is focused on the setting of low latency, large number of devices, automated deployment, e.g. industrial IoT. The use of passwords has not been requested in this context.
    
Working assumption: PAKEs are out of scope for this version
    
    
8. PQC support 
    
There are currently no standardized PQC key exchange algorithms.
  
Working assumption: PQC is out of scope for this version

    
    
9. Selfie attack
    
The protocol is assumed to be two-party PSK, i.e. need not protect against attacks when more than two parties share keys.

Working assumption: The AKE need to protect against reflection attacks but need not protect against attacks when more than two parties legitimately share keys.


    
10. Extensibility
    
By supporting COSE, the AKE supports new algorithms, new certificate formats, ways to identify credentials, etc. The AKE may need to support new AKE methods, e.g. to later add PAKE support. Since simplicity is one objective with this work, care needs to be taken to avoid extensions working against this.
    

11. Support for different MACs in AKE and OSCORE
    
Longer MAC length for AKE than OSCORE may give better security properties.
    
Working assumption: The AKE shall support different AEAD/MAC algorithms for OSCORE and AKE
    


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




On 2019-12-17, 21:38, "Lake on behalf of Stephen Farrell" <[e-mail] on behalf of [e-mail]> wrote:

    
    Hiya,
    
    Thanks all, I've scheduled meetings for:
    
    - Jan 16th 1600 UTC, and
    - Jan 23rd 1600 UTC.
    
    I've requested 2 hour slots for both but we might
    not need that long, we'll see closer to time.
    
    Webex stuff below.
    
    We can sort out agenda early in Jan and also figure
    out if we only need one of those two meetings as
    well, and which to keep if one's enough. It'd be
    great if people can raise issues on the list (or
    in github and then the list) between now and the
    new year to help with agendising and figuring out
    who really needs to be on the call.
    
    Cheers,
    S.
    
    PS: In case someone wonders: The 23rd has one more
    person who can attend, (10 vs. 11) but I figure it's
    better to schedule both for the moment as chances are
    someone's availability will change between now and
    then in any case;-)
    
    
    LAKE WG invites you to join this Webex meeting.
    
    
    Lake virtual interim
    Occurs every Thursday effective Thursday, January 16, 2020 until
    Thursday, January 23, 2020 from 4:00 PM to 6:00 PM, (UTC+00:00) Dublin,
    Edinburgh, Lisbon, London
    4:00 pm  |  (UTC+00:00) Dublin, Edinburgh, Lisbon, London  |  2 hrs
    Meeting number (access code): 645 835 024
    Meeting password: C4j4PgDJ
    
    
    
    When it's time, join the meeting.
    https://ietf.webex.com/ietf/j.php?MTID=ma39f9f8ea114844f79e2c962c6efdd52
    
    Add to Calendar
    https://ietf.webex.com/ietf/j.php?MTID=m31715fa29e54db30d0d7ce118716a7c0
    
    
    
    
    JOIN BY PHONE
    1-650-479-3208 Call-in toll number (US/Canada)
    Tap here to call (mobile phones only, hosts not supported):
    tel:%2B1-650-479-3208,,*01*645835024%23%23*01*
    1-877-668-4493 Call-in toll free number (US/Canada)
    Tap here to call (mobile phones only, hosts not supported):
    tel:[phone],,*01*645835024%23%23*01*
    
    Global call-in numbers
    https://ietf.webex.com/ietf/globalcallin.php?MTID=mb28c544358b89779e001306dfd4fb04e
    
    Toll-free calling restrictions
    https://www.webex.com/pdf/tollfree_restrictions.pdf
    
    
    JOIN FROM A VIDEO SYSTEM OR APPLICATION
    Dial sip:[e-mail]
    You can also dial 173.243.2.68 and enter your meeting number.
    
    
    Join using Microsoft Lync or Microsoft Skype for Business
    Dial sip:[e-mail]
    
    
    Can't join the meeting?
    https://collaborationhelp.cisco.com/article/WBX000029055
    
    
    
    
    On 16/12/2019 11:46, Stephen Farrell wrote:
    > 
    > Reminder:
    > 
    > On 10/12/2019 21:17, Stephen Farrell wrote:
    >> Please fill in the poll before the end of Dec 16th so we can pick a
    >> time before the holidays.
    > 
    > As of now, [1] it's looking like Thu Jan 16 1600 UTC is winning. If
    > that doesn't change by tomorrow I'll setup a webex thing for then,
    > and maybe a backup one for the same time the following week, in case
    > we run out of time or just like chatting a lot:-)
    > 
    > Cheers, S.
    > 
    > [1] https://dudle.inf.tu-dresden.de/dip-in-the-lake/
    > 
    >