tech-invite   World Map     

IETF     RFCs     Groups     SIP     ABNFs    |    3GPP     Specs     Glossaries     Architecture     IMS     UICC    |    search

RFC 3127

Pages: 84
Top     in Index     Prev     Next
in Group Index     Prev in Group     Next in Group     Group: AAA

Authentication, Authorization, and Accounting: Protocol Evaluation

Part 1 of 3, p. 1 to 20
None       Next RFC Part


Top       ToC       Page 1 
Network Working Group                                          D. Mitton
Request for Comments: 3127                               Nortel Networks
Category: Informational                                      M. St.Johns
                                                  Rainmaker Technologies
                                                              S. Barkley
                                                               D. Nelson
                                                      Enterasys Networks
                                                                B. Patil
                                                              M. Stevens
                                                       Ellacoya Networks
                                                                B. Wolff
                                                            Databus Inc.
                                                               June 2001

             Authentication, Authorization, and Accounting:
                          Protocol Evaluation

Status of this Memo

   This memo provides information for the Internet community.  It does
   not specify an Internet standard of any kind.  Distribution of this
   memo is unlimited.

Copyright Notice

   Copyright (C) The Internet Society (2001).  All Rights Reserved.


   This memo represents the process and findings of the Authentication,
   Authorization, and Accounting Working Group (AAA WG) panel evaluating
   protocols proposed against the AAA Network Access Requirements, RFC
   2989.  Due to time constraints of this report, this document is not
   as fully polished as it might have been desired.  But it remains
   mostly in this state to document the results as presented.

Top       Page 2 
Table of Contents

   1.  Process Description  . . . . . . . . . . . . . . . . . . . . . .3
   1.1  WG Co-Chair's Note  . . . . . . . . . . . . . . . . . . . . . .3
   1.2  Chairman's Note . . . . . . . . . . . . . . . . . . . . . . . .4
   1.3  Members Statements  . . . . . . . . . . . . . . . . . . . . . .4
   1.4  Requirements Validation Process . . . . . . . . . . . . . . . .6
   1.5  Proposal Evaluation . . . . . . . . . . . . . . . . . . . . . .7
   1.6  Final Recommendations Process . . . . . . . . . . . . . . . . .7
   2.  Protocol Proposals . . . . . . . . . . . . . . . . . . . . . . .8
   3.  Item Level Compliance Evaluation  . . . . . . . . . . . . . . . 8
   3.1  General Requirements . . . . . . . . . . . . . . . . . . . . . 9
   3.2  Authentication Requirements. . . . . . . . . . . . . . . . . .11
   3.3  Authorization Requirements . . . . . . . . . . . . . . . . . .12
   3.4  Accounting Requirements  . . . . . . . . . . . . . . . . . . .12
   3.5  MOBILE IP Requirements . . . . . . . . . . . . . . . . . . . .13
   4.  Protocol Evaluation Summaries . . . . . . . . . . . . . . . . .14
   4.1  SNMP . . . . . . . . . . . . . . . . . . . . . . . . . . . . .14
   4.2  Radius++ . . . . . . . . . . . . . . . . . . . . . . . . . . .14
   4.3  Diameter . . . . . . . . . . . . . . . . . . . . . . . . . . .14
   4.4  COPS . . . . . . . . . . . . . . . . . . . . . . . . . . . . .14
   4.5  Summary Recommendation   . . . . . . . . . . . . . . . . . . .14
   5.  Security Considerations . . . . . . . . . . . . . . . . . . . .14
   6.  References  . . . . . . . . . . . . . . . . . . . . . . . . . .15
   7.  Authors' Addresses. . . . . . . . . . . . . . . . . . . . . . .15
   A.  Appendix A - Summary Evaluations  . . . . . . . . . . . . . . .17
   B.  Appendix B - Review of the Requirements . . . . . . . . . . . .18
   B.1 General Requirements. . . . . . . . . . . . . . . . . . . . . .18
   B.2 Authentication Requirements . . . . . . . . . . . . . . . . . .19
   B.3 Authorization Requirements. . . . . . . . . . . . . . . . . . .19
   B.4 Accounting Requirements . . . . . . . . . . . . . . . . . . . .20
   C.  Appendix C - Position Briefs  . . . . . . . . . . . . . . . . .21
   C.1  SNMP PRO Evaluation  . . . . . . . . . . . . . . . . . . . . .21
   C.2  SNMP CON Evaluation  . . . . . . . . . . . . . . . . . . . . .28
   C.3  RADIUS+ PRO Evaluation . . . . . . . . . . . . . . . . . . . .33
   C.4  RADIUS+ CON Evaluation . . . . . . . . . . . . . . . . . . . .37
   C.5  Diameter PRO Evaluation  . . . . . . . . . . . . . . . . . . .44
   C.6  Diameter CON Evaluation  . . . . . . . . . . . . . . . . . . .50
   C.7  COPS PRO Evaluation  . . . . . . . . . . . . . . . . . . . . .55
   C.8  COPS CON Evaluation  . . . . . . . . . . . . . . . . . . . . .59
   D.  Appendix D - Meeting Notes  . . . . . . . . . . . . . . . . . .66
   D.1  Minutes of 22-Jun-2000 Teleconference  . . . . . . . . . . . .66
   D.2  Minutes of 27-Jun-2000 Teleconference  . . . . . . . . . . . .68
   D.3  Minutes of 29-Jun-2000 Teleconference  . . . . . . . . . . . .73
   D.4  Minutes of 06-Jul-2000 Teleconference  . . . . . . . . . . . .78
   D.5  Minutes of 11-Jul-2000 Teleconference  . . . . . . . . . . . .80
   Full Copyright Statement  . . . . . . . . . . . . . . . . . . . . .84

