2.4.2 Authentication, Authorization and Accounting (aaa)

NOTE: This charter is a snapshot of the 46th IETF Meeting in Washington, DC. It may now be out-of-date. Last Modified: 29-Sep-99


Paul Krumviede <Paul@mci.net>
Bernard Aboba <aboba@internaut.com>

Operations and Management Area Director(s):

Randy Bush <randy@psg.com>
Bert Wijnen <wijnen@vnet.ibm.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

AAA WG meeting minutes - 46th IETF - Washington, DC - Nov 10-11, 1999

Bernard Aboba - aboba@internaut.com
Paul Krumviede - paul@mci.net

Reported by: David Harrington - dbh@cabletron.com
John Vollbrecht - jrv@merit.edu

Edited by: Bernard Aboba

Powerpoint files used by the speakers may be found at the following URL: http://www.drizzle.com/~aboba/AAA/IETF46/ietf46.zip

Note from the reporteur (dbh@cabletron.com):
The meetings were primarily slide presentations followed by question and answer periods. Readers should view the appropriate slide presentations, and read the source documents to clarify any ambiguities.

There was very limited time available, so presentations were rushed, and discussion was limited. I recorded comments made during the presentations and the following question and answer sessions, without attempting to capture the slides in the minutes. Comments recorded are not necessarily comments made by the presenters. I recorded the sometimes lively debate as best I could. In the following, the notation [???] means I captured an incomplete note with enough to know the topic but not the expressed opinion. I include it here just to make the reader aware that the topic was raised.

Q means question; A means answer; C means comment.

Session 1 - 11-10-99
- Network Access AAA Requirements
- Draft-ietf-nasreq-criteria-03.txt
- Draft-ietf-cdma2000-aaa-00.txt
- Draft-ietf-mobileip-aaa-requirements-00.txt
- Draft-ietf-aaa-na-reqts-01.txt

Presentation by Mark Beadles

Radius compatibility is required because hordes of radius implementations are deployed. This is an operational requirement radius and new protocol must be able to coexist.

Due to the large numbers of NASs, AAA will need good support for fail-over, etc., and flow control will probably be required. Congestion management is a fair synonym for flow control.

Mutual authentication between user and NAS will probably be required and the AAA protocol should support this. The AAA focus is on protocols between NAS and AAA server, although the protocol should not preclude mutual authentication between user and server. It may be important to some applications to verify that the user is connected to the correct network.

Authentication Requirements include:

Multi-phase authentication, which would require a sequence of exchanges. Authentication must be extensible - PPP should be a requirement, and EAP should be recommended. Clear-text credentials must be hidden by the protocol.

Operational Requirements include dynamic authorization. The AAA server must be able to send updated authorization state information to the NAS during a session, such as "stop service", so as to limit the impact of fraud, and for other reasons. A protocol must support bi-directional authorization. Events to trigger re-authorization may occur at either end of the relationship. Authorization may allow for a time period, then additional authorization may be sought to continue; A server may initially authorize a user to connect and receive services, but later decide the user is no longer allowed use of the service. You may want to update authorization capabilities after N minutes for example. All authorization have a time limit.

Attributes for AAA must recognize the large installed base of attributes for existing approaches (radius). Attributes must be defined that are usable by NASs, but the attributes already defined are not enough to define framework.

Are attributes and objects interchangeable? Should we consider these terms synonymous? Do objects subsume attributes? If we require attributes, we may lose some of the semantics from existing objects. Question whether attributes could be "objects" or parts of "objects" -- this was agreed to be ok.

Some things in authorization may need to be hidden, and they should be hidden end-to-end (NAS to originating AAA server).

Accounting Requirements (still NASREQ)

Accounting requirements include guaranteed delivery, real-time reporting, batch reporting, and time stamps. Guaranteed delivery refers only to transport, protecting against packet loss. Real-time is loosely defined as reporting synchronously with events. Batch reporting is data saved up and sent later, for some value of later. Is guaranteed delivery requirement handled solely by transport reliability? Answer was yes, but discussion seemed to indicate that there was a need to guarantee insertion into the database as well. So that would mean more end to end. A protocol to support one could probably do the other.

Time stamps are needed to reflect the time dimension of events such as logon, logoff, authentication, authorization, and interim accounting. Secure timestamps are preferred, but secure has varying interpretations.

