Tech-invite3GPPspaceIETFspace
959493929190898887868584838281807978777675747372717069686766656463626160595857565554535251504948474645444342414039383736353433323130292827262524232221201918171615141312111009080706050403020100
in Index   Prev   Next

RFC 3127

Authentication, Authorization, and Accounting: Protocol Evaluation

Pages: 84
Informational
Part 3 of 3 – Pages 55 to 84
First   Prev   None

Top   ToC   RFC3127 - Page 55   prevText

C.7 COPS PRO Evaluation

Evaluation of COPS AAA Requirements PRO Evaluation Evaluator - David Nelson Ref [1] is "Comparison of COPS Against the AAA NA Requirements", work in progress, a.k.a. 'the document' Ref [2] is RFC 2748 a.k.a. 'the protocol' Ref [3] is the AAA evaluation criteria as modified by us. Ref [4] is "AAA Protocols: Comparison between RADIUS, Diameter, and COPS" work in progress. Ref [5] is "COPS Usage for AAA", work in progress. This document uses T to indicate total compliance, P to indicate partial compliance and F to indicate no compliance. Section 1 - Per item discussion 1.1 General Requirements 1.1.1 Scalability - The document [1] claims "T", and the evaluator concurs. 1.1.2 Fail-over - The document [1] claims "T", and the evaluator concurs. 1.1.3 Mutual Authentication - The document claims "T", and the evaluator concurs. 1.1.4 Transmission Level Security - The document [1] indicates that transmission layer security, as defined in [3], is provided in the protocol, using the mechanisms described in [2]. It should be noted that this requirement is now a SHOULD in [3]. The document claims "T", and the evaluator concurs. 1.1.5 Data Object Confidentiality - The document [1] indicates that end-to-end confidentiality is provided using a CMS-data attribute, based in large part upon RFC 2630. The evaluator has not, at this time, investigated the applicability of RFC 2630 to the AAA work. The document claims "T", and the evaluator concurs.
Top   ToC   RFC3127 - Page 56
   1.1.6 Data Object Integrity - The document [1] indicates that data
   object integrity is provided using a CMS-data attribute, based in
   large part upon RFC 2630.  The evaluator has not, at this time,
   investigated the applicability of RFC 2630 to the AAA work.  The
   document claims "T", and the evaluator concurs.

   1.1.7 Certificate Transport - The document [1] indicates that
   certificate transport is provided using a CMS-data attribute, based
   in large part upon RFC 2630 and RFC 1510.  The evaluator has not, at
   this time, investigated the applicability of RFC 2630 to the AAA
   work.  The document claims "T", and the evaluator concurs.

   1.1.8 Reliable AAA Transport - The document [1] indicates that COPS
   uses TCP, which certainly meets the requirements for a reliable
   transport.  The document claims "T", and the evaluator concurs.

   1.1.9 Run over IPv4 - The document [1] claims "T", and the evaluator
   concurs.

   1.1.10 Run over IPv6 - The document [1] claims "T", and the evaluator
   concurs.

   1.1.11 Support Proxy and Routing Brokers - Reasonable detail of proxy
   operations is provided in [5].  The document [1] claims "T", and the
   evaluator concurs.

   1.1.12 Auditability - The document [1] alludes to a History PIB that
   would enable auditing without explaining how it would work.  The AAA
   Extension [5] does not provide additional insight.  The document
   claims "T", and the evaluator awards "P".

   1.1.13 Shared Secret Not Required - The document [1] claims "T" and
   the evaluator concurs.

   1.1.14 Ability to Carry Service Specific Attributes -  The document
   [1] claims "T", and the evaluator concurs.

   1.2 Authentication Requirements

   1.2.1 NAI Support - The document [1] indicates that NAI is to be
   supported in the Information Model, but notes that for cases where
   certificates are in use, the more restrictive syntax of RFC 2459
   applies.  The document claims "T", and the evaluator awards "P".

   1.2.2 CHAP Support - The document [1] claims "T", and the evaluator
   concurs.
Top   ToC   RFC3127 - Page 57
   1.2.3 EAP Support - The document [1] claims "T", and the evaluator
   concurs.

   1.2.4 PAP/Clear-text Passwords - The document [1] indicates
   compliance, presumably using a CMS-data attribute, based in large
   part upon RFC 2630.  The evaluator has not, at this time,
   investigated the applicability of RFC 2630 to the AAA work.  The
   document claims "T", and the evaluator concurs.

   1.2.5 Reauthentication on demand - The document [1] claims "T", and
   the evaluator concurs.

   1.2.6 Authorization w/o Authentication - This requirement, as applied
   to the protocol specification, mandates that non- necessary
   authentication credentials not be required in a request for
   authorization.  The actual decision to provide authorization in the
   absence of any authentication resides in the application (e.g. AAA
   server).  The document [1] claims "T", and the evaluator concurs.

   1.3 Authorization Requirements

   1.3.1 Static and Dynamic IP Addr Assignment -  The document [1]
   claims "T", and the evaluator concurs.

   1.3.2 RADIUS Gateway Capability - The document [1] claims "T", and in
   the absence of any detailed discussion of how this is accomplished,
   in either [1] or [5], the evaluator awards "P".

   1.3.3 Reject Capability - The document claims [1] "T" and the
   evaluator concurs.

   1.3.4 Preclude Layer 2 Tunneling - The document [1] claims "T", and
   in the absence of any detailed discussion of how this is
   accomplished, in either [1] or [5], the evaluator awards "P".

   1.3.5 Reauth on Demand -  The document [1] claims "T", and the
   evaluator concurs.

   1.3.6 Support for ACLs - The document [1] "T", and the evaluator
   concurs.

   1.3.7 State Reconciliation - The document [1] "T", and the evaluator
   concurs.

   1.3.8 Unsolicited Disconnect - The document [1] claims "T", and the
   evaluator concurs.