Top      ToC       Page 3 
1.  Process Description

   Due to time constraints, the original draft of this document was
   rushed to meet the publication deadline of the June 2000 Pittsburgh
   meeting.  Since the meeting has passed, we do not wish to
   substantially revise the findings within this document, so that we
   don't give the appearance of changing information after the
   presentation.  Only additional descriptions of the process,
   formatting, layout editing and errors of fact have been corrected in
   subsequent revisions.

1.1.  WG Co-Chair's Note:

   After the AAA WG re-charter was approved, and the Network Access
   Requirements document passed AAA WG Last Call, a Solicitation of
   Protocol Submissions was issued on 4/13/2000.  The Solicitation was
   sent to the AAA WG mailing list, as well as to other IETF WG mailing
   lists related to AAA, including NASREQ, Mobile IP, RAP, and SNMPv3.

   Submissions were solicited effective immediately.  Authors of
   candidate protocols were requested to notify the AAA WG chairs of
   their intent to submit a candidate protocol.  It was suggested that
   this notification be sent by May 1, 2000.

   Protocol submissions and compliance description documents were to be
   submitted in Internet Draft format by email to internet-  The deadline for submissions was June 1, 2000.  To
   be considered as a candidate, submissions needed to include an
   unqualified RFC 2026 statement, as described at:

   In order to assist the AAA WG in evaluating the protocol submissions
   and compliance description documents, the AAA WG chairs then formed
   an evaluation team, which was announced on May 20, 2000.  The job of
   the team was be to put together an Internet Draft documenting their
   evaluation of the protocol submissions.  The goal is to have a first
   draft available prior to the July 14, 2000 submission deadline for
   IETF 48.

   In composing the evaluation draft, the evaluation team was asked to
   draw from the protocol specifications, the compliance descriptions,
   and other relevant documents, the Network Access Requirements
   document, RFC 2989.

   Mike St. Johns was asked to chair the evaluation team.  The chairs of
   WGs related to AAA were also invited to join the team.  These
   included Dave Mitton, co-chair of NASREQ WG, Basavaraj Patil, co-
   chair of Mobile IP WG, and Mark Stevens, co-chair of the RAP WG.

Top      ToC       Page 4 
   Additional members of the evaluation team were chosen to represent
   the interests of network operators as well as developers of AAA
   client and server software.

   As usual, the IESG advised the evaluation team.  IESG advisors
   included Randy Bush and Bert Wijnen, Directors of the Operations and
   Management Area.

1.2.  Chairman's Note:

   This document is the result of 6 weeks of intense work by the panel
   listed below.  Our mission was to evaluate the various AAA proposals
   and provide recommendations to the AAA working group and to the IESG
   on the viability of each of the proposals.

   The evaluation process had three distinct phases.  1) Validate the
   AAA requirements document [AAAReqts] against the base requirements
   documents for NASREQ, MOBILEIP and ROAMOPS.  2) Evaluate each of the
   SNMP, Radius++, Diameter and COPS proposal claims against the
   validated requirements.  3) Provide final recommendations based on
   side by side comparison for each proposal on a requirement by
   requirement basis.

   In general, the ONLY information the evaluators were allowed to use
   throughout the process was that provided in the source documents (the
   requirements document and the proposal) or documents referenced by
   the source documents.  In other words, if it wasn't written down, it
   generally didn't exist.  Our cutoff for acceptance of information was
   1 June 2000 - any submissions after that time were not considered in
   the panel's deliberations.

