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

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

Hi Glen,

Please see my further comments inside.

Glen Zorn a écrit :
>> 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.  
>>     
>
> In theory this sounds good.  If, however, an implementation receives _any_
> key that it can't use (or isn't interested in) this poses a major security
> problem.
>   
I don't understand how this is related to the format for conveying the key.
On the contrary, I'd think that with different AVP codes for different
types of keys, when the implementation understand the AVP code, we can
assume that it fully understand the content of the AVP. If you have a
generic "key" container, your implementation is able to extract the key
content, even if it does not understand the value inside the Key-Type
AVP. I would therefore think that my approach is slightly more secure in
that sense. What do you think?

>> 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). 
>>     
>
> I'm not really sure why this would be useful...
>   
I believe it is more generic, which is good since we are trying to
define a generic container :) For some key usages TBD, it might be
interesting to request for example the Key-Scope or Key-Algorithm (not
sure if this means anything) or Key-Strength in the ABNF, when they are
really needed by the application using this key.

I personally think a good approach for the document is to define all the
AVP that contain key data and metadata (key, key-name, key-lifetime,
key-scope, key-strengh, ... it can be updated when needed) and propose a
"template" for other documents to use these new AVPs, an example grouped
AVP. Then, each Diameter application that need to transport some key
material define its own grouped AVP with its particular ABNF and
semantics (depending on the application requirements) and re-uses these
generic AVPs inside the particular grouped AVP.


>> 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
>>     
>
> I'm not sure that I understand this: it doesn't appear to me that the
> definition of the DEA command would need to be changed: the
> EAP-Master-Session-Key & EAP-Key-Name AVPs are both optional & the new AVP
> would certainly qualify as [ * AVP ] ;-).
>   
You are right, it is my mistake. RFC4072 (Diameter EAP) only say that
DEA MAY include this AVP, so it is no problem to have a new container.
Anyway, on an implementation point of view, this would be very confusing
(again, interoperability is getting worse)... :-(

Best regards,
Sebastien.

-- 
Sebastien Decugis
Research fellow
Network Architecture Group
NICT (nict.go.jp)