Secure authentication is an event that could, or should, be audited. There is a fuzzyness between accounting and auditing, and it is unclear whether AAA accounting should support logging of "auditable events."

There can be multiple accounting records for a single session. Some say cumulative interim accounting records are required, but there have been requests for both approaches. AAA may need to support both approaches and allow the operator to tune the reporting to suit their needs. If reliable accounting is beyond the accounting layer, then you might not need cumulative stats [???].

There are some open issues being worked on by the NASREQ WG; some don't directly affect AAA.

There are some requirements for inter-domain real-time accounting and for on-demand accounting that need to be considered.

There is a need for support of multiple severs for failover - this is not for load disribution, only for hot standby service.

It is unclear whether we need to provide service discovery for finding AAA servers, and negotiation mechanisms for determining capabilities of servers found. These are mostly needed for inter-domain relationships - a routing issue. Service discovery may be recursive, may not be part of the protocol, and may be dependent on the credentials provided. Negotiation may require some attributes at run-time, or communications may not be allowed to continue.

Question and Answer Period:

The NAS requirement to support multiple device servers is for fail-over purposes, rather than for sending a request to multiple servers.

PAP support is required -- but only for one time passwords.

Support for non-repudiation is a SHOULD. Legal requirements may be complex. The requirement as presented is considered an operational requirement, not a legal one, and the NASREQ WG stopped short of making it a MUST, or specifying mechanisms, or considering the ramifications of third-party repudiation and resolution issues. Meeting operational requirements and not meeting legal requirements may not be adequate. The repudiation requirement should include steps to build evidence for court. Legal requirements may vary over time and location, so support for legal requirements would be way beyond what we could do at the protocol layer.

Bi-directional authentication does mean a connection could be initiated from the net to the user.

Question was raised as to whether accounting should be used for "signalling". Answer was -- not clear yet.

A discussion of how flow control would work here was taken offline.
Presented by Tom Hiller

For private networks, primarily MobileIP, the goal is to reduce the on-the-air requirements. For a wireless channel, the authentication in done in the data domain. CDMA2000 expects to support thousands of private networks, therefore it needs to have brokers to aggregate

Authentication Timing - latency round trip estimate - should be less than 100 MS. Needs carrier grade service (redundancy, scaling, management).

Deployment starts next year. Need protocol to go with it. Want to use new AAA protocol (not RADIUS with known problems).

A radio network uses non-IETF authentication to establish a channel then uses IETF authentication, usually a foreign agent challenge. A key idea is the same server works. We haven't considered whether a broker must forward packets, or whether a broker can change the path. The whole point is to ensure that somebody will pay the serving network for services rendered

In MobileIP there are a variety of proposals based on address of home agent. We believe packets need to be routed by NAI, not just address. Cell networks are expecting 1000s of clients, so one-to-one is not scalable. Another approach is to send the user profile from home agent to foreign agent or server.

Another more controversial item is key distribution. Key distribution has been talked about a lot in MobileIP. [a discussion of key distribution ensued] [ a discussion of certificates ensued]

To reduce latency, it would be nice to embed or encode multiple facets of a request into a single request message to reduce the transaction to a single round trip between home and foreign entities. If you need multiple trips, it is not as scalable. The notion of round trip is ambiguous when dealing with more than two entities. There have been various proposals for handoff.

TIA is working on understanding fraud between carriers, to better recognize the requirements for integrity and non-repudiation. There is a need for replay protection, and the ability to match accounting records with prior authentication and authorization records to know whom to bill. There is a requirement for reliable transmission. Some brokers take the message apart, to accept financial responsibility.

3G deployment starts next year. Packet data is the driving factor. It would be nice to have AAA protocol available at that time.

