Subject: [TLS] Working Group Last Call for draft-ietf-tls-pwd

From: "Joseph Salowey (jsalowey)" <[email-masked]>
Date: Fri, 8 Nov 2013 01:11:39 +0000

This is the beginning of the working group last call for  draft-ietf-tls-pwd-01.   The underlying cryptographic protocol for TLS-PWD has been reviewed by the IRTF CFRG group with satisfactory results.  The document needs particular attention paid to the integration of this mechanism into the TLS protocol.   Please send comments to the TLS list by December 2, 2013.  

- Joe
(For the TLS chairs)

---

From: Douglas Stebila <[email-masked]>
Date: Fri, 8 Nov 2013 16:50:28 +1000

I believe that where possible the IETF should aim to standardize cryptographic protocols that have provable security results.  Such proofs of course don't guarantee the protocol is secure in all scenarios, but at least rule out some classes of attacks.  In the field of password authenticated key exchange, there are many provably secure protocols, and so it would be preferable to see one such protocol adopted.

Douglas

On Nov 8, 2013, at 2:11 AM, Joseph Salowey (jsalowey) <[email-masked]> wrote:

> _______________________________________________
> TLS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tls

---

From: "Blumenthal, Uri - 0558 - MITLL" <[email-masked]>
Date: Fri, 8 Nov 2013 11:35:16 -0500

On 11/8/13 1:50 , "Douglas Stebila" <[email-masked]> wrote:

>I believe that where possible the IETF should aim to standardize
>cryptographic protocols that have provable security results.  Such proofs
>of course don't guarantee the protocol is secure in all scenarios, but at
>least rule out some classes of attacks.  In the field of password
>authenticated key exchange, there are many provably secure protocols, and
>so it would be preferable to see one such protocol adopted.

I concur - except I believe that whenever possible the IETF should aim to
standardize cryptographic protocols that are unencumbered by license fees
and patents. If the choice arises between a protocol that carries both
(provable security and Intellectual Property) and a protocol that has
neither - I'd strongly prefer the latter.

>> This is the beginning of the working group last call for
>>draft-ietf-tls-pwd-01.   The underlying cryptographic protocol for
>>TLS-PWD has been reviewed by the IRTF CFRG group with satisfactory
>>results.  The document needs particular attention paid to the
>>integration of this mechanism into the TLS protocol.   Please send
>>comments to the TLS list by December 2, 2013.
>> 
>> - Joe
>> (For the TLS chairs)

---

From: SeongHan Shin <[email-masked]>
Date: Sat, 9 Nov 2013 02:03:51 +0900

FYI,
AugPAKE is provably secure and can be used royal-free.
AugPAKE
https://tools.ietf.org/html/draft-shin-tls-augpake-01
IPR Disclosures
https://datatracker.ietf.org/ipr/2037/

Regards,
Shin

-- 
------------------------------------------------------------------
SeongHan Shin
Research Institute for Secure Systems (RISEC),
National Institute of Advanced Industrial Science and Technology (AIST),
Central 2, 1-1-1, Umezono, Tsukuba City, Ibaraki 305-8568 Japan
Tel : +81-29-861-2670/5284
Fax : +81-29-861-5285
E-mail : [email-masked]
------------------------------------------------------------------

---

From: Love Hörnquist Åstrand <[email-masked]>
Date: Mon, 11 Nov 2013 11:52:55 +0100

[resend now that i’m subscribed to the mailinglist]

AugPAKE is not defined for ECC, the draft just say that is possible to implement but not how. For example, is it safe for all kind of curves ?

AugPAKE have not test vectors in the draft. (very important because of the next point).

AugPAKE have no reference implementation that I’ve found.

I have not seen a review of AugPAKE by IRTF CFRG.

AugPAKE is currently encumbered by IPR issues for all protocols.

Love

8 nov 2013 kl. 18:03 skrev SeongHan Shin <[email-masked]>:

> On Sat, Nov 9, 2013 at 1:35 AM, Blumenthal, Uri - 0558 - MITLL <[email-masked]> wrote:

---

From: Love Hörnquist Åstrand <[email-masked]>
Date: Mon, 11 Nov 2013 11:53:53 +0100

No test vectors so hard to verify that implementation will have a chance to interoperate.

Love

---

From: "Dan Harkins" <[email-masked]>
Date: Mon, 11 Nov 2013 06:19:55 -0800 (PST)

Hi Love,

> No test vectors so hard to verify that implementation will have a chance

  Good comment. I will add test vectors showing a sample exchange in
