Request for Comments: 3127 Nortel Networks
Category: Informational M. St.Johns
Rainmaker Technologies
S. Barkley
UUNET
D. Nelson
Enterasys Networks
B. Patil
Nokia
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.
Abstract
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.
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
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-
drafts@ietf.org. The deadline for submissions was June 1, 2000. To
be considered as a candidate, submissions needed to include an
unqualified RFC2026 statement, as described at:
http://www.ietf.org/Sec10.txt
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, RFC2989.
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.
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
process.
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
Diameter.
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 (RFC2977)
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.
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.
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
here.
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.
Key:
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.
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,
COPS:T
All protocols have methods of securing the message data.
3.1.5 Data Object Confidentiality - SNMP:P, RADIUS:P, Diameter:T,
COPS: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.
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
be.
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
extent.
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
platforms.
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.
3.1.13 Shared Secret Not Required - SNMP:P/T, RADIUS:T, Diameter:T,
COPS:T
The requirement is interpreted to mean that any application level
security can be turned off in the presence of transport level
security.
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,
COPS: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,
COPS:T
To supply this, the proposal must have asynchronous peer-to-peer
capabilities, and there must defined operation for such state
changes.
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).
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
user.
3.3.2 RADIUS Gateway Capability - SNMP:P, RADIUS:P, Diameter:T/P,
COPS: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,
COPS:T
3.3.5 Reauthorization on Demand - SNMP:P/F, RADIUS:P, Diameter:T/P,
COPS:T
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
semantics.
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
3.4.2 Mandatory Compact Encoding - SNMP:T, RADIUS:T, Diameter:T,
COPS: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,
COPS: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
moment.
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.
COPS:T
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.
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
COPS.
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.
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
Progress.
[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
EMail: dmitton@nortelnetworks.com
Michael StJohns
Rainmaker Technologies
19050 Pruneridge Ave, Suite 150
Cupertino, CA 95014
Phone: 408-861-9550 x5735
EMail: stjohns@rainmakertechnologies.com
Stuart Barkley
UUNET
F1-1-612
22001 Loudoun County Parkway
Ashburn, VA 20147 US
Phone: 703-886-5645
EMail: stuartb@uu.net
David B. Nelson
Enterasys Networks, Inc. (a Cabletron Systems company)
50 Minuteman Road
Andover, MA 01810-1008
Phone: 978-684-1330
EMail: dnelson@enterasys.com
Basavaraj Patil
Nokia
6000 Connection Dr.
Irving, TX 75039
Phone: +1 972-894-6709
EMail: Basavaraj.Patil@nokia.com
Mark Stevens
Ellacoya Networks
7 Henry Clay Drive
Merrimack, NH 03054
Phone: 603-577-5544 ext. 325
EMail: mstevens@ellacoya.com
Barney Wolff, Pres.
Databus Inc.
15 Victor Drive
Irvington, NY 10533-1919 USA
Phone: 914-591-5677
EMail: barney@databus.com
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
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 RFC2989. 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.
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
unsupported.
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
requirement.
Reject capability - [Table] Delete the NASREQ "M" and footnote "12".
The NASREQ document does not appear to require this capability.
Reauthorization on Demand - [Table] Delete the MOBILE IP "S" and
footnotes "30,33" The referenced text does not support this
requirement.
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 8.4.1.5 of [3]. Delete the MOBILE IP
"S" and footnote "30" as the reference does not support the
requirement.
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].
Appendix C - Position Briefs
C.1 SNMP PRO Evaluation
Evaluation of SNMP AAA Requirements
PRO Evaluation
Evaluator - Stuart Barkley
Ref [1] is "Comparison of SNMPv3 Against AAA Network Access
Requirements", aka 'the document'
Ref [2] is the aaa eval criteria as modified by us, aka 'the
requirements'
The document uses T to indicate total compliance, P to indicate
partial compliance and F to indicate no compliance. For each section
I've indicated my grade for the section. If there is a change, I've
indicated that and the grade given by the authors.
1 Per item discussion
1.1 General Requirements
1.1.1 Scalability - Grade T
The document indicates that SNMP can adequately handle that scale
from the requirements document. Since most current uses are ppp
connections and SNMP is already capable of handling the interface
table and other per session tables it is clear that basic capacity
exists. Additions to support other tables and variables scales in a
simple linear fashion with the number of additional variables and
protocol interactions. Regardless of the final selected protocol
handling the scaling required is not a trivial undertaking. SNMP can
draw upon existing network management practices to assist in this
implementation.
1.1.2 Fail-over - Grade T
SNMP is of vital importance to the operation of most networks.
Existing infrastructures can handle required failover or other
redundant operations.
1.1.3 Mutual Authentication - Grade T
The use of shared secrets described in the document is a well
understood method of integrity control. Although shared secrets
don't necessarily provide full authentication since other parties may
also have the same secrets, the level of authentication is sufficient
for the task at hand. In many cases the SNMP infrastructure will
already exist and shared secrets should already be properly managed
on an operational network. A failure of the SNMP shared secret
approach regardless of the AAA protocol will likely leave equipment
and systems open to substantial misuse bypassing any more elaborate
AAA authentication.
1.1.4 Transmission Level Security - Grade T
SNMPv3 provides many additional security options which were not
available or were more controversial in previous SNMP versions.
1.1.5 Data Object Confidentiality - New Grade P (from T)
The document discusses SNMPv3 which can provide data confidentially
for data passing over the wire. There is substantial implied AAA
architecture (brokers and proxies) in the requirements that full
conformance is difficult to determine. In particular, the evaluator
has difficulty with the concept of "the target AAA entity for whom
the data is ultimately destined", but will concede that the desired
requirement is only partially met (most especially with the transfer
of a PAP password).
1.1.6 Data Object Integrity - New Grade T (from P)
SNMP has full capabilities that allow the authentication of the data.
Brokers, proxies or other intermediaries in the data chain can verify
the source of the information and determine that the data has not
been tampered with. The document downgrades the grade to P because
of confusion over the integrity checking role of intermediaries.
1.1.7 Certificate Transport - Grade T
The requirements require the capability of transporting certificates
but do not have any specific use for the certificates. The
requirements make assumptions that the protocol selected will be
dependent upon certificates, but this is not necessarily true. SNMP
can transport arbitrary objects and can transport certificates if
necessary. The document indicates some issues with size of
certificates and current maximum practical data sizes, however if the
compact encoding requirement extends to the internal certificate
information this should be less of an issue.
1.1.8 Reliable AAA Transport - New Grade T (from P)
The requirements is stated rather strongly and makes substantial
assumptions of AAA protocol architecture and based upon current
protocols and their failings. SNMP allows for great flexibility in
retransmission schemes depending upon the importance of the data.
1.1.9 Run over IPv4 - Grade T
SNMP has operated in this mode for many years.
1.1.10 Run over IPv6 - New Grade T (from P)
SNMP must support IPv6 for many other systems so support for this
should be possible by the time the requirement becomes effective.
The document indicates that experimental versions satisfying this
requirement are already in existence.
1.1.11 Support Proxy and Routing Brokers - New Grade T (from P)
The requirements make significant assumptions about the final
architecture. It is well within the capabilities of SNMP to provide
intermediaries which channel data flows between multiple parties.
The document downgrades SNMPs compliance with this requirement due to
issues which are covered more specifically under "Data Object
Confidentially" which the evaluator has downgraded to P.
1.1.12 Auditability - New Grade T (from F)
Data flows inside SNMP are easily auditable by having secondary data
flows established which provide copies of all information to
auxiliary servers. The document grades this as a failure, but this
support is only minor additions within a more fully fleshed out set
of data flows.
1.1.13 Shared Secret Not Required - Grade T
Shared secrets are not required by SNMP. They are desirable in many
instances where a lower level does not provide the necessary
capabilities. The document supplies pointers to various security
modes available.
1.1.14 Ability to Carry Service Specific Attributes - Grade T
SNMP has long had the ability for other parties to create new
unambiguous attributes.
1.2 Authentication Requirements
1.2.1 NAI Support - Grade T
SNMP easily supports this. NAIs were defined to be easily carried in
existing protocols.
1.2.2 CHAP Support - Grade T
SNMP can easily provide objects to pass the necessary information for
CHAP operation.
1.2.3 EAP Support - New Grade T (from P)
SNMP can easily provide objects to pass the necessary information for
EAP operation. As with CHAP or PAP MIB objects can be created to
control this operation thus the upgrade from the document grade.
1.2.4 PAP/Clear-text Passwords - New Grade P (from T)
SNMP can easily provide objects to pass the necessary information for
PAP operation. The requirement about non-disclosure of clear text
passwords make assumptions about the protocol implementation. The
choice to use clear text passwords is inherently insecure and forced
protocol architecture don't really cover this. This requirement
grade is downgraded to P (partial) because the document does not
really address the confidentially of the data at application proxies.
1.2.5 Reauthorization on demand - Grade T
SNMP can easily provide objects to control this operation.
1.2.6 Authorization w/o Authentication - New Grade T (from T)
The document makes an incorrect interpretation of this requirement.
However, SNMP makes no restriction which prevents to desired
requirements. No actual change of grade is necessary, since both the
actual requirements and the incorrect interpretation are satisfied by
SNMP.
1.3 Authorization Requirements
1.3.1 Static and Dynamic IP Addr Assignment - Grade T
SNMP can easily provide objects to control this operation.
1.3.2 RADIUS Gateway Capability - Grade T
As the document describes, with the addition of any necessary
compatibility variables SNMP can be gatewayed to RADIUS applications.
1.3.3 Reject Capability - Grade T
Any of the active components in the SNMP based structure could decide
to reject and authentication request for any reason. Due to mixing
different levels of requirements the document doesn't attempt to
directly address this, instead indicating that a higher level
application can cause this operation.
1.3.4 Preclude Layer 2 Tunneling - New Grade T (from ?)
Nothing in SNMP explicitly interacts with the selection of any
tunneling mechanisms the client may select. The document author was
unclear about the needs here.
1.3.5 Reauth on Demand - Grade T
SNMP can easily provide objects to control this operation.
1.3.6 Support for ACLs - Grade T
The document indicates that should it be desired SNMP can provide
objects to control these operations. In addition, active components
can apply substantial further configurable access controls.
1.3.7 State Reconciliation - Grade T
The requirements describe an over broad set of required capabilities.
The document indicates concern over incompatibilities in the
requirements, however SNMP can provide methods to allow active
components to reacquire lost state information. These capabilities
directly interact with scalability concerns and care needs to be
taken when expecting this requirement to be met at the same time as
the scalability requirements.
1.3.8 Unsolicited Disconnect - Grade T
The document indicates that SNMP can easily provide objects to
control this operation.
1.4 Accounting Requirements
1.4.1 Real Time Accounting - Grade T
SNMP can provide this mode of operation. The document outlines
methods both fully within SNMP and using SNMP to interface with other
transfer methods. Many providers already use SNMP for real time
notification of other network events. This capability can directly
interact with scalability concerns and implementation care needs to
be taken to make this properly interact is large scale environments.
1.4.2 Mandatory Compact Encoding - Grade T
The document indicates the possibility of controlling external
protocols to handle data transmissions where the BER encoding of SNMP
objects would be considered excessive. SNMP BER encoded protocol
elements are generally in a fairly compact encoding form compared
with text based forms (as used in some existing radius log file
implementations). This interacts with the general requirement for
carrying service specific attributes and the accounting requirement
for extensibility. With careful MIB design and future work on SNMP
payload compression the SNMP coding overhead can be comparable with
other less extensible protocols.
1.4.3 Accounting Record Extensibility - Grade T
SNMP has a strong tradition of allowing vendor specific data objects
to be transferred.
1.4.4 Batch Accounting - Grade T
There are many methods which a SNMP based system could use for batch
accounting. The document discusses SNMP parameters to control the
batching process and indicates that certain existing MIBs contain
examples of implementation strategies. SNMP log tables can provide
accounting information which can be obtained in many methods not
directly related to real time capabilities. The underlying system
buffering requirements are similar regardless of the protocol used to
transport the information.
1.4.5 Guaranteed Delivery - Grade T
SNMP is very amenable to providing guaranteed delivery. Particularly
in a pull model (versus the often assumed push model) the data
gatherer can absolutely know that all data has been transfered. In
the common push model the data receiver does not know if the
originator of the data is having problems delivering the data.
1.4.6 Accounting Timestamps - Grade T
Timestamps are used for many SNMP based operations. The document
points at the DateAndTime textual convention which is available for
use. As with all environments the timestamps accuracy needs
evaluation before the information should be relied upon.
1.4.7 Dynamic Accounting - Grade T
As long as there is some way to relate multiple records together
there are no problems resolving multiple records for the same
session. This interacts with the scalability requirement and care
must be taken when implementing a system with both of these