Top   ToC   RFC3127 - Page 58
   1.4 Accounting Requirements

   1.4.1 Real Time Accounting -  The document [1] claims "T", and the
   evaluator concurs.

   1.4.2 Mandatory Compact Encoding - Note that the term "bloated" in
   [3] is somewhat subjective.  The document [1] claims "T", and the
   evaluator concurs.

   1.4.3 Accounting Record Extensibility -  The document [1] claims "T",
   and the evaluator concurs.

   1.4.4 Batch Accounting - The protocol [2] [5] does not address how in
   detail this feature might be accomplished.  The document [1] claims
   "T", and the awards "P".

   1.4.5 Guaranteed Delivery - Guaranteed delivery is provided by TCP.
   The document [1] claims "T", and the evaluator concurs.

   1.4.6 Accounting Timestamps - The document [1] claims "T", and the
   evaluator concurs.

   1.4.7 Dynamic Accounting - The document [1] claims "T", and the
   evaluator concurs.

   1.5 MOBILE IP Requirements

   1.5.1 Encoding of MOBILE IP Registration Messages - The document [1]
   claims "T", and the evaluator concurs.

   1.5.2 Firewall Friendly - The document [1] claims "T", and the
   evaluator concurs.

   1.5.3 Allocation of Local Home Agent - The document [1] claims "T",
   and the evaluator concurs.

   2. Summary Discussion

   It may appear, upon initial inspection, that the evaluator has not
   lent a critical eye to the compliance assertions of the document [1].
   First, this memo is a "PRO" brief, and as such reasonable benefit of
   doubt is to be given in favor of the protocol submission.  Second,
   there is a fundamental conceptual issue at play.  The COPS-PR model
   provides a sufficient set of basic operations and commands, a
   stateful model, the ability for either "peer" to initiate certain
   kinds of requests, as well as an extensible command set, to be able
   to support a wide variety of network and resource management
   protocols.  The details of protocol specific messages is left to
Top   ToC   RFC3127 - Page 59
   Policy Information Base (PIB) data objects.  Since no AAA PIB has
   been written, the evacuator can only (optimistically) assess the
   inherent capabilities of the base protocol to accomplish the intended
   requirements of [3], given a reasonable set of assumptions about what
   an AAA PIB might look like.

   In some sense, this akin to asserting that a given algorithm can be
   correctly implemented in a specific programming language, without
   actually providing the code.

   The PIB model used by COPS is a powerful and flexible model.  The
   protocol document [5] spends a considerable amount of time
   enumerating and describing the benefits of this data model, and
   explaining its roots in Object Oriented (OO) design methodology.
   Analogies are made to class inheritance and class containment, among
   others.  It's always hard to say bad things about OO.

   3. General Requirements

   COPS-AAA would appear to meet (totally or partially) all of the
   requirements of [3], at least as can be determined without the
   benefit of an AAA PIB.

   4. Summary Recommendation

   Recommended with reservation.  Before final acceptance of COPS-AAA,
   someone is going to have to write the AAA PIB and evaluate its
   details.

C.8 COPS CON Evaluation

Evaluation of COPS against the AAA Requirements CON Evaluation Evaluator - David Mitton The Primary document discussed here is [COPSComp] and the arguments therein based on the proposal [COPSAAA]. [COPSComp] "Comparison of COPS Against the AAA NA Requirements", Work in Progress. [COPSAAA] "COPS Usage for AAA", Work in Progress. [EksteinProtoComp] "AAA Protocols: Comparison between RADIUS, Diameter, and COPS", Work in Progress.
Top   ToC   RFC3127 - Page 60
   References: (in order of relevancy)

   [COPSBase]  Durham, D., Boyle, J., Cohen, R., Herzog, S., Rajan, R.
               and A. Sastry, "The Common Open Policy Service Protocol",
               RFC 2748, January 2000.

   [COPSFwork] Yavatkar, R., Pendarakis, D. and R. Guerin, "A Framework
               for Policy-based Admission Control", RFC 2753, January
               2000.

   [COPSPR]    "COPS Usage for Policy Provisioning", Work in Progress.

   [COPSSPPI]  "Structure of Policy Provisioning Information (SPPI)",
               Work in Progress.

   [COPSCMS]   "COPS Over CMS", Work in Progress.

   [COPSTLS]   "COPS Over TLS", Work in Progress.

   [COPSGSS]   "COPS Extension for GSS-API based Authentication
               Support", Work in Progress.

   Other COPS & RSVP RFCs & drafts not listed as not directly relevant.

   Compliance: T==Total, P==Partial, F=Failed

   Section 1 - Per item discussion

   Initial Note: [COPSComp] claims "unconditional compliance" with all
   requirements.

   1.1 General Requirements

   1.1.1 Scalability - P (was T) The evaluator is concerned with
   scalability of many always-on TCP connections to a server supporting
   a lot of clients, particularly with the heartbeat messages.  The
   claim that the request handle is "unbounded" sounds fishy.

   1.1.2 Fail-over - P (was T) COPS gives an indication of peer failure,
   and has mechanisms to restart state, but there seems to be a bias
   toward a single state server.  COPS has decided that synchronizing
   state between multiple hot servers is out of scope.

   Because COPS uses TCP, it is at the mercy of the TCP timers of the
   implementation which can be significant.  Connection timeout
   reporting to the application may be delayed beyond the client
   authentication timeouts.  Tuning the Keep-Alive message to a tighter
   period will increase the session and system overhead.
