Current Meeting Report

2.3.2 Authentication, Authorization and Accounting (aaa)

NOTE: This charter is a snapshot of the 52nd IETF Meeting in Salt Lake City, Utah USA. It may now be out-of-date. Last Modified: 03-Dec-01
Bernard Aboba <>
David Mitton <>
Operations and Management Area Director(s):
Randy Bush <>
Bert Wijnen <>
Operations and Management Area Advisor:
Randy Bush <>
Mailing Lists:
To Subscribe:
In Body: subscribe 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.
Request For Comments:
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
Salt Lake City, UT

Bernard Aboba <>
David Mitton <> (absent)

Minute takers:
John Vollbrecht <>
La Monte Yarroll <>

Monday, December 10, 2001
1530 - 1730 Afternoon Session

Preliminaries (15 minutes)
Agenda bashing
Minutes & bluesheets
Document status
WG Last Call Report
Bakeoff Report

DIAMETER Issues, Pat Calhoun (20 minutes)

DIAMETER APIs, James Kempf (10 minutes)

Diameter Base & NASREQ MIBs, J. Koehler/M. Eklund (20 minutes)

Transport draft, Bernard Aboba/Steve Rich (10 minutes)

EAP keying issues, Bernard Aboba (15 minutes)

WG Last Call Report - Bernard Aboba

150 issues raised in WG last call
13 rejected
128 resolved
9 still open

- Where are we?

Issue count has risen from the previous last call (which brought up 92 issues).
This is explained largely by the bakeoffs, and more advanced status of implementations. This is not necessarily a bad thing -- it indicates that people are implementing the drafts, finding issues. Diameter base and mobile IP interoperability has been demonstrated to some extent -- so the protocol works!

Once over this hump, issue count will probably decline markedly in subsequent last calls.

Still, at the current pace, we might need several last calls. Given the cycle of last call, draft fixes, another last call -- getting docs to the IESG could drag out until Spring, RFC issuance into summer or even fall.

That would not be a pleasant experience for anyone.

Mush mush! Pick up the pace. Bernard proposes a short intense period of pain -- another WG last call to flush out issues, discussions with IESG to understand meta-issues, followed by large scale effort to ready drafts for the IESG. Goal is to short circuit one or more additional WG last call cycles, save ourselves a month or two in the process -- and likely cycles of IESG comment and review.

NB: The RFC editor is now requiring separation of informative versus normative references. So these changes should be made prior to submission of documents to the IESG.

Game plan:

1. Completion of Diameter protocol development
Results are URGENTLY needed (we have implementations going out into the world).

2. Process
Focus on last call comments at IETF52
Review WG last call comments
Confirm proposed resuolutions
Discuss and resolve "still open" issues
Verify consensus on the mailing list

3. What else can we do to pick up the pace?

The danger at this point is that the working implementations are attractive to people who are going to start using these in the field.

Bakeoff Report - Tony Johanssen

3rd Diameter bakeoff, held at Ericsson facility in Berkeley, California

- 11 vendors registered
- 5 attended (after 9-11-01 tragedy)

Found 30 issues. Complete report is at:

Bakeoff had implementations of all drafts except cms-sec:
Base, NASREQ, MobileIP, transport.

However, there were only two NASREQ implementations and interoperability was not demonstrated between them.

A lot of the issues came out of the bakeoff, and there will probably be another one sometime in the future. This will be helpful to demonstrate interoperability of CMS security, NASREQ.

Possibility of "Internet bakeoffs" was discussed -- putting Diameter servers and clients on the Internet for testing. It is difficult to test Mobile IP/AAA this way. Seems unlikely that there will be much Diameter interoperability testing at Connectathon.

Diameter Status -- Pat Calhoun
draft-ietf-aaa-mobileip-08.txt Pat

9 issues remain open

Major issues addressed:

Issue 95: Remove support for proxies that hide the internal AAA
Issue 117: R7 included a reverse path which we just removed
Issue 173: failover algorithms
remove the text from the base protocol and use the transport doc
Issue 208: Lost election response is simplified
Issue 220: The protocol allows for dynamically loaded and removed
applications. You can now send CER and CEA at any time, not just at start up.
Issue 146: CHAP algorithm was inconsistently used

