draft-josefsson-password-auth-00.txt

[Martin Rex]

Nicolas Williams wrote:
> 
> 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.

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".

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.


> 
> > 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.

Sorry, but I have to disagree completely.  GSS-API has a very
"open" concept of channel bindings.

You might want to turn your attention to RFC-2744 Section 3.11.
which lists all types of channel bindings that "GSS-API v2"
knows about.  None of what I see there is what I recognize
as "secure" channel bindings, but it does have the "GSS_C_AF_INET"
type.


-Martin