Minutes of the RADEXT session at IETF62

["Nelson, David" <dnelson@enterasys.com>]

Please review these minutes and reply to the list with any errors or omissions.


Minutes of the RADEXT WG session at IETF62
Wednesday, March 9, 2005 1530 - 1730
Hilton Minneapolis
Rochester Room

Notes taken by Paul Condgon and John Vollbrecht and edited by Dave Nelson.
 
Agenda: http://www.drizzle.com/~aboba/IETF62/radext/ietf62_radext-agenda.ppt
Slides: http://www.drizzle.com/~aboba/IETF62/radext/
Issues Tracker: http://www.drizzle.com/~aboba/RADEXT
 

1. Agenda Bashing: The published agenda was set for 2.5 hours but we were switched into a 2.0 hour session slot. Agenda will be reshuffled to fit in 2 hours because few wanted to cut short the dinner hour.  Will start the capabilities discovery discussion at a fixed time.

2. Document status was covered 
  
3. Milestones need to be updated on web site.  Proposed revision is:

- Done    RFC 2486bis submitted as a Proposed Standard RFC
- May 05  RADIUS digest auth draft submitted as a Proposed Standard RFC
- Jun 05  Updates to RFC 2618-2621 RADIUS MIBs submitted for publication
- Jul 05  RADIUS CUI draft submitted as a Proposed Standard RFC
- Dec 05  RFC 3576 MIBs submitted as an Informational RFC
- Dec 05  RADIUS design guidelines submitted as an Informational RFC
- Jul 06 (W)LAN attributes draft submitted as a Proposed Standard RFC
- Sep 06  RADIUS issues and fixes draft submitted as an Informational RFC
- Dec 06  RADIUS Prepaid draft submitted as a Proposed Standard RFC
 
4. Jari Arkko on 2486bis status - updated NAI.
draft-ietf-radext-rfc2486bis-05.txt

-- Document has been sent to IESG and has a single issue.  Some minor modifications a have been made.

-- Extended to use international characters, but UTF-8 is a problem.  Needs to be made clear in the ABNF.
 
-- Issue 18n includes a question about unassigned code points. Should they be prohibited or allowed?  Approach is to prohibit them from a specification perspective. 

-- Related issue with ! syntax.   Unclear what to do and we need the help of internationalization gurus.  Username part may have different rules from IDN part of the NAI.

-- Chairs will solicit consultation from an expert in internationalization issues.

-- Conversation to be moved to list.

5. Wolfgang Beck on auth digest draft
draft-ietf-radext-digest-auth-01.txt
 
-- There are several security design alternatives; encryption per RFC2868, wait for draft-zorn-radius-encattr or mandate IPSec if RADIUS client supports TLS.  Concern about the draft-zorn... being "late" (now an individual submission).  Wolfgang believes the IPSec solution is the only viable option.
 
-- Concern about encrypted RADIUS attributes not providing the same level of protection as TLS (or IPSec). It was pointed out that most operators already protect their RADIUS traffic, but there is some debate about this.
 
-- Other misc. changes in the works regarding alignment with diameter-sip-app, digest-Qop, multiple authorization, and document re-arranging. 

-- There is a comment that the parameters being included in the SIP-AOR are not properly discussed in the draft.

6. Avi Lior on the CUI draft
draft-ietf-radext-chargeable-user-id-03.txt
 
-- All issues in the tracker have been addressed to date.  One issues raised recently, but not in the tracker yet.  Resolution has been agreed on the list. Requesting that the document move to WG last call.

7. Dave Nelson on the base MIBs Revision
draft-nelson-rfc2618bis-00.txt
draft-nelson-rfc2619bis-00.txt
draft-nelson-rfc2620bis-00.txt
draft-nelson-rfc2621bis-00.txt
 
-- Asked to update the current set of four MIBs.  There are now four drafts that update, but not obsolete the existing RFCs.
 
-- Added support for IPv4/IPv6 textual conventions.  Using the SMI AUGMENTS syntax to perform the update and non-obsolesce of the existing objects. 

-- To advance these, there will need to be updates to the boilerplates. 

-- Has been some informal MIB Doctor review and will be requesting formal review and recommend they become WG documents.
 
-- Dan Romascanu doesn't believe that the boilerplate needs to be updated.  Dave Harrington is the one who made this assertion, in his slides at IETF60/58.  This is only related to the Standards Track MIBs.  The AD wasn't clear what the procedure is.
 
-- Glen Zorn would like to see the current Standard Track MIBs move to Draft Standard status.  We need to understand what all is implied by taking this action.

8. Greg Webber on the RFC3576 MIBs 
draft-decnodder-radext-dynauth-client-mib-03.txt
draft-decnodder-radext-dynauth-server-mib-03.txt

-- This adds support for the new extensions in 3675.  Addresses IPv6/IPv6 textual conventions.
 
-- Four issues are noted: 31, 44, 45, 48.  Various changes to support the resolution of these issues. 

