draft-josefsson-password-auth-00.txt

[Nicolas Williams]

On Fri, Mar 30, 2007 at 12:50:43AM +0200, Martin Rex wrote:
> Nicolas Williams wrote:
> > Any where the server stores a secret verifier derived from the password
> > salted with the server's name.  If the server sends a response to the
> > client's response that proves it knows the verifier then the client can
> > consider the server to be authenticated to the client.
> 
> Depending on the architecture of the challenge response scheme
> this may not be easily done.
> 
> There are legacy systems where the (app)server actually possesses
> the shared secret and could therefore "prove he knows it".

Indeed.  But that doesn't mean that a generic mechanism in this area
must not support salting passwords as I described.

> AFAIK, the NTLM authentication on windows differs here.  The
> server doesn't have access to the shared secret, but has a
> secure channel to a domain controller where he can ask whether
> a particular combination of challenge and response is acceptable.

Yes, proxying should be acceptable.

> > You're misusing the term "channel binding" here.  A server name not
> > associated with some secure channel below the application layer is not a
> > channel binding.
> 
> Sorry, but I have to disagree completely.  GSS-API has a very
> "open" concept of channel bindings.

Here we're talking about a mechanism more generic still than a GSS
mechanism.  Lately when we speak of channel binding we mostly mean it in
the "transformed representations of encryption keys) of the underlying
communications channel, of protection mechanisms applied to that
communications channel," subset of the sense of RFC2743.

You may want to comment on draft-williams-on-channel-binding-01.txt;
it's in IETF Last Call.

> You might want to turn your attention to RFC-2744 Section 3.11.

The relevant text is in RFC2743, section 1.1.6, first paragraph.

Nico
--