2.4.16 RADIUS EXTensions (radext) Bof

Current Meeting Report

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

Slides

Agenda
RADIUS UDP Transport Mapping
RADIUSEXT MIBs
RADIUS Extended Attributes for Management Authorization
RADIUS Client Kickstart
RADIUS extensions for Prepaid
RADIUS & SIP
Wi-Fi Alliance Issues in WLAN Roaming
LAN Edge Radius Attributes
RADIUS Context Relocation Issues
RADIUS Attribute Harmonization and Informational guidelines for PWLAN
RADIUS & L2TP Extended NAS-Port AVPs
Using RADIUS for PE-Based VPN Discovery