ESnet RADIUS Authentication Fabric: Federating Secure Authentication

1
ESnet RADIUS Authentication FabricFederating
Secure Authentication

• Michael Helm
• ESnet ATF Project
• 10 March 2005

2
ESnet RADIUS Authentication Fabric

• What is this for?
• Enabling strong, cross-site authentication
• What is the RAF?
• Hierarchy of RADIUS servers that route
  authentication queries from an application (e.g.
  a login process) at one site to a One-Time
  Password (OTP) service at the users home site
• A collection of cross site trust agreements
• Feasibility study requested by ESSC is complete
• Model RADIUS hierarchy interoperating with
  multiple OTP services
• Next step is a pilot project that will build the
  foundation for a production service
• 3 FTEs plus equipment
• New opportunities - initiatives in Internet2 and
  EU
• Project papers at
• http//www.es.net/raf
• Whitepaper, presentations, ESSC proposal

3
How Does the RAF Work?

• In the example shown, sites have deployed
  one-time password (OTP) authentication services
  and have federated at the RAF
• Home institution issues user a one-time password
  token (such as a CryptoCard)
• The user wants to use a service at another
  institution
• Service login application takes RAF
  johndoe_at_pnnl.gov login name, plus password
  generated from users token
• Login application forwards to edge RADIUS
• Edge RADIUS forwards the non-local name
  authentication query to the RAF
• RAF forwards authentication query to users home
  institution for validation
• RAF returns validation response to originating
  application
• Edge RADIUS (or PAM) maps name to local account
  OR
• Edge RADIUS (or App) applies appropriate
  authorization

4
How Does the RAF Work?
Edge RADIUS knows local realms, and OTP
Local Realm
Local Realm
ORNL
PNNL
OTP Service
OTP Service
r
r
6
ESnet
5
4
R
RAF Realms
RAF Realms
6
ANL
NERSC
Local Realm
OTP Service
OTP Service
3
r
r
Core RADIUS knows all RAF Realms
6
A
1
2
Each user has an OTP token from home site (local
realm)
RAF Realms
RAF Realms
5
What is the RAF?

• Hierarchy of RADIUS servers
• ESnet runs a core of redundant, secure RADIUS
  servers
• Sites each have (typically) one edge RADIUS
  server
• Authentication transport and routing scheme
• RADIUS server (proxy) authentication queries
  are routed from edge site to edge site thru the
  core, using standard RADIUS proxy packets
• RADIUS realm naming convention
• mike_at_es.net local_name _at_ realm_name
• Use local names and DNS names
• Realm names gt route
• Security and reliability (24x7 infrastructure)
• Enhancement / development opportunities
• RADIUS can support other authentication through
  encapsulation
• RADIUS can support some authorization information
• Sites own authorization and application
  deployment decisions
• See RFC 2865
• Obviously, this is subject to engineering and
  policy

6
Applications

• Application
• A computer process, service, or user interface
  that requires some kind of authentication and
  authorization. Examples include Windows or UNIX
  login service, a protected web page, sshd, a Grid
  credential store, an IMAP mail service, a
  database, a VOIP service.
• Many applications benefit from OTP. Not all
  applications require the RAF.
• Why dwell on applications?
• RAF separates itself from applications, but the
  middleware linking the application to the RAF in
  legacy applications always needs work
• We need common solutions and UI for applications
  as part of RAF.

7
RAF Key Points

• One-time passwords (OTP)
• RAF makes distributed computing services possible
  and practical, in face of OTP deployments
• Not just OTP
• RAF supports other authentication foundation for
  multiple trust communities?
• Transport layer for authentication (or, maybe,
  AAA) queries/responses
• Like the ESnet network and all ESnet services,
  separation from site security solution,
  authorization decisions, and application
  deployment
• UNIX and Windows but different methods
• RAF is not a security solution it enables other
  security solutions

8
RADIUS OTP Feasibility Study Summary

• April 2004 project proposal
• ESSC charge
• Based on NOPS (NERSC) requirements document
• http//www.doegrids.org/CA/Research/GIRAF.doc
• Evaluated two OTP vendors
• SecurID Cryptocard
• Three strong sites
• NERSC ORNL ESnet
• Applications Apache (secure web server), and
  sshd
• RADIUS appliance vendor Infoblox
• Results were very favorable

9
Next Step RAF Pilot Project Proposal

• RAF Whitepaper
• http//www.es.net/raf/ESnet-RAF-WP.pdf
• Advance to Pilot
• Build the core edge sites
• Put an application into production
• Federation
• Technical and policy oversight essential to
  provide a trusted infrastructure
• RD needed
• Kerberos and RADIUS can they work together?
• RADIUS and applications have issues
• In order to support this, we must buy additional
  equipment and add staff

10
RAF Pilot Project plan

