draft-josefsson-password-auth-00.txt

[Nicolas Williams]

On Fri, Mar 30, 2007 at 12:11:16AM +0200, Martin Rex wrote:
> To me that seems to be slightly inappropriate terminology.
> 
> Which particular challenge-response scheme do you have in mind
> where the server actually performs a mutual authentication,
> i.e. provides a cryptographic proof of his identity?

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.

> If the client derives the target name from the network endpoint
> address (i.e. fqdn-hostname plus service/tcp-port-no) and
> the server simply "asserts" this name, then this is really
> a channel binding based on a printable name instead of

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.

> the low-level network address, but still a channel binding and
> not an authentication.

I really didn't want to talk about server name canonicalization.  I
wanted to sketch a generic password-based challenge/response mechanism
that supports the optional use of channel binding and optional mutual
authentication.

Yes, I included in my sketch an acceptor-side assertion of its name.
This has two purposes that I did not mention.  One: when the client
doesn't know the server's name the client can simply go ahead and use
the asserted server name as the salt -- if the alternative is not to
salt the password at all then this is clearly good and not harmful (the
client provides material that can be attacked offline regardless of how
the password is salted).  The other: so the client can output the
correct server name to the application which can then prompt the user,
or for "fuzzy" server name canonicalization.

(I know, you don't have to remind me that the GSS-APIv2u1's
GSS_Canonicalize_name() is supposed to be able to canonicalize the given
server (or whatever) name securely and out of band w.r.t. security
context establishment.  But we're talking here too about a mechanism
usable outside the context of the GSS-API also, and anyways, that bit of
GSS-APIv2u1 semantics is rather cumbersome.)