Subject: [TLS] draft-ietf-tls-tls13-26 is vulnerable to externally set PSK identity enumeration

From: Hubert Kario <[email-masked]>
Date: Mon, 12 Mar 2018 16:27:46 +0100

When the server supports externally set PSKs that use human readable 
identities (or, in general, guessable identities), the current text makes it 
trivial to perform enumeration attack.

The proposed fix was identified as conflicting with the "Client Hello 
Recording" security section, the severity of that conflict wasn't quantified 
though.

Issue in detail:

Problematic paragraph as it stands in draft-ietf-tls-tls13-26 (section 
4.2.11):
   Prior to accepting PSK key establishment, the server MUST validate
   the corresponding binder value (see Section 4.2.11.2 below).  If this
   value is not present or does not validate, the server MUST abort the
   handshake.  Servers SHOULD NOT attempt to validate multiple binders;
   rather they SHOULD select a single PSK and validate solely the binder
   that corresponds to that PSK.  In order to accept PSK key
   establishment, the server sends a "pre_shared_key" extension
   indicating the selected identity.

That means, given a server with both PSK and PKI authentication, if attacker 
sends multiple PSK identities with garbage binders, the server will abort the 
connection if and only if at least one of the identities was recognised by 
server. Applying the well known binary search method allows the attacker to 
then narrow it down to a single identity in O(log_2(n)) steps.

The solution to ignore that one selected binder, and continuing the connection 
in case that binder does not validate (this is the version in the PR mentioned 
below), unfortunately doesn't solve this issue either;

