| RE: Issue: AAA Key Caching effectively prohibited? | <– Date –> <– Thread –> |
|
From: Nakhjiri Madjid-MNAKHJI1 (Madjid.Nakhjiri |
|
| Date: Wed, 2 Nov 2005 12:44:22 -0500 (EST) | |
> 1. We've talked about deletion of transported keys from the AAA > server. So if an MSK (or AMSK) is calculated within the AAA layer and > subsequently transported, that key is destroyed and cannot be cached. > [Joe] I don't think we have said that the AMSK must be deleted or cannot be cached. It should be the contrary, the AMSK is a quantity that an application such as AAA can use for the purpose it has defined. Madjid>> AAA can _use_? How about create and keep? [Joe] This depends on how you define your key hierarchy. If you derive your keys directly from the EMSK you have a problem. If you define your keys from an AMSK derive for the purpose of pre-emptive key distribution then things work out a bit better. Madjid>>Are you saying we create our application specific keys out of AMSK that is already called application master key? Not sure what "rainy day" we are saving EMSK for? Why have so many key levels, does anybody care about the CPU and battery consumptions down at a tiny mobile device that may have to do all this? > To be able to do this, it would seem like the AAA server would need to > have access to the EMSK -- since the EAP layer doesn't cache EMSKs, > how else could AMSKs be calculated once EAP authentication completes? > In the case of roaming systems it is not feasible to ask the EAP layer > to calculate every conceivable AMSK that could be useful -- there > could be thousands of them. > [Joe] An AMSK is an application specific master key. Typically there are a few applications for key material that will be invoked for a particular EAP transaction. For example you might have L2 ciphering, preemptive hand-off and Joe's service activation. Each of these would get their own AMSKs, in addition my assumptions is that in many cases you know if you have the capability or the desire to perform these services so it is possible to derive these AMSKs at the same time. These AMSK's may be cached by entities that will then use them derive thousands of keys for ciphering, hand-off, buying auto-parts, etc. Are there cases where we really have 1000's of different applications or where the application is not known ahead of time. If this turns out to be the case then AAA may need to have access to a KDF that has access to the EMSK. Madjid>> I gave 3 examples in my previous email. Are we now creating yet another entity in the protocol? What is a KDF in relation to EAP server and AAA server? > > _______________________________________________ > eap mailing list > eap [at] frascone.com > http://mail.frascone.com/mailman/listinfo/eap >
- RE: Issue: AAA Key Caching effectively prohibited?, (continued)
-
RE: Issue: AAA Key Caching effectively prohibited? Nakhjiri Madjid-MNAKHJI1, November 2 2005
-
RE: RE: Issue: AAA Key Caching effectively prohibited? Bernard Aboba, November 2 2005
- Re: RE: Issue: AAA Key Caching effectively prohibited? Jari Arkko, November 5 2005
- Re: Issue: AAA Key Caching effectively prohibited? Jari Arkko, November 5 2005
-
RE: RE: Issue: AAA Key Caching effectively prohibited? Bernard Aboba, November 2 2005
- RE: Issue: AAA Key Caching effectively prohibited? Nakhjiri Madjid-MNAKHJI1, November 2 2005
- RE: Issue: AAA Key Caching effectively prohibited? Bernard Aboba, November 2 2005
-
RE: Issue: AAA Key Caching effectively prohibited? Nakhjiri Madjid-MNAKHJI1, November 2 2005
- 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
Results generated by Tiger Technologies using MHonArc.