RADIUS EXTensions BOF (radext) Friday, November 14 at 0900-1130 ================================= CHAIRS: Bernard Aboba <aboba@internaut.com> David Nelson <dnelson@enterasys.com> AGENDA: Preliminaries - 5 minutes Bluesheets Meeting Minutes Agenda Bashing What is the work, and how real is it? Ground rules: if you've read 3 or more drafts, sit in the front. Sessions divided according to: - Basic RADIUS work - SIP RADIUS - LAN apps - PPVPNS Time is enforced. 5 questions each presenter should address: - which WG do you want to undertake the work? - is it currently deployed? - is it being implemented? - is under discussion in the IETF? - is it under discussion in another SDO? Basic RADIUS work RADIUS UDP Transport Mapping - Avi Lior, 5 minutes http://www.ietf.org/internet-drafts/draf t-lior-radius-udp-transport-mapping-00.txt - Motivation is to improve RADIUS reliability (now focused on Retransmit behavior) - doing re-authentication every time someone does push-to-talk (for cell phone applications), i.e. re-authentication at service instantiation, not just at login - huge increase in RADIUS traffic - currently no guidelines for retransmission strategy - sometimes retransmission is OK, sometimes it's really bad, depending on scenarios - current practice uses static retransmit timers often with default values which may lead to congestive collapse (RFC 2914) - some implementations retransmitting at intermediate [proxy] nodes - recommendations: no retransmission from [proxy] intermediate nodes (but track retransmission) calculate RTO based on RTT (RFC 2988), per-destination (but we don't know how proxies route packets) - do we want a heartbeat command? (RFC 3359 discusses these) - do we jitter? - do we differentiate treatment of packets? - do we dork with RTO timers? SHOULD BE DONE IN RADEXT, NOT DEPLOYED, NOT IMPLEMENTED, NOT UNDER DISCUSSION IPv6 support in the RADIUS MIBs - David Harrington (for Bert Wijnen) http://www.ietf.org/rfc/rfc2618.txt http://www.ietf.org/rfc/rfc2619.txt http://www.ietf.org/rfc/rfc2620.txt http://www.ietf.org/rfc/rfc2621.txt - need to change IPv4-only addresses to handle IPv6 - two new objects in each MIB - older objects to be deprecated - need new compliance statement and updated security information - MIB and IPR boilerplate, etc. - MIB doctors suggest SSPP in a separate module SHOULD BE DONE IN RADEXT, NOT DEPLOYED, NOT IMPLEMENTED, NOT UNDER DISCUSSION RADIUS management - David Nelson - Extended Management Attributes - what is the need, how to fill it, is it interesting? - existing management attributes imply CLI interface (Admin/NAS-Prompt) - no way to provision other forms of management - SNMP, HTTP - add "Framed-Management" value of Service-Type attribute - more management roles - today, we have only two - add "Management-Access-ID" attribute - map to management privilege level - map to SNMPv3 VACM entries, split-horizon management views - need to provision security level - SSH, SNMPv3, HTTPS/TLS - add Management-Protocol attribute (SNMP versions, etc) per authorized user - we're doing it vendor-specific - any interest from others? SHOULD BE DONE IN RADEXT, NOT DEPLOYED, EARLY DESIGN BUT NOT IMPLEMENTED, NOT UNDER DISCUSSION RADIUS client kickstart - Alan DeKok, 10 minutes http://www.ietf.org/internet-drafts/draf t-moskowitz-radius-client-kickstart-01.txt http://www.ietf.org/internet-drafts/draf t-moskowitz-sspp-snmp-01.txt - Problem is that vendors have WLAN APs that get DHCP addresses, and need to authenticate users - authorizations are based on addresses, so ... you're hosed - AP autoconfig become impossible, shared secrets are difficult to manage - need to add indirection to RADIUS client secret and registration of client IP address - SSPP runs over SNMP using Diffie-Helman - subject to MITM attacks, but that are ways to fix this - add "Access-Boot" request command in client registration (with replay prevention) - server responds with encrypted data of session secret and session timeout - validates fingerprint of client's D-H value - prevents replays, spoofing, packet modifications SHOULD BE DONE IN RADEXT, NOT DEPLOYED, NOT IMPLEMENTED, UNDER DISCUSSION IN IEEE for wireless RADIUS Prepaid - Avi Lior, 10 minutes http://www.ietf.org/internet-drafts/draf t-lior-radius-prepaid-extensions-02.txt - very important to 3GPP/3GPP2/WISP, AAA infrastructure is a critical element - 3GPP2/IS-835C is using RADIUS - 3GPP is using Diameter - WLAN/WISP is using RADIUS - deployments are happening today - Requirements are service portability, seamless mobility charging accuracy, simultaneous pre-paid sessions, different pre-paid models - proposing an architecture for pre-paid which includes router-based HAs when you move between networks - uses quotas negotiated using (RFC 3576), including booting subscribers off - needs to support time-of-day based tarrifs - NAS needs to manage access quotas, and return any unused portion at session termination - singe quota must be managed over multiple simultaneous sessions - need to match up with Diameter CC - no new commands, no impact on AAA proxies, does require sub-types SHOULD BE DONE IN RADEXT, NOT DEPLOYED YET BUT SOON, IS BEING IMPLEMENTED, UNDER DISCUSSION in 3GPP2 DISCUSSION Richard Perlman (Lucent) - to David Nelson Q: different vendors have wildly different views on this. A: intent was to provide a framework, capabilities will be dependent on the NAS. Intention was to provide a wide area Joel Halprin to Avi Q: currently doing this, so want to make sure it does it right. Comment on the proposed. It is based upon a current business model & would like it that other models can be supported. Joel will provide input. A: it is possible to get feature creep. Want to build a framework which is extensible. Joel agrees. Phil Neumiller Q: - to Hannes - could the kick-start be done by PANA? A: hasn't read the RADIUS, but thinks that the work proposed seems like imprinting, like the ENROLL WG. Q: regarding UDP transport & RADIUS prepaid - how much code is required to upgrade servers? A: want to re-use existing infrastructure. Current own implementations could upgrade relatively easily. More memory is needed to NASes. Greg Webber Q: - regarding the transport - Vendors have already provided this functionality as product differentiation. Doesn't want to make mandatory function. If the draft proposed more functionality, that might make the work more interesting. A: can try to address this. Draft is meant as a best practices. Craig - worried that this becomes a tickmark. Craig - is their a draft for management work A: no, not yet. Farid Adrangi C: This work is important. Being looked at other SDOs. Important to do this at the David Harrington C: PANA infra looks like it has extra infrastructure, & doesn't look like it covers the area. SIP-RADIUS RADIUS Accounting & Authentication for SIP - Wolfgang Beck, 15 minutes http://www.watersprings.org/pub/id/draft -schulzrinne-sipping-radius-accounting-00.txt - today we have SIP proxies with own databases, servers with own databases, maybe PSTN gateways with own databases - have to understand vendor-specific RADIUS attributes - are new attributes required? - not many details from SIPPING requirements - some vendor-specific extensions accounting of media resources is not defined yet - reuses/overloads existing attributes - has SIP-specific attributes (SIP-Method, etc.) - open issues too many attributes in limited space need a general mechanism for proprietary SIP headers in accounting? MMUSIC also needs accounting for media resources - are there others? - work will be done in SIPPING if it's not done here http://www.watersprings.org/pub/id/draft -sterman-aaa-sip-00.txt - need HTTP digests in RADIUS - CHAP not sufficient, MD5/MD5-sess not sufficient - move response calculation from NAS to RADIUS server (like CHAP) - can reuse existing code - already running code - need user-specific settings (Idle-Timeout, etc) - using SIPPING profile notification instead? - AAA draft defines transparent User-Data - can't use pre-computed responses with pre-computed challenges! - open issues uses attribute numbers from experimental number space - need IANA section need better security considerations is deployed base already too large to change things? SHOULD BE DONE IN RADEXT, DEPLOYED, IS BEING IMPLEMENTED, EITHER HERE OR SIPPING DISCUSSION Allison Mankin C: - needs to be checked against requirements - SIPPING is really overloaded - could be done here [radext] with care - requirements need to be normative Henry Sennrich Q: can we combine wireless hot spot plus SIP? A: yes Jari Arkko Q: MD5 or other ones? need to apply to others, too John Q: these are old drafts that haven't been completed - how much change to RADIUS and SIP if we do the work? - neither draft could get an RFC number as-is - will current implementations be redone? - is this useful work? Dean Willis C: this is addition of an attribute plus calculation in the Sterman draft Bernard Aboba Q: are we doing standardization or ratification? Dean C: every operator is slightly different - need change control here Allison Mankin C: do security considerations and operational guidance - this is standard IETF work * LAN applications Wi-Fi Alliance - Serge Manning - Market Requirements Document (MRD) for WLAN Public Access in progress - finish December/March 2004 - includes usage guidelines - "Wi-Fi Protected Access (WPA)" - pre-Standard 802.11i security - need to simultaneously coexist with legacy systems (web browser hijack, etc). - need to define standard attributes for UAM (Universal Access Method) and WPA - network discovery not a solved problem, especially when multiple networks are present - pre-paid support with existing attributes - MRD uses WISPr defined VSAs, would like to migrate to standard attributes - Hot Spot locator, Operator identifier, user bandwidth - Wi-Fi Alliance not a standards body - it's an industry forum - need to get past proprietary reuse of existing attributes SHOULD BE DONE IN RADEXT, NOT DEPLOYED, NOT BEING IMPLEMENTED BUT CLOSE, IN 3GPP/3GPP2 AND OTHER GROUPS LAN Edge Device RADIUS Attributes - Paul Congdon, 10 minutes http://www.drizzle.com/~aboba/IEEE/draft -black-radius-lanedge-00.txt - vice-chair of IEEE 802.1 WG - many IEEE 802 device capabilities not represented by RFC 3580 attributes, e.g. VLAN attributes, CoS, Access Control, Bandwidth Attributes - looking for collaborators - contact chuck.black at hp.com - RFC 3580 also an annex in IEEE 802.1 standard SHOULD BE DONE IN RADEXT, PROPRIETARY SOLUTIONS DEPLOYED, IS BEING IMPLEMENTED, WISPr AND IEEE RADIUS context relocation issues - Bernard Aboba, 10 minutes http://www.ietf.org/internet-drafts/draf t-aboba-context-802-00.txt http://www.ietf.org/internet-drafts/draf t-ietf-eap-keying-01.txt - fast handoff applications allow movement without AAA server - can get incoherent or incorrect response - do fast handoff to same virtual IP and resets Session timer - unlimited network access - authorized-SSID, Fast-Handoff-Allowed? - types of attributes - location and operational ownership generic RADIUS application capabilities redirect attribute network bandwidth rate attributes DNS server address remote IP services attributes SHOULD BE DONE IN RADEXT, DEPLOYED, IS BEING IMPLEMENTED, EITHER HERE OR SIPPING WLAN Roaming - Farid Adrangi, 15 minutes http://www.ietf.org/internet-drafts/draf t-adrangi-radius-issues-in-pwlan-roaming-01.txt http://www.ietf.org/internet-drafts/draf t-adrangi-radius-att ributes-extension-for-pwlan-00.txt http://www.weca.net/OpenSection/downloads/WISPr_V1.0.pdf - if we don't have common understanding and standardization of new attributes, we'll fragment and lose interoperabity - draft is currently under revision - need common usage model - what's required for public WLAN roaming? DISCUSSION Frank Webber Q: why would WISPr or Wi-Fi Alliance own vendor IDs? - not a vendor, so attributes not vendor-specific A: just doing a semi-standard/semi-private solution - same with IEEE 802.11 and other SDOs Rajeev Q: use handover work developed elsewhere? - MIPSHOP, SEAMOBY for transfers, etc. clarify "fast handover" A: vulnerability is general when you don't go to AAA server Itojun Q: attribute currently maintained by SNMP - why RADIUS now? A: fits into the framework - can't synchronize configuration with authorization Ed Bandhort Q: location attribute - need grammar for context that machines can process A: we're looking at the grammar Pete McCann C: Fast Handoffs between APs on the same subnet Dave Nelson C: new attribute requests can often be reused attributes * RADIUS & PPVPNs RADIUS & L2TP Extended NAS-Port AVPs - G. Weber, 5 minutes http://www.ietf.org/internet-drafts/draf t-nmcgill-l2tp-radius-ext-nas-port-01.txt - NAS-Port in RADIUS was a sequential number - NAS-Port becoming a hierarchical number - inherited by DIAMETER, overloaded, encoded with bit-fields, vendor specific - want to normalize encoding so NAS-Port is more valuable for backend servers - adds a new L2TP attribute and a new RADIUS attribute - string type SHOULD BE DONE IN RADEXT, NOT DEPLOYED, NOT IMPLEMENTED, EITHER HERE OR L2TP RADIUS in PPVPN - Greg Weber, 10 minutes http://www.ietf.org/internet-drafts/draf t-heinanen-radius-pe-discovery-04.txt - using RADIUS for VPN discovery, presented in PPVPN - open issues authentication method interim accounts reuse of 2868bis RADIUS attributes hub-and-spoke VPLS lists coordinated with L2TP/VPLS draft scalability and security considerations need to be be beefed up SHOULD BE DONE IN RADEXT, NOT DEPLOYED, NOT IMPLEMENTED, EITHER HERE OR L2VPN (NO Discussion) Wrap-up - 20 minutes - Bernard and Dave - lots of restrictions! - charter includes quality plan Avi C: use of subtypes - some drafts don't call them subtypes, they call them strings - now I have to parse these strings in realtime - suggest we allow subtypes Henry Semmich Q: backward-compatible with existing protocol? Jari Arkko Q: we should have a WG with a different name? - we're really doing AAAEXT for LAN Access Richard Perlman Q: proposals might conflict with limitations re-charter later? Randy Bush Q: why subtypes? Richard Perlman A: prefer new attributes, may have space limitations Bernard Aboba C: less than 30-40 attributes have been proposed Randy Bush, speaking as AD C: IETF is about interoperability - scoping the boundaries is important - within these boundaries it's still tough to produce high-quality documents to meet these needs - current documents aren't shining examples Greg Weber Q: any conflicts with IANA RADIUS RFC? Bernard Abona A: probably infinite numbers of conflicts... three new commands? - are they required? Dave Mitton C: whole chapter in DIAMETER on how to deal with RADIUS Spencer Dawkins Q: is non-UDP restriction the DIAMETER upgrade carrot? Randy Bush A: yes John Loughney C: congestion control mechanisms in TSV apply to both TCP and SCTP - one draft is plenty - don't allow RADIUS feature creep - just upgrade to DIAMETER Avi Lior C: operators choose RADIUS or DIAMETER, we don't mandate this Henry S. C: agree as service provider - not a political consideration ??? - AAA architecture is around DIAMETER - need to allow this in RADIUS Phil N. C: we do lots of billing. - RADIUS sucks and won't scale. - this is not good. - RADIUS scaling has been solved in DIAMETER - don't keep patching - WLAN hotspots will break RADIUS - don't build transport in UDP Joe Salowey C: it is AAAEXT, but we need to be clear on what applies to DIAMETER and what to applies to RADIUS Randy Bush C: we already have DIAMETER, don't recreate it in RADIUS - too boring for next five years - if you abstract new applications, what applies to RADIUS, should play with DIAMETER * Call for Interest Q: Should we form a RADEXT extension group? A: sense of the room is yes Q: Who is willing to do significant amounts of work? A: about 8 10 hands shown |