Re: [TLS] The PAKE question and PSK

["Dan Harkins" <[e-mail]>]

  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?

> 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.

  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
>>
>
>