Re: [TLS] The PAKE question and PSK

[Watson Ladd <[e-mail]>]

On Apr 2, 2014 9:39 AM, "Dan Harkins" <[e-mail]> wrote:
>
>
>   Hi Hannes,
>
> On Wed, April 2, 2014 12:29 am, Hannes Tschofenig wrote:
> > Hi Watson,
> >
> > I believe there are several aspects that need to be untangled here:
> >
> > a) Is there a problem where a strong password-based authentication and
> > key exchange protocol can help?
> >
> > b) Since there are various protocol variants available, which one is the
> > best for the job?
> >
> > Item (a) is about use cases and clearly the Web is not the use case.
> > There are use cases documented in
> > http://tools.ietf.org/html/draft-ietf-tls-pwd-04#section-1.1 but I
> > personally don't quite buy them.
> >
> > The constrained device use case is, however, one that I ran into myself
> > as well. It requires a bit more description since constrained device are
> > used in various different ways. There are at least three different cases
> > I have seen:
> >
> > 1) Device talks to the cloud infrastructure. For this case it is not a
> > problem to use long symmetric keys since the is nothing for the user to
> > type.
>
>   From what authenticated source does this long symmetric key come?

The manufacturer.
>
> > 2) Device talks to another device. There are two variants to this:
> >
> >  2a) Pairing / Imprinting
> >
> > Here the pairing protocol typically runs a Diffie-Hellman and then you
> > might have to confirm the initial set-up to avoid MITM attacks (via an
> > out-of-band channel, such as a human entering something).
>
>   The "something" the user enters is a simple, low-entropy, easy-to-enter
> key. That key authenticates a PAKE exchange.
>
> > There are obviously many ways to do this pairing procedures and I am
> > sure you have used many of them already yourself.
> >
> > Ekr provided a good overview for a workshop:
> >
http://www.lix.polytechnique.fr/hipercom/SmartObjectSecurity/papers/EricRescorla.pdf
>
>   And the use of PAKEs is mentioned there. The downside to PAKEs,
according
> to Eric, is use of public key cryptography with a constrained device that
is
> assumed to have limited CPU power. And that's why ECC support in a PAKE
> is so crucial.
>
> >  2b) Key printed on the device itself
> >
> > I believe that this is the case you are talking about where you want to
> > avoid having users enter too many numbers. Today, user's are often only
> > required to scan a QR code instead of entering something but maybe there
> > is something to standardize here.
>
>   Putting a symmetric key in a QR code is a bad idea. Anybody who
> sees the QR code can determine the secret. As Eric said in the paper
> you referred to above, "The primary concern with a secret value system
> is that the value must be kept secret or an attacker can impersonate the
> base station to the device and vice versa." Indeed.
>
>   Putting a public key in a QR code is a much better idea (and, again,
> ECC support is crucial because the x-coordinate of a point on a 256-bit
> curve produces a usable QR code while a 4096-bit RSA key does not-- too
> big, too dense, hard-to-impossible to scan). For many devices, though,
this
> only provides one way authentication (not mutual) because the device that
> scanned the QR code knows definitely it is talking to the device whose QR
> code was scanned, but the device with the QR code has no idea who it is
> communicating with. Using a short, easy-to-enter key with a PAKE
> provides good mutual authentication.
>
>   Also not every constrained device has a camera interface to scan QR
> codes with, while many of them do have some limited UI from which
> the user can enter a short key.
>
> > Regarding item (b) about the protocol choice. Given the use cases
> > previously described I doubt that the "database leaking secrets" is a
> > bit concern here in these environments. The database in most cases
> > contains a single key (or a small number of them).
>
>   Yes, that is correct. A large password database is not envisioned by
> this use case. In fact, as The whole benefit of an augmented PAKE--
> a protected password database-- is not applicable to this use case.
>
> > A few years ago Yaron, Glen, Scott and myself co-authored EAP-EKE (RFC
> > 6124) and we picked EKE because the publications reached their 20 year
> > anniversary.
>
>   I remember it well. I wrote EAP-pwd (dragonfly) and Yaron followed
> with EAP-EKE, I proposed a dragonfly exchange in IKE and Yaron followed
> with an EKE exchange (which was later abandoned).
>
>   One of the problems with EKE is that using it with ECC opens the
> exchange up to a partitioning attack.

Not if you use a uniform representation like Elligator.

>
>   regards,
>
>   Dan.
>
> > Just something to think about.
> >
> > Ciao
> > Hannes
> >
> >
> > On 04/02/2014 06:28 AM, Watson Ladd wrote:
> >> Dear all,
> >>
> >> I'm afraid that several important points and quite a bit of history
> >> has been missing from the recent exchange concerning Dragonfly in TLS.
> >>
> >> Dragonfly is a modified SPEKE. SPEKE was introduced in 2001. SPEKE has
> >> a patent that expires in 2016, and a security proof in the ROM under a
> >> DH style assumption and a reasonable ideal/real attack model.
> >> Dragonfly was created by Dan Harkins, and adopted in IEEE 802.11s to
> >> authenticate nodes in a mesh network. It has no security proof despite
> >> efforts to try and find one.
> >>
> >> The intended usecase is provisioning of constrained devices. While one
> >> could include a 128 bit key on each device and have users type it in
> >> (as they do for Xbox Live and Windows verification: 25 letters and
> >> numbers from a 32 bit alphabet) it was felt that this was a bit much.
> >> PSK will not work with anything that isn't a key, because offline
> >> attack works beautifully. Nico's concerns about key database
> >> compromise, etc, are ignoring the realities of this setting: the
> >> password is the least valuable thing on the device, and since it was
> >> not entered by the user (as the device has no user interaction
> >> capability) unlikely to be reused.
> >>
> >> Dragonfly was presented at IETF 83. AugPAKE was proven secure in 2010.
> >> There is currently a draft for AugPAKE in TLS. Unfortunately AugPAKE
> >> is not specified on ECC groups, but this is easy to fix. (It's also
> >> ugly to shoehorn into TLS, but the draft seems to do it) PAKEs are not
> >> on the agenda because of a rather heated controversy about how
> >> Dragonfly got (seeming) CFRG approval, but there is a good case for
> >> including them. On the web we have more of a problem due to the UI
> >> issues that made client certificates a nonstarter.
> >>
> >> Sincerely,
> >> Watson Ladd
> >>
> >> _______________________________________________
> >> TLS mailing list
> >> [e-mail]
> >> https://www.ietf.org/mailman/listinfo/tls
> >>
> >
> >
>