| draft-nakhjiri-eap-ho-00.txt | <– Date –> <– Thread –> |
|
From: Nakhjiri Madjid-MNAKHJI1 (Madjid.Nakhjiri |
|
| Date: Fri, 10 Jun 2005 17:43:26 -0400 (EDT) | |
|
Hi folks,
There has been a lot of discussion recently on the use of EAP key management framework for supporting handovers. People (including myself) have been suggesting different methods and it seems that almost all of them have pros and cons associated to them. I tried to put a draft together to discuss ways of using EAP key management and its extensions to support key distribution that is required in an architecture that needs to support user mobility. I am aware that the proposals are mostly half baked and need further considerations, but am at the same time hoping that this may be an step towards consolidating some of thoughts and discussion presented on this list and other places towards a workable and easy-to-understand solution.
Appreciate comments,
Regards,
Madjid Nakhjiri
http://www.ietf.org/internet-drafts/draft-nakhjiri-eap-ho-00.txt
Abstract The current EAP documentation set, such as [EAP3748], [EAPKEY6], and [RADEAP3579] provide a powerful framework for performing combined authentication and key management using an EAP server and an AAA infrastructure. The framework competently deals with many issues related to network-access control and link security setup. However, when it comes to deploying these specifications for mobile wireless environments, where a peer is required to perform fast and/or heterogeneous handovers, the current framework can be extended with more clear guidelines and possibly specifications in ways that prevent interoperability or security issues. This draft intends to explore some of the complications in deploying the EAP framework for handovers and analyze a few solution alternatives. Further threat analysis of each alternative or providing trade-off guidelines for support of handover may be part of the future revisions of this document.
|
- (no other messages in thread)
Results generated by Tiger Technologies using MHonArc.