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

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

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


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

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)