an appendix of the next version. Speaking of interoperability, I have an
implementation and can put a server up on a globally-routable IP
address if anyone wants to try to interoperate, just let me know.

  thanks,

  Dan.

---

From: Love Hörnquist Åstrand <[email-masked]>
Date: Mon, 11 Nov 2013 11:48:07 +0100

Love

---

From: SeongHan Shin <[email-masked]>
Date: Tue, 12 Nov 2013 11:14:25 +0900

Hi Love,

Thank you for your comments!

>AugPAKE is not defined for ECC, the draft just say that is possible to
implement but not how. For example, is it safe for all kind of curves ?
The ECC part will be added to the next version of our I-D.

>AugPAKE have no reference implementation that I’ve found.
We already implemented AugPAKE and the test vectors also will be added to
the next version of our I-D.
If you want to test interoperability, just let me know. :)

>I have not seen a review of AugPAKE by IRTF CFRG.
We already submitted the I-D to the CFRG. We hope to see reviews from the
CFRG soon.
http://tools.ietf.org/html/draft-irtf-cfrg-augpake-00
For security proof. please refer to the below IACR eprint archive.
https://eprint.iacr.org/2010/334.pdf

>AugPAKE is currently encumbered by IPR issues for all protocols.
What does it mean?
The patent of AugPAKE was granted in Feb. and April of 2013 from Japan and
U.S. respectively.
As in IPR Disclosures, AugPAKE can be used royal-free for any conforming
implementations.
https://datatracker.ietf.org/ipr/2037/

Best regards,
Shin

On Mon, Nov 11, 2013 at 7:52 PM, Love Hörnquist Åstrand <[email-masked]> wrote:

> AugPAKE is not defined for ECC, the draft just say that is possible to
> implement but not how. For example, is it safe for all kind of curves ?
>

---

From: Ralf Skyper Kaiser <[email-masked]>
Date: Tue, 12 Nov 2013 10:28:16 +0000

Hi,

could not find it in the draft:

the interoperability with draft-ietf-websec-key-pinning-08 should be
mentioned explicitly to prevent
an attack scenario. (e.g. user has pinned certificate for google.com.
Attacker MITM forces
client to do tls-pwd. Client should not allow this). E.g. once a host is
pinned no other server-side
auth mechanism should be allowed.

regards,

ralf

On Fri, Nov 8, 2013 at 1:11 AM, Joseph Salowey (jsalowey) <
[email-masked]> wrote:

>  draft-ietf-tls-pwd-01.   The underlying cryptographic protocol for TLS-PWD
> has been reviewed by the IRTF CFRG group with satisfactory results.  The
> document needs particular attention paid to the integration of this
> mechanism into the TLS protocol.   Please send comments to the TLS list by
> December 2, 2013.
>
> - Joe
> (For the TLS chairs)

---

From: "Dan Harkins" <[email-masked]>
Date: Mon, 18 Nov 2013 13:51:28 -0800 (PST)

Hi Ralf,

> auth mechanism should be allowed.

  If the client doesn't want to do TLS-pwd then it won't include the
mandatory extension in its client hello and it won't include any TLS-pwd
ciphersuites. I don't see how this attack happens.

  Perhaps the necessary requirements to deal with pinning certificates
for websec should be dealt with in the draft you mention.

  regards,

  Dan.

---

From: Ralf Skyper Kaiser <[email-masked]>
Date: Tue, 19 Nov 2013 10:15:34 +0000

Hi Dan,

The security risk lies within the implementation.

The capable client will always offer TLS-PWD.

Simplified, this is how pinning will be implemented: The client receives
the server's certificate. The client checks if the server's certificate (or
better the SPKI) is already known to the client (e.g. pinned) and if the
server's certificate is different to the pinned certificate then the
connection fails.

The draft assumes that certificate based server authentication is the only
authentication that exists.

The draft does not discuss the scenario where TLS-PWD is used.

In such a case I'm concerned that the part of the client source code that
checks for pinning is not triggered and by-passed. The client goes into the
TLS-PWD mode.

Instead what should be pinned is the SPKI _and_ that certificate based
server-authentication must be used. E.g. once a client has pinned a
certificate for a host it should not allow TLS-PWD.

This is obvious to us but not obvious to the developer and should be
explicitly mentioned.

(It could be mentioned in websec-rfc as you say but that's beyond draft
status and additions are no longer practical). Mentioning it in the TLS-PWD
draft will hopefully prevent an insecure implementation.

regards,

Ralf

---

