[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Draft RADEXT WG Minutes from IETF-63
Please review this draft of the minutes of the RADEXT WG session at IETF-63. Kindly reply to the list with any errors or omissions you may notice, by the end of this week (August 26). Thanks!
----------------------------------------------------------------------------
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:
- 2684bis in AD follow-up
- Dynauth MIBs completed WGLC, 9 issues
- CUI in AD follow-up
- Digest Auth completed WGLC xx issues
- 802 Extensions in WGLC, 3 issues (so far)
Presentations:
- 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 Webber 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:
- Proper use of the state attribute
- Request ID supplementation alternative
- Re-transmit schemes
- How to handle overload conditions
- Clarification of accounting attribute updates
- Clarification of using multiple Filter-ID attributes
- Treating access-accept for unknown services as a reject
- Avoiding sending VSAs to a NAS that doesn't understand them
A question about this recommendation is how to reliably detect supported vs. unsupported VSAs. The capabilities attribute is a possible solution. Glen Zorn suggested the possibility of a version number. Since this is just -00, it was suggested to post issues against the document. It was noted that some issues were currently in the tracker but not yet included in the draft.
- Corrections to RFC 2869, section 2.2 regarding miss-stated Access-Challenge.
- Handling multiple services
- Defining how to calculate Message-Authenticator for Disconnect, COA and others
- Authorize only discussion
There were some questions of how this document should progress. The document is useful, but perhaps an RFC 3576bis additionally needs to be created. Also, some of the issues are against earlier RFCs as well. These are standards track and may be more difficult to update. This document is intended to address existing and past issues. Another forward looking document discusses future issues. Other issues not addressed were NASes with multiple IP addresses and accounting interval updates. These should be included and consensus on a solution for these needs to be proposed.
- 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 points out that IPSec is inappropriate as a protection mechanism for an application level protocol. Glen believes 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. The latest draft of the Zorn document has all the changes included based upon the NIST discussion. Nancy indicated that NISTs reaction to IPSec 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 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 appropriate.
- 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-capability-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.
--
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/>