1 / 8

RadSec version 2 IETF 69 - radiusext 26 july 2007

RadSec version 2 IETF 69 - radiusext 26 july 2007. RadSec A secure, reliable transport profile for the RADIUS protocol. Stefan Winter (stefan.winter@restena.lu). RadSec on one slide. wraps RADIUS payloads in new transport profile transport packet payload with TCP

kato-phelps
Download Presentation

RadSec version 2 IETF 69 - radiusext 26 july 2007

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. RadSec version 2IETF 69 - radiusext 26 july 2007 RadSec A secure, reliable transport profile for the RADIUS protocol Stefan Winter (stefan.winter@restena.lu)

  2. RadSec on one slide • wraps RADIUS payloads in new transport profile • transport packet payload with TCP • UDP made sense when one packet per auth was sufficient, bot not any more with EAP conversations • peer's “alive” status does not rely on guessing any more • authenticate peers and encrypt traffic with TLS • obsoletes (weak) shared secrets and static IP bindings • independence of shared secrets and IP bindings enables dynamic peer discovery

  3. Implementations • OSC's “Radiator”: popular RADIUS server, has RadSec since several years • described in company's whitepaper; RadSec v1 • v2 narrows the specification • Stig Venaas' radsecproxy • lightweight RADIUS <-> RadSec proxy • very small + efficient, proxy only • two implementations exist and interoperate -> description of the protocol in use should benefit community

  4. Merits of IP/shared secret independence • server-to-server: ad-hoc session establishment • deployment of NASes possible in • NATted networks • changing IPs (e.g. DSL with forced re-dial) • OpenWRT APs exist already

  5. Why not Diameter? • lack of usable implementations • no real open source solution • most Diameter servers focus on validating EAP-TLS and EAP-SIM • RadSec's simple measures achieve large portion of the merits of Diameter • largely deployed RADIUS installations (easy to leverage to RadSec) • no WLAN NAS support for Diameter • IPR situation concerning Diameter

  6. State of the draft • I-D athttp://www.ietf.org/internet-drafts/draft-winter-radsec-00.txt • describes transport profile, two implementations and use case • submitted independently • out-of-charter for radext (?) • creates no new interop problems with Diameter • Plan: Informational RFC via Independent Submission track or Experimental

  7. Relation to RADIUS+DTLS • very similar approach • differences: • no up-negotiation from RADIUS implemented (could be done though) • dedicated TCP port from beginning of conversation means easier capability determination • on par with RADIUS+DTLS regarding crypto-agility (though RadSec is not a wg item)

  8. Questions? • What do you think? • Does draft fit into radext business? Room in the charter for this? • Is radext the place to discuss the draft? • Informational vs. Experimental?

More Related