Dan Harkins wrote:
> On Sun, August 16, 2009 9:43 am, Stephen Hanna wrote:
> > I do not agree that EAP channel bindings are about
> > authentication. They have two parts: checking whether
> > the NAS is advertising services that it's not
> > authorized to advertise and using information from
> > the NAS (like which SSID the peer is trying to
> > connect to) to supplement the AAA server's decision
> > about whether to grant the requested access.
> > Both of these are authorization decisions and they
> > are made not based on authenticating the NAS (which
> > we have had for many years in the form of the secret
> > shared between the NAS and the AAA server) but on
> > supplementary information about the SSIDs and other
> > things being advertised by the NAS and requested by
> > the EAP peer.
>
> The problem with your definition of channel bindings is that it
> completely ignores the lying NAS problem. An identity is not a service
> that a NAS can be authorized to provide that is checked after
> authentication has completed.
After carefully reviewing again the list of attributes
verified by draft-ietf-emu-chbind-03.txt, I would agree
that several of them are related to the NAS identity:
NAS-IP-Address, Called-Station-Id (the MAC part), and
NAS-Identifier. Some are related to the identity of
the network to which the NAS claims to provide access
or to the mobility domain of which it is a part:
Called-Station-Id (the SSID part) and Mobility-Domain-Id.
For those, I agree that we can call them authentication
since the main purpose of channel bindings is to verify
that the identity claimed by the NAS to the EAP peer is
acceptable (although SSID and Mobility-Domain-Id are
not really NAS identity but network identity).
If/when the AAA server uses the SSID to decide whether
a user is authorized to connect to that SSID, there's
definitely authorization taking place but one can argue
that the primary reason to convey this attribute in
channel bindings is to verify the network identity
claimed by the NAS to the EAP peer. So let's overlook
this authorization aspect.
However, I wonder if you really want to claim that
the Cost-Information AVP is part of the NAS identity.
That seems to be clearly not. Do you want to claim
that this is part of the network identity? That seems
to be a stretch. Really, I think that this is an
attribute of the network (or one could say an
advertisement) that is being verified.
> > I agree that NEA assessments are a different topic.
> > They're not the same as channel bindings. I'd say
> > that the data conveyed in EAP for channel bindings
> > and for NEA assessments are both authorization data
> > in that they are not authentication protocols but
> > supplementary data that the AAA server will use in
> > deciding whether access should be granted (and maybe
> > whether other action should be taken, like getting
> > the lying NAS repaired or sending remediation
> > instructions to an unhealthy endpoint).
>
> "Repair" the lying NAS after authentication? Whoa! If authentication
> does not fail because a lying NAS was detected then there is a huge
> security problem.
I agree that authentication should not succeed if a
lying NAS is detected. I didn't say otherwise. I said
that you might want to repair a lying NAS. Of course,
"repair" would mainly apply if it's your equipment.
If it's a rogue NAS, you might want to find it and
smash it with a sledgehammer. ;-)
> You seem to be conflating authentication and authorization
> because a "AAA server" might use information from both steps
> in deciding whether access is granted or not. An EAP server
> asks "who are you?" and then proceeds to prove the identity
> it is told using a method of its choice. If the EAP method
> derives keys the keys have to be bound to a consistent
> view of the identities involved in the communication
> (including the NAS identity). If the EAP server is successful
> in proving that the peer really is the identity it claimed
> (and the key is successfully bound to a consistent view of
> all identities) there can still be other, supplementary,
> things to consider before deciding to grant access or not--
> time-of-day, location, up-to-date anti-virus software, etc.
> But those other, supplementary, things are not EAP, which
> is why you're mentioning a "AAA server" and not an "EAP server".
>
> We might want to make them part of EAP since EAP is the only
> protocol allowed prior to the access decision being made and
> it's attractive to pass arbitrary data encapsulated in EAP.
> But I think it's wrong to say that NEA assessments can piggy
> back in because the door is being held open for channel bindings.
I am not trying to conflate authentication and authorization.
I recognize that these are two different things and I think
that it will help us to have a clear definition of each.
That should help us decide whether we want to allow some
authorization data to travel over EAP. You wrote:
> Authentication has to do with proving an identity. Authorization
> has to do with determining whether that proven identity is
> "good" or "bad".
I agree with the gist of your definition of authentication.
We might more precisely define authentication as:
the process of verifying a claim that an entity has a certain
identity
However, I think that your definition of authorization is a bit
too loose. A perfectly good person should not be authorized to
access someone else's records. I suggest that we use this
definition of authorization from RFC 4949:
1b. (I) A process for granting approval to a system entity to
access a system resource.
I agree that EAP was originally defined solely for the purpose
of authentication. I agree that it is wise for us to consider
carefully whether we want to also allow it to be used to carry
information that is useful in authorization. While I believe that
this is a good idea, I think that we'll want to continue to place
constraints on the amount and kind of data that should be
conveyed over EAP. EAP is not a bulk data transfer protocol
and it should not be used as one. That will only result in
heartache for all involved (due to the limit of one packet
in flight at any time, the frequently long round trip times
when RADIUS proxies are used, and the short timeouts given
by many NASs, among other issues).
Thanks,
Steve
_______________________________________________
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu
