rfc3127.txt

RFC 的详细文档！

   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.



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


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.







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


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









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


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



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


   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.



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


   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.





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


   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