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

[Eric Rescorla <[e-mail]>]

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


On Mon, Mar 12, 2018 at 8:27 AM, Hubert Kario <[e-mail]> wrote:

> 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
> _______________________________________________
> TLS mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/tls
>
>