On May 4, 2011, at 9:18 AM, Qin Wu wrote:
> Hi,
> ----- Original Message -----
> From: "Yoav Nir" <y...@checkpoint.com>
> To: "Qin Wu" <sunse...@huawei.com>
> Cc: <ipsec@ietf.org>
> Sent: Wednesday, May 04, 2011 1:30 PM
> Subject: Re: [IPsec] New I-D: draft-nir-ipsecme-erx-00
>
>
>>
>> On May 4, 2011, at 4:50 AM, Qin Wu wrote:
>>
>>>>> - I am missing the "authenticated peer identity", which I would assume
>>>>> should arrive from the AAA server. This should be the basis of RFC4301
>>>>> policy decisions on the IKE gateway. Does ERP provide this identity?
>>>>
>>>> The EAP-Initiate/Re-auth packet carries a keyName-NAI TLV, but that is
>>>> sent from the client (or "peer") to the authentication server through the
>>>> gateway. (section 5.3.2 of the bis document)
>>>> The EAP-Finish/Re-auth packet also carries a keyName-NAI TLV, and that is
>>>> sent from the authentication server through the gateway to the client.
>>>> But these don't really help, because the username part of NAI is the
>>>> 64-bit EMSKname, which is not directly related to user name.
>>>> However, these messages come within an Access-Accept packet from the
>>>> RADIUS server, and those include a proper user name.
>>>
>>> [Qin]: If you are talking about the second identity specified in section
>>> 6.4 of RFC5998, I think, unlike EAP, ERP does not provide such identity.
>>> ERP only define two types: one is Re-auth-Start, the other is Re-Auth.
>>>
>>> KeyName-NAI TLV defined in RFC5296 and RFC5296bis more looks like the first
>>> idenity described in section 6.4 of RFC5998.
>>> As decribed in section 5.1 of RFC5296,
>>> "
>>> When an ERP-capable authenticator receives the EAP-Initiate/
>>> Re-auth message from a peer, it copies the contents of the
>>> ^^^^^^^^^^^^^^^^^^^^
>>> keyName-NAI into the User-Name attribute of RADIUS [13].
>>> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>>> "
>>
>> But what does the RADIUS send in the User-Name attribute of Access-Accept?
>> How does the Authenticator know who the user is? The Authenticator needs
>> the true identity to make policy decisions.
>
> [Qin]: I assume username part of KeyName-NAI will be regarded by RADIUS
> server as User-Name during authentication.
RFC 3579 says:
"The User-Name attribute within the Access-
Accept packet need not be the same as the User-Name attribute in the
Access-Request."
Do current implementations copy the KeyName-NAI to the Access-Accept?
> Also I think it is not necessarily to couple authorization with
> authentication.
They may not be coupled in other EAP contexts, but IPsec requires policy
decisions based on authenticated identity. One way or another, the IKE
implementation needs to get the real user identity for policy decisions.
Yoav
_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
