Hi Raj,
RFC 3748 (the RFC defining EAP) says:
The Identity Response may not be the appropriate
identity for the method; it may have been truncated or obfuscated
so as to provide privacy, or it may have been decorated for
routing purposes.
In other words, the identity the IKEv2 gateway receives is worthless
for authentication purposes and authentication is what IKE does. That
identity is just to decide what EAP method to use with the peer. It is
not an "authenticated identity" as you suggest. RFC 3748 further
recommends:
[F]or an EAP method to include an identity exchange that supports
per-packet authentication, integrity and replay protection, and
confidentiality.
So the identity that is used for _authentication of the peer_ is something
that is just passed through the IKEv2 gateway and may even be encrypted by
a key that the IKEv2 gateway does not have access to.
Imagine the next time some guard at a building or in an airport says,
"let me see your ID please" when you attempt to gain entry and you say,
"sorry you're not in a position to see that but our shared friend here
can vouch for me." How do you think that's gonna fly? Not too well, I'd
imagine.
regards,
Dan.
On Thu, February 4, 2010 8:56 am, Raj Singh wrote:
> Hi Yoav,
>
> According to RFC-3579 [Appendix-A] RADIUS (Remote Authentication Dial In
> User Service) Support For Extensible Authentication Protocol (EAP) shows
> that NAS (IKEv2 Gateway) sends an EAP-Request/Identity as the initial
> packet
> to IKEv2 initiator. Here IKEv2 will come to know EAP identity and apply
> policy based on authenticated identity.
>
> We can add text at end of section 2.16 that if authenticated identity is
> not
> sent by AAA server to IKEv2 responder, the IKEv2 responder can begin EAP
> authentication by sending EAP-Request/Identity as the initial packet to
> IKEv2 initiator.
>
> Regards,
> Raj
>
> 2010/2/4 Yoav Nir <y...@checkpoint.com>
>
>> 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
>
_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
