Re: [HOKEY] Mail regarding draft-ietf-dime-erp

[Qin Wu <[e-mail]>]

Hi,
----- Original Message ----- 
From: "Glen Zorn" <[e-mail]>
To: "Qin Wu" <[e-mail]>
Cc: "Jouni Korhonen" <[e-mail]>om>; <[e-mail]>rg>; <[e-mail]>rg>; <[e-mail]>rg>; <[e-mail]>
Sent: Sunday, June 26, 2011 3:19 PM
Subject: Re: Mail regarding draft-ietf-dime-erp


> On 6/24/2011 9:03 AM, Qin Wu wrote:
> 
>> Hi,
>> I think the draft is almost stable besides we have two open issues that need to be fixed.
>> One issue is about authorization and how to do the session management. I have summarized some results
>> about what we discussed in the DIME and Hokey WG in the past and will put them into the new version 
>> of Hokey Architecture document.
>> 
>> The second issue is about Shall Hokey WG should cover the case where home realm contains
>> more than one EAP server. I believe none of existing works in the hokey WG cover this case. My opinion is the peer or user only need to talk
>> to one EAP serve during full EAP exchange. 
> 
> OK, but It's not clear to me what that has to do with ERP.  Doesn't it
> rely upon a key derived from a _previous_ EAP authentication for
> re-authentication?

[Qin]: The problem that has to do with ERP is how does the local ER server reach the the same home EAP server as the one in the previous
full EAP authentication to request DSRK if there is several EAP servers in the home realm posessing EMSK.


>> Even there is several EAP servers, the user should only choose
>> one EAP server in the home realm. How to do this is decided by Diameter Routing mechanism rather than rely on Hokey WG come up some new mechanisms to fix this. 
> 
> 
> I don't believe that ERP messages contain any data that is useful for
> the kind of intra-realm routing we're discussing.

[Qin]: In my view, the client/peer should know which home EAP server he should talk with during ERP exchange since the client had 
already communicated with the same home EAP server during full EAP authentication.

The proposal in the open issue section of draft-ietf-dime-erp is the ER server or local server save the Origin-Host 
AVP of all successful EAP/DEA in the ER server.

Comparing the above two propsals, I prefer to let the client decide how to route the message to the right server.

>> 
>> So I think we should leave this out of scope of draft-ietf-dime-erp.
> 
> Maybe so, but the problem should be at least discussed, if not solved.

[Qin]: Agree.

>> Also draft-ietf-dime-erp should not rely on the Hokey Progress. I have repeated this in the last meeting several times.
> 
> That's something that I don't really understand.  How can you write a
> Diameter application for an architecture that is not well-understood?

[Qin]: See above. As regarding the details of the second issue I mentioned, please 
see the 3rd paragraph, section 9 of draft-ietf-dime-erp.
>> 
>> Therefore I think we should move this forward with the first open issue fixed.  There is no reason to let this work get 
>> stuck there and we wait for nothing from Hokey WG. 
> 
> It seems that there is even less reason to publish an RFC that is
> incorrect or incomplete just to satisfy some desire to make "progress"
> (which seems only to arise in this WG every 4 months or so).

[Qin]:  Okay, I think we should 
decide whether the issue I mentioned above should be addressed in the DIME ERP document or Hokey
architecture document in the upcoming IETF meeting.

> ...
>