Presentation on theme: "SALSA-NetAuth SALSA-FWNA BoF Kevin Miller Duke University Internet2 Member Meeting May 2005."— Presentation transcript:
SALSA-NetAuth SALSA-FWNA BoF Kevin Miller Duke University email@example.com Internet2 Member Meeting May 2005
Federated Wireless NetAuth Premise Enable members of one institution to authenticate to the wireless network at another institution using their home credentials. –Reduce the need for guest IDs –Simplify authentication when roaming
Current Activities 1. Defining Use Cases for FWNA 2. Identify requirements for roaming implementation
Use Cases 1. Roaming Between Sites a)Guest is a member of participating institution b)Guest from a national lab c)Conference guest (local federation) d)“Guest” is a sensor / probe 2. Roaming between departments within the same institution 3. Shared buildings – multiple organizations in close proximity sharing a wireless infrastructure 4. ? ?
Basic Use Case Purpose: Academic Visitor Actors: Client, AP, Authentication System Procedure –Client associates with AP, initiates EAP association –Client credentials are forwarded to home authentication service –Home server indicates accept/decline
Key Requirements Security –Clients must only need to trust the home server, and must authenticate it –Credentials must be encrypted between client and server Authorization –Sites should be able to restrict network access by user ID or user attributes Accounting –Record authenticated ID and network address for each user. Usability –Users should receive an EAP Message if authorization fails. ??
SALSA-NetAuth Road Map Version 0.9 published 25 April 05 “Strategies” Document – Final Version Published –Taxonomy of some approaches for automating technical policy enforcement “Futures” Documents –Architecture document: Draft 02 Published 25 April 05 A proposed architecture for integrating network policy enforcement Draft 03 Published Soon “Prerequisites” Document – On Hold –A reference to systems and services necessary to deploy NetAuth systems SALSA-FWNA Subgroup – Group Active –To investigate the visiting scholar problem
Strategies Document Taxonomy of mechanisms for automating network policy enforcement –For example: NetReg, Perfigo, etc. –Provides a starting point for discussions on improving the process –References free and commercial systems
Lifecycle of Network Access Registration is the initial state DetectionIsolationNotificationRemediation
Future Architecture Document Developing a unified architecture for future systems based upon current experiences –“Past performance is no guarantee of future results” Identified common features of existing policy enforcement systems
Architecture Document Policy Determination States –L2INIT –L2NEGOTIATION –L3INIT –L3CONNECT –L3SERVICE Final States –Offline: Disconnected –Compliant: Full Access –Non-Compliant: Restricted Access
State Transitions Any Policy Determination State can move to Final State
Policy Evaluation Can be applied in any state Host can move from “final” state to policy state due to external action
Questions Is the state machine an appropriate representation? –Are the states correct? Is the policy evaluation component generic enough? ? ?