E Snet Raf Essc Jan2005

ESnet RADIUS Authentication Fabric Michael Helm 19 January 2005

ESnet RADIUS Authentication Fabric Report on RADIUS-OTP feasibility study ESSC commissioned Apr 2004 ESnet and collaborators : May – Oct 2004 ESnet RAF Whitepaper – product of study Proposed service Section-by-section Note: “ESnet RAF Progress Report” Discuss project next steps: project proposal Pilot production service Additional R&D New opportunities: FWNA, wireless roaming

RADIUS – OTP Feasibility Study Summary April Project proposal: http://www.doegrids.org/CA/Research/GIRAF.doc Evaluated two OTP vendors: SecurID Cryptocard 3 “Strong” Sites NERSC ORNL ESnet Applications: Apache, and sshd RADIUS Appliance vendor : Infoblox Results were very favorable

RADIUS – OTP Next Steps – Project Proposal Advance to Pilot: Build the core; edge sites Put an application into “production” R&D needed : RADIUS has many issues Applications have some issues Kerberos and RADIUS: can they play together? New opportunities : 802.1x, EAP-TLS, and more Wireless / roaming initatives In order to support this, we must buy additional equipment and add staff .

ESnet RAF Whitepaper Plan http://www.es.net/raf Background Architecture Applications and Services Outstanding Engineering Issues Federation Future Work / New Opportunities Team

Background DOE Lab Computing Facilities Hacked Panel discussion at Apr 2004 ESSC OTP and RADIUS efforts commissioned Why OTP? NOPS – NERSC founded grassroots effort RADIUS Authentication Fabric ESnet response to OTP initiatives

DOE Lab Computing Facilities Hacked Widespread hacking incidents early 2004 Crossover between DOE labs, NSF labs, educational institutions, other collaborations Long lifetime, reusable passwords No amount of self-protection adequate Privilege escalation Attack “unpatchable” services Platform for further attacks Problems continued through 2004

Why One Time Passwords? OTP tokens limit effectiveness of sniffing OTP breaks up domino effect noted in recent hacks Additional protection for unsecured, commercial environments (kiosks, shared / home computers &c) Tokens and commercial services Improve the user experience over S/KEY Reduce / limit some threats related to management of the one-time password list Tokens (and OTP in general) add some additional, DoS-type threats

NOPS NERSC + friends organized to respond to hacks; protect distributed collaborations How would a large-scale OTP deployment actually be accomplished? What product or products would be used? What would happen to the applications and services? Requirements document The multiple token catastrophe

What is the Multiple Token Catastrophe? Assume a large physics collaboration. A scientist at LBNL needs to move data from an experiment at FNAL, to an archiving service at ANL, and then run a distributed simulation from compute centers at NERSC and NCSA. How many different OTP hardware tokens does she need to use to get her work done? <insert picture of DOE Bandolier here> The answer should be: she needs only ONE

RADIUS Authentication Fabric Solution to the OTP interoperability problem Solution to the Multiple token catastrophe But – does not exclude other solutions! App can require particular token Sites + vendors can use proprietary interoperability capabilities transparently What is the RAF? Deploy a hierarchy of RADIUS servers Edge (site) RADIUS servers support applications Edge RADIUS forwards to ESnet RADIUS core ESnet RADIUS core dispatches to site back end authentication service Let’s look at an architectural picture and work through an example….

How Does the RAF Work? All RAF Realms NERSC ANL r OTP Service ORNL r PNNL OTP Service OTP Service OTP Service R ESnet RAF Federation anl.gov nersc.gov pnnl.gov ornl.gov S r r RAF Realms RAF Realms RAF Realms RAF Realms r RADIUS

Architecture Fill in – explain protocols / jargon One-Time Password Technology RADIUS RADIUS Naming Convention RAF Terminology RAF Core – RADIUS components @ ESnet RAF Edge – RADIUS @ sites or … Fabric – Core + Edge+RADIUS clients

One-Time Password Technology (OTP) Account is static Password is dynamic Tied to a non-reversible algorithm: see S/KEY RFC Eliminating reusable passwords eliminates classes of threats OTP can be retrofitted into legacy apps Looks like ordinary password dialogue App must be able to outsource Auth* This done through PAM – Pluggable Authentication Module

One-Time Password Technology (Vendors) Three principal vendors in DOE labs RSA: SecurID – market leader – 4 sites Proprietary, time - sequence based algorithm Cryptocard – FNAL, others experimenting sequence based; open source (?) Safe Computing: Safeword – LBNL Sequence based Non – interoperable!

