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:

> 
> Hi Glen,
> 
> Glen Zorn a écrit :
> > 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?
> Yes, it is exactly what I am saying.
> 
> >   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.
> >
> Actually, any agent that relays a Diameter message (not only the
> proxies) receive this kind of information, right ? 

Physically, yes, it will receive the message.  Logically, however, I fail to
see any reason why an agent (with the exception of the ERP server, if you
wish to call it an agent) should look inside any AVP containing a key, since
by definition the AVP is not any of its business.

> Do you mean that key
> material should be protected in an end-to-end maneer (from sender to
> recipient), instead of having only the hop-by-hop protection of
> Diameter? 

No.

> I think this is quite contradictory with Diameter trust model
> (which on the other side I believe is not scalable)
> 
> For a concrete example, in ERP explicit bootstrapping, the home server
> generates two keys (rDSRK and rMSK) that are directed to two different
> nodes (ERP server and NAS). Do you imply that these keys should not be
> sent in the same Diameter message?

No.

> 
> 
> >> 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...
> >
> If the NAS does not support the new container and receives a DEA with
> the MSK key in this container, it will fail to establish the session
> with the peer. (basically, the new container will have its 'M' flag
> set,
> and the NAS will not recognize it).
> Therefore, the server has to either:
> - have a configuration parameter for each NAS, telling if the new
> container can be used or not.
> - start using the new container only after all NAS (in the world?) have
> been upgraded to support the new container.

We are defining the Diameter ERP application & we can state that the 'M' bit
is set for the new container.

> 
> Both solutions seems not very convenient to me.
> 
> My comment of course assumes that some NAS already support RFC4072 as
> it
> is defined currently... I don't know if this is true or not. If nobody
> is "doing" RFC4072 currently, it is not a problem to change the
> recommanded way of passing the MSK to the NAS...
> 
> Best regards,
> Sebastien.
> 
> --
> Sebastien Decugis
> Research fellow
> Network Architecture Group
> NICT (nict.go.jp)
>