NOTE: This charter is a snapshot of the 51st IETF Meeting in London, England. It may now be out-of-date. Last Modified: 31-Jul-01
Bernard Aboba <aboba@internaut.com>
David Mitton <david@mitton.com>
Randy Bush <randy@psg.com>
Bert Wijnen <bwijnen@lucent.com>
Randy Bush <randy@psg.com>
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/
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.
Done |
|
Submission of requirements document as an Informational RFC. |
Sep 00 |
|
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. |
· Diameter Implementation Guidelines
· Diameter Mobile IPv4 Application
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 |
IETF 51 - AAA Working Group Minutes
Wednesday, Aug 8th, 2001 13:00
Recorded by Pete McCann
Edited by Dave Mitton
AGENDA:
PRELIMINARIES (5 minutes)
Agenda bashing
Blue sheets
Minute takers
Document status
DIAMETER ISSUES
Open Diameter Issues (30 minutes)
Pat Calhoun (pcalhoun@diameter.org)
Documents now in AAA WG last call:
http://www.ietf.org/internet-drafts/draft-ietf-aaa-diameter-07.txt
http://www.ietf.org/internet-drafts/draft-ietf-aaa-diameter-cms-sec-02.txt
http://www.ietf.org/internet-drafts/draft-ietf-aaa-diameter-mobileip-07.txt
http://www.ietf.org/internet-drafts/draft-ietf-aaa-diameter-nasreq-07.txt
http://www.ietf.org/internet-drafts/draft-ietf-aaa-transport-04.txt
3G COMMENTS ON DIAMETER
Diameter as a 3G Accounting Protocol (10 minutes)
Thaddeus Kobylarz
SUPPORT FOR MOBILE IPv6
Diameter support for Mobile IPv6 (10 minutes)
Franck Le (franck.le@nokia.com)
http://www.ietf.org/internet-drafts/draft-le-aaa-diameter-mobileipv6-00.txt
AAA Local Security Association (LSA): The Temporary Shared Key (TSK) (10 min.)
Franck Le (franck.le@nokia.com)
http://www.ietf.org/internet-drafts/draft-le-aaa-lsa-tsk-00.txt
SUPPORT FOR SIP/HTTP AUTHENTICATION
HTTP Authentication with EAP (10 minutes)
Jari Arkko (Jari.Arkko@ericsson.com)
http://www.arkko.com/draft-torvinen-http-eap-00.txt
Digest Authentication in SIP using RADIUS (10 minutes)
Baruch Sterman (baruch@deltathree.com)
http://www.ietf.org/internet-drafts/draft-sterman-sip-radius-00.txt
Diameter support for Basic and Digest authentication (10 minutes)
Sengodan Senthil (senthil.sengodan@nokia.com)
http://www.ietf.org/internet-drafts/draft-srinivas-aaa-basic-digest-00.txt
WRAPUP
Where do we go from here? (IESG, Chairs) (10 minutes)
Need for interim meeting?
---
Agenda Bashing: Jari Arkko's talk was moved to after 3G Comments.
Announcement:
New Diameter Interoperability Test Event to be held.
Location: Ericsson Research, Berkeley, CA
First week of October (10/1/01 - 10/5/01)
See: http://standards.ericsson.net/diameter-bake-off
Document Status:
Documents now in AAA WG last call
draft-ietf-aaa-diameter-07.txt
draft-ietf-aaa-diameter-cms-sec-02.txt
draft-ietf-aaa-diameter-mobileip-07.txt
draft-ietf-aaa-diameter-nasreq-07.txt
draft-ietf-aaa-diameter-transport-04.txt
It is important for everyone to get their comments in as soon as possible.
The next step will be IETF Last Call.
Diameter Issues
Open Diameter Issues (30 mins) Pat Calhoun
Only issues other than editorial were discussed.
Diameter documents are in last call, which expires Aug 20.
Since last call sent to the list, 25 new issues submitted;
8 of those closed,
17 still open,
5 technical,
12 editorial.
Issue 95:
Request that we remove support for proxies that hide the internal AAA topology by removing Route-Records.
No objections received, Support will be removed
Issue 117:
Submitted yesterday
In -07, a feature was added to support server initiated messages.
There was an assumption that routes in reverse direction would not be set up.
So a complicated feature was added for setting them up. Pat doesn't like it.
More clarification: If a home server wants to send a message to the NAS, a complicated source-routing scheme was put in place to process the message proxies/relays must advertise themselves during original request proxies/relays may not be available, so must advertise alternates
Shouldn't it be safe to assume that a business relationship establishes routes? Yes, But there are issues on what a AAA server must remember about an active session to send a message, possibly back through a broker, to an unknown NAS provider.
Proposed: Let's just remove the issue, and assume that routes based on NAIs will be configured properly
Hums for support of this feature, very few to support, many to remove.
Issue resolved in favor of removal
Issue 97:
Given a mechanism as described in 117, entities might want to state the path for any Diameter messages, not just home-)NAS.
Given we removed 117, do we want to do this?
Discussion: In practice, how many public hops do we really expect to have?
One hop is a direct bilateral relationship, 2 hops is through a broker.
Quick poll of audience members revealed 1 or 2, maybe 3.
Perhaps inside a network, you want all messages to go through the same set of proxies?
Shouldn't the proxies just maintain state? Some may not be stateful.
Proposed: If there are many hops, just need to make sure all hops are stateful
Show of hands to like this feature -- nobody. Feature to be removed.
Issue 98
Request to clarify the difference between a primary, secondary, and alternate peer. Really editorial, marked as technical by mistake
Issue 109
Add a new AVP to include AVPs that are missing from a command
We don't need this mechanism to accomplish this end.
No Issue filed
Do we need to signal the end of all accounting sub-sessions?
e.g., SIP registration defines a session, but accounting is sent for each call
Protocol does define sub-sessions
How do you know when all the sub-sessions are closed?
Proposal: Each sub-session has Start, Interim, Stop messages. And if the master session stops, then implicitly all sub-sessions are stopped.
Unfortunately, there's no such thing as a master session in the protocol. If people want to detect the end, we could have some AVP with a termination cause, which would indicate whether whole session is done. It was suggested that we could have start-master, stop-master, start-sub, stop-sub events, perhaps application dependent. Even use of RADIUS Tunneling Accounting message types is NASreq application dependent. Another possibility raised would be to put an optional extension in acct record with a parent session identifier, then a sub-session is any session that has a parent. Evidently we can already to this, but we still don't know when the parent went away. Further discussion seemed to favor defining parent termination behavior relative to sub-sessions on a per application basis.
Issue 114
Replace DiameterIdentity format with two new formats
- NAI for Redirect-Host, Route-Record
- Loop detection
Pat believes that what we have is sufficient.
Discussion rationale was that it is possible for server to support both TCP and SCTP, and the URI form with 2 different transforms, so a simple equals check for identity may fail. This is that the "true identity" is different from "referential identity". Some of this problem comes from the loop detection changes.
Further discussion decided to take this issue to the WG list.
Hidden Issue in issue 100
If you get an IP-Filter rule, and you can't support it, and M bit is not set, should you ignore it or terminate the session?
Currently you can ignore it, the Proposal is to terminate the session.
The editor thinks it is a change to the protocol and isn't needed.
Pat will close 100 and open a new issue, and take discussion to the list.
Issue 118
A subtle request to redesign the protocol to a multi-round one, (from request/response), to allow negotiation of authorization AVPs
Editor would like to kill this.
Protocol already support multiple rounds, for authentication. But not for negotiating authorization AVPs.
Discussion explored possible coping strategies. The NAS can re-request, but it is the enforcement point for the policy set by the server.
Providing this is a whole lot of work. Not just editorial.
How many people are ok with killing it? Many hands
How many do like it? No hands.
Last call expires on 20 Aug.
Many will arrive on 19th... but, if all issues are closed, can we submit the edited draft on the 21st?
Diameter as a 3G Wireless Accounting Protocol
-Thaddeus Kobylarz (AT&T Wireless)
Disclaimer: unlike previous presentation, this presentation is not screened by 3GPP. Currently SA5 is embroiled in completing release 4. Diameter is a release 5 issue, so they haven't spend much time reviewing current work.
Caveat: everything is subject to change, especially because it hasn't been approved. This should be a good first start on how 3G wireless accounting could use Diameter. The purpose is to stimulate interest in using Diameter as 3G accounting protocol.
Reasons for presentation;
1) Real-time accounting needs more specific descriptions of processes. Real-time charging will need data acquisition, to do complete processing within 1 second time. The Diameter network should be architected to support this. Also a lower class service, "near-real-time".
2) Protocol applications need to be defined elsewhere. Extensions are probably needed, or at least AVPs defined, for 3G accounting.
Discussion from floor at this time, alternated around getting definitions, and incorporating them into the drafts. This WG cannot define every application, and needs external inputs. However there seems to be some concern that some external developments may not be suitable and this group could do better. Discussion best taken offline, in the interest of progress in the meeting.
Scenarios using Pre-paid services, Third party services, Roaming were presented. Data and flow requirements were outlined. These need to be reviewed.
Another scenario of an Electronic wallet service using "near real-time" and "off-line" support. Packets would go through some mediation function, determine currency conversion, and approve or disapprove transaction. This would need accounting, authorization, and authentication features as well, and this is one of the deficiencies of GTP-prime.
Issues are outstanding on using wireless for credit cards and encryption as well as all 3 A's.
Third scenario, Complexity introduced when 2 operators are involved. Roaming introduces latency, and these new services may not be able to meet 1 second threshold in this environment. TAP3 exchanges data under a fraud threshold of 36 hours - not intended for real-time operations. Probably not a possibility for real-time, but maybe for near real-time and batch. Again, GTP-prime can't do the roaming.
Conclusion - Encourage people assist SA5 to meet the requirements of these scenarios. Diameter is in competition with GTP-prime, but belief is GTP-prime will not handle all services. Diameter could, but must meet Release 5 timeframe, which is March 02.
Discussion attempted to clarify how we would "assist" SA5, but was inconclusive, and curtailed for meeting time.
HTTP Authentication with EAP
Jari Arkko (Ericsson)
draft-torvinen-http-eap-00.txt
Current SIP authentication schemes are TLS, IKE/IPSec - below SIP, and HTTP basic/digest, PGP - inside SIP. Work going on to refine some of these methods. Need to extend Diameter protocol if we want to implement some of these methods over AAA.
Suggesting adding HTTP EAP, Alternative HTTP authentication method, and reuse existing AAA protocols directly May also reduce the need for having special Diameter AKA extensions via draft-arkko-pppext-eap-aka-00.txt
EAP allows to N RFCs instead of NxM methods, which gives commonality to reduce number of Diameter RFCs and others.
Conclusions:
Reduce the number of RFCs needed,
UMTS AKA auth available even via NASREQ,
Some SIP AAA RFCs,
Don't invent N new generic authentication schemes.
Comment: if we stuff too much into NASREQ, there may be side effects.
AKA in Diameter has been proposed before, but putting it in EAP is a better idea.
Diameter Mobile IPv6 Application
draft-le-aaa-mobileipv6-00.txt
Faccin, Le, Paril, Perkins
Mobile IPv6 does not define inter-domain roaming, we will need to define interaction with AAA for deployment and Billing/accounting.
Current Diameter MIP application is not enough. Mobile IPv46 is a different architecture with no Foreign Agent.
Basic Proposed Model: Same as MIPv4 model, but replace FA with "AAA Client"
Optional Features: key distribution for MIP, MN-MAgents, others Secure dynamic Home Agent assignment, optimized means of BUs Only one round trip required.
The authors assert that a MIPv6 app is needed and ask the working group;
Where should work be done? What should be starting point?
The discussion brought out several points. Our current charter only covers MIPv4, and that draft needs to be completed. MIPv6 would be a new effort, and we should consider it as a new charter item, but we also need information on MIPv6's completeness in authentication, and their schedule. Discussion was stopped for time.
AAA Local Security Association (LSA): The Temporary Shared Key (TSK)
Franck Le (franck.le@nokia.com)
draft-le-aaa-lsa-tsk-00.txt
TSK is a secure mechanism to setup a LSA between the MN and visited domain
Framework: long-term SA is available between visitor and home domain
Establish TSK with visited domain, Then establish LSA with visited domain.
Could be used in any Diameter Application (Mobile IPv4, ...) to authenticate and distribute keys.
TSK benefits: Enables freqeunt user authentications, Enables frequent refreshing of the LSA, Doesn't involve home domain.
Two usages; Embedded in each application, however, may interfere with last-call drafts, New application: independent, but less optimized.
Suggestion: new application, but future apps can define embedding
Digest Authentication in SIP using RADIUS
Baruch Sterman - Did not show.
Mapping of Basic/Digest Authentication to Diameter AAA messages
Sengodan Senthil (Nokia)
Problem Scenario is a Front-end protocol like SIP/HTTP, which carries basic/digest authentication, and a Back-end Diameter framework. Difference from AKA in EAP is that EAP is not used in front end.
For SIP the resource is the userinfo, host and port part of the SIP Request-URI, For HTTP the resource is the canonical root URL. The realm defines the protection scheme.
Given a Resource, a Challenge, and a Response; we propose to have three new AVPs. Proposed in the draft with respect to NASREQ, but believe it is better to define a new application.
A new AVP (resource) goes in DIAMETER auth-request, A new AVP (challenge) goes in DIAMETER autho-answer and a second Auth Request includes Resource and Response. The Response carries entire digest response.
Some advantages are; Less overhead at Diameter client, Proposed AVPs are generic, could go in other Diameter applications, New application would be lightweight and Diameter client/server may not need to support NASREQ.
Suggestion from the floor; Another way might be to define EAP type for digest, then use existing AVPs on Diameter side.
----
End of the meeting Wrap up:
We have about 18 issues open, mostly editorial. The closure date is Aug. 20th. Then we go to IETF last call, which is open for two weeks. If any substantial technical changes occur, we may need to reestablish consensus, before closing WG last call.
The WG Charter called out Mobile IP, NASREQ, TIA 45.6 which was folded into Mobile IP. That is the focus of the work to-date. We need to finish these documents before taking on anything else. Separately, we also need to deliver a MIB document, which has not been attended to recently.
What was brought up was possibility of more applications like MIPv6, SA5 accounting, SIP At this time we cannot consider doing that, however, that is clearly topic for discussion later.
Randy, our AD suggested that one way of proceeding would be to get these documents through IETF last call & IESG review. Then once done IETF last call, re-charter the working group, include MIB work, start doing applicability statement RFCs: on "How to use the Diameter protocol with..." specific applications of the protocol.
The chair noted that there will be need to be continuing maintenance work on Diameter as it progresses from Proposed Standard to Draft Standard. Though it was noted that this work could be done separately.
People working on applications of Diameter, do not have to wait for the chartering issues to settle to write new drafts proposing or explaining application designs, and submitting them for comment.
Diameter Issues
EAP Authentication for SIP & HTTP
Diameter Mobile IPv6 Application
Local Security Association (LSA) & The Temporary Shared Key (TSK)
Mapping of Basic/Digest Authentication to DIAMETER AAA messages