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

[Sebastien Decugis <sdecugis at nict.go.jp>]

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.

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

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

Thanks ,
Sebastien.

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