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

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

Hi,all:
I have some comments on the abstract and section 1 of new version draft-ietf-dime-erp-01.
please see the comments inline!

Abstract

   EAP Re-authentication Protocol (ERP) defines extensions to the
   Extensible Authentication Protocol (EAP) to support efficient re-
   authentication between the EAP peer and an EAP re-authentication
   server through an EAP/ERP authenticator.  This document specifies
   Diameter support for ERP.  It defines a new Diameter ERP application
   to transport ERP messages between authenticator and ERP server, and a
   set of new AVPs that can be used to transport the cryptographic
   material needed by ERP server.

[Qin]:ERP authenticator and ERP server seems  new terminologies, I am wondering
      whether we need to define these terminologies in the document? Actually as 
      described in RFC5296, ER Server relevant to ERP server has already been
      defined, Is it necessary to define the same thing?

1.  Introduction

   [RFC5296] defines the EAP Re-authentication Protocol (ERP).  It
   consists in the following steps:

   1.  Bootstrapping: a root key for re-authentication is derived from
       the Extended Master Session Key (EMSK) created during EAP
       authentication [RFC5295].  This root key is transported from the
       EAP server to the ER server.

   [Qin]: I agree implicit bootstrapping is not Re-authentication. However 
          I am wondering whether explicit bootstrapping can still be viewed as 
          Re-authentication?
          So whether dividing ERP into two step will cause a little confusion?

   2.  Re-authentication: a one-round-trip exchange between the peer and
       the ER server, resulting in mutual authentication.  To accomplish
       the EAP reauthentication functionality, ERP defines two new EAP
       codes - EAP-Initiate and EAP-Finish.

   This document defines how Diameter transports the ERP messages (Re-
   authentication step).  For this purpose, we define a new Application
   Id for ERP, and re-use the Diameter EAP commands (DER/DEA).

   This document also discusses the distribution of the root key
   (bootstrapping step), either during the initial EAP authentication
   (implicit bootstrapping) or during the first ERP exchange (explicit
   bootstrapping).  Security considerations for this key distribution
   are detailed in [RFC5295].

---

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

Hello Qin,

Thank you for the detailed review. Please find my comments inline. Sorry
for my late answer.

> defined, Is it necessary to define the same thing?
You are right, we must use consistent terminology with RFC5296. I will
change "ERP server" to "ER server" and replace "EAP/ERP authenticator"
with "Compatible authenticator". Do you agree with these changes?

> So whether dividing ERP into two step will cause a little confusion?
Explicit bootstrapping in a kind of special case: the re-authentication
happens between peer and home ER server, and also carries the key
material for the local ER server. Therefore it is a "step 2" for the
home server and "step 1" for the local server. In any case, the home
server must already be bootstrapped -- or collocated with the EAP
server, as we currently assume, and derive the key when it is needed.
But from a process point of view, I believe these two separate steps
still apply to any ERP exchange -- only the timing may be different with
some scenarios. Does this clarify the text?

Sebastien.

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

---

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

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

> with "Compatible authenticator". Do you agree with these changes?

[Qin]: I agree to change ERP Server to ER Server.
As regarding "EAP/ERP authenticator", I think the definition of authenticator 
has already implied that it supports EAP authentication, ERP is a extension to EAP,
So it seems not neccessary to emphasize whether authenticator support EAP. Given
"ER Peer" and "ER Authenticator" defined in the RFC5296, how about say:
"
support efficient re- authentication between the *ER peer* and an EAP re-authentication
server through an *ER authenticator*.
"
instead of 
"
support efficient re-  authentication between the EAP peer and an EAP re-authentication
   server through an EAP/ERP authenticator.
"

> some scenarios. Does this clarify the text?

[Qin]:  What I am difficult to understand is Explicit bootstrapping actually can be understand
as full ERP authentication with the home ER server. Because Explicit bootstrapping uses ERP message
 with bootstrapping flag turned on to request the key materials. In this sense, in the Explicit bootstrapping, 
key transport happens in the same step.
Unlike Explicit bootstrapping, Implicit bootstrapping uses EAP message to request key materials.Therefore 
Re-authentication will not happen with Implicit bootstrapping at the same time. So for Implicit bootstrapping,
I agree with you implicit bootrapping step happen before re-authentication. However for Explicit bootstrapping,
I am afraid bootstrapping and Re-authentication happens in the same step at the same time.
To avoid confusion, how about say:
step 1 is for Re-auth root key transport, 
Step 2 is for Re-authentication, i.e., using key material from step 1 to perform Re-auth.

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

---

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

Hi Qin,

> So it seems not neccessary to emphasize whether authenticator support EAP.
I understand your point now, thank you. Since it's only the abstract, I
think we should try and avoid using too much abbreviations such as "ER".
I'll change to more explicit language using words instead of acronyms.

