• Share
  • Email
  • Embed
  • Like
  • Save
  • Private Content
E Snet Raf Essc Jan2005
 

E Snet Raf Essc Jan2005

on

  • 712 views

Fashion, apparel, textile, merchandising, garments

Fashion, apparel, textile, merchandising, garments

Statistics

Views

Total Views
712
Views on SlideShare
712
Embed Views
0

Actions

Likes
0
Downloads
2
Comments
0

0 Embeds 0

No embeds

Accessibility

Categories

Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

E Snet Raf Essc Jan2005 E Snet Raf Essc Jan2005 Presentation Transcript

  • 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
  • FWNA (Project outline)
  • 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