Subject: [Cfrg] OPAQUE

From: Watson Ladd <[email-masked]>
Date: Wed, 27 Mar 2019 14:41:04 +0100

Following up on the conversation: OPAQUE can include auxiliary data along
with the private key in the encrypted bundle sent in the first round. This
may be useful for IPsec for instance as you can insert client
configuration data there as well.

This is an advantage that might be interesting.
Sincerely,
Watson

---

From: Dan Harkins <[email-masked]>
Date: Wed, 27 Mar 2019 07:45:47 -0700

But OPAQUE is augmented and that won't work for IPsec. IPsec, well IKE
actually, needs a balanced PAKE because is not client-server, either side
can initiate.

   regards,

   Dan.

On 3/27/19 6:41 AM, Watson Ladd wrote:
> Following up on the conversation: OPAQUE can include auxiliary data 
> along with the private key in the encrypted bundle sent in the first 
> round. This may be useful for IPsec for instance as you can insert 
> client  configuration data there as well.
>
> _______________________________________________
> Cfrg mailing list
> [email-masked]
> https://www.irtf.org/mailman/listinfo/cfrg

---

From: "Valery Smyslov" <[email-masked]>
Date: Wed, 27 Mar 2019 19:31:20 +0300

Hi Dan,

it depends. Don't forget about EAP-based authentication in IKEv2,

that is clearly client-server oriented.

Regards,

Valery.

From: Cfrg <[email-masked]> On Behalf Of Dan Harkins
Sent: Wednesday, March 27, 2019 5:46 PM
To: [email-masked]
Subject: Re: [Cfrg] OPAQUE

  regards,

  Dan.

Following up on the conversation: OPAQUE can include auxiliary data along with the private key in the encrypted bundle sent in the first round. This may be useful for IPsec for instance as you can insert client  configuration data there as well. 

Sincerely,

Watson

_______________________________________________
Cfrg mailing list
[email-masked] <mailto:[email-masked]> 
https://www.irtf.org/mailman/listinfo/cfrg

---

From: Dan Harkins <[email-masked]>
Date: Wed, 27 Mar 2019 16:05:31 -0700

Hi Valery,

> that is clearly client-server oriented.

   That is true but in that case it would be EAP-OPAQUE which
is EAP not IPsec.

   regards,

   Dan.

> Regards,
>
> Valery.
>
> *From:*Cfrg <[email-masked]> *On Behalf Of *Dan Harkins
> *Sent:* Wednesday, March 27, 2019 5:46 PM
> *To:* [email-masked]
> *Subject:* Re: [Cfrg] OPAQUE
>
>
>     Following up on the conversation: OPAQUE can include auxiliary
>     data along with the private key in the encrypted bundle sent in
>     the first round. This may be useful for IPsec for instance as you
>     can insert client  configuration data there as well.
>

---

From: Yoav Nir <[email-masked]>
Date: Thu, 28 Mar 2019 06:19:21 +0100

> On 28 Mar 2019, at 0:05, Dan Harkins <[email-masked]> wrote:
> 
>  
>  Hi Valery,
> 

It could be.  But if we’re able to handle user-chosen passwords well in regular IKEv2, I’d rather not ever bother with embedding EAP in IKEv2.

I think the chances of having strong PSKs in gateway-to-gateway or server-to-server scenarios are far better than the chances of having strong PSKs or passwords for remote access VPNs.  We’re even writing a document to automate that in I2NSF.

So ISTM that IKEv2 should handle both cases with a PAKE, and maybe that means we need both an augmented PAKE and a balanced PAKE. If forced to choose just one, I’d rather solve the problem of weak passwords and use an augmented PAKE.

Yoav