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:
>
>     Eric> Sorry, I don't see what you're getting at. PwdHash is
>     Eric> specified to use the domain name of the server as the hash
>     Eric> salt. RFC 2818 requires that that domain name match the
>     Eric> server's certificate. There's nothing additional required.
>
> The additional thing is that the specification of pwdhash uses the
>         same naming for servers that tls does and that as pwdhash is
>         used, it derives the name of the server it is contacting from
>         the same place as TLS (the URI).

Yes, I agree that this is necessary. I don't agree that it's
"additional". It's a basic part of any design that aims
to preserve referential integrity, which is why TLS and
PwdHash both do it.

> Say I replace pwdhash with an authentication scheme where the client
> needs to learn from the user an identity for the server to be used at
> the TLS layer (the domain name from the URI) and an identity to be
> used for my upper layer authentication scheme (derived somewhere
> else).
>
> For example, SASL digest effectively names the server based on a
> realm.  There's no good mapping between the server's domain name and
> the realm.  So, I'm fairly certain that a server could trick you into
> giving it a challenge to replay with another server.
>
> I think HTTP digest works approximately the same way.
> In this situation, TLS would not be enough to prevent MITM.
>
> Although perhaps the difference here is that I was using a broader
> definitiong of hi jacking than you were and my definition included
> MITM.

Uh, no. The difference is that HTTP Digest and SASL Digest don't
provide CRA, because they don't include the user's intended
URI in the C-R response.

-Ekr

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