ABFAB译文

lixiaoshuai · 发表于 2015-3-8 11:02:01

马上注册，结交更多好友，享用更多功能^_^

您需要登录才可以下载或查看，没有账号？立即注册

x

看来鱼油们并不感兴趣，这次最后一次发了。

2.1.1 AAA, RADIUS and Diameter
从一个部署点，在AAA框架RADIUS[RFC2865]下，直径[RFC6733]网络接入认证的使用已经成功。如图1所示映射，AAA框架下，IDP对应于AAA服务器的术语，RPC对应于AAA客户端，一个联合的技术构建块，分别是AAA代理，继电器和重定向剂（尤其是当它们是由第三方，如AAA经纪和结算公司操作）。
他的前端，即，终端主机与AAA客户端，通过交换链路层协议提供网络接入认证，可以来回转发认证协议（以实现沟通）。大规模的基于RADIUS联合的例子是EDUROAM[4]。通过AAA框架，ABFAB可建协议联盟已经存在，这些协议不仅仅在扩大于ABFAB。在AAA框架下已经解决了一些上面概述的问题, 例如，
o 它已经有路由基于域的请求方法。
o 它已经拥有了一个可扩展的架构，允许新属性定义和运输。
o 存在的预关系可重复使用。
细心的读者会发现，RADIUS和Diameter有基本上相似的特性。为什么不选一个？RADIUS和直径被部署在不同的环境中。RADIUS往往可以在企业和大学网络发现，也是在由固网运营商使用。另一方面，直径，由移动运营商部署。
另一个关键的区别是，今天是RADIUS在很大程度上是UDP传输。该协议有所调整时，我们离开会是部署决策。该协议定义了所有作为RADIUS属性，所需要的新AAA属性。未来的文档可以定义为一个直径环境相同的AAA属性。我们
还指出，存在代理从RADIUS转换为直径和背部。这使得有可能两个都被部署在一个联合基板。通过在AAA框架的完整性保护机制，可以建立技术信托消息机制，身份提供者经由相应的依赖方发送（消息）。任何给定的相互作用
将与一级联合在政策方面有关。该法律或业务关系定义了报表的身份供应商是值得信赖，以及如何由依赖方将这些语句解释。在AAA框架还允许依靠RP 和身份提供者任一一方做出RP的陈述。AAA框架提供交通工具的属性。报表制作关于有身份提供的客户端，声明对于该RP和其他信息传输的属性。一个要求，即使得AAA生效的上层是它们必须正确识别通信端点。它必须有可能为AAA客户端处的RP确定在何处发送每个RADIUS或Diameter消息。没有这样的要求，它将是RP的责任来确定客户端身份没有了IDP的协助。这种架构利用了网络访问标识符（NAI），其IDP部分是界成分[I-D.ietf-radext-nai] 表示。该NAI表示和指定，GSS-API层在[RFC2743]作为GSS_C_NT_USER_NAME
特殊使用。在GSS-API EAP机制包括EAP响应/身份消息中的钉子。由于当时这份文件发表后，配置文件的使用径未被创建。
2.1.2 发现和确定规则
当我们使用AAA协议与IDP进行通信，所述RP可以有多个联合机制选择。在 RP有许多标准，这将在不同的联合中选择使用何种的：
o 选择的联合必须能够对IDP进行通信。
o 选择该联合必须符合业务规则和符合RP安全要求。
联合用于接触ldP时，RP的需要观察。第一选择标准是ldP的名称。第二选择标准是商业规则和技术政策管理的关系；这就是所谓规则的决心。该RP 也需要建立与ldp通信的技术信任。
规则确定涵盖范围广泛的有关交换的决定。其中之一是在给定的RP是否允许联合所有的lDP说话，因此规则的决心包括基本的授权决定。其他因素包括，什么样的政策管理的信息发布，约客户端的RP，什么样的政策治理RP 以防止利用信息。而规则的决心是企业灵魂，其对技术交流影响显著。该协议需要通信的授权。多组规则是可能的，该协议在规则集中消除歧义。有些规则有技术执行机制;例如，某些联合会中介机构确认，正在内部传达信息。在编写任何协议机制的时间已经指定允许AAA客户端，以确定AAA代理是否的确会能够路由AAA请求到特定的ldP。AAA级路按业务规则和技术政策可能影响相当复杂，在当前时刻，该路由选择是基于手动配置。
2.1.3 路由和技术信任
几种方法使路由有消息，通过联合会支持是可能的。这些路由的方法可以很容易得到技术的信任，在分类机制的基础上。技术的信任机制的选择限制规则如何判定实现。不管是什么部署策略被选择，它的技术信任机制很重要，（因为要）验证双方的身份交换。该信任机制必须保证作为实体的 ldP得到一个NAI获准的标准，任何基于RP的服务都被允许声称该实体。
这里有技术的信任类别：
AAA代理：
最简单的模型是RP是一个AAA客户端，并可以发送直接请求到AAA代理。逐跳完整性保护AAA得到了技术的信任。一个RP可以直接提交请求到正确的联合。可替代地，一个联合消歧织物都可以使用。这种织物大约需要什么样的联合RP的信息的一部分，idp的部分和消息发送到适当联合的路线。消息的路由横跨织物加上属性添加到请求和响应是规则的一部分。例如，当一个消歧织物将消息路由到一个给定的联合，该联合的规则已被选择的。名称验证强制作为旅游信息穿过织物。附近的RP实体确认其身份并验证其命名。该面料由消息路由对相应的ldp，验证了ldp的名字。路由可以被静态配置。另外路由协议可以开发交换可达性，跨AAA给定的IdP和申请信息面料。这样的路由协议可能会在织物上淹没命名，约束合适的点。
可信经纪人：
并非通过AAA代理路由消息，一些信任券商在RP实体和实体之间建立ldp。这种方法的优点是消息处理的效率。需要为每个消息涉及更少的条目。
安全性可以通过发送个人得到改善，减少消息跳跃。规则确定涉及按什么键给予信任的经纪人的决策。此外，相关每个凭证是上下文有关规则和其它技术有关的信任，包括名称声明方面。一类似于用于AAA代理路由协议是可能是对信任经纪人有用，但受洪水规则和命名限制。
全球凭据：
全球凭据，如在公共密钥和公钥基础设施建立技术信任。目录或分布式数据库，如域名名称系统所使用的RP对一个给定的NAI发现端点联系。数据库或证书可以提供一个地方来存储有关确定和命名的限制信息。只要没有中间体是必须的（或似乎是必需的），而RP和lDP足以执行并确定规则，规则执行是相当简单。然而施加一定的规则可能是相当复杂。例如，如果多组规则是可能的ldp和RP之间，确认正确的设置使用可能难。这是真实的，如果是中间体参与作出的决定。另外，在某种程度，目录信息需要被信任，规则确定更为复杂。真实世界的部署可能是这些基本的混合物方法。例如这将是很常见的是RP路由交通组织中的AAA代理。该代理可以再使用任何的三种方法来接近ldp。这也是很有可能，而不是直接到达，国内流离失所者可能有在其组织的边缘代理。联合将可能提供AAA代理接口，即使他们还提供了一个传统的的另一种机制以提高效率或安全性。
2.1.4 AAA安全
AAA框架有两个不同的地方，安全性需要被审查。第一是安全是到位，用于 AAA骨干的链接。第二是在节点形成了AAA的骨干。ADIUS默认链接安全性展示，它使用它的年龄MD5和共享秘密来模糊处理密码，并提供在RADIUS消息的完整性。虽然一些EAP有能力，以保护客户端身份验证凭据，MSK从ldp返回RP是只由RADIUS保护安全性。在许多环境中，这被认为是不足，特别是由于不是所有的属性都模糊处理，并且会泄漏信息到窃听者。使用RADIUS 与TLS[RFC6614]和/或DTLS[ID.ietf-radext-DTLS]解决了这些攻击。相同的安全水平被包含在基座直径规范。

