rfc3127.txt

RFC 的详细文档！

Mitton, et al.               Informational                      [Page 6]

RFC 3127            AAA Protocol Evaluation Process            June 2001


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.




Mitton, et al.               Informational                      [Page 7]

RFC 3127            AAA Protocol Evaluation Process            June 2001


   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.





Mitton, et al.               Informational                      [Page 8]

RFC 3127            AAA Protocol Evaluation Process            June 2001


   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.







Mitton, et al.               Informational                      [Page 9]

RFC 3127            AAA Protocol Evaluation Process            June 2001


   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.








Mitton, et al.               Informational                     [Page 10]

RFC 3127            AAA Protocol Evaluation Process            June 2001


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








Mitton, et al.               Informational                     [Page 11]

RFC 3127            AAA Protocol Evaluation Process            June 2001


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