Last Modified: 2004-10-15
| 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 | |
| Feb 05 | 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 |
|
Minutes of RADEXT WG meeting at IETF61
Monday November 8, 2004, 9:00AM-11:30AM Hilton Washington, Military Room Chairs: Preliminaries --------------------------------------------- The Co-chairs presented the agenda. All slides are available from http://www.drizzle.com/~aboba/RADEXT/IETF61/ Blue sheets were circulated. Document status: - Having completed WGLC - 2486bis - SIP authentication - Requiring review - GEOPRIV WG has requested us to review the RADIUS Extensions for GEOPRIV (and some people are doing that already). Preferably this should be stable by December due to 3GPP deadlines. Will go to GEOPRIV WGLC soon. - IPv6 MIB revisions will go to WGLC once we get the submissions - Two documents being evaluated as potential WG work items - Chargeable user identities - RFC 3576 MIBs Milestones: - Some documents are pretty much ready, and some have been worked on for a long time -- we should move fast on those. - If something doesn't move, we interpret that as a lack of interest and drop it. So authors, please keep moving them. Jari Arkko: draft-ietf-radext-rfc2486bis-01.txt ---------------------------------------------- Overview - Passed WGLC - All issues raised in WGLC have been resolved - Three new issues brought up since then - Better examples (#16) - Bernard's review and editorial nits (#15) - Josh's editorial nit (#17 part 1) - Suffix vs. prefix for the home realm (#17 part 2) - All have been addressed, except last one - It was discussed extensively in EAP WG early in this work - Prefix approach works better with unmodified AAA nodes Next steps: - Will submit -02 as soon as submission opens again - Jari thinks it's ready to go to IESG - This is one of the 3GPP R6 dependencies marked as "critical", so it should be stable (approved by IESG) by December - There is one reference to an internet-draft, but that's already in RFC editor queue, so it's not a problem Wolfgang Back: RADIUS Extensions for Digest Authentication (draft-sterman-aaa-sip-04.txt) ---------------------------------------------------------- This is now a WG item, but missed deadline for renaming it. Trying to align the draft with the Diameter application (ietf-aaa-diameter-sip). Response-Auth: - Could not be calculated by RADIUS client alone, so we added a new attribute. - Comment: MD5 might not be acceptable anymore. - Response: This draft is not actually using MD5, just providing support for HTTP digest (which uses MD5). Message-Authenticator: - This is a good thing to do, but RFC3579 is Informational - Added in -04 as "MAY" What's a "secure connection"? - Added some clarifications - Question: What exactly is a secure connection (IPsec, MPLS VPN, ...), and should we rely on the operator getting this right? - Comment: IPsec is used in RFC3579, so using it here should not be a problem. - Comment: It's important that the RADIUS client/server knows that IPsec was used. - Comment: The distinction is that this ID requires application to know that IPSec is being used. That requirement is not in RFC3579. - Comment: RADIUS includes other means to hide attributes besides IPSec. Other documents specify this. IANA allocation - IANA request has been submitted long ago, but received no decision yet. - Comment: It's probably been lost; resend it and CC the Chairs. Review - Chairs: We need people to check -04 and say that it's OK. Silence does not mean WG consensus. - Chairs: We may need a security review, too, considering the issues discussed today. The chairs will contact the Security ADs to solicit reviewers. Farid Adrangi: Carrying Location Objects in RADIUS (draft-ietf-geopriv-radius-lo-01.txt) -------------------------------------------------- Farid presented the history, motivation and overview of the draft (see the slides). The goal is to convey location information to the home AAA server while taking privacy into consideration. This will support location-based authorization, taxation, location-based services, a mid-session method for transfer. It is based on the CoA RFC and reuses existing GEOPRIV work as much as possible. - Question: What exactly does "not sharing the location information" mean, e.g., can RADIUS proxy forward it? Or how the home AAA server can use it? - Response: The policy rules are intended for the home AAA server, and the policy is mostly about passing the information beyond the AAA infrastructure. - Question: About retention: ISPs store accounting records for several years (because they're required to), so how the does the "retention-expires" work in this case? - Response: Most likely the entities are assumed to have business relationships and contracts that deal with some of these issues. - Question: Should the users be setting their own location privacy policies? - Response: This is mostly between operators and based on operators' policy (if an operator needs the location for authorization and accounting). - Question: So this is not about customers, it's about operators? - Response: Yes. - Comment: The location of the NAS often does not have anything to do with the location of the user. The document supports both, and in case of wireless, the radio range is limited. - Comment: Restricting this to only NAS location would simplify the draft and improve understandability. - Comment: The location of the user is important. - Question: Where does the NAS gets the location information? - Response: NAS or AAA proxies are configured with this information. There was discussion about alternative solutions. Since NASes don't in general move, why this could not be solved by some other approach? A table mapping NAS-Identifier to location at home AAA server does not scale in roaming situations (consider 100,000 APs and 10,000 home AAA networks). It's probably better to have this information in one place and send it to home AAA server where it's actually used. Chairs: We've had good discussion here, please continue it on the mailing list. Bernard Aboba (on behalf of Paul Congdon): 802.1 Support Attributes (draft-congdon-radext-ieee802-02.txt) ------------------------------------------------------------------- - Missed the ID update deadline - Not many changes to the previous version - Added VLAN-Name attribute - There as been interest from Trusted Computing Group (TCG) in referencing RADIUS attribute documents, most likely this one and the bandwidth draft. - Work has been slow, a new author should accelerate things - Some people are interested in new Layer 2 filter attributes - Is NIST ever going to speak up about key management attributes? - Paul Congdon would like to get a "design team" to work on this draft, please contact him to volunteer - Question: Does this document replace RFC3580? - Response: No, it adds attributes for 802 stuff that was not covered by 3580, but explicitly stating this might help. - Comment: Some have expressed an interest in working on a RFC3580-like document for IPsec VPNs, "RADIUS usage guidelines for IPsec/IKE/IKEv2 stuff". This would not necessarily define any new attributes, but at least clarify how existing ones should be used. Anyone interested should contact Pasi Eronen. Farid Adrangi: Chargeable User identity (draft-adrangi-radius-chargeable-user-identity-02.txt) ------------------------------------------------------ Farid went through current issues. Issues 13, 14 and 15 are addressed in the most recent draft. There are two open issues: (a) backward compatibility and (b) the lack of general capability negotiation mechanism in RADIUS. We could send a "hint" attribute in the Access-Request message as indication of CUI feature support. There was some discussion about why this draft is needed. The main reason seems to be that currently User-Name is overloaded for both routing and identification. The Class attribute works for two parties, but not so well for multiple parties (like roaming clearinghouses). It seems that the draft needs a better explanation of the problem being solved. Glen Zorn volunteered to send a paragraph clarifying the problem statement to the list. - Question: Clarification about the different identity type prefixes? It seems that the document defines a new number space, but does not say how numbers get added to that space. Chairs: We would like more than two people to read this, and say on the mailing list that they like it and would like it to be WG item. Farid Adrangi: RADIUS Redirection (draft-lior-radius-redirection-01.txt) -------------------------------------- No activity. Chairs: Please review and comment upon the draft. Farid Adrangi: Bandwidth Capability (draft-adrangi-radius-bandwidth-capability-01.txt) -------------------------------------------------- In previous versions of the draft, there was some confusion about what exactly NAS should do with these attributes, e.g. what kind of algorithm it should apply to actually doing something about the traffic, or reserving something, or something. Farid presented the idea of having a general framework that would allow different types of actions. - Comment: A general framework without any concrete mechanisms is not useful. - Response: The draft would define one or two concrete mechanisms as well, but allow others to define more in the future. - Comment: This ID uses structured attributes, which are not very nice in RADIUS. Having separate attributes might be better from RADIUS point of view. - Response: We are running out of RADIUS Attribute ID space. - Comment: It's not clear that this is imminent, and when we do run out, there have been several proposals made on how do extend the ID space. We could pursue one of those proposals, as needed. - Comment: There's probably overlap with QoS-Filter-Rule attribute in the 802.1 LAN Attributes draft. - Question: What is the relationship to Diameter QoS application draft. - Comment: Having something very simple would probably be better than something complex and general. Jari Arkko (on behalf of David Mariblanca): EAP lower layer attributes (draft-mariblanca-aaa-eap-lla-01.txt) ---------------------------------------------------------------------- Jari presented the approach (see slides). - Question: Do we want to just know the physical layer used to carry EAP, or tell the difference between what kind of service the user is using? - Response: The main goal was to tell the difference between 802.1X and IKEv2 cases, and allow policies like "this user can use 1X but not IKEv2". -Comment: Using Service-Type or some other attribute might be more appropriate. Chairs: It seems that several people are interested in NAS-Port-Type and/or Service-Type usages. It would be good if they can get together and review the alternatives. Volunteers: Glen Zorn, Pasi Eronen, Jari Arkko. Chairs: MIB work ---------------- RADIUS and RADIUS Accounting MIBs. An IPv6 MIB update was intended for this meeting, but was delayed. The work is straightforward. MIB doctor review and input will be sought for the MIB updates, once the drafts are available. RFC3576 MIB. (draft-decnodder-radext-dynauth-server-mib-01.txt) Murtaza Chiba was not present. We should proceed with this work, as it is in the charter. Will seek volunteers to review the current draft, and seek MIB Doctor review, as well. The meeting ended about 11:00AM. --------------------------------------------------------------------------- |