1.3.  Members Statements

   The group was chaired by Michael St.Johns.  David Mitton was the
   document editor.  Following are the background statements and any
   conflicts of interest from them and the rest of the panel.

   Michael St. Johns, Rainmaker Technologies

   I have no known conflicts of interest with respect to the AAA
   process.  I have neither advocated nor participated in the creation
   of any of the submissions.  My company is a service company (ISP) and
   will not be involved in the manufacture or sale  of AAA enabled
   products.  Other than my participation as the chair of the AAA
   evaluation process, I have not had any contact with the AAA standards

Top      ToC       Page 5 
   David Mitton, Nortel Networks

   I have been Nasreq WG co-chair and author of several Nasreq drafts.
   As well as, previously contributed to several RADIUS drafts.

   I have been a RADIUS NAS implementor and Technical Prime on our
   Server products, so know it extremely well.  In my current job role I
   am involved with Nortel's IP Mobility products, which support

   I have written a presentation on COPS vs NASreq Requirements for a
   Nasreq meeting, but have not implemented it, nor consider myself an
   through expert on the subject.

   Stuart Barkley, UUNET

   I've been working for 5 years at UUNET on various parts of our dialup
   network.  I have extensive experience with designing, developing and
   operating our SNMP based usage data gathering system.  I've also been
   involved in our radius based authentication and authorization systems
   in an advisory position.

   I've participated in radius/roamops/nasreq/aaa groups for the past
   several years.  I'm not an author or contributer on any of the
   requirements or protocol documents being presented although I have
   been peripherally involved in these working groups.

   Dave Nelson, Enterasys Networks

   Very active in the RADIUS WG, especially during the early years.  No
   involvement in the AAA submission.  Have not contributed to the
   development of Diameter.

   No involvement with SNMPv3 or the AAA submission.  David Harrington,
   a proponent, works in a different group within my company.  We have
   not discussed the submission.  No involvement with the COPS protocol.

   Basavaraj Patil, Nokia

   I am a contributor to the AAA requirements document (RFC 2977)
   submitted by the Mobile IP WG.  I was a member of the team that was
   constituted to capture the Mobile IP requirements for AAA services.

   As part of the co-chairing activity of the Mobile IP WG I have
   realized the need for AAA services by Mobile IP and hence closely
   followed the work done in the AAA WG, RADIUS, RoamOps and TR45.6.

Top      ToC       Page 6 
   My present work at Nokia does involve looking at AAA protocols (to
   some extent at least) for use in wireless networks.  I have also done
   some work with AAA protocols such as Diameter in my previous job at
   Nortel Networks.

   Mark Stevens, Ellacoya Networks

   I am the co-chair of the IETF RAP working group which is the working
   group that has developed the COPS protocol.  I have not contributed
   to the documents describing how COPS can satisfy AAA requirements.

   I participated in early AAA working group meetings, but have not been
   an active participant since the group's rechartering.  The company
   that currently employees me builds devices might benefit from being
   AAA enabled.

   Barney Wolff, Databus Inc.

   I have implemented RADIUS client, proxy and server software, under
   contract to AT&T.  That software is owned by AT&T and I have no
   financial interest in it.

   I have been a member of the RADIUS WG for several years, and consider
   myself an advocate for RADIUS against what I consider unjustified
   attacks on it.

   I've never worked for any of the companies whose staff have produced
   any of the proposals, although I obviously might at some future time.

1.4.  Requirements Validation Process

   For each of the base requirements documents, the chair assigned a
   team member to re-validate the requirement.  The process was fairly
   mechanical; the evaluator looked at what was said in [AAAReqts], and
   verified that the references and supporting text in the basis
   document supported the requirement in [AAAReqts] as stated.  Where
   the reference was wrong, too general, missing or otherwise did not
   support the requirement, the evaluator either deleted or downgraded
   the requirement.  The results of that process were sent to the AAA
   mailing list and are also included in this document in the
   appendixes.  The group's used [AAAReqts] as modified by our
   validation findings to evaluate the AAA proposals.

Top      ToC       Page 7 
1.5.  Proposal Evaluation

   For each of the four proposals, the chair assigned two panel members
   to write evaluation briefs.  One member was assigned to write a 'PRO'
   brief and could take the most generous interpretation of the
   proposal; he could grant benefit of doubt.  The other member was
   assigned to write a 'CON' brief and was required to use the strictest
   criteria when doing his evaluation.

   Each brief looked at each individual requirement and evaluated how
   close the proposal came in meeting that requirement.  Each item was
   scored as one of an 'F' for failed to meet the requirement, 'P' for
   partially meeting the requirement, or 'T' for totally meeting the
   requirement.  The proposals were scored only on the information
   presented.  This means that a particular protocol might actually meet
   the specifics of a requirement, but if the proposal did not state,
   describe or reference how that requirement was met, in might be
   scored lower.

   The panel met by teleconference to discuss each proposal and the PRO
   and CON briefs.  Each of the briefers discussed the high points of
   the brief and gave his summary findings for the proposal.  We then
   discussed each individual requirement line-by-line as a group.  At
   the conclusion, the members provided their own line-by-line
   evaluations which were used to determine the consensus evaluation for
   the specific requirement relative to that proposal.  The meeting
   notes from those teleconferences as well as the individual briefs are
   included in the appendixes.