From: <[email-masked]>
Date: Tue, 19 Nov 2013 12:15:13 +0100

May I add that it's not clear which elements are to be presented to the user for visual (or automated) inspection and in which form. I can handle long random string for visual inspection, but I wonder if this is to be expected from all users. If I've understood the spec correctly the fingerprint of the public key and the domain names, i.e. the subject alt names, are to be presented to the user. This could turn out to be quite a bit of data per certificate.

Also, if the fingerprint is tied to public key exclusively I wonder what the UAs are expected to do when subject alt names have changed in the certificates when the public key is preserved.

Oscar Koeroo
Red Team / Ethical Hacker
Chief Information Security Office
KPN
Tel: +31 6 1217 5278
Fingerprint: 3D5F 5BA5 AF84 BBE1 3D60 8621 0DCD 74C3 A211 B654

Van: TLS [mailto:[email-masked]] Namens Ralf Skyper Kaiser
Verzonden: dinsdag 19 november 2013 11:16
Aan: Dan Harkins
CC: [email-masked]
Onderwerp: Re: [TLS] Working Group Last Call for draft-ietf-tls-pwd

Hi Dan,

Simplified, this is how pinning will be implemented: The client receives the server's certificate. The client checks if the server's certificate (or better the SPKI) is already known to the client (e.g. pinned) and if the server's certificate is different to the pinned certificate then the connection fails.
The draft assumes that certificate based server authentication is the only authentication that exists.
The draft does not discuss the scenario where TLS-PWD is used.
In such a case I'm concerned that the part of the client source code that checks for pinning is not triggered and by-passed. The client goes into the TLS-PWD mode.

Instead what should be pinned is the SPKI _and_ that certificate based server-authentication must be used. E.g. once a client has pinned a certificate for a host it should not allow TLS-PWD.
This is obvious to us but not obvious to the developer and should be explicitly mentioned.
(It could be mentioned in websec-rfc as you say but that's beyond draft status and additions are no longer practical). Mentioning it in the TLS-PWD draft will hopefully prevent an insecure implementation.

regards,

Ralf

  Hi Ralf,

  regards,

  Dan.

---

From: Bodo Moeller <[email-masked]>
Date: Tue, 19 Nov 2013 12:38:29 +0100

2013/11/8 Douglas Stebila <[email-masked]>

> so it would be preferable to see one such protocol adopted.

Right.  So there's already an RFC for using SRP in TLS, but it's
Informational.  Many other such protocols can be found in the research
literature (and, sometimes, in Internet-Drafts).  If we're picking a
password-based key exchange for Standards Track, why this one?  What are
the advantages of this specific protocol over the others?

>From a brief look, one drawback of draft-ietf-tls-pwd-01 besides lack of
formal security arguments appears to be that it's presumably less efficient
than some other such protocols ("hunt-and-peck" loop).

Bodo

---

From: "Dan Harkins" <[email-masked]>
Date: Tue, 19 Nov 2013 07:31:10 -0800 (PST)

Hi Ralf,

> The capable client will always offer TLS-PWD.

  Unless it is expressly told not to because of some external event,
like pinning of a certificate for websec.

> draft will hopefully prevent an insecure implementation.

  It's a draft. The tracker does not indicate that it has passed IETF LC.
Make the comment. It's the right place to do so. If you want this
event to take precedence then expressly say so in the document
that defines the event.

  regards,

  Dan.

---

From: "Dan Harkins" <[email-masked]>
Date: Tue, 19 Nov 2013 07:33:35 -0800 (PST)

Hi Oscar,

On Tue, November 19, 2013 3:15 am, [email-masked] wrote:
> May I add that it's not clear which elements are to be presented to the
> user for visual (or automated) inspection and in which form. I can handle
> long random string for visual inspection, but I wonder if this is to be
> expected from all users. If I've understood the spec correctly the
> fingerprint of the public key and the domain names, i.e. the subject alt
> names, are to be presented to the user. This could turn out to be quite a
> bit of data per certificate.
>
> Also, if the fingerprint is tied to public key exclusively I wonder what
> the UAs are expected to do when subject alt names have changed in the
> certificates when the public key is preserved.

  Very interesting questions... for the web sec WG; this is TLS. And this
is a thread dealing with a draft that does certificate-less authentication.

  regards,

  Dan.

> the server's certificate. The client checks if the server's certificate
> (or better the SPKI) is already known to the client (e.g. pinned) and if
> the server's certificate is different to the pinned certificate then the
> connection fails.
> checks for pinning is not triggered and by-passed. The client goes into
> the TLS-PWD mode.
>
> status and additions are no longer practical). Mentioning it in the
> TLS-PWD draft will hopefully prevent an insecure implementation.
>
> regards,
>
> Ralf
>
>