Top   ToC   RFC3127 - Page 61
   1.1.3 Mutual Authentication - P (was T) The explanation is sort of
   for message object integrity.  It does not describe authentication
   techniques.  The evaluator assumes that COPS peers would authenticate
   each other at Client-Open time.  But cannot understand how this would
   work if proxies are involved.

   1.1.4 Transmission Level Security - T

   1.1.5 Data Object Confidentiality - T  Seems almost a carbon copy of
   the Diameter capabilities.  This evaluator echoes the high overhead
   concerns of the Diameter evaluator for the CMS capability.  TLS is
   not mentioned here, but is piled on later.

   1.1.6 Data Object Integrity - T  See above.

   1.1.7 Certificate Transport - T

   1.1.8 Reliable AAA Transport - T (maybe P) COPS meets this
   requirement as well as any other protocol we've evaluated.  That is
   it does have one application level ACK.  Statements such as "TCP
   provides guaranteed delivery" are incorrect.  COPS does attempt to
   identify outages by using a keep-alive message between TCP peers.

   1.1.9 Run over IPv4 - T

   1.1.10 Run over IPv6 - T

   1.1.11 Support Proxy and Routing Brokers - P (was T)  How client
   types are supported forward is not well understood by this evaluator.
   Does each client type require the Broker to make a different client
   Open request to it's upstream servers?  What about routing brokers?

   1.1.12 Auditability - P (was T)  (based on our interpretation as
   non-repudiation, rather than the definition given in reqts) The
   explanation of a History PIB is incomplete and therefore
   inconclusive.

   1.1.13 Shared Secret Not Required - T  Except this clause in
   [COPSAAA] 6.2 page 14 "COPS MUST be capable of supporting TLS"

   1.1.14 Ability to Carry Service Specific Attributes - P (was T)

   a) COPS only allows a small number of unique objects to be added.
      256 Object "classes" or types, with 256 subtypes or versions.
      Client types are 16 bits long, where the high bit indicates
      "enterprise" specific values.  But pertain to a COPS peer-
Top   ToC   RFC3127 - Page 62
      connection session.  The client type seems to just identify the
      information model for the message. eg. it will be fixed to one
      value for AAA.

   b) Service specific objects are not the same as Vendor Specific
      Objects.  They pertain to objects within a client type.

   c) The PIB model leads to a different model interoperability.
      Because most vendor product differ in some way, each PIB will be
      different, and sharing common provisioning profiles will be a
      rather difficult mapping problem on the server.

   d) It's not clear the different client types can be mixed or that
      other objects definitions can be used from other defined client
      types.  It's really unclear how the client type of a connection
      propagates in a proxy situation.

   1.2 Authentication Requirements

   1.2.1 NAI Support - T  The requirement that RFC 2459 (X.509 profiles)
   be met presumes that Auth servers would not have a mapping or local
   transformation.

   1.2.2 CHAP Support - T  An Information Model is being invoked, which
   I don't see really fleshed out anywhere.  [COPSAAA] does a bit of
   handwaving and definitions but doesn't deliver much meat.
   Nonetheless, this could be handled ala RADIUS.

   1.2.3 EAP Support - P (was T)  Again with the non-existent
   Information Model.  To do EAP, this evaluator thinks another Request
   or Decision type is needed here to indicate to proxies that an
   extended message exchange is in progress.

   1.2.4 PAP/Clear-text Passwords - T

   1.2.5 Reauthentication on demand - T

   1.2.6 Authorization w/o Authentication - T

   The comment "Please note: with existing algorithms, any authorization
   scheme not based on prior authentication is meaningless" is
   meaningless out of application context.

   1.3 Authorization Requirements

   1.3.1 Static and Dynamic IP Addr Assignment - T
Top   ToC   RFC3127 - Page 63
   1.3.2 RADIUS Gateway Capability - P (was T).  It would be interesting
   to see RADIUS attributes wrapped in some COPS "Information Model".

   1.3.3 Reject Capability - T

   1.3.4 Preclude Layer 2 Tunneling - T

   More work for the "Information Model" author!

   1.3.5 Reauthorization on Demand - T

   1.3.6 Support for Access Rules & Filters - P (was T)  Yet more work
   for the "Information Model" author, including some design issues
   which alluded the RADIUS and Diameter designers.  At least an attempt
   was made in Diameter.  There is nothing here.

   1.3.7 State Reconciliation - P (was T).  It is difficult for the
   evaluator to understand how well the COPS mechanisms work in a
   multi-administration situation, or in any proxy situation.  Multi-
   server coordination, if allowed, seems to be lacking a description.

   1.3.8 Unsolicited Disconnect - T

   1.4 Accounting Requirements

   1.4.1 Real Time Accounting - T

   1.4.2 Mandatory Compact Encoding - T  This evaluator does not believe
   that ADIF is a compact format.  But does believe that the Information
   Model author can design a PIB with accounting statistics that will
   satisfy this requirement.

   1.4.3 Accounting Record Extensibility - P (was T)  By defining a
   vendor/device specific PIB for additional elements.

   1.4.4 Batch Accounting - P (was T)  Offered description does not seem
   to match the requirement.

   1.4.5 Guaranteed Delivery - P (was T)  TCP does NOT "guarantee
   delivery", only application Acks can do that.  If these acks can be
   generated similar to the description here, then this requirement is
   met.
