2.1.1. AAA, RADIUS and Diameter
The usage of the AAA framework with RADIUS [RFC2865] and Diameter
[RFC6733] for network access authentication has been successful from
a deployment point of view. To map to the terminology used in Figure
1 to the AAA framework the IdP corresponds to the AAA server, the RP
corresponds to the AAA client, and the technical building blocks of a
federation are AAA proxies, relays and redirect agents (particularly
if they are operated by third parties, such as AAA brokers and
clearing houses). The front-end, i.e. the end host to AAA client
communication, is in case of network access authentication offered by
link layer protocols that forward authentication protocol exchanges
back-and-forth. An example of a large scale RADIUS-based federation
is EDUROAM [4].
By using the AAA framework, ABFAB can be built on the federation
agreements already exist, the agreements can then merely be expanded
Howlett, et al. Expires January 22, 2015 [Page 16]
Internet-Draft ABFAB Architecture July 2014
to cover the ABFAB. The AAA framework has already addressed some of
the problems outlined above. For example,
o It already has a method for routing requests based on a domain.
o It already has an extensible architecture allowing for new
attributes to be defined and transported.
o Pre-existing relationships can be re-used.
The astute reader will notice that RADIUS and Diameter have
substantially similar characteristics. Why not pick one? RADIUS and
Diameter are deployed in different environments. RADIUS can often be
found in enterprise and university networks, and is also in use by
fixed network operators. Diameter, on the other hand, is deployed by
mobile operators. Another key difference is that today RADIUS is
largely transported upon UDP. We leave as a deployment decision,
which protocol will be appropriate. The protocol defines all the
necessary new AAA attributes as RADIUS attributes. A future document
could define the same AAA attributes for a Diameter environment. We
also note that there exist proxies which convert from RADIUS to
Diameter and back. This makes it possible for both to be deployed in
a single federation substrate.
Through the integrity protection mechanisms in the AAA framework, the
identity provider can establish technical trust that messages are
being sent by the appropriate relying party. Any given interaction
will be associated with one federation at the policy level. The
legal or business relationship defines what statements the identity
provider is trusted to make and how these statements are interpreted
by the relying party. The AAA framework also permits the relying
party or elements between the relying party and identity provider to
make statements about the relying party.
The AAA framework provides transport for attributes. Statements made
about the client by the identity provider, statements made about the
relying party and other information are transported as attributes.
Howlett, et al. Expires January 22, 2015 [Page 17]
Internet-Draft ABFAB Architecture July 2014
One demand that the AAA substrate makes of the upper layers is that
they must properly identify the end points of the communication. It
must be possible for the AAA client at the RP to determine where to
send each RADIUS or Diameter message. Without this requirement, it
would be the RP's responsibility to determine the identity of the
client on its own, without the assistance of an IdP. This
architecture makes use of the Network Access Identifier (NAI), where
the IdP is indicated by the realm component [I-D.ietf-radext-nai].
The NAI is represented and consumed by the GSS-API layer as
GSS_C_NT_USER_NAME as specified in [RFC2743]. The GSS-API EAP
mechanism includes the NAI in the EAP Response/Identity message.
As of the time this document was published, no profiles for the use
of Diameter have been created.
2.1.2. Discovery and Rules Determination
While we are using the AAA protocols to communicate with the IdP, the
RP may have multiple federation substrates to select from. The RP
has a number of criteria that it will use in selecting which of the
different federations to use:
o The federation selected must be able to communicate with the IdP.
o The federation selected must match the business rules and
technical policies required for the RP security requirements.
The RP needs to discover which federation will be used to contact the
IdP. The first selection criterion used during discovery is going to
be the name of the IdP to be contacted. The second selection
criteria used during discovery is going to be the set of business
rules and technical policies governing the relationship; this is
called rules determination. The RP also needs to establish technical
trust in the communications with the IdP.
Howlett, et al. Expires January 22, 2015 [Page 18]
Internet-Draft ABFAB Architecture July 2014
Rules determination covers a broad range of decisions about the
exchange. One of these is whether the given RP is permitted to talk
to the IdP using a given federation at all, so rules determination
encompasses the basic authorization decision. Other factors are
included, such as what policies govern release of information about
the client to the RP and what policies govern the RP's use of this
information. While rules determination is ultimately a business
function, it has significant impact on the technical exchanges. The
protocols need to communicate the result of authorization. When
multiple sets of rules are possible, the protocol must disambiguate
which set of rules are in play. Some rules have technical
enforcement mechanisms; for example in some federations
intermediaries validate information that is being communicated within
the federation.
At the time of writing no protocol mechanism has been specified to
allow a AAA client to determine whether a AAA proxy will indeed be
able to route AAA requests to a specific IdP. The AAA routing is
impacted by business rules and technical policies that may be quite
complex and at the present time, the route selection is based on
manual configuration.
2.1.3. Routing and Technical Trust
Several approaches to having messages routed through the federation
substrate are possible. These routing methods can most easily be
classified based on the mechanism for technical trust that is used.
The choice of technical trust mechanism constrains how rules
determination is implemented. Regardless of what deployment strategy
is chosen, it is important that the technical trust mechanism be able
to validate the identities of both parties to the exchange. The
trust mechanism must ensure that the entity acting as IdP for a given
NAI is permitted to be the IdP for that realm, and that any service
name claimed by the RP is permitted to be claimed by that entity.
Here are the categories of technical trust determination:
AAA Proxy:
The simplest model is that an RP is an AAA client and can send the
request directly to an AAA proxy. The hop-by-hop integrity
protection of the AAA fabric provides technical trust. An RP can
submit a request directly to the correct federation.
Alternatively, a federation disambiguation fabric can be used.
Such a fabric takes information about what federations the RP is
part of and what federations the IdP is part of and routes a
message to the appropriate federation. The routing of messages
across the fabric plus attributes added to requests and responses
provides rules determination. For example, when a disambiguation
fabric routes a message to a given federation, that federation's
Howlett, et al. Expires January 22, 2015 [Page 19]
Internet-Draft ABFAB Architecture July 2014
rules are chosen. Name validation is enforced as messages travel
across the fabric. The entities near the RP confirm its identity
and validate names it claims. The fabric routes the message
towards the appropriate IdP, validating the name of the IdP in the
process. The routing can be statically configured. Alternatively
a routing protocol could be developed to exchange reachability
information about a given IdP and to apply policy across the AAA
fabric. Such a routing protocol could flood naming constraints to
the appropriate points in the fabric.
Trust Broker:
Instead of routing messages through AAA proxies, some trust broker
could establish keys between entities near the RP and entities
near the IdP. The advantage of this approach is efficiency of
message handling. Fewer entities are needed to be involved for
each message. Security may be improved by sending individual
messages over fewer hops. Rules determination involves decisions
made by trust brokers about what keys to grant. Also, associated
with each credential is context about rules and about other
aspects of technical trust including names that may be claimed. A
routing protocol similar to the one for AAA proxies is likely to
be useful to trust brokers in flooding rules and naming
constraints.
Global Credential:
A global credential such as a public key and certificate in a
public key infrastructure can be used to establish technical
trust. A directory or distributed database such as the Domain
Name System is used by the RP to discover the endpoint to contact
for a given NAI. Either the database or certificates can provide
a place to store information about rules determination and naming
constraints. Provided that no intermediates are required (or
appear to be required) and that the RP and IdP are sufficient to
enforce and determine rules, rules determination is reasonably
simple. However applying certain rules is likely to be quite
complex. For example if multiple sets of rules are possible
between an IdP and RP, confirming the correct set is used may be
difficult. This is particularly true if intermediates are
involved in making the decision. Also, to the extent that
directory information needs to be trusted, rules determination may
be more complex.
Real-world deployments are likely to be mixtures of these basic
approaches. For example, it will be quite common for an RP to route
traffic to a AAA proxy within an organization. That proxy could then
use any of the three methods to get closer to the IdP. It is also
likely that rather than being directly reachable, the IdP may have a
proxy on the edge of its organization. Federations will likely
Howlett, et al. Expires January 22, 2015 [Page 20]
Internet-Draft ABFAB Architecture July 2014
provide a traditional AAA proxy interface even if they also provide
another mechanism for increased efficiency or security.
2.1.4. AAA Security
For the AAA framework there are two different places where security
needs to be examined. The first is the security that is in place for
the links in the AAA backbone being used. The second are the nodes
that form the AAA backbone.
The default link security for RADIUS is showing its age as it uses
MD5 and a shared secret to both obfuscate passwords and to provide
integrity on the RADIUS messages. While some EAP methods include the
ability to protect the client authentication credentials, the MSK
returned from the IdP to the RP is protected only by the RADIUS
security. In many environments this is considered to be
insufficient, especially as not all attributes are obfuscated and can
thus leak information to a passive eavesdropper. The use of RADIUS
with TLS [RFC6614] and/or DTLS [I-D.ietf-radext-dtls] addresses these
attacks. The same level of security is included in the base Diameter
specifications.
( 粤ICP备18085999号-1 | 粤公网安备 44051102000585号)
狗仔卡
发表于 2015-3-8 11:02:01
置顶卡
千斤顶
显身卡
楼主
发表于 2015-5-2 16:08:04
