Dan, > 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.
I guess it can be specified. > 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. Isn't IDi what IKE deals with? > 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) I'm not aware, either. In other uses of AAA (such as with WiFi, WiMAX, 3GPP2, etc.) I know that the subscriber ID is hidden from the NAS. There are even specific methods deployed for that purpose. So, disclosing that ID would not be acceptable there. I'm just not sure if the same privacy concerns apply to the VPN deployments. > 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? If you don't do that, then you have to maintain "per subscriber policy" on each one of the VPN gateways. Now that starts defeating some of the purpose that AAA was offloaded to a centralized/dedicated server. Regards, Alper > > 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
