Subject: [Cfrg] Future applications of PAKEs

From: Станислав Смышляев <[email-masked]>
Date: Sun, 24 Jul 2016 15:24:45 +0300

Good afternoon, dear colleagues!

We've had a very fruitful discussion with Watson Ladd and have both understood that to continue a productive work on PAKEs in CFRG (not only on SESPAKE and SPAKE2 drafts) it will be better if all of us now decide which PAKEs applications to consider as primary ones for IETF.

The concrete questions that depend on this decision are more specific than the ones considered in the requirements draft (which is quite ready to be followed now)‎ - they are about how the defined protocols are to be integrated. For instance, if we need a PAKE to be ready for integration in some IoT initialization protocol (as we discussed with Hannes Tschofenig) or to be used separately for specific needs as securing channel between a key container and a CSP (as it is used in my company), we have to define a wise key confirmation part and surroundings (like the way of obtaining Q_PW in SESPAKE draft or the final key K' in Watson's SPAKE2 draft). Otherwise, if we primarily think about TLS or IKE, for example, we don't need to define anything except the core key exchange mechanism now - and leave all other important questions like the countermeasures against online password guessing until the future work on a corresponding TLS(/IKE/SSH/etc)-related draft.

Kindest regards,

Stanislav Smyshlyaev

---

From: Robert Moskowitz <[email-masked]>
Date: Fri, 29 Jul 2016 17:59:31 -0400

I have an IoT vendor that has an ECDH KE embedded in their protocol.  
They have asked me to enhance this with a password. Actually I have TWO 
such vendors (different industries so no conflict of interest).  I 
cannot provide details of what they do beyond there is an ECDH KE.

So I need to turn their ECDH KE into a PAKE.

I recognize that this is not directly an IETF problem, but if I point to 
an IETF protocol, they will be more willing to adopt change.

Choices, choices...

I would like to have a draft that provides the differences between the 
various proposed PAKEs.

On 07/24/2016 08:24 AM, Станислав Смышляев wrote:
> We've had a very fruitful discussion with Watson Ladd and have both 
> understood that to continue a productive work on PAKEs in CFRG (not 
> only on SESPAKE and SPAKE2 drafts) it will be better if all of us now 
> decide which PAKEs applications to consider as primary ones for IETF.
>
> The concrete questions that depend on this decision are more specific 
> than the ones considered in the requirements draft (which is quite 
> ready to be followed now)‎ - they are about how the defined protocols 
> are to be integrated. For instance, if we need a PAKE to be ready for 
> integration in some IoT initialization protocol (as we discussed with 
> Hannes Tschofenig) or to be used separately for specific needs as 
> securing channel between a key container and a CSP (as it is used in 
> my company), we have to define a wise key confirmation part and 
> surroundings (like the way of obtaining Q_PW in SESPAKE draft or the 
> final key K' in Watson's SPAKE2 draft). Otherwise, if we primarily 
> think about TLS or IKE, for example, we don't need to define anything 
> except the core key exchange mechanism now - and leave all other 
> important questions like the countermeasures against online password 
> guessing until the future work on a corresponding 
> TLS(/IKE/SSH/etc)-related draft.
>
> Kindest regards,
> Stanislav Smyshlyaev
>
>
>
>
>
>
> _______________________________________________
> Cfrg mailing list
> [email-masked]
> https://www.irtf.org/mailman/listinfo/cfrg

---

From: Watson Ladd <[email-masked]>
Date: Fri, 29 Jul 2016 19:05:31 -0700

On Fri, Jul 29, 2016 at 2:59 PM, Robert Moskowitz
<[email-masked]> wrote:
> I have an IoT vendor that has an ECDH KE embedded in their protocol.  They
> have asked me to enhance this with a password.  Actually I have TWO such
> vendors (different industries so no conflict of interest).  I cannot provide
> details of what they do beyond there is an ECDH KE.
>
> I recognize that this is not directly an IETF problem, but if I point to an
> IETF protocol, they will be more willing to adopt change.
>
> Choices, choices...
>

I'll answer briefly: SESPAKE and SPAKE2 are very similar. SESPAKE is a
symmetric variation with an explicit key confirmation step. The SPAKE2
draft was meant for embedding into other protocols easily. Both have
security proofs and are very efficient.

AugPAKE shouldn't be used: the proof is wrong. JPAKE is wildly inefficient.

> understood that to continue a productive work on PAKEs in CFRG (not only on
> SESPAKE and SPAKE2 drafts) it will be better if all of us now decide which
> PAKEs applications to consider as primary ones for IETF.
>
> The concrete questions that depend on this decision are more specific than
> the ones considered in the requirements draft (which is quite ready to be
> followed now)‎ - they are about how the defined protocols are to be
> integrated. For instance, if we need a PAKE to be ready for integration in
> some IoT initialization protocol (as we discussed with Hannes Tschofenig) or
> to be used separately for specific needs as securing channel between a key
> container and a CSP (as it is used in my company), we have to define a wise
> key confirmation part and surroundings (like the way of obtaining Q_PW in
> SESPAKE draft or the final key K' in Watson's SPAKE2 draft). Otherwise, if
> we primarily think about TLS or IKE, for example, we don't need to define
> anything except the core key exchange mechanism now - and leave all other
> guessing until the future work on a corresponding TLS(/IKE/SSH/etc)-related
> draft.
>
> Kindest regards,
> Stanislav Smyshlyaev
>
>
>
>
>
>

-- 
"Man is born free, but everywhere he is in chains".
--Rousseau.

---

From: Peter Gutmann <[email-masked]>
Date: Sat, 30 Jul 2016 07:01:22 +0000

Robert Moskowitz <[email-masked]> writes:

>have asked me to enhance this with a password.

RFC 5489?

(Or have they invented their own transport-level encryption?).

Peter.

---

From: Robert Moskowitz <[email-masked]>
Date: Sun, 31 Jul 2016 09:40:48 -0400

> (Or have they invented their own transport-level encryption?).

Well they are protocols directly on the MAC.  No IP, no TCP, and no 
TLS.  Not even EAPOL (IEEE 802.1X) (one is on the PHY, 'we don't need no 
stinking MAC to eat up our bandwidth').

That said, they did not even strip out the usable portion of 5489.

 From Watson's common, I am going to look seriously at SPAKE2 to see how 
it fits.  The less I change what they are doing, the better the 
likelihood of advancing.