>  with bootstrapping flag turned on to request the key materials.
It's actually a strange behavior of ERP (which I hope would be fixed in
new revision if any): the peer sets the B flag to request for key
material on behalf of an hypothetic local ER server... In explicit
bootstrapping we have really two different things in the same exchange:
1) peer <-> home server : re-authentication
2) local ER server <-> home server : bootstrapping
For (1) to occur, it supposes that the home server already have the key
material. Therefore it is either collocated with EAP server (and so the
key material is locally available) or has already bootstrapped
previously (kind of recursive architecture in this case).

> Step 2 is for Re-authentication, i.e., using key material from step 1 to perform Re-auth.
I don't see the difference between your proposal and the current text...
Can you highlight what is changed?

Thanks ,
Sebastien.

---

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

Hi,Sebastien:
----- Original Message ----- 
From: "Sebastien Decugis" <[email-masked]>
To: <[email-masked]>
Sent: Monday, September 14, 2009 12:22 PM
Subject: Re: [Dime] Comments on abstract and section 1 of newversiondraft-ietf-dime-erp-01

> I'll change to more explicit language using words instead of acronyms.

[Qin]: Okay.

> material on behalf of an hypothetic local ER server... 

[Qin]: It is not very strange to me. Because it is not the ER server but the peer to do bootstrapping.
So it is natual for peer to set B flag in the ERP message. when the peer gets response from the home server,
the peer need to compute DSRK, DS-rRK, DS-rIK, and keyName- NAI based on the local domain name
and install these key on the peer. That's what is called "bootstrapping", in my understanding.

>In explicit bootstrapping we have really two different things in the same exchange:

[Qin] Unlike explicit bootstrapping, Implicit bootstrapping only has 2) in the exchange.
1) does not happen in the implicit bootstrapping. Am I right?
So I am wondering whether we can say ERP has two steps? or we just say Explicit ERP bootstrapping
has two step or two phase.

Another concern is whether we can say local ER server<--> home ER server can be viewed as "bootstrapping"?
How to understand bootstrapping? 

> Can you highlight what is changed?

[Qin]: The difference is using *Re-auth root key transport* instead of *Bootstrapping*
Because I am afraid that bootstrapping is not used by local server but by the peer to request Re-authentication key.
What do you think of it?

---

From: Sebastien Decugis <[email-masked]>
Date: Mon, 14 Sep 2009 17:34:26 +0900

Hi again,

> and install these key on the peer. That's what is called "bootstrapping", in my understanding.
The peer does not receive any key material during the ERP exchange: it
already possess the EMSK. The only eventual benefit for the peer in
explicit bootstrapping is to learn the domain of the local ER server.
The main goal is the bootstrapping of this local server, IIUC.

> 1) does not happen in the implicit bootstrapping. Am I right?
Yes that is right for the bootstrapping exchange; but then later ERP
exchange are performed to actually re-authenticate the peer.

> How to understand bootstrapping? 
Bootstrapping is providing the ERP root key to the ER server that need
it, to perform the re-authentication of the peer.

> Because I am afraid that bootstrapping is not used by local server but by the peer to request Re-authentication key.
Well, since bootstrapping is creating and transporting the key material
to the ER server, I still think it is equivalent :) The peer never
request any key to the server, otherwise there would be no security...

Best regards,
Sebastien.

---

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

Hi, Sebastien:
----- Original Message ----- 
From: "Sebastien Decugis" <[email-masked]>
To: <[email-masked]>
Sent: Monday, September 14, 2009 4:34 PM
Subject: Re: [Dime] Comments on abstract and section 1 ofnewversiondraft-ietf-dime-erp-01

> The main goal is the bootstrapping of this local server, IIUC.

[Qin]: I agree key derivation and transport happens during bootstrapping,
          But I am still difficult to understand bootstrapping is identical to key transport.
          on the other hand, as described in the section 5.1 of RFC5296:
          "
          The peer MAY also* initiate bootstrapping* to fetch information
                                          ++++++++++++++++
         such as the rRK lifetime from the AAA server.

          "
          From the above description, it is the peer who accomplish bootstrapping, 
         if we say local server is bootstrapped, I am wondering whether it 
         is consistent with the description in the RFC5296,what am I missing?

         Another reason is during bootstrapping, it is not the local server but the peer who 
         turn on "bootstrapping" flag in the ERP message. Is it enough to justify who make 
        bootstrapping? -:)

> exchange are performed to actually re-authenticate the peer.

[Qin]:  I am wondering whether the implicit bootstrapping can be viewed as part of ERP?

> it, to perform the re-authentication of the peer.

[Qin]: Isn't consistent with bootstrapping described in RFC5296? 

> request any key to the server, otherwise there would be no security...

[Qin] I neve say the peer need to request any key from the server.
The peer can fetch local domain name during explicit ERP bootstrapping and base on local name to derive Re-auth root keys,
isn't it termed bootstrapping? :-)
Anyway, if you can redefine bootstrapping in the document different from RFC5296, that's another thing.