• Build on feasibility study
• RAF Whitepaper has detailed argument
• Pilot Three core, three edge sites ( others)
• Turnkey for some sites
• Others will provide own solution
• Engineering work
• 24x7 level robustness in the core
• Contingency RSA/SecurID support
• Federation see detail slide
• Application support selected apps
• One internal application
• Kerberos
• Restart Kerberos-in-RADIUS encapsulation effort,
  or
• Preferably, support NERSC initiative

11
Federation

• Site representatives
• OTP projects
• Early Manage applications
• Identify appropriate applications for RAF
• Review/spec middleware
• RAF oversight
• ESnet RAF core Operations security
• Best practices for OTP services
• Best practices for Edge RADIUS servers
• Support and service metrics
• Note this kind of federation is more basic
  than the Internet2/Shibboleth usage

12
RAF Pilot Costs

• 6 Infoblox high availability pairs 12 units x
  12k ea
• 150K
• 3 core pairs 3 edge pairs
• Support Misc. servers 20k
• 3 FTE (750K)
• Developer 1.25 FTE
• Engineering cases support
• Replication services
• Selected application development
• Deployment 1.25 FTE
• RADIUS configuration management
• VPN / IPSec management
• Support
• Federation 0.50 FTE
• National team coordination
• Outreach
• Travel Training/conferences 20k
• Contingency Need access to SecurID for 1 year
  cost unknown
• Ongoing Expect about 0.5 FTE (developer-deploymen
  t) 0.5 FTE (federation) indefinitely

13
RAF Pilot
Core RADIUS knows all RAF Realms
14
What is the problem with Kerberos?

• Kerberos is important FNAL, others
• FNAL has integrated their KDC with OTP
• RADIUS is a simple authentication query
• Name/password gt Yes or No lightweight protocol
• Kerberos is a comprehensive authentication
  security protocol (RFC 1510)
• Large impact on infrastructure
• RADIUS and Kerberos are invisible to each other
• Use cases we need something like EAP-Kerberos
• KDC Key Distribution Center Authentication
  dbms

15
One-Time Passwords (OTP)

• Identity bound to one-way function, not password
  string
• Eliminates several common classes of attacks
• Token-based technology is simple
• No dongles push-button operation (or simpler)
• Sites can choose to make it very complex
• Problems
• Requires back-end database
• Requires application integration (fairly modest)
• Vendors have poor interoperability story
• RAF and SETA address these problem areas

16
Relationship With PIV

• Some PIV integration ideas
• http//www.es.net/PIV/PIV-support.txt
• Edge RADIUS can provide direct PIV support
• Legacy apps still need to outsource
  authentication
• EAP-TLS support client (PIV) certificates
• Hybrid
• Support OTP and PIV
• Modest project extension
• Enable and test EAP-TLS support on RADIUS (we
  want to do this anyway)
• Develop application middleware to pass client
  certificates through (not unlike Grid software)

17
Who Will Use RAF?

• High profile research
• DOE Lab researchers, between DOE Lab sites
• External collaborators, with affiliations at
  multiple sites
• Other uses
• External RADIUS trust federations and OTP
  infrastructure, as they develop
• Roaming/visiting scientists

18
Who Will Use RAF? (2)

• NERSC
• Fusion Grid
• The GIRAF, or Grid-Integrated RAF, is alive and
  well in FG. Good progress is being made in
  extending initial OTP work done by NCSA to
  support RSA SecurID.
• BNL
• Letter of support from Scott Bradley to ESCC, and
  other BNL comments
• FNAL
• We have good dialogue with them, but we must come
  up with a Kerberos-RAF interoperation scheme.
  NERSC is addressing this.

19
Benefit to Community

• Proactive security
• Eliminate classes of security attacks based on
  reusable passwords
• Provide security for non-PIV problem areas
• Moderate cost savings
• Reduce duplication of application development
• Reduce token deployment
• Improve the situation of high profile researchers
• Reduce OTP impact No DOE OTP Bandolier
• Reduce exposure and worry

20
New Opportunities

• Other RADIUS hierarchy projects
• FWNA, wireless roaming
• Internet2 Salsa subgroup Federated Wireless
  NetAuth
• http//security.internet2.edu/fwna/
• 802.1x and related security protocols
• Wireless is marketing network admission is
  closer
• Shibboleth for authorization eventually
• http//shibboleth.internet2.edu/
• Just beginning feasibility study
• EduRoam
• Roaming in EU and AU
• http//www.eduroam.org/
• 2 years old some infrastructure

21
Conclusion

• What are the sale/no-sale issues?
• Does it address the right problems?
• What is the true demand (remember driver)?
• Level of Commitment
• Direction
• Project plan / management
• otp-eng_at_nersc.gov
• helm_at_es.net
• http//www.es.net/raf