Minutes of the Authentication, Authorization and Accounting WG 
(aaa)IETF 56, San Francisco, 
CA
Wednesday, March 19 at 
1300-1500
=================================
CHAIRS: Bernard Aboba 
<aboba@internaut.com>        David Mitton 
<david@mitton.com>
Scribe: Jari Arkko 
<jari.arkko@piuha.net>
1. Agenda Bashing & 
Administrativia
   No 
comments.
2. Document 
status
   The document status is as 
follows:
   - Diameter BASE-17 and TRANSPORT-12 are in the RFC Editor 
queue.
   - Diameter MIPv4-13 has completed IESG review, but is held waiting for an 
author update, as well as completion of the MIPv4/AAA keys draft, which has 
just been updated. 

   - Diameter NASREQ-11 completed AAA WG last call. Five issues remain 
open. 

   - Diameter EAP and CMS are in progress to be published in June and 
December, 2003. We are probably going to split key attributes from EAP to a 
separate draft to give more focus to the 
work.
   - New working group items include documents for Diameter key wrap, 
credit control, and 
multimedia.
3. Diameter NASREQ, David Mitton (10 
minutes)
   
http://www.ietf.org/internet-drafts/dra
ft-ietf-aaa-diameter-
nasreq-11.txt
   The latest draft was published Feb 14th. Changes in draft 11 include the 
fo
llowing:
   - Issues 389 and 395 have been 
closed.
   - Sections renumbered so that the outline is 
flatter.
   New issues have been filed against draft 11: 402, 403, 404, 405, 406 
Most serious things relate to RADIUS compatibility with ability to 
fallback to RADIUS-only AVPs from either the server or client 
side.
   The next steps for this document 
are:
   - David comes up with proposed changes and sends them to the mailing 
list
.
   - New issue acceptance to be closed 
soon.
   - New draft version to be published with the next month and be sent to 
the 
IESG.
4. Diameter Credit Control Application, John Loghney (10 
minutes)
   
http://www.ietf.org/internet-drafts/dra
ft-hakala-diameter-cr
edit-control-06.txt
   This draft will become a AAA WG work item after addressing initial 
review comments. The motivation for this work is on-line/prepaid 
accounting, which is popular in mobile networks.  The draft enhances 
Diameter base accounting messages with new AVPs, but there are no new 
messages. This work has been officially included in 3GPP 
specifications TS 32.225, which can be viewed at the 3GPP web site 
(www.3g
pp.org).
   Major changes in draft version 06 
include:
   - A server or client is not required to implement all 
functionality. That is, the M bit settings have been 
changed.
     Question: The 'M' bit does not reflect whether an AVP is 
mandatory to implement or not -- just whether a Diameter peer can 
discard it if it is not supported. Is the Credit Control using the 'M' bit 
cor
rectly?
   - New result code has been 
added.
   On the to do list there are the following items: editorial 
improvements, ID nits check, and working with 3GPP to ensure that it fits 
their needs. This may be possibly nearly ready for WG last 
call.
   Bernard Aboba: It is essential to get many reviewers. Can we get 3GPP 
comments on this? 

   John: Yes, the intention is to request a "3GPP last call" and ask for 
comments to be sent to the IETF AAA WG list. Comments from IETF and other 
groups are solicited as 
well.
   Next steps for this work 
are:   
   - Get reviews, address 
comments.   - Issue a new version as a WG work item. 

5. Credit Control and Prepaid Applications, Avi Lior (10 
minutes)
   
http://www.ietf.org/internet-drafts/dra
ft-lior-radius-prepai
d-extensions-00.txt
   Avi Lior, Bridgewater systems, talked about his draft on RADIUS 
prepaid extensions. Prepaid data services are very important to 3GPP, 
3GPP2, and WLAN. AAA infrastructure is central in these services. 3GPP2 and 
WLAN rely on RADIUS-based infrastructure. Deployment is happening 
today.
   Requirements for these services include service portability and 
continuity, no revenue leakage, support for multiple sessions, and 
support for different prepaid schemes. Good picture of the 
requirements in 
draft-francis-prepaid-00.txt.
   Bernard Aboba: What does "no revenue leakage" mean? 

   Avi Lior: If there are errors in the network, you want to make sure that 
you don't give free service. 

   Bernard Aboba: Is this the same as reliability of 
accounting?   Avi: Roughly speaking yes it 
is.
   Bernard Aboba: Who created the requirements draft, does this come from 
some standardization organization? 

   Avi: The requirements draft is not related to our 
work.
   One major difference in the approach of RADIUs pre-paid is that this is 
handled with authentication/authorization messages, not accounting 
messages. The Access request includes the prepaid operations and quota 
allocation. Additional quotas can be allocated using accounting 
messages, a new Access Request, or the use of RADIUS dynamic 
authorization 
[draft-chiba-radius-dynamic-authorization-07.txt]. The former two 
mechanisms are problematic in large 
networks.
   When the prepaid account runs out, the session is not directly 
terminated, but rather the user is directed to a web site to where he can, 
for instance, use a credit card to continue the use of the 
account.
   Bernard Aboba: Is RADIUS - Diameter translation for this 