Issues 188-190 (marked open in Bernard's list):

Issue 188: It should be possible to send a bare session key w/o binding.
Issue 189: New AVP for keying.
Issue 190: No way to know if key was master session key or session key.

MIP Application
Issue 148: Editorial but significant
MIP works by generating two different kinds of key blobs (keys vs key material)
Issue 186: Session keys were tied to the Authorization-Lifetime AVP new AVP for key lifetime
Issue 203: HA in foreign networks.
Issue 212: What happens if the AAAH gets registration request w/no URI?
Issue 223: HA allocated in FN, AAAF can not specify URI of HA.

CMS Application
Counter signatures was a big issue
Issue 136: Agent may cache info from a previous DSAR and apply them to a PDSR.
Issue 149: When should a device cache/revalidate?
Issue 165: Unclear on how to deal w/TTL settings, when an agent wishes to enforce a lifetime on the access device
Issue 170: "This is one of the biggest issues covered."
1. What happens when the peer's policy disagress with the node's behaviour?
2. Although issue resolved, we did it by eliminating issue in draft.
Issue 180: removed feature
Issue 199: Missing counters in failover
"Issue 221 is what we need to talk about."
Two AVPs that contained the local policy.
Does anybody object? Silence.
Does anybody not care? Silence.
Does anybody agree? 1 person

The current draft has a table stating which AVP's should be encrypted and which should be signed.
Is this ok? Very little noise.

How many people believe we need an overly complex mechanism to say which are which?
No voices at all.

LET THE MINUTES SHOW we leave the issue as it stands in the draft.
[Pat declares victory! :-]

Issue 235: Duplicate detection
There is no way of determining WHICH setup messages are duplicate.
The current solution is only to check a LONG history.
The D bit allows you to compare a set of records against every other record.

Q (Pat): Is this only an issue for prepaid services? For batch processing who cares?
A: There is a LOT of overhead for processing these duplicates.
Q (Pat): Is this a serious problem?
A (Randy): We do duplicate elimination as a post-processing step.

Bernard: Duplicate detection is very difficult in the general case. Even if a packet isn't marked D, it can still be a duplicate. In Failover, it is possible for the duplicate to arrive prior to the original. So the packet marked 'D' arrives, and no duplicate is found. Then the original arrives without the 'D' marking. It isn't checked as a dupe because the 'D' bit isn't set.
So how does the 'D' bit help?
Randy: Post-process anyway--I don't trust it.

Show of hands:
Important issue we should solve?
Issue we shouldn't go near?
[About even.]
Continue the discussion on the list to determine if we can do duplicate determination in a reliable way. Jari Arkko has some ideas on how it might work.

Issue 241 Accounting Issues

"Correlation of accounting records"
Pat: This is a change to allow an implementation to use the accounting subset of the base protocol.

There is no way in the base protocol to abort individual accounting sub-sessions.

Pat: Will send an email to the list to discuss it again.

Issue 247:
Handling of watchdogs is inconsistent between base and transport draft. Will resolve.

DIAMETER APIs, James Kempf (10 minutes)

The security API needs work. The JAVA API is stalled. I proposed that we move this into the JAVA JCP community. What do people think?

La Monte Yarroll: on behalf of Panos, no objection.
Others: Good idea, you probably will get a better review over there.
Glen Zorn: The IETF DOES occassionally standardize API's (GSS-API is an example).

We will need only one implementation for the reference...
Resolution: La Monte, Dave, and James Kempf will discuss the JAVA API offline and post to the list.

Transport issues, Bernard Aboba

- Jonathan Wood rewrote failover state machine
- Corrected typos
- Implementation in progress

Would request that implementors review the new state machine. This is now documented solely in the transport draft to avoid contradictions with the base document.

Here are the transport issues:

235: possible reject
224: accept, change to base
199: revisit after review of change made as a response to #173
173: accept
164: reject
94: accept

Diameter Base & NASREQ MIBs, Greg Webber (20 minutes)
MIB authors are Mark Eklund, Jay Koehler.

Diameter Base MIB

There's been a lot of cleanup. There are 8 tables in the base, but we are considering adding another layer.

Bernard: There is a document which is now expired called "AAA Issues" which includes many MIB issues, especially what should be exposed from a security point of view. Most of the draft is no longer relevant, but the MIB section may still be useful. We will resubmit it.

Two MIB drafts:
base v3

The MIB structure is inherited from the protocol itself -- it is not a monolithic MIB, but rather one that has subtrees for each application.

IANA assigned experimental root 119, four subtrees:


"These are just the basic statistics."

Question: There is a way to get the server to reread its config?

ApplicationsTable (the list of applications supported by the server)
PeerServerTable (Config info for each peer, static or ow)
Question: Is the port information missing here?

PerPeerStatsTable (mostly command counters)

There are about 45 entities defined.


[We can get roughly the same info per realm...]

Q (Bernard): One thing we've found useful is to count transitions within the failover state machine. I've been in situations where we've had a lot of packet loss...
A: Noted.

Q (Bernard): When we had a review of the RADIUS MIBs by Bert Wijnen a few years ago, he asked us "If you can assume SNMP v3 what more can you do?".
The RADIUS MIBs were really oriented towards SNMPv2, so there were not many uses of SET. So you might think about what can be done with SNMPv3.
A: Noted.
Q: The RADIUS MIB did not have trap definitions. Should we add traps, too?
A. Noted.
Q: Transaction threshholds could be very useful.
A: Noted.


Tables section:
PerPeerStats (more command counters)
HistorySessionTable (same as last, but can be variable length of history)

Q (Bernard): For those of us using EAP, it might be useful to get breakdowns on specific EAP methods.
A: Noted.

Bernard: I'd like to propose that these be adopted as official WG items. Any objections? [none noted by this note taker] OK, then we'll add them.

EAP keying issues, Bernard Aboba (15 minutes)

The presentation relates to issues 188-190.
Bernard: "This is why I think 188-190 are still open."

188: NAS Key Binding and Ciphersuite negotiation
189: NAS session key and initilization vectors
190: NAS session key and session master keys

What's the theory of this?
From the point of view of the NAS, new EAP methods do not require new code to be put on the NAS. NASen do not understand EAP methods (passthrough only).

AAA servers
- Act as a "passthrough" to EAP methods hosted via EAP API
- Server core code should not need to be updated to support new EAP methods.
- May not know what ciphersuite was negotiated between NAS and client (in PPP, ECP occurs *after* authentication).
- As a result, the AAA server cannot be assumed to have the information to pass back ciphersuite-specific keys.
- In any case, don't want to have to modify AAA server in order to support new ciphersuites.

EAP methods
- On the Server, may not know the negotiated ciphersuite (since this information can't necessarily be passed to it by the AAA server hosting the EAP method)
- EAP/TLS negotiates cyphersuite. Not such a good idea, even if you can have a "ciphersuite dictionary" to avoid code changes. The problem is that the AAA server doesn't know the ciphersuites that the NAS can support unless ciphersuite AVPs is sent from NAS to AAA server. Without that, the EAP method can negotiate ciphersuites that the NAS won't support. Note that the ciphersuite AVPs might be quite complex (look at IKE proposals). So if supported, we might have to design these AVPs for the general case (don't think current AVPs can handle that).
- Want to be able to use an EAP method with *any* media or ciphersuite. So don't want to have to update the EAP method when a new ciphersuite is developed for any media supporting EAP.

Summary: The matrix of EAP methods and ciphersuites is growing too rapidly -- best to not create interactions between them. That means no ciphersuite-specific keys, probably also no ciphersuite-negotiation within EAP methods.

Implication: EAP methods are generally incapable of supporting ciphersuite-specific keys. There are a few examples, of where this has been attempted (EAP SRP is one), but it is a maintenance nightmare. The whole purpose of EAP was to have a general authentication mechanism that works across a variety of lower layers and with *any* ciphersuite.

Some things to think about.
- Resolution of issues 188-190 is to enable any type of key to be passed back: master session keys, ciphersuite-specific keys, etc.
- Flexibility is good, isn't it?
Not necessarily. We are just providing mechanisms that will create problems with interoperability and maintainability.
- Enabling Diameter to pass back ciphersuite-specific EAP keys is not necessarily a good idea
- EAP methods should work with ANY ciphersuite
- Don't want EAP methods that only work with proprietary ciphersuites

Steve: I guess I agree with your point. I think you could find a way to just pass a ciphersuite identifier or a list of preferences.

BA: you might not know the ciphersuite until later.

Steve: E.g. Everyone is going to have to support WEP for some time to come. My concern is that there is always going to be one point of security failure, namely the AAA server, but this would introduce a second point (the ciphersuite negotiation).

Glen: People aren't going to stop doing this because we think it isn't a good idea. Sometimes you do know.

Bernard: There is no use of ciphersuite-specific keys within EAP methods published as RFCs. Only among proprietary EAP methods. So why do we have to accomodate proprietary EAP methods in standardized AVPs? Why can't those proprietary methods use vendor-specific attributes?

Bernard: There are cases where a AAA server may want to CONSTRAIN the choice?

Glen: Yeah.

John: This should be done, but I'm not sure this is the place to do it.

Bernard: Correct. Standardization of EAP belongs in PPPEXT WG. The discussion here is about how we resolve issues 188-190.

Bob: When I look at the model I see the remote client, the NAS, and the AAA server. There are three points of interaction, but we only handle NAS-AAA and client-AAA. The client-NAS relationship is not defined. I think we need to define this. Does it belong in this WG, or is it out-of-charter?

Bernard: Client-NAS interaction is accomplished via EAP, which is owned in PPPEXT. NAS-AAA and client-AAA interaction is via AAA protocol, so AAA WG owns that part.

Pat Calhoun: We had an EAP BOF in Florida three years ago. These kind of issues could have been solved by now, had we chartered an EAP WG at that time. Instead, EAP is being handled in PPPEXT WG, which doesn't really have the expertise or desire to complete the work. Given that we haven't made progress, and that we *still* need to charter an EAP WG, three years later, do we want to hold up Diameter to solve this? I don't think we want the dependency -- so all Diameter can do is provide a general facility, and let PPPEXT WG or a future EAPEXT WG define how that facility is used.

Paul Funk: 2 things are needed: Key material; and how you use it
All you need to do is assign them a number and a key length.
This is a very simple solution, that allows us to define the types we understand today, and allow extensibility tommorrow as well.

Bernard: Could you write up your proposal to resolve issues 188-190 and send it to the list?

Paul: Sure.

Bernard: I encourage Paul and others who think they have solutions please post them to the list for others to read.

We are now done with today's agenda.

Thursday, December 13, 2002


Mobile IPv6/AAA (20 minutes)
Digest Authentication (20 minutes)
Accounting (10 minutes)
Where do we go from here? (10 minutes)

Agenda bashing
There were no changes to the agenda.

CMS Security, Stephen Farrell (30 minutes)

SF: Are there any comments on the draft?
There were none. Next item!

Mobile IPv6/AAA (20 minutes)
draft-dupont-mipv6-aaa-01.txt (Maryline Laurent-Maknavicius)


MIPv6 needs access control both when the mobile node is at home and away
Why support MIPv6 in AAA?
- MIPv6 doesn't do it's own AAA, and needs help for scaling to inter-domain roaming...
- IPv6 not quite the same as v4--e.g. no Foreign Agent. But that doesn't mean there still isn't a need to manage network access.

Diameter MIPv6 Application
- support node authorization and authentiction
- support mobility
- Support SAs

Basic MIPv6 model looks almost like the MIPv4 architecture

- Authentication can happen in parallel with handoff
- Secure dynamic HA assignment when mobile node is at home or away

MN-HA, MN-Mobility Agents, LSAs
Q: What's an LSA?
A: Local security association--for relationships with entities in visited domains...

Q: How about keys between MN and the Attendant?
A: Sure, why not?
Q: Why do we need these keys?
A: This SA is necessary to restrict access to HA's by access network.
Q: Is this needed in all cases? What if the admin of the home domain has no issue with allowing the Mobile Node to roam anywhere? And if there is an issue, why can't this be handled via filters? Why is the architecture (mechanism) mandating a specific implementation (policy)?
A: The architecture is oriented toward carrier scenarios.
Q: So there are potentially other architectures that might be used in other scenarios?
A: Yes. For example, if the Attendant is willing to allow MIPv6 messages through prior to authentication, then these messages need not be sent via the AAA protocol. However, carriers aren't willing to do that, in general.

Bernard: We may have identified a conflict between the MIPv6 work and AAAv6.
R: Not necessarily. If this is a need of the AAA WG then we can adjust MIPv6.

Open issues:
- Authentication data format
- MN

Support for MIPv6: the protocol should support AAA for MIPv6 nodes.
Support of mobility and establishment of SA should be incorporated according to requirements.

Q: Can we make this a AAA WG work item?

Bernard: MIP WG still has a lot of work to do to get MIPv6 out; we still have a lot of work to do to complete our work. It is likely to be quite a while before it will become part of the AAA WG charter.

Q: The MIPv6 architecture is already sufficiently stable to start AAA work.
This item is not affected by the discussion over MIPv6 Binding Update security, for example.

BA: From a process point of view, AAA did not take on MIPv4 until there was a stable requirements document from MIP.

Q: I would say that we have sufficient requirements already.

Randy Bush as AD: When we see AAA WG documents go to WG last call in February, we will consider adding deliverables to AAA.

Digest Authentication (20 minutes) B. Srinivas

draft-srinivas-aaa-basic-digest-00.txt (B. Srinivas)

Problem scenario

Three entities: client, SIP proxy/server, AAA server

Proposing three new AVPs
- Resource AVP
- Challenge AVP
- Response AVP

Two examples:
A SIP example
An HTTP example

Option 1: New Application
- New Diameter application, similar to NASREQ, with new AVPs

Advantages of opt 1
- Less processing/framing overhead at DIAMETER client

Option 2: Use NASREQ unchanged, AA-Request and AA-Answer commands
- No changes at all
- Not a clean solution
- DIAMETER servers need to interpret fields differently

Use NASREQ unchanged: DER and DEA commands

Option 3: Define new AVPs & use them in NASREQ
The three described earlier

- Less processing/framing overhead at DIAMETER client
- Proposed AVPs are generic enough for other apps
- None

Pat: I favor a new application. I'm reminded of what's happened to Radius with certain fields getting heavily overloaded. I don't want to see this happen to Diameter.

BA: The AAA server is coming up with the challenge, is that right?
Bernard: Are the EAP frames being sent to the client, or are they being stripped off?
Speaker: They are sent to the client. Stripping them off would require the SIP proxy to have EAP-specific knowledge (contrary to "passthrough" nature of EAP).

Coauthor: We're very supportive of EAP, but we think there could be a use of this if somebody does not want to support the full NASREQ application.

Pat Calhoun: The only concern I have about this proposal is support for today's SIP clients and servers.

Bernard: Certainly servers, but it should be transparent to the clients.

Q: Are you saying that you would do some translation from HTTP digest form to EAP at the AAA server?

Bernard: It isn't yet clear and the people who should answer that are not here.

Bernard: Is there an agreed set of requirements on what this thing is supposed to do? Is the client supposed to change or not?


Bernard: Maybe that means no.

Coauthor: We're targeting just a niche.

Pat Calhoun: What are the authorization parameters that are supposed to be provided?
Or is this just for authentication and not authorization?

Bernard: How about we defer this question until we see the next presentation and see how they compare?

draft-sterman-aaa-sip-00.txt (B. Sterman)

Bernard: Do we have Mr. Sterman here? I guess not...

Bernard: Is there any communication between the authors of these two drafts?

Coauthor: Not directly. We understood their proposal to be extensions to Diameter itself.

Bernard: would you consider merging the proposals and also clarifying the issue of authorizations?

Accounting (10 minutes)

Why write thi draft?
No requirements on accounting in draft-calhoun-sip-aaa-reqs-03.txt
Yet there are accounting requirements from charging perspective!

Top level requirements:
Credit check/prepaid

- Support on and off-line accounting within a Diameter application
- Do rating, credit control, billing on different parameters
- AVPs needed for this.

On-line accounting example

Bernard: Did any issues with Diameter accounting arise during design of your application?

Answer: No issues. The protocol is fine.

Bernard: I heard that you are doing accounting first and THEN authorization?

Answer:: Authorization is always done first, but accounting generally has to happen BEFORE service is provided.

Bernard: Pat, have you considered describing this sort of thing in Diameter Base?

Pat Calhoun: I suppose it's possible but, we're almost done and I hate to be adding more stuff to it.

Bernard: I meant from a framework perspective. The claim is that this can be done only with new AVPs and no other changes.

Pat Clahoun: Oh, yeah, that's already in there. You can do that. There is no assertion that accounting has to come AFTER authorization. Hmm... I'm not sure -- there is a state machine in there. Maybe there are issues after all. We will have to review the state machine to make sure there are no gotchas. Can someone file an issue on this?

Review of next steps

Bernard: Randy, do you have anything to say?

Rany Bush: Where are the drafts? AAA WG has an urgent need for results. That means getting drafts to the IESG in "publishable" form.

Bernard: The focus over the next couple months is clearly getting drafts ready for IETF last call. This means:

Resolving WG issues
Addressing IESG concerns expressed to date
Cleaning up references, grammar, rewriting sections which aren't clear
Making sure that security issues are tied down
Writing the documents for a first time reader, not a AAA expert.

The plan is to go to WG last call on the Base, NASREQ, MIP, Transport and CMS-Sec documents after IETF 52. WG last call should expire around January 15, 2002. We'll resolve the issues, do the work above... and shoot for getting docs to the IESG by February, 2002.

Bernard: Any other items for the agenda? We're done for today.


Diameter Issues 52st IETF, SLC
Mapping of Basic/Digest Authentication to DIAMETER AAA messages
Diameter Base Protocol MIB & Diameter NASREQ MIB
Diamater Issues