Hi Raj I don’t think we can specify MUST requirements for the AAA servers, because we’re not specifying RADIUS or DIAMETER here.
For example in RADIUS, the VPN gateway sends an Access-Request to the server, which contains the user-name, presumably the same user-name from the IDi payload. If the server authenticates the user successfully, and has not sent an user-name attribute, then I guess we can assume that it has authenticated the identity sent in the access-request payload (= the identity in the IDi payload). For example, if I pass the identifier “ynir” (which is unique at my company) or “y...@checkpoint.com”, which is globally unique, this is good enough for policy updates, even if the EAP server did not send another identity. Of course, in some cases the IDi could be an anonymized identity, and then if the server doesn’t give us a real identity, then something is wrong. But this distinction is a matter for local policy, which I don’t think we can specify in ikev2bis. In any case, policy lookups have to be done using the authenticated identity, either the one in IDi or the one supplied by the AAA server. I think the line “It is important that policy lookups and access control decisions use the actual authenticated identity.” conveys that. ________________________________________ From: ipsec-boun...@ietf.org [mailto:ipsec-boun...@ietf.org] On Behalf Of Raj Singh Sent: Wednesday, February 03, 2010 8:22 AM To: Yaron Sheffer Cc: ipsec Subject: Re: [IPsec] Fwd: Issue : Regarding EAP identity Hi Yaron, The question is more towards when EAP identity is needed and is different from IDi. But AAA server doesn't send it, we will fail. But draft doesn't have any say for this scenario. So it becomes mandatory for AAA server to send identity. Regards, Raj On Wed, Feb 3, 2010 at 11:22 AM, Yaron Sheffer <yar...@checkpoint.com> wrote: The authenticated identity needs to be sent by the AAA server to the IKE responder in some cases only. For example, in EAP-SIM/AKA people often use “temporary” (anonymized) identities in IDi. But in other cases, like EAP-MSCHAPv2 or (God forbid!) EAP-GTC, there’s no need for a separate “authenticated identity”. In these cases the IKE responder should simply use the original IDi for policy lookup. Thanks, Yaron From: ipsec-boun...@ietf.org [mailto:ipsec-boun...@ietf.org] On Behalf Of Raj Singh Sent: Wednesday, February 03, 2010 7:45 To: ipsec Subject: [IPsec] Fwd: Issue : Regarding EAP identity Hi Paul, Ticket Issue#174 opened for it. Regards, Raj ---------- Forwarded message ---------- From: Paul Hoffman <paul.hoff...@vpnc.org> Date: Wed, Feb 3, 2010 at 9:41 AM Subject: Re: Issue : Regarding EAP identity To: Raj Singh <rsjen...@gmail.com> Cc: Yaron Sheffer <yar...@checkpoint.com> At 9:09 AM +0530 2/3/10, Raj Singh wrote: Hi Paul, In ikev2bis07 ----- ikev2-bis-07 section 2.16, last paragraph ------------------------------------------- When the initiator authentication uses EAP, it is possible that the contents of the IDi payload is used only for AAA routing purposes and selecting which EAP method to use. This value may be different from the identity authenticated by the EAP method. It is important that policy lookups and access control decisions use the actual authenticated identity. Often the EAP server is implemented in a separate AAA server that communicates with the IKEv2 responder. In this case, the authenticated identity has to be sent from the AAA server to the IKEv2 responder. --------------------------------------------------------------------------------------------------------------- It says the autheticated EAP identity "has to" be send from AAA server, our iterpretation is "has to" is obvious MUST. I believe that is correct. If AAA doesn't send the authenticated EAP identity, what should be the behavior? I would assume "everything stops" Also, what if AAA server EAP server is not AAA server? Good question. Can i open a ticket for it? Yes, please! --Paul Hoffman, Director --VPN Consortium _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