The question of using accounting packets for signaling, session tracking, and resource allocation was raised again. TR45.6 is not looking at accounting to be used for resource allocation. Latency for accounting probably not the same as for authorization: 1-2 seconds would be ok.
Draft-ietf-mobileip-aaa-requirements-00.txt Presented by Charlie Perkins [slides - http://www.iprg.mokia.org/~charliep/.... ]

TR456 fed a lot of input into MobileIP, and this has had a serious affect on MobileIP directions. MobileIP is changing their view of the trust model, to use AAA.

AAA protocol should not need to get into the guts of the MobileIP messages, and MobileIP should not need to get into the guts of the AAA information. Given that separation, no matter which AAA protocol was used for a transaction, MobileIP should be fine.

Here is the new trust model being considered by MobileIP to use AAA. It used to be that a mobile node had a relationship with the home agent; now it is with home server. Home and foreign servers have a trust relationship.

We need to be more specific as to what "trust" means; what is trusted in the other? A lot of these documents use trust, security, etc. loosely; we may need to spend time doing education, etc. This is not a discussion for this meeting. MobileIP has defined what security is needed. The phrase "security relationship" could substitute for "trust".

Does this mean mobile node no longer trusts home agent? No, a mobile node gets authentication/authorization at the start of the session, and session goes on without re-authentication/re-authorization. There must be a key distribution between the home agent and the mobile node.

It would be nice to have a local home agent that is instantiated neat the mobile node. If done this way, everything can be done local to the mobile node.

For key generation, we mapped out some trust relationships.
- between what entities
- for what
- what is trusted
need iteration with security people to get trust issues clear/right

For the broker model, a broker can be in the middle. MobileIP trust requirements reflect those mentioned by Tom Hiller; some requirements were taken directly from the CDMA draft. Trust for key distribution is important, keys must be able to get through the middle without disclosure.

MobileIP WG would like to have an extension so when AAA completes, MobileIP is set to go. The MobileIP WG planned on a tight binding between the MobileIP starting sequence and AAA authentication and authorization. There are cases where a single registration is not a good idea. For example, if there is a local policy of free time before authentication/authorization is required, the single registration before service is permitted would not work. Maybe the MobileIP starting sequence should be able to be done within AAA, but not with a tight binding.

[There were a number of questions and replies about key distribution. All I have are the following disjoint notes]. MobileIP was designed before IPSec. [There was a short discussion of the interaction between AAA and MobileIP sessions.] Should this be pushed into a key distribution for multicast over MobileIP? All AAA can do is push it down; something other than AAA needs to handle this. I thought user's profile request should be forwarded to mobile node.

Open Discussion:
[discussion of home and/or foreign agent and/or home/foreign AAA servers relationships]
Communications between home agent and home AAA server - what kinds of things have to pass between them? [???] How many communications paths are needed?

Guaranteed delivery means robustness in the face of packet loss. Reliability is required for transport (robustness against packet loss), but also for failover routing (failover of broker).

Non-repudiation is not a legal requirement, it is an "audit" requirement.

Proxy /non-proxy broker -- not clear yet whether both are required. How is encrypted key sent through broker? major issue for AAA protocol is sending the key without broker seeing it.

A security guy observed that he was hearing lots of key/trust/complex multi-party security relationships. When people say "I think we need this," there's unnecessary complexity. Use AAA to do the minimum bootstrapping.AAA should not be about getting random keys it should be about getting authenticated/authorized.

We want to get a key to allow MobileIP to work and it's well understood. MobileIP will take whatever brokering is provided by AAA.

What happens when a mobile node wants to authenticate the foreign agent? A key is distributed between foreign agent and mobile at same level of trust mobile node has with the home AAA server.

This is very much MobileIP v4, have you considered v6? A: you know I have ;-) MobileIP v6 is very important because it doesn't have the foreign agent [???]. Hopefully we'll a draft in the next couple of months.

"Somewhere there is a simple idea waiting to get out -can we reduce the laundry list of requirements?" Perhaps we want to make a distinction between authentication/authorization and key distribution. These are related in terms of time and space, so it's desirable to do this together.

Should both foreign and home agents send the same accounting packet to the home AAA server? Accounting at the foreign agent/server and at home agent/server should be able to be correlated.
Panel Discussion led by Paul K

A panel was created of the representatives of the other working groups, and they were asked questions so we could all see whether they agreed as to the meanings of the requirements.

Q: Reliability - reliable only against packet loss - agreed?
A: Hiller - also detect failures, route around failures, high network availability
A: Paul - also non-volatile storage?

Q: fail-over is to protect against packet loss?
A: transport level fail-over

Q: non-repudiation? not a legal requirement
A: this never came up in MobileIP

Q: proxy and non-proxy brokers. Why?
A: Hiller: to distribute NAI knowledge

Q: so you mean a transparent broker; no attribute edits?
A: Hiller: yes, no attribute edits
A: CP: MobileIP doesn't require attribute edits
A: Hiller: we allowed non-proxy brokers to edit (see ipass)

