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

[Qin Wu <sunseawq at huawei.com>]

Hi, Sebastien:
----- Original Message ----- 
From: "Sebastien Decugis" <sdecugis at nict.go.jp>
To: "Qin Wu" <sunseawq at huawei.com>
Cc: <dime at ietf.org>
Sent: Monday, August 31, 2009 3:15 PM
Subject: Re: [Dime] [DIME] Comments about AVP for crypto key transport draft
> 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 :)

[Qin]: You are right.:)

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

[Qin]: Since we assume the transport layer is reliable, it seems to me parsing 
the top-level AVP is more efficient than full parsing the whole grouped AVP at each levels. 
However we put the key type as the first nested AVP and define it as eNumerated type,  
 it does not take time to interpret this first inner AVP of one grouped AVP, i.e., parsing is
 not so deep as you concerned. What do you think of it? :)

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

[Qin]: In my understanding, if the intermediary node, e.g.,local server detects
 the inside AVP is not validated, the intermediary node can simply notify the
authenticator of the results by encapsulating the EAP-Failure in the AAA message
and sending to the authenticator. or ask the home server to re-transport the relevant
key materials.

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

[Qin] As described in the draft-ietf-hokey-key-mgm-09, actually we have already specified such future usages for key transportation, i.e.,
Scenario 1: EAP/AAA server to USR-KH:  In this scenario, the EAP/AAA server delivers a USRK to a USR-KH.
Scenario 2: EAP/AAA server to DSR-KH:  In this scenario, the EAP/AAA server delivers a DSRK to a DSR-KH.
Scenario 3: DSR-KH to DSUSR-KH:  In this scenario, a DSR-KH in a specific domain delivers keying material to a 
DSUSR-KH in the same domain.
In these scenarios, USRK,DSRK, DSUSRK are all EAP based keys and should be defined.

Also as described in RFC5296, the implicit bootstrapping for ERP uses the EAP request/response encapsulated in the 
AAA message to carry DSRK and rMSK simultaneously to the local Server. while explicit bootstrapping 
for ERP uses the EAP Initiate/response encapsulated in the AAA message to carry DSRK and rMSK simultaneously. 
In two bootstrapping scenarios, DSRK and rMSK are both EAP based key and should be defined.
Since all these keys are directly or indirectly derived from the same EMSK. I wonder is it necessary for us to define each grouped 
AVP for USRK, DSRK, DSUSRK, rMSK.

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

[Qin]: The reasons to define only one AVP code for these keys are:
1. Save AVP code
2. All these transported key materials derive from the same EMSK and are variants of EAP based key.
Is it necessary for us to define separate AVP codes for them?
3. As described in draft-ietf-hokey-key-mgm-09, distribution of EAP based keys for handover are not
only specific to the ERP scenarios or Re-authentication. There are other scenarios which this generic AVP 
can be applied as well.

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

[Qin] Are you intending to use EAP-Master-Session-Key AVP to transport rMSK 
from the home Server to the Local Server, In this sense, I am afraid you change the
 meaning of EAP-Master-Session-Key. Because the local server will confuse whether 
 the home Server is transporting MSK or rMSK to him. because rMSK is derived from 
rRK while MSK is Exported by EAP method. Also when you use the EAP-Master-Session-Key 
to transport rMSK to the authencator, it will cause confusion of authenticator as well. :)
In this way, it is better to distinguish between rMSK and MSK.

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