One document matched: draft-schaad-trust-router-problem-00.txt
Network Working Group J. Schaad
Internet-Draft Soaring Hawk Consulting
Intended status: Informational May 24, 2013
Expires: November 25, 2013
Trust Router Problem Statement
draft-schaad-trust-router-problem-00.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 November 25, 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 November 25, 2013 [Page 1]
Internet-Draft Trust Router Problem May 2013
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Real Introduction . . . . . . . . . . . . . . . . . . . . 3
2. Justification . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Routing Problems . . . . . . . . . . . . . . . . . . . . . . 4
4. Trust Router Objectives . . . . . . . . . . . . . . . . . . . 5
5. Entities in the system . . . . . . . . . . . . . . . . . . . 5
5.1. End User . . . . . . . . . . . . . . . . . . . . . . . . 5
5.2. Service Provider . . . . . . . . . . . . . . . . . . . . 6
5.3. Community of Registration (COR) . . . . . . . . . . . . . 6
5.3.1. Atomic CORs . . . . . . . . . . . . . . . . . . . . . 6
5.3.2. Mesh CORs . . . . . . . . . . . . . . . . . . . . . . 7
5.3.3. Release of Information . . . . . . . . . . . . . . . 7
5.4. Communities of Interest (COI) . . . . . . . . . . . . . . 7
5.4.1. Security Issues . . . . . . . . . . . . . . . . . . . 9
5.5. Trust Backbone . . . . . . . . . . . . . . . . . . . . . 9
5.6. Trusted Introducers . . . . . . . . . . . . . . . . . . . 10
5.6.1. Trusted Introducer Initiator . . . . . . . . . . . . 10
5.6.2. Trusted Introducer Router . . . . . . . . . . . . . . 10
5.6.3. Trusted Introducer Target . . . . . . . . . . . . . . 10
6. Communication Flows . . . . . . . . . . . . . . . . . . . . . 11
6.1. COI Distribution . . . . . . . . . . . . . . . . . . . . 11
6.2. COR Connectivity . . . . . . . . . . . . . . . . . . . . 11
6.3. AAA Entity Introduction . . . . . . . . . . . . . . . . . 11
7. Putting it all together . . . . . . . . . . . . . . . . . . . 12
7.1. Scenario - One Trust Backbone . . . . . . . . . . . . . . 12
7.2. Scenario - Three Trust Backbones . . . . . . . . . . . . 13
8. Security Considerations . . . . . . . . . . . . . . . . . . . 16
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16
10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 16
11. 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.
This document is heavily influenced by alcohol. Any one wishing to
fund future trips by the author to Porto, Portugal is requested to
communicate immediately.
Schaad Expires November 25, 2013 [Page 2]
Internet-Draft Trust Router Problem May 2013
This document is an expansion of an email message that was origanally
sent to Alan DeKork and was probably passed on to others. Given that
the updates to the problem statement document
[I-D.howlett-abfab-trust-router-ps] have not been forth comming and
that the BOF needs some documents in order to progress this draft has
been produced.
1.1. Real Introduction
The ABFAB architecture as outlined by [I-D.ietf-abfab-arch] is, for
some, missing a key component. This key component is how the trust
is conveyed between the service provider, the server recipient and
the identity provider in an efficient manner.
2. Justification
The first thing that must be understood in respect to this issue is
that for many of the 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
(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.
Schaad Expires November 25, 2013 [Page 3]
Internet-Draft Trust Router Problem May 2013
Next, it needs to be understood that the current set of AAA routing
infrastructure is deficient to meet the needs of a truly secure
system. Many of these short comings can be seen by the attempt of
[I-D.ietf-radext-dynamic-discovery] to close some of these issues,
but not very successfully.
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.
3. Routing Problems
There are a number of routing specific issues that need to be
addressed with this solution as well.
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 TCP/IP
Schaad Expires November 25, 2013 [Page 4]
Internet-Draft Trust Router Problem May 2013
[RFC6613][RFC6614], with it's session state and recovery will help
this problem.
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 enforce.
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.
4. 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.
5. 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.
5.1. End User
The end user is the entity that is requesting a service from the
service provider.
Schaad Expires November 25, 2013 [Page 5]
Internet-Draft Trust Router Problem May 2013
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.
5.2. Service Provider
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.
5.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.
5.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.
Schaad Expires November 25, 2013 [Page 6]
Internet-Draft Trust Router Problem May 2013
5.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..
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.
5.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.
5.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.
Schaad Expires November 25, 2013 [Page 7]
Internet-Draft Trust Router Problem May 2013
A COI is defined by the following properties:
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.
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
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.
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.
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.
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.
The set of security properties that are required for SPs. This is
similar to the set of security proprieties that are required for
users.
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.
Schaad Expires November 25, 2013 [Page 8]
Internet-Draft Trust Router Problem May 2013
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
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.
5.4.1. Security Issues
There are a number of security issues that will need to be addressed:
Should a COI be able to coop a COR without the consent of the COR.
Depending on how COIs are defined, they can be turned into oracles
about the members of CORs.
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.
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?
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.
5.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.
Schaad Expires November 25, 2013 [Page 9]
Internet-Draft Trust Router Problem May 2013
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.
5.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.
5.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.
5.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.
5.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.
Schaad Expires November 25, 2013 [Page 10]
Internet-Draft Trust Router Problem May 2013
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.
6. Communication Flows
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.
6.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.
6.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.
6.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.
Schaad Expires November 25, 2013 [Page 11]
Internet-Draft Trust Router Problem May 2013
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.
7. Putting it all together
In this section there are a number of pictures of different
configurations that are germane to the problem
7.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
+--------+ +----------+
| Trust | | COI |
| Router | | Manager |
| Root | +----------+
+--------+ ^ |
|
v |
+----------+ +----------+ +----------+
| Trust | | Trust | | Edge |
| Router |<------>| Router |<----->| Trust |
| B | | A | | Router |
+----------+ +----------+ +----------+
^ ^ |
| |
v v |
+----------+ +----------+
| TIT | | TII | |
- - | | -+- - - | | - - - - +
+----------+ | +----------+ |
Schaad Expires November 25, 2013 [Page 12]
Internet-Draft Trust Router Problem May 2013
^ ^
| | |
v v |
+----------+ | +----------+
|AAA Server|<-------->| AAA | | External
| IDP | | | Proxy | World
+----------+ +----------+ |
| ^
| |
| |
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.
7.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
Schaad Expires November 25, 2013 [Page 13]
Internet-Draft Trust Router Problem May 2013
components. However for conversation purposes it is easier to keep
then separate.
Schaad Expires November 25, 2013 [Page 14]
Internet-Draft Trust Router Problem May 2013
Trust Realm A | Trust Realm B | Trust Realm C
+----------+ | | +----------+
| COI | | COI |
| Manager | | | | Manager |
+----------+ +----------+
^ | | ^
| |
v | | v
+----------+ +----------+ +----------+ +----------+
| | | Edge | | Edge | | |
| Trust | | Trust | | Trust | | Trust |
| Router |<-->| Router |<-->| Router |<-->| Router |
| A1 | | AB | | BC | | C1 |
+----------+ +----------+ +----------+ +----------+
^ | ^ ^ | ^
| v v |
5 | +---------+ | 3
| | Trust | |
v | | Router | | v
+----------+ | B1 | +----------+
| TIS | | +---------+ | | TIC |
- -| |- - - - - - - - - | | - -
+----------+ | | +----------+
^ ^
| | | |
v v
+----------+ | | +----------+
|AAA Server|<-------------------------------->| AAA |
| IDP | | | | Proxy |
+----------+ +----------+
| | ^
|
v
+----------+ | | +----------+
| Subject |--------------------------------->| Relying |
| | | | | Party & |
+----------+ | AAA |
| | | Client |
+----------+
| |
COR D | | COR E
Architecture
Schaad Expires November 25, 2013 [Page 15]
Internet-Draft Trust Router Problem May 2013
8. 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.
9. IANA Considerations
This document has no IANA considerations.
10. Acknowledgments
None at the moment, but that will change.
11. 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.
[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.
[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]
Schaad Expires November 25, 2013 [Page 16]
Internet-Draft Trust Router Problem May 2013
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.
[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 November 25, 2013 [Page 17]
| PAFTECH AB 2003-2026 | 2026-04-23 02:13:19 |