If the attacker is in possession of a known good PSK secret (established 
either through session resumption mechanism or of a less-privileged identity), 
it can list the known good one as the very last one in the PSK extension. If 
server recognises one of the identities earlier in the list it will choose no 
identity (as the binder didn't validate) or the known good identity if none of 
the previous identities were recognised. Again, applying binary search method 
allows the attacker to narrow the list to a single entry in just O(log_2(n)) 
steps.

Proposed solution:

in paragraph above, in description of `binders`:
  binders
  : A series of HMAC values, one for
   each PSK offered in the "pre_shared_keys" extension and in the same
   order, computed as described below. If the number of binders does not match
   number of identities the server MUST abort the connection with
   "illegal_parameter" alert.

problematic paragraph after changes:
   Prior to accepting PSK key establishment, the server MUST validate
   the corresponding binder value (see Section 4.2.11.2 below).  If this
   value does not validate, the server MUST ignore the
   associated identity and retry selection of identity. If no identity is 
   recognised or, for recognised identities, no binder could be validated
   the server MUST continue connection as if PSK key establishment wasn't
   attempted.  In order to accept PSK key
   establishment, the server sends a "pre_shared_key" extension
   indicating the selected identity.

Unfortunately that solution was identified as conflicting with "Client Hello 
Recording" section.

Do we consider that conflict to be severe enough to block this change?

Or should we just add more information to that security section, that it needs 
to deal with this kind of attack?

PS: some discussion on this issue already happened in the github PR: 
https://github.com/tlswg/tls13-spec/pull/1167
-- 
Regards,
Hubert Kario
Senior Quality Engineer, QE BaseOS Security team
Web: www.cz.redhat.com
Red Hat Czech s.r.o., Purkyňova 115, 612 00  Brno, Czech Republic

---

From: Ilari Liusvaara <[email-masked]>
Date: Tue, 13 Mar 2018 17:18:48 +0200

> trivial to perform enumeration attack.

What would be impact of such enumeration attack? It seems to me that
not disclosing identities is to make weak passwords more difficult to
attack, but here there are no weak passwords.

Note that:

- There is no protection for the PSK identity, so putting anything
  sensitive in it is a bad idea.
- The identity can not be used without the associated secret, which
  needs to withstand serious offline cracking attempts anyway.
- Passive attack gives attacker not only a valid PSK identity, but
  enough information to mount high-speed offline cracking attack on the
  PSK secret. Only one captured key exchange is needed, and (EC)DHE
  does not help.

The last point is why PSK secrets need to have enough entropy to resist
high-speed offline cracking.

-Ilari

---

From: Hubert Kario <[email-masked]>
Date: Tue, 13 Mar 2018 18:44:39 +0100

On Tuesday, 13 March 2018 16:18:48 CET Ilari Liusvaara wrote:
> > identities (or, in general, guessable identities), the current text makes
> > it trivial to perform enumeration attack.
> 

the usernames themselves can be confidential information

behaviour like that was considered a vulnerability before, irrespective of 
robustness of passwords:
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2003-0190
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-5229

>   sensitive in it is a bad idea.

the server can be accessible both through Internet and through encrypted 
connections (e.g. IPsec), and while it exposing identities may not lead to an 
exploit, it very likely will make social engineering easier; it is information 
disclosure one way or the other

>   PSK secret. Only one captured key exchange is needed, and (EC)DHE

that does require you to be on-route of a connection and to capture it, that's 
much harder to do than firing up a simple script against any given server with 
PSK enabled.

---

From: Benjamin Kaduk <[email-masked]>
Date: Tue, 13 Mar 2018 21:02:10 -0500

It seems like we get ourselves in trouble by allowing multiple
external PSKs to be present.  If we allowed at most one external
PSK in a given ClientHello, then aborting the handshake on binder
failure would be the correct choice, as discovering a valid identity
would require discovering a valid key/password as well.

Disallowing multiple external PSKs would make migration scenarios a
little more annoying, but perhaps not fatally so.

-Ben(jamin)

---

From: Hubert Kario <[email-masked]>
Date: Wed, 14 Mar 2018 12:46:25 +0100

> would require discovering a valid key/password as well.

but identity/binder may be invalid only because the server was restarted and 
generated a new in-memory key; we don't want to abort connection in such 
situation, continuing to a regular handshake is necessary then for good user 
experience (and likely, even security, given the history of TLS version 
fallbacks)
 
> little more annoying, but perhaps not fatally so.

not only migration, but session resumption and regular PSK at the same time 
too - for session resumption you may not do DH, while for initial handshake 
with PSK you may want to to gain PFS...

so as tempting as the removal of multiple PSKs from ClientHello is, I'm afraid 
the fallout is far too large to do it
-- 
Regards,
Hubert Kario
Senior Quality Engineer, QE BaseOS Security team
Web: www.cz.redhat.com
Red Hat Czech s.r.o., Purkyňova 115, 612 00  Brno, Czech Republic

---

From: Benjamin Kaduk <[email-masked]>
Date: Wed, 14 Mar 2018 15:13:29 -0500

> generated a new in-memory key; we don't want to abort connection in such 

For an external PSK?  That hardly sounds like "external" to me...

> the fallout is far too large to do it

I did not say removal of multiple PSKs, rather removal of multiple
*external* PSKs.

-Ben(jamin)

---

From: Hubert Kario <[email-masked]>
Date: Thu, 15 Mar 2018 12:25:38 +0100

On Wednesday, 14 March 2018 21:13:29 CET Benjamin Kaduk wrote:
> > but identity/binder may be invalid only because the server was restarted
> > and generated a new in-memory key; we don't want to abort connection in
> > such

not my fault that what we called just "PSK"s in TLS 1.2 is now "external PSKs" 
in TLS 1.3... I wanted to be unambiguous, so please, can we discuss the issue, 
not semiotics?

> > situation, continuing to a regular handshake is necessary then for good
> > user experience (and likely, even security, given the history of TLS
> > version fallbacks)
> > 
> > so as tempting as the removal of multiple PSKs from ClientHello is, I'm
> > afraid the fallout is far too large to do it
> 

we do not have a reliable mechanism of differentiating between external and 
resumption PSKs while parsing Client Hello

---

From: Benjamin Kaduk <[email-masked]>
Date: Thu, 15 Mar 2018 16:51:49 -0500

> in TLS 1.3... I wanted to be unambiguous, so please, can we discuss the issue, 

Sure!  (I still don't see how an ephemeral in-server key would be
used as/with an external PSK.)

> resumption PSKs while parsing Client Hello

Well, a valid external PSK (identity) the server will of course
recognize, and we have a SHOULD-level requirement that the
obfuscated_ticket_age is zero for external PSKs.  I haven't gotten
to think through whether there is still potential for information
leakage about external PSK identities, but it seems like there would
not be, provided that the server prefers resumption to external-PSK
full handshakes.

-Benjamin

---

From: Hubert Kario <[email-masked]>
Date: Fri, 16 Mar 2018 12:36:47 +0100

On Thursday, 15 March 2018 22:51:49 CET Benjamin Kaduk wrote:
> > not my fault that what we called just "PSK"s in TLS 1.2 is now "external
> > PSKs" in TLS 1.3... I wanted to be unambiguous, so please, can we discuss
> > the issue, not semiotics?
> 

aah, that's were the confusion is, I was talking ("only because the server was 
restarted") about resumption PSKs, I didn't think you were proposing ("then 
aborting the handshake on binder failure would be the correct choice") that 
behaviour only for external PSKs — you can't differentiate resumption PSKs 
based on being able to verify the identify (assuming it's a RFC 5077-style 
ticket) because you can't be sure you have all the keys to verify them
(not to mention that the tickets could have been established by a TLS 
implementation that was used on this server yesterday or the identity can be a 
database lookup key, session_id style)

so there's no reliable way to say that, yes, this identity is or is not a 
resumption ticket, if I can't decrypt it

> not be, provided that the server prefers resumption to external-PSK

SHOULD means we can't depend on it — it's not reliable

if we say that resumption PSKs MUST have zero age and resumption ticket MUST 
NOT be zero (even if that means fudging the time a bit), then yes, there would 
be a way to differentiate them

that doesn't help against attackers that have one valid identity and want to 
find out other identities configured on the server though

I'd really prefer we exhaust other possibilities before sacrificing support 
for multiple external PSK. With TLS 1.2 we had ticket_hint to guide PSK 
selection, now we're left with just server IP or hostname.
(I do admit that requiring one external PSK, having way to identify them with 
no false positives and negatives, and ignoring it completely in case of binder 
verification failure does look solid)
-- 
Regards,
Hubert Kario
Senior Quality Engineer, QE BaseOS Security team
Web: www.cz.redhat.com
Red Hat Czech s.r.o., Purkyňova 115, 612 00  Brno, Czech Republic

---

From: Christian Huitema <[email-masked]>
Date: Fri, 16 Mar 2018 09:11:32 -0400

On 3/15/2018 5:51 PM, Benjamin Kaduk wrote:
> ...

I am concerned with the privacy issues linked to these "external PSK
identities". If a system is set so that clients use static PSK
identities, then the identity is an identifier and the client's
movements and connections can be tracked. I don't think privacy is
improved if we make it easy to differentiate external identities from
resumption tickets.

If you want to use PSK with some level of privacy, you might adopt a
different setup. For example, servers could provision the clients with a
set of single-use external PSK identities. But then, that looks a lot
like resumption. Or, clients could generate single-use external PSK
identities by encrypting their long term identity and a nonce with the
public key of the server, a design which of course has its own set of
issues.

-- Christian Huitema

---

From: Benjamin Kaduk <[email-masked]>
Date: Fri, 16 Mar 2018 14:45:20 -0500

> improved if we make it easy to differentiate external identities from

Oh, of course, the privacy considerations of the current external
PSK scheme are terrible!  This follows naturally from external PSKs
having not really been a first-class citizen while we were designing
things; we stuffed resumption PSKs together with external PSKs for
the convenience of having them use the same binder construct and
only needing to have one extension at the end of the ClientHello.
Resumption flows get single-use tickets for privacy preservation,
and external PSKs get infinite use and a gigantic correlation
channel.

> public key of the server, a design which of course has its own set of

But, as you note, this is something of an open problem for how to do
well, and this document is already approved by the IESG.  (It's also
not entirely clear that the TLS WG would be the best place to design
this sort of scheme, though of course it could choose to do so.)

So to me the open question is whether we consider enumeration of
external PSK identifiers to be something we can address reasonably
at this stage of the document's lifecycle at all.  (I also note that
the presence of a CVE number for a similar issue does not
necessarily mean anything -- CVE assignments can occur for
situations with no actual security impact and/or against the wishes
of the software authors.)  I don't think anyone has proposed a
minimal change that would close the enumeration channel, and given
that external PSKs already have bad privacy properties, it seems
like we may just have to accept this state of affairs for this
document.

