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

From: Qin Wu <[email-masked]>
Date: Tue, 25 Aug 2009 16:28:47 +0800

Hi, folk,
During the last IETF meeting, We made a presentation on AVP for crypto key transport and recieved a few comments from some experts. The URL links for our I-D and presentation slides are:
http://tools.ietf.org/html/draft-wu-dime-local-keytran-02
http://www.ietf.org/proceedings/75/slides/dime-2.pdf

Here I would like to provide an overview of  our I-D and address the comments received in the IETF to help people to better understand what we are doing in this I-D.
The basic idea of this I-D is to specify a set of AVPs allowing the transport of multiple cryptographic keys in a single Diameter message(e.g, transport rMSK and DSRK in one Diameter message in ERP). All these multiple cryptographic keys are EAP based root keys derived from EMSK exported by EAP(i.e., ERP depends on EAP key mangement) e.g., DSRK, USRK, rRK, DSUSRK, rMSK  and are also master keys used in the handover optimization during network access. And each cryptographic key has its own lifetime, type, name.
Suppose more than one such cryptographic keys including lifetime, type, name need to be encapsulated in a set of  AVPs of  one Diameter message, if we don't define one grouped AVP to organize these AVPs, it is hard to use the same AVP to encapsulate the lifetime of one cryptographic key with the lifetime of another cryptographic key in one Diameter message. That's why we define one grouped AVP to accommodate each type of cryptograhic key with its lifetime, name and type. On the other hand, since these cryptographic keys are all EAP based transported key materials and used for handoff, it seems more practical to try to reuse
the same AVP to acccomodate the lifetime, name, type of key materials, e.g, define the same AVP to encapsulate the lifetime of rMSK and DSRK.

As regarding whether reuse of EAP-Key-Name change the meaning of itself, My answer is no, because as described in the section 5.9 of RFC5247, EAP-Key-Name means EAP Session-Id, So it is not limited to identify MSK. It is also can be used to identify the other EAP based key materials. 

In the Diameter ERP document, the AVP of ERP keys are also defined. However these transport of ERP keys are specific to the ERP application and can not solve how to transport more than one cryptographic keys in one message.

As regarding why we want to make the key transport more generic, the reason is, in some EAP/ERP scenario, transport of multiple cryptographic keys in a single Diameter message is required.
E.g., in the implicit bootstrapping for ERP(i.e.,full EAP authentication), the EAP request/response encapsulated in the AAA message is used to carry DSRK and rMSK simultaneously to the local Server. Upon receiving DSRK and rMSK, the local Server further deliver the rMSK to the given authenticator. In this scenario, the rMSK and DSRK need to be transported in the EAP request/Response simutaneously.

In contrast with implicit bootstrapping, the explicit bootstrapping will use EAP-Initiate/Finish to carry rMSK and DSRK. If rMSK, DSRK and relevant key information including lifetime, name is transported one AAA message, it will be difficult to distinguish which key information is corresponding to which keying materials. So it is sensible to define one grouped AVP to organize each type of transported keys and make the transport more generic.

With respect to whether 3GPP would dump existing stuff in favour of the new transport, if my understanding is correct, 3GPP has its own key generation which depends on authentication Vector to derive key materials. These  key materials has nothing to do with EAP based transport key materials.

I hope I have addressed all the comments collected in the last meeting. If you have any further comments or good suggestions to make the I-D more concise and  adoptable, please let us know.

Regards!

-Qin

---

From: Sebastien Decugis <[email-masked]>
Date: Wed, 26 Aug 2009 17:23:11 +0900

Hello Qin,

In general I agree that a grouped AVP is best suited to transport a Key
and its related information: name, lifetime, other (depending on the keys).

