Re: [Dime] Comments on section 2 of new version draft-ietf-dime-erp-01
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
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...
>>> 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. 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.
BR
Sebastien.
--
Sebastien Decugis
Research fellow
Network Architecture Group
NICT (nict.go.jp)
Note: Messages sent to this list are the opinions of the senders and do not imply endorsement by the IETF.