Hubert also says:

% so there's no reliable way to say that, yes, this identity is or is not a
% resumption ticket, if I can't decrypt it

Mostly.  External PSKs are established out of band, and that
provisioning process *could* include knowledge that the
obfuscated_ticket_age would always be zero when those PSKs are in
use, and that would be reliable for those specific parties.

It's probably also worth considering the two cases for server
behavior when presented with a PSK id that is neither a known
external PSK nor a known resumption ticket -- the server could
either treat it as an unknown external PSK id or as a resumption
ticket that fails to decrypt.  The latter case fails because the
attacker can try candidate external identities and the server falls
back to a full handshake unless the PSK ID is good.  (Well, maybe
the server rejects PSK IDs that are shorter than a ticket would be.)
The first case is not really usable since it would lead to spurious
triggering of the proposed "at most one external PSK" check.

So, in addition to the "we provision external PSKs only when we know
that obfuscated_ticket_age will be zero", deployments could also
agree that external PSK ids are shorter than a given length and
resumption PSKs are larger, which would again provide a reliable
differentiator between resumption and external.

The privacy issues remain terrible, of course.

% I'd really prefer we exhaust other possibilities before sacrificing support
% for multiple external PSK. With TLS 1.2 we had ticket_hint to guide PSK
% selection, now we're left with just server IP or hostname.