However, for the efficiency of parsing the message, I personally think
that having the key "type" *inside* the grouped AVP is not efficient,
since it means that the implementation has to parse the message "in
depth" to find the key it is interested in. If we define different
grouped AVPs for different key types, we have a better parsing
efficiency, and save some space in the message (key type AVP is not
needed). In addition, this approach allows to have a different ABNF for
each key type (for example, making the Key Name mandatory for DSRK keys,
but not for rMSK keys). This is the approach I followed in the draft
draft-sdecugis-dime-diameter-erp-01, which I plan to reproduce in the
upcoming draft-ietf-dime-erp-01.

About the transport of the MSK / rMSK, I am not sure if people will be
interested in changing the existing commands to use this more generic
approach of grouped AVPs. It is probably not a sufficient reason to
update the commands definitions (such as DEA for example), even though
the current format is quite strange :-D

Anyway, once we agree on the format of the suitable AVP to transport the
keys (in the case of ERP: DSRK, rMSK), I have no strong opinion as if it
is better to have it defined inside the Diameter ERP document or in a
separate document, as you know.

Best regards,
Sebastien.

> In the Diameter ERP document, the AVP of ERP keys are also defined.
> However these transport of ERP keys are specific to the ERP
> application and can not solve how to transport more than one
> cryptographic keys in one message.
>

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

---

From: "Glen Zorn" <[email-masked]>
Date: Thu, 27 Aug 2009 13:39:26 -0700

Sebastien Decugis [mailto://[email-masked]] writes:

> depth" to find the key it is interested in.  

In theory this sounds good.  If, however, an implementation receives _any_
key that it can't use (or isn't interested in) this poses a major security
problem.

> If we define different
> but not for rMSK keys). 

I'm not really sure why this would be useful...

> This is the approach I followed in the draft

I'm not sure that I understand this: it doesn't appear to me that the
definition of the DEA command would need to be changed: the
EAP-Master-Session-Key & EAP-Key-Name AVPs are both optional & the new AVP
would certainly qualify as [ * AVP ] ;-).

> _______________________________________________
> DiME mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dime

---

From: Qin Wu <[email-masked]>
Date: Fri, 28 Aug 2009 10:08:21 +0800

Hi, Sebastien:
----- Original Message ----- 
From: "Sebastien Decugis" <[email-masked]>
To: "Qin Wu" <[email-masked]>
Cc: <[email-masked]>
Sent: Wednesday, August 26, 2009 4:23 PM
Subject: Re: [Dime] [DIME] Comments about AVP for crypto key transport draft

> depth" to find the key it is interested in. 

[Qin]:  I think how many key materials need to be transported is specified in the RFC5296.e.g, In Explicit ERP boostrapping, ,both rMSK and DSRK is mandatory to be derived in the home Server based on local domain name and transported to the local Server, the local server should know this beforehand. Also as decribed in the EAP-key-type, the key type has been sorted in the ascending order. the Local Server
need not guess which key type is DSRK and which key type is rMSK. e.g., there are two grouped AVP encapsulated in one Diameter message,
the local server can easily know the first grouped AVP as DSRK, the second grouped AVP as rMSK. I am not sure whether this way can be seen
an inefficient way? :)
On the other hand, when the local server recieve a set of AVP from the home server, AVPs validation is necessary, the parsing can be done with validation together.

> each key type (for example, making the Key Name mandatory for DSRK keys,

[Qin]: As described in RFC5296, the rMSK and DSRK are both mandatory to be transported from the home Server to the local server during the ERP bootstrapping.  As we know, ERP has no indpendent key derivation mechanism and should depend on EAP key management to derive the Re-authentication Root keys and rMSK.
After bootstrapping, the local Sever obtain the DSRK, the ERP with the local server can be applied in the local domain, in this case, only rMSK is mandatory to be
transported from the local Server to the authenticator.

On the other hand, as you indicated, if we only allow home server derive DSRK and transport it to the local server, and then the local server take responsiblity to derive rMSK and transport it to the authentication, I am afraid it is not efficienty way to do bootstrapping, am I right?

> the current format is quite strange :-D

[Qin] We don't change the DER/DEA. MSK and rMSK are both EAP based transported key material
depend on the same EAP key architecture. Also they have the same parents.:)