application feasible? 
   Avi Lior: We need to look at this. 
   Bernard Aboba: So we do have a problem with this? 
   Avi Lior: The fact of life is that Diameter and RADIUS need to live 
side-by-side for a long time. If translation is not possible it is going to 
be a problem. 

6. Diameter Multimedia Application, Miguel Garcia (10 
minutes)
   
http://www.ietf.org/internet-drafts/dra
ft-belinchon-aaa-diam
eter-mm-app-00.txt
   This is a diameter application tailored for the 3GPP IP Multimedia 
Subsystem. Provides SIP servers with authentication, 
authorization, and accounting functionality. Includes 6 new commands and a 
few AVPs. This is an evolution of 
draft-johansson-aaa-diameter-mm-app-02.txt, and is a solution for 
draft-i
etf-sipping-aaa-req-02.txt.
   John Loghney: I was going to be mention that 
draft-ietf-sipping-aaa-req-02.txt is in WG last call. It is going to be 
discussed in the SIPPING meeting as well right after this 
meeting.
   Next steps for this work 
are:   
   - Get reviews, address 
comments.   - Issue a new version as a WG work item. 
   - Decouple from SIP 
procedures
   Bernard Aboba: Here too we will need significant review prior to 
making this an official WG work item. 

7. Diameter Session Mobility, Dan Forsberg (10 
minutes)
   
http://www.ietf.org/internet-drafts/dra
ft-liu-aaa-diameter-s
ession-mobility-00.txt
   Diameter base protocol can only handle static sessions, it can not 
handle session mobility. Diameter MIPv4 application suggests that a new 
session should be setup when movement happens. Dan's draft has a 
requirement that movements must be possible without causing any actions in 
the home 
network.
   Problem is that when movement has occurred, how does the home AAA send 
unsolicited messages to the foreign AAA? 
   James Kempf: Why does the home AAA server have to do it? 
   Dan Forsberg: There is AAAF on the picture as well, it is 
involved.
   The AAA mobility problem can be seen as a context transfer between two 
local AAA 
servers.
   Question: Why isn't the context transferred between access routers, 
rather than between AAA servers? Is this because of the difficulty of 
doing such transfers between providers? 

   James Kempf: There's a lot of roundtrips in this protocol.  Should this 
happen before, during, or after handover? 

   Dan Forsberg: This is an open issue. 
   James Kempf: Could the two AAA nodes act as Diameter peers and not go 
through proxies higher in the AAA hierarchy? 

   Dan Forsberg: It may be possible but then the old access router would 
have to know the address of the new access router. 

   Question: Can't this be learned through an inter-access point 
protocol
?
   James Kempf: It would be desirable to avoid additional roundtrips and 
just have the two access routers discuss with each other.  Anyway, this is 
just something to think about. 

   Dan: 
Yes.
   Someone: Is this mainly for Mobile IPv6 or for IPv4? Is this for 
foreign agents or for access routers? Can this be used in the 
co-located case? Wouldn't it be a problem if the both access router and 
foreign agents are used at the same time. If co-location is not used, then 
both would be handling AAA and it seems like a conflict would result. 

   Jessie Walker: One advantage of the hierarchical approach is that it 
allows the security properties to be stated. One can't pass around keys 
directly and maintain the desired security 
properties.
   Open 
issues:   - 
Security   - Performance and 
scalability   - Session updates between two different 
domains   - Relationship with mobility 
protocols   - Race condition requirements described in the 
draft
   Next 
steps:   - Further study with the Diameter MIPv4 
application.   - Performance 
measurements

8. Diameter APIs, Yoshihiro Obha and James Kempf (10 
minutes)
   
http://www.ietf.org/internet-drafts/dra
ft-ietf-aaa-diameter-
api-03.txt   
http://www.ietf.org/internet-drafts/dra
ft-ohba-aaa-diameter-
cxxapi-00.txt
   No one to present 
this.
9. Diameter Mobile IPv4, Tony Johansson (10 
minutes)
   
http://www.ietf.org/internet-drafts/dra
ft-ietf-aaa-diameter-
mobileip-13.txt
   No one to present 
this.
   Someone: I had a question on MIPv4. About nine months ago issue 326 was 
filed, but as I recall it hasn't been resolved. The Mobile IP WG should 
answer the issue but they have not done so 
yet.
   Bernard: Your issue is not listed as open. Checking the list, it says the 
status is Rejected. 

   Jari, do you remember anything about it?  

   Jari Arkko: No. 

   Bernard Aboba: Why don't you ask this question on the list? Maybe 
someone will remember. 


10. Diameter CMS, Stephen Farrell (10 
minutes)
    
http://www.ietf.org/internet-drafts/dr
aft-ietf-aaa-diameter
-cms-sec-04.txt
    No one to present 
this.
11. Issues in AAA Key Distribution (20 minutes), Russ 
Housley
    
http://www.ietf.org/internet-drafts/dr
aft-walker-aaa-key-di
stribution-00.txt
    Bernard Aboba: Let me start with some sobering facts: no AAA 
