Re: [HOKEY] [IPsec] New I-D: draft-nir-ipsecme-erx-00

Hi,
----- Original Message ----- 
From: "Yoav Nir" <ynir@checkpoint.com>
To: "Qin Wu" <sunseawq@huawei.com>
Cc: <ipsec@ietf.org>rg>; <hokey@ietf.org>
Sent: Wednesday, May 04, 2011 3:00 PM
Subject: Re: [IPsec] New I-D: draft-nir-ipsecme-erx-00

> 
> On May 4, 2011, at 9:18 AM, Qin Wu wrote:
> 
>> Hi,
>> ----- Original Message ----- 
>> From: "Yoav Nir" <ynir@checkpoint.com>
>> To: "Qin Wu" <sunseawq@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."

[Qin]: RFC5296 does not specify how UserName is copied into Access-Accept. The reason this part is about authorization which is beyond scope of ERP document.
But I agree the different user name can be used. 
One way in my mind is 
Radius Server could use KeyName-NAI to look up real user name and add it into the Accss-Request.

> Do current implementations copy the KeyName-NAI to the Access-Accept?  

[Qin]: I am not aware of it. But it could be.

>> 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.

[Qin]: Okay. the authenticated identity you mentioned is user identity, right?
I think we should be careful to differentiate these identities. becos it seems there are lots of identities:
e.g., EAP identity, IKEv2 identity and User identity.

> Yoav
> 
> 
> _______________________________________________
> IPsec mailing list
> IPsec@ietf.org
> https://www.ietf.org/mailman/listinfo/ipsec