1.6.  Final Recommendations Process

   The panel met for one last time to compare the results for the four
   proposals and to ensure we'd used consistent evaluation criteria.  We
   did a requirement by requirement discussion, then a discussion of
   each of the protocols.

   The final phase was for each member to provide his final summary
   evaluation for each of the protocols.  Each proposal was scored as
   either Not Acceptable, Acceptable Only For Accounting, Acceptable
   with Engineering and Fully Acceptable.  Where a proposal was
   acceptable with engineering, the member indicated whether it would be
   a small, medium or large amount.

   It should be noted that score indicated the opinion of the team
   member.  And they may have taken into consideration background
   knowledge or additional issues not captured in the minutes presented

Top      ToC       Page 8 
   Each member's scores were used within the group to develop the
   group's consensus.

2.  Protocol Proposals

   The following proposal documents were submitted to the AAA WG for
   consideration by the deadline.

   - SNMP:

      [SNMPComp] "Comparison of SNMPv3 Against AAA Network Access
                  Requirements", Work in Progress.

   - RADIUS Enhancements:

      [RADComp]  "Comparison of RADIUS Against AAA Network Access
                  Requirements", Work in Progress.

      [RADExt]   "Framework for the extension of the RADIUS(v2)
                  protocol", Work in Progress.

   - Diameter

      [DIAComp]  "Comparison of Diameter Against AAA Network Access
                  Requirements", Work in Progress.

   - COPS for AAA:

      [COPSComp] "Comparison of COPS Against the AAA NA Requirements",
                  Work in Progress.

      [COPSAAA]  "COPS Usage for AAA", Work in Progress.

3.  Item Level Compliance Evaluation

   For each requirement item, the group reviewed the proposal's level of
   compliance.  Where the proposal was lacking, the evaluators may have
   made supposition on how hard it would be to resolve the problem.  The
   following shows the consensus results for each requirement item.

   T = Total Compliance, Meets all requirements fully
   P = Partial Compliance, Meets some requirements
   F = Failed Compliance, Does not meet requirements acceptably

   Where two are shown eg: P/T, there was a tie.

Top      ToC       Page 9 
   The sub-section numbering corresponds to the requirements document
   section and item numbers.  This relative numbering was also used in
   the Protocol Position presentations, here in the appendices.

3.1 General Requirements

   3.1.1 Scalability - SNMP:P, RADIUS:P, Diameter:T, COPS:T

   SNMP was downgraded due to a lack of detail of how the current agent
   model would be adapted to a client request based transaction.  The
   RADIUS proposal did not address the problem adequately.  There are
   open issues in all proposals with respect to webs of proxies.

   3.1.2 Fail-over - SNMP:P, RADIUS:P, Diameter:P, COPS:T/P

   The group particularly noted that it didn't think any protocol did
   well in this requirement.  Insufficient work has been done to specify
   link failure detection and primary server recovery in most
   submissions.  COPS has some mechanisms but not all.  How these
   mechanisms would work in a web of proxies has not been addressed.

   3.1.3 Mutual Authentication  - SNMP:T, RADIUS:T/P, Diameter:T, COPS:T

   Many of the submissions missed the point of the requirement.  There
   should be a way for the peers to authenticate each other, end-to-end,
   or user-to-server.   However, the group questions who really needs
   this feature, and if it could be done at a different level.

   Mutual authentication in RADIUS is only between hops.

   3.1.4 Transmission Level Security  - SNMP:T, RADIUS:P, Diameter:T,

   All protocols have methods of securing the message data.

   3.1.5 Data Object Confidentiality  - SNMP:P, RADIUS:P, Diameter:T,

   This requirement usually comes from third-party situations, such as
   access outsourcing.

   Diameter and COPS both use CMS formats to secure data objects.  The
   group is concerned if this method and it's support is perhaps too
   heavy weight for NAS and some types of edge systems.

