Hi Yoav,
First of all, IDi is not sent in response to an EAP Identity Request.
Every NAS will, when it comes time to initiate EAP authentication,
request an identity. That's how EAP works. The IKEv2 responder "knows"
to send an EAP Identity Request because the IKEv2 initiator has
indicated its "desire to use extensible authentication by leaving out
the AUTH payload from message 3." So the IDi in message 3 of the exchange
in 2.16 of RFC 4306 will not be an identity from an EAP identity response.
It's going to be anything the initiator decides to use and has no bearing
on reality. The NAS, in message 4, will do an EAP Identity Request. And
now the client, in a subsequent message, will provide it's decorated or
obfuscated identity which is used to find a suitable AAA server that will
actually determine what the real and authenticated identity of this thing
is.
So what we have is:
1) IDi, whatever the client decides to use.
2) the identity in the EAP Identity response to message 4 which can
be decorated or obfuscated and is useless for authentication.
3) the real identity that was used to authenticate the client
at the EAP server.
Now, what identity are you saying is used by the IKEv2 responder to
enforce policy and how and why?
regards,
Dan.
On Wed, February 10, 2010 10:16 pm, Yoav Nir wrote:
> Hi.
>
> This is an interesting subject, and perhaps could be a good candidate for
> discussion at Anaheim. However, from the narrow perspective of a VPN
> vendor, I don't think this issue is very complicated:
>
> - In the first IKE_AUTH request the initiator provides *an* identity. This
> could be something meaningful like "ynir", or something less meaningful,
> like "@checkpoint.com", or something really unique like
> "y...@checkpoint.com"
>
> - The responder uses this info to decide on using the EAP/RADIUS server
> (perhaps running on an LDAP server).
>
> - The RADIUS protocol is really out of scope for this document, so we
> won't discuss its details, but in any case, eventually this AAA server
> returns an EAP success and RADIUS access-accept. Now we have two
> possibilites:
>
> #1) The AAA server passed an authenticated identity, perhaps
> UID=ynir,OU=People,O=intranet,DC=checkpoint,DC=com. (No, I don't know why
> I work for the "intranet" organization). In this case, the IKE responder
> will enforce policy according to what the PAD and SPD say about this
> identity. Where this policy comes from does not matter - maybe it's also
> passed from the AAA server, maybe it's specially configured and maybe
> it's stored on the LDAP server. How IKE gets its policy is out of scope
> while we're discussing IKEv2bis.
>
> #2) The AAA server did not pass an authenticated identity. In this case,
> the authenticated identity is exactly what you had in the ID payload. If
> this is "ynir", than we can expect the IKE responder to have policy based
> on this name. If it's "@checkpoint.com" - a name that everybody uses,
> then either the policy is the same for all defined users (a valid policy
> and very common) or you have a misconfiguration here - the combination of
> obfuscated identity and an AAA server that does not provide the
> authenticated identity is a configuration mistake, and it's entirely
> correct for the IKE responder to treat packets from this user as if they
> come from an unauthenticated source (in our product - only firewall rules
> apply)
>
> I don't think this behavior is specified anywhere, but to me it's just the
> obvious thing for an IKE responder to do.
>
> _______________________________________________
> IPsec mailing list
> IPsec@ietf.org
> https://www.ietf.org/mailman/listinfo/ipsec
>
_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
