requirements.
1.5 MOBILE IP Requirements
1.5.1 Encoding of MOBILE IP Registration Messages - Grade T
SNMP can easily provide objects to transfer this information.
1.5.2 Firewall Friendly - New Grade T (from P)
SNMP is already deployed in many operational networks. SNMPv3
addresses most concerns people had with the operation of previous
versions. True SNMPv3 proxies (as opposed to AAA proxies) should
become commonplace components in firewalls for those organizations
which require firewalls.
1.5.3 Allocation of Local Home Agent - New Grade T (from ?)
SNMP is not concerned with the LHA. This can be under control of the
Local network to meet its needs.
2. Summary Discussion
SNMP appears to meet most stated requirements. The areas where the
SNMP proposal falls short are areas where specific AAA architectures
are envisioned and requirements based upon that architecture are
specified.
Scaling of the protocol family is vital to success of a AAA suite.
The SNMP protocol has proved scalable in existing network management
and other high volume data transfer operations. Care needs to be
taken in the design of a large scale system to ensure meeting the
desired level of service, but this is true of any large scale
project.
3. General Requirements
SNMP is well understood and already supported in many ISP and other
operational environments. Trust models already exist in many cases
and can be adapted to provide the necessary access controls needed by
the AAA protocols. Important issues with previous versions of SNMP
have been corrected in the current SNMPv3 specification.
The SNMP proposal is silent on the specific data variables and
message types to be implemented. This is largely due to the
requirements not specifying the necessary data elements and the time
constraints in extracting that information from the base document
set. Such a data model is necessary regardless of the ultimate
protocol selected.
4. Summary Recommendation
SNMP appears to fully meet all necessary requirements for the full
AAA protocol family.
C.2 SNMP CON Evaluation
Evaluation of SNMP AAA Requirements
CON Evaluation
Evaluator - Michael StJohns
Ref [1] is "Comparison of SNMPv3 Against AAA Network Access
Requirements", aka 'the document'
Ref [2] is the aaa eval criteria as modified by us.
The document uses T to indicate total compliance, P to indicate
partial compliance and F to indicate no compliance. For each section
I've indicated my grade for the section. If there is no change, I've
indicated that and the grade given by the authors.
Section 1 - Per item discussion
1.1 General Requirements
1.1.1 Scalability - Although the document indicates compliance with
the requirement, its unclear how SNMP actually meets those
requirements. The document neither discusses how SNMP will scale,
nor provides applicable references. The argument that there is an
existence proof given the deployed SNMP systems appears to assume
that one manager contacting many agents maps to many agents (running
AAA) contacting one AAA server. A server driven system has
substantially different scaling properties than a client driven
system and SNMP is most definitely a server (manager) driven system.
Eval - F
1.1.2 Fail-over - The document indicates the use of application level
time outs to provide this mechanism, rather than the mechanism being
a characteristic of the proposed protocol. The protocol provides
only partial compliance with the requirement. Eval - P
1.1.3 Mutual Authentication - There is some slight handwaving here,
but the protocol's USM mode should be able to support this
requirement. Eval - No Change (T)
1.1.4 Transmission Level Security - The authors should elaborate on
the specific use of the SNMPv3 modes to support these requirements,
but the text is minimally acceptable. Eval - No Change (T)
1.1.5 Data Object Confidentiality - The authors describe a mechanism
which does not appear to completely meet the requirement. VACM is a
mechanism for an end system (agent) to control access to its data
based on manager characteristics. This mechanism does not appear to
map well to this requirement. Eval - P
1.1.6 Data Object Integrity - There appears to be some handwaving
going on here. Again, SNMP does not appear to be a good match to
this requirement due to at least in part a lack of a proxy
intermediary concept within SNMP. Eval - F
1.1.7 Certificate Transport - The document does indicate compliance,
but notes that optimization might argue for use of specialized
protocols. Eval - No Change (T)
1.1.8 Reliable AAA Transport - The document indicates some confusion
with the exact extent of this requirement. Given the modifications
suggested by the eval group to the explanatory text in [2] for the
related annotation, the point by point explanatory text is not
required. The document does indicate that the use of SNMP is
irrespective of the underlying transport and the support of this
requirement is related at least partially to the choice of transport.
However, SNMP over UDP - the most common mode for SNMP - does not
meet this requirement. Eval - No Change (P)
1.1.9 Run over IPv4 - While the evaluator agrees that SNMPv3 runs
over V4, the authors need to point to some sort of reference. Eval -
No Change (T)
1.1.10 Run over IPv6 - The document indicates both experimental
implementations and future standardization of SNMPv3 over IPv6. Eval
- No Change (P)
1.1.11 Support Proxy and Routing Brokers - The section of the
document (5.5.3) that, by title, should have the discussion of SNMP
proxy is marked as TBD. The section notes that the inability to
completely comply with the data object confidentiality and integrity
requirements might affect the compliance of this section and the
evaluator agrees. Eval - F
1.1.12 Auditability - The document indicates no compliance with this
requirement. Eval - No Change (F)
1.1.13 Shared Secret Not Required - Slight handwaving here, but
SNMPv3 does not necessarily require use of its security services if
other security services are available. However, the interaction with
VACM in the absence of USM is not fully described and may not have
good characteristics related to this requirement. Eval - P
1.1.14 Ability to Carry Service Specific Attributes - SNMP complies
via the use of MIBs. Eval - No Change (T)
1.2 Authentication Requirements
1.2.1 NAI Support - The document indicates that MIB objects can be
created to meet this requirement, but gives no further information.
Eval - P
1.2.2 CHAP Support - The document indicates that MIB objects can be
created to meet this requirement, but gives no further information.
Given the normal CHAP model, its unclear exactly how this would work.
Eval - F
1.2.3 EAP Support - The document notes that EAP payloads can be
carried as specific MIB objects, but also notes that further design
work would be needed to fully incorporate EAP. Eval - No Change (P)
1.2.4 PAP/Clear-text Passwords - The document notes the use of MIB
objects to carry the clear text passwords and the protection of those
objects under normal SNMPv3 security mechanisms. Eval - No Change
(T)
1.2.5 Reauthorization on demand - While there's some handwaving here,
its clear that the specific applications can generate the signals to
trigger reauthorization under SNMP. Eval - No Change (T)
1.2.6 Authorization w/o Authentication - The author appears to be
confusing the AAA protocol authorization with the AAA user
authorization and seems to be over generalizing the ability of SNMP
to deal with general AAA user authorization. Eval - F
1.3 Authorization Requirements
1.3.1 Static and Dynamic IP Addr Assignment - The reference to MIB
objects without more definite references or descriptions continues to
be a negative. While the evaluator agrees that MIB objects can
represent addresses, the document needs to at least lead the reader
in the proper direction. Eval - F
1.3.2 RADIUS Gateway Capability - The transport and manipulation of
Radius objects appears to be only a part of what is required. Eval -
P
1.3.3 Reject Capability - Again, a clarification of how SNMP might
accomplish this requirement would be helpful. The overall document
lacks a theory of operation for SNMP in an AAA role that might have
clarified the various approaches. Eval - F
1.3.4 Preclude Layer 2 Tunneling - Document indicates lack of
understanding of this requirement. Eval - F
1.3.5 Reauth on Demand - See response in 1.3.3 above. None of the
text responding to this requirement, nor any other text in the
document, nor any of the references describes the appropriate
framework and theory. Eval - F
1.3.6 Support for ACLs - The response text again references MIB
objects that can be defined to do this job. There is additional
engineering and design needed before this is a done deal. Eval - P
1.3.7 State Reconciliation - The text fails to address the basic
question of how to get the various parts of the AAA system back in
sync. Eval - F
1.3.8 Unsolicited Disconnect - Assuming that the NAS is an SNMP agent
for an AAA server acting as an SNMP manager the evaluator concurs.
Eval - No Change (T).
1.4 Accounting Requirements
1.4.1 Real Time Accounting - SNMP Informs could accomplish the
requirements. Eval - No Change (T)
1.4.2 Mandatory Compact Encoding - This is a good and reasonable
response. SNMP can vary the style and type of reported objects to
meet specific needs. Eval - No Change (T).
1.4.3 Accounting Record Extensibility - MIBs are extensible. Eval -
No Change (T)
1.4.4 Batch Accounting - MIBs provide data collection at various
times. Eval - No Change (T)
1.4.5 Guaranteed Delivery - There's some weasel wording here with
respect to what guaranteed means, but the description of mechanisms
does appear to meet the requirements. Eval - No Change (T)
1.4.6 Accounting Timestamps - Accounting records can use the
DateAndTime Textual Convention to mark their times. Eval - No Change
(T)
1.4.7 Dynamic Accounting - The author may have partially missed the
point on this requirement. While the number of records per session
is not of great interest, the delivery may be. The author should go
a little more into depth on this requirement. Eval - No Change (T)
1.5 MOBILE IP Requirements
1.5.1 Encoding of MOBILE IP Registration Messages - Registration
messages can probably be encoded as SNMP messages. Eval - No Change
(T)
1.5.2 Firewall Friendly - There's a chicken and egg problem with the
response to the requirement in that the author hopes that SNMP as an
AAA protocol will encourage Firewall vendors to make SNMP a firewall
friendly protocol. Eval - F
1.5.3 Allocation of Local Home Agent - The author disclaims an
understanding of this requirement. Eval - F
2. Summary Discussion
The documents evaluation score was substantially affected by a lack
of any document, reference or text which described a theory of
operation for SNMP in AAA mode. Of substantial concern are the items
relating to the AAA server to server modes and AAA client to server
modes and the lack of a map to the SNMP protocol for those modes.
The evaluator also notes that the scaling issues of SNMP in SNMP
agent/manager mode are in no way indicative of SNMP in AAA
client/server mode. This has a possibility to substantially impair
SNMPs use in an AAA role.
However, SNMP may have a reasonable role in the Accounting space.
SNMP appears to map well with existing technology, and with the
requirements.
3. General Requirements
SNMP appears to meet the general requirements of an IP capable
protocol, but may not have a proper field of use for all specific
requirements.
4. Summary Recommendation
Recommended in Part. SNMP is NOT RECOMMENDED for use as either an
authentication or authorization protocol, but IS RECOMMENDED for use
as an accounting protocol.
C.3 RADIUS+ PRO Evaluation
Evaluation of RADIUS AAA Requirements PRO Evaluation
Evaluator - Mark Stevens
Ref [1] is "Comparison of RADIUS Against AAA Network Access
Requirements"
Ref [2] is "Framework for the extension of the RADIUS(v2) protocol"
Ref [3] is the aaa eval criteria as modified by us.
The documents uses T to indicate total compliance, P to indicate
partial compliance and F to indicate no compliance.
For each section I've indicated my grade for the section. I have
indicated whether or not my evaluation differs from the statements
made with respect to RADIUS++. The evaluation ratings as given below
may differ from the evaluations codified in the document referred to
as, "Comparison of RADIUS Against AAA Network Access Requirements"
without any indication.
1.1 General Requirements
1.1.1 [a] Scalability - In as much as a protocol's scalability can be
measured, the protocol seems to transmit information in a fairly
efficient manner.So, in that the protocol appears not to consume an
inordinate amount of bandwidth relative to the data it is
transmitting, this protocol could be considered scalable. However,
the protocol has a limit in the number of concurrent sessions it can
support between endpoints. Work arounds exist and are in use. Eval
- P (no change)
1.1.2 [b] Fail-over - The document indicates the use of application
level time outs to provide this mechanism, rather than the mechanism
being a characteristic of the proposed protocol. The fail-over
requirement indicates that the protocol must provide the mechanism
rather than the application. The implication is that the application
need not be aware that the fail-over and subsequent correction when
it happens. The application using the RADIUS++ protocol will be
involved in fail-over recovery activities. The protocol layer of the
software does not appear to have the capability built-in. Given the
wording of the requirement: Eval - P (changed from T)
1.1.3 [c] Mutual Authentication - The RADIUS++ protocol provides
shared-secret as a built-in facility for mutual authentication. The
authors of the document suggest the use of IPSec to obtain mutual
authentication functions. The RADIUS++ protocol provides no road
blocks to obtaining mutual authentication between instances of AAA
applications, however the protocol provides no facilities for doing
so.
1.1.4 [d] Transmission Level Security - The RADIUS++ protocol
provides no transmission level security features, nor does it
preclude the use of IPSec to obtain transmission level security.
Eval - P (no change)
1.1.5 [e] Data Object Confidentiality - The document describes a
RAIDUS++ message designed to server as an envelope in which encrypted
RADIUS messages (attributes) may be enclosed. Eval - T (no change)
1.1.6 [f] Data Object Integrity - Using visible signatures, the
RADIUS++ protocol appears to meet this requirement. Eval - T (no
change)
1.1.7 [g] Certificate Transport - The document indicates compliance
through the use of the CMS-Data Radius Attribute (message). Eval - T
(no change)
1.1.8 [h] Reliable AAA Transport - The document points out that
RADIUS++ can be considered a reliable transport when augmented with
Layer 2 Tunneling Protocol. The protocol itself does not provide
reliability features. Reliability remains the responsibility of the
application or a augmenting protocol. Eval - P (no change)
1.1.9 [i] Run over IPv4 - Eval - T (no change)
1.1.10 [j] Run over IPv6 - an IPv6 Address data type must be defined.
Eval - T (no change)
1.1.11 [k] Support Proxy and Routing Brokers - There is no mechanism
for rerouting requests, but an extension can be made to do so. Eval
- T (no change)
1.1.12 [l] Auditability - The document indicates no compliance with
this requirement. Eval - F (no change)
1.1.13 [m] Shared Secret Not Required - RADIUS++ can be configured to
run with empty shared secret values. Eval - T (no change)
1.1.14 [n] Ability to Carry Service Specific Attributes - Vendor
escape mechanism can be used for this purpose.. Eval - T (no
change)
1.2 Authentication Requirements
1.2.1 [a] NAI Support - Eval - T (no change)
1.2.2 [b] CHAP Support - Subject to dictionary attacks. Eval - P
(changed from T)
1.2.3 [c] EAP Support - Eval - T (no change)
1.2.4 [d] PAP/Clear-text Passwords - No end-to-end security, but
potential for encapsulation exists within current paradigm of the
protocol. - Eval -T (no change)
1.2.5 [e] Reauthentication on demand - The RADIUS protocol
supports re-authentication. In case re-authentication is initiated
by the user or AAA client, the AAA client can send a new
authentication request. Re-authentication can be initiated from the
visited or home AAA server by sending a challenge message to the AAA
client. Eval - T (no change)
1.2.6 [f] Authorization w/o Authentication - A new message type can
be created to enable RADIUS++ to support Aw/oA . Eval - T (no
change)
1.3 Authorization Requirements
1.3.1[a] Static and Dynamic IP Addr Assignment - Both supported.
IPv6 would require the definition of a new address data type. Eval -
P (no change)
1.3.2 [b] RADIUS Gateway Capability - The transport and manipulation
of RADIUS objects appears to be only a part of what is required.
Requirement seems to be worded to preclude RADIUS. Eval - P (changed
from T)
1.3.3 [c] Reject Capability - Eval -T
1.3.4 [d] Preclude Layer 2 Tunneling - I do not see a definition in
the AAA eval criteria document. Eval - ?
1.3.5 [e] Reauthorization on Demand - Implementation in the field
demonstrate that extensions to RADIUS can support the desired
behavior. Re-authentication is currently coupled to re-
authorization. Eval - P (no change)
1.3.6 [f] Support for ACLs - Currently done in the applications
behind the RADIUS end points, not the within the protocol. RADIUS++
could define additional message types to deal with expanded access
control within new service areas. Eval - P (no change)
1.3.7 [g] State Reconciliation - Eval - F (no change)
1.3.8 [h] Unsolicited Disconnect - RADIUS++ extensions to support.
Eval - T. (no change)
1.4 Accounting Requirements
1.4.1 [a] Real Time Accounting - Eval - T (no change)
1.4.2 [b] Mandatory Compact Encoding - Eval - T (no change)
1.4.3 [c] Accounting Record Extensibility - Eval - T (no change)
1.4.4 [d] Batch Accounting - RADIUS++ offers no new features to
support batch accounting. Eval - F No change)
1.4.5 [e] Guaranteed Delivery - Retransmission algorithm employed.
Eval - T (no change)
1.4.6 [f] Accounting Timestamps - RADIUS++ extensions support
timestamps. Eval - T (no change)
1.4.7 [g] Dynamic Accounting - RADIUS++ extensions to support. Eval
- T (no change)
1.5 MOBILE IP Requirements
1.5.1 [a] Encoding of MOBILE IP Registration Messages - RADIUS++
extensions can be made to include registration messages as an opaque
payload. Eval - T (no change)
1.5.2 [b] Firewall Friendly - RADIUS is known to be operational
in environments where firewalls acting as a proxy are active. Eval -
T (no change)
1.5.3 [c] Allocation of Local Home Agent -Requirement statement needs
some clarification and refinement. Eval - F (no change)
2. Summary Discussion
The RADIUS protocol, and its associated extensions, is presently not
fully compliant with the AAA Network Access requirements.
However, it is possible with a small effort to extend present
procedures to meet the requirements as listed in, while maintaining a
high level of interoperability with the wide deployment and
installed base of RADIUS clients and servers.
3. General Requirements
RADIUS++ the protocol and the application meet the majority of the
requirements and can be extended to meet the requirements where
necessary.
4. Summary Recommendation
RADIUS++ as it could be developed would provide a level of backward
compatibility that other protocols cannot achieve. By extending
RADIUS in the simple ways described in the documents listed above,
the transition from existing RADIUS-based installations to RADIUS++
installations would be easier. Although accounting continues to be
weaker than other approaches, the protocol remains a strong contender
for continued use in the areas of Authorization and Authentication.
C.4 RADIUS+ CON Evaluation
Evaluation of RADIUS++ (sic) AAA Requirements CON Evaluation
Evaluator - David Nelson
Ref [1] is "Comparison of RADIUS Against AAA Network Access
Requirements", a.k.a. 'the document'
Ref [2] is "Framework for the extension of the RADIUS(v2) protocol",
a.k.a. 'the protocol'
Ref [3] is the AAA evaluation criteria as modified by us.
Ref [4] is RFC2869.
Ref [5] is an expired work in progress "RADIUS X.509 Certificate
Extensions".
Ref [6] is RFC2868
The document uses T to indicate total compliance, P to indicate
partial compliance and F to indicate no compliance. Evaluator's
Note: The document [1] pre-dates the protocol [2]. It is clear from
reading [2], that some of the issues identified as short comings in
[1] are now addressed in [2]. The evaluator has attempted to take
note of these exceptions, where they occur.
Section 1 - Per item discussion
1.1 General Requirements
1.1.1 Scalability - The document [1] indicates partial compliance,
largely in deference to the "tens of thousands of simultaneous
requests" language in [3], that has been deprecated. The issue of
simultaneous requests from a single AAA client is addressed in [1],
indicating that the apparent limitation of 256 uniquely identifiable
outstanding request can be worked around using well known techniques,
such as the source UDP port number of the request. The document
claims "P", and the evaluator concurs.
1.1.2 Fail-over - The document [1] indicates the use of application
level time outs to provide the fail-over mechanism. Since the AAA
protocol is indeed an application-layer protocol, this seems
appropriate. There are significant issues of how to handle fail-
over in a proxy-chain environment that have not been well addressed,
however. The document claims "T", and the evaluator awards "P".
1.1.3 Mutual Authentication - The document [1] indicates that mutual
authentication exists in the presence of a User-Password or CHAP-
Password attribute in an Access-Request packet or the Message-
Authenticator [4] in any packet. Once again, this addresses hop-by-
hop authentication of RADIUS "peers", but does not fully address
proxy-chain environments, in which trust models would need to be
established. The document further indicates that strong mutual
authentication could be achieved using the facilities of IPsec. This
claim would apply equally to all potential AAA protocols, and cannot
be fairly said to be a property of the protocol itself. The document
claims "T", and the evaluator awards "F".
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 section 1.1.3. It should
be noted that this requirement is now a SHOULD in [3]. The document
claims "P", and the evaluator concurs.
1.1.5 Data Object Confidentiality - The document [1] indicates that
end-to-end confidentiality is not available in RADIUS, but goes on to
say that it could be added. The protocol [2] actually makes an
attempt to specify how this is to be done, in section 4.3.2.2 of [2],
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 "F", but in light of
the specifics of the protocol [2], the evaluator awards "P".
1.1.6 Data Object Integrity - The document [1] indicates that end-
to-end integrity is not available in RADIUS, but goes on to say that
it could be added. The protocol [2] actually makes an attempt to
specify how this is to be done, in section 4.3.2.1 of [2], 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 "F", but in light of the specifics
of the protocol [2], the evaluator awards "P".
1.1.7 Certificate Transport - The document [1] indicates that
certificate transport is not available in RADIUS, but goes on to say
that it could be added. The protocol [2] actually makes an attempt
to specify how this is to be done, in section 4.3.2.3 of [2], 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. Other relevant work in the area of certificate support
in RADIUS may be found in an expired work in progress, "RADIUS X.509
Certificate Extensions" [5]. The document claims "F", but in light
of the specifics of the protocol [2], the evaluator awards "P".
1.1.8 Reliable AAA Transport - The document [1] indicates that RADIUS
provides partial compliance with the requirements of the original AAA
requirements document. However, in [3], the requirement has been
simplified to "resilience against packet loss". Once again, the
evaluator finds that the protocol [2] meets this criteria on a hop-
by-hop basis, but fails to effectively address these issues in a
proxy-chain environment. The document claims "P", and the evaluator
awards "F".
1.1.9 Run over IPv4 - RADIUS is widely deployed over IPv4. The
document claims "T", and the evaluator concurs.
1.1.10 Run over IPv6 - The document [1] indicates that adoption of a
limited number of new RADIUS attributes to support IPv6 is
straightforward. Such discussion has transpired on the RADIUS WG
mailing list, although that WG is in the process of shutting down.
The document claims "P", and the evaluator concurs.
1.1.11 Support Proxy and Routing Brokers - The document [1] indicates
that RADIUS is widely deployed in proxy-chains of RADIUS servers.
This is equivalent to the Proxy Broker case, but the Routing Broker
case is a different requirement. The protocol [2] does not describe
any detail of how a Routing Broker might be accommodated, although it
opens the door by indicating that the RADIUS++ protocol is peer-to-
peer, rather than client/server. The document claims "P", and the
evaluator awards "F".
1.1.12 Auditability - The document [1] indicates no compliance with
this requirement. The document claims "F", and the evaluator
concurs.
1.1.13 Shared Secret Not Required - The document [1] indicates that
RADIUS may effectively skirt the requirement of application-layer
security by using a value of "zero" for the pre-shared secret. While
this is a bit creative, it does seem to meet the requirement. The
document claims "T" and the evaluator concurs.
1.1.14 Ability to Carry Service Specific Attributes - RADIUS has a
well defined Vendor-Specific Attribute, which, when properly used,
does indeed provide for the ability to transport service-specific
attributes. The document claims "T", and the evaluator concurs.
1.2 Authentication Requirements
1.2.1 NAI Support - The document [1] indicates that RADIUS specifies
the NAI as one of the suggested formats for the User-Name attribute.
The document claims "T", and the evaluator agrees.
1.2.2 CHAP Support - CHAP support is widely deployed in RADIUS. The
document claims [1] "T", and the evaluator concurs.
1.2.3 EAP Support - The document [1] indicates that EAP support in
RADIUS is specified in [4]. The document claims [1] "T", and the
evaluator concurs.
1.2.4 PAP/Clear-text Passwords - The document [1] indicates that
RADIUS provides protection of clear-text passwords on a hop-by-hop
basis. The protocol [2] indicates how additional data
confidentiality may be obtained in section 4.3.2.2 of [2], 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 [1] "F", but in light of the
specifics of the protocol [2], the evaluator awards "P".
1.2.5 Reauthentication on demand - The document [1] indicates that
RADIUS may accomplish re-authentication on demand by means of an
Access-Challenge message sent from a server to a client. The
evaluator disagrees that this is likely to work for a given session
once an Access-Accept message has been received by the client. The
document claims "T", and the evaluator awards "F".
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). RADIUS does require some form of credential in request
messages. The document [1] claims "F", and the evaluator concurs.
1.3 Authorization Requirements
1.3.1 Static and Dynamic IP Addr Assignment - The document [1]
indicates that RADIUS can assign IPv4 addresses, and can easily be
extended to assign IPv6 addresses (see section 1.1.10). Of greater
concern, however, is the issue of static vs. dynamic addresses. If
dynamic address has the same meaning as it does for DHCP, then there
are issues of resource management that RADIUS has traditionally not
addressed. The document claims "P", and the evaluator concurs.
1.3.2 RADIUS Gateway Capability - The document [1] maintains that a
RADIUS++ to RADIUS gateway is pretty much a tautology. The document
claims "T", and the evaluator concurs.
1.3.3 Reject Capability - The document [1] maintains that RADIUS
Proxy Servers, and potentially RADIUS++ Routing Brokers, have the
ability to reject requests based on local policy. The document
claims "T" and the evaluator concurs.
1.3.4 Preclude Layer 2 Tunneling - The document [1] indicates that
[6] defines support for layer two tunneling in RADIUS. The document
claims "T", and the evaluator concurs.
1.3.5 Reauth on Demand - The document [1] indicates that RADIUS
provides this feature by means of the Session-Timeout and
Termination- Action attributes. While this may, in fact, be
sufficient to provide periodic re-authorization, it would not provide
re- authorization on demand. The protocol [2] does not address this
further. The document claims "P", and the evaluator awards "F".
1.3.6 Support for ACLs - The document [1] describes the attributes in
RADIUS that are used to convey the access controls described in [3].
Certain of these (e.g. QoS) are not currently defined in RADIUS, but
could easily be defined as new RADIUS attributes. The document
claims "P", and the evaluator concurs.
1.3.7 State Reconciliation - The document [1] addresses each of the
sub- items, as listed in the original AAA requirements document. In
reviewing the document against the modified requirements of [3],
there is still an issue with server-initiated state reconciliation
messages. While the protocol [2] makes provision for such messages,
as servers are allowed to initiate protocol dialogs, no detailed
message formats are provided. This is an area that has traditionally
been a short coming of RADIUS. The document claims "P", and the
evaluator awards "F".
1.3.8 Unsolicited Disconnect - Much of the discussion from the
previous section applies to this section. The document [1] claims
"F", and the evaluator concurs.
1.4 Accounting Requirements
1.4.1 Real Time Accounting - RADIUS Accounting is widely deployed and
functions within the definition of real time contained in [3]. The
document [1] claims "T", and the evaluator concurs.
1.4.2 Mandatory Compact Encoding - RADIUS Accounting contains TLVs
for relevant accounting information, each of which is fairly compact.
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 - RADIUS Accounting may be
extended by means of new attributes or by using the Vendor-Specific
attribute. While it has been argued that the existing attribute
number space is too small for the required expansion capabilities,
the protocol [2] addresses this problem in section 3.0, and its
subsections, of [2]. The document [1] claims "T", and the evaluator
concurs.
1.4.4 Batch Accounting - RADIUS has no explicit provisions for batch
accounting, nor does the protocol [2] address how this feature might
be accomplished. The document [1] claims "F", and the evaluator
concurs.
1.4.5 Guaranteed Delivery - RADIUS Accounting is widely deployed and
provides guaranteed delivery within the context of the required
application-level acknowledgment. The document [1] claims "T", and
the evaluator concurs.
1.4.6 Accounting Timestamps - The document [1] indicates that this
feature is specified in [4] as the Event-Timestamp attribute. The
document claims [1] "T", and the evaluator concurs.
1.4.7 Dynamic Accounting - The document [1] indicates that this
requirement is partially met using the accounting interim update
message as specified in [4]. In addition, there was work in the
RADIUS WG regarding session accounting extensions that has not been
included in [4], i.e., some expired works in progress. The document
claims [1] "P", and the evaluator concurs.
1.5 MOBILE IP Requirements
1.5.1 Encoding of MOBILE IP Registration Messages - The document [1]
claims "F", and the evaluator concurs.
1.5.2 Firewall Friendly - The document [1] indicates that RADIUS
deployment is know to have occurred in fire-walled environments. The
document claims "T", and the evaluator concurs.
1.5.3 Allocation of Local Home Agent - The document [1] claims "F",
and the evaluator concurs.
2. Summary Discussion
The document [1] and the protocol [2] suffer from having been written
in a short time frame. While the protocol does provide specific
guidance on certain issues, citing other relevant documents, it is
not a polished protocol specification, with detailed packet format
diagrams. There is a pool of prior work upon which the RADIUS++
protocol may draw, in that many of the concepts of Diameter were
first postulated as works in progress within the RADIUS WG, in an
attempt to "improve" the RADIUS protocol. All of these works in
progress have long since expired, however.
3. General Requirements
RADIUS++ meets many of the requirements of an AAA protocol, as it is
the current de facto and de jure standard for AAA. There are long-
standing deficiencies in RADIUS, which have been well documented in
the RADIUS and NASREQ WG proceedings. It is technically possible to
revamp RADIUS to solve these problems. One question that will be
asked, however, is: "What significant differences would there be
between a finished RADIUS++ protocol and the Diameter protocol?".
4. Summary Recommendation
Recommended in part. What may possibly be learned from this
submission is that it is feasible to have a more RADIUS-compliant
RADIUS-compatibility mode in Diameter.
C.5 Diameter PRO Evaluation
Evaluation of Diameter against the AAA Requirements
PRO Evaluation
Evaluator - Basavaraj Patil
Ref [1] is "Diameter Framework Document".
Ref [2] is "Diameter NASREQ Extensions".
Ref [3] is the AAA evaluation criteria as modified by us.
Ref [4] is "Diameter Accounting Extensions".
Ref [5] is "Diameter Mobile IP Extensions".
Ref [6] is "Diameter Base Protocol".
Ref [7] is "Diameter Strong Security Extension".
Ref [8] is "Comparison of Diameter Against AAA Network Access
Requirements".
The document uses T to indicate total compliance, P to indicate
partial compliance and F to indicate no compliance.
Evaluator's note : The Diameter compliance document [8] claims Total
"T" compliance with all the requirements except : - 1.2.5 - 1.5.2
Section 1 - Per item discussion
1.1 General Requirements
1.1.1 Scalability
Diameter is an evolution of RADIUS and has taken into consideration
all the lessons learned over many years that RADIUS has been in
service. The use of SCTP as the transport protocol reduces the need
for multiple proxy servers (Sec 3.1.1 Proxy Support of [1]) as well
as removing the need for application level acks. The use and support
of forwarding and redirect brokers enhances scalability. Evaluator
concurs with the "T" compliance on this requirement.
1.1.2 Fail-over
Again with the use of SCTP, Diameter is able to detect disconnect
indications upon which it switches to an alternate server (Sec 4.0
[6]). Also Requests and Responses do not have to follow the same
path and this increases the reliability. Evaluator concurs with the
"T" compliance on this requirement.
1.1.3 Mutual Authentication
The compliance document quotes the use of symmetric transforms for
mutual authentication between the client and server (Sec 7.1 of
[6]). The use of IPSec as an underlying security mechanism and
thereby use the characteristics of IPSec itself to satisfy this
requirement is also quoted. Evaluator concurs with the "T"
compliance on this requirement.
1.1.4 Transmission Level Security
Although this requirement has been deprecated by the AAA evaluation
team the document complies with it based on the definition (referring
to hop-by-hop security). Section 7.1 of [6] provides the details of
how this is accomplished in Diameter. Evaluator concurs with the "T"
compliance on this requirement.
1.1.5 Data Object Confidentiality
This requirement seems to have come from Diameter. Ref [7] explains
in detail the use of Cryptographic Message Syntax (CMS) to achieve
data object confidentiality. A CMS-Data AVP is defined in [7].
Evaluator concurs with the "T" compliance on this requirement.
1.1.6 Data Object Integrity
Using the same argument as above and the hop-by-hop security feature
in the protocol this requirement is completely met by Diameter.
Evaluator concurs with the "T" compliance on this requirement.
1.1.7 Certificate Transport
Again with the use of the CMS-Data AVP, objects defined as these
types of attributes allow the transport of certificates. Evaluator
concurs with the "T" compliance on this requirement.
1.1.8 Reliable AAA Transport
Diameter recommends that the protocol be run over SCTP. SCTP
provides the features described for a reliable AAA transport.
Although the compliance is not a perfect fit for the definition of
this tag item, it is close enough and the functionality achieved by
using SCTP is the same. Evaluator concurs with the "T" compliance
on this requirement.
1.1.9 Run over IPv4
Is an application layer protocol and does not depend on the
underlying version of IP. Evaluator concurs with the "T" compliance
on this requirement.
1.1.10 Run over IPv6
Is an application layer protocol and does not depend on the
underlying version of IP. Evaluator concurs with the "T" compliance
on this requirement.
1.1.11 Support Proxy and Routing Brokers
Section 3.1.1/2 of the framework document [1] provides an explanation
of how Diameter supports proxy and routing brokers. In fact it
almost appears as though the requirement for a routing broker came
from Diameter. Evaluator concurs with the "T" compliance on this
requirement.
1.1.12 Auditability
With the use of CMS-Data AVP [7] a trail is created when proxies are
involved in the transaction. This trail can provide auditability.
Evaluator concurs with the "T" compliance on this requirement.
1.1.13 Shared Secret Not Required
With the use of IPSec as the underlying security mechanism, Diameter
does not require the use of shared secrets for message
authentication. Evaluator concurs with the "T" compliance on this
requirement.
1.1.14 Ability to Carry Service Specific Attributes
The base protocol [6] is defined by Diameter and any one else can
define specific extensions on top of it. Other WGs in the IETF can
design an extension on the base protocol with specific attributes and
have them registered by IANA. Evaluator concurs with the "T"
compliance on this requirement.
1.2 Authentication Requirements
1.2.1 NAI Support
The base protocol [6] defines an AVP that can be used to support
NAIs. Diameter goes one step further by doing Message forwarding
based on destination NAI AVPs. Evaluator concurs with the "T"
compliance on this requirement.
1.2.2 CHAP Support
Reference [2] section 3.0 describes the support for CHAP. Evaluator
concurs with the "T" compliance on this requirement.
1.2.3 EAP Support
Reference [2] section 4.0 describes the support for EAP. Evaluator
concurs with the "T" compliance on this requirement.
1.2.4 PAP/Clear-text Passwords
Reference [2] section 3.1.1.1 describes the support for PAP.
Evaluator concurs with the "T" compliance on this requirement.
1.2.5 Reauthentication on demand
The use of Session-Timeout AVP as the mechanism for reauthentication
is claimed by the compliance document. However no direct references
explaining this in the base protocol [6] document were found.
Evaluator deprecates the compliance on this to a "P"
Note: However this is a trivial issue.
1.2.6 Authorization w/o Authentication
Diameter allows requests to be sent without having any authentication
information included. A Request-type AVP is defined in [2] and it
can specify authorization only without containing any authentication.
Evaluator concurs with the "T" compliance on this requirement.
1.3 Authorization Requirements
1.3.1 Static and Dynamic IP Addr Assignment
The base protocol includes an AVP for carrying the address.
References [6.2.2 of 2] and [4.5 of 5] provide detailed explanations
of how this can be done. Evaluator concurs with the "T" compliance
on this requirement.
1.3.2 RADIUS Gateway Capability
One of the basic facets of Diameter is to support backward
compatibility and act as a RADIUS gateway in certain environments.
Evaluator concurs with the "T" compliance on this requirement.
1.3.3 Reject Capability
Based on the explanation provided in the compliance document for this
requirement evaluator concurs with the "T" compliance on this
requirement.
1.3.4 Preclude Layer 2 Tunneling
Ref [2] defines AVPs supporting L2 tunnels Evaluator concurs with
the "T" compliance on this requirement.
1.3.5 Reauth on Demand
A session timer defined in [6] is used for reauthorization. However
Diameter allows reauthorization at any time. Since this is a peer-
to-peer type of protocol any entity can initiate a reauthorization
request. Evaluator concurs with the "T" compliance on this
requirement.
1.3.6 Support for ACLs
Diameter defines two methods. One that supports backward
compatibility for RADIUS and another one with the use of a standard
AVP with the filters encoded in it. Evaluator concurs with the "T"
compliance on this requirement.
1.3.7 State Reconciliation
A long explanation on each of the points defined for this tag item in
the requirements document. Evaluator concurs with the "T" compliance
for this requirement.
1.3.8 Unsolicited Disconnect
The base protocol [6] defines a set of session termination messages
which can be used for unsolicited disconnects. Evaluator concurs
with the "T" compliance on this requirement.
1.4 Accounting Requirements
1.4.1 Real Time Accounting
Evaluator concurs with the "T" compliance based on explanations in
[4].
1.4.2 Mandatory Compact Encoding
Use of Accounting Data Interchange Format (ADIF)-Record-AVP for
compact encoding of accounting data. Evaluator concurs with the "T"
compliance.
1.4.3 Accounting Record Extensibility
ADIF can be extended. Evaluator concurs with the "T" compliance.
1.4.4 Batch Accounting
Sec 1.2 of [4] provides support for batch accounting.
1.4.5 Guaranteed Delivery
Sections 2.1/2 of [4] describe messages that are used to guarantee
delivery of accounting records. Evaluator concurs with the "T"
compliance.
1.4.6 Accounting Timestamps
Timestamp AVP [6] is present in all accounting messages. Evaluator
concurs with the "T" compliance.
1.4.7 Dynamic Accounting
Interim accounting records equivalent to a call-in-progress can be
sent periodically. Evaluator concurs with the "T" compliance.
1.5 MOBILE IP Requirements
1.5.1 Encoding of MOBILE IP Registration Messages
Ref [5] provides details of how Diameter can encode MIP messages.
Evaluator concurs with the "T" compliance.
1.5.2 Firewall Friendly
Some handwaving here and a possible way of solving the firewall
problem with a Diameter proxy server. Document claims "T", evaluator
deprecates it to a "P"
1.5.3 Allocation of Local Home Agent
Diameter can assign a local home agent in a visited network in
conjunction with the FA in that network. Evaluator concurs with the
"T"
Summary Recommendation
Diameter is strongly recommended as the AAA protocol. The experience
gained from RADIUS deployments has been put to good use in the design
of this protocol. It has also been designed with extensibility in
mind thereby allowing different WGs to develop their own specific
extension to satisfy their requirements. With the use of SCTP as the
transport protocol, reliability is built in. Security has been
addressed in the design of the protocol and issues that were
discovered in RADIUS have been fixed. Diameter also is a session
based protocol which makes it more scalable. The support for
forwarding and redirect brokers is well defined and this greatly
improves the scalability aspect of the protocol.
Lastly the protocol has been implemented by at least a few people and
interop testing done. This in itself is a significant step and a
positive point for Diameter to be the AAA protocol.
C.6 Diameter CON Evaluation
Evaluation of Diameter against the AAA Requirements
CON Brief
Evaluator: Barney Wolff
Section 1 - Per item discussion
1.1 General Requirements
1.1.1 Scalability - P (was T) The evaluator is concerned with
scalability to the small, not to the large. Diameter/SCTP may prove
difficult to retrofit to existing NAS equipment.
1.1.2 Fail-over - P (was T) SCTP gives an indication of peer
failure, but nothing in any Diameter or SCTP document the evaluator
was able to find even mentions how or when to switch back to a
primary server to which communication was lost. After a failure, the
state machines end in a CLOSED state and nothing seems to trigger
exit from that state. It was not clear whether a server, on
rebooting, would initiate an SCTP connection to all its configured
clients. If not, and in any case when the communication failure was
in the network rather than in the server, the client must itself,
after some interval, attempt to re-establish communication. But no
such guidance is given.
Of course, the requirement itself fails to mention the notion of
returning to a recovered primary. That is a defect in the