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

[Sebastien Decugis <sdecugis at nict.go.jp>]

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" ;)


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

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)