Re: [Lake] Forward Security with PSK-Only LAKE

Yeah, btw, I think it is a minimal requirement to have FS but let’s not call LAKE a secure protocol if it is not gonna provide both FS and PCS for long term sessions...
B.

> On Jan 18, 2020, at 1:38 AM, Eric Rescorla <ekr@rtfm.com> wrote:
> 
> 
> Thanks Karthik.
> 
> Just to sharpen this point: you *do* need a new DH exchange to get PCS, but not to get PFS.
> 
> -Ekr
> 
> 
>> On Fri, Jan 17, 2020 at 2:58 AM Karthik Bhargavan <karthikeyan.bhargavan@inria.fr> wrote:
>> It looks like I over-simplified the protocol.
>> Some clarifications and corrections below.
>> 
>> At the beginning of a session: 
>> A and B have a PSK K, associated with id I, and a session counter C
>> 
>> ---
>> A -> B: m1 = N_A, I, C, other_params
>> B -> A: m2 = N_B, other_params, MAC(K_mB, m1 | m2)
>> A -> B: MAC(K_mA, m1 | m2)
>> A -> B: AEAD(K_eA, msg0,…)
>> B -> A: AEAD(K_eB, msg1,…)
>> ——
>> 
>> At the end of a session:
>> A and B set C <- C + 1, K <- HKDF(K, I, C+1)
>> A and B throw away the old PSK K.
>> 
>> Note:
>> - N_A and N_B are nonces generated by A and B, respectively.
>> - K_mA = HKDF(K, “mac_key A”, m1 | m2)
>> - K_mB = HKDF(K, “mac_key B”, m1 | m2)
>> - K_eA = HKDF(K, “ae_key A”, m1 | m2)
>> - K_eB = HKDF(K, “ae_key B”, m1 | m2)
>> 
>> 
>> 
>> > 
>> > --------
>> > 
>> > The above protocol can be generalized in several ways.
>> > First, A and B need not have exactly the same counter C, instead they could negotiate the MAX of their two counters and derive the PSK corresponding to that counter.
>> > Second, A and B may share both a long-term PSK K0 and an ephemeral PSK K and mix them both together in the protocol above. 
>> > This provides a clean separation between the PSK used for authentication and the PSK used for forward secrecy.
>> > Third, we may use the protocol above as a “fast resumption” mechanism but fall back to full PSK-ECDHE whenever we want.
>> > 
>> > To conclude, I wonder if we should explicitly consider a mechanism like the above as a requirement for LAKE.
>> > It appears to meet the security goals we have set for PSK-LAKE and it is a good example of what can be achieved without an expensive DH operation..
>> > (Incidentally, the message sizes of the protocol above are very tiny.)
>> > 
>> > -Karthik
>> > 
>> > 
>> > 
>> > 
>> > -- 
>> > Lake mailing list
>> > Lake@ietf.org
>> > https://www.ietf.org/mailman/listinfo/lake
>> 
>> -- 
>> Lake mailing list
>> Lake@ietf.org
>> https://www.ietf.org/mailman/listinfo/lake
> -- 
> Lake mailing list
> Lake@ietf.org
> https://www.ietf.org/mailman/listinfo/lake