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

[Qin Wu <sunseawq at huawei.com>]

Hi, Sebastien:
----- Original Message ----- 
From: "Sebastien Decugis" <sdecugis at nict.go.jp>
To: "Qin Wu" <sunseawq at huawei.com>
Cc: <dime at ietf.org>
Sent: Wednesday, August 26, 2009 4:23 PM
Subject: Re: [Dime] [DIME] Comments about AVP for crypto key transport draft


> Hello Qin,
> 
> In general I agree that a grouped AVP is best suited to transport a Key
> and its related information: name, lifetime, other (depending on the keys).
> However, for the efficiency of parsing the message, I personally think
> that having the key "type" *inside* the grouped AVP is not efficient,
> since it means that the implementation has to parse the message "in
> depth" to find the key it is interested in. 

[Qin]:  I think how many key materials need to be transported is specified in the RFC5296.e.g, In Explicit ERP boostrapping, ,both rMSK and DSRK is mandatory to be derived in the home Server based on local domain name and transported to the local Server, the local server should know this beforehand. Also as decribed in the EAP-key-type, the key type has been sorted in the ascending order. the Local Server
need not guess which key type is DSRK and which key type is rMSK. e.g., there are two grouped AVP encapsulated in one Diameter message,
the local server can easily know the first grouped AVP as DSRK, the second grouped AVP as rMSK. I am not sure whether this way can be seen
an inefficient way? :)
On the other hand, when the local server recieve a set of AVP from the home server, AVPs validation is necessary, the parsing can be done with validation together.

>If we define different
> grouped AVPs for different key types, we have a better parsing
> efficiency, and save some space in the message (key type AVP is not
> needed). In addition, this approach allows to have a different ABNF for
> each key type (for example, making the Key Name mandatory for DSRK keys,
> but not for rMSK keys). 

[Qin]: As described in RFC5296, the rMSK and DSRK are both mandatory to be transported from the home Server to the local server during the ERP bootstrapping.  As we know, ERP has no indpendent key derivation mechanism and should depend on EAP key management to derive the Re-authentication Root keys and rMSK.
After bootstrapping, the local Sever obtain the DSRK, the ERP with the local server can be applied in the local domain, in this case, only rMSK is mandatory to be
transported from the local Server to the authenticator.

On the other hand, as you indicated, if we only allow home server derive DSRK and transport it to the local server, and then the local server take responsiblity to derive rMSK and transport it to the authentication, I am afraid it is not efficienty way to do bootstrapping, am I right?

>This is the approach I followed in the draft
> draft-sdecugis-dime-diameter-erp-01, which I plan to reproduce in the
> upcoming draft-ietf-dime-erp-01.
> 
> About the transport of the MSK / rMSK, I am not sure if people will be
> interested in changing the existing commands to use this more generic
> approach of grouped AVPs. It is probably not a sufficient reason to
> update the commands definitions (such as DEA for example), even though
> the current format is quite strange :-D

[Qin] We don't change the DER/DEA. MSK and rMSK are both EAP based transported key material
depend on the same EAP key architecture. Also they have the same parents.:)

> Anyway, once we agree on the format of the suitable AVP to transport the
> keys (in the case of ERP: DSRK, rMSK), I have no strong opinion as if it
> is better to have it defined inside the Diameter ERP document or in a
> separate document, as you know.
> 
> Best regards,
> Sebastien.
> 
>> In the Diameter ERP document, the AVP of ERP keys are also defined.
>> However these transport of ERP keys are specific to the ERP
>> application and can not solve how to transport more than one
>> cryptographic keys in one message.
>>
> 
> -- 
> Sebastien Decugis
> Research fellow
> Network Architecture Group
> NICT (nict.go.jp)
>