---

From: "Dan Harkins" <[email-masked]>
Date: Sat, 23 Nov 2013 16:18:34 -0800 (PST)

Hello,

  I just uploaded -02 of this draft. The only difference is the addition
of an example exchange in an appendix. I thought it would be useful
for evaluation of the exchange as defined in the draft so I elected to
put out this -02 before WGLC closes.

  The exchange uses private use ciphersuites because IANA has not
yet assigned numbers for the TLS-pwd ciphersuites. It negotiates
a private version of TLS_ECCPWD_WITH_AES_128_GCM_SHA25 and
uses the brainpool P256 elliptic curve.

  Please take a look. Regards,

  Dan.

---

From: Bodo Moeller <[email-masked]>
Date: Wed, 27 Nov 2013 18:09:28 +0100

2013/11/19 Bodo Moeller <[email-masked]>

> than some other such protocols ("hunt-and-peck" loop).

Besides the *general* security concerns about this protocol (cursory review
by CFRG doesn't make up for a lack of formal security arguments), here's a
*specific* concern.  (This should be considered "pars pro toto": for all we
know, the protocol could have countless other problems, as isn't uncommon
for cryptographic protocols not justified by format security arguments.)

Given how draft-ietf-tls-pwd-02 specifies negotiation of domain parameters,
I think that a trapdoor-prime attack similar to the one I previously
described for SRP applies (
https://groups.google.com/forum/#!msg/sci.crypt/JMcCA6FhTDk/e3BKt-CnvQkJ).
 It makes more sense to standardize domain parameters (allowing a selection
of "named groups").  Full flexibility sounds nice at first, until you
realize that it couldn't only be used by legitimate protocol participants
to select groups that they might deem more secure than whatever is
specified, but could also used by an attacker to select particularly bad
groups (in particular if the scenario doesn't provide for any
authentication other than the password-based authentication the protocol is
meant to provide).

Bodo

---

From: "Dan Harkins" <[email-masked]>
Date: Wed, 27 Nov 2013 14:21:06 -0800 (PST)

Hi Bodo,

On Wed, November 27, 2013 9:09 am, Bodo Moeller wrote:
> authentication other than the password-based authentication the protocol
> is meant to provide).

  TLS-pwd does allow for a selection of "named groups". If you look at
the example exchange in appendix A of -02 you'll see that that is how
an elliptic curve is agreed upon (a whole slew of named curves are offered
by the client in the ClientHello and they end up using brainpoolP256r1:
curve_id = 26).

  That said, the issue you bring up remains since it is also possible to
just send the complete domain parameter set. But this is how TLS handles
discrete logarithm-style cryptographic parameter negotiation. So this
issue applies to every TLS cipher suite that provides for some kind of
exchange using discrete logarithm cryptography, including all of the
ones with DH in the key exchange-- i.e. DHE, ECDH, ECDHE, etc. This
"full flexibility" issue sounds more like something for TLSv1.3  than for
TLS-pwd.

  regards,

  Dan.

---

From: Bodo Moeller <[email-masked]>
Date: Wed, 27 Nov 2013 23:31:38 +0100

> "full flexibility" issue sounds more like something for TLSv1.3  than for

While parameter negotiation does look like that for TLS DHE ciphersuites,
that's actually a very different issue, because there these groups are used
differently: either parameters are authenticated (signed by the server's
public key from the server cert) or the server is entirely anonymous.  This
is very different from relying on initially unauthenticated parameters for
a password-authenticated key exchange, where the security issues that I
described come up.

Bodo

---

From: "Dan Harkins" <[email-masked]>
Date: Wed, 27 Nov 2013 22:49:05 -0800 (PST)

> a password-authenticated key exchange, where the security issues that I

  I'm not sure how using a cipher suite with an anonymous (i.e.
unauthenticated) server is "very different from relying on initially
unauthenticated parameters" since with an unauthenticated server
the parameters will not only be initially unauthenticated but always
unauthenticated.

  Regardless though, what you said was that TLS-pwd was susceptible to
a "trapdoor prime" attack and you provided a link describing it in regards
to TLS-SRP,  and you described it thusly:

"Not all safe primes are created equal -- a malicious server might
compel the client into performing the SRP protocol where N is a
'trapdoor prime', a prime that has been specifically chosen to make
the computation of discrete logarithms feasible."

