NOTE: This charter is a snapshot of the 44th IETF Meeting in Minneapolis, Minnesota. It may now be out-of-date. Last Modified: 26-Feb-99
Chair(s):
Brian Lloyd <brian@lloyd.com>
Paul Krumviede <Paul@mci.net>
General Area Director(s):
Fred Baker <fred@cisco.com>
General Area Advisor:
Fred Baker <fred@cisco.com>
Mailing Lists:
General Discussion:aaa-wg@merit.edu
To Subscribe: majordomo@merit.edu
In Body: subscribe aaa-wg
Archive: http://www.merit.edu
Description of Working Group:
The Authentication, Authorization and Accounting working group will focus on the specification of a general Authentication, Authorization, and Accounting architecture for the Internet. The purpose behind this is to create a set of base protocols applicable to a number of specific AAA applications. These include at least IP Telephony, SS7 AAA, Bandwidth Broker AAA, and Network Access Server AAA. By creating an architecture and set of base protocols, the amount of work to create specific AAA protocols will be reduced.
The list of target applications implies a strong interaction with many areas of IETF activity, which is the justification for doing this work in the General Area. The working group will dialog specifically with the Application, Transport, and Security Areas, and others as needed, to achieve its objectives.
The problem space for a general AAA working group contains work in:
- determining the current set of specific applications that the AAA will service;
- documenting requirements for a base AAA architecture;
- identifying the capabilities and limitations of protocols currently used to represent and transport AAA information, e.g. RADIUS, Diameter, COPS, etc.;
- selecting a transport protocol or set of transport protocols to be used by a general AAA protocol based on the requirements,
- selecting the framework for the AAA protocols;
- specifying the AAA architecture and nature of the implied protocols;
- specifying the data formats for information contained in the AAA protocol information for authentication, authorization, and accounting;
- identify the relationship and interaction between Policy and Authorization.
The first step in this working group is to determine the requirements for the AAA architecture, and probable uses of that architecture. Once the requirements have been documented, the working group will be rechartered to implement to those requirements. A close second is to consider proposals of base protocols; ideally, the working group should be able to finalize requirements and review proposals during its second meeting.
The working group will target the use of TCP and defined procedures on UDP. When a transaction transport protocol has been developed elsewhere in the IETF, the working group will consider changing from TCP and UDP to that protocol.
Goals and Milestones:
Apr 99 |
|
Publish AAA Applications (to be an Informational RFC) as an Internet Draft |
Apr 99 |
|
Submit Authentication Requirements initial Internet-Draft |
Apr 99 |
|
Submit Authorization Requirements initial Internet-Draft |
Apr 99 |
|
Submit Accounting Requirements initial Internet-Draft |
Jun 99 |
|
AAA Base protocol proposals documented as Internet-Drafts |
Aug 99 |
|
Submit AAA Base Protocol Framework Working Group as Internet-Draft |
Aug 99 |
|
Submit AAA Applications to IESG for publication as an Informational RFC |
Aug 99 |
|
Submit AAA Requirements to to IESG for publication as an Informational RFC |
Sep 99 |
|
Revision of charter to include statement of work regarding specific protocols and data formats. |
Oct 99 |
|
Submit AAA Base Protocol(s) Specification as an Internet-Draft |
Internet-Drafts:
No Request For Comments
Chairs: Paul Krumviede (paul@mci.net), Brian LLoyd (brian@lloyd.com)
Minutes: Steve Moulton and Dave Mitton
Brian Lloyd introduced the new chairs and started a discussion of purpose of the group as currently chartered. A list of "nots" was presented:
- not a protocol development group
- not the Diameter WG
- not the COPS WG
- not the RADIUS WG
Want to look at the applications and services that need to use AAA and look at their characteristics and requirements. An initial, non-exclusive list was presented to start with:
- Remote Access, L2TP
- VPNs (IPsec and others)
- Bandwidth Broker
- VoIP
- Mobile IP
- others?
Additional suggestions from the floor included: web repositories, information repositories, e-commerce, news servers, management control services, system login, printing.
Authentication access to content and administrative data suggested; not clear if this in scope.
Someone asked if we should/could work on definitions first, but consensus favored working applications requirements as we were proceeding.
Should we define applications that are out-of-scope? like POP/IMAP which have their own mechanisms. While we should try not to overlap other groups efforts, we should stay open to other groups adapting our mechanisms.
It was suggested that we should try to fit into applicable current security mechanisms (like GSS-API). There was also a concern that we may end up duplicating other work (e.g., don't re-invent Kerberos).
Paul K indicated that he thought the charter too ambitious in some respects and we will have to work on a subset of the general problem.
A discussion of authentication started by pointing out the multiple existing techniques for authentication (e.g.: assertion, password, shared secret). We need to define what persistent date is required so that we can figure out what features are required in the protocol(s). It's likely that we will need more than one protocol.
It was further suggested that we consider not just algorithms but frameworks too (e.g.: EAP, Xauth, GSS-API). SASL has 13 different techniques in draft status. It was pronounced that this WG isn't currently working with transports, and will not discuss transports issues (e.g., UDP vs. TCP) at this time. Want to see what RUTS/SLUMS does.
The discussion of accounting started with enumerating some of the different types of accounting services and practices.
- transaction vs session oriented services
- types of services
- needs for billing
- needs for resource and allocation, usage and network engineering
Brian claimed he believed accounting was a separable problem, unlike authentication and authorization which seem to be intertwined. There was disagreement from the floor, authorization may be dependent on accounting data. Brian explained that state information dependencies should not be tied to accounting services. Just because some RADIUS implementations use accounting to compensate for lack of state, that is not what I mean here.
A comment was made that billing doesn't need dollars counts, just usage information. It was explained that this was the intention of the item. That is collecting data for external usage, but the requirements of different users will affect the delivery and dissemination of the information.
Accounting definitions get fuzzy, we need to work the sources, but not necessarily all of the uses. It was requested that we will want to address both real-time and batch needs.
There will be desires to want to gather information together, and do correlation and trend analysis. The information should hold up to this kind of operation. This led to needs for accounting correlation for the purposes of tracking intrusion detection, yes?
Bernard: Needs may be different, but we should explore them.
MarkB: Need to separate accounting from monitoring. Not a byte/packet monitor
JohnV: Should put in the need for fraud detection system. Should keep that in mind.
This framework will generate lots of information for different users; are we going to include mechanisms for customizing the information (views, cuts) ?
- PaulK: maybe, but that might be something we deal with later
Authorization
- least understood
- what is the relationship to Policy? they will interact and we will have to define this
- Does it require authentication?
- Not always... sometimes entities may be talking among themselves
- authentication by assertion is sometimes used
m: more experience today... ACLs, etc.... policies that are used based on your identity are often very service dependent. Hard to standardize this... should look at common frameworks for authorization models. ACL related: LDAP, IMAP, ACAP.... have these design features.
Authentication can be implicit example mandatory tunnel setup, sets up tunnel based on your phone number.
Denis Pinkas: authorization maybe interested in roles as a dimension of authorization (role-based authentication). CAT is working authentication - BrianL we are overlapping, and not doing protocols
<break>
m: scope? real -time payment methods - PaulK: not payment per-se, but certainly a discussion topic there are other schemes in this area (e.g.: IOTP) that we could tie into but not try to recreate it ourselves. Will not rule it out, but won't rule it in either.
Protocols are referred to in the charter - we are trying to stall that for now, as people are jumping straight into protocol messages and data elements. Eventually we will push protocol issues out to other groups and/or re-charter when we are ready.
JohnV - single or multiple authorizing parties; maybe more.
Accounting requires an identity not just a authentication, distinct for tracking instances, and unauthenticated users. Also authorization by role.
m: Non-repudiation? - PK: not going to devise a protocol, but the accounting data may need this (as may other forms of data, such as requests, approvals or denials, and authorizations). How this is provided is open for discussion. Some authentication methods may not allow non-repudiation.
FredB: could be certificates, could be detecting missing data
m: non-repudiation could be handled by transactions
Marcus: non-repud is a legal problem with soft boundaries, we don't want to go there. Technical problems are difficult to satisfy.
Paul: the cost of supporting this is also an issue.
PatC: must take brokering into account, RoamOps would make this requirement.
Tomorrow:
- give presentations from subgroups
people to split up into subgroups and pursue initial issues
3:30 pm AAA
- groups to produce draft-documents by end of April
Strawman architecture diagram presented by Brian Lloyd and discussed
Application AAA Focus Group (Alex, Siggy Maier)
Note that in some cases authentication and authorization may be based on payment info rather than identity.
Bandwidth Broker (Sue Hares, Shai Herzog)
Note the desire to support multicast applications here. includes dynamic allocation of bandwidth resources domain chaining process
Basic Operations:
- Requestor has authentication requirements
- Grantor performs admission control to domain
- Updates/Notification - needs may change, availability may change
SLAs - diagram of chaining application to campus net to backbone provider(s) to remote lab net
wants to account for bandwidth used by connection
Question arose as to whether or not denial of service should be considered in AAA. Marcus suggests solving the obvious cases first.
Mobile IP (Stuart Jacobs)
Authentication requirements
- scaleability
- performance: at most 1 sec, inter-domain; less than 1 sec intra-domain
- non-repudiation
- two-way
- One-way: mobile node to visited network
- authentication data exchange
- expedited re-registration authentication
Authorization requirements
- Policy driven
- QoS;location hiding; Tunneling; Dynamic/non HAs; other
- Bandwidth broker?
Accounting
- per mobile node
- reconciliation
- network port and addresses
- traffic handled; bytes, packets, tunneled packets
- NAIs used
- integrity, accuracy
- retention time
- privacy
- Fraud
- RoamOps model
VoIP (Pat C, Ping Pan, Rosenberg)
AAA server is used to centralize the user VoIP profile, call handling features support both user owned SIP client as well as public telephones in public case, the authentication must be done between user and the home server
discussions on whether roaming is a suitable topic for discussion here voip may require additional dynamic authorization and authentication to setup fancy call features (3way bridging, etc.) VoIP may involve billing requirements, and certainly inter-domain issues
SIP AAA server can return users profile, which can include calling features, speed dial, etc. Successful sequence indicates willingness to pay AAA may/will keep state information about previous calls accounting; Start and Stop records (some SIP problems here)
E-Commerce (Jason Eaton)
- diagram of Http/ssl exchange to Merchant server
- Merchant talks SCMP, S/Mime, SSL to E-commerce provider
- E-commerce provider does fraud detection, payment processing,
- Fulfillment, address verification
- Merchant and E-commerce Provider talk to Merchant bank
- The bank needs to setup trust relationship and authenticate
NASreq (Dave Mitton - Nortel)
Need to support transition from existing RADIUS services.
Authentication (Mark Stevens - Lucent)
- Examine current authentication technology
- Outline the authentication requires of a good sample of application
- correlate various authentication methods with requirements of applications
- evaluate existing protocols and authentication for fit
- publish informational document
Brian Carp: Do need to know identity of authenticatee before attempting authentication?
No, we don't want to go down rathole of distinguished names.
How many methods?, performance issues; should be a matter of policy But the design goal should include performance issues, if there are lots of iterations of authentications over the life of the individual sessions. e.g.: Kerberos is considered a good approach because it aids performance (can do local verification of tickets).
do we care about the survey?, we have to support existing techniques yes, and some protocols have not chosen yet and may want to use whatever this group may provide
Accounting (Nevil Brownlee)
- references aboba and arkko drafts as pre-existing 19 I-Ds and 8 RFCs concerned with Accounting
Examples:
- RADIUS Accounting (RFC 2139)
- RoamOps ietf-roamops-acctng-05.txt
- Atommib (RFC2512) MIB
- Atommib (RFC2513) Collection & Storage
- ISDN (RFC2573) MIB
- RTFM (RFC 2063) Measurement Architecture
- RTFM (RFC 2064) Meter MIB
work on a generalized form for describe accounting data, maybe a file format
Accounting terminology (Bernard)
Application usage characteristics and needs: sensitivity to data loss, delay, security needed. Differences between flat-rate billing and usage sensitive or transactional billing used as example to demonstrate different requirements.
Scaling and Reliability issues
- contributing causes attack the storage issue not the network protocol problems
Why not SNMP?
- polling model is efficient
- SNMP v3 provides security
- adequate for intra-domain accounting
Issues with inter-domain accounting
- access rights issues
- index table by provider, or context use
- but most MIBs are not structured this way
Bob Stewart; SNMP can be used in file transfer mode
- Bulk transfer issues
- high volume accounting
- Push model needed in some cases; high value transactions,
- fraud detect, sparse contact
m: some systems (ex: hotel checkout) will require push, as immediate billing is required
mailing list aaa-wg@merit.edu
Interim meetings & teleconference: expect to have, will be discussed on list
Paul Krumvide <paul@mci.net>
Brian Lloyd <brian@lloyd.com>
Authorization Requirements (Pat C presenting)
6 drafts and RFC2477
George Gross discusses diagram of Policy Decision Points, PEPs, PDPs.
Notion of attribute certificates as possible approach for authorization.
Pat C discusses Inter-Domain AAA
Accounting Requirements
Network Access Requirements
Quality of Service Requirements
Authentication Requirements
Authentication Sub-Group