Top      ToC       Page 10 
   3.1.6 Data Object Integrity  - SNMP:F, RADIUS:P, Diameter:T, COPS:T

   How to guard the data object from changes was not adequately
   described in the SNMP proposal.  The RADIUS solution was not very
   strong either.

   3.1.7 Certificate Transport  - SNMP:T, RADIUS:T, Diameter:T, COPS:T

   All protocols can figure out some way to transport a certificate.

   3.1.8 Reliable AAA Transport  - SNMP:P, RADIUS:P, Diameter:T, COPS:T

   The requirement does not give a definition of "how reliable" it must

   The SNMP and RADIUS proposals lacked in providing solutions to
   message retransmission and recovery.

   3.1.9 Run over IPv4  - SNMP:T, RADIUS:T, Diameter:T, COPS:T

   3.1.10 Run over IPv6  - SNMP:P, RADIUS:T, Diameter:T, COPS:T

   The SNMP proposal indicated that this area is still in the
   experimental stages.

   3.1.11 Support Proxy and Routing Brokers  - SNMP:F, RADIUS:P,
   Diameter:T, COPS:P

   The SNMP proposal did not address this requirement.  COPS claims
   support, but does not work through some of the issues.  Diameter was
   the only protocol that attempted to address this area to a fair

   3.1.12 Auditability - SNMP:F, RADIUS:F, Diameter:T, COPS:P

   We treated this requirement as something like "non-repudiation".
   There is a concern that digital signatures may be too computationally
   expensive for some equipment, and not well deployed on those

   The SNMP and RADIUS proposals did not attempt to work this
   requirement.  COPS suggests that a History PIB will help solve this
   problem but gives no description.

Top      ToC       Page 11 
   3.1.13 Shared Secret Not Required  - SNMP:P/T, RADIUS:T, Diameter:T,

   The requirement is interpreted to mean that any application level
   security can be turned off in the presence of transport level

   Pretty much every protocol can use an enveloping secure transport
   that would allow them not to use an internal secret.

   3.1.14 Ability to Carry Service Specific Attributes  - SNMP:T,
   RADIUS:T, Diameter:T, COPS:T

3.2 Authentication Requirements

   3.2.1 NAI Support  - SNMP:T, RADIUS:T, Diameter:T, COPS:T

   3.2.2 CHAP Support  - SNMP:T, RADIUS:T, Diameter:T, COPS:T

   3.2.3 EAP Support  - SNMP:T, RADIUS:T, Diameter:T, COPS:T

   3.2.4 PAP/Clear-text Passwords  - SNMP:T, RADIUS:T, Diameter:T,

   The requirement for clear-text passwords comes from one-time-password
   systems and hard-token (SecurID) systems.

   3.2.5 Reauthentication on demand - SNMP:T, RADIUS:P, Diameter:P,

   To supply this, the proposal must have asynchronous peer-to-peer
   capabilities, and there must defined operation for such state

   We also distinguished event-driven Reauthentication from timer-driven
   (or lifetime-driven).  Also concerned about how this would work in a
   proxy environment.

   3.2.6 Authorization w/o Authentication - SNMP:P, RADIUS:T/P,
   Diameter:T, COPS:T

   This requirement really means authorization with trivial
   authentications (e.g. by assertion or knowledge).

Top      ToC       Page 12 
3.3 Authorization Requirements

   3.3.1 Static and Dynamic IP Addr Assignment - SNMP:P/F, RADIUS:T,
   Diameter:T, COPS:T

   There is difficulty in interpreting what is static or dynamic with
   respect to the viewpoint of the client, server, administrator or

   3.3.2 RADIUS Gateway Capability  - SNMP:P, RADIUS:P, Diameter:T/P,

   It was noted that any new capability in a new AAA protocol would not
   be able to map directly back to RADIUS.  But this is already a
   problem within a RADIUS environment.

   3.3.3 Reject Capability  - SNMP:T/P/F, RADIUS:T, Diameter:T, COPS:P

   3.3.4 Preclude Layer 2 Tunneling  - SNMP:F, RADIUS:T, Diameter:T,

   3.3.5 Reauthorization on Demand  - SNMP:P/F, RADIUS:P, Diameter:T/P,

   Some evaluators wondered how the server will know that re-
   authorization is supposed to be done?  Will it interface to something
   external, or have sufficient internals?

   3.3.6 Support for Access Rules & Filters  - SNMP:P, RADIUS:P,
   Diameter:P, COPS:T/P

   Only the Diameter proposal actually tackled this issue, but the group
   felt that the rules as designed were too weak to be useful.  There
   was also concern about standardizing syntax without defining

   3.3.7 State Reconciliation - SNMP:F, RADIUS:P/F, Diameter:P, COPS:T/P

   All of the protocols were weak to non-existent on specifying how this
   would be done in a web of proxies situation.

   3.3.8 Unsolicited Disconnect  - SNMP:T, RADIUS:P, Diameter:T, COPS:T

