Hi Jari,
I think keeping EMSK at the server (EAP or AAA server), and
calculating
AMSK there (your alternative 1) provides for better control
of the
overall AAA and security of both handover and applications.
So I favor
1.
This way not only you are not worried about misuse of EMSK
in generating
unauthorized AMSKs by the authenticator, but also are
covered against a
few things:
1) authenticator handover does not require regeneration of
EMSK (read
new EAPs).
2) application keying does not require
authenticator-application agent
SA s that may otherwise not exist. We ran into this problem
with Proxy
MIP. Authenticator gets a PMIP key (say generated from a
PMIP-AMSK), the
authenticator can have an SA with the proxy MN, since they
are expected
to be within the foreign network, but the authenticator is
not expected
to have an SA with the HA, meaning, the HA cannot get the
PMIP key, it
has to go to the AAA server to get it and guess what, the
AAA server
cannot even send the PMIP-AMSK to the authenticator, because
according
to EAP requirements, it has to have deleted it after
transport to
authenticator.
3) As you mentioned, the AAA server may even have a policy
about the
KDFs to be used for each application keying, say MIP or
whatever, so you
may not have negotiate the KDF.
Madjid
-----Original Message-----
From: Jari Arkko [mailto:jari.arkko piuha.net]
Sent: Monday, March 06, 2006 3:36 AM
To: Bernard Aboba
Cc: eapfrascone.com
Subject: Re: [eap] About use of EMSK
Here's some analysis of the server vs. lower-layer based
EMSK processing
approaches.
(1) In the server based approach we keep the EMSK in the
server (perhaps
just for a moment) and generate the AMSKs, which are given
to the the
different applications, such as fast handoff mechanisms.
The use of these applications goes via AAA, e.g., some kind
of key
requests or fast re-auth requests can be sent from NASes to
the server.
The AMSKs are derived using a KDF which is decided either
(a) by a
default plus optional negotiation in methods or (b) by lower
layer
negotiation and having AAA tell the server which KDF to use.
(2) In the lower-layer based EMSK processing approach, the
EMSK is
delivered to the authenticator along with the MSK.
KDF is selected either (a) by a default in EAP plus optional
negotiation
in methods, choice is communicated to the lower layer via
AAA or (b) by
lower layer negotiation alone.
The lower layer is responsible for all use of the AMSKs in a
local
context. That is, no AAA key requests are needed or
possible.
Discussion about the chosen approach for EMSK use has so far
appeared to
assume 1a vs. 2b. Based on the above, it seems that the KDF
negotiation
may be a separate issue from who maintains the EMSK and
calculates
AMSKs.
In the following I'll try to analyze these issues.
The KDF negotiation is indeed problematic almost no matter
what we do.
Requiring new funtionality in methods is in practice often a
non-starter; while we can develop new methods and update old
ones, it is
expected that most of current usage will continue to use the
existing
methods. Having a default does not help much either, if the
default
becomes broken in the near future.
But requiring new functionality in link layers it not always
easy
either. It would be easy when we are developing a new link
layer and
including some EMSK usage as a part of that. But if we were
to use EMSK
for some new function over 802.11, for instance, would there
be enough
incentive to extend 802.11 just to make this possible?
The choices and their implications are:
(a) Specified default, optional negotiation in EAP
methods.
This implies an interface either from methods to the
AAA/EAP
server
code (for solution 1) or AAA protocol extensions for
solution 2.
Changes in peers, servers, methods, possibly AAA
protocols.
(b) Lower layer negotiation.
If used together with solution 1, implies AAA
protocol extensions
to communicate the KDF. If used with solution 2,
implies AAA
protocol extensions to carry the EMSK.
Changes in lower layers, AAA protocol. No changes in
EAP or
methods.
Based on this my current preference is (b). I'd be willing
to accept
(a), too.
The choice between server or lower-layer based EMSK
processing depends
on security implications and ease of use for different
purposes.
The choices are:
(1) Derive AMSKs at the EAP/AAA server.
Implies a AAA protocol extension to retrieve AMSKs.
Changes at the EAP/AAA server, authenticator. New,
stateful
nature of the EAP/AAA server.
(2) Derive AMSKs at the lower layer.
Implies a AAA protocol extension to carry EMSK to the
authenticator.
Small changes at the EAP/AAA server, main
functionality in
the authenticator.
Hard to see how other nodes than the authenticator
would
actually use the AMSKs. Traditionally, NAS -> NAS
communication
has not been easy compared to NAS -> AAA
communication.
Based on this my current preference is (1). But its a close
call.
--Jari
____________________________________________________________
_____
To unsubscribe or modify your subscription options, please
visit:
http:/
/lists.frascone.com/mailman/listinfo/eap
Arhives: http://lists.
frascone.com/pipermail/eap
____________________________________________________________
_____
To unsubscribe or modify your subscription options, please
visit:
http:/
/lists.frascone.com/mailman/listinfo/eap
Arhives: http://lists.
frascone.com/pipermail/eap
|