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

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

Hi Qin,

Thank you for your answer. Please find my comments inside, as usual.

Qin Wu a écrit :
> [Qin]: I am glad you agree with us to define grouped AVP to contain context of key usage.
>   
Yes, it seems to me a very good example where the "Grouped AVP" concept
of Diameter is useful :)

> It seems we have two choices for defining grouped AVP
> a). the same AVP code for DSRK and rMSK
> b). the different AVP code for DSRK and rMSK respectively
>   
> [skip]
> when the local server recieves AAA message including DSRK and rMSK from the home server, it does not simply forward the AAA message to the given authenticator, it needs to take out the grouped AVP for DSRK and check the format validicity of rMSK, and then include rMSK in the AAA message and send it to the given authenticator.
>   
I think this is an implementation issue. Since the local server does not
use/modify the rMSK, it might as well totally ignore this AVP. The full
validation of the message is not required on each hop, because the
transport layer is reliable, and we supposedly trust the (home) server
to generate a valid message... Parsing the top-level AVPs is mandatory
to find the AVPs we are interested in, but I think further validation
should be avoided on intermediary nodes, to accelerate the processing
and avoid congestion.

> If the inside AVP of  rMSK is not checked by the local server and directly transported to the authenticator, it is a little fragile too.
It is not clear to me what should be the behavior in such case when an
intermediary node detects a problem in an answer message, to avoid
breaking application synchronization between the client and the
end-server...

> So I wonder how the local Server process the DSRK,rMSK and other keys, especially more than two EAP-based key materials need to be transported, e.g., DSRK, DSUSRK, rMSK are transported simutaneously to the local ER. Shall we  need to define each grouped container for each key, what the local Server should do? 
>   
In my understanding the purpose of defining a "generic" approach is that
what we define should be re-usable for transport of other keys in future
usages. We don't know yet the semantics of these key, and the meta-data
that will be needed along them. That is IMHO a good reason to have a
different AVP code for different keys, while the AVPs inside the group
can be reused whenever possible (key name, key lifetime, and so on...).

But I am not saying that the other approach is not working, I just think
it requires a little more work from the implementation. On the other
side, it saves AVP codes, but I doubt that we will run out of available
codes soon. There might be also other good reasons that I am not
familiar with for defining only one AVP code (for example, is the
process to get a new AVP code from IANA too difficult and would restrict
the use of the generic AVP template in some case ?) but from a pure
protocol and implementation point of view, I believe separate AVP codes
is a better approach, that's all I am saying here.


>> If I understand correctly, the intent was to replace the use of
>> EAP-Master-Session-Key AVP by a new generic AVP to transport this MSK or
>> rMSK, right?
>>     
>
> [Qin]: We don't intend to replace or change it. For backward compatibility, we just want to give another choice, i.e.,Since MSK and rMSK both belong to EAP based keys and depend on the same EMSK for key derivation, I wonder whether we can use the same container for both of them? Is it necessary to define different AVP code for both of them?
>   
No, on the contrary, since MSK and rMSK are meant to be used in the same
way, I would rather think we should avoid at all cost to pass the rMSK
in a different container than the MSK...
I was just pointing that it will be confusing if we define a new
alternative container for the same thing in the same message...

Best regards,
Sebastien.

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