-- Proposed to make these a WG item.  The WG seems to agree.  Validate on the list.

9. Mauricio Sanchez on the IEEE 802 Attributes
draft-congdon-radext-ieee802-03.txt
 
 -- Avi Lior and Farid Adrangi have contributed to this as well and should be noted as authors.
 
-- Because of overlap, the draft-lior-redirection draft has been merged in and some changes to the format were made.  The redirection draft was dropped. 
 
-- NAS-Filter-Rule supports L2 filters now and supports a flush action.

-- 802.11i Key attributes were removed to avoid NIST issues. It was noted that all 802.11 attributes were pulled and they shouldn't have been. 

-- The dropping of the Key attributes is a concern by Glen Zorn.  Since NIST has a bad track record of responding in a predictable timeframe, we don't want to create a dependency. 

-- Key attributes were copied for Key space so the code points already exist, so therefore some of these already exist. 

-- Several issues have been addressed: 37, 38, 39. 

-- Will bring back non-key related attributes for 802.11.

-- The TNC of the TCG is interested in these attributes, so is 3GPP.  John Vollbrecht will present on the TCG/TNC in the EAP WG tomorrow.

-- Next steps involve incorporating the capabilities discovery direction of the group, more formatting of NAS-Filter-Rule and its syntax, improve document flow, considering a title change. 

-- Other SDOs depend on this, so rapid progress is necessary. 

-- Question about the extended attribute usage being removed. Glen Zorn is happy about this.
 
-- Question about accounting records used on redirect.  There is a stop and start used, but could there be a single record?  Avi Lior believes it is possible to do this and an Interim should be used.

10. Dave Nelson on Management Authorization Attributes
draft-nelson-radius-management-authorization-01.txt 
 
-- Currently two attributes for management; CLI, privileged and non-privileged.  The draft would like to extend this for SNMP and HTTP management.  Would like the extend the privilege levels, support SSH, create a label for policy scope, leverage split horizon views of management, and do this on a per-command basis (parity with TACACS+)... a lot of improvements.
 
-- The design is to add a Framed-Management service type and a Management-Access-ID (label), Management-Protocol, Non-Framed-Management-Command and operation, Management-Context for logging and human consumption. 

-- Today Enterasys uses VSA and believe that there is value in multi-vendor environment so would like to open them up.  Would like to ask that this become a WG item.  Poll of the room indicated about six to eight interested parties.  Will validate on the list.
 
-- Glen Zorn questions the wisdom of using RADIUS accounting for an audit log of command line changes because of the size of Radius logs - perhaps syslog would be better.
 
-- Unclear how this works with SNMP.   The idea is it would leverage the ISMS WG work.  The ISMS group should certainly review this and an action was taken to put them in the loop.
 
-- The ISMS scope, however, does not cover management access control. 

-- Dave Perkins asks if some of the other functionality is to provide parity with TACACS+.  Yes, some of this is going to address that, but there is also the goal of addressing other management interfaces other than CLI.  Dave Perkins points out that it is hard to do command-by-command authorization because you need to understand the level within the CLI you are operating at.  Greg Weber indicated that the Management-Context attribute is defined to address this.

11. Avi Lior on Prepaid Extensions
draft-lior-radius-prepaid-extensions-07.txt 
 
-- Now at draft 7.  During IETF60 they were at draft 5.  A number of changes identified in the slides. 

-- Interesting complexities defined to transfer prepaid credit from the NAS to the device.

-- The goal is to be similar to Diameter Credit Control, but integration will be hard to do.  There are differences between Quotas in the two schemes; one is a delta the other is absolute.  More thought needed here. 

-- Is the draft dependent on RFC3576?  No, according to Avi Lior, but some disagreement on this.  Any dependency can be taken out, but it would be good to have it in.

12. Avi Lior on Bandwidth Parameters
draft-lior-bandwidth-capability-00.txt 
 
-- Draft has been thrashing about.  The current draft strives towards simplicity with a simple set of attribute with reasonable tightness. 

-- There are ingress and egress bandwidth attributes, and a Bandwidth-ID for labels (similar to Filter-ID).  Can use either of these, but not both at the same time. 

-- There is a capability to advertise, select and confirm bandwidth usage. Ability to update these dynamically as well.  Mutual agreement among the parties?

-- Reporting via start/stop or interim and the NAS decides which way it wants to do this.

-- Bernard claims this draft has grown way out of scope.  Need discussion on what is the appropriate set of functionality 
 
-- Question about the Bandwidth-Profile-ID and what are the scalability issues?   Should it be part of the Filter-Rule attributes?  Avi Lior believes it would be a bad idea to overload Filter-Rule with bandwidth as well.

13. Dave Nelson on RADIUS Issues and Fixes
 
-- Kicking off a discussion on problems and points of confusion in existing RADIUS RFCs.  Not to be used for new functionality.  Goal is an informational RFC. 