Top   ToC   RFC3127 - Page 64
   1.4.6 Accounting Timestamps - T  Another item for the "Information
   Model" author.

   1.4.7 Dynamic Accounting - T  Event and interim accounting can be
   supported.

   1.5 MOBILE IP Requirements

   1.5.1 Encoding of MOBILE IP Registration Messages - P (was T)  Yet
   more work for the "Information Model" author.  Hope he can handle it.

   1.5.2 Firewall Friendly - P (was T)  I guess.  Because it uses TCP
   and can be identified by known connection port.  But there is an
   issue with respect to the impact level of mixed COPS traffic coming
   through a common firewall port.

   1.5.3 Allocation of Local Home Agent - P (was T)  Just add another
   element to that "Information Model" definition.

   2. Summary Discussion

   COPS was designed to do some things similar to what we want and be
   somewhat flexible, but with a totally different set of assumptions on
   how many clients and requests would be funneled through the
   infrastructure and the acceptable overhead.  This evaluator is not
   sure that it scales well to the fast evolving access market where
   every product doesn't implement a small set of common features, but a
   large set of overlapping ones.

   3. General Requirements

   COPS started out with small and easily met set of design goals for
   RSVP and DiffServe, and is evolving as a new hammer to hit other
   nails [COPSPR].  As COPS implementors get more operational
   experience, it is interesting to see more reliability fixes/features
   quickly get patched in.

   Understanding COPS requires that you read a number RFCs and drafts
   which do not readily integrate well together.  Each application of
   COPS has spawned a number of drafts.  It's not clear if one wants to
   or can implement a single COPS server that can service AAA and other
   application clients.

   The COPS authors seem to overly believe in the goodness of TCP, and
   rely on it to solve all their transport problems, with concessions to
   application keep-alive messages to probe the connection status and
   sequence numbers to prevent replay attacks.  This evaluator believes
   this type of approach may work for many networks but really doesn't
Top   ToC   RFC3127 - Page 65
   scale well in larger configurations.  End-to-end application acks are
   the only guaranteed delivery solution, particularly where distributed
   state is involved.

   COPS falls into an in between place on encoding.  It has small number
   of simple data object blobs which are concatenated ala
   RADIUS/Diameter TLVs to form a flexible message layout.  However,
   they attempt to limit the number of objects by making them
   arbitrarily complex ala SNMP MIBs, and defining yet another data
   structuring language for these PIBs.  There is a lot of computer
   science style grandstanding in [COPSAAA] Section 1.2, but no
   translation into how a set of data objects can be used to meet these
   wonderful features in operation.  (or even if we needed them) This
   will be the crux of the interoperability issue.  RADIUS
   implementations interoperate because they at least, understand a
   common set of functional attributes from the RFCs.  And vendor extent
   ions can be simply customized in as needed via dictionaries.  If PIB
   definitions are needed for every piece and version of access
   equipment, before you can use it, then the bar for ease of
   configuration and use has been raised quite high.

   Support for PIB definition and vendor extensions will be on the same
   order as MIB integration in SNMP management products and put the
   supposed complexity of Diameter to shame.

   4. Summary Recommendation

   COPS has a structure that could be made to serve as a AAA protocol,
   perhaps by just copying the features of RADIUS and Diameter into it.
   The author of [COPSAAA] and [COPSComp] has not done the whole job yet
   and some of the missing pieces are vexing even for those already in
   the field.

   While some of the synergy with other COPS services is attractive,
   this evaluator is concerned about the liabilities of combining AAA
   services with the new emerging COPS applications in a single server
   entity will introduce more complexity than needed and opportunities
   to have progress pulled into other rat-holes. (eg. Policy Frameworks)
Top   ToC   RFC3127 - Page 66

Appendix D - Meeting Notes

The minutes of the team meetings as recorded by various members.

D.1 Minutes of 22-Jun-2000 Teleconference

Recorded by: Mark Stevens Arguments for and against SNMP as an AAA protocol were given. Stuart Barkley gave a summary of the pro argument. Mike St. Johns gave a summary of the con argument. Dave Nelson asked for "instructions to the jury" in an effort to determine what evidence could and could not be used in making decisions. The AAA evaluation criteria is weak in some areas and in others it appears to be written with what might be interpreted as undue influence from the NASREQ working group. Mike St. Johns offered that we must restrict ourselves to considering only the evidence provided in the compliance documents and any supporting documents to which they may refer. In summary: AAA evaluation criteria document, AAA evaluation criteria source documents, protocol response documents and reference documents. The question as to what the group should do with malformed requirements came up. The consensus seemed to be that we would use the requirements as adjusted in our last meeting where the requirements made no sense. The floor was then given to Stuart Barkley for the pro SNMP argument. Highlights: * In most areas the requirements are met by SNMP. * Confidentiality and Certificate transport mechanisms may be weak, but workable. * With regard to Authentication, every technique can be supported although support for PAP or cleartext passwords is weak. * With regard to Authorization, there is nothing in the requirements that cannot be supported. * Accounting everything supported, although there is no specific consideration for compact encoding. SNMP not as bloated as ASCII or XML based encoding schemes. Requirement for compact encoding weakly indicated in requirements anyway. Server-specific attributes needed, but compact encoding preclude w/o tradeoffs.
Top   ToC   RFC3127 - Page 67
   *  With regard to mobile IP requirement, everything works well,
      although firewall friendliness is a judgment call.
   *  Proxy mechanisms of SNMPv3 mitigates problems w/ firewalls.
   *  Scalability is ok.
   *  Overall, meets most requirements and shortfalls are minor.
   *  In some cases requirements seemed to expressed in a manner that
      "stacks" the odds against SNMP.
   *  SNMP is deployed everywhere already.

   *  The protocol has a well-understood behavior despite the tedium of
      MIB definition, so it has the advantage of not requiring the
      creation of a new infrastructure.
   *  AAA response document is silent on architecture and MIB
      definition, but there is too much work to do at this stage of
      evaluation.  Not having done the MIB definitions and architecture
      is not a limitation of the protocol.
   *  SNMP is a good candidate.

   Mike St. Johns took the floor to give a summary of the con argument.

   *  Neither the requirements, core documents nor response document
      specify the mechanism of operation.
   *  Liberties were taken in the assertion that the server to server
      interaction requirements were met.
   *  The scaling arguments are weak.
   *  Fail-over arguments are weak.
   *  Security aspects work well with the manager/server paradigm, but
      not well in bidirectional interactions among peers.
   *  The authentication requirements not understood by authors of the
      response document.  *  SNMP is just data moving protocol.
   *  Message formats not specified.
   *  What is the method for supporting authentication? Storing the
      information is handled, but what do the nodes do with it?

   *  The protocol certainly shined in the area of meeting accounting
      requirements.
   *  Although SNMP could certainly play a role in the accounting space,
      it is unusable in the areas of Authorization and Authentication.
   *  The response document does not address how the problem will be
      solved.
   *  It does not address the scalability issues that may arise in the
      transition from a manager-agent mode of operation to a client-
      server model.

   The group then examined each requirement against SNMP in a line-by-
   line exercise.