application supporting key distribution has ever been approved as an IETF 
Proposed Standard. RFC 2548 is Informational and 
vendor-specific. Diameter MIPv4 is blocked due to security issues. No 
progress on Diameter EAP or CMS.  

    So the question is: What does AAA WG need to do in order to make more 
progress? Are there aspects of the problem that we have missed? What 
criteria does the IESG expect us to meet? To answer these questions we have 
invited Russ Housley, the incoming security area director, to give us some 
adv
ice. 
    Russ Housley: Some people are concerned that working group outside the 
security area is designing a key management protocol. 
Why? 
    - Key management protocols are 
subtle. 
    - An expert can easily miss a 
flaw. 
    - Peer review by multiple experts is 
essential 
    There are also concerns with 
EAP: 
    - Employs new key distribution architecture, with poorly 
understood security properties. Three party models have been studied but 
these do not align directly with 
AAA. 
    - Select one e2e mechanism to protect distributed 
keys. 
    - Needs robust key naming 
scheme. 
    - Needs to establish fresh session keys i.e. not get the same key 
every 
time. 
    - The principle of least privilege not followed. That means the 
session keys should not be exposed to parties that do not have an 
absolute essential reason to see the key 
material.    
    An acceptable solution 
MUST: 
    - Be algorithm independent. For interoperability, select at least one 
suite of algorithms that MUST be 
implemented. 
    - Establish strong, fresh session keys. Maintain algorithm 
independe
nce. 
    - Include a replay detection mechanism for all 
exchanges. 
    - Authenticate all parties. Maintain confidentiality of the 
authenticator. Public key mechanisms could be used to send keys so that 
only the recipient who has the private key can come back with the sent key. 
No plaintext 
passwords. 
    The solution MUST 
also:
    - Perform client and NAS 
authorization 
    - Maintain confidentiality of the session 
keys. 
    - Confirm selection of the "best" 
ciphersuite. 
    - Uniquely name session 
keys.
    - Compromise of a single NAS cannot compromise any other part of the 
system, including session keys and long-term 
keys. 
    - Bind key to appropriate 
context. 
    To me, the question is what's next. This was what the 
requirements are and Bernard tells you more about how to get this 
done.  
    Someone: You mentioned EAP, will you reject EAP as well before it 
solves these problems? 

    Russ Housley: No, that's not what I meant. These issues will be 
presumably addressed in the EAP Keying Framework draft being worked on in 
EAP 
WG.  
    Bernard: Where do we go from 
here: 
    - We need a fresh start on Diameter MIPv4. Look at the whole system. 
Make it clear how to meet the requirements articulated by Russ. 
 
    - We need an EAP key framework document. This will describe the 
architecture and security requirements for each element of the system and 
analyze how they interact. It will also address key naming and binding 
issues. This is being done in the EAP WG in 
draft-aboba-pppext-key-problem-06.txt. The next revision will attempt to 
address Russ's requirements explicitly. 
 
    - Split out Diameter key wrap into separate document from Diameter EAP. 
This will allow more focus in this critical part of the document. 
   
    - Take a fresh look at Diameter CMS. Can we remove deployment 
barriers? Can we decrease complexity of the specification? Any 
implementation 
plans?
    Anybody want to comment on the barriers? 

    Jessie Walker: I think it's a curiosity. Is anyone going to 
implement Diameter CMS? If not, then why are we working on it? 

    Robert Moskowitz: I have a question. I'd like to know if there's any 
performance measurements that have been done with the Diameter CMS 
application? Its not very lightweight. It would be very worthwhile to get 
some numbers. 

    Bernard Aboba: Would the CMS numbers from pure CMS (not Diameter CMS) 
implementations be sufficient?  

    Robert Moskowitz: Not sure. 

    Russ Housley: the S/MIME group is doing interoperability tests and 
there should be at least 4-5 implementations for which you can get some 
performance data. 

    Jessie Walker: What comes to my mind is mainly the complexity. 
    If its too big for embedded implementations, it's the wrong 
specific
ation.
    Paul Funk: I suspect people are sufficiently happy with 
hop-by-hop security. Once Diameter starts to carry money in some format, 
then its an issue. 

    Bernard Aboba: But we do already have usage-based billing. 

    Paul Funk: Yes, if there would be attack that can be used to cause an 
incorrect bill to be sent. 

    Bernard Aboba: If you have an untrusted proxy handling accounting 
records and it is compromised, it can forge accounting data. Isn't that 
enou
gh?
    Randy Bush: I just wanted to remind the WG that not everybody is happy 
with hop-by-hop security. I have been warning about this before. And we are 
now paying for the proxy architecture, and we are unhappy. But we are far 
less unhappy than if the kind of attacks just were discussed were to 
happen
.
    Russ Housley: I wanted to clarify that the first slide was not a 
reason to say "STOP", but rather to make sure that the security area is 
invo
lved.

12. Any Other 
Business
    Francis Dupont: Now, Mobile IPv6 is ready. I propose to resume the work 
on AAA and Mobile IPv6. Bernard: Need to talk about this with the Mobile IP 
WG 
chairs.
Meeting adjourned.