Re: [Dime] Comments on abstract and section 1 ofnewversiondraft-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 4:34 PM
Subject: Re: [Dime] Comments on abstract and section 1 ofnewversiondraft-ietf-dime-erp-01


> Hi again,
> 
>> [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.
>>   
> 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.

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

>>> 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?
>>   
> Yes that is right for the bootstrapping exchange; but then later ERP
> exchange are performed to actually re-authenticate the peer.

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

>> Another concern is whether we can say local ER server<--> home ER server can be viewed as "bootstrapping"?
>> 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.

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

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

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

> Best regards,
> 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