2.4.2 Authentication, Authorization and Accounting (aaa)

NOTE: This charter is a snapshot of the 47th IETF Meeting in Adelaide, Australia. It may now be out-of-date. Last Modified: 02-Mar-00


Paul Krumviede <Paul@mci.net>
Bernard Aboba <aboba@internaut.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/html/aaa-wg/

Description of Working Group:

The Authentication, Authorization and Accounting working group focuses on development of requirements for Authentication, Authorization and Accounting as applied to network access.

The purpose behind this is to create a base protocol applicable to a number of specific network access models. These will include Network Access Server AAA, Mobile IP, and roaming. By creating an architecture and set of base protocols, the amount of work to create specific network access AAA protocols will be reduced.

The working group will incorporate requirements provided by the NASREQ, Mobile IP, and ROAMOPS working groups. Once the requirements documents are completed, the working group may be re-chartered to include work regarding the base protocol.

Collecting and satisfying application-layer requirements is not in the current set of AAA WG milestones. However, if a set of agreed upon application-layer requirements can be delivered before the deadline of I-D submission for the next IETF, then such document(s) will/may be considered.

The immediate goals of the AAA working group are to:

- assemble AAA requirements arising from specific network access applications: Network Access Server AAA, Mobile IP, and roaming.

- document requirements for a base AAA architecture;

- identify the relationship and interaction between Policy and Authorization.

Goals and Milestones:

Sep 99


Submit Mobile IP requirements initial Internet-Draft

Sep 99


Submit Accounting Requirements initial Internet-Draft(s)

Oct 99


Submit policy/authorization initial Internet-Draft

Nov 99


Revision of charter to include statement of work regarding the base protocols and data formats.


No Request For Comments

Current Meeting Report

IETF 47, Adelaide, Australia
AAA WG Minutes

Chairs: Bernard Aboba, Paul Krumviede
Recorded by: Dave Mitton

3:30pm, Thursday, Mar 30th, 2000
The meeting started off with agenda bashing. John Vollbrecht agreed to present the IRTF report.

Document status update

We then had a summary of the status of requirements documents:
AAA Network Access requirements is in AAA WG last call
Mobile IP AAA requirements are about to go to Mobile IP WG last call
Nasreq Criteria are in NASREQ WG last call

Accounting documents:
Accounting attributes draft is currently in AAA WG last call
Accounting Management draft is undergoing revision and will go through AAA WG last call again

Dave Mitton then gave an update on the NASREQ requirements document.
Nasreq has updated their Requirements Criteria document per discussions at the AAA Interim Meeting. The new draft has been put out for WG last call.

Tom Hiller made a presentation on TIA 45.6 requested updates to the network access requirements draft.
The issues had to do with a few "shoulds" that TIA 45.6 considered as "musts". It was agreed minor differences would be captured in footnotes for completeness. In all cases there were already "musts" in these rows in the other columns, so these are minor issues.

The items are:

Section 5.1
Data object confidentiality (e): M
Certificate Transport (g): M

Section 5.2
NAI Support (a): M

Section 5.3
RADIUS Gateway (b): M

Section 5.4
Accounting Time Stamps (e): M

PatC: There was a problem when merging the TIA 45.6 column with Mobile IP, because MobileIP has Should for several of these requirements.
Certificate Transport is a Must for TIA 45.6.
NAI Support is also a Must for TIA 45.6.
CharlieP: MIP doesn't require an NAI, since it works without it. Therefore the Mobile IP column cannot have a MUST for NAI.
Tom Hiller: specific scenarios may not require it, but this is required feature for TIA 45.6. So we believe it is a MUST.
Question: Why is CHAP support of Mobile IP optional?
Answer: Because it isn't mentioned in RFC 2002!
Question: Why is RADIUS gateway support optional? Shouldn't this be a MUST?
Shouldn't an accounting timestamp be a MUST?
Question: We took the CDMA2000 column out to simplify the document. Should we put it back in?
Answer: No, just footnotes the differences.
Question: should we have a "phantom" fifth column of existing practices? Is there is anything missing that currrent vendors are using?
Answer: the requirements document does not attempt to encompass all "extended practices", on those that were felt to be important by the NASREQ, ROAMOPS, TIA 45.6 and Mobile IP WGs.
John Volbrecht comments that the requirements were missing a description of encryption groups and aggregation capability.
Paul Krumviede requested that this issue be taken this to the mailing list.