Top   ToC   RFC3127 - Page 68

D.2 Minutes of 27-Jun-2000 Teleconference

Attendees - All (Mike St. John, Dave Mitton, Dave Nelson, Mark Stevens, Barney Wolff, Stuart Barkley, Steven Crain, Basavaraj Patil) Minutes recorded by : Basavaraj Patil Evaluation of RADIUS++ AAA Requirements Pro : Mark Stevens Con : Dave Nelson - Question raised on if all meetings held so far have been recorded. Last week's meeting was recorded by Mark. Previous meetings have been recorded by Mike. All of these minutes should be available in the archive. - Dave Nelson mentioned that Pat Calhoun has responded on the AAA WG mailing list to the changes made to the requirements document by the evaluation team. Pat's response includes arguments for inclusion of some of the requirements that were deleted by the eval team. - Mike concluded that we can reinstate these requirements after reviewing Pat's comments in detail and the RFCs referenced. The intent is to take Pat's comments/document and review it between now and next Thursday (July 6th) and integrate the comments based on the findings at that time. Voting Procedure for evaluation : No voting during the discussion. All votes MUST be submitted to Mike by COB, June 28th, 00. - Dave Nelson's summary of the Con statement for RADIUS++. Overview of the points on which the evaluator disagrees with the compliance statement. Conclusion from Dave : Not recommended (Details in the con statement). Q: Is it possible to use it for accounting? A: Authentication and Authorization could be separated, but Accounting is the weak link in this protocol and hence is not suitable. - Mark Steven's summary of the Pro statement Agreed with most of the observations made by Dave Nelson. The biggest thing going for it is that it has been running in this environment for a while and it does meet most of the requirements
Top   ToC   RFC3127 - Page 69
      in the document.  Transition will be easy and backwards
      compatibility is a key plus point.

   Point-by-point Discussion:

   General (1.1):

   1.1.1 Scalability

   BW - There is no actual limit on the number of outstanding requests.
   The protocol itself does not limit the number.

   DN -Simultaneous requests is not the same as outstanding requests.

   Discussion of workarounds that have been implemented to overcome this
   problem.

   1.1.2 Fail-over

   DN - This is an application layer protocol and uses application level
   time-outs to provide fail-over solutions.  Analogy and discussion on
   the use of round-trip-timer in TCP.

   Example of how robust a network can be based on a machine at MIT that
   was decommissioned and a new one with the same name installed in the
   network.

   Discussion of environments where proxies for primary, secondary and
   tertiaries exist and the possible effect of flooding messages in the
   event of a fail-over detection.

   1.1.3 Mutual Authentication

   No Discussion.  Accepted as stated.

   1.1.4 Transmission level security

   This requirement was deleted from the list by the evaluation team.
   It was deleted because it is an overgeneralization of Roam Ops.

   DN - There is a concern regarding what this really means.  Referred
   to what Pat is saying about this on the list and the need for it to
   be reinstated.

   Suggestion to change the tag in the requirements document to hop-by-
   hop security.
Top   ToC   RFC3127 - Page 70
   Does the Roamops group use transmission level security to imply hop-
   by-hop security?

   1.1.5 Data Object Confidentiality

   Mike explained the concept of Cryptographic Message Syntax (CMS -
   RFC2630).  There are some issues regarding the use of CMS at an end
   point.  Symmetric or Asymmetric keys can be used.

   There does not seem to be a problem with the suggested usage of CMS
   in RADIUS++.

   1.1.6/7 Data Object Integrity/Certificate Transport

   No discussion.  (I guess everyone concurs with the statement in the
   compliance document and the reviewers comments).

   1.1.8 Reliable AAA Transport

   BW - Radius provides reliability at the application layer by doing
   retransmissions.  So why is there a need for a reliable AAA transport
   protocol?

   - Is it packet loss that the protocol needs to be concerned about?

   DN - This requirement is tied to the failover issue.  Explanation of
   the negative impact of retransmissions in a network, especially in
   the case of a web of proxies.

   Conclusion is that this requirement deals with packet loss.

   1.1.9/10 Run over IPv4/6

   Running over IPv6 should be a trivial issue.

   1.1.11 Support Proxy and Routing Brokers

   -  Discussion on what this requirement means and analogy to DNS
      servers in a network.

   -  RADIUS can be extended to support this requirement and from the
      compliance document this does not appear to be fully cooked yet.

   1.1.12 Auditability

   No Discussion
Top   ToC   RFC3127 - Page 71
   1.1.13 Shared Secret Not Required

   This seems to be a trivial issue to be addressed in RADIUS++.

   1.1.14 Ability to carry Service Specific Attributes

   No Discussion

   Authentication Requirements:

   1.2.1 NAI Support

   Trivial - Total compliance.

   1.2.2 CHAP Support

   Comment : RADIUS support of CHAP could be better and the response
   needs to be encrypted.

   1.2.3/4 EAP/PAP

   No Discussion

   1.2.5 Reauthentication on Demand

   DN - Document claims that the server can reauthenticate by issuing an
   Access-challenge.  There is a change to the state machine and the
   suggested solution is too simplistic.  Also backwards compatibility
   would be an issue.

   1.2.6 Authorization w/o Authentication

   DN - This is trivial to fix, but this is not mentioned in the
   compliance document.

   Authorization Requirements:

   1.3.1 Static and Dynamic IP Addr assignment

   -  RADIUS does not rise to the demands of being a resource manager
   -  RADIUS assigns an address and it stays assigned for the session.
      There is no concept of leasing.

   1.3.2 RADIUS Gateway Capability

   This is a requirement written that is not applicable to RADIUS
   itself.
