2.4.12 RADIUS EXTensions (radext)

NOTE: This charter is a snapshot of the 64th IETF Meeting in Vancouver, British Columbia Canada. It may now be out-of-date.
In addition to this official charter maintained by the IETF Secretariat, there is additional information about this working group on the Web at:

       Additional RADEXT Web Page

Last Modified: 2005-10-03

Chair(s):

David Nelson <dnelson@enterasys.com>
Bernard Aboba <aboba@internaut.com>

Operations and Management Area Director(s):

Bert Wijnen <bwijnen@lucent.com>
David Kessens <david.kessens@nokia.com>

Operations and Management Area Advisor:

David Kessens <david.kessens@nokia.com>

Technical Advisor(s):

Paul Congdon <paul.congdon@hp.com>

Mailing Lists:

General Discussion: radiusext@ops.ietf.org
To Subscribe: radiusext-request@ops.ietf.org
In Body: In Body: subscribe
Archive: https://ops.ietf.org/lists/radiusext

Description of Working Group:

The RADIUS Extensions Working Group will focus on extensions to the
RADIUS protocol required to enable its use in applications such as IP
telephony and Local Area Network authentication, authorization and
accounting.

The IETF has recently completed work on the Diameter Base protocol. In
order to support the deployment of Diameter, and enable interoperation
of heterogeneous RADIUS/Diameter deployments, all RADEXT WG work items
MUST contain a Diameter compatibility section, outlining how
interoperability with Diameter will be maintained.

Furthermore, to ensure backward compatibility with existing RADIUS
implementations, as well as compatibility between RADIUS and Diameter,
the following restrictions are imposed on extensions considered by the
RADEXT WG:

- All RADIUS work MUST be backward compatible with existing RADIUS
RFCs,
including RFCs 2618-2621, 2865-2869, 3162, 3575, 3576, 3579, and 3580.
- All RADIUS work MUST be compatible with equivalent facilities in
Diameter. Where possible, new attributes should be defined so that
the same attribute can be used in both RADIUS and Diameter without
translation. In other cases a translation considerations
section should be included in the specification.
- No new RADIUS transports (e.g. TCP, SCTP) will be defined.
- No new security mechanisms will be defined for protecting RADIUS.
- No new commands will be defined.

Work Items

The immediate goals of the RADEXT working group are to address the
following issues:

- RADIUS design guidelines. This document will provide guidelines for
design of RADIUS attributes. It will specifically consider how
complex data types may be introduced in a robust manner, maintaining
backwards compatibility with existing RADIUS RFCs, across all the
classes of attributes: Standard, Vendor-Specific and SDO-Specific.
In addition, it will review RADIUS data types and associated
backwards compatibility issues.

- RADIUS implementation issues and fixes. This document will address
common RADIUS implementation issues and describe proposed solutions.

- Revised NAI specification. This document, known as "RFC 2486bis"
will revise the NAI specification to correct known errors,
add support for privacy and internationalization, and provide
more details on routing.

- Pre-paid support. Prepaid services are contemplated in a number
of potential applications, including wireless LAN access and IP
telephony. In order to enable support of pre-paid services in
an interoperable way, the WG will provide definitions of the
attributes required to support operator service models for
pre-paid, as documented in liaison communications. This
document will include within it a specification for interoperation
with Diameter Credit Control.

- SIP support. RADIUS is currently used for SIP authentication,
authorization and accounting. Standardization of these attributes
will enable improved interoperability.

This document will be upwards compatible with the Diameter SIP
application, and conform to existing IETF RFCs on HTTP Digest,
including RFC 2617, 3261, and 3310.

- LAN attributes. New attributes have been proposed to enable use of
authentication, authorization and accounting in wired and
wireless LANs. Standardization of these attributes will enable
improved interoperability.

- RADIUS MIB update. RFC 2618-2621 lack IPv6 compatibility, and modest
changes are required to address this issue. MIBs for RFC 3576 are
also needed.

Goals and Milestones:

Dec 2004  Updates to RFC 2618-2621 RADIUS MIBs submitted for publication
Dec 2004  RADIUS design guidelines submitted as an Informational RFC
Dec 2004  SIP RADIUS authentication draft submitted as a Proposed Standard RFC
Jan 2005  LAN attributes draft submitted as a Proposed Standard RFC
Feb 2005  RADIUS implementation issues and fixes submitted as an Informational RFC
Feb 2005  WLAN attributes draft submitted as a Proposed Standard RFC
Done  RFC 2486bis submitted as a Proposed Standard RFC
Dec 2005  RADIUS Prepaid draft submitted as a Proposed Standard RFC
Dec 2005  RFC 3576 MIBs submitted as an Informational RFC

Internet-Drafts:

  • draft-ietf-radext-rfc2486bis-06.txt
  • draft-ietf-radext-digest-auth-06.txt
  • draft-ietf-radext-chargeable-user-id-06.txt
  • draft-ietf-radext-dynauth-server-mib-02.txt
  • draft-ietf-radext-dynauth-client-mib-02.txt
  • draft-ietf-radext-ieee802-00.txt
  • draft-ietf-radext-rfc2618bis-01.txt
  • draft-ietf-radext-rfc2619bis-01.txt
  • draft-ietf-radext-rfc2621bis-01.txt
  • draft-ietf-radext-rfc2620bis-01.txt

    No Request For Comments

    Current Meeting Report

    IETF-64 RADEXT WG Agenda
    Tuesday, November 8, 2005
    0900-1130 Salon F
    
    ADMINISTRATIVE
    --------------
    
    Chairs: Bernard Aboba 
    David Nelson 
    
    Scribes: Pasi Eronen and Jari Arkko
    Jabber scribe: John Loughney
    
    Open Issue Summary:
      http://www.drizzle.com/~aboba/RADEXT/
    Presentations and agenda online at:
      http://www.drizzle.com/~aboba/IETF64/radext/
    
    Dave Mitton: Do you have enough bandwidth on your server?
    Bernard Aboba: Yes. 
    
    1. Preliminaries
       - Bluesheets
       - Agenda Bash
    
    2. Document Status
       - 2486bis, CUI are in RFC editor queue
       - IETFLC completed on radius digest authentication
       - Completed WGLC, awaiting issue resolution: VLAN/Priority.
       - In WGLC: RADIUS IPv6 MIBs, RFC 3576 MIBs
       - Pre-work item review: issues & fixes, design guidelines
    
       Discussion on the need for at least four people to review documents
       (in addition to authors). David reminds that a lack of comments
       means the document needs extra careful review from the AD, and it's
       difficult to determine whether the document is useful for anyone
       (if nobody bothers to read the document in the WG, why should the
       AD spend time on it?). Hannes to suggest that WGLCs not be arranged
       at the same time as IETF meetings.
    
    WORK ITEMS IN IETF Last Call (30 minutes)
    -----------------------------------------
    
    3. Digest Authentication, Wolfgang Beck (10 minutes)
    
    http://www.ietf.org/internet-drafts/draft-ietf-radext-digest-auth-06.txt
    
      There has been a discussion of the security of the RADIUS transaction
      from SIP to AAA. Parts of the SIP messages are revealed over
      RADIUS as-is. Should there be a mandate to use encryption if the user
      uses TLS or SIPS?
    
      Glen Zorn worries that MPLS is listed along with security methods in
      the slide. But Wolfgang put it there just because someone had
      mentioned it.
    
      Hannes Tschofenig is not convinced that this usage of RADIUS is any
      different than others. Should be enough with the use of local methods
      or IPsec VPNs, etc. This is what Wolfgang's resolution suggests, and
      failing if this can not be done.  Miguel Garcia worries that the RADIUS
      server does not know whether it is running IPsec or not. The SIPS URI
      implies that all communications should be protected hop-by-hop at
      least by TLS or equivalent. There's no mechanism to tell the SIP user
      that we can not provide the requested security. 
    
      Bernard: is there an objection to the resolution? 
      Miguel: No.
    
      Discussion on the AAA WG mailing list is also affecting this draft.
      For instance, is Digest-Username attribute redundant? The proposal for
      this issue is that the draft will not be changed.
    
    4. Diameter SIP Application, Miguel Garcia (10 minutes)
    
    http://www.ietf.org/internet-drafts/draft-ietf-aaa-diameter-sip-app-10.txt
    
      We are discussing this draft here due to the lack of a AAA WG
      meeting. Status of the draft is that it has passed three WGLCs.
    
      New issues were brought up after WGLC. There's an issue with CX and
      Diameter SIP application alignment. There are some incompatibilities
      that are being looked at.
    
      Issue 49 - required authentication parameters. There are possible
      optimizations, raised by the 3GPP folks. Proposal is to make
      Digest-Nonce AVP optional in SIP-Authenticate AVP, make Digest-URI
      and Digest-Response AVP optional in the SIP-authorization AVP, make
      Digest-Nextnonce AVP optional in the SIP-Authentication-Info AVP.
    
      Issue 50 - User-DATA AVP in Push-Profile-Request (PPR) command.
      This is also about alignment with CX. Proposal is to make User-Data
      AVP optional because it is possible that only the accounting
      information but not user data changes. Glen Zorn asks why this
      command is used just for accounting information. Miguel says that
      this command can also be used to update the URIs related to
      accounting. These URIs are not a part of the profile data object
      due to historical resons.
    
      Issue 51 - Result-Code AVP. The worry is that formats are not open
      to extension because all commands mandate Auth-Application-ID
      AVP. But this is what standard Diameter applications should do.
      Proposal is to do nothing.
    
      Issue 53 - MAR processing. Miguel needs to take a deeper look at
      this. The issue relates to the Authentication flag in the MAA/MAR
      commands. It looks like the flag must be cleared when processing the
      SAR/SAA commands instead, not in MAA/MAR.
    
      Issue 54 - Syntax issues in the Auth-Application-ID. Seems like an
      editorial error.
    
      John Loughney, co-chair of AAA, says that the ADs are worried about
      late comments after WGLC. But the draft will go to IETF LC, and the
      open issues are taken as IETF LC issues.
    
      Glen Zorn: I am still confused. I thought that IETF LC comments go
      to the IETF discussion list, not to some database in control of the
      chairs. John Loughney: What is being suggested is that if there are
      issues, submit them to the ietf or aaa mailing lists or both. The
      WG will consider whether it will be fixed or not. Glen Zorn: OK.
      Bert Wijnen (AD): after three WGLCs, people should not come up
      with more issues.
    
    
    WORK ITEMS COMPLETING WG LAST CALL (30 minutes)
    -----------------------------------------------
    
    
    5. Dynamic Authorization MIBs, Greg Weber (10 minutes)
    
    http://www.ietf.org/internet-drafts/draft-ietf-radext-dynauth-server-mib-02.txt
    http://www.ietf.org/internet-drafts/draft-ietf-radext-dynauth-client-mib-02.txt
    
      These are in WGLC, to end on Nov 14th.
    
      Issues 92, 96, 97, 105 resolved in -02. New issue 137 received.
    
      Someone asks about the security considerations of counters: although
      the information is going only to the SNMP manager, the security
      considerations section might mention that some people would consider
      this information sensitive.
    
      Bernard: Are these MIBs being implemented? Greg: At least one vendor
      is implementing them.
    
    
    6. RADIUS IPv6 MIBs, Dave Nelson (5 minutes)
    
    http://www.ietf.org/internet-drafts/draft-ietf-radext-rfc2618bis-01.txt
    http://www.ietf.org/internet-drafts/draft-ietf-radext-rfc2619bis-01.txt
    http://www.ietf.org/internet-drafts/draft-ietf-radext-rfc2620bis-01.txt
    http://www.ietf.org/internet-drafts/draft-ietf-radext-rfc2621bis-01.txt
    
      Bernard Aboba presents this on Dave's behalf. There has been a MIB
      Doctor review. New revision has been produced based on this. No
      comments received to date -- please review and comment as
      soon as possible. Drafts are in WGLC.
    
      Changes in -01 are very similar for all four drafts. All known
      issues have been addressed. Based on issue 135, new RFCs must
      obsolete the base RFCs.
    
    7. VLAN/Priority, Paul Congdon (15 minutes)
    
      http://www.ietf.org/internet-drafts/draft-ietf-radext-ieee802-00.txt
    
      Paul indicates that one should never change ones domain password one
      hour before taking a trip, or if one does, it would be useful to
      write the password down.
    
      There is no new draft, too many unresolved issues. A few issues are
      closed and there's progress on others; discussion is still required
      on many.
    
      Issue 110 - compliance and coherence. Hard to define conformance
      when the draft defines attributes for many different types of
      devices. Should we split the draft?
    
      Dave Nelson: It may be more convenient to split the document and 
      claim conformance per document, but this would create more documents.
    
      Dave Nelson: IP redirect will break things. 
      Bernard: IP redirect is no longer in the document, only HTTP.
    
      Issue 102 - Pasi's issue with many subissues. Relates to parsing
      Tunnel-Assignment-ID and issues in NAS-Filter-Rule definition.
      Escape characters may be needed.
    
      Issue 113 - Confusion on how to concatenate multiple filter
      attributes. Issues with Diameter filter rule syntax usage.  Three
      potential ways to go forward (see slides), including dropping the
      functionality. Hannes: I was wondering how this relates to the other
      documents, such as the bandwidth document. 
    
      Bernard: This is mainly priority marking, but there is overlap 
      with the metering part and the bandwidth draft. 
    
      Jari: sounds like there are technical issues and lack of requirements and 
      no implementations. Sounds like we should drop it. 
      John: Or alternatively break it out and put it in the
      qos document. 
      Paul: I'm ok with dropping it, it allows the uncontroversial
      parts to proceed faster.
    
      Issue 130 - Diameter compatibility. Major discussion on whether to
      retain Diameter compatibility or not. Jari Arkko believes that this
      is very much necessary, and Glen Zorn believes it should be
      ignored. David Mitton comments that if we need new functionality, we
      need to develop that. Jari points out that new functionality and
      superset of the Diameter format is fine. Just that we'd like to
      see one format going forward, rather than several.
    
      We will bring this issue to the list. 
    
      Other issues -- see slides.
    
    PRE-WORK ITEM REVIEW (30 minutes)
    ---------------------------------
    
    8. Common Radius Implementation Issues and Suggested Fixes, Bernard
    Aboba  (10 minutes)
    
      http://www.ietf.org/internet-drafts/draft-aboba-radext-fixes-01.txt
    
      (No discussion)
    
    
    9. Design Guidelines, Greg Weber (10 minutes)
    
    http://www.ietf.org/internet-drafts/draft-weber-radius-attr-guidelines-01.txt
    
      Question about the possibility to allocate vendor-specific
      values in standard attributes. This would require a RFC 3575
      (RADIUS IANA policy) revision.
    
      Fragmentation of data. Is there a simpler method than attribute
      flagging?
    
      Other issues - look at the slides.
    
      Is this a reasonable starting point for a working group item?
      Volunteers for this work? How many people have even read it? 
      (six hands)
    
      John: Channeling Jabber - 2-4 people have spoken in favor of
      this draft.
    
      David Kessens (AD): Need to be strict here. Milestones are
      slipping. More discussion is needed before adding new work.
      General topic, not related to this draft.
    
    10. RADIUS/Diameter VSA Translation, David Mitton (10 minutes)
    
    http://www.ietf.org/internet-drafts/draft-mitton-diameter-radius-vsas-00.txt
    
      Generally Diameter is upwards compatible with RADIUS. There are
      exceptions, however, such as RADIUS Vendor-Specific attributes.
    
      Draft analyses the problem with the VSAs, and suggests a method
      to overcome the problems. Problems include long attributes.
    
      Glen: I cannot send down a 25K blob via RADIUS. Can you really
      maintain any kind of actual data integrity over the transformation
      without constraining Diameter, which would be a bad thing.
      Diameter server can be told that the message to which it responds
      is coming through RADIUS. To respond correctly, however, it
      would need two sets of attributes. 
      Someone: Is this a real case?
      Glen: I know people who would send attributes of 20-40K. But
      this approach would still work for some upper limit.
    
      Paul Congdon: Length is just one issue. This is a slippery slope,
      e.g. not sure if we have any way of doing mandatory bits.
    
      David Nelson: Sees a RADIUS->Diameter requirement but
      not necessarily a Diameter->RADIUS requirement.
    
      John Loughney: AAA WG shutting down, but a Diameter maintenance
      WG might be started up.
    
      Shof Lee (?): Can a vendor hop on Diameter immediately or should it
      use RADIUS or RADIUS with extensions. 
      Bernard: We recommend that the vendors attempt to satisfy the needs 
      of their customers. 
      David Mitton: I'm here not to extend RADIUS, but to move people to
      Diameter.
    
      Glen Zorn: There's an actual way to do this. 
      Bernard: Bring this to the list. Let's not try to solve it here. 
      Glen will send text.
    
    
    WORK ITEMS IN OTHER WGs (40 minutes)
    ------------------------------------
    
    11. RADIUS Support for Delegation, Ralph Droms (5 minutes)
    
    http://www.ietf.org/internet-drafts/draft-salowey-radext-delegated-prefix-01.txt
    http://www.ietf.org/rfc/rfc3633.txt
    http://www.ietf.org/rfc/rfc3162.txt
    
      Scenario is assignment of IPv6 prefixes from ISP devices
      to CPE. Assignment of prefix to a customer is left to the
      implementation. One solution is to associate a prefix 
      with the user via RADIUS.  RFC 3162 defines the
      Framed-IPv6-Prefix attribute, and RFC 3633 suggests that
      this attribute be used for prefix delegation. 
    
      However, what happens if the ISP wants to assign one 
      prefix to the CPE, and another prefix for prefix-delegation?
      The same Framed-IPv6-Prefix attribute can't be used for
      both purposes; this is overloading.  The draft suggests
      a new attribute be sent from the AAA server to the NAS
      for delegation. 
    
      Bernard:  Is this new document redefining the 
      Framed-IPv6-Prefix attribute?  The original intent was
      that this attribute would include prefixes to be announced
      via RS/RA? Is that still the behavior that is desired?
      What behavior is implied if a prefix larger than /64 is
      assigned?  Does anything more granular than a /64 make sense?
    
      One approach would be to update RFC 3162, with the
      new attribute as well as explaining what the other
      existing attributes actually mean.
    
      We will get a draft together as this is urgent. ("We"
      means the draft authors as well as RFC 3162 authors.)
      Pasi and Hannes suggest that if delegation is urgent, it
      might be easier to go individual instead of working group item,
      especially since the draft is simple and doesn't need extensive
      review.
    
    12. ISMS Requirements, David Harrington (5 minutes)
    
      The following mechanisms are popular for securing CLI according 
      to a NANOG survey:
      66% local accounts 
      49% SSH 
      40% RADIUS 
      29% TACACS+
    
      SNMPv3 requires authentication. USM is an SNMPv3 security
      model that employs local account authentication, and ISMS
      is in the process of using SSH to do this.
    
      No current AAA attributes are suitable for use with SNMP access
      control. Draft-nelson-radius-management-authorization is very much in
      line with the needs of the network management comunity. We'd like to
      see this work not just for SNMPv3, but also CLI.
    
      There's a need to have the AAA map an authenticated user to a named
      policy. The mapping of policy names to policy implementation should
      be left to the management protocols. ISMS would like RADIUS experts
      to do the AAA parts, but the secure shell model is not sufficiently
      mature yet to have exact AAA requirements.
    
      Hannes Tschofenig would like to see a more complicated approach
      to authorization than the delivery of a policy name.
    
      Discussion moved to the list due to lack of time.
    
    13. Management Authorization, Greg Weber (5 minutes)
    
    http://www.ietf.org/internet-drafts/draft-nelson-radius-management-authorization-02.txt
    
      Adds new value to Service-Type (Framed-Management). Provides new
      attributes to indicate the type of protocol (e.g. SNMPv3, HTTP,
      SSH), management policy ID, etc.
    
      How to progress? Is there a need for a formal request from ISMS?
      ISMS and RADEXT will figure it out. One way is for the ISMS to say
      we want this particular draft.
    
    14. RADIUS/MIPv4 Extensions, Madjid Nakhjiri (5 minutes)
    
      http://www.watersprings.org/pub/id/draft-nakhjiri-radius-mip4-02.txt
    
      Adds RADIUS support for Mobile IPv4. Becoming a MIP4 WG work
      item. Possibly comes for review also in RADEXT later.
    
      Diameter spec for Mobile IP already defined in RFC 4004.
      Draft defines attributes and procedures for RADIUS,
      and includes Diameter translation.
    
      For RADEXT, issues include status of the key wrap status
      and guidance on Diameter-RADIUS translation.
    
    15. RADIUS/GEOPRIV, Hannes Tschofenig (5 minutes)
    
    http://www.ietf.org/internet-drafts/draft-ietf-geopriv-radius-lo-04.txt
    
      Capability exchange was the main sticking point. Now people have
      come to a conclusion how this can be handled. Emile Van Bergen
      has prepared slides describing the solution. 
    
      Discussion appears to have converged on the Supported-Location approach. 
      The remaining issue is how to deal with the Challenge problem. 
      Jari, Bernard:  this part may need some more thinking/review. 
      Allison: so we are past the impasse that we had on the capability part. 
      Bernard: Yes.
      Post challenge issue to the list and discuss.
    
      Glen: I would like to work on the general capability problem.
      Hannes: Not sure we want to wait for another document.  
      Dave Nelson via Jabber: Does not understand the trust model. 
      RADIUS security is hop-by-hop. Why does GEOPRIV need to be told 
      by the RADIUS server when it can send the location information? 
      Hannes: Because the AAA user or the end user wants to control 
      how the location data is revealed.  Dave
      Nelson: But proxy servers can lie. 
      Hannes: True. But this is the assumption is in the document, the 
      AAA infrastructure needs to be trusted.
    
      Last comment from Dave: We can't change the way RADIUS works.
      But is the way that it works suitable for GEOPRIV? Discussion
      to be taken to the list.
    
    16. RADIUS Capabilities Problem Statement, Alan DeKok (10 minutes)
    
      Goal is to esbtalish a framework, terminology for capabilities.
      Rigorous approach. Mathematical approach makes it possible to be
      exact. Need to establish WG opinion on the assumptions and approach.
    
      Hannes Tschofenig is not sure if a simple problem needs to be
      turned into a complex one. Discussion about whether mathematical
      notation helps.
    
    
    Next Steps, ADs & WG Chair (10 minutes)
    ---------------------------------------
    
    David Kessens, AD, is concerned that we are not meeting charter
    milestones. How can we take on more work? Particularly concerned
    about progress on the RADIUS design guidelines document.  This
    document is fundamental, because it provides help for others
    doing RADIUS work, and would guide the future of RADIUS.  This
    would be a step forward. 
    
    Hannes Tschofenig: Do you think the issue is bad initial milestone
    deadlines, or something else.
    
    Bernard thinks that much of the problem is due to the failure
    to progress on the design guidelines.
    
    Bert Wijnen says that existing deadlines are kept while new
    work is being taken on board. Would be good to adjust deadlines.
    
    Glen Zorn thinks that the charter and milestones were articifially
    constrained and not a result of a consensus process. The charter
    would look different if this had been the result of a consensus
    and not a result of management action.
    
    Hannes questions why prepaid is being delayed. Bernard responds
    that during chartering, it was agreed that design guidelines
    needs to be done first, since prepaid depends on things like
    compound attributes. 
    
    Paul: Where have these dates on the slide come from? 
    Bernard: These are the original deadlines from chartering/re-chartering.
    
    David Kessens: Wants to see a realistic plan to produce design
    guidelines. If we can see this, no need to put roadblocks on
    other documents.
    
    

    Slides

    Agenda
    draft-ietf-radext-digest-auth-06
    Diameter SIP application
    RADEXT Dynauth MIBs
    RADIUS MIB Update for IPv6
    draft-ietf-radext-ieee802-00
    RADIUS Implementation Issues & Fixes
    RADIUS Attribute Guidelines
    Diameter NASreq (RFC 4005) and RADIUS Compatibility
    RADIUS Delegated-IPv6-Prefix Attribute
    RADIUS Attributes for Network Management Authorization
    Management Attributes
    RADIUS Mobile IPv4 extensions V.02
    Carrying Location Objects in RADIUS
    RADIUS Capabilities