RADIUS RFC 2865: http://www.ietf.org/rfc/rfc2865.txt About 10 years’ development history Wide support in industry Built-in features support our needs: Proxying RADIUS-RADIUS and RADIUS-OTP back end Adequate extensibility and security and other features RADIUS Realm: “name” used to organize RADIUS features This is just a fancy way to describe how we divide up our hierarchy and decide where to forward auth queries Client-server model NAS =Network Access Server=Radius Client(=PAM) Naming convention

RADIUS - Infoblox Appliance – Infoblox Soon: FreeRADIUS based http://www.infoblox.com/products/radiusone_overview.cfm Dedicated Hardware Minimal Ports No User Accounts High Availability Geographical dispersion

RADIUS Naming Convention RADIUS RFC defines names RADIUS RFC mentions realms , but does not define realms One widespread convention for this is name@Radius-realm eg [email_address] or [email_address] We will use our top-level domains: mike@es.net or joe.doakes@nersc.gov Caveat: RADIUS user names are case-sensitive!

RAF Terminology RAF Core – RADIUS servers operated by ESnet Authentication routers – RADIUS proxy Back end database RAF Edge – RADIUS servers at sites or… RADIUS client – PAM Usually identical: most services of interest use a RADIUS client in PAM (… Except wireless)

Applications and Services Applications – consumed a lot of our time The “ESnet RAF Progress Report” documents much of this work. From the RADIUS operation point of view, the OTP back end services are another application . ESnet set up several RSA demo services in 2004 for its own use. We did not have the resources to set up other vendors’ products, but relied on NERSC and ORNL to help us with additional instances and alternate vendor. Applications and PAM PAM widely used in modern UNIX Semi-standardized; capabilities vary Multi-layered API: many capabilities GIRAF (See picture next) We focused on these 2 widely used applications SSHD Apache

Grid Integrated RAF GIRAF OTP Grid App MyProxy RADIUS Authentication Fabric On-Demand CA (SIPS) GridLogon ESnet Root CA 0 Sign Subordinate CA 1Token authentication; release proxy cert 3 RADIUS Auth query 4 OTP Back end authentication 2. “Prime” account

GIRAF Looks complicated, but it can be REAL simple: openssl req + simple RADIUS client + signing key pair + name policy Or NCSA Grid Logon proposal (Fusion Grid, NERSC) Or Infoblox RADIUS server! Very important app – protect Grid investments

Outstanding Engineering Issues RAF Core The set of RADIUS servers operated by ESnet Route authentication requests RADIUS Operations and Security Not ESnet-specific issues: but somebody needs to work on these: OTP Applications SETA: Secure, Extensible, Token Authentication (NB: 15 Dec 2004) Grid Integrated RADIUS Authentication Fabric Web server client authentication Ssh Large scale file transfers Firewalls and VPNs Client security

Applications ESnet should pick ONE (but see later) Volunteers or broader project for others “Everything needs work” – mostly PAM GIRAF – NCSA/NMI support? SETA – NERSC proposal Batch jobs Kerberos support

RAF Core Reliability, reliability, reliability Multiple instances WAN high-availability Presentation: round robin or individual We need to understand failure modes better Simpler is better Where does the “core” end? Doesn’t matter now: we need configuration solutions for “edge” or site RADIUS

RADIUS Operations and Security RADIUS security shortcomings OTP bypasses some of these Shared secret RADIUS-RADIUS-R Client Lack of confidentiality of transactions Need to secure admin interfaces Absolutely must protect against man-in-the-middle hijacking &c Deploy VPN or IPSec to support service Look at EAP/802.1x for person RADIUS Operations and Security

OTP Engineering Issues Cryptocard receives better reviews, but… Essential to support RSA SecurID ESnet needs access to both technologies Quality control issues: Error recovery Lost back end server Reporting synchronization errors Documents needed OTP Service “Best Practices” guides and other security analysis

Federation “ Layer 8” issues trump technical issues RAF Federation document in draft: http://www.es.net/raf /DOE%20OTP%20federation_v2.doc Federation governance: Based on GGF template RAF-specific issues: Types of authentication permitted VPN or IPSec management Token management – replacement, resynchronization, etc Radius shared secret management RADIUS configurations RADIUS replication Realm naming practices DISCLOSURE by participants (sites) is essential How should this federation be governed/populated?

