requirement. The evaluator has had unfortunate experience with a
vendor's RADIUS implementation that had exactly the defect that it
often failed to notice recovery of the primary.
1.1.3 Mutual Authentication - T
1.1.4 Transmission Level Security - T
1.1.5 Data Object Confidentiality - P (was T). Yes, the CMS data
type is supported. But the work in progress, "Diameter Strong
Security Extension", says:
Given that asymmetric transform operations are expensive, Diameter
servers MAY wish to use them only when dealing with inter-domain
servers, as shown in Figure 3. This configuration is normally
desirable since Diameter entities within a given administrative
domain MAY inherently trust each other. Further, it is desirable
to move this functionality to the edges, since NASes do not
necessarily have the CPU power to perform expensive cryptographic
operations.
Given all the fuss that has been made about "end-to-end"
confidentiality (which really means "NAS-to-home_server"), the
evaluator finds it absurd that the proposed solution is acknowledged
to be unsuited to the NAS.
1.1.6 Data Object Integrity - P (was T). See above.
1.1.7 Certificate Transport - T
1.1.8 Reliable AAA Transport - T
1.1.9 Run over IPv4 - T
1.1.10 Run over IPv6 - T
1.1.11 Support Proxy and Routing Brokers - T
1.1.12 Auditability - T (based on our interpretation as non-
repudiation, rather than the definition given in reqts)
1.1.13 Shared Secret Not Required - T
1.1.14 Ability to Carry Service Specific Attributes - T
1.2 Authentication Requirements
1.2.1 NAI Support - T
1.2.2 CHAP Support - T
1.2.3 EAP Support - T
1.2.4 PAP/Clear-text Passwords - T
1.2.5 Reauthentication on demand - P (was T). No mechanism was
evident for the server to demand a reauthentication, based for
example on detection of suspicious behavior by the user. Session-
timeout is not sufficient, as it must be specified at the start.
1.2.6 Authorization w/o Authentication - T
1.3 Authorization Requirements
1.3.1 Static and Dynamic IP Addr Assignment - T
1.3.2 RADIUS Gateway Capability - P (was T). RADIUS has evolved from
the version on which Diameter was based. EAP is a notable case where
the convention that the Diameter attribute number duplicates the
RADIUS one is violated. No protocol, not even RADIUS++, can claim a
T on this.
1.3.3 Reject Capability - T (The evaluator fails to understand how
any AAA protocol could rate anything other than T on this.)
1.3.4 Preclude Layer 2 Tunneling - T
1.3.5 Reauth on Demand - P (was T). As with reauthentication, there
is no evident mechanism for the server to initiate this based on
conditions subsequent to the start of the session.
1.3.6 Support for ACLs - P (was T). The evaluator finds the Filter-
Rule AVP laughably inadequate to describe filters. For example, how
would it deal with restricting SMTP to a given server, unless all IP
options are forbidden so the IP header length is known? No real NAS
could have such an impoverished filter capability, or it would not
survive as a product.
1.3.7 State Reconciliation - P (was T). It is difficult for the
evaluator to understand how this is to work in a multi-administration
situation, or indeed in any proxy situation. Furthermore, SRQ with
no session-id is defined to ask for info on all sessions, not just
those "owned" by the requester.
1.3.8 Unsolicited Disconnect - T
1.4 Accounting Requirements
1.4.1 Real Time Accounting - T
1.4.2 Mandatory Compact Encoding - T
1.4.3 Accounting Record Extensibility - T
1.4.4 Batch Accounting - P (was T). The evaluator suspects that
simply sending multiple accounting records in a single request is not
how batch accounting should or will be done.
1.4.5 Guaranteed Delivery - T
1.4.6 Accounting Timestamps - T (The evaluator notes with amusement
that NTP time cycles in 2036, not 2038 as claimed in the Diameter
drafts. It's Unix time that will set the sign bit in 2038.)
1.4.7 Dynamic Accounting - T
1.5 MOBILE IP Requirements
1.5.1 Encoding of MOBILE IP Registration Messages - T
1.5.2 Firewall Friendly - F (was T). Until such time as firewalls
are extended to know about or proxy SCTP, it is very unlikely that
SCTP will be passed. Even then, the convenient feature of being able
to send a request from any port, and get the reply back to that port,
means that a simple port filter will not be sufficient, and
statefulness will be required. Real friendship would require that
both source and dest ports be 1812.
1.5.3 Allocation of Local Home Agent - T
2. Summary Discussion
In some areas, Diameter is not completely thought through. In
general, real effort has gone into satisfying a stupendous range of
requirements.
3. General Requirements
Diameter certainly fails the KISS test. With SCTP, the drafts add up
to 382 pages - well over double the size of RADIUS even with
extensions. The evaluator sympathizes with the political instinct
when faced with a new requirement no matter how bizarre, to say "we
can do that" and add another piece of filigree. But the major places
where Diameter claims advantage over RADIUS, namely "end-to-end"
confidentiality and resource management, are just the places where
some hard work remains, if the problems are not indeed intractable.
More specifically, the evaluator sees no indication that specifying
the separate transport protocol provided any advantage to defray the
large increase in complexity. Application acks are still required,
and no benefit from the transport acks was evident to the evaluator.
Nor was there any obvious discussion of why "sequenced in-order"
delivery is required, when AAA requests are typically independent.
SCTP offers out-of-order delivery, but Diameter seems to have chosen
not to use that feature.
Whether TLV encoding or ASN.1/BER is superior is a religious
question, but Diameter manages to require both, if the "strong"
extension is implemented. The evaluator has a pet peeve with length
fields that include the header, making small length values invalid,
but that is a minor point.
Finally, interoperability would be greatly aided by defining a
standard "dictionary" format by which an implementation could adopt
wholesale a set of attributes, perhaps from another vendor, and at
least know how to display them. That is one of the advantages of
MIBs.
4. Summary Recommendation
Diameter is clearly close enough to meeting the myriad requirements
that it is an acceptable candidate, though needing some polishing.
Whether the vast increase in complexity is worth the increase in
functionality over RADIUS is debatable.
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 RFC2748 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 RFC2630. The evaluator has not, at this
time, investigated the applicability of RFC2630 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 RFC2630. The evaluator has not, at this time,
investigated the applicability of RFC2630 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 RFC2630 and RFC1510. The evaluator has not, at
this time, investigated the applicability of RFC2630 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 RFC2459
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 RFC2630. The evaluator has not, at this time,
investigated the applicability of RFC2630 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",
RFC2748, January 2000.
[COPSFwork] Yavatkar, R., Pendarakis, D. and R. Guerin, "A Framework
for Policy-based Admission Control", RFC2753, 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 RFC2459 (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 RFC2459 (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