IETF65 - Dallas, TX March 21, 2006 RADIUS Extensions Working Group Minutes Minute taker: David Mitton. Edited by David Nelson, with input from the Jabber Room log file. Agenda bashing. Milestone review -- We are trying to get to done. The revised WG milestones, recently approved and posted to the WG's IETF web site, were presented. We will be managing the work flow to keep to the new milestones. Document Status (see slides for overview) ------ Digest Authentication: Wolfgang Beck Wolfgang presented his recommendations for resolutions of IESG review comments. The one outstanding issue was the security concerns over the option for client supplied nonces. Sequence numbers are an option, but as timestamps they present issues. Glen Zorn: The size of the synchronization window is pretty large. Dave Nelson: There had been a request from 3GPP2 to add the option for client supplied nonces. Do they still need this? David S: We could live without it. It's a round-trip reduction optimization. Bernard Aboba polled the WG members present to sense consensus: (1) Remove the added Sequence number, and simple recommend that client supplied nonces be used not use - several hands (2) Keep the added Sequence number as described - nobody (3) Remove the client supplied nonce option altogether - several hands (3) Keep the client supplied nonce option - nobody The consensus of the room was to remove the client supplied nonce option altogether. This will be confirmed on the WG mailing list. Bernard asked for people to confirm if issues with this are closed, adn to send that notice to the WG mailing list. John Loughney - His issue is cleared. ------ Dynamic Authorizations MIB - Stefaan DeCnodder The status of open issues was reviewed. There seems to be consensus on how to address the AD review comments. The authors will submit a revised version, and a pre-submittal notice to the WG mailing list so we can check the revisions. ------ RADIUS IPv6 MIBs - Dave Nelson Reviewed the status of open issues from AD review, numbers 182 and 177, item 2. Similar in nature to the comments on the Dyn Auth MIBs. Will submit a revised version. ------ VLAN and Priority Attributes - Mauricio Sanchez Split out from the IEEE 802 Attributes draft. Trying to progress the non-contentious attributes and work on the NAS-Filter-Rule separately. Completed WGLC last week. Strawman revision draft posted to Bernard's web site to address WGLC comments. After IETF 65 and any additional comments, the revised version will be formally submitted. Open issue number 180, coding of attribute values: Bernard proposes: - VLANID as an integer - Priority Table as a string - VLAN Flag? Naming and encoding questions? It is currently 0x31 because it's easer to type an ASCII "1" as part of name string. It gets added to a VLAN name, but also used as a number. VLAN Tag-Indicator is preferred as the field in by large margin of those in the room. NAS-Filter-Rule Attribute Asked the DiME WG for their input, as the original version was defined in the Diameter RFCs. The question of how to keep RADIUS and Diameter in sync on this feature is not yet resolved. It will require cooperation of RADEXT with DiME. Bernard Aboba: 3GPP has recently requested the Diameter Filter-Rule feature in RADIUS. Dave Nelson: RADIUS and Diameter should not have separate dialects of filter rules. Bernard Aboba observed that the syntax is defined in RFC 3588, but only used in RFC 4005. John Loughney suggested that the NAS-Filter-Rule move to an RFC 4005 revision draft. Glen Zorn: If we're doing translations in a gateway anyway, just do another one. If it's just a syntax issue... (that is not answered) Dave Nelson: The identity translation operator is always easier. John Loughney: Agree with the proposal, but we need to write down translation rules. Q: Is there a plan to continue rules for translation? John Loughney: This is a topic for the DiME WG, and we would like a volunteer. Glen Zorn: The translation rules are in RFC 3988 and RFC 4005. -------- Delegated IPv6 Prefix - Ralph Droms Revisions and issues because from WGLC were reviewed. Created an attribute to match a similar one in RFC 3162. An issue was rained with respect to attribute design guidelines. Bernard Aboba: The issue have been resolved on the WG mailing list. Question: What is the use case? One use case is DOCSIS authorization. Comment: Could also use in WiMax. ------ WLAN Attributes - Bernard Aboba Several attributes to pass 802.11 new things - EAP-Key-Name - EAP-Peer-Name Parviz Yegani: What is Mobility-Domain-ID for? Bernard: Thought that IEEE 801.11r specified the need. If you see this advertised, then you can roam between them and get fast handoff. Nancy Cam-Winget: Not required, but could be useful for accounting. ------- RADIUS Design Guidelines - Greg Weber Dave Nelson: We have a milestone to go to WGLC in June, so we need to get motivated on this. Bernard Aboba: If your draft will get gated by this one, then you must read it. Question: What is the level of compliance expected? Bernard Aboba: The content of the document is a WG issue. If the working group doesn't think everything needs to be enforced, then those items should be removed from the draft. Glen Zorn: My understanding is that the reason there is pressure to get this out is that it is holding up other work. Dan Romascanu: Wants the design guidelines work to move forward. Don't want other documents to move forward with things contrary to the guidelines. In MIB world we have CLRs (crappy little rules), which don't always add value. Various commenters: A lively discussion of when the format and structure of complex attributes matters and when it doesn't. The general sense of the discussion is that it matters when some RADIUS entity needs to pick apart and take action on individual sub-elements. Bernard Aboba: The Wolff draft looks like Diameter VSAs. VSEs - No, use standard attribute values instead. Glen Zorn: Per-attribute encryption applies only to only User-Password. Tunnel-Password is not standardized. Greg Weber: Encrypt the whole message. Glen Zorn: How? Greg Weber: Use IPsec. Glen Zorn: IPsec has problems with authentication and Trojan horse issues. Greg Weber: Security must be done at the application layer, because cannot tell if IPsec is operating as desired. Do we have an IPsec problem in general? Glen Zorn: I think we do. Dave Nelson: The expectation is to produce a new standard for crypto agility for the current mechanisms, and a guideline for accommodating other mechanisms. Bernard Aboba: Are we saying don't use existing RADIUS security mechanisms? Glen Zorn: As written, this is band-aiding the broken stuff. Bernard Aboba: Security statement or guideline? Don't do it as we did, but like we might say in the future. Bert Wijnen: SDO related attribute design rules? Do they want them? Bernard Aboba: No, we need to give something for them to use in creating RADIUS Extensions, without a full review here [in the IETF]. Other SDOs try to come through the IETF or go via IANA. Allow them to do work independently. Dave Nelson: Encourage SDOs to design for the standard attribute space. Discourage them from inventing novel encapsulations, particularly when multi-vendor interoperability is required. Glen Zorn: Using the Vendor-Specific attribute space has kept them from infringing on an already crowded standard attribute space. Wolff draft on Extended RADIUS Attributes. (See slides) Bergen draft on Extended RADIUS Attributes. (See slides) Discussion of Extended RADIUS Attributes: Question: Are we recommending Sub-Attributes? Will these be nested or flat? Greg Weber: They would be hierarchical. Parviz Yegani: Should we be following this structure? Greg Weber: That's the issue in question. Bernard Aboba: Do people like it or not? Nested is fine, but the format is an issue. Dave Nelson: This is like coding standards, you love them or hate them. Parviz Yegani: We need to move on. Should we redo things? Bernard Aboba: If you don't like them, propose something better or different. Dave Mitton: What is the status of these drafts? Bernard Aboba: They are pre-WG items. Dave Mitton: Suggest two documents, one for guidelines and one for extended attributes. ------ Issues and Fixes - Bernard Aboba Presented the current draft status. It probably needs more input before becoming a WG work item. ---- RADIUS-Diameter-VSAs - Dave Mitton Presented the status of the draft, and it relation to the Extended Attribute ideas. Glen Zorn: Has an issue with putting Diameter AVPs in RADIUS messages, becasue of the overall RADIUS message length limitation. He is working on a solution to the RADIUS message length constraint. Dave Mitton: Please publish and I-D on this. ---- Pre-Paid Attributes - Parviz Yegani Presentation of the changes from the last draft version. Glen Zorn: Removing Authorize-Only reduces usefulness, please put it back. Bernard Aboba: To clarify the issue: Authorize-Only raises the opportunity for DOS attacks, and has to be tied to State attribute to prove prior authentication. Glen Zorn: Issue with requiring a minimum number of positive reviews to advance documents. Bernard Aboba: This recommendation came from our AD and the IESG chair. ----- GEOPRIV RADIUS Attributes - Jouni Korhonen Presented the changes based on RADEXT WG reviews so far. This document is being advanced in the GEOPRIV WG. Bernard Aboba: We are not coming to convergence quickly enough. We need to figure out how to finish this. Do we need to assign a team? Dave Nelson: The major issue is with the attribute structure? Bernard Aboba: I think there are values that will need to be picked apart, so the current [attribute] design won't work. Greg Weber: This may represent another class of data blobs that need to be picked apart, but need to be carried by multiple transports (RADIUS, Diameter, DHCP). Bernard Aboba: Yes, I wish I knew what DHCP was doing with location information encoding. From the Jabber room: Alan DeKok: Is the format defined elsewhere? Bernard Aboba: Yes, in the case of the civic and geospatial location data. Dave Nelson: How do we move forward? Bernard Aboba: We need to get the RADIUS people to decide what they want to do. with the help of the location people. Dave Nelson: The chairs will attempt to set up a small group to facilitate this. With this, the session time expired and the meeting adjourned.