At 12:14 PM +0200 2/10/10, Alper Yegin wrote:
Dan,
Hi Alper,
In that case there is no standard way for the AAA server to inform
the
IKEv2 responder of this "policy" that it needs to enforce. So that
sounds
unworkable.
I guess it can be specified.
The IKEv2 responder already has the mechanisms in place to enforce a
policy based on the authenticated identity of the IKEv2 initiator. So
if
EAP is being used then all we need is a way to get that authenticated
identity from the AAA server to the IKEv2 responder.
Isn't IDi what IKE deals with?
not always. See the discussion in 4301 re the PAD.
I'm not aware of a document to allows a AAA server to export the
authenticated identity to the AAA client (maybe such an attribute
already
exists, I just don't know)
I'm not aware, either.
In other uses of AAA (such as with WiFi, WiMAX, 3GPP2, etc.) I know that the
subscriber ID is hidden from the NAS. There are even specific methods
deployed for that purpose. So, disclosing that ID would not be acceptable
there. I'm just not sure if the same privacy concerns apply to the VPN
deployments.
There is a difference here in that the IPsec device normally performs
peer auth and access control, independent of an AAA server.
but surely it would be easier to define that
then to define a standard way to send some "policy" from AAA server to
IKEv2 responder. Right?
If you don't do that, then you have to maintain "per subscriber policy" on
each one of the VPN gateways. Now that starts defeating some of the purpose
that AAA was offloaded to a centralized/dedicated server.
Maybe. I thought the principle argument for AAA (really RADIUS) use
here was that enterprise IT folks already managed user authentication
via these servers and wanted to use that aspect of their investment
in the IPsec context. If one wants to rely on these servers for more
than just user authentication, a more complex solution is needed.
Steve
_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