And that is not possible with TLS-pwd because the client presents the
set of domain parameter sets and the server picks one. The server does
not dictate the acceptable domain parameter set(s) with TLS-pwd. This
sort of attack where a malicious server forces a client into using a
domain parameter set it did not offer is not really possible. And any
man-in-the-middle that mucked with a ClientHello to force the
exchange into some domain parameter set it wants would be detected
when checking the Finished message and the exchange would fail.

  It's interesting that the fix you suggest for this problem-- "The proper
fix is to allow just a certain fixed (standardized) set of parameters" --
is what TLS-pwd already does.

  Dan.

---

From: Peter Sylvester <[email-masked]>
Date: Thu, 28 Nov 2013 09:07:01 +0100

On 11/27/2013 06:09 PM, Bodo Moeller wrote:

> Given how draft-ietf-tls-pwd-02 specifies negotiation of domain parameters, I think that a 
> trapdoor-prime attack similar to the one I previously described for SRP applies 
> (https://groups.google.com/forum/#!msg/sci.crypt/JMcCA6FhTDk/e3BKt-CnvQkJ 
> <https://groups.google.com/forum/#%21msg/sci.crypt/JMcCA6FhTDk/e3BKt-CnvQkJ>).  It makes more
The server's ability to send arbitrary values for negotiation does not mean that the client blindly 
accepts them.

> sense to standardize domain parameters (allowing a selection of "named groups").
In the SRP code of OpenSSL for example, by default, the client accepts only a few groups, the one's 
from the RFC

  "names"  vs  actual values:
- syntactical sugar
- needs or doesn't some form of registration
- requires more or less data to be transmitted
- ...

One possible name for a value is "value", it is understood without any prerequisites, registration,
avoids name clashes.  the price is 500 octets, another "name" would be the hash of the
parameters, since/if they are known in advance.

> Full flexibility sounds nice at first, until you realize that it couldn't only be used by 
> legitimate protocol participants to select groups that they might deem more secure than whatever 
> is specified, but could also used by an attacker to select particularly bad groups (in particular 
> if the scenario doesn't provide for any authentication other than the password-based 
> authentication the protocol is meant to provide).
you wrote in your comment:
"but the adversary, when sitting in for the server, can send Alice the parameters for any 
well-formed group"

  The client can decide what it accepts as "well-formed".

> Bodo
Peter

---

From: Bodo Moeller <[email-masked]>
Date: Thu, 28 Nov 2013 10:09:32 +0100

Peter Sylvester <[email-masked]>:

The server's ability to send arbitrary values for negotiation does not mean
> that the client blindly accepts them.

> In the SRP code of OpenSSL for example, by default, the client accepts
> only a few groups, the one's from the RFC
>

That works, of course.  The TLS-SRP RFC says that "Because of the
difficulty of checking for [trapdoor] primes in real time, clients SHOULD
only accept group parameters that come from a trusted source, such as those
listed in Appendix A, or parameters configured locally by a trusted
administrator."  (Language added as of draft-ietf-tls-srp-09, after I'd
presented the attack idea.)

draft-ietf-tls-pwd-02 does not appear to have a similar provision.  If
there are no standardized primes that you can rely on for interoperability,
there's the danger that implementations might do what the specification
appears to suggest, which is to do the same checks they'd be doing to
validate parameters for a DH key exchange.  (This is useful as a sanity
check to prevent certain types of severely broken implementations from
getting deployed, but it is not sufficient to protect against malicious
parties.)

Bodo

---

From: Bodo Moeller <[email-masked]>
Date: Thu, 28 Nov 2013 10:00:02 +0100

2013/11/28 Dan Harkins <[email-masked]>

> the parameters will not only be initially unauthenticated but always

Right; in that case you have no hopes of defending against an active
adversay anyway.

> set of domain parameter sets and the server picks one.

What I got from draft-ietf-tls-pwd-02 is that (in the non-EC case) the
server proposes a group in ServerFFPWDParams in the ServerKeyExchange
message, and "Upon receipt of the ServerKeyExchange, the client decides
whether to support the indicated group or not."  Before the server chooses
the group for the ServerKeyExchange, all the client sends is the
ClientHello, which does not seem to allow the client to present a set of
domain parameters.  I may have missed something.

In any case, if the client presents the domain parameters and the server
accepts or rejects, we should have a similar attack the other way around.

> is what TLS-pwd already does.

It doesn't seem that FFC primes are standardized in draft-ietf-tls-pwd-02.
 Am I missing something?

Bodo