---

From: Sebastien Decugis <[email-masked]>
Date: Fri, 28 Aug 2009 11:41:56 +0900

Hi Glen,

Please see my further comments inside.

> key that it can't use (or isn't interested in) this poses a major security
I don't understand how this is related to the format for conveying the key.
On the contrary, I'd think that with different AVP codes for different
types of keys, when the implementation understand the AVP code, we can
assume that it fully understand the content of the AVP. If you have a
generic "key" container, your implementation is able to extract the key
content, even if it does not understand the value inside the Key-Type
AVP. I would therefore think that my approach is slightly more secure in
that sense. What do you think?

> I'm not really sure why this would be useful...
I believe it is more generic, which is good since we are trying to
define a generic container :) For some key usages TBD, it might be
interesting to request for example the Key-Scope or Key-Algorithm (not
sure if this means anything) or Key-Strength in the ABNF, when they are
really needed by the application using this key.

I personally think a good approach for the document is to define all the
AVP that contain key data and metadata (key, key-name, key-lifetime,
key-scope, key-strengh, ... it can be updated when needed) and propose a
"template" for other documents to use these new AVPs, an example grouped
AVP. Then, each Diameter application that need to transport some key
material define its own grouped AVP with its particular ABNF and
semantics (depending on the application requirements) and re-uses these
generic AVPs inside the particular grouped AVP.

> would certainly qualify as [ * AVP ] ;-).
You are right, it is my mistake. RFC4072 (Diameter EAP) only say that
DEA MAY include this AVP, so it is no problem to have a new container.
Anyway, on an implementation point of view, this would be very confusing
(again, interoperability is getting worse)... :-(

Best regards,
Sebastien.

---

From: Sebastien Decugis <[email-masked]>
Date: Fri, 28 Aug 2009 12:09:52 +0900

Hi Qin,

Thank you for reply. Please see my comments inline.

> On the other hand, when the local server recieve a set of AVP from the home server, AVPs validation is necessary, the parsing can be done with validation together.
I had missed the ordering of the AVPs by key types, sorry. What I want
to avoid is that the peer who is interested in only one of the keys in
the message has to parse all the grouped AVPS. For example the local ERP
server which receives a DEA with explicit bootstrapping exchange, i.e.
containing both rMSK and DSRK, has to extract the DSRK but can ignore
the rMSK.
Relying on the order for this purpose may work (as long as no other key
is added in the message in the [*AVP] rule) but is seems a little
fragile to me.

About validation, if you want to check that your message really contains
the rMSK and DSRK, you really have to parse the grouped AVPs of type
"key" to check they key-types. With a different AVP code for each
grouped AVP, you only parse the top-level AVPs, without parsing inside
the grouped AVPs. That is what I meant by "efficiency" ;)

> On the other hand, as you indicated, if we only allow home server derive DSRK and transport it to the local server, and then the local server take responsiblity to derive rMSK and transport it to t…
I am sorry if I implied this at some point. It is not my intent. I don't
even think this could work with the current design of ERP explicit
bootstrapping.
I did not mean to imply any change to the ERP mechanism.

> depend on the same EAP key architecture. Also they have the same parents.:)
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?

BTW sorry about my comment on the AVP format, I confounded with the
format in RADIUS... The format in Diameter is straightforward.

Best regards,
Sebastien.

---

From: Qin Wu <[email-masked]>
Date: Mon, 31 Aug 2009 14:16:17 +0800

Hi, Sebastien, Glen:
----- Original Message ----- 
From: "Sebastien Decugis" <[email-masked]>
To: "Qin Wu" <[email-masked]>
Cc: <[email-masked]>
Sent: Friday, August 28, 2009 11:09 AM
Subject: Re: [Dime] [DIME] Comments about AVP for crypto key transport draft

