Re: [Dime] [DIME] Comments about AVP for crypto key transport draft

[Qin Wu <sunseawq at huawei.com>]

Hi, Sebastine and Glen:
----- Original Message ----- 
From: "Sebastien Decugis" <sdecugis at nict.go.jp>
To: "Qin Wu" <sunseawq at huawei.com>
Cc: <dime at ietf.org>; "Glen Zorn" <glenzorn at comcast.net>
Sent: Wednesday, September 02, 2009 11:34 AM
Subject: Re: [Dime] [DIME] Comments about AVP for crypto key transport draft


> Hi Qin,
> 
>> [Qin]: The problem is when the NAS recieves MSK or rMSK, the NAS can not judge
>> whether MSK or rMSK is validated. because the NAS has no  root key. Only intermediary node and End-Server
>> can tell whether MSK or rMSK is validated. What the NAS can do is format checking, e.g.,
>> whether the lifetime of MSK is more than 0 or something else. 
>>   
> 
>> [Qin]: It may introduce security threat. Because the authenticator has no 
>> root keys and can not judge the key is validated. Only local server can validate 
>> the rMSK based on DSRK.
>>   
> 
>> [Qin]: In implicit bootstrapping aren't both the MSK & rMSK sent in the same
>> message?  How can you tell the difference between them at the NAS?
>>   
> Implicit bootstrapping is not an ERP exchange, therefore it does cannot
> derive an rMSK (no SEQ available). Only MSK is sent in that case.

[Qin]: Implicit ERP bootstrapping is actually full EAP authentication.
 However it is involved in the Implicit ERP exchange. Because the local
 ER server will request Re-authentication root key from home EAP server
 through local EAP server. So in my understanding, rMSK and MSK 
can be sent in the same message with same SEQ. Am I right?

> In my understanding explicit bootstrapping is an ERP exchange between
> peer and home server; therefore the rMSK is derived from the rRK key
> (although I could not find this clarified in RFC5296 after a quick
> search). At the same time, the rDSRK is derived to be provided to local
> server. There is no relationship between this rMSK and rDSRK, so the
> local server would not be able to check the validity of the key material
> further than the NAS.

[Qin]: As described in  RFC5296, rMSK can be derived from DSRK or EMSK. So there are two choice:
a) If rMSK and DSRK are both derived from EMSK, I think you are right. the local server can not
   check the validity of key material.
b) If rMSK is derived from DSRK, I think the local server definitely can check the validity of key material.
For security consideration, I prefer the b). 

> Anyway, these details are far away from the initial discussion about
> what is best choice for distinguishing between two different keys:
> - an enumerated AVP "Key-Type" inside the grouped AVP, or
> - a different grouped AVP code for each key types.
> Except for the different parsing and different message size, those two
> possibilities are equivalent in terms of functionality it offers...

[Qin]: Okay, Let's see what other folks think,-:).

> Best regards,
> Sebastien.
> 
> -- 
> Sebastien Decugis
> Research fellow
> Network Architecture Group
> NICT (nict.go.jp)
>