I think that "do nothing and accept external PSK enumeration as a
risk" is more likely than sacrificing support for multiple external
PSKs, personally.

-Benjamin

---

From: Lanlan Pan <[email-masked]>
Date: Sun, 18 Mar 2018 15:24:02 +0000

> little more annoying, but perhaps not fatally so.

what about each external PSK's survival time ?

It seems should be updated in period.

>
> -Ben(jamin)
> _______________________________________________
> TLS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tls
>
-- 
致礼  Best Regards

潘蓝兰  Pan Lanlan

---

From: Eric Rescorla <[email-masked]>
Date: Sun, 18 Mar 2018 15:27:34 +0000

After discussion with the chairs and the AD, I have opted to just add a
section
that explains the attack. I just merged that (but managed not to get it
into -27
due to fumble fingering).

-Ekr

---

From: Viktor Dukhovni <[email-masked]>
Date: Sun, 18 Mar 2018 12:08:13 -0400

> On Mar 18, 2018, at 11:27 AM, Eric Rescorla <[email-masked]> wrote:
> 
> After discussion with the chairs and the AD, I have opted to just add a section
> that explains the attack. I just merged that (but managed not to get it into -27

It seems to me that privacy considerations for external PSKs are a rather
secondary issue.  These are infinitely more likely to be used by IOT devices
calling the mothership than by users browsing content they'd rather keep
private.  I've never used an external PSK, nor do I expect have any of the
posters pointing out the privacy issues.

The devices that might use external PSKs will likely be unavoidably
fingerprinted by source IP address and the target mothership.

So I agree with the above approach.  It is better to keep external PSKs
simple, with understood limitations, that to attempt (and fail) to turn
privacy up to eleven.

-- 
	Viktor.

---

From: Benjamin Kaduk <[email-masked]>
Date: Sun, 18 Mar 2018 19:40:25 -0500

> It seems should be updated in period.

It should, but that has always been the case and nothing has changed
in that regard in TLS 1.3 vs TLS 1.2.  (In practice, they are not,
and nothing we say in the document is likely to produce substantial
change in that regard.)

-Ben

---

From: Daniel Kahn Gillmor <[email-masked]>
Date: Mon, 19 Mar 2018 10:38:58 +0000

> fingerprinted by source IP address and the target mothership.

I'm not convinced that this is the case -- it's not at all clear that
IoT devices will be attached to a stable network (so the source IP may
change), and for large deployments, the devices might all share the same
"mothership".  But the device might still present significant privacy
concerns (for example, if it's a device that travels with a person, its
presence on the network could be used to track that person). 

> simple, with understood limitations, that to attempt (and fail) to turn

fwiw, i agree that a big fat warning about the privacy implications of
reused (if you don't reuse, there is no problem) external PSKs is about
all we can do at this stage of TLS 1.3.

    --dkg

---

From: Joseph Lorenzo Hall <[email-masked]>
Date: Mon, 19 Mar 2018 07:02:46 -0400

> presence on the network could be used to track that person).

In addition to locative privacy threats, the nature of the IoT device
itself might expose something sensitive about the user (e.g., a
connected pleasure device, medical device, or solid platinum espresso
maker).

---

From: Nikos Mavrogiannopoulos <[email-masked]>
Date: Mon, 19 Mar 2018 14:33:52 +0100

> and external PSKs get infinite use and a gigantic correlation

I agree.

> like we may just have to accept this state of affairs for this

That's a good general remark, but not really the case for the
vulnerabilities that Hubert pointed out.

> use, and that would be reliable for those specific parties.

I believe that this can happen in an interoperable way if the protocol
mandates it (which is not the case now). These specific parties may use
software from different vendors which may use different conventions if
the protocol is not clear enough.

> differentiator between resumption and external.

That cannot easily happen. I can have multiple servers answering to the
same hostname each using a different implementation. Any conventions
used in one implementation would not apply to another.

> risk" is more likely than sacrificing support for multiple external

The problem is that you personally are not affected by that risk and I
guess that makes it easy for you to accept it. TLS1.2 with PSK did
explicitly prevent enumeration (by asking implementations to proceed to
handshake even with unknown usernames, and making up a key), meaning
that this is a risk that the designers of PSK (external) intentionally
ruled out. Going that path, it would be a step back in PSK security for
TLS1.3.

regards,
Nikos

---

From: Eric Rescorla <[email-masked]>
Date: Mon, 19 Mar 2018 13:38:05 +0000

> ruled out. Going that path, it would be a step back in PSK security for

Nikos,

Just as a clarification, I believe it's possible for a PSK-only
implementation to
avoid this attack by behaving uniformly for "unknown ID" and "invalid
binder"

-Ekr

---

From: Hubert Kario <[email-masked]>
Date: Mon, 19 Mar 2018 17:00:51 +0100

> due to fumble fingering).

