Internet DRAFT - draft-schaad-trust-router-problem
draft-schaad-trust-router-problem
Network Working Group J. Schaad
Internet-Draft Soaring Hawk Consulting
Intended status: Informational May 30, 2013
Expires: December 01, 2013
Trust Router Problem Statement
draft-schaad-trust-router-problem-01.txt
Abstract
There are a number of problems with using the current AAA framework
for doing access control, this document looks at a number of these
issues and poses some questions about how to create a new trust
router system.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on December 01, 2013.
Copyright Notice
Copyright (c) 2013 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Schaad Expires December 01, 2013 [Page 1]
Internet-Draft Trust Router Problem May 2013
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Justification . . . . . . . . . . . . . . . . . . . . . . . . 3
2.1. AAA Routing Problems . . . . . . . . . . . . . . . . . . 3
2.2. AAA Security Issues . . . . . . . . . . . . . . . . . . . 4
2.3. X.509 Security Issues . . . . . . . . . . . . . . . . . . 5
3. Trust Router Objectives . . . . . . . . . . . . . . . . . . . 6
4. Entities in the system . . . . . . . . . . . . . . . . . . . 6
4.1. End User . . . . . . . . . . . . . . . . . . . . . . . . 6
4.2. Service Provider . . . . . . . . . . . . . . . . . . . . 6
4.3. Community of Registration (COR) . . . . . . . . . . . . . 7
4.3.1. Atomic CORs . . . . . . . . . . . . . . . . . . . . . 7
4.3.2. Mesh CORs . . . . . . . . . . . . . . . . . . . . . . 7
4.3.3. Release of Information . . . . . . . . . . . . . . . 8
4.4. Communities of Interest (COI) . . . . . . . . . . . . . . 8
4.4.1. Security Issues . . . . . . . . . . . . . . . . . . . 10
4.5. Trust Backbone . . . . . . . . . . . . . . . . . . . . . 10
4.6. Trusted Introducers . . . . . . . . . . . . . . . . . . . 11
4.6.1. Trusted Introducer Initiator . . . . . . . . . . . . 11
4.6.2. Trusted Introducer Router . . . . . . . . . . . . . . 11
4.6.3. Trusted Introducer Target . . . . . . . . . . . . . . 11
5. Communication Flows . . . . . . . . . . . . . . . . . . . . . 11
5.1. COI Distribution . . . . . . . . . . . . . . . . . . . . 12
5.2. COR Connectivity . . . . . . . . . . . . . . . . . . . . 12
5.3. AAA Entity Introduction . . . . . . . . . . . . . . . . . 12
6. Putting it all together . . . . . . . . . . . . . . . . . . . 13
6.1. Scenario - One Trust Backbone . . . . . . . . . . . . . . 13
6.2. Scenario - Three Trust Backbones . . . . . . . . . . . . 14
7. Security Considerations . . . . . . . . . . . . . . . . . . . 15
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16
9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 16
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 16
10.1. Normative References . . . . . . . . . . . . . . . . . . 16
10.2. Informative References . . . . . . . . . . . . . . . . . 16
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 17
1. Introduction
The following document is a product of my diseased mind as opposed to
the deceased minds of the Janet Group or Painless Security.
Specifically, this document uses terms that are defined in
[I-D.howlett-abfab-trust-router-ps] and in
[I-D.mrw-abfab-trust-router] but in completely different ways. One
therefor needs to be clear about which document one is looking at
when referring to these documents as oppose to this one.
Schaad Expires December 01, 2013 [Page 2]
Internet-Draft Trust Router Problem May 2013
The ABFAB architecture as outlined by [I-D.ietf-abfab-arch] provides
the necessary information for understanding the basic needs of ABFAB.
As outlined in that document, there are still number of worries in
terms of trying to implement the ABFAB architecture in the real
world. These worries come out of the way that some of the basic
components used by ABFAB where orignally designed to be used, and the
way that they are actually used in the AFBAB architecture. This
document examines some of the perceived short comings of those
component and provides a basic paradigm that is believed to address
those short comings. In this document a number of issues that any
solution adopting that paradigm is also going need to be addressed
are outlined.
This write up of the problem statement reflects to some degree a
proposed solution to the problem, however it does so in the most
general terms possible. Some pieces are fixed by the ABFAB
architecture, such as the use of RADIUS clients and servers for user
authentication, however other pieces are intentionally left nebulous
(what does the inter AAA server routing look like). A basic picture
of how the different pieces are put together can be found in Figure
1.
2. Justification
This section outlines a number of different areas where components of
the current architecture are considered to be deficient.
2.1. AAA Routing Problems
The fist selection of problems that are examined are related to how
routing is done in the AAA architecture. These issues are, in many
cases, specific to the RADIUS version of AAA. The problems may or
may not also apply to Diameter, however as ABFAB as currently
deployed is focused on RADIUS rather than Diameter these issues still
need to be addressed.
o There is expected to be a large amount of data that is passed
between the EAP server and the EAP client as part of the
validation process. This is a logical consequence of the fact
that we will be using TEAP [I-D.ietf-emu-eap-tunnel-method] which
is based on TLS and thus can contain large certificates, CRLs and
other cryptographic information. Hosting this on top of UDP is
not going to be successful in the long run, the amount of
fragmenting both at the UDP level and at the RADIUS and EAP levels
will lead to poor performance in many cases. The use of TLS/TCP
[RFC6613][RFC6614], with it's session state and recovery will help
this problem.
Schaad Expires December 01, 2013 [Page 3]
Internet-Draft Trust Router Problem May 2013
o Routing needs to be static rather than dynamic from end-to-end.
Given that the routing is based on the conditions required for the
set of messages under consideration, the policy enforcement needs
to be consistent, allowing for routing of each packet in the
stream independently means that enforcement of constraints cannot
be consistently enforced. Again, the use of TLS/TCP helps if one
assumes that sessions are kept up for longer
o Adding and removing destinations from the routing tables is hard
as it must be done for every entity on the backbone.
o There is currently no way to apply policy to the routing of items
based on such things as the LOA desired by the message.
2.2. AAA Security Issues
The next selection of problems to be examined are the security issues
related to the AAA routing infrastructure is deficient to meet the
needs of a truly secure system.
The following represents a set of reasons why the current RADIUS
security is not adequate.
o Link level security is the current state of the art for RADIUS
servers, however it is frequently missing on individual links and
it is not possible for either end point to verify that link level
security is provided over the entirety of the system.
o Link level security is currently configured on each hop in the
link. It would be preferable that the security could be
"centrally" configured.
o Different message need to be routed differently based on the level
of security needed for the message. This is currently addressed
by either having all of the links configured to be at the highest
level of security or for there to be multiple links between
different entities based on the different levels. Since the
configuration is done on each pair of RADIUS entities, there is no
easy way for a third party auditing service to either add or
remove entities from the backbone based on an evaluation of their
security practices.
o RADIUS security is monolithic in concept, this means that one
cannot readily have multiple different communities with different
needs use a single RADIUS network. The network would need to be
configured at the highest needs, but that may not be is not
necessary for all of the communities.
Schaad Expires December 01, 2013 [Page 4]
Internet-Draft Trust Router Problem May 2013
RADIUS dynamic discovery [I-D.ietf-radext-dynamic-discovery] has
attempted to address some of these issues, however based on the
discussions on the RADEXT mailing list this has not always been
successful. Some of the issues found are:
o Setting up the correct security infrastructure based on X.509
certificates is still too high of a bar for some RADIUS server
operators. This means that people are setting up proxy servers
which are discoverer and these then talk to the actual RADIUS
server.
o There are problems with how naming of entities should be done and
what name checking needs to be done when comparing a RADIUS server
with the contents of an X.509 certificate. This becomes even more
complex when there are proxy servers in the path.
o The use of unsecured DNS records to do the lookup from the
original AAA domain name to a server name is problematic as there
is no reason to believe that this cannot be easily attacked by DNS
cache poisoning.
2.3. X.509 Security Issues
Finally we look at the some issues with X.509 security. There is no
way when using the ABFAB architecture to avoid the possibility of
using X.509 certificates. The EAP method TEAP uses TLS, and thus
will likely use an X.509 certificate, even if it is self-signed.
With in the community of ABFAB architecture proponents, is it an
article of faith that the PKIX architecture [RFC5280] is broken and
cannot be trusted. There are many components that go into this
statement, however it is as much a statement of religion as it is of
reality for the proponents of the ABFAB architecture. That being
said, there are a number of reasons why this position can be taken.
o Correct and usable name formats are very difficult to get correct.
This is especially true when proxying needs to be done for. As an
example see [I-D.ietf-radext-dynamic-discovery] for why this is
the case.
o Revocation processing and checking of PKIX systems is frequently
missing.
o Trust Anchors are a problem when looking in these scenarios. One
cannot generally have a single trust anchor due to political a
trust problems, however having a multiplicity of trust points can
yield problems when trying to decide who and why trust can be
placed. Either one is dependent on a general purpose trust system
Schaad Expires December 01, 2013 [Page 5]
Internet-Draft Trust Router Problem May 2013
(i.e., the current set of commercial Certificate Authorities) or
one needs to setup a special purpose CA for the requirements of
the current infrastructure.
o Attribute certificates [RFC5755] have never been readily adopted
as a way to convey attributes.
o Provisioning and restricting of trust anchors is proving
problematic in many cases. This can even be seen in terms of how
one should provision a clients computer with the appropriate trust
anchor for doing EAP validation in the case of using TEAP.
3. Trust Router Objectives
There are three main objectives for this work:
1. Publish the location of AAA servers in a secure manner to all AAA
clients within a trusted network.
2. Create a mechanism to allow for creation of sub-communities
within a AAA system.
3. Create a temporary "short-lived" direct link with a DH or ECDH
key pair for validation between an AAA client/proxy (near the
service) and the AAA server for the user (near the IDP). The
link created will carry policy information for governing the
release of information from the IDP to the AAA client.
4. Entities in the system
This section documents a number of basic entities that are
participating in the trust router system. Some of these entities are
included for completeness as they are part of the ABFAB architecture,
but are not direct participants in the Trust Router architecture.
4.1. End User
The end user is the entity that is requesting a service from the
service provider.
The end user has no pre-existing relationship with the service
provider. The end user does have a pre-existing relationship with an
IDP. The relationship with the IDP will include the ability for a
set of cryptographic credentials to be used to validate the user to
the IDP. This validation is done using one or more EAP methods.
4.2. Service Provider
Schaad Expires December 01, 2013 [Page 6]
Internet-Draft Trust Router Problem May 2013
The Service Provider is used by the end user to get some service.
The Service Provider has a pre-exsting relationship with a local AAA
proxy. The Service Provider itself will be a AAA client.
There is an issue with the current AAA system that needs to be
examined, the ABFAB architecture requires that the AAA proxy that the
SP connects to validate information about the SP. With a large
number of SPs being added to and removed from the AAA network, we
need to look for a way of using the AAA architecture itself to do the
validation of the SP rather than using the configuration of public
keys in the AAA proxy. This can be done with a X.509 certificate
architecture, however this would not match the overall principle of
not using X.509 certificates. The use of EAP and a AAA server to do
the authentication and attribute checking would make the
administration of SPs and End Users similar which would reduce
administrative problems.
4.3. Community of Registration (COR)
At its most basic level, a Community of Registration (COR) consists
of a set of entities and an IDP that can authenticate those entities.
A COR operator has a specific set of requirements about how entities
are to be initially identified, how they are to be authenticated each
time they appear and what information is to released to third parties
upon request. A COR operator may have a multiplicity of such
requirements based on internal policies and requests from service
providers. A Level Of Assurance (LOA) is one of the pieces of
information that a COR would have in this set of requirements.
4.3.1. Atomic CORs
An Atomic COR consists of a single database of registration. It may
consist of one or more on-line presences, but each on-line presence
is required to produce exactly the same results.
4.3.2. Mesh CORs
The following is a potential feature and may not make it into the
final output.
It makes sense to allow for CORs to be aggregated together into a
single unit, thus for example the University of Washington could run
a mesh COR that comprises of the CORs for the undergraduate school,
the law school, the medical school, etc..
Schaad Expires December 01, 2013 [Page 7]
Internet-Draft Trust Router Problem May 2013
There is a known privacy issue with allowing the existence of mesh
CORs, multiple correlated queries can be constructed that can leak
information about which COR an entity is associated, even if that
information is not directly provided to the SP.
4.3.3. Release of Information
The main function of a COR in the ABFAB architecture is to release
information about the end user to the service provider. The smallest
amount of information that can be provided is to say that the COR
does or does not recognized the end user. At the larger end of
infomration provided, the COR can responde to an SP request with a
large number of attributes about the end user as part of a SAML
statement.
The decision of releasing attributes about the end user is an
important issue, the least possible amount of information should
generally be released. If the user can participate in the decision
to release information then that should be encouraged, such
participation is not always possible. The release of information
should always be in accordance with the policy of the IDP and, in
many cases, should be an auditible function.
There is a need to look at how policies are to be provided for both
external review and auditing. It is not clear that this is a strong
requirement ala the CPS framework that PKIX created [RFC3647].
However, the more standardized and machine readable this information
is, the simpler it would be for tools to be able to process and look
at this information. This may be an issue when starting to look at
how things such as attributes are mapped when crossing trust
boundaries.
4.4. Communities of Interest (COI)
One of the goals of this work is to allow for the formation of closed
subsets of users and services within the overall trust architecture
that is created. These closed subsets are called Communities of
Interest.
A COI is defined by the following properties:
o The name of the COI. COIs are expected to be uniquely named
within some domain. The domain that is used and how that is
expressed needs to be determined.
o Version control on the COI. This may be some type of
monotonically increasing value or a time of last update indicator.
If there are multiple possible configuration locations in the
Schaad Expires December 01, 2013 [Page 8]
Internet-Draft Trust Router Problem May 2013
system then a time value may be better as collisions on a counter
could collide. In any event there may be a requirement for
detection of update collisions.
o The set of users that can participate in the COI. The set of
users are defined by the use of one or more attribute. These
attributes can include the name of the user (expressed as an NAI),
the COR for a group of users (i.e. everyone at the University of
Washington) roles, departments and so forth. The method of
expressing the attributes needs to be defined, however one of the
issues that needs to be dealt with is that fact that the
attributes are frequently dependent on the COR that issues them.
This means that attributes will either need to be defined by the
COI, the trust backbone, a global attribute definier or have the
ability to some type of mapping of attribute names.
o The set of security properties that are required for users. Even
when a user might be able to participate in a COI, the location of
the user and the methods of authentication used by the user may
rule out participating in the COI at a given moment. The security
proprities represent a set of dynamic properpties based on how the
user is attached to the network rather than relatively static
properties that the COR will maintain over time. The security
properites may also represent tasks that the COR is requried to
perform during the authentication. An example would be that a COI
requires a specific LOA to be used in authenticating the user.
This is a property of the COI and not a property of the user.
o The set of service providers that are permitted to use the COI.
SPs may be specified by name or other attributes in a similar
manner to that done for users.
o The set of security properties that are required for SPs. This is
similar to the set of security proprieties that are required for
users.
o The set of security properties that are required for the Trusted
Introducers. This is similar to the set of security properties
that are required for users.
COIs are managed in a central location rather than being distributed
through the system. It is presumed that the management of COIs is
connected to the management of Trust Introducers, but that is an
issue that will need to be resolved by the protocol.
It can be seen that ability to make COIs be hierarchical would be a
convenient practice. As an example, a COI could be maintained for
every physical location of the University of Washington. It would
Schaad Expires December 01, 2013 [Page 9]
Internet-Draft Trust Router Problem May 2013
then be able to group those COIs in a hierarchical manner grouping by
larger and larger locations until the entire school is covered. This
means that if a new user or service provider were added to one of the
leafs in the tree then it automatically propagates into all of the
nodes above it in the tree without additional administrative work.
4.4.1. Security Issues
There are a number of security issues that will need to be addressed:
o Should a COI be able to coop a COR without the consent of the COR.
o Depending on how COIs are defined, they can be turned into oracles
about the members of CORs.
o If an SP can use multiple COIs, then it needs a way to select
which COI to use for any single transaction. The choice of the
COI then needs to be provided to the Trust Backbone.
o There are no provisions for the existence of a COI to be published
to either SPs or users. Does there need to be a method for doing
so?
o When COIs are propagated around the trust backbone, does the data
about them need to be kept confidential. While the existence of a
COI is probably not a big security risk, knowledge of the security
parameters and entity attributes about the users of the COI may
constitute a security risk.
4.5. Trust Backbone
The trust backbone is a generic term that is being used to designate
the network of systems which are responsible for connecting the
different CORs together. A trust backbone can come in two flavors:
Intra backbones are maintained by a single entity and operate at a
single level of security. Inter backbones consist of multiple intra
backbones with special systems that operate on the boundaries between
the different intra backbone to mediate the differences in security
practices.
Information flows both within a single backbone and between different
backbones. Within a single backbone, all information flows
unmodified. However when information crosses between backbones it is
frequently modified to deal with differences in policies or simply
prevented from passing across the boundary.
A trust backbone will normally have multiple CORs in it. A trust
backbone is the location where COIs are introduced into the system.
Schaad Expires December 01, 2013 [Page 10]
Internet-Draft Trust Router Problem May 2013
4.6. Trusted Introducers
The concept of a trusted introducer has been around for a long time.
This is the basic method by which webs of trust are created. The
basic model that is to be used will be based on a web of trust and
trusted introducers.
The trusted introducer subsystem is the method where a direct link is
going to be established between the AAA proxy near the SP and the AAA
server for the end user.
4.6.1. Trusted Introducer Initiator
The Trusted Introducer Initiator (TII) is expected to be integrated
into the AAA proxy that is adjacent to the SP. The TII is the
location where the introduction protocol is kicked off. The TII is
required to do the necessary enforcement of the SP identity and
attributes with the security properties of the backbone and the COI
selected by the SP.
4.6.2. Trusted Introducer Router
The Trusted Introducer Router (TIR) is the basic routing element of
the trusted introducer network. TIRs come in two flavors, internal
and boundary TIRs. The internal TIR is a simple thing that just does
routing and the necessary security enforcements. A boundary TIR on
the other hand is responsible to dealing with all of the security
problems that are needed with crossing a security boundary.
4.6.3. Trusted Introducer Target
A Trusted Introducer Target (TIT) is expected to be integrated into
the AAA server. The TIT is the target of the trusted initiator
protocol. The TIT is required to do the necessary enforcement of
security parameters that are imposed by the AAA server and then
return the necessary information for the AAA proxy associated with
the TII to setup a direct TLS link between it and the AAA server.
Once a TLS link between the AAA server and the AAA proxy has been
established, it may be used for more than one AAA protocol exchange.
This means that it is a requirement that the AAA server apply all of
the security information setup on the TLS link be enforced on each
AAA protocol exchange.
5. Communication Flows
Schaad Expires December 01, 2013 [Page 11]
Internet-Draft Trust Router Problem May 2013
There are going to be three different sets of information that will
need to flow through the system. We examine each of those flows and
the properties that are needed.
5.1. COI Distribution
The system will need to distribute information about all COIs from
the centralized configuration points to all of the AAA entities in
the system.
5.2. COR Connectivity
The system will need to distribute the information necessary to build
a path from any specific Trust Introducer to any given COR. In point
of fact, there may be CORs in the system that will not be reachable
from a specific Trust Introducer due to security constraints on the
distribution of COR connectivity.
One of the interesting questions that will need to be explored is:
Can the COR and COI information be distributed independently and
combined on the AAA systems or does it need to be combined by the
Trust Brokers that are doing the distribution of this information.
5.3. AAA Entity Introduction
This flow of communication represents the final goal of the protocol.
We want to be able to build up a TLS connection between the AAA proxy
that resides nearest to the SP and the AAA server that is going to be
used to validate the user.
In building the connection between the proxy and the server the
following will need to be taken into account:
o The identity of the service provider.
o The security properties of the connection between the service
provider and the AAA proxy.
o The COI that will govern the connection.
o The possible routes between the AAA proxy and the AAA server and
their security properties.
Note that no information about the user except the target COR is used
in the path construction as no such information is both available and
reliable. Until the authentication between the user and the COR has
completed the network will have no idea about the user except for the
claimed COR.
Schaad Expires December 01, 2013 [Page 12]
Internet-Draft Trust Router Problem May 2013
6. Putting it all together
In this section there are a number of pictures of different
configurations that are germane to the problem
6.1. Scenario - One Trust Backbone
In this scenario, we are looking at what is the basic roll out that
will be done. In this scenario there are four different security
zones:
o The trust backbone,
o The COR for organization A,
o The COR for organization B,
o The external world
+----------+
| COI |
| Manager |
+----------+
^ |
|
v |
+----------+ +----------+ +----------+
| | | | | Edge |
| TIR B |<------>| TIR A |<----->| TIR |
| | | | | |
+----------+ +----------+ +----------+
^ ^ |
| |
v v |
+----------+ +----------+
| TIT | | TII | |
- - | | -+- - - | | - - - - +
+----------+ | +----------+ |
^ ^
| | |
v v |
+----------+ | +----------+
|AAA Server|<-------->| AAA | | External
| IDP | | | Proxy | World
+----------+ +----------+ |
| ^
| |
Schaad Expires December 01, 2013 [Page 13]
Internet-Draft Trust Router Problem May 2013
| |
v |
+----------+ | +----------+
| Subject |--------->| Relying | |
| | | | Party & |
+----------+ | AAA | |
| | Client |
+----------+ |
|
COR B | COR A |
Multiple CORs - One Trust Backbone
There may be a need to create a different scenario for discussion
about what happens if there is a single COR. Specifically, on needs
to look at the question: Does one still need to go through a AAA
proxy and the trusted introducer protocol or can the SP go directly
to the AAA Server? If one goes directly, then there are some
security gateways that might not get checked.
6.2. Scenario - Three Trust Backbones
In this scenario, we are looking at a more complex roll out. In this
scenario there are five different security zones:
o The trust backbone for A,
o The trust backbone for B,
o The trust backbone for C,
o The COR D,
o The COR E.
In the picture, there is a distinction between the internal and the
edge trust routers. In an actual roll out there may not be distinct
components. However for conversation purposes it is easier to keep
then separate.
Trust Realm A | Trust Realm B | Trust Realm C
+----------+ | | +----------+
| COI | | COI |
| Manager | | | | Manager |
+----------+ +----------+
Schaad Expires December 01, 2013 [Page 14]
Internet-Draft Trust Router Problem May 2013
^ | | ^
| |
v | | v
+----------+ +----------+ +----------+ +----------+
| | | Edge | | Edge | | |
| TIR A1 |<-->| TIR AB |<-->| TIR BC |<-->| TIR C1 |
| | | | | | | |
+----------+ +----------+ +----------+ +----------+
^ | ^ ^ | ^
| v v |
5 | +---------+ | 3
| | | |
v | | TIR B1 | | v
+----------+ | | +----------+
| TIT | | +---------+ | | TIC |
- -| |- - - - - - - - - | | - -
+----------+ | | +----------+
^ ^
| | | |
v v
+----------+ | | +----------+
|AAA Server|<-------------------------------->| AAA |
| IDP | | | | Proxy |
+----------+ +----------+
| | ^
|
v
+----------+ | | +----------+
| Subject |--------------------------------->| Relying |
| | | | | Party & |
+----------+ | AAA |
| | | Client |
+----------+
| |
COR D | | COR E
Figure 1: Architecture
7. Security Considerations
This document does not define a protocol and as such has no direct
security considerations. The document does pose a number of
questions dealing with security that will need to be addressed by a
protocol that implements the problem stated here.
Schaad Expires December 01, 2013 [Page 15]
Internet-Draft Trust Router Problem May 2013
8. IANA Considerations
This document has no IANA considerations.
9. Acknowledgments
This document is an expansion of an email message that was originally
sent to Alan DeKork and was probably passed on to others.
10. References
10.1. Normative References
[I-D.ietf-abfab-arch]
Howlett, J., Hartman, S., Tschofenig, H., Lear, E., and J.
Schaad, "Application Bridging for Federated Access Beyond
Web (ABFAB) Architecture", draft-ietf-abfab-arch-06 (work
in progress), April 2013.
10.2. Informative References
[I-D.howlett-abfab-trust-router-ps]
Howlett, J., Smith, R., and M. Wasserman, "Trust
Requirements in a Federated World", draft-howlett-abfab-
trust-router-ps-03 (work in progress), March 2013.
[I-D.mrw-abfab-trust-router]
Wasserman, M., Hartman, S., and J. Howlett, "Application
Bridging for Federation Beyond the Web (ABFAB) Trust
Router Protocol", draft-mrw-abfab-trust-router-02 (work in
progress), February 2013.
[RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
Housley, R., and W. Polk, "Internet X.509 Public Key
Infrastructure Certificate and Certificate Revocation List
(CRL) Profile", RFC 5280, May 2008.
[I-D.ietf-radext-dynamic-discovery]
Winter, S. and M. McCauley, "NAI-based Dynamic Peer
Discovery for RADIUS/TLS and RADIUS/DTLS", draft-ietf-
radext-dynamic-discovery-06 (work in progress), February
2013.
[I-D.ietf-emu-eap-tunnel-method]
Zhou, H., Cam-Winget, N., Salowey, J., and S. Hanna,
"Tunnel EAP Method (TEAP) Version 1", draft-ietf-emu-eap-
tunnel-method-05 (work in progress), February 2013.
Schaad Expires December 01, 2013 [Page 16]
Internet-Draft Trust Router Problem May 2013
[RFC5755] Farrell, S., Housley, R., and S. Turner, "An Internet
Attribute Certificate Profile for Authorization", RFC
5755, January 2010.
[RFC6613] DeKok, A., "RADIUS over TCP", RFC 6613, May 2012.
[RFC6614] Winter, S., McCauley, M., Venaas, S., and K. Wierenga,
"Transport Layer Security (TLS) Encryption for RADIUS",
RFC 6614, May 2012.
[RFC3647] Chokhani, S., Ford, W., Sabett, R., Merrill, C., and S.
Wu, "Internet X.509 Public Key Infrastructure Certificate
Policy and Certification Practices Framework", RFC 3647,
November 2003.
Author's Address
Jim Schaad
Soaring Hawk Consulting
Email: ietf@augustcellars.com
Schaad Expires December 01, 2013 [Page 17]
