Subject: [TLS] JPAKE

From: "Salz, Rich" <[email-masked]>
Date: Mon, 8 Feb 2016 18:36:43 +0000

Is anyone else using JPAKE?  I found old I-D, but my search-engine-skillz must be atrophied as I can't find any final RFC on it.

It's currently "experimental" code in OpenSSL and we might drop it in the next release.

--
Senior Architect, Akamai Technologies
IM: [email-masked] Twitter: RichSalz

---

From: Paul Duffy <[email-masked]>
Date: Mon, 8 Feb 2016 13:54:54 -0500

I believe Thread Group is using JPAKE?

http://threadgroup.org/Portals/0/documents/whitepapers/Thread%20Commissioning%20white%20paper_v2_public.pdf

Best that one of the Threaders confirm

Cheers

On 2/8/2016 1:36 PM, Salz, Rich wrote:
>
> Is anyone else using JPAKE?  I found old I-D, but my 
> search-engine-skillz must be atrophied as I can’t find any final RFC 
> on it.
>
> It’s currently “experimental” code in OpenSSL and we might drop it in 
> the next release.
>
> -- 
>
> _______________________________________________
> TLS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tls

---

From: "Salz, Rich" <[email-masked]>
Date: Mon, 8 Feb 2016 19:29:35 +0000

> http://threadgroup.org/Portals/0/documents/whitepapers/Thread%20Commissioning%20white%20paper_v2_public.pdf

Thanks.  A quick skim shows it's some variant/combo of jpake-like and EC (NISTP256) .  But hopefully they'll speak up here.

---

From: Benjamin Kaduk <[email-masked]>
Date: Mon, 8 Feb 2016 13:33:59 -0600

> search-engine-skillz must be atrophied as I can’t find any final RFC

JPAKE was mentioned as an option in kitten's discussions of adding PAKE
preauthentication mechanisms to kerberos, but the current
draft-mccallum-kitten-krb-spake-preauth is (as the title would imply)
using spake and not jpake.  I'd have to dig into the archives to
remember why we decided that spake was better, though.

-Ben

---

From: Robert Cragie <[email-masked]>
Date: Tue, 9 Feb 2016 12:05:36 +0000

I can confirm the Thread Group is using an EC variant of JPAKE, which we
have been using in interop tests for over a year now. I have had a short
presentation ready to give to TLS WG for some time but I was told it
wouldn't receive much interest because it is based on TLS 1.2 and the
current focus is very much on 1.3. The aim is to get an informational RFC
out shortly.

Robert

On 8 February 2016 at 19:29, Salz, Rich <[email-masked]> wrote:

> Thanks.  A quick skim shows it's some variant/combo of jpake-like and EC
> (NISTP256) .  But hopefully they'll speak up here.
>

---

From: Brian Smith <[email-masked]>
Date: Mon, 15 Feb 2016 09:02:29 -1000

Robert Cragie <[email-masked]> wrote:

> I was told it wouldn't receive much interest because it is based on TLS
> 1.2 and the current focus is very much on 1.3. The aim is to get an
> informational RFC out shortly.
>

I'm looking forward to the RFC and I would be happy to offer feedback on it
before or after the first public draft is published.

BTW, if someone tells you something won't receive much interest, it doesn't
mean it won't receive much interest. It more likely means *they* don't want
it to receive much interest. I think you might be surprised how much
interest there actually is.

Cheers,
Brian

---

From: Watson Ladd <[email-masked]>
Date: Mon, 15 Feb 2016 11:54:14 -0800

>
>
> I'm looking forward to the RFC and I would be happy to offer feedback on
it before or after the first public draft is published.
>
> BTW, if someone tells you something won't receive much interest, it
doesn't mean it won't receive much interest. It more likely means *they*
don't want it to receive much interest. I think you might be surprised how
much interest there actually is.

At the time this work was being done JPAKE had a rather sorry excuse for a
security proof. It's only recently that a solid one has been created. At
the same time SRP did not receive much usage when included in OpenSSL, and
with an RFC describing it. PAKE in SSL has always been a solution in search
of a problem.

---

From: Tony Arcieri <[email-masked]>
Date: Mon, 15 Feb 2016 14:32:14 -0800

On Mon, Feb 15, 2016 at 11:54 AM, Watson Ladd <[email-masked]> wrote:

