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

[Qin Wu <sunseawq at huawei.com>]

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


> Hi Qin,
> 
>> 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.
> 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.

[Qin]: Okay.

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

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

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


>> 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.
>>   
> I don't see the difference between your proposal and the current text...
> 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?

> Thanks ,
> 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