Re: [TLS] The PAKE question and PSK

Hannes Tschofenig <hannes.tschofenig@gmx.net> Wed, 02 April 2014 07:31 UTC

Return-Path: <hannes.tschofenig@gmx.net>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 30A291A00CF for <tls@ietfa.amsl.com>; Wed, 2 Apr 2014 00:31:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.91
X-Spam-Level:
X-Spam-Status: No, score=-3.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, GB_I_LETTER=-2, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7yU80dood7JB for <tls@ietfa.amsl.com>; Wed, 2 Apr 2014 00:31:26 -0700 (PDT)
Received: from mout.gmx.net (mout.gmx.net [212.227.15.18]) by ietfa.amsl.com (Postfix) with ESMTP id B3CA61A001B for <tls@ietf.org>; Wed, 2 Apr 2014 00:31:25 -0700 (PDT)
Received: from [192.168.131.137] ([80.92.119.215]) by mail.gmx.com (mrgmx101) with ESMTPSA (Nemesis) id 0M9wrU-1WKD1z2XJQ-00B3MG; Wed, 02 Apr 2014 09:31:19 +0200
Message-ID: <533BBC3C.6000704@gmx.net>
Date: Wed, 02 Apr 2014 09:29:00 +0200
From: Hannes Tschofenig <hannes.tschofenig@gmx.net>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0
MIME-Version: 1.0
To: Watson Ladd <watsonbladd@gmail.com>, Dan Harkins <dharkins@lounge.org>
References: <CACsn0cnBXvjo4cCN8htKvmakzhneqq4nXN9WfPdgkqjgBTNpGA@mail.gmail.com>
In-Reply-To: <CACsn0cnBXvjo4cCN8htKvmakzhneqq4nXN9WfPdgkqjgBTNpGA@mail.gmail.com>
X-Enigmail-Version: 1.5.2
Content-Type: multipart/signed; micalg="pgp-sha512"; protocol="application/pgp-signature"; boundary="choMUv1WQK00xso4FKhcfHvGxc275Dije"
X-Provags-ID: V03:K0:AE+RtDtc5Nl7mnXFzXAW4FlISi9KfaY5U0v5qTLHkqkGQ/zUNHY 4yNDXKtOCvww7yhaCunWtrUSBM3rejdBsjmO9tG+95zkotQTEo5PwgbXRVg4PFKG2JcWrE8 RCDCdjQXAiCzOKGfZ3KpeudNM2gj0Zv2aoECOkwApYsef25J8TTaylIZhGYXc7QGdWuDvqx 5jeeVSQd37CSeMsxCN6mg==
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/6IbmZy2PB4bL71I3U0_JKhIUdiA
Cc: "tls@ietf.org" <tls@ietf.org>
Subject: Re: [TLS] The PAKE question and PSK
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <tls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tls>, <mailto:tls-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/tls/>
List-Post: <mailto:tls@ietf.org>
List-Help: <mailto:tls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 02 Apr 2014 07:31:30 -0000

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.

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

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

 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.

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

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.

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
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>