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

[Qin Wu <sunseawq at huawei.com>]

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


> Hi Qin,
> 
> Thank you for reply. Please see my comments inline.
> 
> Qin Wu a écrit :
>> [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.
>>   
> I had missed the ordering of the AVPs by key types, sorry. What I want
> to avoid is that the peer who is interested in only one of the keys in
> the message has to parse all the grouped AVPS. For example the local ERP
> server which receives a DEA with explicit bootstrapping exchange, i.e.
> containing both rMSK and DSRK, has to extract the DSRK but can ignore
> the rMSK.
> Relying on the order for this purpose may work (as long as no other key
> is added in the message in the [*AVP] rule) but is seems a little
> fragile to me.
> 
> About validation, if you want to check that your message really contains
> the rMSK and DSRK, you really have to parse the grouped AVPs of type
> "key" to check they key-types. With a different AVP code for each
> grouped AVP, you only parse the top-level AVPs, without parsing inside
> the grouped AVPs. That is what I meant by "efficiency" ;)

[Qin]: I am glad you agree with us to define grouped AVP to contain context of key usage.
It seems we have two choices for defining grouped AVP
a). the same AVP code for DSRK and rMSK
b). the different AVP code for DSRK and rMSK respectively
Regarding a), as you said, the deep parsing of key types in the grouped AVP is required. Compared with a), 
b) only needs to parse the top level grouped AVP. It is true. We need to think about it carefully.
However, on the other hand, when the local server recieves AAA message including DSRK and rMSK from the home server, it does not simply forward the AAA message to the given authenticator, it needs to take out the grouped AVP for DSRK and check the format validicity of rMSK, and then include rMSK in the AAA message and send it to the given authenticator.
As for b), Suppose the local server only checks the top level grouped AVP of rMSK and don't check the inside AVP, e.g., the lifetime of rMSK is zero, the length of rMSK is zero, it seems useless for the authenticator to recieve such rMSK. If the inside AVP of  rMSK is not checked by the local server and directly transported to the authenticator, it is a little fragile too(I guess this is what Glen want to point out as well in the previous mail).So I wonder how the local Server process the DSRK,rMSK and other keys, especially more than two EAP-based key materials need to be transported, e.g., DSRK, DSUSRK, rMSK are transported simutaneously to the local ER. Shall we  need to define each grouped container for each key, what the local Server should do? 

>> 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?
>>   
> I am sorry if I implied this at some point. It is not my intent. I don't
> even think this could work with the current design of ERP explicit
> bootstrapping.
> I did not mean to imply any change to the ERP mechanism.
>>> 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.:)
>>   
> If I understand correctly, the intent was to replace the use of
> EAP-Master-Session-Key AVP by a new generic AVP to transport this MSK or
> rMSK, right?

[Qin]: We don't intend to replace or change it. For backward compatibility, we just want to give another choice, i.e.,Since MSK and rMSK both belong to EAP based keys and depend on the same EMSK for key derivation, I wonder whether we can use the same container for both of them? Is it necessary to define different AVP code for both of them?

> BTW sorry about my comment on the AVP format, I confounded with the
> format in RADIUS... The format in Diameter is straightforward.
> Best regards,
> Sebastien.
> 
> -- 
> Sebastien Decugis
> Research fellow
> Network Architecture Group
> NICT (nict.go.jp)
>