Subject: Re: [Dime] New version of draft-wu-dime-local-keytran
From: Qin Wu <[email-masked]>
To: Sebastien Decugis <[email-masked]>
Cc: [email-masked]
Date: Wed, 09 Dec 2009 14:49:18 +0800
List-Id: Diameter Maintanence and Extentions Working Group <dime.ietf.org>

Hi,Sebastien:
----- Original Message ----- 
From: "Sebastien Decugis" <[email-masked]>
To: "Qin Wu" <[email-masked]>
Cc: "Glen Zorn" <[email-masked]>; <[email-masked]>
Sent: Wednesday, December 09, 2009 12:40 PM
Subject: Re: [Dime] New version of draft-wu-dime-local-keytran

> Hi Qin,
> 
>> - USRK (2) & DSUSRK (5): RFC5295 defines a generic algorithm to derive
>> usage-specific keys. The definition alone is not sufficient to create
>> keying material: we need the usage itself to define the missing parts.
>> [Qin]: The usages for USRK and DSUSRK have been defined in the section
>> 4.2 of draft-ietf-hokey-key-mgm-13.
>> That is to say, USRK and DSUSRK may be derived in the EAP/AAA server
>> and transported in the message to the same USR-KH.
>> And then DSUSRK can be further transported from USR-KH to DSUSR-KH.
> Sorry, I have difficulties to express my idea clearly. What I mean is
> that for example the definition of USRK is just a generic method to
> derive a class of keys, we will never have a "USRK key" without any
> precision on the usage it-self (usage as in the "US" part of USRK). On
> the other hand, rRK is an instance of this class, where the algorithm
> parameters are specified in the ERP document, and we can effectively
> have to transport rRK keys. As I understand draft-ietf-hokey-key-mgm-13,
> that document is also talking about generic mechanisms, that can be
> applied for instance to the ERP specific usage.

[Qin]: According to draft-ietf-hokey-key-mgm-13, USRK and DSUSRK can be used in
Key Distribution Exchange Scenarios, that is to say EAP based key transportation is not limited for ERP
specific usage. Also I am not saying using of USRK and DSUSRK in the ERP scenario. I am wondering 
whether USRK and DSUSRK transportation can be used for other non ERP specific cases like Key Distribution 
Exchange Scenarios.

> Does this make my point more understandable?
> 
> Best regards,
> Sebastien.
> 
> -- 
> Sebastien Decugis
> Research fellow
> Network Architecture Group
> NICT (nict.go.jp)
>