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

[Hubert Kario <[e-mail]>]

On Sunday, 18 March 2018 16:27:34 CET Eric Rescorla 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
> 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.

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


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