Re: [Dime] Comments on abstract and section 1 of new versiondraft-ietf-dime-erp-01

[Qin Wu <sunseawq at huawei.com>]

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


> Hello Qin,
> 
> Thank you for the detailed review. Please find my comments inline. Sorry
> for my late answer.
> 
> 
>> Abstract
>> [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?
> 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?

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

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

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

> 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