Q: PatC: when messages are taken apart, do we need end-to-end authentication?
A: Beadles: not for NASREQ

Q: Agenda question - when do we evaluate against the matrix?
A: This panel is for asking question about the matrix.
C: I think sum of AAA requirements is greater than these three sets of requirements
A: if we take union of all and find a empty set we'll fail. We need to determine which are real requirements
A: MobileIP hasn't yet met this week, so the matrix may change for MobileIP

Q: fraud detection - how do frauds differ from traditional security threats?
A: Hiller - there is a study about things that can be done with radius with cap[???] relay, etc. It's that type of thing.
Q: can we get a short list of those threats?

C: we need a terminology draft

Carl Ellison
Certificates for Authorization

There are some mentions of certificates in drafts. This is a presentation about some work that has been done about certificates. The ideas presented came out of the work of SPKI working group, which made the distinction between identity certificates and authorization certificates. The identity certificate binds an identity to a public key. The authorization certificate binds the public key to a set of authorizations. Note that the identity is not in the authorization certificate, which enables anonymous authorization. SPKI work is documented in RFC 2692 (cert requirements) and RFC 2693 (theory).

Authentication must not be limited to identification information. Using identification information can lead to the identity being disclosed.

What we care about is not the name of the key holder, it is the permissions associated with that key holder. Most certificates don't provide linkage to permission, they provide linkage to the identification information. One of the characteristics is that the security perimeter is around the entire structure of permission-identifier-public key. There are 3 points of possible attack. The fact you're linking to identifier, then can violate privacy and lead to identity theft.

There is a class of certificates that directly links certificate to permissions, in a permission-public key-identifier linkage. The security perimeter is limited to permission-public key leg. The identifier doesn't need to be moved around the network This helps to preserve privacy.

We have the option to choose authentication certificates. See rfc2693 and 2692.

This approach currently has a status of Experimental. It could be moved toward standard track if there is enough interest. The concept is now in x509.
Accounting Requirements Dialogue
Presented to the panel by Bernard Aboba

Did you say accounting is not being used for billing? No. It is primarily used for non-usage sensitive billing Flat-rate plans are most popular; not usage-sensitive. Don't many ISPs do radius accounting for billing? Not generally; most use flat-rate billing. Radius accounting is used for a number of purposes, some of which is billing.

Non-usage sensitive billing does not require much robustness against packet loss, for example. New applications require usage sensitive billing, need to meet more stringent requirements.

In Europe, billing is based on usage. Statistics must be retained for a period of years as statutory requirement. Yes, we're just trying to distinguish. There can be many different billing plans, we should accommodate as many models as we can.

Some other things are not included in the requirements, such as signaling, terminating sessions, etc. Yes, but is that an artifact or a core use? Signaling exists and should be included. Also auditing is used for accounting data; to look at a system as a whole, to look at a set of transactions, to verify that the process is working properly. In signaling, maintenance of state is very important. Changes in state could be signaled on authentication/authorization. Most use accounting records as that signal for state maintenance.

Question about using accounting for signaling. Discussion was that while it may not be appropriate to accounting, it is what is done now, and should not be ignored.

Auditing requirements as mapped to accounting. Discussion was about auditing being used as "proof of operation" both in near real time and in post processing.
Alan Blount
Accounting record formats

Focus on service capabilities. separate record format and protocol so that same info could be carried in different protocols.

Focus on "extensibility" so that accounting capability can be extended by service, either adding more standard services or allowing ad hoc extensions for special situations.

Section 4.4 refers to aggregation. This is in terms of say a fax service with attributes. There are independent service definitions.
Section 4.4.3refrs to compound services, such as multiple billable services. We need to bind multiple pieces into a transaction.

Neville Brownlee
Accounting attributes

Reviewed draft he presented at Oslo. No changes in draft.

Similarities between Authorization and Accounting: both carry attributes, need routing.

Need to develop a common session "id" for both accounting and authorization to support auditing.

ADIF has a good set of attributes, and can use attributes from other sets. Could we use a single common accounting record format?
- low overhead desirable (ADIF, binary)
- existing fit well in their particular usage (asn.1, XML)
- don't think we'll see a single format

Authorization and Accounting differ; they also have lots in common, sending attributes back and forth. There are ranges of reliability and timeliness.

There is a difference between encoding and format. ASN.1 is an encoding. I see that as deciding between different set of data types. We need a terminology draft.

