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.
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. 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) 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? regards, Dan. On Tue, February 9, 2010 2:53 am, Alper Yegin wrote: > Dan, > > I'm not aware of any such document. > > Alper > > >> -----Original Message----- >> From: Dan Harkins [mailto:dhark...@lounge.org] >> Sent: Monday, February 08, 2010 8:13 PM >> To: Alper Yegin >> Cc: 'Yoav Nir'; 'Raj Singh'; 'Yaron Sheffer'; 'ipsec' >> Subject: Re: [IPsec] Fwd: Issue : Regarding EAP identity >> >> >> Hi Alper, >> >> What document describes how a AAA server communicates selector and >> SPD information for this authenticated peer to an IKEv2 responder? >> >> Dan. >> >> On Mon, February 8, 2010 1:41 am, Alper Yegin wrote: >> > Yoav, >> > >> > When the IKEv2 responder offloads the Authentication, Authorization, >> and >> > Accounting (AAA) responsibilities to a centralized AAA server, it is >> no >> > longer in the business of figuring out who the peer is, if the peer >> is >> > really who it claims it is, what policies to apply to the peer. These >> are >> > the things handled by the AAA server, and communicated to the IKEv2 >> > responder. "Policy" needs to be enforced by the IKEv2 responder, but >> the >> > policy is determined by and communicated to the responder by the AAA >> > server. >> > >> > Alper >> > >> > >> > >> > >> > >> > >> >> -----Original Message----- >> >> From: Yoav Nir [mailto:y...@checkpoint.com] >> >> Sent: Thursday, February 04, 2010 3:45 PM >> >> To: 'Alper Yegin'; 'Raj Singh'; Yaron Sheffer >> >> Cc: 'ipsec' >> >> Subject: RE: [IPsec] Fwd: Issue : Regarding EAP identity >> >> >> >> 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 dont think we can specify MUST requirements for the AAA >> servers, >> >> > because were 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 doesnt give us a real identity, then something >> is >> >> > wrong. But this distinction is a matter for local policy, which I >> >> dont >> >> > 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, theres 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 >> > > > > _______________________________________________ > 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
