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

[Eric Rescorla <[e-mail]>]

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.


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


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



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



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


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


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

-Ekr

On Fri, Dec 20, 2019 at 6:39 AM Göran Selander <goran.selander=
[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] 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/
>     >
>     >
>
>
> --
> Lake mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/lake
>