复制代码

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.

复制代码

lixiaoshuai · 发表于 2015-3-8 11:02:53

这次排版没排好，

酱油哥 · 发表于 2015-3-9 10:17:27

强烈支持楼主ing

Ryans · 发表于 2015-5-2 16:08:04

这个好！！这个好哟~

Hugo101 · 发表于 2015-5-12 12:21:49

应该是做这方向的比较少，方向相近的话大家都会来参考的，楼主不要泄气啊~~~~~~~~

StartUp · 发表于 2015-5-17 22:32:09

我只对鱼币感兴趣。

2413780002 · 发表于 2015-5-25 23:32:06

hongqixiadedan · 发表于 2015-5-26 13:25:10

真的能加鱼币么

woshidamowang24 · 发表于 2015-8-7 18:43:30

这是什么啊

DreamClear · 发表于 2015-11-10 13:22:53

看不懂

狮子王辛巴 · 发表于 2015-11-21 18:51:37

强烈支持楼主

showyoyoya · 发表于 2015-11-21 20:44:45

人工置顶

[交流] ABFAB译文

马上注册，结交更多好友，享用更多功能^_^

评分

回帖奖励 +3 鱼币

回帖奖励 +3 鱼币

回帖奖励 +3 鱼币

回帖奖励 +3 鱼币

回帖奖励 +3 鱼币

回帖奖励 +3 鱼币

回帖奖励 +3 鱼币

回帖奖励 +3 鱼币

回帖奖励 +3 鱼币

回帖奖励 +3 鱼币

浏览过的版块

账号		自动登录	找回密码
密码			立即注册