3.4 Accounting Requirements

   3.4.1 Real Time Accounting  - SNMP:T, RADIUS:T, Diameter:T, COPS:T

Top      ToC       Page 13 
   3.4.2 Mandatory Compact Encoding  - SNMP:T, RADIUS:T, Diameter:T,

   3.4.3 Accounting Record Extensibility  - SNMP:T, RADIUS:T,
   Diameter:T, COPS:T

   3.4.4 Batch Accounting  - SNMP:T, RADIUS:F, Diameter:P, COPS:P

   Some members of the group are not sure how this fits into the rest of
   the AAA protocol, which is primarily real-time and event driven.
   Would this be better met with FTP?

   3.4.5 Guaranteed Delivery   - SNMP:T, RADIUS:T, Diameter:T, COPS:T

   3.4.6 Accounting Timestamps       - SNMP:T, RADIUS:T, Diameter:T,

   3.4.7 Dynamic Accounting  - SNMP:T, RADIUS:T, Diameter:T, COPS:T

3.5 MOBILE IP Requirements

   3.5.1 Encoding of MOBILE IP Registration Messages  - SNMP:T,
   RADIUS:T/P, Diameter:T, COPS:T

   3.5.2 Firewall Friendly   - SNMP:F, RADIUS:T, Diameter:P, COPS:P

   There was considerable discussion about what it means to be "firewall
   friendly".  It was suggested that not making the firewall look into
   packets much beyond the application port number.  Protocols such as
   SNMP and COPS are at a disadvantage, as you must look far into the
   packet to understand the intended operation.  Diameter will have the
   disadvantage of SCTP, which is not well deployed or recognized at the

   SNMP and COPS also have the problem that they are used for other
   types of operations than just AAA.

   Should firewalls have AAA Proxy engines?

   We didn't look at "NAT friendly" issues either.


   The group is not clear on how this requirement impacts the actual
   protocol.  Raj explained it to us, but we mostly took it on faith.

Top      ToC       Page 14 
4.  Protocol Evaluation Summaries

4.1.  SNMP

   SNMP is generally not acceptable as a general AAA protocol.  There
   may be some utility in its use for accounting, but the amount of
   engineering to turn it into a viable A&A protocol argues against
   further consideration.

4.2.  Radius++

   Radius++ is not considered acceptable as an AAA protocol.  There is a
   fairly substantial amount of engineering required to make it meet all
   requirements, and that engineering would most likely result in
   something close to the functionality of Diameter.

4.3.  Diameter

   Diameter is considered acceptable as an AAA protocol.  There is some
   minor engineering required to bring it into complete compliance with
   the requirements but well within short term capabilities.  Diameter
   might also benefit from the inclusion of a broader data model ala

4.4.  COPS

   COPS is considered acceptable as an AAA protocol.  There is some
   minor to medium engineering required to bring it into complete
   compliance with the requirements.

4.5.  Summary Recommendation

   The panel expresses a slight preference for Diameter based on the
   perception that the work for Diameter is further along than for COPS.
   However, using SCTP as the transport mechanism for Diameter places
   SCTP on the critical path for Diameter.  This may ultimately result
   in COPS being a faster approach if SCTP is delayed in any way.

5.  Security Considerations

   AAA protocols enforce the security of access to the Internet.  The
   design of these protocols and this evaluation process took many
   security requirements as critical issues for evaluation.  A candidate
   protocol must meet the security requirements as documented, and must
   be engineered and reviewed properly as developed and deployed.

Top      ToC       Page 15 
6.  References

   [AAAReqts] Aboba, B., Clahoun, P., Glass, S., Hiller, T., McCann, P.,
              Shiino, H., Walsh, P., Zorn, G., Dommety, G., Perkins, C.,
              Patil, B., Mitton, D., Manning, S., Beadles, M., Chen, X.,
              Sivalingham, S., Hameed, A., Munson, M., Jacobs, S., Lim,
              B., Hirschman, B., Hsu, R., Koo, H., Lipford, M.,
              Campbell, E., Xu, Y., Baba, S. and E. Jaques, "Criteria
              for Evaluating AAA Protocols for Network Access", RFC
              2989, April 2000.

   [AAAComp]  Ekstein, TJoens, Sales and Paridaens, "AAA Protocols:
              Comparison between RADIUS, Diameter and COPS", Work in

   [SNMPComp] Natale, "Comparison of SNMPv3 Against AAA Network Access
              Requirements", Work in Progress.

   [RADComp]  TJoens and DeVries, "Comparison of RADIUS Against AAA
              Network Access Requirements", Work in Progress.

   [RADExt]   TJoens, Ekstein and DeVries, "Framework for the extension
              of the RADIUS (v2) protocol", Work in Progress,

   [DIAComp]  Calhoun, "Comparison of Diameter Against AAA Network
              Access Requirements", Work in Progress.

   [COPSComp] Khosravi, Durham and Walker, "Comparison of COPS Against
              the AAA NA Requirements", Work in Progress.

   [COPSAAA]  Durham, Khosravi, Weiss and Filename, "COPS Usage for
              AAA", Work in Progress.