Where do we go next on network access requirements?

The next step of the process is to put the network access requirements document through WG last call again after the requested changes are incorporated, since they are substantive. In general, editorial changes and clarifications will be handled while the group progresses with the new work. We don't want to hold the group from moving forward.

Alan Blount - Accounting Attributes
Pat Calhoun mentioned a number of issues with the DIAMETER section of the draft and promised to send comments on the document to the list before the last call expired.

Dave Harrington discussed the changes to the Accounting Management draft, which focused on use of SNMP for Accounting.

Dave asserted that SNMP was not designed for Inter-Domain accounting, and so figuring out how this could be done is tricky. There may be a way in SNMP v3 to handle inter-domain accounting using contextName. The draft currently discusses use of proxies, contextEngineID (not practical) and using the domain as an index (requires new MIBs). Use of contextName should enable backwards compatibility with existing MIBs, although it does require SNMP v3. The next revision of the draft will cover this.
Since there will be substantitive changes in the -02 draft, the document will go to Last Call again.

Charlie Perkins - AAA in Ipng
Charlie Perkins talked about how Ipv6 mobility might use AAA. He noted that there is no Foreign Agent in Ipv6,and so it is necessary to define mobile node behaviors/mechanisms to establish and control service access in v6 networks. Current thinking is that there is a Mobile Node NAI extension to router solicitation, and a AAA reply included in the Router Advertisement.

Question: Are there any new requirements that came out of this work that would require us to modify the AAA Requirements document?
Answer: it appears not.

There was some discussion on use of DHCP with Mobile IP. This was brought up in the DHC WG. The issue is that the current DHCP authentication draft does not support AAA well, for either intra or inter-domain use. The problem is that the DHCP authentication option requires both the client and server to sign the immutable portions of the DHCP packet. However, the DHCP server cannot typically validate the DHCP authentication option because it doesn't have access to cleartext passwords. Validating this via AAA requires that the DHCP server include the entire DHCP packet since this is required to validate the authentication option signature. The DHCP server must also send the AAA server its proposed reply so that the AAA server can use the password to sign the packet via the DHCP authentication option. This requires more knowledge of DHCP than a AAA server is likely to have.

The same issues were encountered with support for Mobile IP in RFC 2002, which is why we have the mobile node NAI extension and Challenge-Response extensions. Addressing the problem will require that DHCP Authentication support challenge/response authentication. Bernard will work this and other issues with the DHCP group.

Further discussion should be taken to the Mobile IP and DHC WG mailing lists.

Chartering discussion
The proposed new charter focuses on evaluating AAA protocol submissions and deciding whether to base the group's work on one of them or to design a new one. There was discussion on the WG mailing list about how to move up the schedule, since there is still an urgent need for results in AAA WG. Looking at the schedule, IETF 48 is July 30 - August 4, and the submission deadline is July 14, 2000. Since there are various national holidays in July, as a practical matter, it would be necessary to have an evaluation document most complete by the end of June. If a protocol solicitation is sent out soon and protocol submissions were required by mid-late May or early June, this leaves just about enough time to complete the evaluation in time to discuss it at IETF 48. It is hard to see how things can be done faster.

<charter milestones prototype shown by Bernard>

Goal Re-Charter by April
Draft Schedule:
- April ?: Call for submissions
- May ?: Submission deadline (Protocol+ Compliance Description)
- May ?+X: First draft of independent evaluation document
- July 4th; Holiday
- July 14: Submission deadline
- July 30: August 4, IETF 48, Pittsburgh
- August: Selection of protocol or decision to start from scratch
- Sep: WG closes and re-charters

[Editor's note: Subsequently the Submission deadline was set to be June 1, 2000].

David Harrington: We want to make sure that existing protocols are considered and not necessarily a new single protocol be designed. The wording should be changed.

It was noted that the protocol solicitation will require that authors give up change control to the IETF and submit an unqualified RFC 2026 statement. It was also noted that authors should submit a Compliance Description. This will make the evaluation easier. There was discussion on whether submission as an Internet Draft is required.

There were no objections to a charter along these lines. Paul and Bernard will implement.

IRTF RG Report - John Vollbrecht
John Vollbrecht gave a short summary of the IRTF RG progress. There was also a meeting of the IRTF WG at this IETF.

Done - 5: 23pm
Since all work was completed at a single meeting, there was no meeting on Friday.


AAA WG Agenda