Last Modified: 2003-10-24
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 | |
Done | Submission of Diameter Base as a Proposed Standard RFC | |
Done | Submission of Diameter NASREQ as a Proposed Standard RFC | |
Apr 04 | Submission of Diameter EAP as a Proposed Standard RFC | |
Apr 04 | Submission of Diameter Credit Control as a Proposed Standard RFC | |
Apr 04 | Submission of Diameter SIP application as a Proposed Standard RFC |
RFC | Status | Title |
---|---|---|
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 |
RFC3539 | PS | Authentication, Authorization and Accounting (AAA) Transport Profile |
RFC3588 | PS | Diameter Base Protocol |
Authentication, Authorization and Accounting WG (aaa) IETF-58 meeting minutes Date: Thursday, November 13 at 1300-1500 Chairs: Bernard Aboba <aboba@internaut.com> David Mitton <david@mitton.com> John Loughney <john.loughney@nokia.com> Scribe: Jari Arkko <jarkko@piuha.net> Diameter NASREQ, David Mitton ============================= The URL for this draft is http://www.ietf.org/internet-drafts/dra ft-ietf-aaa-diameter-nasreq-13.txt The current revision is -13, published last month. The document has been in the WG last call during the whole year! Draft 13 incorporates the following modifications: - Issues closed: 416, 417, 418, 423, 425, 426, 428. - Removed references to CMS. - There has been some code point updates. - Accounting-Auth-Method AVP was added. - Yet more work on RADIUS interactions was done. - Additional reference updates were made. Issues pending are: - Issue 430 - 3GPP comments, mostly editorial - Issues 427 & 431 - Identities in RADIUS translation. The issue was filed by Pasi Eronen. Next steps for the document are finishing this document -- no more issues are accepted unless they are serious. We are awaiting for IESG review comments. Glen Zorn: I'm puzzled because this is draft 13. In draft 11, you said this is past WG last call. It seems to be a pattern that they are WG last called, and three years later they go to an IESG review. I would ask the WG to respect the WG last call. Bernard: There is no requirement that there's just one WG last call, if there's substantial issues found in one WG last call. The current comments -- such as those from 3GPP2 -- are IETF last call comments, not WG last call comments. Randy Bush: Do you have trouble with the actual changes? If not, lets get back to work. Bernard Aboba: By the way, have you Glen Submitted any last call comments. Glen Zorn: No. Diameter EAP, Pasi Eronen ========================= The URL for this draft is http://www.ietf.org/internet-drafts/dra ft-ietf-aaa-eap-03.txt This documents the combination of RFC 3579 (RADIUS EAP) for Diameter, and the addition of keying AVPs for Diameter. The document may be dependent on the results of the EAP keying framework document (draft-ietf-eap-keying-01.txt). There is no technical dependency, but the security considerations of the whole system are described in the EAP draft. A couple of small changes have been done since Vienna: - Removed EAP-MTU AVP (issue 435) - Rewrote the security considerations section as a shorter section, relying more on the EAP keying framework draft (issue 437) - Changed the AVP numbers to TBD. THe main open issue is how to transport keys, what kind of AVPs are needed. The alternatives are: - A simple MSK AVP - More complex AVP for separate uplink/downlink keys and so on - Including even the initialization vectors Another open issue is the authorization step. The -02 draft added a mechanism which allows the authorization AVPs to be retrieved via a separate step, if redirects are used and the usual proxy chain mechanism can not be used. Sense of the room: Is it necessary to support two conversations: one between the NAS-home, and another via the proxy chain? Pro: 1, Against: 0. One abstained. Next steps for this document is to see whether the EAP keying framework document puts now requirements for this document. Hopefully we can achieve WG last call soon. Bernard: One issue is that keys may be at least 64 bytes, not necessarily exactly 64 bytes. Diameter MIPv4, Pete McCann =========================== Pete presented this draft on the behalf of Tom Hiller who could not be here this time. The URL for this draft is http://www.ietf.org/internet-drafts/dra ft-ietf-aaa-diameter-mobileip-15.txt The purpose of this draft is to support MIPv4 registration both for foreign-agent care-of address and co-located care-of address modes of operation. The biggest issue is that we should not expose distributed keys to entities that don't need to see them, such as intermediate Diameter agents. The basic solution for this is done in the same manner as the Diameter EAP application works. But after this was done, it resulted in it being hard to support one existing feature in the document. But there appears to be no requirement from 3GPP2 for this feature. The security mechanisms work using a Redirect server that allows the FA to establish a direct TLS connection to the home AAA server. Steven Bellovin has reviewed the document and has raised a number of issues: - How is the preconfigured shared security association defined? The document has been clarified. - What are the rules on firewalls mentioned in the document. The response is that the firewall part has been ruled out of scope for this document. - Key length has been increased from 64 to 128 bits. - Unclear how the FA and HA know and authorize each other. The response for this issue is the direct TLS connection between the FA and the home AAA. The remaining issues for this document are: - Who actually picks the SPIs? Changed from the home AAA to the foreign agent. - Can the foreign AAA server also act as a redirect server? Bernard: I would agree there is no need to delete the possibility that intermediaries can act as redirect servers. But the document should be clarified. - Issue 445: Radia Perlman's review. The authors wish that the review could be finalized. In Radia's preliminary opinion the document is incomprehensible. The authors will rewrite the introduction. She also complained that intermediaries will see the keys. But the TLS redirect scheme will prevent this from happening. Pasi: I have serious objections to the terminology used. The three keys are not all keys, two of them are nonces. Pete disagrees, thinks the keys are still keys and have to be distributed. Pasi thinks that some AVPs are nonces. Bernard: This issue has been raised before, lets take it offline. Pasi: Key material is what you keep secret, nonces can be public. Bernard: From a technical point of view, we are through WG last call, IESG review, and now we have gotten another review. We need to address the IESG comments, and then we can ask whether we have addressed them in a satisfactory manner. Diameter Credit Control Application, John Loughney ================================================== The URL for this draft is http://www.ietf.org/internet-drafts/dra ft-ietf-aaa-diameter-cc-01.txt This draft started as an individual draft from 3GPP, and has gone through several revisions before becoming a working group draft. The draft is its official working group version 01. The main changes since -00 document are: - Graceful service termination has been added (issue 419). - Abnormal-Termination-Reason AVP (issue 433) removed. - Separation of sent and received bytes was provided. - Failover procedures were updated - Cost-information AVP was enhanced. - Missing message flows for refund and price enquiry were added to the appendix. - And so on The open issue which still need to be addressed are: - Update of the security considerations section based on Jari Arkko's comments and Pasi Eronen's work in the Diameter EAP application. - A tarif change principle has been agreed, but not specified yet. - A re-authorization trigger scheme will also be needed. Since the document is getting large, a feature freeze is suggested. The remaining issues need to be solved, and an editorial clean-up is needed. Then a decision has to be made whether the draft is ready for WG last call. John has been informed that a couple of implementations are being worked on. 3GPP has also asked the IETF to finalize this document. Diameter SIP application, Pete McCann ===================================== The URL for this draft is http://www.ietf.org/internet-drafts/dra ft-ietf-aaa-diameter-sip-app-00.txt Pete presented the Diameter SIP application on behalf of Miguel Garcia-Martin who could not be here this time. This draft is designed to support SIP applications in their AAA functions. It defines six new commands, and the authors think it satisfies the requirements laid out for it. Pete continued the presentation with an architecture picture that shows how this draft can be used in the 3GPP IMS model. The changes from the last version are: o New name for the application to show that is a general SIP related AAA application. o Some definitions and an applicability statement were added. o Some AVPs were renamed. o MAR command can now be used in a more generic fashion. o Some new scenarios were added to highlight that this can be used many environments, not just the 3GPP one. o The IANA section has been touched up. Next steps for this document include resolving the four pending issues, add clearer description of the semantics of the commands, add a missing security considerations section, provide support to use SIP and Diameter in conjunction of authentication methods that use HTTP Digest, and perform a full review. Wolfgang Beck: Is there a plan to add media routing accounting? Pete: Accounting is not in the draft. We need to have a discussion about that. o Multicast Security, George Gross This is a talk George made on monday in the MSEC working group. What motivates the combination of MSEC and AAA is large scale secure multicast groups that cross administrative domain boundaries. It is necessary to enforce contractual relationships, and to allow the service providers to control their multicast transit routing service. MSEC AAA would also enable dynamic MSEC groups with the service provider AAA as the broker. Background reading for this document include: - Diameter base, RFC 3588 - Generic authorization framework, RFC 2904 - Diameter NASREQ - Generic policy token draft (draft-ietf-msec-gspt-04.txt which will be submitted within a couple of weeks). This document defines a signed policy object that defines who is allowed to enter the group. The work is based on two different modes: the GDOI/AAA and GSAKMP/AAA models. The GDOI pull-based roaming model. Here Diameter NASREQ and Diameter MSEC are used between two domains. Diameter AAA server sends information to the domain's GC/KS (Group Controller / Key Server), which manage the multicast clients via GDOI. A minimal amount of extensions are needed for the NASREQ application to support MSEC. Alternatively, credit control application could be used; this needs to be looked at. The GDOI/AAA approach can leverage an existing IKE/ISAKMP AAA. Bernard: How would the identity used in either IKE or MIKEY relate to this? George: That's a tough question. Bernard: Can this be an authorization-only mechanism? George: I wouldn't characterize this like that. The model that is being considered by MSEC is the GSAKMP push-based AAA model. This is quite different from the pull model. The domains would use only Diameter accounting between themselves in this case. In GSKAMP/AAA, the authentication is based on PKI only, not NAIs. Multicast policy token encodes membership authorization, acts as AAA service ticket. This does not fit the Diameter NASREQ model, but uses Diameter backend for accounting. The future direction of this work involves the definition of a generic polocy token attributes to encode multiple service authorizations. Long-term, Diameter extensions could be defined for MSEC. Bernard: It seems that there are some deployment problems in multicast services that you are trying to address. George: Currently, there is not much multicast services deployed, but you can imagine some services such as gaming that could make this commercial. bernard: The reason I ask is that there's been more interest in other groups to look at the authentication issues, what you seem to define is looking more at what is requirement for deployment. Bernard: Have you talked to the MAGMA group? George: Not yet, but would like to get them involved. Roadmap (15 minutes) WG Chairs and ADs ====================================== The first AAA meeting was held in March, 1999. The proceedings of that meeting show the milestones to all complete in 1999. The sign of success it to get the protocols done and deployed. Some implementations are being worked on, and even some prototype deployments are being done. The proposal is to have the last AAA WG meeting in Seoul, Korea, in March 2004. The Diameter EAP and cost control drafts can be revised and WG last calls can be started. Then SIP AAA needs to be worked on to get it to be ready for WG last call. Creg Webber: Has the MIBs charter item been dropped. John: Yes. Are you volunteering. Greg: No. John: The IETF will not work on MIBs unless there is interested folks to work on it. Pete McCann: What happens in the future? Would future applications transition to the application WGs. Someone: just run a AAA extensions BOF. Pete: But do we have to do that, for instance, in the case of QoS authorization protocols? John: It would be possible to handle them in the specific application area. Bernard: The suggestion is not to end the AAA WG, just that it should go dormant. Bernard: There's been a general question of whether all AAA work in the IETF should be done here. The general answer is no. John: Is this proposal acceptable (some amount of humming). Is this proposal not acceptable (no one hums). Meeting was |