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

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

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, but if there are good reasons to
define only one grouped AVP, I guess the additional space is not really
an issue.

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

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

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

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

Best regards,
Sebastien.

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