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
