Transcript 20050503-SALSA-Miller2

SALSA-FWNA
Activity Update
Kevin Miller • Duke University
[email protected]
Internet2 Member Meeting
May 2005
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”
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
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
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
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
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
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
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
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
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
FWNA Project Milestones
Phase 1
– Core RADIUS Server: Established
– Experimentation: Ongoing
Phase 2
– Technical plan: Ongoing
– Experimentation: TBD
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
SALSA-NetAuth
Activity Update
Kevin Miller • Duke University
[email protected]
Internet2 Member Meeting
May 2005
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
NetAuth Timeline
SALSA-NetAuth Activity Timeline
5/04
Group
6/04
7/04
8/04
9/04 10/04 11/04 12/04
1/05
2/05
4/05
5/05
Group Active
Prerequisites
Strategies
3/05
On Hold
Document Complete
Future
Architecture
Draft 02 Released
Components
FWNA
Pre-Draft
Group Active
6/05
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
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
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
Detection
Detection
Isolation
Notification
Remediation
Isolation
Notification
Remediation
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
Futures Documents
Originally targeted as a single
document
– Too complex
Current goal is to outline each in a
separate document:
– Architecture
– Components
– Deployment
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
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
Future Architecture Document
Draft 02 published 25 April 2005
Draft 03 will be published soon
Edited by Kevin Amorin (Harvard),
Eric Gauthier (Boston University)
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
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
Policy Evaluation
Can be applied in
any state
Host can move
from “final” state
to policy state due
to external action
Workflow Diagram
Network
Transitions
to New
State
Detection
Detection
External Event
Occurs – Policy
Decision Check
Required
Policy Decision
Policy Action:
Move to new state
Lookup to
Policy
Repository
Policy Action:
Enforcement
Action Required
Policy
Enforcement
Applied
Notification
Isolation
Remediation
Take Enforcement Action and return to Policy Decision
Policy Action:
None Required
Network Transitions
to a fully compliant or
non-compliant final
state.
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
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
State Transitions
Any Policy
Determination
State can move to
“Final” State
External events
cause transition
back to
Determination
State
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
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
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
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
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