IETF-66 RADEXT WG Meeting Minutes 9:00 AM - 11:30 AM Monday, July 10, 2006 Montreal, Quebec, Canada Note takers: Mauricio Sanchez, David Mitton. Edited by: David Nelson. 1. Agenda bashing: no changes proposed 2. Document status (Bernard) Since last IETF eight (almost nine) documents are completed 3. NAS-Traffic-Rules, NAS-Filter-Rule (Mauricio) Comment (Glen Z): You can always parse the beginning of a rule. The end is harder to recognize. Suggest that you enhance the Diameter filter rules, as it's not that good. Comment (Dave N): Suggest that we don't pack multiple rules into one attribute. Comment (Bernard A): We need to clarify the issues. Comment (Glen Z): With NAS-Traffic-Rule you will have to translate strings. Answer: We'll we have a proposal coming. Comment (Dave N): 3GPP has already deployed Diameter, and requested the NAS-Filter-Rule capability in RADIUS. We need to meet that requirement. Issue: RADEXT Issue 170 -- Precedence and order of server-provided rules to local NAS-provide rules. Comment (Bernard A): This is an issue if NASes have local rules and policies. This has been around forever. Comment (Dave N): We are about policy provisioning, not policy definition. Comment: The principle should be interoperability of features. Poll (Bernard A): Who thinks the NAS-Filter-Rules draft is ready last call? Response: 1 Poll (Bernard A) Who thinks the NAS-Traffic-Rules draft is ready for last call? Response: 0 Comment (Bernard A): We all need to read and submit comments so we can move forward. 4. Pre-Authentication AAA Requirements (Yoshiro Ohba) Yoshiro presented two basic requirements identified in the IETF-65 BoF. Yoshiro presented technical issues related to pre-authentication. There is a dependency between moving between pre-auth and auth states and key caching. Comment (Bernard A.): Key caching was addressed 802.11i and it was decided that key caching was not going to be managed individually by user, it is a global parameter. Given it’s a global parameter its there’s no need to control via RADIUS. Each system is configured with key cache timeout. Comment (Nancy C-W): Says that 802.11 revisiting topic and considering to use something else other than Session-Timeout as a means to signal when to expire keys. In 802.11i, there is no notion of session lifetime, just a key lifetime. Comment (Bernard A): Asserts that the meaning of the Session-Timeout attribute is too overloaded. Comment (Nancy C-W): Yes this is an issue. Says that 802.11r has no notion of pre-authentication. We are looking at making this more explicit but it's not done. Comment (Pat C): Points out that there is no signaling between authenticator and server about the pre-auth state. You are trying to do some sort of signaling on the transition from Pre-Auth to active? It's not clear that these events exist, and they are not RADIUS issues. Comment (Bernard A): Points out that no accounting is generated prior to session setup. Accounting is used to know when session starts and ends. We need to ask implementers what they do. This is discussed in RFC 3780. Comment (Pat C): Not sure this is practical for wireless roaming. Concerned that a client may pre-auth with many APs and if it moves just a bit... Comment: Calling-Station-ID – What value shall it take on with pre-authentication? Yoshiro presents a summary: Drives home message that pre-auth requires a lot of work in EAP and AAA layers. Most work to be done in HOAKEY. Comment: Someone asks scope of HOAKEY. Answer: HOAKEY will define requirements that will need work in respective working groups. 5. WLAN Attributes (Bernard) Bernard presented the notion of a pre-auth specific timeout attribute. Comment (Yoshiro O): Asks whether the absence of pre-auth attribute should be considered always as a normal session? Answer (Bernard A): It depends. The presence of the attribute in an Access-Request means it is a pre-auth session. However, when absent, it’s not always pre-auth. Need to use RFC3580 behavior. Comment: Asks about key cache lifetime? Answer (Bernard A): Thinks that 802.11i drives the lifetime based on the session-timeout value. Comment (Dorothy S): Validates Bernard’s assertion; states that work on wireless attributes is good to clear up gaps of understanding. Bernard asks how to work with other standards groups on open questions/issues. Comment (Dorothy S): Responds that groups should work with liaison representatives by generating lists of questions/issues. Comment (Dan R): Points out that the discussion a number of times this morning has been topics out of scope of RADEXT, e.g. data format for Diameter’s filter rule, 802.11i discussion. Dan feels we need figure out how not to talk about issues that other groups need to resolve. Comment (Pat C): Looked at RFC 3780. Accounting is not required to go to same server as Authentication. Comment (Bernard A): If you want state, you setup a server that keeps state that both Authentication and Accounting talk to. Comment (Pat C): Does this presume a common backend? Answer (Bernard A): Yes. Bernard presented the SSID attribute. 6. RADIUS Attribute Design Guidelines (Dave N. for Greg W.) Dave presented an overview of document. Dave presented the open issues. Comment (Glen Z): Wondering why use by an independent SDO is an issue. Glen asserts that most SDOs are just looking for IANA code-point numbers. This could be solved by giving blanket permission. Neither Dave nor Glen believe this is good practice. Dave presented RADIUS attribute guidelines (section 7 of the draft). Comment (Glen Z): Believes all problems have been solved over the years. Dave asks in which documents problems have been solved. Glenn feels that problems should be solved just once, if there are existing solutions elsewhere, they should be deprecated. There should be only one solution. Comment (Dan R): Questions whether this document is to be a BCP. Dave says yes, that is the plan. Comment (Dan R): Says same problem happened with MIBs. The felling there was that a guidelines document would make it easier for new people to ramp up on standards development. Comment (Glen Z): Asserts that solutions exist in a protocol called Diameter. He points out that most of the problems in design guidelines were fundamental problems addressed in Diameter. Sees no need to re-solve problems that have already been solved once. Comment (Bernard A): Points out that the guidelines document should strictly be about BCP, not defining new extensions to RADIUS. Dave describes examples of where several new document rely on complex data structures, such as GEOPRIV, where having design guideline document would be (have been) beneficial. Dave opens up discussion to group on how to move forward. Comment (Bernard A): Points out that design guidelines document has taken on two hard problems, BCP and designing new RADIUS protocol extensions (i.e. extended attributes), that will make it difficult to make progress. He suggests that problems be split up into two individual documents. Comment (Glen Z): Agrees with Bernard's suggestion to split up document. Having a BCP would be beneficial. Comment (Hannes T): Says that time is of essence for this document as SDOs continue to make progress and they may use non-optimal designs. Dave asks group to consider the suggestion to remove any references to extended attributes. Extended attributes would be treated in separate effort. There seems to be rough consensus in the room. We will confirm this direction on the WG mailing list. 7. RADIUS Attribute Space Exhaustion (Bernard) Bernard presented summary of RADIUS attribute exhaustion issues. Bernard presented possible outcomes of the discussion. Bernard opened up the discussion to floor to discuss whether solution is desired, where work should be performed, and whether there any other problems to solve. Comment (Pat C): Believes that RADIUS should not be used for new applications, but extensions should be allowed for existing applications. Doesn’t care whether RADEXT tackles problem. Comment (Dave N): Believes the problem should be solved. Believes that SDOs and implementers will continue to use RADIUS even if IETF stops work on it. Believes that the attribute exhaustion solution work should be done in RADEXT. Unsure whether there are any additional problems that need work. Comment (Dave N): Puts out radical suggestion of reclaiming blocks of reserved but ill-defined attribute code-points, such as the experimental or implementation-specific blocks. Bernard says it needs to be investigated. Comment (Glen Z): Says that problems have already been solved (i.e. Diameter). He’s OK with solving problem, again. However, does not feel RADIUS attribute space should be extended. Feels RADEXT is the right place to do the work, if other solutions are thrown out. Comment: Believes that attribute space should be extended, RADEXT is the right place, and does believe extended attributes is the only problem. Comment (Glen Z): Disagrees with Dave N. The IETF has more power to stop people from doing work than we think we do. The SDOs use the IETF to talk to each other and standardize interoperation. If there is no RFC, this will challenge them. Comment: (Pasi E): Repeats Glen’s claim that problem has already been solved. However, feels usage of vendor-specific attributes offers an infinite space. Comment: Points out that allowing on certain applications to use RADIUS and not Bernard does straw poll of group on three questions: Is the problem worth solving? 13 in favor, 6 against Is RADEXT the right place to do the work? 18 in favor, 0 against Should the extended attribute ID space be the only problem to be solved? 6 in favor, 3 against We will confirm this rough consensus on the WG mailing list. Bernard recaps existing proposals. 8. Extended RADIUS Attributes (Bernard A. for Barney W.) Bernard presented the motivation for this work. Bernard presented usage of Diameter AVP format as the extended RADIUS Attribute format. Bernard opens up to the floor for comments. Comment (Glen Z): Mapping Diameter AVP formats in RADIUS brings up the RADIUS PDU length problems. Comment (Dave M): Yes, maybe it is a bad idea in general. But it may work for some things. I think we should start saying things like "This feature is limited, and if that's a problem, use something else, i.e. Diameter". Comment (Dave M): I like the characterization of the issues. This provides a good basis for tradeoffs. We need to make decisions and perhaps say we don't do some of it. Comment (Dave N): This draft is proposing solutions rather than just hand-waving. Asserts that the backbone of RADEXT will be tested on whether to address these problems. Comment (Glen Z): Points out that entire network will have to be upgraded to support Barney’s draft. Questions why it would be easier to force a RADIUS forklift upgrade than going to Diameter. Comment (Dave N): Asks for opinions from RADIUS server vendors. Questions what server vendor will support all functionality. Comment (Bernard A): Points out the fundamental change this draft would have to the RADIUS data-dictionary. We’d be nearly 75% of the way to Diameter if this draft is approved. Comment (Yoshiro O): Believes RADIUS should remain simple and not take on Diameter like parsing. Comment (Joe S): Re-iterates that this draft takes RADIUS nearly all the way to Diameter. Agrees with Glen that this is not good. Comment (Glen Z): It's still possible to do some grouping using tags. Comment (Dave N): Asks the group whether group feels that the RADIUS tagging mechanism is sufficient for all attribute grouping? Bernard does straw poll: How many people favor addressing extended attributes using limited solution proposed by Lior? 8 in favor, 1 against This seems to be a solid consensus of the room. We'll verify this on the WG mailing list. 9. Issues & Fixes (Bernard for Alan DeKok) Bernard presented a summary. Not much discussion. We need to get more people to read the draft and comment on the list. 10. RADIUS Attribute for Management Authorization (Dave N.) Dave presented the background and motivation. Dave presented current attribute proposals. Dave asks group whether document is ready for adoption as a WG work item? Bernard asks how many people have read document? One person in the room has. The obvious outcome is that additional people need to read document and comment on the list. 11. GEOPRIV (Hannes T.) Hannes described the status of GEOPRIV work. Many changes between the current and previous version. Open issue on encoding of location attributes, split complex attributes into two, wrong references corrected and lot of cleanup work. Bernard asks how work should progress towards completion, given it’s been around so long. Decided that next step is that when document goes last call in GEOPRIV that RADEXT should also review document from a last call perspective. Bernard suggests that RADEXT group submit issues prior to GEOPRIV last call. 12. ISMS WG requirements for RADIUS (Dave N.) Dave described motivation for Authorize Only operations. Dave described motivation for an Asserted Identity. Comment (Hannes T): ISMS requirements seem similar to requirements he’s hearing in other groups. Seems similar to the SIP problem. Should look at that. Comment (Dave N): ISMS is interested in RADIUS because it integrates something people already have. Comment (Bernard A): Points out that the document is making a leap by integrating technologies like Kerberos and RADIUS. Questions how these technologies will be re-conciliated. Answer (Dave N): Responds that Jeff H. (Kerberos WG Chair) believes that authentication and authorization services should be split. In his mind, the authentication and authorization services are/should be decoupled and independent. Comment (Bernard A): Curious to hear whether the security considerations hve been investigated thoroughly. Comment (Bernard A): Points out that ISMS requirements seem to violate basic key distribution principles, feels it's very ad-hoc, and changes Kerberos in a fundamental way. Kerberos tickets are bound to capabilities. Bernard would like agreement from the Kerberos WG before ratifying such a fundamental change. Comment (Dave N): This comes from specific deployment requirements in ISMS, and this situation is not an integration of Kerberos and RADIUS. Comment: Kerberos does have optional authorization fields, some may be used or not. This should be looked at carefully. Don't know if anyone does that.... Comment (Joe S): Agrees that additional thought is necessary. Comment (Hannes T): Questions the viability of splitting authentication and authorization services, given that most technologies bind authentication and authorization together. SAML has similar mechanisms. Comment (Dave N): Will take this feedback to ISMS WG and see how they wish to proceed. 13. Wrap-up/final comments Comment (Glen Z): Would like the crypto-agility work item to be clarified. What is the problem, the issues, etc.? The WG should decide to make this into a formal work item, if that is deemed necessary. Answer (Dave N): It is already a WG milestone, but we should look at whether charter language, scope, etc. also needs revision. End of the meeting.