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

From: Qin Wu <[email-masked]>
Date: Wed, 09 Sep 2009 11:56:56 +0800

3.  Assumptions

   This document makes the following assumptions.

   The Home EAP server of a peer that wants to use ERP is extended to
   support:

      Cryptographic operations needed to derive the ERP root key from
      the EMSK.  By deriving the ERP root key for a specific domain, the
      
      [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?
  
      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? 

      Diameter operations to include this root key inside an appropriate
      AVP as defined in this document, in an answer message
      corresponding to a request that contained a request for this
     
      [Qin]: s/contained/contains
      material (AVP for the request also defined in this document).

      (recommanded) Ability to answer a DER message with EAP-Payload
      containing an explicit bootstrapping ERP message.
      
      [Qin]:What does "(recommanded)"? recommended?
      Is there any missing text here? I am wondering ability to answer
      a DER message can be covered by Diameter operations?

   The Authenticator (NAS) is extended to support:

      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?

      (optional) Provide the local domain name via lower layer specific
      mechanism or via TLV in the EAP-Initiate/Re-Auth-Start message.

      Encapsulate ERP message and receive corresponding Diameter answer,
      as described in this document.

   If one of the components does not match these assumptions, the ERP
   mechanism will fail.  In such situation, a full EAP authentication
   may be attempted as a fallback mechanism.

   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?

---

From: Sebastien Decugis <[email-masked]>
Date: Fri, 11 Sep 2009 18:13:12 +0900

Hi again again, and inline...

> domain as the home EAP server,
I think I don't understand the question... For home domain, the key
derivation is different in ERP: rRK instead of rDSRK.

> 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]: s/contained/contains
Hmmm I will try a different phrasing here, the sentence is too
complicated anyway. Thank you for pointing it out.

> [Qin]:What does "(recommanded)"? recommended?
Oops that is French-English sorry I will fix it. Yes, I meant
"recommended".
> 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]: I am wondering what's the difference between the first 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] Does this mean all the ER server in one domain can be seem as
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?

Best regards,
Sebastien.

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

---

From: Qin Wu <[email-masked]>
Date: Mon, 14 Sep 2009 10:52:53 +0800

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

> 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.-:)

> 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?

> complicated anyway. Thank you for pointing it out.
[Qin]: Okay. 
> Oops that is French-English sorry I will fix it. Yes, I meant
[Qin]: Okay.
> "(recommended)" notation.

[Qin]: Well, I understand.

> dropped, so the NAS must be changed to allow the ERP codes as well.

[Qin]: Right, thank for your clarification.

> 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?

> _______________________________________________
> DiME mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dime

---

From: Sebastien Decugis <[email-masked]>
Date: Mon, 14 Sep 2009 13:47:01 +0900

Hi, again :)

> based on the home domain name?
It would seem quite logical, but the RFC5295/5296 currently specify a
different mechanism for the home domain (rRK)... So no, currently we
cannot do that unfortunately.

> 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...
> 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.

>  EAP servers described in the "open issues"section? Isn't it the same thing?
Unfortunately, the architecture for EAP is already defined, so we cannot
change it, and it has different assumptions (which are justified because
each EAP server may support a different set of EAP methods). So, we have
to deal with it, as described in the open issues...

BR
Sebastien.

---

From: Qin Wu <[email-masked]>
Date: Mon, 14 Sep 2009 15:40:40 +0800

Hi, Sebastien:
----- Original Message ----- 
From: "Sebastien Decugis" <[email-masked]>
To: <[email-masked]>
Sent: Monday, September 14, 2009 12:47 PM
Subject: Re: [Dime] Comments on section 3 of new version draft-ietf-dime-erp-01

> cannot do that unfortunately.

[Qin]: Okay. I agree with you.
But based on the definition of rRK, rRK is not derived based on domain name.
 
> don't use this in the document, I think this terminology is too vague,

[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.

> 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?

> to deal with it, as described in the open issues...
[Qin]: 
In this sense, does it mean each EAP server only support one EAP method?
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?

---

From: Sebastien Decugis <[email-masked]>
Date: Tue, 15 Sep 2009 11:00:27 +0900

Hi,

> Home ER server is refered as an logical entity that performs the server portion of ERP
The "server portion of ERP" is the key derivation, right?

> Based the above description, it is home ER server to derive DSRK from the EMSK.
Yes: the EMSK is on the EAP server, nowhere else. So only the EAP server
can use it for any purpose...

> In this sense, does it mean each EAP server only support one EAP method?
no
> 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.