| Re: RE: Issue: EMSK transported to other parties? | <– Date –> <– Thread –> |
|
From: Jari Arkko (jari.arkko |
|
| Date: Mon, 7 Nov 2005 14:53:43 -0500 (EST) | |
Someone wrote: >>>I think it makes sense to have the KDF in the AAA server only when (1) >>>such an entity resides in the same domain as the AAA server and (2) >>>use of the AAA protocol for distributing application-specific keys to >>>application-specific entities is assumed. For other cases (i.e., >>>bootstrapping applications in visiting domain or using non-AAA >>>protocol for distributing application-specific keys), it might be >>>good to put the KDF in a separate entity from the AAA server. >>> >>> I am confused by this. KDF is a function, not an entity. Every we subdivide the key hierarchy in some manner we need a function to do this... this happens in different places in the network, depending on what level of keys we are talking about. and Bernard wrote: >>How could an entity other than the EAP peer or server gain access to the >>EMSK in order to generate AMSKs? The EMSK cannot be transported, so only >>the EAP peer and server can have access to it. An entity must have access >>to the EMSK to apply a Key Distribution Function (KDF) to it in order to >>produce an AMSK. So therefore only the EAP peer and the EAP server can >>apply a KDF to the EMSK to produce AMSKs. >> >> Agreed. and Yoshi wrote: >If we use generic AMSK to derive other AMSKs, the EAP server can >derive the generic AMSK from the EMSK and give it to the entity >providing KDF (and I think the generic AMSK should be >cryptographically bound to the identity of the KDF entity which could >be the AAA server or something else in general). Once it is done, the >generic AMSK can be deleted from the EAP server and no entity needs to >access the EMSK and the generic AMSK. > > We can have lower layer ask for AMSKs. Such AMSKs can have further hierarchy. But I don't think we should have a generic AMSK in the sense that its used for multiple applications. One per app, be it mobile ipv6 with ha x, or handoffs within this domain, or... --Jari
- RE: RE: Issue: AAA Key Caching effectively prohibited?, (continued)
-
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
- Re: RE: Issue: EMSK transported to other parties? Bernard Aboba, November 3 2005
- Re: RE: Issue: EMSK transported to other parties? Yoshihiro Ohba, November 3 2005
- Re: RE: Issue: EMSK transported to other parties? Jari Arkko, November 7 2005
-
Re: RE: Issue: AAA Key Caching effectively prohibited? Yoshihiro Ohba, November 3 2005
-
RE: RE: Issue: AAA Key Caching effectively prohibited? Nakhjiri Madjid-MNAKHJI1, November 3 2005
Results generated by Tiger Technologies using MHonArc.