Hi Jari,
I am not saying you have to have multiple AMSKs for multiple
technologies, but I was providing an example as a case where
people may
want to. I don't happen to be one of them, at least not for
a single AAA
domain.
Anyhow, as far as "<x> MUST be deleted after
<y>" and "<x> MUST be only
used for <y>", I agree there are no differences
IF and ONLY IF <y> needs
to happen only once. I.e. if you use EMSK for generation of
multiple
AMSKs at various times, then EMSK should not be deleted. You
can still
require that EMSK is only used for authorized AMSK
generation, under
whatever conditions that are set. But you cannot create AMSK
later after
EMSK is deleted.
Madjid
-----Original Message-----
From: Jari Arkko [mailto:jari.arkko piuha.net]
Sent: Sunday, March 05, 2006 1:30 PM
To: Nakhjiri Madjid-MNAKHJI1
Cc: Avi Lior; Salowey, Joe; Rafa Marin Lopez; Bernard Aboba;
eapfrascone.com
Subject: Re: [eap] Strawman -10/EMSK deletion requirement?
Madjid, Avi,
>The only reason for caching the EMSK is if you have to
generate an AMSK
>for another application associated with the current
session.
>
>Madjid>> Thank you for clarification. Another
example may be roaming to
>another access technology!!
>
>So the question is do you have to generate all possible
AMSKs and then
>delete the EMSK or can you generate the AMSKs as needed?
>
>Madjid>>i.e. keep EMSK for future AMSK generation.
The first option
>Madjid>>will
>create the need for running EAP again.
>
>
>
We have discussed this before... I do not see an issue for
handoffs to
another access. If your AAA server supports this then it
derives
AMSK_ho_root from EMSK, deletes EMSK but keeps the derived
key. Once a
need to do a handoff arrives, you derive AMSK_ho_key1 from
AMSK_ho_root,
next time you will derive AMSK_ho_key2, etc.
Having said that, I do agree with Avi that there's really
no substantial
difference between "<x> MUST be deleted after
<y>" and "<x> MUST be only
used for <y>", except maybe some implementation
note describing that it
would be a good idea to securely delete the value once you
know that <y>
is done.
But part of this debate is really not about whether the key
should be
deleted, but rather about whether we know the applications a
priori. I
think there are practical and security reasons why it is a
good idea to
set a requirement that the applications are known a priori.
First of
all, there are no surprises to the AAA server; it needs have
specific
authorization to serve a particular application. (Possibly
even specific
code.) Secondly, as we are currently in a world where the
AAA servers
cache no keys at all, we need to avoid a situation where AAA
servers end
up storing a lot of key state and have no way of knowing
when it is
needed. Finally, security-wise I want to know what my EAP
authentication
somewhere means. I, as the end user, do not want surprises.
It is better
to limit the set of applications of the keys at the
beginning. Note that
if you want, you can set up state for handoff/SIP/MIP even
if you do not
know they will actually be used; you set the state and keys
based on the
user's authorization profile.
Based on the above, I still like the design where we know
the possible
applications (and AMSKs) at the first authentication.
But we could write the text slightly differently, based on
what you Avi
suggested.
--Jari
____________________________________________________________
_____
To unsubscribe or modify your subscription options, please
visit:
http:/
/lists.frascone.com/mailman/listinfo/eap
Arhives: http://lists.
frascone.com/pipermail/eap
|