Top   ToC   RFC3127 - Page 72
   1.3.3/4/5/6/7/8

   Call dropped.  Somebody else needs to fill in here.  (Mike ????)

   Accounting Requirements:

   1.4.1 Real time accounting

   No dissent.  No discussion

   1.4.2 Mandatory compact encoding

   Comment made regarding ASN.1 and XML in this context

   1.4.3 Accounting Record Extensibility

   No discussion

   1.4.4 Batch Accounting

   No specific wording in the document to show how this can be done.
   Basically it is real time accounting without the real time
   constraint.

   It may be a trivial issue.

   1.4.5/6 Guaranteed Delivery/Accounting Timestamps

   No Discussion

   1.4.7 Dynamic Accounting

   There is ongoing discussion in the AAA WG on this requirement.  The
   RADIUS WG is also discussing this (comment).  The idea here is to be
   able to send the equivalent of a phonecall in progress type of
   messages.

   Mobile IP Requirements:

   1.5.1 Encoding of Mobile IP Reg. Messages

   May be trivial.  Discussion on what this requirement really is.  Is
   it just the ability to carry the reg. message as payload? Does the
   AAA protocol have to delve into the reg. message and behave
   differently.
Top   ToC   RFC3127 - Page 73
   1.5.2 Firewall Friendly

   No Discussion

   1.5.3 Allocation of Local Home Agents

   This concept needs to be clarified as the author writing the
   compliance statement did not understand it either.

   If you notice anything that I recorded here as something
   misinterpreted, please feel free to make corrections.

D.3 Minutes of 29-Jun-2000 Teleconference

Attendees: Mike St. John, Dave Mitton, Dave Nelson, Barney Wolff, Stuart Barkley, Steven Crain, Basavaraj Patil. Missing: Mark Stevens. Minutes recorded by: Stuart Barkley Evaluation of Diameter AAA Requirements Advocates: Pro: Basavaraj Patil Con: Barney Wolff Summary discussion: PRO summary (Basavaraj Patil): session based lightweight base + extensions has implementation experience based upon radius fixes specific problems with radius, interoperates with radius looks like requirements are written for diameter CON summary (Barney Wolff): meets most needs, designed with requirements in mind issues: scalability in small devices (strong crypto specifically) failover (need guidance on failover recovery procedures)
Top   ToC   RFC3127 - Page 74
      Data object confidentiality has been expressed as very important,
      diameter glosses over it referring to rfc2630, cost to run on NAS
      device

      ACL: filter style syntax seems inadequate

      state reconciliation: difficult over global multiple
      administrative domains

      batch accounting: implementation doesn't meet intended need

      firewall friendly: until firewalls support SCTP will be failure

   summary very close

   concerns:

   size and complexity needs almost all extensions to actually support
   needs separation of SCTP and data (as per IESG suggestion?)
   application vs transport acks

   Point-by-point Discussion:

   General (1.1):

   1.1.1 Scalability

      Handles large number of requests

      SCTP reduces proxy needs (how? what is justification for this
      statement?)

      Scalability in large

   1.1.2 Fail-over

      Recovery from SCTP failure needs discussion (Note to DM: Include
      in final document considerations)

   1.1.3 Mutual Authentication

      No Discussion

   1.1.4 Transmission level security

      No Discussion
Top   ToC   RFC3127 - Page 75
   1.1.5/6 Data Object Confidentiality/Data Object Integrity

      Crypto in NAS
      NAS needs knowledge of when to use crypto
      One Time Passwords

   1.1.7 Certificate Transport

      No Discussion

   1.1.8 Reliable AAA Transport

      No Discussion

   1.1.9/10 Run over IPv4/6

      No Discussion

   1.1.11 Support Proxy and Routing Brokers

      No Discussion

   1.1.12 Auditability

      No Discussion

   1.1.13 Shared Secret Not Required

      No Discussion

   1.1.14 Ability to carry Service Specific Attributes

      No Discussion

   Authentication Requirements:

   1.2.1 NAI Support

      No Discussion

   1.2.2 CHAP Support

      No Discussion

   1.2.3/4 EAP/PAP

      No Discussion
Top   ToC   RFC3127 - Page 76
   1.2.5 Reauthentication on Demand

      No Discussion

   1.2.6 Authorization w/o Authentication

      No Discussion

   Authorization Requirements:

   1.3.1 Static and Dynamic IP Addr assignment

      No Discussion

   1.3.2 RADIUS Gateway Capability

      Protocol requirement or implementation/application requirement?
      Which RADIUS versions are to be supported?  Which subset?

   1.3.3 Reject Capability

      No Discussion

   1.3.4 Preclude L2TP

      No Discussion

   1.3.5 Reauthorize on demand

      Raj to look at this again

   1.3.6 Support for ACLs

      Standardizes syntax not semantics.
      Standardizes semantics in NASREQ extension, but is very weak

   1.3.7 State reconciliation

      Appears to be weak in that server must "query the world" to
      restore its state
      Just in time reconciliation
      Simultaneous usage limitations
      More discussion needed
