|
List Info
Thread: About use of EMSK
|
|
| About use of EMSK |
|
2006-02-26 22:09:57 |
> -----Original Message-----
> From: Rafa Marin Lopez [mailto:rafa dif.um.es]
> Sent: Monday, February 20, 2006 2:13 PM
> To: eapfrascone.com
> Subject: [eap] About use of EMSK
>
> After last discussions in strawman -10 (and those one
related
> with EMSK/AMSK in November),
> I am still trying to figure out what layer as specified
in figure 3
> would be intended to create more keys by using MSK,EMSK
> exported by EAP method.
>
> In section 2.2 it is said:
>
> "As illustrated in Figure 3, on completion of EAP
authentication, EAP
> methods export the Master Session Key (MSK),
Extended
> Master Session
> Key (EMSK), Peer-ID, Server-ID, Session-ID and
Key-Lifetime to the
> EAP peer or authenticator layers. The
Initialization
> Vector (IV) is
> deprecated."
>
> That is , EMSK, MSK arrives to next lower layer than
EAP
> method layer . Now EMSK,MSK are in EAP
peer/authenticator
> layer. Following next text:
>
> "The EAP peer and authenticator layers MUST
NOT modify or
> cache keying
> material or parameters (including Channel Bindings)
> passing in either
> direction between the EAP method layer and the EAP
layer."
>
> it means EMSK,MSK now arrives to EAP layer... but
>
> "The EAP layer also MUST NOT cache keying
material or
> parameters (including
> Channel Bindings) passed to it, whether by the EAP
> peer/authenticator
> layer, the lower layer or the AAA layer."
>
> Thus EMSK,MSK would arrive lower layer/AAA layer. If
EMSK
> does not want to be exported to AAA layer or lower
layer in
> some point (either EAP peer/authenticator layer
> or EAP layer), EMSK is removed. In strawman 10, now
EMSK
> appears in AAA layer (though i don't know if it will
> eventually be in that way).
[Joe] The EMSK MUST NOT be exported to the lower layer.
>
> My question is what layer (EAP method, EAP
peer/authenticator
> layer, EAP layer, lower layer/AAA layer)
> is intended to get EMSK to create new possible keys
(AMSK)?
>
[Joe] The AMSKs should be derived by the EAP server and the
EAP peer.
> is there any decision in this regard?
>
> The question is also related with
> draft-aboba-eap-keying-extns-00.txt, basically what
layer is
> intended to calculate this function (or similar)?
> AMSK = KDF(EMSK, key label, optional application data,
length)
>
> Thanks.
>
> --
> ------------------------------------------------------
> Rafael Marin Lopez
> Faculty of Computer Science-University of Murcia
> 30071 Murcia - Spain
> Telf: +34968367645 e-mail: rafadif.um.es
> ------------------------------------------------------
>
>
____________________________________________________________
_____
> 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
|
|
| About use of EMSK |
|
2006-02-27 16:10:08 |
Hi Joe,
I appreciate your answer... please see inline.
Salowey, Joe wrote:
>
>
>
>
>>-----Original Message-----
>>From: Rafa Marin Lopez [mailto:rafadif.um.es]
>>Sent: Monday, February 20, 2006 2:13 PM
>>To: eapfrascone.com
>>Subject: [eap] About use of EMSK
>>
>>After last discussions in strawman -10 (and those
one related
>>with EMSK/AMSK in November),
>>I am still trying to figure out what layer as
specified in figure 3
>>would be intended to create more keys by using
MSK,EMSK
>>exported by EAP method.
>>
>>In section 2.2 it is said:
>>
>>"As illustrated in Figure 3, on completion of
EAP authentication, EAP
>> methods export the Master Session Key (MSK),
Extended
>>Master Session
>> Key (EMSK), Peer-ID, Server-ID, Session-ID and
Key-Lifetime to the
>> EAP peer or authenticator layers. The
Initialization
>>Vector (IV) is
>> deprecated."
>>
>>That is , EMSK, MSK arrives to next lower layer than
EAP
>>method layer . Now EMSK,MSK are in EAP
peer/authenticator
>>layer. Following next text:
>>
>> "The EAP peer and authenticator layers MUST
NOT modify or
>>cache keying
>> material or parameters (including Channel
Bindings)
>>passing in either
>> direction between the EAP method layer and the
EAP layer."
>>
>>it means EMSK,MSK now arrives to EAP layer... but
>>
>> "The EAP layer also MUST NOT cache keying
material or
>>parameters (including
>> Channel Bindings) passed to it, whether by the
EAP
>>peer/authenticator
>> layer, the lower layer or the AAA layer."
>>
>>Thus EMSK,MSK would arrive lower layer/AAA layer. If
EMSK
>>does not want to be exported to AAA layer or lower
layer in
>>some point (either EAP peer/authenticator layer
>>or EAP layer), EMSK is removed. In strawman 10, now
EMSK
>>appears in AAA layer (though i don't know if it
will
>>eventually be in that way).
>>
>>
>
>[Joe] The EMSK MUST NOT be exported to the lower layer.
>
>
Clarified this point. In your answer you specify
"only" lower layer. Did
you forget to include AAA layer ? Or do you think AAA layer
might
receive EMSK?.
>
>
>>My question is what layer (EAP method, EAP
peer/authenticator
>>layer, EAP layer, lower layer/AAA layer)
>>is intended to get EMSK to create new possible keys
(AMSK)?
>>
>>
>>
>
>[Joe] The AMSKs should be derived by the EAP server and
the EAP peer.
>
>
Yes. But my question was a bit more specific. As you know
the figure 3
in EAP key mng fwk (v9 and v10) shows several layers.
Thus my question was in EAP peer / EAP server (and
considering figure 3):
"what layer (EAP method layer, EAP peer/authenticator
layer, EAP layer,
lower layer/AAA layer) is intended to get EMSK to create new
possible
keys (AMSK)?"
(From your previous answer, it is clear we can discard lower
layer as a
possible answer)
Thanks.
>>is there any decision in this regard?
>>
>>The question is also related with
>>draft-aboba-eap-keying-extns-00.txt, basically what
layer is
>>intended to calculate this function (or similar)?
>>AMSK = KDF(EMSK, key label, optional application
data, length)
>>
>>Thanks.
>>
>>--
>>----------------------------------------------------
--
>>Rafael Marin Lopez
>>Faculty of Computer Science-University of Murcia
>>30071 Murcia - Spain
>>Telf: +34968367645 e-mail: rafadif.um.es
>>----------------------------------------------------
--
>>
>>____________________________________________________
_____________
>>To unsubscribe or modify your subscription options,
please visit:
>>http:/
/lists.frascone.com/mailman/listinfo/eap
>>
>>Arhives: http://lists.
frascone.com/pipermail/eap
>>
>>
>>
>
>
>
>
--
------------------------------------------------------
Rafael Marin Lopez
Faculty of Computer Science-University of Murcia
30071 Murcia - Spain
Telf: +34968367645 e-mail: rafadif.um.es
------------------------------------------------------
____________________________________________________________
_____
To unsubscribe or modify your subscription options, please
visit:
http:/
/lists.frascone.com/mailman/listinfo/eap
Arhives: http://lists.
frascone.com/pipermail/eap
|
|
| About use of EMSK |
|
2006-03-05 21:12:09 |
Rafa Marin Lopez wrote:
>>
>> [Joe] The EMSK MUST NOT be exported to the lower
layer.
>>
> Clarified this point. In your answer you specify
"only" lower layer.
> Did you forget to include AAA layer ? Or do you think
AAA layer might
> receive EMSK?.
Ignoring the definition problems with layers for a while.
I think we know the external behaviour we want. We
want
- Avoid L2 design, implementation, or node compromise
problems
causing the compromise of other L2 networks. Or compromise
of one application of EAP keys leading to the compromise
of
others.
- Allow crypto-agility for the function used in the key
derivation.
- Allow different keys to be used for different attachments,
without keys 2, 3, ... to be based on key 1, which is what
we would have to do with MSK
- Make it possible to use existing EAP methods.
One way of approaching this is to have the EAP server/AAA
server
keep the EMSK, and provide AMSKs for various purposes.
Another
is giving the EMSK to the lower layer, but dictating
something about
its use.
--Jari
____________________________________________________________
_____
To unsubscribe or modify your subscription options, please
visit:
http:/
/lists.frascone.com/mailman/listinfo/eap
Arhives: http://lists.
frascone.com/pipermail/eap
|
|
| About use of EMSK |
|
2006-03-06 09:36:24 |
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
|
|
| About use of EMSK |
|
2006-03-17 20:23:36 |
One thing we might discuss is whether (a) and (b) provide
the same
level of security or not. Since (b) is not end-to-end,
negotiation
bidding down attack may be possible by passthrough
authenticator.
Yoshihiro Ohba
On Mon, Mar 06, 2006 at 11:36:24AM +0200, Jari Arkko wrote:
>
> 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
|
|
[1-5]
|
|