Re: [Dime] Comments on section 2 of new version draft-ietf-dime-erp-01

[Qin Wu <sunseawq at huawei.com>]

Hi, Sebastien:
----- Original Message ----- 
From: "Sebastien Decugis" <sdecugis at nict.go.jp>
To: "Qin Wu" <sunseawq at huawei.com>
Cc: <dime at ietf.org>
Sent: Monday, September 14, 2009 12:36 PM
Subject: Re: [Dime] Comments on section 2 of new version draft-ietf-dime-erp-01


> Hi,
> 
>> [Qin]:
>> If only the local server support ERP, I think it is necessary for local ER server to change
>> its application ID from ERP to EAP.
>> However If the local server and home server both support ERP, I don't think 
>> it is necessary for local ER server to change its application ID from ERP to EAP, 
>> am I right?
>>   
> The EMSK is located on the EAP server, not ER server. For bootstrapping,
> the message *must* therefore reach the *EAP* server. We might go through
> the ER server in the home domain but it would be just an additional
> useless relay...
> The reason for changing the application Id is routing of the message to
> the proper server (the one that has the EMSK).
> Of course if there is only one server in the domain, the application Id
> can be anything... But we want to separate the logical entities...

[Qin]: Sorry for your misunderstanding here. what I want to say here is
suppose both the local ER server and the home ER server support *EAP*, 
we can simply assume the home EAP server and the peer has already export
the same EMSK during the initial EAP exchange. In this way, the Re-authentication
root key can be derived  from EMSK. There is no extra delay to be introduced.

>>>> another example when home EAP server does not support ERP    
>>> In that case, the ER server cannot obtain the root key required for ERP
>>> function...
>> [Qin]: In the Implicit Bootstrapping, the local ER server can obtain the root key 
>> from the home EAP server through local AAA agent or proxy.You can check
>> the following errata report in the hokey ML:
>> http://www.ietf.org/mail-archive/web/hokey/current/msg01662.html 
>> In this scenario, the local ER can fetch root key from the local AAA agent or
>> the local AAA agent can manually install root key on the local ER, am I right?
>>   
> Well, even if the errata says so, if the EAP server is not able to
> derive ERP material, I cannot see how the AAA server (a third entity?)
> would be able to obtain it...
> Furthermore, this errata assumes that some protocol such as Diameter is
> available to do all the operations it describes. If we want to
> accommodate such architecture, we have to define new messages for key
> exchanges only (maybe even another Diameter application Id). Anyway, I
> don't see the benefit of this compared to the architecture we define
> currently... I think this can be discussed in next IETF meeting with
> interested people.

[Qin]: Sorry for your misunderstanding, Here mentioned AAA server or AAA agent  is not third entity but the EAP sever.
So it is not necessary to define new message for key exchange here. If the EAP sever is not able to derive ERP stuff,
the ERP exchange will fail and fall back to the full EAP exchange.

>> [Qin]: Sorry for your misunderstanding. I just want to figure out in which scenario EAP/DER
>> and EAP/DEA will be used? 
>> In my understanding, If the home server does not support ERP, the local ER server collocated with
>> the local AAA agent, we can use EAP/DER and EAP/DEA, in this sense, we need to change application ID from
>> EAP to ERP, as you mentioned above.
>>   
> As I wrote earlier, the rationale for changing the application Id is to
> route the message to the server that has the EMSK material, which is
> needed for bootstrapping.
> 
> Unfortunately, so far we don't consider the situation where several EAP
> servers are in the home domain (and only 1 has the EMSK). It must be
> addressed.

[Qin]: Okay.
Suppose there is serveral EAP servers in the home domain, 
If one EAP server can not use specific EAP method to export EMSK, why do we
need to deploy such kind of EAP server? 

> BR
> Sebastien.
> 
> -- 
> Sebastien Decugis
> Research fellow
> Network Architecture Group
> NICT (nict.go.jp)
>