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

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

2.  Terminology

   This document uses terminology defined in [RFC3748], [RFC5295],
   [RFC5296], and [RFC4072].

   "Root key" (RK) or "bootstrapping material" refer to the rRK or rDSRK
   derived from an EMSK, depending on the location of the ER server in
   home or foreign domain.

   We note in this document ERP/DER a Diameter-EAP-Request command with
   the Application Id set to Diameter ERP application.  On the same
   model, we use ERP/DEA, EAP/DER and EAP/DEA.
   
   [Qin]: what does the same model mean? how about saying:
   "
   We note in this document ERP/DER *refer to* a Diameter-EAP-Request Command with the
   Application Id set to Diameter ERP application. *Similarly*, we use ERP/DEA, EAP/DER
   and EAP/DEA
   "
   [Qin] I am wondering how EAP/DER and ERP/DER can be used in the same one roundtrip exhange
   between the authenticator, ER server and home EAP server. In my understanding, when to use ERP/DER
   and when to use EAP/DER depends on the deployment scenario and bootstrapping mode. e.g., in implicit
   bootstrapping mode, we use EAP/DER, in explicit bootstraping mode, we use ERP/DER?
   another example when home EAP server does not support ERP and ER server support EAP, in this case,
   EAP/DER and EAP/DEA can be used between ER server with EAP proxy function support and home EAP server.
   Am I right?

---

From: Sebastien Decugis <[email-masked]>
Date: Fri, 11 Sep 2009 17:51:16 +0900

Hi again, comments inline...

> Application Id set to Diameter ERP application. *Similarly*, we use
Agreed, my phrasing was quite bad :D I will change it to something
better, such as what you are suggesting. Thank you for catching this.

> bootstrapping mode, we use EAP/DER, in explicit bootstraping mode, we
This is explained in the explicit mechanism description later in the
document... Basically the local ER server proxies the request and
changes its application Id, so ERP/DER becomes EAP/DER.

> 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...
> and ER server support EAP, in this case,
I don't really understand what you are implying here, sorry. Can you
clarify?

Sebastien.

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

---

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

Hi, Sebastien:
----- Original Message ----- 
From: "Sebastien Decugis" <[email-masked]>
Cc: <[email-masked]>
Sent: Friday, September 11, 2009 4:51 PM
Subject: Re: [Dime] Comments on section 2 of new version draft-ietf-dime-erp-01

> changes its application Id, so ERP/DER becomes EAP/DER.

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

> In that case, the ER server cannot obtain the root key required for ERP
[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?

> I don't really understand what you are implying here, sorry. Can you

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

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

---

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

Hi,

> it is necessary for local ER server to change its application ID from ERP to EAP, 
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...

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

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

---

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

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

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

> currently... I think this can be discussed in next IETF meeting with

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

> servers are in the home domain (and only 1 has the EMSK). It must be

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

---

From: Sebastien Decugis <[email-masked]>
Date: Tue, 15 Sep 2009 10:51:57 +0900

Hi,

Sorry for late answer.

> suppose both the local ER server and the home ER server support *EAP*, 
...
> the same EMSK during the initial EAP exchange.
That's the base assumption of ERP, yes.
>  In this way, the Re-authentication
Do you mean that intermediary nodes (such as local ER server) can derive
the EMSK also? This would be a security issue...

> the ERP exchange will fail and fall back to the full EAP exchange.
I think this is what is written in the document, yes...

> need to deploy such kind of EAP server? 
There can be several EAP servers that are able to derive EMSK...

Sebastien.