The IKEv2 responder enforces policy, so it has to know the identity, both for enforcement and auditing. Suppose y...@checkpoint.com is allowed to access server X, while alper.ye...@yegin.org is not, then the IKEv2 responder needs to both block your attempts to access server X (perhaps by failing the CREATE_CHILD_SA exchange), and to log that you tried this.
If auditing is not required, it's possible to work with some kind of pseudo-identity, but in that case, for the IKEv2 responder, this is the authenticated identity. Unless there is a single policy for all authenticated users, you do need the user identity. -----Original Message----- From: Alper Yegin [mailto:alper.ye...@yegin.org] Sent: Thursday, February 04, 2010 3:40 PM To: Yoav Nir; 'Raj Singh'; Yaron Sheffer Cc: 'ipsec' Subject: RE: [IPsec] Fwd: Issue : Regarding EAP identity Hello, Why would the IKEv2 responder need to know the real identity? There can be privacy reasons for hiding it from any entity other than the AAA/authentication server. I'm thinking that mandating AAA server to reveal that value is not necessary and also problematic. Alper > -----Original Message----- > From: ipsec-boun...@ietf.org [mailto:ipsec-boun...@ietf.org] On Behalf > Of Yoav Nir > Sent: Wednesday, February 03, 2010 10:43 AM > To: 'Raj Singh'; Yaron Sheffer > Cc: ipsec > Subject: Re: [IPsec] Fwd: Issue : Regarding EAP identity > > 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 Scanned by Check Point Total Security Gateway. _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