Team – RAF/NOPS/Globus ESnet: Tony Genovese, Michael Helm, Roberto Morelli, Dhivakaran Muruganantham, John Webster InfoBlox: Edwin Menor, Andy Zindel LBNL : Olivier Chevassut NERSC: Stephen Chan, Eli Dart ORNL: Tom Barron, Sue Willoughby ANL: Remy Evard, Gene Rakow, Craig Stacey; Frank Siebenlist (Globus) PNNL: Craig Gorenson NCSA: Jim Basney, Von Welch

Future Work / New Opportunities KERBEROS – RADIUS interoperability NERSC’s SETA FNAL Use cases DIAMETER IETF (partial?) replacement for RADIUS Wireless – FWNA Wireless Roaming initiatives September 2004 – GGF-12

KERBEROS-RADIUS Motivated by FNAL situation: Cryptocard tightly integrated with KDC Predates this effort How can we integrate them? Use case (hypothetical) FNAL scientist wants to use service at LBNL (no Kerberos) Get OK at LBNL from FNAL KDC LBNL scientist wants to use FNAL service (Kerberos) Get TGT at FNAL from LBNL RADIUS OK FNAL scientist wants to use NERSC service (K2K) Get forwarded TGT | Kerberos interrealm from FNAL OK? Don’t have any of this – can EAP do this? Can we find EAP-GSS or something similar?

DIAMETER DIAMETER – IRTF/IETF replacement for RADIUS – RFC 3588 TCP instead of UDP Mandatory IPSec support In practice, TLS too; ie most security is in hands of security protocols, not DIAMETER Dynamic discovery Better proxy and roaming support Universal support is “some years away” However: Wireless initiatives may need DIAMETER in the core: more like a true “authentication router”

Federated Wireless Network Authentication First contact: Eduroam, Sep 2004 TERENA initiative to support roaming in European NREN community Eduroam contacts led us to I2 SALSA-Netauth FWNA subgroup: milestone 0 of similar project We all have the same RADIUS architecture Eduroam is 6-12 mos ahead of ESnet technologically SALSA, Eduroam, and ESnet RAF all have some orthogonal components

FWNA http://wiki.netcom.duke.edu/twiki/bin/view/NetAuth/WebHome “ Analysis and proposal toward a pilot and eventual implementation to support network access to visiting scholars among federated institutions.” Subgroup of Internet 2 SALSA-Netauth

Eduroam TERENA TF-Mobility New site: http://www.eduroam.org Originally: 802.1x and web based redirection More elaborate requirements run-up Pilot began about Sep 2003

Project plan Build on feasibility study Pilot: 3 core, 3 edge sites (+ others) Engineering studies: Data replication Contingency: RSA/SecurID support Federation: build out Application: support selected apps One internal application

What Will It Take? 6 Infoblox HA pairs – 12 units / $12k ea ~ $150K 3 core pairs; 3 edge pairs Support: Misc. servers: $20k Travel: training/conferences: $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 Contingency: Need access to SecurID for 1 year: cost unknown Ongoing: Expect about 0.5 FTE + Federation 0.5 FTE indefinitely

What Will It Take? (2) New initiatives – After 1 st year Eduroam + I2/FWNA: 1.5 FTE 1.0 Deployment 0.5 Federation burden DIAMETER Initial deployment cost Reduce maintenance as IPSec and discovery simplify KERBEROS 0.25 FTE – Feasibility and implementation estimate

RAF Pilot Lab4 Lab2 r OTP Service Lab1 Lab3 OTP Service OTP Service OTP Service ESnet RAF Federation S r r RAF Realms RAF Realms RAF Realms RAF Realms All RAF Realms R1 R3 R2 R1 – Master R2,R3 – Slaves rE – Edge rE rE rE FreeRADIUS External Hierarchy r RADIUS

RAF Pilot engineering Replication Presentation – is the core round robin, or distinct nodes? Default and filtering : new info from RADIATOR and Infoblox Error conditions and reporting VPN/IPSEC Lights out / Colocation configuration Edge site / customer configuration

Applications What is the most useful application? sshd ESnet application – roaming support? Complication: trust domains GIRAF – NERSC, Fusion Grid

Federation Build out Rules / policies Role of ESSC in oversite / reporting

Conclusion Discuss: Level of Commitment Direction Project plan / management http://www.es.net/raf

E Snet Raf Essc Jan2005

More Related Content

What's hot (19)

Viewers also liked (11)

Similar to E Snet Raf Essc Jan2005 (20)

More from FNian (20)

Recently uploaded (20)

E Snet Raf Essc Jan2005