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