SALSA-FWNA Activity Update

1. SALSA-FWNAActivity Update Kevin Miller • Duke University kevin.miller@duke.edu Internet2 Member Meeting May 2005

2. Federated Wireless Auth Vision • 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 • The “roaming scholar” problem • Wired network roaming comes “free”

3. Federations • Goals of federations • Establish trust between entities • Make assertions about identities (authenticate) and release attributes • Protect user privacy through opaque user handles and controlled attribute release

4. Federations • All are relevant to FWNA • Need to create/reuse trust between sites • Could take many forms (hierarchical, central, 1-way, …) • Shibboleth is a candidate • Visited sites may want attributes about visiting users (e.g. type of user, mobile number) • Control release of user information

5. Potential Federations • Decentralized School • School Systems • State schools, local school districts, etc. • Regional consortia: GigaPoP / *REN • National consortia: Internet2 • International: EduRoam • Government: ESNet, NSF, NASA • Industry

6. Use Cases • “Simple” Roaming within Federation • Among Peer Institutions • Local Federation (Conference Guests) • Sensor Nets • Municipal Networks • VoIP • Inter-Federation Roaming • Shared Tenancy • Commercial Roaming

7. FWNA Project Plan • Work divided in two phases • Phase 1: RADIUS Hierarchy • Initial solution to the problem • Modeled after current Eduroam network • Develop knowledge of relevant technology • Learn capabilities and drawbacks of hierarchy • Relatively straightforward • Exchange RADIUS keys • Interface to existing authn systems using basic RADIUS mechanism

8. FWNA Phase 2 • Phase 2: RADIUS + Federation • Develop technically superior solution that enables attribute release • Identify and address other concerns regarding FWNA implementation • infrastructure • security • authorization • diagnostics • usability • Requires development • May not be solved by FWNA itself

9. Framing the Solution • 802.1x • Often used with WPA or WPA2 (802.11i) for edge encryption • Or middlebox access controller • EAP authentication • Exact EAP type selected by home institution, deployed on client machines • Establish client-to-home trust for purpose of transporting credentials

10. Beyond authentication… • In many cases today, once authenticated all users obtain same level of service • FWNA is about identity discovery • We must be able to separately provision services from authn and attributes: • Technical setup (IP address, QoS, ACL, etc..) • Access policy • Billing

11. Other Areas of Investigation • Real Time Diagnostics • Determining cause of authn failure • Requires additional inter-domain data exchange • Access Point Roaming • Will cause re-authentication back to home server (additional delay) • Mitigated by 802.11i pre-authentication

12. FWNA Project Milestones • Phase 1 • Core RADIUS Server: Established • Experimentation: Ongoing • Phase 2 • Technical plan: Ongoing • Experimentation: TBD

13. Join the FWNA Group • Project website:http://security.internet2.edu/fwna • Biweekly Conference Calls • Thursday 11am-12pm: May 19 • 866-411-0013, 0184827 • salsa-fwna @ internet2 list • “subscribe salsa-fwna” to sympa @ internet2

14. SALSA-NetAuthActivity Update Kevin Miller • Duke University kevin.miller@duke.edu Internet2 Member Meeting May 2005

15. 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 Will Be 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

16. NetAuth Timeline

17. NetAuth Road Map • NetAuth still focused on document development • Engaging other players in the space (Cisco NAC, Microsoft NAP, TNC) • Encouraging and/or Developing for these efforts

18. Strategies Document • Draft 3 became final version • Published 20 April 2005 • Edited by Eric Gauthier (Boston University) and Phil Rodrigues (New York University) • May return to draft stage after wider analysis and vetting

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

20. Lifecycle of Network Access • Registration is the initial state • Detection • Isolation • Notification • Remediation

21. NetAuth Prerequisites • Currently on hold • The Strategies document assumes certain underlying components (systems, software) • The Prerequisites would be a reference to sites interested in establishing network policy enforcement • May evolve as a reference to EDUCAUSE Effective Practices, RESNET presentations, and some additional material as necessary • Will be covered in Futures documents

22. Futures Documents • Originally targeted as a single document • Too complex • Current goal is to outline each in a separate document: • Architecture • Components • Deployment

23. Futures Documents • How would we design a NetAuth system if we could do it again? • Focused on interoperability and modularization • Leveraging the taxonomy from the Strategies document to define a unified architecture • Building text and images to understand the space

24. Futures Documents • Example implementations from the architecture will demonstrate better ways of achieving policy enforcement • Cognizant of vendor/commercial activity in this space • Trusted Computing Group TNC • Cisco NAC • Microsoft NAP

25. Future Architecture Document • Draft 02 published 25 April 2005 • Draft 03 will be published soon • Edited by Kevin Amorin (Harvard), Eric Gauthier (Boston University)

26. Future Architecture Document • Two major themes • Workflow • Conceptual model • How a ‘network’ may determine and enforce policy compliance • State Diagram • Mapping of states and transitions • Summation of above workflow

27. Future Architecture Workflow • Transitions through states can be triggered by various events • Connections • Disruptions • Change in endpoint network stack • Active scanning • Passive detection • Event detection causes a policy decision • Possible enforcement action • Transition to next state

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

29. Future Architecture Workflow • Process oriented • A drill down of state transitions in future NetAuth systems • Iterative policy decisions • Policy compliance/non-compliance determined by summation of policy decisions • Based on local criteria

30. Future Architecture States • The network cycles through various well-defined states while determining policy compliance • Transitions between states are defined by the workflow above • Provides a taxonomy of these states • Represents the lifecycle of an endpoint during policy determination

31. State Transitions • Any Policy Determination State can move to “Final” State • External events cause transition back to Determination State

32. Future Components Document • Pre-draft stage • What are the components the comprise a NetAuth system? • How do these components: • Communicate • Interoperate • Modularize • Application to use-cases

33. Why Develop Futures Documents? • NetAuth systems are complex • There are a mix of commercial and open-souce offerings • Complexity is obscuring our understanding of how they work • As ‘Strategies’ provided a baseline for the current deployments, this effort will help us analyze future systems

34. FWNA Interactions • We (will) deploy NetAuth systems to federated environments (like FWNA) • To ensure endpoint policy compliance • What if the home institution policies vary from the visited institution? • How do we notify the user if they are a guest? • Identifiers may be opaque

35. FWNA Interactions • Understanding NetAuth in a federated environment is a challenge • Deployment constraints • Policy enforcement consequences • We can’t understand how NetAuth works in a federated environment until we have a consistent taxonomy to discuss them

36. Join the NetAuth Group • All documents available fromhttp://security.internet2.edu/netauth • Biweekly Conference Calls • Thursday 12pm-1pm (EDT): May 12, May 26 • 866-411-0013, 0122644 • salsa-netauth @ internet2 list • “subscribe salsa-netauth” to sympa @ internet2