Re: [Ietf-http-auth] Re: [dix] Notes on Web authentication enhancements

Sam Hartman <hartmans-ietf@mit.edu> writes:

>>>>>> "Eric" == Eric Rescorla <ekr@networkresonance.com> writes:
>     >> An additional issue is hijacking: without cryptographic
>     >> binding, an attacker who observes a request can make future
>     >> requests in the name of the user via a cut-and-paste attack
>     >> (remember, the token is bearer). If you take the threat of this
>     >> type of attack seriously, you need to run the traffic over
>     >> SSL/TLS. [1]
>     >> 
>     >> 
>     >> [1] Note that if you're worried about this class of attack, you
>     >> need *every* PDU to be cryptographically bound to the
>     >> credential with all designs. If, for instance, you use
>     >> cert-based auth but then transition to cookies over HTTP for
>     >> state management, there's a cut-and-paste attack there.
>     >> 
>     >> 
>     >> I think the primary paragraph is misleading.  We've started
>     >> from an assumption that there are practical problems that
>     >> prevent server certificates from being validated.  Given this
>     >> assumption I don't understand how TLS actually gives us
>     >> protection against the hijacking.
>
>     Eric> Imagine a case where you have credentials that have CRA but
>     Eric> not HRA. A good example is Boneh's PwdHash, which includes
>     Eric> the domain name of the server in the "password". If it's
>     Eric> restricted to use with SSL/TLS then you know that each RP
>     Eric> will have a unique domain name and therefore each "password"
>     Eric> is unique to a single RP, so there's automatic CRA--if the
>     Eric> user is phished the phisher must pose as a different RP
>     Eric> because he has a different certificate. [0]
>
> This is not true of all credentials that have cra but not ha--or at
> least I don't see why it is.  TLS only provides security because you
> bind the two authentication layers together by using the same naming
> for both the TLS authentication and the higher layer authentication.
> (It also assumes that your CA is trusted; that assumption seems
> consistent with our threat model.)
>
> I was explicitly trying to get at the fact that you needed to do
> something in addition to TLS.  Here you've made the naming be the
> same.

Sorry, I don't see what you're getting at. PwdHash is specified to use
the domain name of the server as the hash salt. RFC 2818 requires
that that domain name match the server's certificate. There's nothing
additional required.

>     >> I also think the footnote ignores an important deployment
>     >> model.  I may be concerned about whether I have reached the
>     >> right RP while not concerned about network level hijacking.  So
>     >> I'm not at all convinced that you always need to protect every
>     >> exchange if you are concerned about hijacking in some
>     >> situations.
>
>     Eric> By hijacking, I mean network level hijacking. If you mean
>     Eric> typos and phishing, then I think this is a different threat.
>
> Can we have a name for that threat, because I thought you were
> lumping the two together.

Uh, I call the other one "phishing" or "credential capture"

-Ekr

_______________________________________________
dix mailing list
dix@ietf.org
https://www1.ietf.org/mailman/listinfo/dix