IETF 67 RADEXT WG Minutes Harbor Island I 9:00 - 11:30 AM Tuesday, November 7, 2006 Note takers: Mauricio Sanchez, Madjid Nakhjiri Jabber scribe: Sharon Chisholm Minutes editor: Dave Nelson * Meeting started at 9:05am * Agenda bashing. No changes. Look for info in http://www.drizzle.com/~aboba/RADEXT/ Look for presentations at IETF meeting material page: https://datatracker.ietf.org/public/meeting_materials.cgi?meeting_num=67 * Bernard went through WG document status. ------------------------------------------ - 7 docs published as RFCs, 4 RADIUS IPv6 MIBs and 2 Dynamic RADIUS MIBs - some comments on the MIBs came after RFC publications, but mostly editorial - Dave described comments made on the RADIUS MIB RFCs relating to structure and format; No substantive comments, just editorial. * Wolfgang Beck went through RFC 4590 errata issues. ---------------------------------------------------- - A week after the RFC publication, an implementer sent email about an error about an IANA type. - It seems to be easier to change the IANA website than to change the RFC. - Bernard asks whether WG feels that errata are severe enough to cause confusion - Alan DeKok (Infoblox) feels strongly that there are issues at hand and should be addressed; He ran into questions. - Bernard recommends that minor clarifications be made; IANA table updates. Feels that a quick spin of document is possible - Bernard moreover recommends that issues not be treated as errata; Indicates that a quick "bis" draft and WGLC would be advisable. * Mauricio Sanchez presented NAS-Filter-Rule and NAS-Traffic-Rule draft ----------------------------------------------------------------------- http://www.ietf.org/internet-drafts/draft-ietf-radext-filter-04.txt http://www.ietf.org/internet-drafts/draft-ietf-radext-filter-rules- - A draft comparison slide was shown between the radext-filter-rules and radext-filter-05 - the filter-rule draft is simpler since it is based on Diameter, - there are two attributes in the first draft and one attribute in the second draft. - NAS-filter-rule status - 5 new draft versions since IETF66 - resolved issues: attribute length and Diameter-READIUS GW behavior - open issues: concatenation/splitting - Base questions: how to split a long rule across multiple rules? - 6 proposals since IETF 65 - usage of tag field was favorite out of IETF 66. - It seems that a consensus is being reached quickly on this issue. - Plan to go to WG last call with 05 draft. - Bernard: Can we deal with the issue right now? What if Diameter sends both kinds of attribute? - Implementers of Diameter come and say what use does it have in RADIUS and why? - Comment: - Bernard: Anybody has an objection to have a MUST not use both here? - Comment: - Bernard: OK, done. - NAS-traffic-rule status - no new drafts since IETF 65 - Editor to go talk to individuals to get opinions - big variety of open issues existed: -- accounting issue mostly closed waiting for 3GPP insights -- NAS filter rule accounting - Diameter compatibility - Bernard: There is a VLAN attribute draft that is not just for RADIUS but also for Diameter. - AD: Pointed the charter to Dave: All RADIUS functions must be compatible with - Diameter and attributes must be reused as much as possible. - Next step: To close the issues to talk to issue owners in the next couple of weeks - new version 02 within a month * Alan DeKok presented RADIUS issues & fixes draft -------------------------------------------------- - A list of clarification (e.g. on EAP), a list of correction, question relatively little discussion or disagreement on list about the issues and fixes draft. - Alan asks the group how many have people have read the draft; Few people have - Dave suggests we take it to last call to force everyone to read it - Someone pointed out that this draft is not a WG item, yet is already being considered for last call. Bernard contends that this has been done in the past to take an individual submission and turn it into a WG item at the same time it went to last call. - Dave asks group whether anyone objects to taking document to working group last call. No one does. Dave and Bernard to confirm consensus on email list. * Dave presented NAS-Port-Type attribute draft ---------------------------------------------- - Dave asks group whether to take document to WG last call - Pasi Eronen says that draft has five lines of technical content, just ship it. - Bernard points out that the RADIUS IANA Considerations in RRC 3575 says additional values for attributes can be approved by designated experts do not require a published specification. - Bernard suggests that it not be published as an RFC to reduce IASA / RFC Editor publishing costs. - Simply request the values from IANA. - WG chairs will provide IANA with an expert review contact. - AD: As long as we have regular get-togethers where people oversee these assignments. * Bernard presented WLAN attributes draft ----------------------------------------- - Some attributes already assigned in RFC 4072 - Pre-auth support -- It was discussed in HOKEY BOF -- There is a use case in 802.11 and there are some tricky issues - SSID attribute - Pre-auth key lifetime attribute -- A STA pre-auths with an AP, but it does not know what the AP SSID is, and the AAA server does not know the diff between pre-auth and full auth. -- Situation, when the admin want to cache the keys just for a short time when it is pre-auth compared to longer time for regular auth. - Bernard asked group whether to make draft an official WG item - Dave questions whether to split document into attributes that are necessary now and those that need further definition. Draft is already behind from a milestone perspective. Bernard points out that IEEE 802.11r group may have requirements, but is busy with other issues at this point. - Dave asks group whether group has preference on what to do with document - Majid points out that HOKEY does have dependency on AAA pre-auth requirements that from a timeline perspective are further out. - Majid asks about the process of getting comments from .11r group; Bernard explains the formal liaison process to request comments - Bernard suggests that we submit a liaison request to IEEE 802.11r to get them to review document. * Glen Zorn presented Extended RADIUS attributes draft ------------------------------------------------------ - Glen asks how many people have read it; Only a couple have - Alan DeKok points out that he has comments, but has separate presentation for his points. - Dave asks Glen how extended attributes should be treated by servers not supporting extended attributes; Glen replies that servers that don't understand the attribute will ignore it, whether that's a problem is a different question. Glen expects all contemporary servers to support extended attributes. If ancient servers can't, then so be it. - Dave asks whether having just an 8-bit type value for extended attributes is too small. An 8-bit value would only allow for 256 additional extended attributes. Glen believes this is good because it would force conservation and have a built-in penalty for creating new attributes willy-nilly. If the type space were once again exhausted, a new vendor-id would have to be allocated. * Alan DeKok goes through his commentary of extended RADIUS ----------------------------------------------------------- - Glen agrees with the argument that a non-zero vendor-ID should be allocated; He went on to say that GEOPRIV should be given their own vendor-id; He argues that the value of 0 traditionally means IETF. - Dave points out that it's unclear of whether multiple vendor-id values can be registered to a singe entity; Someone in group says that it is possible. - Dave made comment on tag and feels that it is of value; It's not a con. Alan agrees that it's the most practical option available; Points out that EAP clients and servers are currently forced to mangle attributes. It would be useful just to do it once. - Glen points out that Alan's presentation isn't as much a criticism as an exposition of issues; Questions whether there will be any short-term decision to make progress; Dave responds that a large block of time was allocated up front but asks opinion of group. Alan says he's fine with the state of the document other than vendor-id. Suggests that group pick a vendor-id value and have some preliminary interoperability testing. Bernard says that the extended attribute draft is necessary to be able to complete ongoing attribute work; Code space will run out based on proposed work and something must be done. - Someone points out that granting control code space control to other groups (other than RADEXT) needs to be considered. Bernard points out that there are already something like 12 different dialects of RADIUS. IESG needs to answer whether this is acceptable or not. - Glen suggests that allocation of vendor-id/type values be separated out from format issues. Bernard nodded in agreement. - Dave opens floor to ask group what should be done with document * Majid points out that other groups do need attributes, groups can't wait. Sees value in allowing groups control their own destiny and manage their own attribute space. * Glen recommends cutting to the chase and making document a WG item. * Bernard recommends that a new version with local RADEXT issues be addressed, thereafter document should be open to other groups for review. * Glen points out that making document a WG item would force control of document by greater group than where it is as an individual submission. Glenn wants to be under the control of the chairs. * Group agrees to make a new version and distribute to greater community. * Dave presents RADIUS guidelines draft --------------------------------------- - Bernard comments that the objectionable part of the draft is to try to deprecate old RFC and say that current way RADIUS works/designed is bad. Objective of document should be limited to things that prevent deployment, such as those things that force server code change issues. Document should strive for architectural purity, since most don't force server code changes. - Bernard wishes that document be basis for other groups to define their own attributes that adhere to guidelines and not force groups to pass their attributes through RADEXT. Dave counters that MIB example is not a valid example. - Bernard suggests that document remove extended attribute discussion and other things people find objectionable. Take a look at the core and see whether enough remains to take on as official WG item. - Glen Z. and Hannes T. step forward to volunteer as co-editors of document * Dave presents crypto-agility work item ---------------------------------------- - Glen questions where security requirements are documented. Dave responds that Russ said to write security requirements as stated to point to SAAG - Hannes T. asks whether this work item would provide end-to-end security between client and server. Dave and Bernard say no. This document only describes how new crypto algorithms can be used in the current protocol framework. Dave states that genesis is document is to address the security issues arising from the recent identified weaknesses in MD5. - Someone comments that if addressing MD5 issues is really the problem at hand, then the document should state that as the scope. Feels current document has many general requirements. Bernard points out that there are probably two paragraphs that actually address the MD5 issue. Feels that document needs to be explicit in what it intends to fix. Bernard recommends title 'Crypto-Agility Goals in RADIUS' - Someone wanted confirmation that this work item was not undertaking a huge gap analysis. Bernard says emphatically no. - Joe S. is concerned by 'negotiation'. Dave contends that there is already a very simple 'negotiation' present in RADIUS. The client proposes via hint attributes in the Access-Request. The server disposes via provisioning attributes in the Access-Accept. This work item would not upset the balance in RADIUS. - Glen concerned about the recommending MD5 as lowest common denominator when no other crypto supported. Feels like a security issue to him. * Hannes presented GEOPRIV cross-WG review item ----------------------------------------------- - Bernard asked about document status. - Hannes unsure and would need to look at the issue tracker. * Hannes presented RADIUS MIPv6 draft ------------------------------------- - Glen asks whether acceptance of extended radius attribute draft will have impact. Hannes says it depends. Glen feels that remaining radius standard code-space should be set aside for future use, a conservation measure - Dave says that RFC 3575 would need to be updated to ensure reservation of remaining code space. * Vidya presented handover key draft ------------------------------------ - Group discussed what to do with draft; Bernard and Jari agree that this draft conceivably create a new authentication method for RADIUS, just like digest authentication. - Glen points out that an existing individual submission, key request, that presumably does some of the same things Vidya's draft provides. Questions arises on whether mechanics used by Glen's draft are similar to handover draft. Glen suggests that key request draft be reviewed for changes that would address handover draft. - Bernard comments he doesn't understand how this draft has anything to do with keying. Vidya explains how key material is transferred as part of handover exchange. - Bernard asks whether handshake is stateful or stateless. Vidya says it's stateless. Bernard now sees parallels to other authentication transactions, like http digest authentication. - Bernard asks what is the question MIPSHOP desires RADEXT to answer. Is it the case that all options needs to be reviewed, just one? Jari says that there may be some of both. - Someone expresses concern of using RADIUS as a key server. Vidya points out that key material is not tied to the RADIUS server and can be logically separated from server. - Glen points out that this draft is shoehorning a function not serviced well by RADIUS; It's key exchange protocol that happens to use RADIUS. Glen doesn't feel this is the way to go. * Dave notes that we are over our allotted time, so remaining discussion, as well as the remaining agenda item will need to be discussed on the WG mailing list.