Did you compare ASN.1 and XML by their level of adoption? No. I think XML is good and powerful, lots of others [???].Commented that there was a big push for "low overhead" rather than asn.1 or XML. Comment that EDI is going to XML, so accountants will be using it. A gateway to translate would be likely [groans from the audience].

We devised service attributes in MobileIP. If we want to set up service descriptions, they should be able to be parsed. I don't know if we want to [???]

I'd like to be able to define a new service without getting everybody to agree before I can use it. What about the problems of adding attributes - if radius receives an attribute it doesn't recognize, then it passes it on? In AAA context it might be good to forward it, assuming there is not a security disclosure problem. Unless it's critical to operation, discard doesn't seem the best policy.
AAA 11-11-99


Interim meeting Jan. 19-20
Probably CA, near RSA meeting

Jari Arkko

This document is based on same sources as NASREQ requirements, and used additional documents for methodology requirements. This draft is simply requirements; the protocol analysis has been removed.

The distinction between billing and accounting is important. The billing can determine which tariffs should be applied at what point during a call.

For event accounting records, just having a start and stop is inadequate. How many packets were used during which period is not included. I do agree that we should support dynamic reauthorization. These features are service specific.

John Vollbrecht

Authorization subgroup
- Draft-ietf-aaa-authz-arch-00.txt - architecture
- Draft-ietf-aaa-authz-samp-00.txt - sample apps
- Draft-delaat-aaa-generic-00.txt - authorization framework - what would we like to have?

Stephen Farrell

CIA in the slides means = confidentiality, integrity, and authentication.

Timeliness may have a relation to structure. Data may require different structures.

Randy asks, "For which applications within the charter is this needed, as compared to a generic survey?" The answer is "The info here was derived from the in-scope reports of requirements. This was started before we limited scope to NASREQ, RoamOps, etc."

Leon Gommans
Authorization requirements

We tried to map requirements into a matrix of access requirements and application requirements. Only subgroup members did the evaluation.

Charlie Perkins, Tom Hiller,

[Slides] cdma2000 requirements - priorities
Reliability was most important - see slides for rest
Transport -neutral
Others ho-hum

Transport reliability means packets should not be lost. We haven't spent time dealing with how many records you can lose and the importance of non-volatile storage. There is more than just transport loss to consider. We haven't discussed requirements of protocol vs. other parts of architecture. We're trying to distinguish the transport part from other parts.

If you have a proxy radius change that does t the transaction, we'd want hop-by-hop acknowledgement. If you're looking for hop-by-hop acknowledgement, then data must be marshaled.

General questions for panel
[Slides] Bernard

When would identification without authentication be needed? DNIS is dial number info service. You may wish to authorize user; all you know somebody called from a number, no identity. Examples are Helpdesk and 911. Also authentication may be by realm portion of NAI, not per-user. Mandatory tunneling [???]

When is anonymous access needed? It should be supported; there are circumstances where there is no knowledge of the user or realm. This is different than identification without authentication. For example, the user may be encrypted.

When is authorization without identification a requirement? We may be dealing with access, when no identifier is found. For example, with two AAA servers; you may want to be anonymous to foreign server. One case is a signup registration service followed by a download of some type.

Policy usually means changing access accept to access reject. Yes.

What are the requirements for obtaining Qos? CDMA 2000 is sending an opaque id to the serving network; opaque id could be [???]. NASREQ is basically the same.

There was a discussion of the types of broker relationships, with a slide to represent each of the relationships. [see Slides]

RADIUS-style proxy uses a shared secret. [Slide] The threats in this relationship include access to PAP passwords.

For NASREQ, PAP will be used to carry one-time password info; since the passwords are one-time only, the effect on access to PAP passwords is irrelevant. They won't be reusable.

This broker model is being done in current use everyday; we can't break it. The general requirement is the abstraction. In that scenario, is it a threat that must be handled - we need to hide the data. The IETF has deprecated PAP except for one-time passwords, but many use it anyway; if we don't hide the data, it will result in password theft. Mobile node requirements are that brokers must not be able to gather passwords. MobileIP encrypts passwords over the wire. Don't we have the same problem with CHAP?

I don't see why we need to worry about the broker when there's also a foreign server involved. We have replay protection so it can't be use repetitively, even with end-to-end. A broker could modify attributes inappropriately - what is the purpose to prevent that editing? Broker can change access-accept to access-reject. Firewalls must be able to prevent access to the network. This is not a threat to be protected against.

