eap Mailing List: RE: Strawman -10/EMSK deletion requirement?

[Nakhjiri Madjid-MNAKHJI1 (Madjid.Nakhjiri]

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 [at] piuha.net] 
Sent: Sunday, March 05, 2006 1:30 PM
To: Nakhjiri Madjid-MNAKHJI1
Cc: Avi Lior; Salowey, Joe; Rafa Marin Lopez; Bernard Aboba;
eap [at] frascone.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