Top   ToC   RFC3127 - Page 77
   1.3.8 Unsolicited disconnect

      No Discussion

   Accounting Requirements:

   1.4.1 Real time accounting

      No Discussion

   1.4.2 Mandatory compact encoding

      Is ADIF compact?
      Is ADIF UTF-8 compatible?

   1.4.3 Accounting Record Extensibility

      No Discussion

   1.4.4 Batch Accounting

      Diameter okay for small batches.  Specification doesn't seem
      suitable for large batch transfers (100,000+ records)

   1.4.5 Guaranteed Delivery

      No Discussion

   1.4.6 Accounting Timestamps

      No Discussion

   1.4.7 Dynamic Accounting

      No Discussion

   Mobile IP Requirements:

   1.5.1 Encoding of Mobile IP Reg. Messages

      Taken of faith

   1.5.2 Firewall Friendly

      Issues with SCTP being supported initially through firewalls
Top   ToC   RFC3127 - Page 78
   1.5.3 Allocation of Local Home Agents

      Still lack of understanding of the AAA protocol requirements here
      (versus just being a roaming attribute)

   Overall summary:

   Diameter seems to meet most requirements and is a likely candidate to
   support AAA requirements.

   Other matters:

   Votes on Diameter should be in by Sunday evening.  Same format as
   before.  Mike will tally up as both majority and average votes.

   Should different requirements have different weight?

   Possibility of SNMP reconsideration as per ADs?  To close off our
   task in timeframe allocated, should not reopen submissions or
   discussions.  Could cause to drag on for long time causing us to miss
   our July 15 date.

   Possibility of needing a few extra days to finish report due to
   editing and review needs of the group.  Mike to ask ADs to consider
   slight time extension possibility.

   "No discussion" means that the topic was mentioned but there we no
   objections/issues raised on that requirement being met.

   These are based upon my notes.  Please send any corrections to the
   list.

D.4 Minutes of 06-Jul-2000 Teleconference

Minutes of AAA-Team Telecon 7/6/00 By: Barney Wolff Pro review of COPS - Dave Nelson Likes the object model. No apparent showstoppers. Will resend review with typos corrected.
Top   ToC   RFC3127 - Page 79
   Con review of COPS - Dave Mitton

      Architecture is mostly there.
      Strong dependency on info model, sceptical of object model.
      Problem with info model in multi-vendor, multi-administration
      environment.
      How does server speak to multiple client flavors?
      Will resend review with typos corrected.

   Comment by Mike StJ "replace SNMP with COPS" - :) I think.

   Per-Item discussion

   1.1.1 Scalability - concern re always-on TCP.  Direction to DM - add
   general issue of number of connections.

   1.1.2 Failover - No hot backup, but true of all protocols.  (ie, no
   explicit mention of server-server protocol that might keep a backup
   server in sync so it could take over instantly.)

   1.1.3 Mutual Authentication - perhaps relies on TLS.  Draft does not
   otherwise support this.

   1.1.8 Reliable AAA Transport - TCP + appl heartbeat.

   1.1.11 Proxy & Routing Brokers - client-type interaction with proxy
   is questionable.  (In later discussion, it appears client-type is a
   field in the request, and perhaps all AAA is one type, so may not be
   an issue.)

   1.1.13 Shared secret not req'd - runs over TLS, no multiple levels of
   security.

   1.2.1 NAI Support - some uncertainty on the impact of RFC 2459 (X.509
   profiles) on this - may restrict NAI in some way?

   1.2.3 EAP Support - multi-pass handshake needs work.

   1.2.6 Authorization without Authentication - Mike comments the
   requirement is broken.  BW comment (post-meeting) - the requirement
   appears intended specifically to chastise RADIUS for requiring User-
   Name and some sort of password in an Access-Request, even if it's
   sent pre-connect, on receipt of DNIS, for example.  Sure it's silly,
   but does it really matter whether an attribute is absent or filled
   with "NONE"?  This was just nasty sniping at RADIUS on somebody's
   part, imho.

   1.3.2 RADIUS Gateway - skepticism was expressed.
Top   ToC   RFC3127 - Page 80
   1.3.4 Preclude L2 Tunnels - too much handwaving.

   1.3.6 Access Rules - lots of work needed.

   1.3.7 State Reconciliation - multi-server coordination is an issue.

   1.4.4 Batch Accounting - for small batches, perhaps.

   1.4.5 Guaranteed Delivery - application acks are an area of mystery.

   1.5.2 Firewall-Friendly - COPS like any Swiss-Army-Knife protocol
   (SNMP) requires the firewall to look inside the packets, because
   passing AAA may be allowed but not other protocol uses.  So it would
   be a big help, for both COPS and SNMP, to define a different port for
   its AAA application.

D.5 Minutes of 11-Jul-2000 Teleconference

Present: Mike, Bernard, Paul, Bert, Raj, Dave N., Dave M., Barney, Stuart, Mark Recorded By: Dave Nelson Mike St. Johns set the ground rules. An item by item review of the summary results was held. 1.1.1 Question as to why SNMP and RADIUS++ are "P"? There are issues regarding scaling of retries in a web of proxies (multi-layer proxy; primary, secondary tertiary servers at each level). 1.1.2 No protocol did very well. Similar issues as above, e.g. web of proxies. Recovery of state from a previously failed primary server? 1.1.3 Question as to how serious is the need for this requirement? May be some legitimate requirements from Mobile IP. Is this requirement an AAA-level issue? 1.1.4 Called hop-by-hop or transmission level? 1.1.5 Most protocols evaluated used CMS to meet this requirement. Question as to applicability of CMS for NASes and other edge devices? There is a requirement for object by object confidentiality. consider three-party scenarios.
Top   ToC   RFC3127 - Page 81
   1.1.6 Question as to why SNMP did not rate the same as for item
   1.1.5?  The evaluation is based on what was contained in the
   submission documents, rather than capabilities of the protocol
   itself.  Too much hand waving.

   1.1.7 No comments.

   1.1.8 Question as to meaning of "reliable"?  Discussion of transport
   protocols was deferred to later in the meeting.

   1.1.9 No comments.

   1.1.10 SNMP received "P" because of hand waving in the submission
   documents.

   1.1.11 SNMP received "F" because this section of the submission
   document indicated "t.b.d.".  Diameter was the only protocol
   submission to completely address this item.

   1.1.12 We treated this requirement as "non-repudiation".  There is a
   concern that digital signatures are computationally expensive and are
   not globally available.  COPS has more work to do on this item.

   1.1.13 Question that "no shared secrets" should be interpreted to
   mean that an alternative key management mechanism is available?  We
   treated this as meaning that application-layer security could be
   turned off in deference to transport layer security.  There had been
   discussion of the use of IKE in the AAA protocol.

   1.1.14 No comments.

   1.2.1 No comments.

   1.2.2 No comments.

   1.2.3 No comments.

   1.2.4 Is there a need for a clear-text "password" for service such as
   OTP, SecurID, et. al.?   It was noted that all plain passwords are
   exposed in clear-text at the NAS or other edge device, which is no
   more inherently trustworthy than any AAA server or proxy.

   1.2.5 We distinguished event-driven reauthentication from timer-
   driven (or lifetime-driven).  How is this requirement to be met in a
   proxy environment?

   1.2.6 We asserted that this requirement is an oxymoron.