How does reconciliation occur? Home agent says yes; proxy changes to no. How to prevent the home from billing for access? CDMA doesn't worry about carrier fraud against each other. This is not a threat to be dealt with. Is this a security issue or an auditing issue?

Local proxy could edit attributes inappropriately. Is local proxy editing attributes a threat or a feature? There are people who make a business of sending mdse. not ordered. This is not the job of the protocol; we must assume trust. Consider this a feature, not a threat. If these entities are making proactive changes, we must trust the proxies. The broker is the guy who pays the bills.

If a foreign server is going to reject the request, why pass it to home server in the first place? The foreign server may ask what services are permitted by th ehome server. When the foreign server gets the authorization, it realizes "oh, I don't offer that kind of service", and rejects the authorization because it cannot be supported.

If you use scenarios to analyze this, you'll always find a case. You need to trust the broker; the trust becomes transitive; it identifies responsibilities in the system; and thus trusts the entities to fulfill the responsibilities.

Redirect Proxy

What threats are mitigated by the redirecting-proxy approach? Broker would get PAP passwords. There's an assumption that entire request may go to referral. The broker can return edited attributes. Is this the same as in the last case? The broker cannot change access accept to access reject. The broker may want proofs that access occurred. Is this a satisfactory protection from the threats identified?

OK, but I'd like to see If you want the broker to be a Certificate Authority, it must have mechanisms for getting certificates from GA. If the broker is a distributor of certificates [???] The assumptions I've been making that broker isn't necessarily [???] [ an analogy to a bank acct here]

My assumption is certificates don't come from anywhere. When broker hands me the certificate, I expect some guarantee of authenticity. This is unlike the bank acct analogy. The certificate is a binding of identification to public key, with a matching private key. Once the binding is done, there is a strong trust relationship if private key is private.

If two trust domains want to use a broker, the broker is serving as certificate authority. I think there may be advantage. I think we do understand issuing and distributing certificates. The question was does issuing security open security holes?

I have not seen a means for AAA server to tell access device it needs more time. Most authentication will take place locally, but some may require a pending status. Take this to the mailing list.

What are our target dates? Randy says that the point of the meeting is to finalize the requirements and get them to the mailing list. Charlie says he's not worried, but mid-January for requirements will make our hair go gray. [Laughter]

The CDMA arena has made a commitment to use IETF protocols in packet network infrastructure. This puts us in a scheduling bind. Part of the reasons for forming the working group was to meet CDMA requirements. What are the work plans? Randy says "I left my magic wand at home; we can only do engineering." We don't yet have consensus on requirements. We cannot discuss further work until the requirements are agreed upon. We'll try to get it nailed down for January. We need a target before we shoot arrows.

The question was raised whether there was that much disagreement on requirements. If someone wants to put a doc on the list saying these are the requirements, and nobody objects to the requirements, maybe we can beat the deadline. Requirements are converging, not converged.

There are concerns that the aggregate set of requirements is too large. Are there simplifications, or can they be consolidated? Assuming we agree simplification is not possible, we're done. If we agree simplification is needed, we'll try to complete simplification. Pat C asked if the panel could go reduce their listed requirements.

Randy says, "IETF is good at doing the possible now, the impossible later. We're looking for a new possible. We're not going to boil the ocean. Requirements are still very abstract."

We need to take the requirements to the mailing list; we have a large set, but it's not necessarily a complete set. We are assuming only that requirements meet specific constituency requirements, not an abstract completion.

Randy says, "we'll stick to our restricted target."

Generic AAA architecture
C. de Laat

Presentation of a generic AAA architecture that concentrates on separating general services available from an AAA server. It includes consideration of brokers, rule-based engines for referrals to other AAA servers. See the slides for details of the analysis.

George Gross - a layered approach
[Slides ] AAA arch slides

This is a continuation of the generic AAA architecture presentation. This portion concentrated on the proposal of a layered architecture. It considers distributed and chained authorization decisions and complex authorization message flows. It proposes a AAA Server protocol stack to make the problem more tractable, to isolate out those things that are specific to the AAA problem. See the slides for details of the proposal.

Future work for authorization subgroup includes identifying which aspects need to be standardized, and which can be left for vendors to define.


None received.