Current Meeting Report
Slides
2.3.2 Authentication, Authorization and Accounting (aaa)
NOTE: This charter is a snapshot of the 53rd IETF Meeting in Minneapolis, MN USA. It
may now be out-of-date. Last Modified:
11-Feb-02
Chair(s):
Bernard Aboba <aboba@internaut.com>
David Mitton <david@mitton.com>
Operations and Management Area Director(s):
Randy Bush <randy@psg.com>
Bert Wijnen <bwijnen@lucent.com>
Operations and Management Area Advisor:
Randy Bush <randy@psg.com>
Mailing Lists:
General Discussion:aaa-wg@merit.edu
To Subscribe: majordomo@merit.edu
In Body: subscribe aaa-wg
Archive: http://www.merit.edu/mail.archives/aaa-wg/
Description of Working Group:
The Authentication, Authorization and Accounting Working Group
focused on the development of requirements for Authentication,
Authorization and Accounting as applied to network access.
Requirements were gathered from NASREQ, MOBILE IP, and ROAMOPS
Working Groups as well as TIA 45.6. The AAA WG then solicited
submission of protocols meeting the requirements, and evaluated
the submissions.
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.
Goals and Milestones:
| 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. |
Internet-Drafts:
Request For Comments:
| RFC | Status | Title |
|
| RFC2924 | | Accounting Attributes and Record Formats |
| RFC2975 | | Introduction to Accounting Management |
| RFC2989 | | Criteria for Evaluating AAA Protocols for Network
Access |
| RFC3127 | | Authentication, Authorization, and Accounting:Protocol
Evaluation |
Current Meeting Report
Minutes of the AAA WG
IETF 53, Minneapolis, MN, USA
March 21, 2002, 1300-1500
Chairs: Bernard Aboba <aboba@internaut.com>, David Mitton <david@mitton.com> (regrets)
Scribes:
Sivasundar Ramamurthy <sramam@cup.hp.com>
John Vollbrecht <jrv@interlinknetworks.com>
Agenda
Preliminaries [15 minutes]
Agenda bashing
Blue sheets
Call for minute takers (2)
Document status
AAA Milestone review
Connectathon Report (David Frascone)
Diameter base draft, John Loughney (10 minutes)
Draft-ietf-aaa-diameter-11.txt
Credit control application, Hari Hakala (5 minutes)
Draft-hakala-diameter-credit-control-01.txt
Mobile IPv4/AAA, Tony Johansson (10 minutes)
Draft-ietf-aaa-mobileip-09.txt
CMS Security, Pat Calhoun (10 minutes)
Draft-ietf-aaa-diameter-cms-sec-04.txt
Transport draft, Bernard Aboba (5 minutes)
Draft-ietf-aaa-transport-05.txt
NASREQ draft, David Spence (10 minutes)
Draft-ietf-aaa-nasreq-09.txt
NASREQ keying issues, Jesse Walker (10 minutes)
Accounting (10 minutes)
Draft-olsson-ip-multimedia-charging-reqs-00.txt
Diameter multimedia application (5 minutes)
Draft-johansson-aaa-diameter-mm-alp-01.txt
Mobile IPv6/AAA (10 minutes)
Draft-dupont-mipv6-aaa-01.txt, Maryline Laurent-Maknavicius
Draft-le-aaa-diameter-mobileipv6-01.txt, Franck Le
AAA WG Document Status
Published so far:
Accounting: RFC 2924, 2975
Requirements: RFC 2977, 2989, 3141
Protocol evaluation: RFC 3127
Previously unpublished docs referenced by RFC 2989
RFC 3141: CDMA 2000/AAA Requirements
RFC 3169: NASREQ Criteria
Completed WG last call with comments:
Draft-ietf-aaa-issues-05.txt (not for publication)
Draft-ietf-aaa-diameter-09.txt (Standards track)
Draft-ietf-aaa-transport-05.txt (Standards track)
Draft-ietf-aaa-diameter-nasreq-09.txt (Standards track)
Draft-ietf-aaa-diameter-mobileip-09.txt (Standards track)
Draft-ietf-aaa-diameter-cms-sec-04.txt (Standards track)
Not yet ready for WG last call:
Draft-ietf-aaa-diameter-api-01.txt (Informational)
Not yet WG work items:
Draft-koehler-aaa-diameter-base-protocol-mib-02.txt
Draft-koehler-aaa-diameter-nasreq-mib-01.txt
WG Last Call Summary
Issue list: http://www.drizzle.com/~aboba/AAA/issues.html
Summary
70 issues raised in WG last call (244 , 313)
49 closed
6 rejected
26 still open
150 issues raised in second WG last call (94 , 243)
93 issues raised in first WG last call
Draft-ietf-aaa-diameter-10.txt
41 issues (67 in previous WG last call)
32 closed (244, 245, 247, 249, 250, 252, 253, 254, 256, 257, 259, 260, 261, 262,
263, 268, 269, 270, 271, 273, 274, 275, 277, 279, 281, 282, 283, 285,
287, 288, 289, 310)
4 rejected (248, 272, 280, 284)
5 still open (218, 302, 303, 304, 311)
Draft-ietf-aaa-diameter-cms-sec-04.txt
8 new issues (42 in previous WG last call)
4 closed (276, 279, 291, 310)
1 rejected (307)
4 still open (218, 278, 312, 313)
Draft-ietf-aaa-diameter-mobileip-09.txt
14 new issues (25 in previous WG last call)
6 closed (250, 264, 265, 266, 267, 286)
1 rejected (292)
8 still open (218, 290, 296, 298, 299, 301, 305, 306)
Draft-ietf-aaa-diameter-nasreq-09.txt
12 new issues (11 in previous WG last call)
6 closed (246, 250, 251, 264, 293, 309)
0 rejected
9 still open (188, 189, 190, 255, 294, 295, 297, 300, 308)
Draft-ietf-aaa-transport-05.txt
1 new issue (5 in previous WG last call)
0 closed
0 rejected
2 still open (199, 258)
AAA milestone review
The chair provided the current versions of the drafts: Diameter Base -09, MIP - 09, CMS - 04, NASREQ - 09, and Transport - 05. He acknowledged that we are a year behind and that our progress, though good, has not been quick enough. He called for the group to read all docs and file issues ASAP; another last call will be issued from 4/2 to 4/16.
Connectathon Report
We forgot about David Frascone's Connecthon Report (sorry, David).
However, he sent in the following notes via email:
From: owner-aaa-wg@merit.edu On Behalf Of David Frascone
Sent: Friday, March 22, 2002 9:19 AM
To: aaa-wg@merit.edu
Subject: [AAA-WG]: Interop Results / Request
Since we ran out of time in the meeting, I thought I'd give a brief synopsis of the testing that occured at Connectathon: No one showed up.
Well, to be fair, there were several Mobile-Ip vendors present that had AAA servers, but none of them supported the applications / extensions that we wanted to test.
On a good note, I was able to get a successful interoperation of Nasreq, over the 'net.
So, here is a synopsis of what has been interoperated:
o Base Protocol
o TLS (only once)
o Mobile-IPv4
o Accounting
o Nasreq (only once, and AAR/AAA only, no DER/DEA)
And, here is what really needs to be hammered on:
o TLS - Since it has only interoperated once, it needs more testing.
o Nasreq - Needs more testing, and DER/DEA needs to be tried.
o CMS Security
o Diameter over IPSec
All of the Nasreq interoperation has been done across the net. Since all of the tests that need to be done are basically point to point exchanges, internet tests should be more than sufficient. (Mobile-IP is very difficult to test when you're not in the same room, but the other tests are not as complex to set up)
So, my request: If you have implemented, or are implementing any of the untested extensions *please* send an e-mail to this list (or to me) so we can test.
-Dave
Diameter Base -09 Draft
John Loughney presented the current status of the base draft (draft-ietf-aaa-diameter-10.xt). The draft needs closure and comments are appreciated.
Interoperability remains the main focus of the draft; new features will need to meet a *very* high bar.
A list of rejected issues with reasons was provided. The presenter called for reviews on DNS usage (section 5.2), Accounting state machine changes (section 8.2), and the split between Diameter URL and ID (issue 286).
As far as security is concerned, the WG would require or strongly recommend Diameter nodes to implement same security mechanism across peer-to-peer connections. If IPSec is used, the node should have mechanism to prevent non-IPSec protected traffic from reaching the node. Also, issues that apply to PKI need to be discussed.
Diameter Credit Control
A new application for Diameter Credit Control was introduced next (draft-hakala-diameter-credit-control-01.txt). While the objective is to support real time cost and credit control, application features include Accounting messages (ACR and ACA) with additional AVPs, and session based credit control. Mailing list messages have suggested need for supporting one-time events like balance check and refund, and spontaneous updates.
An 02 version will be created after IETF53. Some of the open issues include whether a new application-id is required. The Base text needs to be clarified to indicate that a new application id is not required just because some vendor-specific AVPs are used; a new application id is only needed when new commands are introduced or changes to the ABNF. It still needs to be decided whether this will be a new work item for the WG; until the AAA WG finishes current work items it cannot take on new ones.
Mobile IP -09
Tony Johansson presented the current status of the Mobile IP draft (draft-ietf-diameter-mobileip-09.txt). Some of the open issues include ABNF/table inconsistencies, and a new AVP (code: 55) for Event-Time-stamping. Minor corrections in the current draft are regarding the use of FA-Host AVP, and the issue of Session-timeout vs auth-lifetime vs key-lifetime.
Issue #299 concerning MN handoffs was discussed in detail. A couple of solutions have been proposed. One was requiring each sub-domain to have only one AAAH or to have a synchronization mechanism between AAAH servers. The other was require MN to support an updated GNAIE draft that includes the definition of AAAH NAI. Including AAAH NAI will guarantee that the user ends up in the same initial AAAH. Audience supported the second solution and this is currently being pursued with the Mobile IP WG (GNAIE draft may come back!).
Issue #301 regarding securing the AAAH generated keys was another issue discussed. There was a big confusion on whether the WG interpreted the security review of this draft correctly: did the review suggest periodical refreshing of the AAA generated keys or the MN-AAA key itself? This was left unresolved as time ran out.
CMS Security -04
An update on CMS security (draft-ietf-diameter-cms-04.txt) was provided by Pat Calhoun. Changes include removal of left over text, issue of deleting expected AVP and knowing when encryption is needed, removal of restrictions, AVP reordering, and processing of grouped AVPs (new section 1.7).
Transport -05
Bernard Aboba provided a brief status update of the Transport draft (draft-ietf-diameter-transport-05.txt). Some of the open issues are 199, 247, 258. Issue 258 was resolved during the meeting; the issue was whether the client should do a CER or DWR upon a reconnet. The audience pointed out that the state machine does provide the answer for this. Issue 199 will be presumed closed by the rewrite of the transport state machine in -05. Issue #247 was resolved by a change to the Base document. Thus, it appears that there are no currently open issues against this document.
NASREQ-09
A detailed update on NASREQ (draft-ietf-diameter-nasreq-09.txt) was provided by David Spence. A list of issues that are currently discussed was provided.
Bernard Aboba gave a presentation on some of the open issues relating to AAA/EAP. These issues represent areas for clarification within RFC 2869 and thus are not unique to Diameter NASREQ.
The issues included:
1. Should a Reply-Message attribute sent within a AAA/EAP conversation bet transport to an EAP-Request/Notification?
a. What if there is an EAP message attribute and a reply-message attribute in the same AAA message?
b. Will AAA server be expecting an Access-request/EAP-message/EAP-response/notification?
The recommendations here are that the AAA server should send EAP message/EAP request/notification instead of Reply-message. If received, NAS should translate Reply-message to EAP-request/notification. And if an EAP-message is in the AAA packet, a Reply-message MUST NOT be included.
2. Multiple EAP messages in the same AAA message. It was pointed out that the AAA server can do this, but it will violate RFC 2284. The consensus was not to allow this. Same with inclusion of reply-message with EAP message attributes, if translated to EAP request/notification.
3. Some corner issues were also presented and the group felt that bad things should be outlawed rather than have NAS server fix situations that arise from these bad things. Glen Zorn noted that some of the "corner conditions" were in fact OK messages, so we need to refine the list of prohibited message combinations further prior to resolution.
NASREQ Keying
Jesse Walker made a presentation regarding Security issues with the NASREQ Keying Attributes. The motivation for the work is that IEEE 802.11 security does not work and that TGI wants to use AAA servers for authorization and key distribution. But it seems that Diameter NASREQ may not meet TGI's key distribution requirements!
The issue is that the Diameter NASREQ key distribution functionality consists of two two-party key exchanges: one between the AAA server and the client, which is carried out in the EAP exchange; and another between the AAA server and the NAS, carried out via the NASREQ keying attributes. Jesse Walker's concern is that two two-way key exchanges do not equal a secure three-way key exchange.
The Objective is to enhance NASREQ to meet 802.11 key distribution requirements. Some of the discussions on issue prior to meeting involved:
a. Simplification of combining NASREQ state machines with those at different layers of protocol stack.
b. Need for new fields (new AVP) in message exchanges for key distribution between NAS and AS.
The resolution to the presentation is:
a. Jesse Walker and Russ Housley agreed to prepare a draft within 30 days explaining what is wrong with the current NASREQ Keying attributes, and proposing an alternative.
b. The AAA WG will seek the appointment of a security advisor to review the draft and rule on its validity. It was noted that the AAA WG's current security advisor, Steve Bellovin, has accepted the position of IESG Security Area Director, and so is too busy to do the review, so we will need to get someone else.
MOBILE IPv6
The session concluded with a brief presentation by Franck Le on Mobile IPv6 AAA Requirements (draft-le-add-mipv6-requirements-00.txt). Work in AAA Support for MIPv6 is needed in order to enable large scale deployment; also, current Mobile IP application does not apply to MIPv6.
The Draft is result of off-line discussion and it lists requirements of what MIPv6 diameter should support. The status of MIPv6 does not impact AAA MIPv6 work. While the final objective is MIPv6 support, requirements are the first step. The work has been accepted by AAA WG
Slides
Agenda
Requirements for Diameter Support for Mobile IPv6
Diameter Base Specification
Key Distribution Observations
Diameter credit control application
Provably Secure Session Key Distribution- The Three Party Case
3GPP-IETF Status Report
Current Status of 3GPP SIP related Internet Draft dependencies
Diameter Issues
Issues (Text list)
Updates - Issues