Re: [Dime] Review of draft-ietf-dime-rfc3588bis-17

[Qin Wu <sunseawq at huawei.com>]

Hi, Victor:
Please see inline.
----- Original Message ----- 
From: "Victor Fajardo" <vfajardo at tari.toshiba.com>
To: "Qin Wu" <sunseawq at huawei.com>
Cc: <dime at ietf.org>
Sent: Monday, June 22, 2009 9:46 PM
Subject: Re: [Dime] Review of draft-ietf-dime-rfc3588bis-17


> Hi Qin,
> 
> Thanks. Comments inline:
> 
>> Hi, Vicotor:
>> Thank for your feedback. I have a few more followup comments below, Please see inline.
>>
>> Regards!
>> -Qin
>> ----- Original Message ----- 
>> From: "Victor Fajardo" <vfajardo at tari.toshiba.com>
>> To: "Qin Wu" <sunseawq at huawei.com>
>> Cc: <dime at ietf.org>
>> Sent: Thursday, June 18, 2009 9:21 PM
>> Subject: Re: [Dime] Review of draft-ietf-dime-rfc3588bis-17
>>
>>
>>   
>>> Hi Qin,
>>>
>>> Thanks for the review.
>>>     
>>>> [snip]
>>>> "
>>>> 1.  Introduction
>>>> .............
>>>> Server-initiated messages
>>>>
>>>> While RADIUS server-initiated messages are defined in [RFC5176],
>>>> support is optional.  This makes it difficult to implement
>>>> features such as unsolicited disconnect or reauthentication/
>>>> reauthorization 
>>>> "
>>>>  [Qin] Reauthentication/reauthoriation is not necessary to be server-initiated?
>>>>   
>>>>       
>>>     
>>>>   e.g., In RFC5296"EAP Extensions for EAP Re-authentication Protocol (ERP)
>>>>    ", EAP Re-authentication is host/peer initiated, isn't it?
>>>>    So it is not very accurate to say the reauthentcation is server-initiated .
>>>>
>>>> "
>>>>   
>>>>       
>>> mmm ... the statement above is just giving an example of 
>>> server-initiated messages. i don't think it stating that re-authz are 
>>> server-initiated only.
>>>     
>> [Qin]:  As described in draft-ietf-dime-rfc3588bis-17,
>> "
>> This makes it difficult to implement features such as unsolicited disconnect or reauthentication/ reauthorization 
>> "
>> It seems reauthentication/reauthorization is a generic feature used here which, I am afraid, does not include EAP re-authentification case
>> described in RFC5296. In this sense, I would like to suggest reword as:
>> "
>> This makes it difficult to implement features such as unsolicited disconnect or reauthentication/ reauthorization for Credit control.
>> "
>>   
> 
> 
> I'm not sure I fully understand. Do you mean you don't want a generic 
> statement because it would not include EAP ? I was thinking the 
> opposite. A generic statement would encompass a broader scope right ?

[Qin]: Surely we need the generic statement here. However as described in the section 5.5 of RFC4006, the reauthentication/ reauthorization mentioned in the section 8.3 of draft-ietf-dime-rfc3588bis-17 is initiated by the server and only applicable for real-time credit control and can not be applicable for EAP Re-authentication described in RFC5296 or Diameter Support for EAP Re-authentication Protocol. Because EAP Re-authentication is initiated by the Client/Peer. That's my difficulty. What am I missing?

>> [snip]
>>
>>   
>>>> "
>>>> 8.3.  Server-Initiated Re-Auth
>>>>
>>>>    A Diameter server may initiate a re-authentication and/or re-
>>>>    authorization service for a particular session by issuing a Re-Auth-
>>>>    Request (RAR).
>>>> "
>>>> [Qin] Can you provide some reference as regarding this mechanism?
>>>>   
>>>>       
>>> I'm guessing diameter credit-control has server-initiated RAR ...
>>>     
>>
>> [Qin]
>> Does it seem confusion to use the terminology "Re-Auth" in Credit Control  which conflicts with
>> the terminology "Re authentication" used in the RFC5296 or Diameter Re-authentication WG draft?
>> i.e, Does Re-auth in Credit control has the same meaning as the Re-auth in the EAP reauthentication described in the RFC5296?
>>   
> 
> I'm not too sure about the history for Diameter CC nor the reasoning for 
> its terminology. I guess the more pertinent question is how this relates 
> to bis. At least for bis the term "Re-Auth" can indicate authorization 
> and/or authentication.

[Qin]: I agree. However the "Re-Auth" is also used in the Diameter Support for EAP Re-authentication Protocol.
It seems they have different meanings and scope.
 
>>>> "
>>>>    For example, for pre-paid services, the Diameter server that
>>>>    originally authorized a session may need some confirmation that the
>>>>    user is still using the services.
>>>> "
>>>> [Qin] If the security information(e.g., keys) is expired, do we need to depend on
>>>>  Server-Initiated Re-auth to renew the security information? In this case, it seems
>>>>  that the Client also can initiate this Re-auth?
>>>>   
>>>>       
>>> Yes the client can perform re-auth in this scenario. The base protocol 
>>> does not limit what the diameter applications can do. it simply provides 
>>> a framework for it.
>>>     
>>
>> [Qin] As you mentioned above, the credit-control has server-initiated RAR, it seems the 
>> server-initiated RAR has different meaning from what I examplified above, hasn't it?
>>   
> 
> Ok. Then I'm not really sure what your comparing re-auth againts. Are 
> you comparing client vs. server re-auth ? In that case, is there 
> anything broken in the bis that relates to this ?

[Qin]: See above.
Since Re-authentication is defined in the credit control in the RFC 4006, I am just confused if the same terms"Re-authentication" is used in the Diameter ERP as well  If the folks have no difficulty to distinguish the Re-authentication in the Diameter ERP from the Reauthentication in the Credit control application,
then I have no strong feeling against it.
If my understanding is not right, please correct me.
> regards,
> victor
>