RFC 3127
Authentication, Authorization, and Accounting: Protocol Evaluation
Pages: 84
Informational
Informational
Part 3 of 3 – Pages 55 to 84
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.
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.
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.
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
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.
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.
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-
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
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.
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
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)
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.
* 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.
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
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.
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
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.
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.
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)
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
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
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
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
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.
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.
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.
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.
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
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.
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.