Sam Hartman <[EMAIL PROTECTED]> writes: >>>>>> "Eric" == Eric Rescorla <[EMAIL PROTECTED]> 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 [email protected] https://www1.ietf.org/mailman/listinfo/dix
