Last Modified: 2005-06-27
| Dec 04 | Updates to RFC 2618-2621 RADIUS MIBs submitted for publication | |
| Dec 04 | RADIUS design guidelines submitted as an Informational RFC | |
| Dec 04 | SIP RADIUS authentication draft submitted as a Proposed Standard RFC | |
| Jan 05 | LAN attributes draft submitted as a Proposed Standard RFC | |
| Feb 05 | RADIUS implementation issues and fixes submitted as an Informational RFC | |
| Feb 05 | WLAN attributes draft submitted as a Proposed Standard RFC | |
| Done | RFC 2486bis submitted as a Proposed Standard RFC | |
| Dec 05 | RADIUS Prepaid draft submitted as a Proposed Standard RFC | |
| Dec 05 | RFC 3576 MIBs submitted as an Informational RFC |
|
IETF-63 RADEXT WG Minutes
Scribes: Paul Congdon, Greg Weber (Editor: Dave Nelson) No jabberer. (Later Hannes Tschofenig joined the jabber room.) Bluesheets started. No agenda changes requested. Presentations and agenda online at: http://www.drizzle.com/~aboba/IETF63/radext/ RADEXT Issues Tracker location: http://www.drizzle.com/~aboba/RADEXT Streaming audio archive location: http://limestone.uoregon.edu/ftp/pub/videolab/media/ietf63/ietf63-ch5-wed.mp3.1 [start time index: 20:34] Brief status of WG work items:
- RFC2684 bis presented by Jari Arkko. http://www.ietf.org/internet-drafts/draft-ietf-radext-rfc2486bis-06.txt Problem with internationalization found in IESG review. Added clarifying text for ABNF vs. document text requirements and the use of UTF-8 vs. IDN-unware ASCII for the realm part. Revision back to IESG for approval -- very soon, e.g. about a week. Realm strings will be IDN unaware (no "!"). - Chargeable User Identity presented by Avi Lior. http://www.ietf.org/internet-drafts/draft-ietf-radext-chargeable-user-id-03.txt All issues have been addressed in the current version of the document. Several SDOs are interested in this draft - WiMAX is one who will be submitting a liaison letter to IETF for this. Pasi Eronen clarifies that this document is in AD evaluation stage and not at the IESG. Bernard may need to update the web-site to indicate the appropriate document status. ID Tracker from IETF homepage is definitive on status. - Digest Authentication update by Wolfgang Beck. http://www.ietf.org/internet-drafts/draft-ietf-radext-digest-auth-03.txt Diameter compatibility is the current main issue with the document. There is also an issue regarding client-side nonce generation when interoperating with Diameter - additional text will be added to address this. We could move forward two ways; one it get client side nonce generation added to diameter, or simply drop this. The 3GPP2 liaison would like to see client side nonce generation remain because they currently use it. Avi Lior recommends that we operate in both modes of operation and when working with Diameter, and get Diameter to update to support client side nonce generation. The 3GPP2 people are waiting for an RFC number on this document so they can publish their spec. The security considerations need to be updated to discuss what to do when realm check fails. There were also some typos that will be corrected. Desire to get -04 version out shortly after IETF-63. - Dynamic Authorization MIBs - Greg Weber speaking for authors who could not attend. http://www.ietf.org/internet-drafts/draft-ietf-radext-dynauth-server-mib-01.txt http://www.ietf.org/internet-drafts/draft-ietf-radext-dynauth-client-mib-01.txt These MIBs are companions to RFC 3576. They are expected to be completed by the end of the year. Issues 96/97 have been resolved and are simply editorial in nature. Issue 105 resolution relates to where the MIBs are to be located in the OID tree. It is believed that new MIBs should be rooted off of mib-2 and the authors are willing to make the change to support this. Issue 92 is the most controversial. A few new terms are defined by this document; DAC and DAS. It was suggested to match RFC 3576 and not introduce new terms in MIB, however the terms are embedded in all of the object names. It is still the belief of the WG that the terms should be consistent and it sounds as though the object names will be globally searched and replaced. Bernard Aboba: RFC 3576bis would be within WG charter, and we could address the terminology issues there. That would mean either delaying the MIBs or revising them later. - 802 Extensions draft presented by Paul Congdon. http://www.ietf.org/internet-drafts/draft-ietf-radext-ieee802-00.txt Discussed recent changes, but not current issue status. Changes include removal of controversial (Diameter-like) extended attribute types, no new data-types or M-bit, fleshed out the NAS-Filter-Rule, can now specify L2 encapsulations, removed IP-redirection rule type in favor of tunneling. Among the interested parties are TNC of TCG, 3GPP, WiMAX (hot-lining). Glen Zorn questioned the chairs on why this document was so quickly moved to last call. The chairs believe that the previous issues in the individual submissions were sufficiently resolved and there being a number of SDOs waiting on this document see the need to expedite the review and closure of this document. WG last call closes on Aug 10th. There was a question regarding when the wireless attributes would be documented. There is a -00 draft on WLAN attributes to be discussed on this later in the meeting. - RADIUS IPv6 MIBs discussed by Dave Nelson. http://www.ietf.org/internet-drafts/draft-nelson-rfc2618bis-01.txt http://www.ietf.org/internet-drafts/draft-nelson-rfc2619bis-01.txt http://www.ietf.org/internet-drafts/draft-nelson-rfc2620bis-01.txt http://www.ietf.org/internet-drafts/draft-nelson-rfc2621bis-01.txt New textual conventions for address objects have been included. Review comments from the MIB Doctors have been resolved in the -01 revisions. The drafts UPDATE their predecessor RFCs, deprecate old tables (not doing table augmenting anymore), added new tables to mirror old ones, added specific usage guidelines new IP address objects. The question of whether these should be WG work items was posed and no objections were heard. The RADEXT -00 drafts will be created and moved to WG last call. - Common Radius Implementation Issues and Fixes presented by Dave Nelson. http://www.ietf.org/internet-drafts/draft-aboba-radext-fixes-00.txt The document was created based upon a long laundry list of issues that have been discussed on the mailing list. This document identifies many of the problems identified in the field and makes suggestions to resolve the problems. Areas discussed include:
- RADIUS Attribute Design Guidelines presented by Greg Weber. http://www.ietf.org/internet-drafts/draft-weber-radius-attr-guidelines-00.txt This is a forwarding looking document addressing design recommendations for new attributes. This document describes what is considered a good attribute design and reviews the current RADIUS data types, as well as the divergence in the Standard and Vendor Specific data models. A few have reviewed this document so far. The current document does include some recommendations, but these are straw-man recommendations. The motivation for this document is to get better alignment with data models in vendor attributes, address attribute space exhaustion and align better with diameter. The scope of the document includes consideration for backward compatibility, existing VSAs, supporting the existing transport, non-AAA applications and Diameter compatibility. The document straw-man proposes a single standards base format for VSAs as a recommendation. The document also includes recommendations on when particular formats should be used and when to use existing VSA format verse the new one. Lots to do on this draft. Avi Lior agrees this document is a good starting point and is willing to work on the draft. There was a question whether SDOs should be differentiated from Vendors, but the group doesn't believe so. There was a question whether IANA considerations are included, but the authors believe this is already spelled out elsewhere. Glen Zorn asks if it was considered to extend the size of RADIUS attributes rather than dealing with fragmentation. Greg Weber did not consider this because he felt it would be beyond the scope of the charter. - WLAN Attributes presented by Jari Arkko. http://www.ietf.org/internet-drafts/draft-aboba-radext-wlan-00.txt The list of attributes that were removed from the 802 Extensions draft was presented. There is some overlap that needs to be discussed. [Technical difficulties with slides caused us to move forward to the next topic.] Upon return, some relationships to the EAP keying draft were described. A list of key management attributes were described and the issues. Privacy can be addressed similar to NAI and by omitting Peer-ID and Server-ID attributes. Key-wrap options were described as three choices; AES key wrap, a Key Encryption Key (Zorn draft) or IPSec. The later is not used in industry. The key-wrap options may be difficult to resolve. The questions on this document are whether this should be a WG item and how to solve the privacy and key-wrap problems. - RADIUS attributes for Cryptographic Keys presented by Glen Zorn. http://www.ietf.org/internet-drafts/draft-zorn-radius-keywrap-07.txt The motivation for this draft was to allow RADIUS to be used in certain government environments. While RADIUS isn't a key provisioning protocol, there are keys that are passed around in RADIUS and perhaps aren't wrapped securely enough. Several editorial changes were made in the -07 revision, but also HMAC-MD5 was removed and other key transport attributes (e.g. MPPE-xxx) were outlawed if the same data is also transferred in the new attributes. Questions about how keys are transferred to the client - hop-by-hop or end-to-end? They are passed along the path in the way they are set-up - may be hop-by-hop. Glen plans to add AES-CMAC and some other technical changes in the -08 revision. - General WG discussion on key-wrap issues. Glen Zorn points out that the keying issue is not just an 802.11 or Wireless problem. Also, Glen believes that IPSec is inappropriate as a protection mechanism for an application level protocol. Glen believes that NIST is in agreement that IPSec is not appropriate for this use. Nancy Cam-Winget from Cisco summarized the NIST meeting that took place back at the end of June. She also agrees that it isn't just wireless that needs the keying solutions. They wanted to know if a new key-wrap attribute with a new algorithm would be sufficient or would IPSec work. Nancy believes that the latest draft of the Zorn document has all the changes included based upon the NIST discussion. Nancy believes that NIST's reaction to the use of IPSec to protect RADIUS key distribution was that it would require further review by NIST. Jari Arkko also believes the key work isn't just for wireless and would like to see it in a separate draft from other WLAN attributes. There was a question about the relationship to the Zorn document and the Aboba document? We do have keying attributes for WLAN as a charter item for this group, but can't introduce new security mechanisms. Bernard's document comes from the EAP key framework perspective. A question about a new message authenticator algorithm and attribute being described by Glen. It can be used in any RADIUS message because it is independent of the authenticator value in the RADIUS message. Message-Authenticator cannot be used in Accounting-Request or CoA messages. The new one is cryptographically stronger; the old one is not FIPS compliant (MD5). The new attribute can be used as a complete replacement of the old style message authenticator. Alternatively, the old message authenticator could still be used. Bernard's draft reuses the RADIUS shared secret, while Glen's draft assumes a cryptographically separate pre-shared key. Bill Burr cautions that NIST is not looking very closely at RADIUS usage and so there isn't a good view of what is being done here. He characterized the existing wireless key distribution mechanism (i.e. as used in 802.11i with RADIUS) as somewhat "Rube Goldberg". Bill described the process of obtaining a FIPS-140 certification and how painful it may be for vendors. Glen points out that there is a lot of interest in solving this problem and it has been solved, so why is there a new WLAN draft addressing the keying mechanisms? Dave Nelson (Chair) indicated that the keying problem seems to have a lot of interest. The WG might consider amending its charter (security mechanism restriction) to address this issue, if needed. [Ed. Note: Only the statements of Bill Burr should be considered as the position of NIST. Other statements are the opinion of the speaker.] - End-to-End capability exchange presented by Avi Lior. http://www.ietf.org/internet-drafts/draft-lior-radext-end-to-end-caps-01.txt The proposal describes an end-to-end, per-session mechanism to negotiate capabilities. The attribute contains a string of octets where each capability is encoded in 2 bits that define, not-supported, supported and required. Avi points out other documents need this work; location in the GEOPRIV WG, VLAN, priority and filtering, CUI and prepaid could all use this. Should it be a WG document? No one objects to making this a WG item, but we will confirm this on the list. This document should be in alignment with Greg's work on Design Guidelines if we are defining a new data type. - RADIUS Prepaid attributes presented by Avi Lior. http://www.ietf.org/internet-drafts/draft-lior-radius-prepaid-extensions-08.txt The document was re-organized for read-ability and updated. Flow based prepaid is becoming a requirement. Requested by 3GPP2 and WiMAX. The difference between RADIUS credit control (a.k.a. prepaid) and Diameter credit control was described. It is believed that some of the differences are regarding some features that may compromise the privacy of the client (e.g. balance check and cost inquiry). Other differences are not clear yet and need to be discussed. How can Diameter credit control and RADIUS prepaid be translated? The recommendation is that the server must do this itself. A recommendation from the audience was to have scenarios documented or analyzed - not necessarily included in the draft, but available. Different SDOs are using Diameter and RADIUS, and there will likely be some issues related to translation. Resolution of these issues may require assistance from 3GPP, 3GPP2 and WiMAX, as the RADEXT WG didn't anticipate supporting different "dialects" of the prepaid extensions. The authors believe the document is ready to become a WG item. Since the authors are not in complete alignment it was suggested that they hash out their problems before making it a WG document. The authors believe they have enough alignment, but being out of time, we will continue the discussion on the WG mailing list. - RADIUS Bandwidth attributes presented by Avi Lior. http://www.ietf.org/internet-drafts/draft-lior-radius-bandwidth-capabili ty-01.txt Issues from Bernard Aboba's extensive review have all been addressed, except one which is related to the length of the attribute size. Should this be a WG document? Discuss on the WG mailing list. - RADIUS QoS attributes presented by Hannes Tschofenig. http://www.ietf.org/internet-drafts/draft-tschofenig-radext-qos-01.txt Hannes describes a more general QoS environment. This work is related to the Diameter work. They are addressing a generic description described in NSIS QSPEC work. As compared to Avi Lior's bandwidth document, this is a more heavy weight description. Avi's document is viewed as a short term solution. There is the question of charter scope in RADEXT. - General WG Discussion about QoS and Bandwidth. Allison Mankin (Transport AD) points out that we shouldn't use RADIUS as a resource management protocol. She believes that RSVP and NSIS are the protocols to do resource allocation. There was an RSVP and Diameter document that is similar to proposed RADIUS document. John Loughney comments that the Diameter QoS document is an individual submission and not a current AAA WG document. John will post the link to the RADEXT WG mailing list for this document, so that we can review it. Allison mentions that we don't want to start extending the bandwidth draft to include a bunch of new things like latency and jitter, but they are happy with simple rates that are currently defined. Combining Avi's bandwidth draft and Hannes' QoS draft would certainly delay the simple bandwidth parameter attribute that has been requested by other SDOs. A comment from 3GPP is that they are depending upon the bandwidth draft to be complete for reference in their specification release 7, by mid-2006. The group doesn't believe they should be combined. Dave Nelson (Chair) asked what the overlap is between the documents. Avi points out that the QoS "blob" includes a bandwidth component and could be used, but John Loughney and the other authors believe there may be a solution on how cross reference the documents and avoid overlap. Dave (Chair) indicated he would work to facilitate the cross-WG and cross-Area coordination that will be required to move forward in this area. |