-- Glen Zorn questions how we fix problems if we can't add new functionality.    Dave Nelson recommends that we document the issues and then consider fixes that might require a re-charter, i.e. a normative change to existing RADIUS RFCs, on a case-by-case basis.
 
-- Slides presented list a large number of current issues and clarifications to be addressed.
 
-- Next steps are to get discussion on the issues and begin a draft.  Dave will kick off as editor but would like someone else to take over at some point soon.

14. Greg Weber on RADIUS usage in L2PVN WG
draft-ietf-l2vpn-radius-pe-discovery-01.txt 
 
-- A current working group item in this group.  How to provision customer equipment as it joins a provider network and determine the set of interconnected pseudo-wires.  

-- This is not a traditional use of RADIUS because it is authenticating equipment not users, but still using User-Name to identify the customer equipment. 

-- Accounting hasn't been addressed much yet.  Looking into scalability concerns.  There is a big question around how 'zero-touch' can be supported?  Would like to get customer equipment with credentials so it could do something like 802.1X.  This is really how devices are being provisioned and authenticated into the network. 

-- Are there any dependencies?  No objective to do this.  Does RADEXT really need to look at this other than provide expertise review? 

-- There is some concern about using complex and formatted radius attributes with structure as this proposes.   There is a general concern about how to represent complex attributes such as NAS-Filter-Rule in 802 extensions.

15. Jari Arkko on Policy Decisions for Multiple Services
draft-arkko-radext-multi-service-decisions-01.txt 

-- Work from EAP lower layer efforts.  A single subscription can have access to multiple services and providers may have to apply policies on how to allow access. 

-- This is only a problem in roaming environments.  How to identify virtual services links such as PANA or IPSec. What is the NAS-Port-Type for these?  It might be better for NAS-Port-Type to represent the physical port and use something else to represent the virtualized or higher-layer.   Unclear that tunnel-type would be a good option either.  Perhaps the combination of NAS-Port-Type and Tunnel-Type to describe this. 

-- Several issues with how to use tunnel attributes for these virtual services in the slide.  Should there be a definition of something new or a clarification of how to use existing attributes?   It was pointed out that this is somewhat like the management attributes being defined because of using Radius in new ways.  This advocates creating new attributes for this.

-- What happens if the NAS "lies"?

-- Several people are interested in the problem, but no-one has a solution yet.  Next steps are to put this document into the pre-working group item review list.

16. Avi Lior on RADIUS Location Attributes (GEOPRIV WG)
draft-ietf-geopriv-radius-lo-02.txt

-- A number of GeoPriv issues were discussed from the slides 

-- One particular resolution is to add a capability attribute. 

-- Dave Nelson points out that this is another space where guidance on structured attributes would help 

-- Jari Arkko comments on Issue 70.  He believes it is a requirement that a policy must be followed if the client demands it, but there is no link layer that advertises the clients demands.  Somehow it would be good if the client could tell the NAS that it didn't want the information to be transferred. 

-- All the GeoPriv wants to do is be able to advertise location, but there are requirements to advertise additional objects that are location related.  There is a proposal to have an additional type of location information beyond civic and geographical to allow this information to be advertised.  This issue has been raised in the GeoPriv WG 

-- There is a question about which device has location information about what entities and what is advertised?  There is location of NAS and of end-user which are separate.   How would a NAS get location information of the user?  Avi points out the goals are to get user location information, and if the user can't do this or there is no channel to communicate this, the NAS may use other information to represent the user's location with reduced capability.

-- This discussion was taken offline to the list.

17. Avi Lior on RADIUS Capability Exchange 

-- There has been a lot of discussion around NASes advertising their capabilities and this draft attempts to capture this and the requirements for capability advertisement. 

-- There are cases where the home AAA server needs to know what the NAS is capability of to properly provision services and policies (e.g. prepaid) 

-- There are cases where the NAS would like to tell the AAA server that it needs to see certain attributes. 

-- There are cases where the AAA server would like to get something specific from the NAS. 

-- There are issues with how to represent granularity of the capabilities. 

-- This mechanism is really necessary to implement mandatory attribute requirements. 

-- A question is if this implies that the server needs to be stateful, and now does the NAS need to advertise this in every access request?  The goal would be to keep the server stateless.  If the info is small it might not be a problem to include in each exchange. 

-- What are the scenarios for capability exchange seen in Diameter? 

-- Glen Zorn believes the exchange makes more sense when there is a persistent session between the NAS and server.  The NAS support won't change session to session, but if we don't want the Radius server to keep NAS state then how will it understand the capabilities?  The concept of a permanent session between the NAS and the server is really about keeping state. 

-- Jari Arkko points out that we are really doing both policy and capability advertisement.

End-of-meeting.


Regards,
 
Dave
 
David B. Nelson
Enterasys Networks, Inc.
50 Minuteman Road
Andover, MA 01810-1008
Phone: (978) 684-1330  
E-mail: dnelson@enterasys.com
 


--
to unsubscribe send a message to radiusext-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>