| Re: Issue: AAA Key Caching effectively prohibited? | <– Date –> <– Thread –> |
|
From: Jari Arkko (jari.arkko |
|
| Date: Sat, 5 Nov 2005 19:33:15 -0500 (EST) | |
Nakhjiri Madjid-MNAKHJI1 wrote:
1. EMSK derived in method
2. lower layer i.e. AAA requests one AMSK:
AMSK_handoff = ...
Lower layer derives to additional keys from
this:
AMSK_handoff_auth = f(AMSK_handoff|"auth")
AMSK_handoff_nasgen = f(AMSK_handoff|"nasgen")
3. EAP authentication completes, EMSK deleted
7. AMSK_handoff_nas_i deletede from AAA server.
o All sent keys can be deleted.
o Other keys that are not sent can be cached.
--Jari
Hi Jari,
Ok, if people feel strongly about not exporting the EMSK to the lower
layer. Then it would seem that a generic AMSK needs to be generated and
passed down to the lower layer (AAA server). The AAA server then should
be able keep the AMSK and to generate other application-specific keys
from the AMSK.
I do not think we want "generic" AMSKs. We want application specific AMSKs. Say, one AMSK for "fast handoff" and another one for "Mobile IPv6 Local HA Assignment". Otherwise one application can break another one. But yes, from a specific AMSK (e.g. for fast handoff) you can create more keys, specific, e.g., to a particular NAS that you have moved to.
Furthermore, it should be possible for the AAA server to not to delete every key it has transported to the pass-through authentication.
Well. Not sure about this. Lets look at this in more detail with an example.
1. EMSK derived in method
2. lower layer i.e. AAA requests one AMSK:
AMSK_handoff = ...
Lower layer derives to additional keys from
this:
AMSK_handoff_auth = f(AMSK_handoff|"auth")
AMSK_handoff_nasgen = f(AMSK_handoff|"nasgen")
3. EAP authentication completes, EMSK deleted
4. AMSK_handoff deleted in AAA server, AMSK_handoff_auth
and _nasgen kept. 4. Host moves to a new authenticator, requests
a key to that without having to reauth at EAP
level. Nonce included. 5. Host and AAA server prove mutual possession of
AMSK_handof_auth. 6. Calculate
AMSK_handoff_nas_i = f(AMSK_handof_nasgen|i|nonce)
AAA server sends AMSK_handoff_nas_i to new NAS.7. AMSK_handoff_nas_i deletede from AAA server.
8. Host and new NAS prove mutual posessions of
AMSK_handoff_nas_iSo from a deletion & caching perspective we can observe that
o EMSK can be deleted immediately, as long as the lower layer (AAA in this case) knows what applications are going to be allowed.
o Each application gets a AMSK that can be kept an appropriate time, depending on whether it is needed or not.
o All sent keys can be deleted.
o Other keys that are not sent can be cached.
--Jari
- RE: Issue: AAA Key Caching effectively prohibited?, (continued)
- RE: Issue: AAA Key Caching effectively prohibited? Salowey, Joe, November 2 2005
-
RE: Issue: AAA Key Caching effectively prohibited? Nakhjiri Madjid-MNAKHJI1, November 2 2005
-
Re: RE: Issue: AAA Key Caching effectively prohibited? Yoshihiro Ohba, November 2 2005
- Re: RE: Issue: AAA Key Caching effectively prohibited? Bernard Aboba, November 2 2005
- Re: Issue: AAA Key Caching effectively prohibited? Jari Arkko, November 5 2005
- Re: Re: Issue: AAA Key Caching effectively prohibited? Yoshihiro Ohba, November 7 2005
-
Re: RE: Issue: AAA Key Caching effectively prohibited? Yoshihiro Ohba, November 2 2005
- RE: Issue: AAA Key Caching effectively prohibited? Nakhjiri Madjid-MNAKHJI1, November 2 2005
-
RE: RE: Issue: AAA Key Caching effectively prohibited? Nakhjiri Madjid-MNAKHJI1, November 3 2005
- Re: RE: Issue: AAA Key Caching effectively prohibited? Yoshihiro Ohba, November 3 2005
Results generated by Tiger Technologies using MHonArc.