Subject: [abfab] Validation of acceptor names for the initiator

From: Sam Hartman <[email-masked]>
Date: Tue, 14 Sep 2010 10:23:23 -0400

>>>>> "Luke" == Luke Howard <[email-masked]> writes:
Luke asked how mutual authentication works and whether you needed the
server to echo back some confirmation about it.
Here's my answer.

Yes, I think so.  We may decide to "trust" the server for basic channel
binding and mutual authentication.  (Or we may not. It's a question of
whether we want to fail-useful or fail-secure.)  However for things like
MTP, where we're depending on the AAA infrastructure to undersatnd a
name form more complex than GSS_NT_HOSTBASED_SERVICE,we absolutely need
to have some way to validate that.

So, for the basic case (GSS_NT_HOSTBASED_SERVICE), the client is  depending on:

* A radius server near the NAS to validate the mapping of host name  and
  probably to assert a realm
* A server near the IDP to validate that the realm in question is
  permitted to  claim that host
* A server near the IDP to do any desired policy enforcement about
  whether the realm in question is permitted to provide the service in
  question to the user

The initiator's interaction here are to give its idea of the acceptor
name as an input to the channel binding operation via EAP.  Based on
discussion in emu, it looks like the initiator will receive an
indication back from the EAP method about what attributes were used in
performing channel binding.  I.E. if it sees whatever AVP it sent the
server name there in the message back from the EAP server, then it can
assume mutual auth.  Otherwise perhaps it should not.

I don't think the acceptor/NAS is depending on anything new not already
in wide EAP deployment.  The only exception is that we'll need to
clearly specify how the acceptor gets the initiator's name.

For something like MTP, We need a way for the initiator to explain to
the GSS mechanism that service-specific validation is
required--presumably setting a name attribute with some token describing
the expected form of validation.
Then, we'll send that in our AVP  and expect to see the server ack it.

Actually, perhaps I'm over thinking this.
Perhaps it's sufficient to simply require that if you're doing
validation  of a moonshot name that has more than just a host, service
and realm, you must understand and accept the extra parts or you must
fail the validation.
That way we need no special name attributes or anything strange like
that.

Here's where I expect to see this appear in specs:

* The next version of draft-ietf-emu-chbind should talk about the
  interface and indicate that you can send channel binding attributes to
  a server and get a set of attributes it used back

* draft-howlett-eap-gss should talk about  what AVPs you send the
  acceptor identity in as well as initiator behavior regarding channel
  binding and the mutual_auth bit.

--Sam