Last Modifield: 02/11/2002
This incarnation of the AAA Working Group will focus on development of an IETF Standards track protocol, based on the DIAMETER submission.
In this process, it is to be understood that the IETF does not function as a rubber stamp. It is likely that the protocol will be changed significantly during the process of development.
The immediate goals of the AAA working group are to address the following issues:
- Clarity. The protocol documents should clearly describe the contents of typical messages and the requirements for interoperability.
- Error messages. The protocol should define categories of error messages, enabling implementations to respond correctly based on the category. The set of error messages should cover the full range of operational problems.
- Accounting. The accounting operational model should be described for each type of network access.
- IPv6. The protocol must include attributes in support for IPv6 network access and must be transportable over IPv6.
- Transport. The protocol should be transport independent and must define at least one mandatory-to-implement transport mapping. Other transport mappings may also be defined. All transport mappings must effectively support congestion control.
- Explicit proxy support. The protocol should offer explicit support for proxies, including support for automated message routing, route recording, and (where necessary) path hiding.
- RADIUS compatibility. The protocol should provide improved RADIUS backward compatibility in the case where only RADIUS attributes are used or where RADIUS proxies or servers exist in the path.
- Security. The protocol should define a lightweight data object security model that is implementable on NASes.
- Data model. The proposal should offer logical separation between the protocol and the data model and should support rich data types.
- MIBs. A MIB must be defined, supporting both IPv4 and IPv6 operation.
|Done||Submission of requirements document as an Informational RFC.|
|Done||Submission of evaluation document as an Informational RFC.|
|Done||Submission of design team recommendations on protocol improvements.|
|Done||Incorporation of design team recommendations into protocol submission.|
|DEC 00||Improved protocol submission accepted as an official WG draft.|
|APR 01||Submission of protocol document(s) as a Proposed Standard RFC.|
|RFC2924||I||Accounting Attributes and Record Formats|
|RFC2975||I||Introduction to Accounting Management|
|RFC2989||I||Criteria for Evaluating AAA Protocols for Network Access|
|RFC3127||I||Authentication, Authorization, and Accounting:Protocol Evaluation|
AAA WG Minutes IETF 55 Wednesday, November 20, 2002 at 1300-1500 ========================================= CHAIRS: Bernard Aboba <email@example.com> David Mitton <firstname.lastname@example.org> Minutes: Jari Arkko AAA Issues list: http://www.drizzle.com/~aboba/AAA/issues.html Preliminaries Document Status Diameter Base, Transport and MobileIPv4 Documents have completed IETF last call. Base and Transport have received IESG comments, which are being resolved. AAA WG last call will begin in NASREQ-10 as soon as the archive opens again. Interoperability events There have been no Diameter interoperability events since the AAA WG last met at IETF 53. Diameter Base -- John Loughney http://www.ietf.org/internet-drafts/draf t-ietf-aaa-diameter-15.txt IETF Last call expired on nov 5th. IESG evaluation results are available online at http://www1.ietf.org/IESG/EVAL UATIONS/draft-ietf-aaa-diameter.bal. The main issues are as follows: - John can agree with some of the comments directly and make the edits, on some others we need WG input. - Definitions: need to use non-OS dependent terminology, need to define what "user" means. - Transport issues: Does "RESET call" mean sending a TCP RST or an application layer termination? How many SCTP streams should be created? - Redirect agents: Not clear if these should be application agnostic. Bernard Aboba: In my reading they don't have to be application agnostic, but they can be. - Reserved bits: Shouldn't the spec say that they must be set to zero and ignored upon receipt? - Security: What TLS/IPsec certificates should be used, and are there any specific things that needs to be checked from the certificates. Bernard Aboba: Basic issue is that just authentication through a certificate does not guarantee that the other side is allowed to be a Diameter agent. Text has been proposed on the list. - Why is the flag "MAY Encr" when confidentiality is mandatory? Need to clarify this. - RAA messages: There is some confusion on these messages. Is a nested sequence intended? This issue is still open. - Reordering of accounting records. There's a concern that there is no way to determine that accounting records have been reordered. Proposed solution is monotonically increasing record number. - The definition of end-to-end security needs to be improved, perhaps the right term is "object security". - Is there any end-to-end authorization model provided? How does a NAS know that it will be paid when an authorization comes from five proxies away. Bernard: There is an implicit assumption that the path represents authorization and business agreements. Steven Bellovin: I am concerned that there is lack of explanation on the security architecture for AAA. All the issues are typically easy, except for authorization which is always the hardest problem. Bernard Aboba: I think this is a reasonable request. John Loughney: Should we document this in CMS document? Stephen Farrell: For some questions this is the right document, but not for the authorization. Steven Bellovin: I'm looking for the top-level view. Bernard Aboba agrees to write an introductory section. - A clarification was needed for Vendor ID. - Filter rules: Why are these different from the MIBs and PIBs? John's proposal is to align. Pat Calhoun: I really don't understand why we need to change, NASes support this type of filters. John: I see, this is building on current solutions, may not be reasonable to change. Bernard Aboba: Yes. Finally, the WG agrees that the white space details etc need to be resolved but the formats stay the same. - Is the use of IPAddress as a datatype misleading? Why not use a union of InetAddressType and InetAddress? Does anyone have an opinion. Dave Mitton: This would break backwards compatibility. Pat Calhoun: The issue came up when designing the protocol; separate AVPs for IPv4 and IPv6 would lead to complexity, and we felt this approach was the right one. Bernard: Since have to support backwards compatibility with Radius, we have to have Framed-IPv6-Address AVPs in any case. - DiameterIdentity: should we use OctetString as we do now, or UTF-8? Patrick Faltsrom suggests creating a separate profile for stringrep and how it is used in Diameter. John says this approach sounds quite heavy. Bernard: UTF-8 for this purpose complicates issues and does not allow anything. However, for FQDNs the situation is different and we'll just use whatever IETF has defined FQDN format to be. No need for new work. - IANA has asked an initial registry to be created either in the document or elsewhere. The preference is latter. John volunteers to do this. - The interesting topic is schedule. John promises a new revision before Christmas, and thinks that most issues can be resolved without too much pain. Transport - Bernard Aboba There were several Transport issue, brought up by Steve Bellovin in IESG review. Most are minor. Bernard will work with John Loughney to address issues relating to SCTP stream usage. Diameter MobileIPv4 - Bernard Aboba - http://www.ietf.org/internet-drafts/dra ft-ietf-aaa-diameter-mobileip-13.txt - The two issues that have come up are visible in the ID Tracker and in the Diameter issues page. The first issue is from Bert Wijnen and largely editorial - Steven Bellovin's issue is technical. One issue is the use of 64 vs. 128 bit keys. His bigger problem is that this draft depends on several things which have not been done. He finds it hard to evaluate the draft until the use of the keys has been specified. Bernard Aboba: Luis Sanchez has reviewed draft. How to move forward? Steven Bellovin: I think you are blocked until the security adivisors for both AAA and MIP can take a look at the complete set of documents. Diameter NASREQ -- David Mitton David Mitton went over the remaining NASREQ issues, most of which are resolved in NASREQ-10. This just missed meeting the IETF 55 submission deadline, and is available for inspection at: http://home.attbi.com/~dmitton/draft-iet f-aaa-diameter-nasreq-10.txt As soon as the archive opens again, NASREQ-10 will be submitted, and will go into AAA WG last call. So if you haven't read it already, please do. This draft has been requested by 3GPP2, so it is on the fast track. - Only four people present have read the document all the way through. - Major changes include section reorganization and removal of EAP to another document. Added mapping of RADIUS Acct-Termination-Cause to Termination-Cause AVP. RADIUS interaction section has been updated with VSA handling. Keying AVPs have been removed as a part of issue 355. - Open issues available at the Diameter issue list. Closed issues include 255, 295, 297, 308, 321, 347, 348, 355. Open issues include the following: - Reconciliation of AVP descriptions with RADIUS descriptions. - More proofreading needed - Glen Zorn has checked the status of 355 and there was no discussion. Why has the issue been adopted. Bernard: the split has been made according to request from 3GPP2. He expects the EAP document to pick up the key AVPs, even if they are currently not anywhere. Glen Zorn feels that there are other reasons for these keys than EAP. Bernard explains that we don't put in things just because there might be uses for them. Tom Hiller noted that 3GPP had not requested keying attributes in NASREQ-10. - Is accounting definition good enough? - Pull up more text from RADIUS? - Do the RADIUS interaction rules for Origin-Hopst and Origin-Realm AVPs work as needed? - Clarify User-Password & Tunnel-Password data. - Issues 331, 379, 380, 381. Glen says 331 i.e. ABNF issues is fine, as the ABNF compiles OK. Diameter C++ API, Y. Ohba - http://www.ietf.org/internet-drafts/dra ft-ohba-aaa-diameter-cxxapi-00.txt Y. Ohba presented on the status of the open Diameter implementation. This has merged two previous open source Diameter implementation projects into The Open Diameter Project (http://www.opendiameter.org). The C++ API is part of this, and has been widely downloaded, indicating substantial interest. There has not been much progress on the existing Diameter API recently (this is a WG work item), so work has shifted toward progress on the C++ API. Question: Is there interest in making the C++ API a separate WG work item? Humming indicates that there is not interest in a separate work item for this. Diameter Credit Control -- Harri Hakala - http://www.ietf.org/internet-drafts/dra ft-hakala-diameter-credit-control-05.txt - During last years pre-paid accounting has become very popular. Only SS7-based protocols are used today for this purpose. For this reason there is a need for a new IP-based protocol for this purpose. Current base protocol mechanisms are not sufficient for this kind of protocol. - The specified protocol is general-purpose, not tied to any specific application. - In 3GPP a stage 1 specification exists to show the requirements for online accounting, and this draft follows the principles set out in those specifications. What will happen next is that 3GPP will have a copy of this in its specifications. Question: Is there interest in taking this on as a WG work item? Humming indicated strong interest in taking on this work item. Diameter Multimedia Application - Maria-Carmen Belinchon - http://www.ietf.org/internet-drafts/dra ft-johansson-aaa-diameter-mm-app-02.txt - This draft is to allow AAA operations from SIP proxies. User authentication is include. The draft also includes a function for allocating the serving SIP proxy from an interrogating SIP proxy. The handling registrations and registration termination are also included. - A request was made to make this a working group item. Bernard said that the request will be considered. Steven Bellovin said Allison Mankin is in favor of this. Question: what is the deadline for this. Stephen Hayes: The deadline for this is the Release 6 deadline. MIPv6/AAA - Franck Le - http://www.ietf.org/internet-drafts/dra ft-le-aaa-diameter-mobileipv6-02.txt - Mobile IPv6 is a routing protocol. Additionally, authorization and authentication tasks are required to provide for roaming part of the functionality. The functionality provoided is: - Mobile node authentication - Home agent assignment - Key distribution Question: What does it take to take this on as a AAA WG work item? Bernard Aboba: AAA WG takes on work items that have been vetted by another WG or standards body. So the MobileIP WG would need to complete work on MIPv6 as well as a MIPv6/AAA architecture document before AAA WG could take on this work item. - Comment: Several ongoing attempts at this: PANA, Secure Neighbor Discovery, this draft. Adjourned.