time)Minutes of the AAA WG meeting in Vienna, Wed July 16 2003 at 1300-1500
CHAIRS: Bernard Aboba <firstname.lastname@example.org>
David Mitton <email@example.com>
Scribe: Jari Arkko <firstname.lastname@example.org>
o Preliminaries (10 minutes)
- Agenda Bashing
- Document Status
Diameter transport specification is now RFC 3539.
Diameter base status is unknown. It is claimed to be held up by IANA
considerations, but IANA does not respond to e-mail and according to the
authors the IANA issues should have been resolved already. The chairs and
editors will ping the RFC editor and IANA for the status.
IESG review has been completed on Diameter MIPv4 draft (-14).
AAA WG Last Call has been completed on Diameter NASREQ draft (-12).
Work in progress includes the following:
- Diameter EAP application
- Diameter credit control application
Initial reviews are in progress with the following:
- Diameter multimedia application
Dropped due to lack of interest
- Diameter CMS (end-to-end security)
o Diameter MIPv4 (15 minutes), Tom Hiller
- Tom has edited AAA-keys since January, which works closely with the
- Draft provides registration support for mobile nodes, as well as key
distribution. AAA keys update: delivers MN-FA and MN-HA keys to the
mobile, using nonces generated by the home AAA.
- Security update is needed, since the AAA WG dropped support of CMS.
Guidance from the IESG says that we should give the keys only those
entities that really need them. The implication is that since current
draft sends the keys in the clear through the AAAF, this needs to be
- One solution is to use Redirects. Not clear to the author how to
eliminate the AAAF involvement, however. Decided to take a look at other
issues. Instead, take the keys out of some of the messages, and use a
separate TLS connection where the keys are sent. This adds some extra
- But the author wants to keep the AAAF in the loop as much as
possible, just get it out of handling keys. New Diameter commands
allocated for the purpose of requesting and sending keys between the HA and
the AAAH, or AAAF and AAAH.
- As a result, only the HA and FA see the keys, AAAF and brokers do not
see keys. May create some extra latency. AAAF still sees
- There is a possible security hole of a rogue AAA node in the home
network, where AAA broker lies about the identity of the home agent. The
author does not think is a practical issue.
- Proposed plan is to review slides and current draft. Post a new
version in about three weeks.
- Bernard Aboba: Dramatic similarities between Diameter EAP and this
approach. Looks good that we are converging. Even the
authorization issue is the same.
- Jari Arkko: I agree that the issues are the same.
o Diameter NASREQ (15 minutes), Bernard Aboba on behalf of David Mitton
- Issues closing 402, 403, 404, 405, 406
- Issues open: 402, 404
- Next steps: review all the changes
- No more issues accepted at this time, unless they expose serious
- New draft version to be published and presened for IESG review, real
o Diameter EAP (15 minutes), Jari Arkko on the behalf of Pasi Eronen
- Diameter-eap-02 is a "RFC 2869bis" plus key AVPs
- Uses roughly the same approach as MIPv4 & AAA keys in avoiding key
exposure to proxies.
- Still problematic to do authz check for NAS-Server after redirect -
certs extensions, domain checks, ...
- Bernard: need to think about the reasons why NASes use proxies. In some
cases if they had e.g. real tables they might not need to use proxies, and
they could go direct
- (Someone) This is a general problem, has appeared in other
o System level security and keying transport issues (30 minutes),
- Slide 6: Russ wants to have a mandatory protocol and algorithm, but the
current mandatory method does not generate keys in EAP.
Russ Housley: I'm happy with your answer on the slide, but we should
require key-generating methods to be used when AAA is used.
- Slide 7: Russ wants to have strong, fresh session keys. It turns out
that in some cases the EAP methods do not provide freshness. It may be
necessary to add a key freshness requirement for methods in RFC 2284bis
- Slide 8: We need to authenticate all parties, no plaintext
We provide this as follows:
- No PAP i.e. no plaintext passwords.
- Diameter supports mutual authentication.
- Remaining issue is authorization.
What does maintain confidentiality of the authenticator mean?
Russ Housley: I didn't want identity privacy. Just that if you have a
secret, you don't disclose it in an inappropriate manner.
- Slide 9: We need to perform client and nas authorization: this one is
kind of interesting as we learned from Jari's presentation. We're still
working that too. But we are making some progress in understanding how we
can detect that the NAS is lying.
- Slide 10: We need to maintain confidentiality of the session keys:
redirect can restrict the MSK to only those nodes that have a need to
- Slide 11: We need to confirm selection of best ciphersuite. We
understood this to affect all legs of the triangle. An open issue is
whether we should require that ciphersuite negotiation in EAP (if
provided by methods) be protected?
- Slide 12: We need to uniquely name the session keys: This is work in
progress. On the list, we have discussed the naming of the EAP SAs, based on
peer and serve names, and pairwise nonces.
Russ Housley: is the MK somehow related to the SA?
Another issue: What to use as NAS name? Bernard thinks
Called-Station-Id AVP is the best candidate, because in 802.11i this will be
the MAC address of the NAS.
A third issue: We now know how to come up with the names. But how does
the nas get to know the names?
Jari: Why do we need to name SAs?
Bernard Aboba: Partially due to new functions such as roaming, but
mainly because roaming has shown us that this is an issue. It could
happen elsewhere too.
Russ Housley: If you can't name something, its hard to manage it, i.e.
communicate it over the network, delete it etc.
- Slide 13: Compromise of a single NAS cannot compromise any other part of
- Slide 14: Bind the key to appropriate context. In the
peer-server case this is implicit, there is no delete message. In the
NAS-peer case it is the responsibility of the secure association
protocol, such as the 802.11i 4-way handshake. In the AAA-NAS case it is
unclear. Does the key name need to be provided along with the key? Sense is
Russ Housley: well, if some of the components are available, maybe not
all have to be sent. If you hash names and nonces separately then you have to
communicate a lot smaller amount of data.
Bernard Aboba: What other AVPs are needed to define the context?
Russ Housley: how does the integrity mechanism protect this?
Bernard Aboba: It's over the whole AAA request. If it goes through a
proxy, the binding is not clear. If you have end-to-end security or
redirects there is no issue. Russ Housley: Ok, but you took a narrow
context. Its not just where, but also how it is used. E.g. MSK used as some
- The summary is as follows:
. We are making progress.
. Key naming and binding issues are the most challenging along with AAA
. System analysis work will occur in EAP WG as a part of the keying
o Diameter Credit Control Application (15 minutes), John Loughney
- The editors have done a heavy edit, but apologize since they
couldn't do a thorough review at the end.
- The goal of the draft is a generic credit control scheme, for 3GPP as
well as WLAN. Should interwork with existing AAA protocols.
- The draft has been updated to authorization-based model instead of an
accounting based application, due to earlier discussion on the list.
The main changes are:
- introduction and architecture diagram
- new commands and AVPs
- updated protocol operation, state machines, and examples
- Tom Hiller: Why not submit proposals that use your messages, but use a
John Loughney: It would be general service.
Tom Hiller: Or just one set of command codes, but different usage --
diameter commands codes are hard to come by.
- Bernard Aboba: Is there a request here for a review?
- Tom Hiller: We can arrange that.
- tom: seems like you could substitue aa requests with mipv4 commands?
john: that's the idea, you can substitute any application.
- requests reviews from group
o Diameter Multimedia Application (15 minutes), M. Garcia-Martin
- This was originally a diameter application born in 3GPP for the IMS (IP
- There is interest to move this work to the IETF. When coming to the
IETF, we do not want to solve only the 3GPP specific problem, but a wider
- The draft provides SIP servers with authentication,
authorization, and accounting services. It is designed for SIP, i.e., RFC
3261. It includes 6 new Diameter commands and a few AVPs. It is a
solution for draft-ietf-sipping-aaa-req-03.
- Changes from version 00 are the following:
- Rewrote the whole draft, moved to XML,
- Clearly differentiate normative and informative text.
- Decoupling from SIP procedures.
- Editorial corrections.
- Next steps are as follows. Comments are coming in from reviewers.
Additional reviews are solicited. We need to analyze compatibility with
RADIUS, remove remaining 3GPP assumptions, crosscheck fullfillment of
requirements, and issue a new version of the draft as a WG item.
- Bernard Aboba: This is ok. But one question is what RADIUS
compatibility will be judged against, since there are no standards this
- (Someone): You do the SIP redirection through AAA, not sure if that's a
typical AAA function. Miguel Garcia: in a distributed case you need to have a
centralized database to say which server to go to. Its a routing
function. (Someone): This is more of a directory service than an AAA
service. Its just a redirection. Miguel Garcia: its not a static
directory server, the information may change dynamically.
o Roadmap (15 minutes) WG Chairs and ADs
- Next major steps in the WG are finishing MIPv4 and NASREQ drafts, and
then EAP or credit control in the next month or two.
- Multimedia application will become a WG item.