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

[Qin Wu <sunseawq at huawei.com>]

Hi, Sebastien:
Thank for your reply, Please see my followup comments.
----- Original Message ----- 
From: "Sebastien Decugis" <sdecugis at nict.go.jp>
Cc: <dime at ietf.org>
Sent: Friday, September 11, 2009 5:13 PM
Subject: Re: [Dime] Comments on section 3 of new version draft-ietf-dime-erp-01


> Hi again again, and inline...
> 
>> 3. Assumptions
>>
>> [Qin]: Since ERP root key can be derived for specific domain, I think
>> these root key can also be derived for the same part of the home
>> domain as the home EAP server,
>> am I right?
> I think I don't understand the question... For home domain, the key
> derivation is different in ERP: rRK instead of rDSRK.

[Qin]: Since DSRK is calculated based the Domain name, given home domain name
in the home domain I am wondering whether we can derive home domain specific DSRK
based on the home domain name?
Anyway, it seems not relevant to this new version draft.-:)

>> home EAP server implicitly authorizes the use of ERP within this
>> domain.
>>
>> [Qin]: I am wondering what does the home EAP server base on to
>> authorize the use of ERP within
>> given domain? Isn't it enough to assume trust relationship between
>> local domain and home domain?
> I wanted to highlight the implication of deriving a key for ERP. By
> providing an ERP root key for a visited domain, the local domain server
> implicitly authorizes the use of ERP in that domain. The consequences on
> the management of the session and other side effects should be
> understood by the home domain before accepting to derive this material.

[Qin]: Okay, I agree with your explainnation. However I have two followup comments as follows:
1. The home EAP server that uses ERP is the home ER server or not?
2. Who actually authorize the use of ERP, home EAP server or home ER server?

>> [Qin]: s/contained/contains
> Hmmm I will try a different phrasing here, the sentence is too
> complicated anyway. Thank you for pointing it out.
[Qin]: Okay. 
>>
>> [Qin]:What does "(recommanded)"? recommended?
> Oops that is French-English sorry I will fix it. Yes, I meant
> "recommended".
[Qin]: Okay.
>> Is there any missing text here? I am wondering ability to answer
>> a DER message can be covered by Diameter operations?
> There are two different operations: support to send the rRK/rDSRK in
> Diameter message; and support to answer an EAP-Initiate ERP message.
> While the first is mandatory, the second is only needed to support
> explicit bootstrapping scenario. That is the rationale for the
> "(recommended)" notation.

[Qin]: Well, I understand.

>> Allow the new ERP command codes (EAP-Initiate and EAP-Finish) in
>> its EAP pass-through mode.
>> (optional) Send the EAP-Initiate/Re-Auth-Start message
>> [Qin]: I am wondering what's the difference between the first bullet
>> and the second bullet?
> The EAP-Initiate/Re-Auth-Start message is optionally sent by the NAS to
> the *peer* to initiate ERP exchange, as described in RFC5296 (second
> bullet). The other messages (from first bullet) are exchanged between
> the peer and the server, the NAS is only acting as a passthrough. But
> EAP passthrough definition requires that unknown EAP codes messages are
> dropped, so the NAS must be changed to allow the ERP codes as well.

[Qin]: Right, thank for your clarification.

>> We consider at most one logical ER server entity in a domain. If
>> several physical servers are deployed for robustness, a replication
>> mechanism must be deployed to synchronize the ERP states (root keys )
>> between these servers. This replication mechanism is out of the
>> scope of this document. If several ER servers are deployed in the
>> domain, we assume that they can be used interchangeably.
>> [Qin] Does this mean all the ER server in one domain can be seem as
>> one logical ER server?
> Yes it is the assumption here in this version of the document. If we
> don't have this assumption, we must provide a way to either:
> - synchronize explicitly the states between different ER servers inside
> one domain.
> - ensure that messages belonging to one session are routed to the
> appropriate ER server.
> Since the primary rationale for having several ER server is robustness,
> it is logical to assume that the servers must be synchronized in any
> case. Since synchronization of states in Diameter between several
> servers is a general issue, it is better not to define a solution only
> for ERP application. A new Diameter application could be defined for
> this matter, but we don't want to do this inside Diameter ERP. So, all
> in all, it is easier to simply assume the servers are synchronized and
> can be used interchangeably. Does that make sense?

[Qin]: I agree, without this assumption, it seems ERP exchange and EAP 
Re-authentication operations on the peer, authenticator and server will
be complicated.
I wonder what do you think of the case where the home realm contains several
 EAP servers described in the "open issues"section? Isn't it the same thing?

> Best regards,
> Sebastien.
> 
> -- 
> Sebastien Decugis
> Research fellow
> Network Architecture Group
> NICT (nict.go.jp)
> 
> _______________________________________________
> DiME mailing list
> DiME at ietf.org
> https://www.ietf.org/mailman/listinfo/dime