Re: [TLS] The PAKE question and PSK

[Hannes Tschofenig <[e-mail]>]

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.


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

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

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

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


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

Ciao
Hannes

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