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

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

Ekr,

Thanks, comments inline.

From: Eric Rescorla <[e-mail]>
Date: Saturday, 28 December 2019 at 18:33
To: Göran Selander <[e-mail]>
Cc: Stephen Farrell <[e-mail]>, "[e-mail]" <[e-mail]>
Subject: Re: [Lake] January lake wg virtual interim webex details

Goran

Thanks for posting this. Some thoughts below.

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

Yes, I think I agree with this, but as soon as you introduce
this much flexibility, we have to ask whether it's negotiable
or whether you just assume that the RP will support whatever
the AP wants to offer. My sense is that negotiable is actually
required in at least some cases, but maybe others feel
differently.


GS: Agree about negotiation. Responder needs to be able to verify which method is being used.


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

Agreed.



> 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

Agreed.


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

It's probably useful to distinguish *messages* from *flights*. I agree
that we want three flights, but it seems clear that for some radio
technologies, it's not possible to get a full signature-based
exchange in three frames, so there needs to be fragmentation
somewhere. The question then becomes where that fragmentation
should happen and whether the AKE should be aware of it. That
seems like a more complicated question, especially with very
small frame sizes.

GS: I didn’t understand the difference. Current terminology is in terms of “messages” (AKE units) and “frames”/”packets” (radio layer units). We want to minimize the number of radio layer units needed, but technology, regulations, configuration, etc. affect the size of the radio layer units. As you say, the AKE message may be fragmented by lower layers, but I don’t think we can require that the AKE layer to be aware or have any control of that. What we can do in design time is to keep the AKE units small and few so that the number of frames/packets are in general few, and optimal when the radio layer so permits. We can use “flight” instead of “message” to describe the AKE unit but I don’t see how that makes a difference. Perhaps I misunderstood?


> 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

Agreed.


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

Hmm.. Maybe. I think this gets back to the question of messages
versus flights. I agree that you want to be able to send application
messages in the same flight as AKE messages, but "within the AKE"
seems too strong, and would violate key separation.

GS: Right, the formulation “within the AKE” is not optimal, we should change that. What is meant is in the same message/flight as the AKE message, i.e. together with the AKE message. Now key separation impacts the message size, so there is a tradeoff to make here. It would be good to list what kind of key separation is actually important. Separation between flights/messages, separation between traffic data and session resumption, they both seems relevant. But it was not clear to us that the attack surface is expanded in any significant way with using a separate key for one flight and the kind of application data we expect to be used in this flight like an access token, authorization voucher, etc.  One interesting comparison is with certificates, would you require a separate key to encrypt the authentication certificate in the AKE?


> 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

Agreed.


> 8. PQC support
>
> There are currently no standardized PQC key exchange algorithms.
>
> Working assumption: PQC is out of scope for this version

Well, sort of. It would be bad if we couldn't easily add PQC,
but I agree we don't need to standardize it now.

GS: I think we agree on this. PQC signatures should be straightforward to add, but less clear what change a PQC key exchange would require. Also, that would probably not be suitable for the most constrained setting.


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

Agreed on the second point. I'm not yet sure if we need internal
anti-reflection mechanisms or just key role sepatation.

GS: The intention with “the AKE need to protect against reflection attacks” was as a high level requirement without go into the solution space. Key role separation is one solution. Can we formulate the requirement better?



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

I'm not sure I understand what this means in practice.

GS: This was an attempt to say that there is a trade-off between extensibility and complexity. Future extensions may have different objectives, but the current version of the protocol must not become heavy just to incorporate a generic extension mechanism. Other formulations are welcome.


> 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

This seems unnecessarily concrete. I tend to think we want to uplevel
the question and ask what the security requirements for the AKE are as
compared to the transport (OSCORE). This pulls in questions of key
separation, strength of the handshake integrity check, etc., but
it's not limited to OSCORE MAC.

GS: This is a good discussion point for the interim. OSCORE needs AEAD, HKDF, Master Secret, Master Salt and Connection IDs. The potential relationship/independence between these and those of the AKE are relevant to document. Was this what you were thinking of?

Göran




On Fri, Dec 20, 2019 at 6:39 AM Göran Selander <goran.selander=[e-mail]<mailto:[e-mail]>> wrote:
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]<mailto:[e-mail]> on behalf of [e-mail]<mailto:[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<https://ietf.webex.com/ietf/j.php?MTID=ma39f9f8ea114844f79e2c962c6efdd52>

    Add to Calendar
    https://ietf..webex.com/ietf/j.php?MTID=m31715fa29e54db30d0d7ce118716a7c0<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]<mailto:[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]<mailto:[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/
    >
    >


--
Lake mailing list
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/lake