time)Minutes of the AAA WG meeting in Vienna, Wed July 16 2003 at 1300-1500

CHAIRS: Bernard Aboba <aboba@internaut.com>
        David Mitton <david@mitton.com>

Scribe: Jari Arkko <jari.arkko@piuha.net>

SLIDES: 
http://www.drizzle.com/~aboba/IETF57/AAA

NOTES: 

o Preliminaries (10 minutes)

  - Bluesheets
  - Minutes
  - Agenda Bashing

    No comments.

  - 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

  
http://www.ietf.org/internet-drafts/dra
ft-ietf-aaa-diameter-mobileip-14.txt

  - Tom has edited AAA-keys since January, which works closely with the 
MIPv4 draft

  - 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 
fixed.

  - 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 
latency.
  
  - 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 
authorization attributes.

  - 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

  
http://www.ietf.org/internet-drafts/dra
ft-ietf-aaa-diameter-nasreq-12.txt

  - 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 
problems.

  - New draft version to be published and presened for IESG review, real 
soon.

o Diameter EAP (15 minutes), Jari Arkko on the behalf of Pasi Eronen

  
http://www.ietf.org/internet-drafts/dra
ft-ietf-aaa-eap-02.txt

  - 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 
contexts.

o System level security and keying transport issues (30 minutes), 
Bernard Aboba

  
http://www.ietf.org/internet-drafts/dra
ft-aboba-eap-keying-framework-07.txt
  
http://www.drizzle.com/~aboba/IETF57/AAA/AAA-IETF57.ppt

  - 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 
(EAP WG).

  - Slide 8: We need to authenticate all parties, no plaintext 
authenticators.
    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 
know.

  - 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 
the system.

  - 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 
yes. 
    
    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 
other key.

  - The summary is as follows:

    . We are making progress.

    . Key naming and binding issues are the most challenging along with AAA 
authorization problems.

    . System analysis work will occur in EAP WG as a part of the keying 
framework document.


o Diameter Credit Control Application (15 minutes), John Loughney

  
http://www.ietf.org/internet-drafts/dra
ft-ietf-aaa-diameter-cc-00.txt

  - 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 
different procedure? 
    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

  
http://www.ietf.org/internet-drafts/dra
ft-belinchon-aaa-diameter-mm-app-01.txt

  - This was originally a diameter application born in 3GPP for the IMS (IP 
Multimedia System).

  - 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 
problem.

  - 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 
space.

  - (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.


SESSION END