Yaron Sheffer wrote:
Hi Vijay,
I don't have the details at hand, but in 3GPP land it is common for the
client to send all sorts of temporary identities, and for the AAA server to
respond to the Packet Data Gateway (that's our gateway) with the client's
"true" identity (IMSI, MSISDN, whatever). Such permanent identity could
serve as the basis for a redirect decision. Do we have people on the list
familiar with these specs?
I am aware of these specs. The last EAP message with "Success" from the
AAA server to the gateway, has the real identity of the client as a
RADIUS attribute (for example). But we don't have a reference for this
in the IETF, since RFC 4306 says that there shouldn't be an EAP Identity
Request/Response exchange.
In RFC 4877, we did mention that the Mobile IPv6 home agent MUST acquire
the true identity of the mobile node when EAP is used, but left the
actual mechanism out of scope. Section 8 of RFC 4877 says
When EAP is used, the identity presented by the mobile node in the
IDi field may not be the actual identity of the mobile node. It
could be set to an identity that is used only for Authentication,
Authorization, and Accounting (AAA) routing purposes and selecting
the right EAP method. It is possible that the actual identity is
carried inside EAP, invisible to the home agent. While IKEv2 does
not allow an EAP Identity Request/Response message exchange, EAP
methods may exchange identities within themselves. In this case, the
home agent MUST acquire the mobile node's identity from the
corresponding AAA server. How the home agent acquires the mobile
node's identity is out of scope for this document.
One option would to be adapt the above text to say that if the client
had presented a temporary identity to the gateway in the IKE_AUTH
request message and the gateway does acquire the real identity of the
client after the EAP exchange, then the gateway can decide to redirect
based on the true identity. The REDIRECT payload would then be sent in
the IKE_AUTH response that carries the EAP success message.
Vijay
Thanks,
Yaron
-----Original Message-----
From: Vijay Devarapalli [mailto:[email protected]]
Sent: Tuesday, March 17, 2009 0:12
To: Yaron Sheffer; Tero Kivinen
Cc: IPsecme WG
Subject: RE: [IPsec] Redirect during IKE_AUTH (was Re: WG Last Call:draft-
ietf-ipsecme-ikev2-redirect-04)
Hi Yaron, Tero,
We don't really have a protocol extension (EAP, RADIUS or Diameter) for
the AAA server to tell the IKEv2 gateway to redirect the client to
another gateway.
In addition, if there is an EAP exchange, the true identity of the
client is not revealed to the gateway.
So I am not sure on what basis the gateway would redirect the client in
message #10 and #18 in Tero's email.
http://www.ietf.org/mail-archive/web/ipsec/current/msg04025.html
My proposal is to limit the REDIRECT payload to appear in message #4 (in
the first IKE_AUTH response), based on the identity presented by the
client. And leave EAP scenarios out of scope for this document. If
someone wants the AAA server to redirect the client based on the EAP
exchange, a separate document could be written. And this document can
specify that the REDIRECT message can be sent in message 10.
Does this sound good?
Vijay
On Thu, 2009-03-12 at 16:07 -0400, Yaron Sheffer wrote:
We should not do the redirect based on an asserted, unautheticated
identity.
Going back to Tero's previous message on this thread, I think we should
allow redirect both in message 10 and 18 (i.e. following both EAP
rounds,
and where the EAP state machine is "idle"). The gateway probably needs
the
AAA server to tell it where to redirect to, anyway.
In message 10 the gateway still doesn't know that the client wants to
perform secondary authentication, but I propose to ignore this issue for
simplicity.
Thanks,
Yaron
-----Original Message-----
From: [email protected] [mailto:[email protected]] On Behalf
Of
Tero Kivinen
Sent: Thursday, March 12, 2009 14:15
To: Vijay Devarapalli
Cc: IPsecme WG; Yoav Nir; [email protected]
Subject: Re: [IPsec] Redirect during IKE_AUTH (was Re: WG Last Call:
draft-ietf-ipsecme-ikev2-redirect-04)
Vijay Devarapalli writes:
The one significant piece of information that the gateway has during
the
IKE_AUTH exchange, that it didn't have during the IKE_SA_INIT
exchange,
is the identity of the client. Some folks want to redirect the
client
based on whatever identity it presents. So if thats they case, the
first
IKE_AUTH response would be used for sending the REDIRECT payload. If
the
gateway wanted to redirect the client because of load conditions, it
would have done it during the IKE_SA_INIT exchange itself. I don't
expect the EAP exchange or the multiple auth exchange to trigger a
redirect. We can make this explicit if needed.
I tought someone wanted to do some kind of radius lookup to select
where client is redirected to and in some cases client might not be
sending the ID used for that in the ID payload but might use the EAP
identity request/reply (even though RFC4306 3.16 says SHOULD NOT).
If it will be enough to only see IDi to do redirect, meaning we can
always restrict the REDIRECT to message 4, then it might be even
acceptable to make that change. The main reason I was against having
REDIRECTS in IKE_AUTHs is that there is so many locations where it can
be and testing all possible combinations with all possible
authentication methods and other extensions gets very complicated.
--
[email protected]
_______________________________________________
IPsec mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ipsec
Scanned by Check Point Total Security Gateway.
Scanned by Check Point Total Security Gateway.
Scanned by Check Point Total Security Gateway.
_______________________________________________
IPsec mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ipsec
