Re: [TLS] The PAKE question and PSK

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

  Hi Hannes,

On Wed, April 2, 2014 9:38 am, Hannes Tschofenig wrote:
> Hi Dan,
>
> comments inline.
>
>
> On 04/02/2014 06:38 PM, Dan Harkins 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?
>>
>
> This secret is pre-provisioned by the manufacturer of the device.
> If you buy any IoT device today this is most likely the model they are
> using.

  It's the symmetric equivalent of a manufacturing certificate. This has
its place but that place is not here.

>>> 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.
>
> Nope, this is not necessarily PAKE and the if you, fo rexample, use
> Bluetooth it is not PAKE.

  Bluetooth is not secure. What I am proposing is to use a secure PAKE,
not something insecure.

>>
>>> 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.
>
> + patents on ECC and patents on PAKE to worry about...

  FUD. There are no patents to worry about with TLS-pwd.

>>>  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.
>
> This is the model that many embedded devices use. Look at your embedded
> router, for example. I doubt that someone breaks into your home and then
> has nothing better to do than to read the secret from your home router...

  They wouldn't need to since the protocol that uses that symmetric key
on my home router is horribly broken.

  You keep bringing up broken uses of symmetric keys (bluetooth, WPS) as
alternatives to doing it right. I'm having a hard time understanding what is
motivating you here.

>> 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.
>
> Understand that argument but nothing of it can be found in your draft.

  I didn't think an expansive explanation of use cases was appropriate for
a draft that defines a protocol. I can provide a bit more introductory text
as well as an "applicability statement" if it will help.

  (I am currently rethinking my opinions on use case documents since
people really seem to not understand the motivation for TLS-pwd. I have
done a very poor job on that front).

>>
>>> 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.
>
> Yes.
>
>>
>>> 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.
> Given that this initial exchange happens very infrequently additional
> delay with RSA does not matter that much (+ you don't have to worry
> about the IPRs).

  EKE doesn't do RSA. And, as Nico pointed out, observing a single exchange
can eliminate a large majority of the potential passwords. Even an infrequent
use can give an adversary a high probability of successfully determining
the secret.

  Again, the IPR issue is FUD.

  regards,

  Dan.