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:

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

As I understand it, you're saying that by putting the key type at the top
level of the AVP structure it will be easier for a node to decide if it is
interested in the contents of the AVP. Is that correct?  If so, I'm saying
that if a node receives any key in which it is not interested, that in
itself is a security problem.  It should never happen & I can't see the
point of optimizing for something that should not happen in the first place.

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

OK.

> 
> 
> >> 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)... :-(

I don't know why...

> 
> Best regards,
> Sebastien.
> 
> --
> Sebastien Decugis
> Research fellow
> Network Architecture Group
> NICT (nict.go.jp)
>