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

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

Hi,

Glen Zorn a écrit :
> 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.
>   
Well, I think this is a good argument in favor of having a different AVP
code for different keys... So that the agent (example: ERP server) will
only look inside the AVPs it has business with, and not other potential
keys (such as rMSK).

As far as the "security issue" I think this only concerns the nodes with
bad intentions -- if nobody was ill-intended, we would not need security
nor keys in the first place -- so assuming that the agent will not look
into the message because it is none of its business seems quite light
security to me ^^.

>> 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.
>   
OK for transporting a (r)MSK in a Diameter ERP message, but I was
talking about the existing messages (NASREQ and Diameter EAP). I think
we may lead to an interoperability issue if we create a new container
for the same thing (MSK) in the same message...

Bests,
Sebastien.

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