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