If there is no consensus on the recommended fix for the issue, I wonder if we 
shouldn't then soften the language in the section about PSK binder handling, 
from SHOULD to MAY.

Though, I'd say that the reference to that newly added section is definitely 
missing.

> >    order, computed as described below. If the number of binders does not
> > 
> > match
> >

---

From: Benjamin Kaduk <[email-masked]>
Date: Mon, 19 Mar 2018 17:53:16 -0500

> shouldn't then soften the language in the section about PSK binder handling, 

I think on the balance I am happier retaining SHOULD.

> Though, I'd say that the reference to that newly added section is definitely 

I expect that can be done as an RFC Editor note or during AUTH48.

-Benjamin

---

From: Benjamin Kaduk <[email-masked]>
Date: Mon, 19 Mar 2018 18:01:43 -0500

> vulnerabilities that Hubert pointed out.

I think you are just referring to the bit about CVE numbers not
necessarily indicating much of anything?

I would like to hear your opinion on the "open question" I
identified...

> the protocol is not clear enough.

The convention for PSK-only deployments in the text Ekr added seems
clear enough to me, so it seems that only deployments willing to do
either Certificate or PSK in the same server instance are at risk.

> used in one implementation would not apply to another.

You think there will be a server using resumption PSK identifiers
shorter than 128 bits??

> ruled out. Going that path, it would be a step back in PSK security for

Especially in light of subsequent updates on the thread, this does
not seem to be a strong enough argument to merit a change after IESG
approval.  There seem to be some options for future updates in
backwards-compatible ways, in any case.

-Benjamin

---

From: Hubert Kario <[email-masked]>
Date: Tue, 20 Mar 2018 13:52:11 +0100

On Monday, 19 March 2018 23:53:16 CET Benjamin Kaduk wrote:
> > If there is no consensus on the recommended fix for the issue, I wonder if
> > we shouldn't then soften the language in the section about PSK binder
> > handling, from SHOULD to MAY.
> 
> > Though, I'd say that the reference to that newly added section is
> > definitely missing.
> 

https://github.com/tlswg/tls13-spec/pull/1189 filed as a reminder

---

From: Sean Turner <[email-masked]>
Date: Tue, 20 Mar 2018 12:55:31 +0000

> On Mar 20, 2018, at 12:52, Hubert Kario <[email-masked]> wrote:
> 

Thanks!

spt

---

From: Hubert Kario <[email-masked]>
Date: Tue, 20 Mar 2018 20:42:22 +0100

> avoid this attack by behaving uniformly for "unknown ID" and "invalid

supporting both external PSK authentication and certificate based 
authentication for a single IoT gateway would be quite expected, I'd say

so just because PSK-only implementations are not vulnerable, I don't think we 
can expect all servers that deploy external PSKs will also disable certificate 
based authentication (not to mention that it's rather unlikely that users will 
expect that adding certificate will suddenly make their server vulnerable)

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 20 Mar 2018 21:21:06 +0000

> expect that adding certificate will suddenly make their server vulnerable)

I'm not making an argument, I'm merely stating what I believe to be the
facts.

-Ekr

--

---

From: Kathleen Moriarty <[email-masked]>
Date: Wed, 21 Mar 2018 04:08:46 -0400

The document has been approved for publication and the outstanding
reference will be added in the RFC editor process during Auth48.

Thank you all for your work on this protocol.

Best regards,
Kathleen

On Tue, Mar 20, 2018 at 5:21 PM, Eric Rescorla <[email-masked]> wrote:
>> > > > % so there's no reliable way to say that, yes, this identity is or
>> > > > is
>> > > > not a
>> > > > % I'd really prefer we exhaust other possibilities before
>> > > > sacrificing
>> > > > support
>> > > > % for multiple external PSK. With TLS 1.2 we had ticket_hint to
>> > > > guide
>> > > > PSK

-- 

Best regards,
Kathleen

---

From: Hubert Kario <[email-masked]>
Date: Wed, 21 Mar 2018 14:46:33 +0100

On Tuesday, 20 March 2018 22:21:06 CET Eric Rescorla wrote:
> > > On Mon, Mar 19, 2018 at 1:33 PM, Nikos Mavrogiannopoulos <
> > 
> > [email-masked]>
> > 
> > > wrote:

ok, then I agree with those facts :)