7.  Authors' Addresses

   David Mitton
   Nortel Networks
   880 Technology Park Drive
   Billerica, MA 01821

   Phone: 978-288-4570

Top      ToC       Page 16 
   Michael StJohns
   Rainmaker Technologies
   19050 Pruneridge Ave, Suite 150
   Cupertino, CA 95014

   Phone: 408-861-9550 x5735

   Stuart Barkley
   22001 Loudoun County Parkway
   Ashburn, VA  20147  US

   Phone: 703-886-5645

   David B. Nelson
   Enterasys Networks, Inc. (a Cabletron Systems company)
   50 Minuteman Road
   Andover, MA 01810-1008

   Phone: 978-684-1330

   Basavaraj Patil
   6000 Connection Dr.
   Irving, TX 75039

   Phone: +1 972-894-6709

   Mark Stevens
   Ellacoya Networks
   7 Henry Clay Drive
   Merrimack, NH  03054

   Phone: 603-577-5544 ext. 325

   Barney Wolff, Pres.
   Databus Inc.
   15 Victor Drive
   Irvington, NY 10533-1919 USA

   Phone: 914-591-5677

Top      ToC       Page 17 
Appendix A - Summary Evaluations Consensus Results by Requirement
             and Protocol

   Requirement Section         SNMP      Radius++  Diameter  COPS
           1.1.1                P         P         T         T
           1.1.2                P         P         P       T/P
           1.1.3                T       T/P         T         T
           1.1.4                T         P         T         T
           1.1.5                P         P         T         T
           1.1.6                F         P         T         T
           1.1.7                T         T         T         T
           1.1.8                P         P         T         T
           1.1.9                T         T         T         T
           1.1.10               P         T         T         T
           1.1.11               F         P         T         P
           1.1.12               F         F         T         P
           1.1.13             P/T         T         T         T
           1.1.14               T         T         T         T

           1.2.1                T         T         T         T
           1.2.2                T         T         T         T
           1.2.3                T         T         T         T
           1.2.4                T         T         T         T
           1.2.5                T         P         P         T
           1.2.6                P       T/P         T         T

           1.3.1              P/F         T         T         T
           1.3.2                P         T       T/P         P
           1.3.3            T/P/F         T         T         P
           1.3.4                F         T         T         T
           1.3.5              P/F         P       T/P         T
           1.3.6                P         P         P       T/P
           1.3.7                F       P/F         P       T/P
           1.3.8                T         P         T         T

           1.4.1                T         T         T         T
           1.4.2                T         T         T         T
           1.4.3                T         T         T         T
           1.4.4                T         F         P         P
           1.4.5                T         T         T         T
           1.4.6                T         T         T         T
           1.4.7                T         T         T         T

           1.5.1                T       T/P         T         T
           1.5.2                F         T         P         P
           1.5.3                F         P         T         T

Top      ToC       Page 18 
Appendix B - Review of the Requirements

   Comments from the Panel on then work in progress, "Criteria for
   Evaluating AAA Protocols for Network Access" now revised and
   published as RFC 2989.  This became the group standard interpretation
   of the requirements at the time.

B.1 General Requirements

   Scalability - In clarification [a], delete "and tens of thousands of
   simultaneous requests."  This does not appear to be supported by any
   of the three base documents.

   Transmission level security - [Table] Delete the ROAMOPS "M" and
   footnote "6".  This appears to be an over generalization of the
   roaming protocol requirement not necessarily applicable to AAA.

   Data object confidentiality - [Table] Delete the MOBILE IP "S" and
   footnote "33".  The base document text does not appear to support
   this requirement.

   Reliable AAA transport mechanism - In clarification [h] delete
   everything after the "...packet loss" and replace with a ".".  The
   requirements listed here are not necessarily supported by the base
   document and could be mistakenly taken as requirements for the AAA
   protocol in their entirety.

   Run over IPv4 - [Table] Replace the MOBILE IP footnote "17" with
   footnote "33".  This appears to be a incorrect reference.

   Run over IPv6 - [Table] Replace the MOBILE IP footnote "18" with a
   footnote pointing to section 8 of [8].  This appears to be an
   incorrect reference.

   Auditability - Clarification [j] does not appear to coincide with the
   NASREQ meaning of Auditability.  Given that NASREQ is the only
   protocol with an auditability requirement, this section should be
   aligned with that meaning.

   Shared secret not required - [Table] General - This section is
   misleadingly labeled.  Our team has chosen to interpret it as
   specified in clarification [k] rather than any of the possible
   interpretations of "shared secret not required".  We recommend the
   tag in the table be replaced with "Dual App and Transport Security
   Not Required" or something at least somewhat descriptive of [k].
   Delete the NASREQ "S" and footnote "28" as not supported by the
   NASREQ document.  Delete the MOBILE IP "O" and footnotes "34" and 39"
   as not supported.

