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