> PAKE in SSL has always been a solution in search of a problem.
>
Browsers do not have UI elements compatible with PAKE (unless someone cares
to bring up the basic auth dialog, in which case I'd simply suggest please
don't)

Brian Warner's "Magic Wormhole" use case seems like something of a killer
app for PAKE, but that's clearly a non-SSL context.

PAKE in SSL seems to be in need of new browser standards which are probably
unlikely to happen. I think "passwordless" standards like FIDO UAF/U2F
which offer a better user experience are far more likely to see browser
support.

---

From: Robert Cragie <[email-masked]>
Date: Tue, 16 Feb 2016 00:33:56 +0000

The big assumption here is that SSL/TLS is used solely in browsers. That is
not how it is being used in Thread, for example, and indeed in other
similar technologies. In Thread, it is used for local device authentication
and authorisation. These use cases clearly benefit from a PAKE, i.e.
getting deriving a shared cryptographic from a weaker shared password.

Robert

On 15 February 2016 at 22:32, Tony Arcieri <[email-masked]> wrote:

> Browsers do not have UI elements compatible with PAKE (unless someone
> cares to bring up the basic auth dialog, in which case I'd simply suggest
> please don't)
>
> PAKE in SSL seems to be in need of new browser standards which are
> probably unlikely to happen. I think "passwordless" standards like FIDO
> UAF/U2F which offer a better user experience are far more likely to see
> browser support.
>

---

From: Tony Arcieri <[email-masked]>
Date: Mon, 15 Feb 2016 16:39:06 -0800

On Mon, Feb 15, 2016 at 4:33 PM, Robert Cragie <[email-masked]>
wrote:

> The big assumption here is that SSL/TLS is used solely in browsers.
>

In literally every one of the non-browser SSL/TLS contexts I use today, I
do not use passwords (preferring client certs instead). The main place I'd
actually be interested in using a PAKE in a generalized transport context
would be an IPSEC/IKE context (in addition to a client cert as a second
factor).

-- 
Tony Arcieri

---

From: "Salz, Rich" <[email-masked]>
Date: Tue, 16 Feb 2016 21:25:56 +0000

> PAKE in SSL has always been a solution in search of a problem.

I kinda agree with this.

---

From: Watson Ladd <[email-masked]>
Date: Tue, 16 Feb 2016 20:05:41 -0800

On Feb 15, 2016 4:33 PM, "Robert Cragie" <[email-masked]>
wrote:
>
> The big assumption here is that SSL/TLS is used solely in browsers. That
is not how it is being used in Thread, for example, and indeed in other
similar technologies. In Thread, it is used for local device authentication
and authorisation. These use cases clearly benefit from a PAKE, i.e.
getting deriving a shared cryptographic from a weaker shared password.

There is no reason not to use keys here and present short fingerprints to
users, unless I am missing something.

>>
>> Brian Warner's "Magic Wormhole" use case seems like something of a
killer app for PAKE, but that's clearly a non-SSL context.

---

From: Tony Arcieri <[email-masked]>
Date: Tue, 16 Feb 2016 20:34:37 -0800

On Mon, Feb 15, 2016 at 4:33 PM, Robert Cragie <[email-masked]>
wrote:

> In Thread, it is used for local device authentication and authorisation.
> These use cases clearly benefit from a PAKE, i.e. getting deriving a shared
> cryptographic from a weaker shared password.
>

The better way to solve this problem is a device-specific "keychain", which
possibly loops in some sort of secure enclave for decrypting secrets, and
can authorize secret decryption based on the requesting app, derive a
strong master secret from a weak password/pin (possibly using a PUF for
anti-tamper). This is becoming a standard feature of the OSes on most
devices humans actually physically interact with, e.g. most smartphones,
tablets, and any OS you'd find on a laptop.

If you have this sort of keychain system, you can provision secrets
on-the-fly, e.g. origin-bound certificates. Now you don't need PAKE.

---

From: "Dan Harkins" <[email-masked]>
Date: Tue, 16 Feb 2016 22:45:23 -0800 (PST)

> tablets, and any OS you'd find on a laptop.

  What?!? How is that "better"? Having a "keychain" that loops in some
vague "secure enclave" that makes authorization decisions based on some
app deriving a "strong master secret from a weak password/pin" sounds
complicated, has more moving parts and more possibility of things
going wrong. If there's some password/pin involved then the protocol
should not depend on whether it's weak or not. Period. That means PAKE.

  Regarding JPAKE, it's support in OpenSSL is in the apps directory,
not the ssl directory. That is, there is no TLS ciphersuite that
supports it and that means no app can use it (except through system()
calls or some such ugliness). TLS-pwd is defined as a TLS ciphersuite
though.

  Dan.

---

From: Tony Arcieri <[email-masked]>
Date: Tue, 16 Feb 2016 22:52:17 -0800

On Tue, Feb 16, 2016 at 10:45 PM, Dan Harkins <[email-masked]> wrote:

> complicated

Microsoft:
https://technet.microsoft.com/en-us/library/mt621546(v=vs.85).aspx
Matt Green: https://twitter.com/matthew_d_green/status/699777680728842240
Apple: https://www.apple.com/business/docs/iOS_Security_Guide.pdf (see
also: Matt Green)

Hardware interlocks around authentication allow various anti-brute force,
exponential backoff, and device wiping security measures. They also allow
you to unlock a "full entropy" cryptographic key with some low entropy
mechanism like a PIN without the former being deterministically derived
from the latter.

I personally believe the future of authentication is having a weak
credential which unlocks a strong credential on something you have. This
approach to authentication is generally described as "something you have
and something you know"

-- 
Tony Arcieri

---

From: Robert Cragie <[email-masked]>
Date: Wed, 17 Feb 2016 22:25:04 +0000

A few points to some of the comments:

1) Thread devices are not typically smartphones and PCs. They are class 1
constrained devices according to RFC7228, i.e. thermostats and light
switches etc.
2) Device certs. and short fingerprints are indeed used in similar systems
to Thread (e.g. ZigBee IP)
3) There is an experimental version of TLS using EC-JPAKE. This will be
written up in an informational RFC as stated
4) Typically the device requiring network access has a burned in passphrase
which is entered into a local commissioning device, establishing a secured
session and high entropy shared secret, which is subsequently used for
delivering network parameters authorising network admission. Any PAKE would
have done really however the decision was made to use EC-JPAKE. This method
may not be appropriate in all scenarios but provides a common, simple
interoperable mechanism for consumer devices.

Robert

---

From: Kurt Roeckx <[email-masked]>
Date: Thu, 18 Feb 2016 16:34:06 +0100

> getting deriving a shared cryptographic from a weaker shared password.

So when looking at things that might use JPAKE, Thread was one of
the things that came up.  But if you then go look, it seems to be
using EC-JPAKE.

Kurt