Top      ToC       Page 19 
B.2 Authentication Requirements

   NAI Support - [Table] Replace MOBILE IP footnote "38" with "39".
   This appears to be a more appropriate reference.

   CHAP Support - [Table] Delete MOBILE IP "O" as unsupported.

   EAP Support - [Table] Delete MOBILE IP "O" as unsupported.

   PAP/Clear-Text Support - [Table] Replace NASREQ footnote "10" with
   "26" as being more appropriate.  Replace ROAMOPS "B" with "O".  The
   reference text appears to not explicitly ban this and specifically
   references clear text for OTP applications.  Delete MOBILE IP "O" as

   Re-authentication on demand - Clarification [e] appears to go beyond
   the requirements in NASREQ and MOBILE IP.  [Table] Delete MOBILE IP
   footnote "30" as inapplicable.

   Authorization Only without Authentication - Clarification [f] does
   not include all NASREQ requirements, specifically that unneeded
   credentials MUST NOT be required to be filled in.  Given that there
   are no other base requirements (after deleting the MOBILE IP
   requirement) we recommend that clarification [f] be brought in line
   with NASREQ.  [Table] Delete MOBILE IP "O" and footnote "30".  The
   referenced text does not appear to support the requirement.

B.3 Authorization Requirements

   Static and Dynamic... - Clarification [a] appears to use a
   particularly strange definition of static and dynamic addressing.
   Recommend clarification here identifying who (e.g. client or server)
   thinks address is static/dynamic.  [Table] ROAMOPS "M" appears to be
   a derived requirement instead of directly called out.  The footnote
   "1" should be changed to "5" as being more appropriate.  A text
   clarification should be added to this document identifying the
   derived requirement.

   RADIUS Gateway capability - [Table] Delete the MOBILE IP "O" and
   footnote "30".  The referenced text does not appear to support the

   Reject capability - [Table] Delete the NASREQ "M" and footnote "12".
   The NASREQ document does not appear to require this capability.

Top      ToC       Page 20 
   Reauthorization on Demand - [Table] Delete the MOBILE IP "S" and
   footnotes "30,33" The referenced text does not support this

   Support for Access Rules... - Clarification [e] has a overbroad list
   of requirements.  NASREQ only requires 5-8 on the list, and as The
   MOBILE IP requirement is not supported by its references, this
   clarification should match NASREQ requirements.  [Table] Delete the
   MOBILE IP "O" and footnotes "30,37" as not supported.

   State Reconciliation - Clarification [f] should be brought in line
   with NASREQ requirements.  The clarification imposes overbroad
   requirements not required by NASREQ and NASREQ is the only service
   with requirements in this area.

B.4 Accounting Requirements

   Real-Time accounting - [Table] Replace MOBILE IP footnote [39] with a
   footnote pointing to section 3.1 of [3] as being more appropriate.

   Mandatory Compact Encoding - [Table] Delete MOBILE IP "M" and
   footnote "33" as the reference does not support the requirement.

   Accounting Record Extensibility - [Table] Delete NASREQ "M" and
   footnote "15" as the reference does not support the requirement.

   Accounting Time Stamps - [Table] Delete MOBILE IP "S" and footnote
   "30" as they don't support the requirement.  Replace MOBILE IP
   footnote "40" with a footnote pointing to section 3.1 of [3] as being
   more appropriate.

   Dynamic Accounting - [Table] Replace the NASREQ footnote "18" with a
   footnote pointing to section of [3].  Delete the MOBILE IP
   "S" and footnote "30" as the reference does not support the

   Footnote section.

   [40] should be pointing to 6.1 of [4].
   [41] should be pointing to 6.2.2 of [4].
   [45] should be pointing to 6.4 of [4].
   [46] should be pointing to 8 of [4].

Next RFC Part