Re: [Dime] Comments on section 3 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 3 of new version draft-ietf-dime-erp-01



Hi,


>>> 1. The home EAP server that uses ERP is the home ER server or not?
>>>   
>>>       
>> Can you define the "home ER server" in the context of your question? We
>> don't use this in the document, I think this terminology is too vague,
>> sorry...
>>     
>
> [Qin] Home ER server is defined in the section 2 of RFC5296.
> Home ER server is refered as an logical entity that performs the server portion of ERP
> in the home domain.
>   
The "server portion of ERP" is the key derivation, right?

>>> 2. Who actually authorize the use of ERP, home EAP server or home ER server?
>>>   
>>>       
>> The home EAP server when it derives the DSRK from the EMSK, and provide
>> it to a foreign ER server.
>>     
>
> [Qin]: What you said here  is not consistent with what RFC5296 describes. According to the section 5.1 of RFC5296,
> it said:
> "
> the home ER server MUST include the DSRK for the
>       local ER server (derived using the EMSK and the domain name as
>       specified in [3]), EMSKname, and DSRK lifetime along with the EAP-
>       Finish/Re-auth message.
> "
> Based the above description, it is home ER server to derive DSRK from the EMSK.
> Am I missing something?
>   
Yes: the EMSK is on the EAP server, nowhere else. So only the EAP server
can use it for any purpose...

> [Qin]: 
> In this sense, does it mean each EAP server only support one EAP method?
>   
no
> Given the home realm name, how the foreign ER server route the message to
> the given EAP server which support the same EAP method as the peer?
>   
For full EAP, the first message is routed by a proxy based on the EAP
method; the following messages use the Destination-Host AVP.
In ERP we should use Destination-Host also, but it is in open issues for
the moment. If you have ideas on how to solve it cleanly...

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.