1. SALSA-NetAuth SALSA-FWNA BoF Kevin Miller Duke University kevin.miller@duke.edu Internet2 Member Meeting May 2005

2. 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

3. Current Activities 1. Defining Use Cases for FWNA 2. Identify requirements for roaming implementation

4. 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. ? ?

5. 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

6. 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. ??

7. 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

8. 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

9. Lifecycle of Network Access Registration is the initial state DetectionIsolationNotificationRemediation

10. 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

11. Architecture Document Policy Determination States –L2INIT –L2NEGOTIATION –L3INIT –L3CONNECT –L3SERVICE Final States –Offline: Disconnected –Compliant: Full Access –Non-Compliant: Restricted Access

12. State Transitions Any Policy Determination State can move to Final State

13. Policy Evaluation Can be applied in any state Host can move from “final” state to policy state due to external action

14. Questions Is the state machine an appropriate representation? –Are the states correct? Is the policy evaluation component generic enough? ? ?