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

["Glen Zorn" <gwz at net-zen.net>]

Sebastien Decugis [mailto://sdecugis at nict.go.jp] writes:

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

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.

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

> 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

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 ] ;-).

> 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)
> 
> _______________________________________________
> DiME mailing list
> DiME at ietf.org
> https://www.ietf.org/mailman/listinfo/dime