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

[Qin Wu <sunseawq at huawei.com>]

Hi, Sebastien:
Thank for your perspective on this AVP issue. :)
Please see my reply below!
----- Original Message ----- 
From: "Sebastien Decugis" <sdecugis at nict.go.jp>
To: "Qin Wu" <sunseawq at huawei.com>
Cc: <dime at ietf.org>
Sent: Tuesday, September 01, 2009 12:27 PM
Subject: Re: [Dime] [DIME] Comments about AVP for crypto key transport draft


> Hi Qin,
> 
>> 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? :)
>>   
> Yes, it's right, if the key type is a fixed position AVP, it is not much
> more work than having the information in the avp header. It just takes a
> little more space in the message, 

[Qin]: Yes, it does not take much work.

>but if there are good reasons to
> define only one grouped AVP, I guess the additional space is not really
> an issue.
[Qin]: The reason is to enable the
transport of 2 or more keys in the same message.  The definition of the
EAP-Master=Key & EAP-Key-Name AVPs is predicated upon the fact that there is
at most one key in a given message.  
Also this generic approach is not specific to the ERP.

>>> 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.
>>   
> I see. In any case, the NAS probably have to validate the key, so I
> still believe the validation in the intermediary node is not necessary.

[Qin]: The problem is when the NAS recieves MSK or rMSK, the NAS can not judge
whether MSK or rMSK is validated. because the NAS has no  root key. Only intermediary node and End-Server
can tell whether MSK or rMSK is validated. What the NAS can do is format checking, e.g.,
whether the lifetime of MSK is more than 0 or something else. 

>>> 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.,
>> In these scenarios, USRK,DSRK, DSUSRK are all EAP based keys and should be defined.
>>   
> But the usages you are talking of here are not defined yet, right? And
> we are only talking about keys derived from EAP EMSK, following rfc5295
> method. We may also have to transport keys in different contexts. In
> some future usages of the key material, additional metadata might be
> needed (a version of the key derivation algorithm for example). Of
> course new AVPs can be defined inside the [ * AVP ] rule of the grouped
> AVP ABNF, but I think that having a clear definition of the ABNF for
> each key usage is easier to understand and more explicit -- and we don't
> implicitely imply the ABNF for the group from the value of the Key-Type
> AVP in that case.

[Qin]: Yes, in my understanding, all these Scenarios can be taken as a 
usage which has already defined in the draft-ietf-hokey-key-mgm-09.
The keys defined in the draft-ietf-hokey-key-mgm-09  are all derived
 from EMSK, conforming to rfc5295. As described in rfc5295, USRK
 is derived from EMSK, DSUSRK is derived from DSRK, so USRK 
and DSRK also can be transported from home server to the local server. 
Suppose USRK,DSRK and DSUSRK are all transported from home
 server to the local server, they all has the same destination,i.e., 
intermediary node.Since they have the same destination, it does not matter
 whether the key Type is in the grouped AVP. The intermediary node needs 
to parse them one by one.

>> 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.
>>   
> Because these keys are used differently, it seems to me logical to have
> different AVP defined. But if other people prefer to define only one
> container and put all the keys in the same one with an AVP inside to
> distinguish between different types of keys, it is OK with me, I already
> argued why I think the other possibility is better...

[Qin]: Okay.:)

>> [Qin]: The reasons to define only one AVP code for these keys are:
>> 1. Save AVP code
>>   
> The code space is 2^32, just for IETF... We will not run out of codes ^^.
> 
>> 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?
>>   
> As I wrote before, the way these keys are used, as well as the node to
> which they are destined, differ. That is a good reason IMHO.
> In addition, if you want to defined a generic AVP, you don't want to
> restrict to keys following the semantics you are describing here, do you?

[Qin] Suppose the home server uses EAP method to export MSK and EMSK 
during the full EAP authentication, and then home server further derives DSRK,
 rRK,USRK and rMSK, in all these keys, MSK and rMSK has the same destination, 
authenticator. DSRK, rRK and USRK has the same destination, i.e., local server.
when the home server needs to transport all these keys to the given local server and authenticator,
I don't think we need to change the semantices the keys follow. 

>> 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.
>>   
> Yes, from the beginning I agree that defining a generic way to transport
> keys is a good idea...  It's only the way that it is done that I am
> discussing :)

[Qin]: Okay.

>> [Qin] Are you intending to use EAP-Master-Session-Key AVP to transport rMSK 
>> from the home Server to the Local Server,
> Yes.
>>  In this sense, I am afraid you change the
>>  meaning of EAP-Master-Session-Key.
> Well, basically, rMSK is an MSK also, I do not see a contradiction here.
>>  Because the local server will confuse whether 
>>  the home Server is transporting MSK or rMSK to him.
> First of all, it is not important for the local server, since it does
> not use this key at all.

[Qin]: It may introduce security threat. Because the authenticator has no 
root keys and can not judge the key is validated. Only local server can validate 
the rMSK based on DSRK.

> Second, during a full EAP authentication, it is an MSK. During an
> explicit bootstrapping ERP exchange, it is an rMSK. There is no
> confusion here.

[Qin]: In implicit bootstrapping aren't both the MSK & rMSK sent in the same
message?  How can you tell the difference between them at the NAS?

>>  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. :)
>>   
> The authenticator uses the rMSK exactly in the same maneer as the MSK,
> there is no point in distinguishing between them.
>> In this way, it is better to distinguish between rMSK and MSK.
>>   
> I don't think so... Why do you need to distinguish? Only the peer need
> to know what key the authenticator will be using. And the peer always
> know...
[Qin]: See above.


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