Top   ToC   RFC3127 - Page 82
   1.3.1 We had difficulty in determining what "static" meant, and from
   which reference point it was measured.

   1.3.2 We agreed that NAIs could be handled, possibly with some
   restrictions.

   1.3.3 No comment.

   1.3.4 The SNMP submission documents contained significant hand
   waving.

   1.3.5 Similar comments as to item 1.2.5.  The question was raised as
   to how the server knows when to send this request?

   1.3.6 We found that the notation in Diameter was weak, and of a least
   common denominator nature.  In general, there was concern about
   achieving interoperability when the syntax was standardized but the

   semantics were not.  This area needs further work.

   1.3.7 Question as to how this requirement is achieved via proxies?

   1.4.1 No comment.

   1.4.2 No comment.

   1.4.3 No comment.

   1.4.4 There was significant skepticism regarding batch accounting as
   part of the AAA protocol.  How large are the "batches"?  Should this
   requirement be met using FTP or something similar?

   1.4.5 No comment.

   1.4.6 No comment.

   1.4.7 No comment.

   1.5.1 No comment.

   1.5.2 There was some discussion of what constitutes firewall
   friendly.  It was suggested that the firewall didn't want to look
   into packets much past the application protocol address (e.g. UDP or
   TCP port number).  Protocols such as SNMP and COPS that have usage
   other than AAA are at a disadvantage, since the firewall must look
   deep into the application PDU to determine the intended purpose of
   the packet.  Diameter suffers from reliance of SCTP, which is not
   widely deployed or widely recognized by firewalls.  Should firewalls
Top   ToC   RFC3127 - Page 83
   also be AAA proxy engines?  Has this issue anything to do with
   interoperability with NAT?

   1.5.3 We had some confusion as to what the requirement actually was.
   Raj seemed to be able to explain it, but the rest of us had to take
   it on faith.

   A poll was taken on overall acceptability and effort for each of the
   protocols submitted, for requirements conformance.

   Each member indicated their evaluation in the form of (Acceptable,
   Not-Acceptable) with qualifiers for (Accounting, or effort to change)
   This information will be summarized in the final report.

   A general wrap-up discussion was held.

   It was considered important that as much of the thought processes and
   rationales be placed in the final report as is feasible.  Mike St.
   John will work with Dave Mitton on the ID.  We really need to meet
   the IETF July 14 submission deadline, even if we have to issue an
   update on the AAA WG mailing list.  All agreed that the process went
   fairly well.  In future evaluations of this nature, it would be well
   for the evaluators to follow the requirements documents closely, for
   the submitters to create accurate and complete conformance documents,
   and to allow a "re-spin" cycle to correct errors and omissions in the
   requirements documents and conformance documents.

   A discussion of the transport protocol was held.

   The issue with transport is congestion control.  There has been a
   problem with streams-oriented applications over TCP.  The IESG is
   increasingly sensitive to this issue in new protocols.  It was noted
   that AAA was a transaction-oriented application.  Other request-
   response applications, such as DNS, seem to scale welt to Internet-
   scale using simple application-level retries and UDP transport.  TCP
   has problems with head-of-line blocking, especially when multiple
   sessions are using a single TCP connection.  AAA typically will send
   3 or 4 iterations and then indicate a failure to the upper layers.
   It won't continue retransmissions in the face of congestion, like
   TCP.  It was noted that bulk data transfer may not best be
   implemented in the AAA protocol.  Concern was voiced that SCTP is not
   a widely implemented protocol.  AAA will implement congestion control
   by limiting the number of outstanding requests.  Some RADIUS
   implementations send lots of traffic when they encounter
   misconfigured shared secrets, but this is likely caused by a lack of
   proper error recovery.  Diameter, as currently drafted, relies on
   SCTP.  Can AAA run over UDP?  The IESG didn't say "no"; their issue
   is addressing congestion control.
Top   ToC   RFC3127 - Page 84
Full Copyright Statement

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

   This document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implementation may be prepared, copied, published
   and distributed, in whole or in part, without restriction of any
   kind, provided that the above copyright notice and this paragraph are
   included on all such copies and derivative works.  However, this
   document itself may not be modified in any way, such as by removing
   the copyright notice or references to the Internet Society or other
   Internet organizations, except as needed for the purpose of
   developing Internet standards in which case the procedures for
   copyrights defined in the Internet Standards process must be
   followed, or as required to translate it into languages other than
   English.

   The limited permissions granted above are perpetual and will not be
   revoked by the Internet Society or its successors or assigns.

   This document and the information contained herein is provided on an
   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Acknowledgement

   Funding for the RFC Editor function is currently provided by the
   Internet Society.