1. SALSA-FWNA Activity 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 infrastructuresecurityauthorizationdiagnosticsusability –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-NetAuth Activity 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 DetectionIsolationNotificationRemediation

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 from http://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