> the grouped AVPs. That is what I meant by "efficiency" ;)

[Qin]: I am glad you agree with us to define grouped AVP to contain context of key usage.
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
Regarding a), as you said, the deep parsing of key types in the grouped AVP is required. Compared with a), 
b) only needs to parse the top level grouped AVP. It is true. We need to think about it carefully.
However, on the other hand, 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.
As for b), Suppose the local server only checks the top level grouped AVP of rMSK and don't check the inside AVP, e.g., the lifetime of rMSK is zero, the length of rMSK is zero, it seems useless for the authenticator to recieve such rMSK. 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(I guess this is what Glen want to point out as well in the previous mail).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? 

> EAP-Master-Session-Key AVP by a new generic AVP to transport this MSK or

[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?

---

From: Sebastien Decugis <[email-masked]>
Date: Mon, 31 Aug 2009 16:15:04 +0900

Hi Qin,

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

> [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 :)

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

> [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 fo…
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.

---

From: "Glen Zorn" <[email-masked]>
Date: Mon, 31 Aug 2009 10:24:52 -0700

> I don't understand how this is related to the format for conveying the

As I understand it, you're saying that by putting the key type at the top
level of the AVP structure it will be easier for a node to decide if it is
interested in the contents of the AVP. Is that correct?  If so, I'm saying
that if a node receives any key in which it is not interested, that in
itself is a security problem.  It should never happen & I can't see the
point of optimizing for something that should not happen in the first place.

> generic AVPs inside the particular grouped AVP.

OK.

> (again, interoperability is getting worse)... :-(

I don't know why...

---

From: Sebastien Decugis <[email-masked]>
Date: Tue, 01 Sep 2009 10:58:28 +0900

Hi Glen,

Glen Zorn a écrit :
> interested in the contents of the AVP. Is that correct?
Yes, it is exactly what I am saying.

>   If so, I'm saying
Actually, any agent that relays a Diameter message (not only the
proxies) receive this kind of information, right ? Do you mean that key
material should be protected in an end-to-end maneer (from sender to
recipient), instead of having only the hop-by-hop protection of
Diameter? I think this is quite contradictory with Diameter trust model
(which on the other side I believe is not scalable)

For a concrete example, in ERP explicit bootstrapping, the home server
generates two keys (rDSRK and rMSK) that are directed to two different
nodes (ERP server and NAS). Do you imply that these keys should not be
sent in the same Diameter message?

>> (again, interoperability is getting worse)... :-(
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.

Both solutions seems not very convenient to me.

My comment of course assumes that some NAS already support RFC4072 as it
is defined currently... I don't know if this is true or not. If nobody
is "doing" RFC4072 currently, it is not a problem to change the
recommanded way of passing the MSK to the NAS...

Best regards,
Sebastien.

---

From: Qin Wu <[email-masked]>
Date: Tue, 01 Sep 2009 11:04:37 +0800

Hi, Sebastien:
----- Original Message ----- 
From: "Sebastien Decugis" <[email-masked]>
To: "Qin Wu" <[email-masked]>
Cc: <[email-masked]>
Sent: Monday, August 31, 2009 3:15 PM
Subject: Re: [Dime] [DIME] Comments about AVP for crypto key transport draft
> Yes, it seems to me a very good example where the "Grouped AVP" concept

[Qin]: You are right.:)

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

> should be avoided on intermediary nodes, to accelerate the processing

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

[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? 
>>   

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

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

>> [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?
>>   

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

---

From: Sebastien Decugis <[email-masked]>
Date: Tue, 01 Sep 2009 13:27:10 +0900

Hi Qin,

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

> and sending to the authenticator. or ask the home server to re-transport the relevant
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 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.

> 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:
The code space is 2^32, just for IETF... We will not run out of codes ^^.

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

> only specific to the ERP scenarios or Re-authentication. There are other scenarios which this generic AVP 
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 :)

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