Last Modified: 2003-01-22
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.|
|Done||Submission of AAA Transport as a Proposed Standard RFC|
|JAN 03||Submission of Diameter Base as a Proposed Standard RFC|
|FEB 03||Submission of Diameter NASREQ as a Proposed Standard RFC|
|JUN 03||Submission of Diameter EAP as a Proposed Standard RFC|
|DEC 03||Submission of Diameter CMS 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|
Minutes of the Authentication, Authorization and Accounting WG (aaa)IETF 56, San Francisco, CA Wednesday, March 19 at 1300-1500 ================================= CHAIRS: Bernard Aboba <email@example.com> David Mitton <firstname.lastname@example.org> Scribe: Jari Arkko <email@example.com> 1. Agenda Bashing & Administrativia No comments. 2. Document status The document status is as follows: - Diameter BASE-17 and TRANSPORT-12 are in the RFC Editor queue. - Diameter MIPv4-13 has completed IESG review, but is held waiting for an author update, as well as completion of the MIPv4/AAA keys draft, which has just been updated. - Diameter NASREQ-11 completed AAA WG last call. Five issues remain open. - Diameter EAP and CMS are in progress to be published in June and December, 2003. We are probably going to split key attributes from EAP to a separate draft to give more focus to the work. - New working group items include documents for Diameter key wrap, credit control, and multimedia. 3. Diameter NASREQ, David Mitton (10 minutes) http://www.ietf.org/internet-drafts/dra ft-ietf-aaa-diameter- nasreq-11.txt The latest draft was published Feb 14th. Changes in draft 11 include the fo llowing: - Issues 389 and 395 have been closed. - Sections renumbered so that the outline is flatter. New issues have been filed against draft 11: 402, 403, 404, 405, 406 Most serious things relate to RADIUS compatibility with ability to fallback to RADIUS-only AVPs from either the server or client side. The next steps for this document are: - David comes up with proposed changes and sends them to the mailing list . - New issue acceptance to be closed soon. - New draft version to be published with the next month and be sent to the IESG. 4. Diameter Credit Control Application, John Loghney (10 minutes) http://www.ietf.org/internet-drafts/dra ft-hakala-diameter-cr edit-control-06.txt This draft will become a AAA WG work item after addressing initial review comments. The motivation for this work is on-line/prepaid accounting, which is popular in mobile networks. The draft enhances Diameter base accounting messages with new AVPs, but there are no new messages. This work has been officially included in 3GPP specifications TS 32.225, which can be viewed at the 3GPP web site (www.3g pp.org). Major changes in draft version 06 include: - A server or client is not required to implement all functionality. That is, the M bit settings have been changed. Question: The 'M' bit does not reflect whether an AVP is mandatory to implement or not -- just whether a Diameter peer can discard it if it is not supported. Is the Credit Control using the 'M' bit cor rectly? - New result code has been added. On the to do list there are the following items: editorial improvements, ID nits check, and working with 3GPP to ensure that it fits their needs. This may be possibly nearly ready for WG last call. Bernard Aboba: It is essential to get many reviewers. Can we get 3GPP comments on this? John: Yes, the intention is to request a "3GPP last call" and ask for comments to be sent to the IETF AAA WG list. Comments from IETF and other groups are solicited as well. Next steps for this work are: - Get reviews, address comments. - Issue a new version as a WG work item. 5. Credit Control and Prepaid Applications, Avi Lior (10 minutes) http://www.ietf.org/internet-drafts/dra ft-lior-radius-prepai d-extensions-00.txt Avi Lior, Bridgewater systems, talked about his draft on RADIUS prepaid extensions. Prepaid data services are very important to 3GPP, 3GPP2, and WLAN. AAA infrastructure is central in these services. 3GPP2 and WLAN rely on RADIUS-based infrastructure. Deployment is happening today. Requirements for these services include service portability and continuity, no revenue leakage, support for multiple sessions, and support for different prepaid schemes. Good picture of the requirements in draft-francis-prepaid-00.txt. Bernard Aboba: What does "no revenue leakage" mean? Avi Lior: If there are errors in the network, you want to make sure that you don't give free service. Bernard Aboba: Is this the same as reliability of accounting? Avi: Roughly speaking yes it is. Bernard Aboba: Who created the requirements draft, does this come from some standardization organization? Avi: The requirements draft is not related to our work. One major difference in the approach of RADIUs pre-paid is that this is handled with authentication/authorization messages, not accounting messages. The Access request includes the prepaid operations and quota allocation. Additional quotas can be allocated using accounting messages, a new Access Request, or the use of RADIUS dynamic authorization [draft-chiba-radius-dynamic-authorization-07.txt]. The former two mechanisms are problematic in large networks. When the prepaid account runs out, the session is not directly terminated, but rather the user is directed to a web site to where he can, for instance, use a credit card to continue the use of the account. Bernard Aboba: Is RADIUS - Diameter translation for this application feasible? Avi Lior: We need to look at this. Bernard Aboba: So we do have a problem with this? Avi Lior: The fact of life is that Diameter and RADIUS need to live side-by-side for a long time. If translation is not possible it is going to be a problem. 6. Diameter Multimedia Application, Miguel Garcia (10 minutes) http://www.ietf.org/internet-drafts/dra ft-belinchon-aaa-diam eter-mm-app-00.txt This is a diameter application tailored for the 3GPP IP Multimedia Subsystem. Provides SIP servers with authentication, authorization, and accounting functionality. Includes 6 new commands and a few AVPs. This is an evolution of draft-johansson-aaa-diameter-mm-app-02.txt, and is a solution for draft-i etf-sipping-aaa-req-02.txt. John Loghney: I was going to be mention that draft-ietf-sipping-aaa-req-02.txt is in WG last call. It is going to be discussed in the SIPPING meeting as well right after this meeting. Next steps for this work are: - Get reviews, address comments. - Issue a new version as a WG work item. - Decouple from SIP procedures Bernard Aboba: Here too we will need significant review prior to making this an official WG work item. 7. Diameter Session Mobility, Dan Forsberg (10 minutes) http://www.ietf.org/internet-drafts/dra ft-liu-aaa-diameter-s ession-mobility-00.txt Diameter base protocol can only handle static sessions, it can not handle session mobility. Diameter MIPv4 application suggests that a new session should be setup when movement happens. Dan's draft has a requirement that movements must be possible without causing any actions in the home network. Problem is that when movement has occurred, how does the home AAA send unsolicited messages to the foreign AAA? James Kempf: Why does the home AAA server have to do it? Dan Forsberg: There is AAAF on the picture as well, it is involved. The AAA mobility problem can be seen as a context transfer between two local AAA servers. Question: Why isn't the context transferred between access routers, rather than between AAA servers? Is this because of the difficulty of doing such transfers between providers? James Kempf: There's a lot of roundtrips in this protocol. Should this happen before, during, or after handover? Dan Forsberg: This is an open issue. James Kempf: Could the two AAA nodes act as Diameter peers and not go through proxies higher in the AAA hierarchy? Dan Forsberg: It may be possible but then the old access router would have to know the address of the new access router. Question: Can't this be learned through an inter-access point protocol ? James Kempf: It would be desirable to avoid additional roundtrips and just have the two access routers discuss with each other. Anyway, this is just something to think about. Dan: Yes. Someone: Is this mainly for Mobile IPv6 or for IPv4? Is this for foreign agents or for access routers? Can this be used in the co-located case? Wouldn't it be a problem if the both access router and foreign agents are used at the same time. If co-location is not used, then both would be handling AAA and it seems like a conflict would result. Jessie Walker: One advantage of the hierarchical approach is that it allows the security properties to be stated. One can't pass around keys directly and maintain the desired security properties. Open issues: - Security - Performance and scalability - Session updates between two different domains - Relationship with mobility protocols - Race condition requirements described in the draft Next steps: - Further study with the Diameter MIPv4 application. - Performance measurements 8. Diameter APIs, Yoshihiro Obha and James Kempf (10 minutes) http://www.ietf.org/internet-drafts/dra ft-ietf-aaa-diameter- api-03.txt http://www.ietf.org/internet-drafts/dra ft-ohba-aaa-diameter- cxxapi-00.txt No one to present this. 9. Diameter Mobile IPv4, Tony Johansson (10 minutes) http://www.ietf.org/internet-drafts/dra ft-ietf-aaa-diameter- mobileip-13.txt No one to present this. Someone: I had a question on MIPv4. About nine months ago issue 326 was filed, but as I recall it hasn't been resolved. The Mobile IP WG should answer the issue but they have not done so yet. Bernard: Your issue is not listed as open. Checking the list, it says the status is Rejected. Jari, do you remember anything about it? Jari Arkko: No. Bernard Aboba: Why don't you ask this question on the list? Maybe someone will remember. 10. Diameter CMS, Stephen Farrell (10 minutes) http://www.ietf.org/internet-drafts/dr aft-ietf-aaa-diameter -cms-sec-04.txt No one to present this. 11. Issues in AAA Key Distribution (20 minutes), Russ Housley http://www.ietf.org/internet-drafts/dr aft-walker-aaa-key-di stribution-00.txt Bernard Aboba: Let me start with some sobering facts: no AAA application supporting key distribution has ever been approved as an IETF Proposed Standard. RFC 2548 is Informational and vendor-specific. Diameter MIPv4 is blocked due to security issues. No progress on Diameter EAP or CMS. So the question is: What does AAA WG need to do in order to make more progress? Are there aspects of the problem that we have missed? What criteria does the IESG expect us to meet? To answer these questions we have invited Russ Housley, the incoming security area director, to give us some adv ice. Russ Housley: Some people are concerned that working group outside the security area is designing a key management protocol. Why? - Key management protocols are subtle. - An expert can easily miss a flaw. - Peer review by multiple experts is essential There are also concerns with EAP: - Employs new key distribution architecture, with poorly understood security properties. Three party models have been studied but these do not align directly with AAA. - Select one e2e mechanism to protect distributed keys. - Needs robust key naming scheme. - Needs to establish fresh session keys i.e. not get the same key every time. - The principle of least privilege not followed. That means the session keys should not be exposed to parties that do not have an absolute essential reason to see the key material. An acceptable solution MUST: - Be algorithm independent. For interoperability, select at least one suite of algorithms that MUST be implemented. - Establish strong, fresh session keys. Maintain algorithm independe nce. - Include a replay detection mechanism for all exchanges. - Authenticate all parties. Maintain confidentiality of the authenticator. Public key mechanisms could be used to send keys so that only the recipient who has the private key can come back with the sent key. No plaintext passwords. The solution MUST also: - Perform client and NAS authorization - Maintain confidentiality of the session keys. - Confirm selection of the "best" ciphersuite. - Uniquely name session keys. - Compromise of a single NAS cannot compromise any other part of the system, including session keys and long-term keys. - Bind key to appropriate context. To me, the question is what's next. This was what the requirements are and Bernard tells you more about how to get this done. Someone: You mentioned EAP, will you reject EAP as well before it solves these problems? Russ Housley: No, that's not what I meant. These issues will be presumably addressed in the EAP Keying Framework draft being worked on in EAP WG. Bernard: Where do we go from here: - We need a fresh start on Diameter MIPv4. Look at the whole system. Make it clear how to meet the requirements articulated by Russ. - We need an EAP key framework document. This will describe the architecture and security requirements for each element of the system and analyze how they interact. It will also address key naming and binding issues. This is being done in the EAP WG in draft-aboba-pppext-key-problem-06.txt. The next revision will attempt to address Russ's requirements explicitly. - Split out Diameter key wrap into separate document from Diameter EAP. This will allow more focus in this critical part of the document. - Take a fresh look at Diameter CMS. Can we remove deployment barriers? Can we decrease complexity of the specification? Any implementation plans? Anybody want to comment on the barriers? Jessie Walker: I think it's a curiosity. Is anyone going to implement Diameter CMS? If not, then why are we working on it? Robert Moskowitz: I have a question. I'd like to know if there's any performance measurements that have been done with the Diameter CMS application? Its not very lightweight. It would be very worthwhile to get some numbers. Bernard Aboba: Would the CMS numbers from pure CMS (not Diameter CMS) implementations be sufficient? Robert Moskowitz: Not sure. Russ Housley: the S/MIME group is doing interoperability tests and there should be at least 4-5 implementations for which you can get some performance data. Jessie Walker: What comes to my mind is mainly the complexity. If its too big for embedded implementations, it's the wrong specific ation. Paul Funk: I suspect people are sufficiently happy with hop-by-hop security. Once Diameter starts to carry money in some format, then its an issue. Bernard Aboba: But we do already have usage-based billing. Paul Funk: Yes, if there would be attack that can be used to cause an incorrect bill to be sent. Bernard Aboba: If you have an untrusted proxy handling accounting records and it is compromised, it can forge accounting data. Isn't that enou gh? Randy Bush: I just wanted to remind the WG that not everybody is happy with hop-by-hop security. I have been warning about this before. And we are now paying for the proxy architecture, and we are unhappy. But we are far less unhappy than if the kind of attacks just were discussed were to happen . Russ Housley: I wanted to clarify that the first slide was not a reason to say "STOP", but rather to make sure that the security area is invo lved. 12. Any Other Business Francis Dupont: Now, Mobile IPv6 is ready. I propose to resume the work on AAA and Mobile IPv6. Bernard: Need to talk about this with the Mobile IP WG chairs. Meeting adjourned.