< draft-ietf-abfab-arch-04.txt   draft-ietf-abfab-arch-05.txt >
ABFAB J. Howlett ABFAB J. Howlett
Internet-Draft JANET(UK) Internet-Draft JANET(UK)
Intended status: Informational S. Hartman Intended status: Informational S. Hartman
Expires: April 25, 2013 Painless Security Expires: August 29, 2013 Painless Security
H. Tschofenig H. Tschofenig
Nokia Siemens Networks Nokia Siemens Networks
E. Lear E. Lear
Cisco Systems GmbH Cisco Systems GmbH
J. Schaad J. Schaad
Soaring Hawk Consulting Soaring Hawk Consulting
October 22, 2012 February 25, 2013
Application Bridging for Federated Access Beyond Web (ABFAB) Application Bridging for Federated Access Beyond Web (ABFAB)
Architecture Architecture
draft-ietf-abfab-arch-04.txt draft-ietf-abfab-arch-05.txt
Abstract Abstract
Over the last decade a substantial amount of work has occurred in the Over the last decade a substantial amount of work has occurred in the
space of federated access management. Most of this effort has space of federated access management. Most of this effort has
focused on two use-cases: network and web-based access. However, the focused on two use-cases: network access and web-based access.
solutions to these use-cases that have been proposed and deployed However, the solutions to these use-cases that have been proposed and
tend to have few common building blocks in common. deployed tend to have few common building blocks in common.
This memo describes an architecture that makes use of extensions to This memo describes an architecture that makes use of extensions to
the commonly used security mechanisms for both federated and non- the commonly used security mechanisms for both federated and non-
federated access management, including the Remote Authentication Dial federated access management, including the Remote Authentication Dial
In User Service (RADIUS) and the Diameter protocol, the Generic In User Service (RADIUS) and the Diameter protocol, the Generic
Security Service (GSS), the GS2 family, the Extensible Authentication Security Service (GSS), the GS2 family, the Extensible Authentication
Protocol (EAP) and the Security Assertion Markup Language (SAML). Protocol (EAP) and the Security Assertion Markup Language (SAML).
The architecture addresses the problem of federated access management The architecture addresses the problem of federated access management
to primarily non-web-based services, in a manner that will scale to to primarily non-web-based services, in a manner that will scale to
large numbers of identity providers, relying parties, and large numbers of identity providers, relying parties, and
skipping to change at page 2, line 7 skipping to change at page 2, line 7
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on April 25, 2013. This Internet-Draft will expire on August 29, 2013.
Copyright Notice Copyright Notice
Copyright (c) 2012 IETF Trust and the persons identified as the Copyright (c) 2013 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5
1.2. An Overview of Federation . . . . . . . . . . . . . . . . 6 1.1.1. Channel Binding . . . . . . . . . . . . . . . . . . . 6
1.3. Challenges for Contemporary Federation . . . . . . . . . . 9 1.2. An Overview of Federation . . . . . . . . . . . . . . . . 7
1.4. An Overview of ABFAB-based Federation . . . . . . . . . . 10 1.3. Challenges for Contemporary Federation . . . . . . . . . . 10
1.4. An Overview of ABFAB-based Federation . . . . . . . . . . 11
1.5. Design Goals . . . . . . . . . . . . . . . . . . . . . . . 13 1.5. Design Goals . . . . . . . . . . . . . . . . . . . . . . . 13
2. Architecture . . . . . . . . . . . . . . . . . . . . . . . . . 14 2. Architecture . . . . . . . . . . . . . . . . . . . . . . . . . 15
2.1. Relying Party to Identity Provider . . . . . . . . . . . . 15 2.1. Relying Party to Identity Provider . . . . . . . . . . . . 16
2.1.1. AAA, RADIUS and Diameter . . . . . . . . . . . . . . . 16 2.1.1. AAA, RADIUS and Diameter . . . . . . . . . . . . . . . 17
2.1.2. Discovery and Rules Determination . . . . . . . . . . 17 2.1.2. Discovery and Rules Determination . . . . . . . . . . 19
2.1.3. Routing and Technical Trust . . . . . . . . . . . . . 18 2.1.3. Routing and Technical Trust . . . . . . . . . . . . . 20
2.1.4. SAML Assertions . . . . . . . . . . . . . . . . . . . 20 2.1.4. AAA Security . . . . . . . . . . . . . . . . . . . . . 21
2.2. Client To Identity Provider . . . . . . . . . . . . . . . 21 2.1.5. SAML Assertions . . . . . . . . . . . . . . . . . . . 22
2.2.1. Extensible Authentication Protocol (EAP) . . . . . . . 21 2.2. Client To Identity Provider . . . . . . . . . . . . . . . 24
2.2.2. EAP Channel Binding . . . . . . . . . . . . . . . . . 23 2.2.1. Extensible Authentication Protocol (EAP) . . . . . . . 24
2.3. Client to Relying Party . . . . . . . . . . . . . . . . . 23 2.2.2. EAP Channel Binding . . . . . . . . . . . . . . . . . 25
2.3.1. GSS-API . . . . . . . . . . . . . . . . . . . . . . . 23 2.3. Client to Relying Party . . . . . . . . . . . . . . . . . 26
2.3.2. Protocol Transport . . . . . . . . . . . . . . . . . . 25 2.3.1. GSS-API . . . . . . . . . . . . . . . . . . . . . . . 26
3. Application Security Services . . . . . . . . . . . . . . . . 26 2.3.2. Protocol Transport . . . . . . . . . . . . . . . . . . 28
3.1. Authentication . . . . . . . . . . . . . . . . . . . . . . 26 2.3.3. Reauthentication . . . . . . . . . . . . . . . . . . . 28
3.2. GSS-API Channel Binding . . . . . . . . . . . . . . . . . 27 3. Application Security Services . . . . . . . . . . . . . . . . 29
3.3. Host-Based Service Names . . . . . . . . . . . . . . . . . 28 3.1. Authentication . . . . . . . . . . . . . . . . . . . . . . 29
3.4. Per-Message Tokens . . . . . . . . . . . . . . . . . . . . 29 3.2. GSS-API Channel Binding . . . . . . . . . . . . . . . . . 30
4. Future Work: Attribute Providers . . . . . . . . . . . . . . . 30 3.3. Host-Based Service Names . . . . . . . . . . . . . . . . . 31
5. Privacy Considerations . . . . . . . . . . . . . . . . . . . . 31 3.4. Additional GSS-API Services . . . . . . . . . . . . . . . 33
5.1. Entities and their roles . . . . . . . . . . . . . . . . . 31 4. Privacy Considerations . . . . . . . . . . . . . . . . . . . . 34
5.2. Relationship between user and entities . . . . . . . . . . 32 4.1. Entities and their roles . . . . . . . . . . . . . . . . . 34
5.3. Data and Identifiers in use . . . . . . . . . . . . . . . 32 4.2. Relationship between user and entities . . . . . . . . . . 35
5.3.1. NAI . . . . . . . . . . . . . . . . . . . . . . . . . 32 4.3. Data and Identifiers in use . . . . . . . . . . . . . . . 35
5.3.2. Identity Information . . . . . . . . . . . . . . . . . 33 4.3.1. NAI . . . . . . . . . . . . . . . . . . . . . . . . . 35
5.3.3. Accounting Information . . . . . . . . . . . . . . . . 33 4.3.2. Identity Information . . . . . . . . . . . . . . . . . 36
5.3.4. Collection and retention of data and identifiers . . . 33 4.3.3. Accounting Information . . . . . . . . . . . . . . . . 36
5.4. User Participation . . . . . . . . . . . . . . . . . . . . 34 4.3.4. Collection and retention of data and identifiers . . . 36
6. Deployment Considerations . . . . . . . . . . . . . . . . . . 35 4.4. User Participation . . . . . . . . . . . . . . . . . . . . 37
6.1. EAP Channel Binding . . . . . . . . . . . . . . . . . . . 35 5. Deployment Considerations . . . . . . . . . . . . . . . . . . 38
6.2. AAA Proxy Behavior . . . . . . . . . . . . . . . . . . . . 35 5.1. EAP Channel Binding . . . . . . . . . . . . . . . . . . . 38
7. Security Considerations . . . . . . . . . . . . . . . . . . . 36 5.2. AAA Proxy Behavior . . . . . . . . . . . . . . . . . . . . 38
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 38 6. Security Considerations . . . . . . . . . . . . . . . . . . . 39
9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 39 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 41
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 40 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 42
10.1. Normative References . . . . . . . . . . . . . . . . . . . 40 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 43
10.2. Informative References . . . . . . . . . . . . . . . . . . 40 9.1. Normative References . . . . . . . . . . . . . . . . . . . 43
9.2. Informative References . . . . . . . . . . . . . . . . . . 43
Editorial Comments . . . . . . . . . . . . . . . . . . . . . . . . Editorial Comments . . . . . . . . . . . . . . . . . . . . . . . .
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 45 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 49
1. Introduction 1. Introduction
The Internet uses numerous security mechanisms to manage access to The Internet uses numerous security mechanisms to manage access to
various resources. These mechanisms have been generalized and scaled various resources. These mechanisms have been generalized and scaled
over the last decade through mechanisms such as Simple Authentication over the last decade through mechanisms such as Simple Authentication
and Security Layer (SASL) with the Generic Security Server and Security Layer (SASL) with the Generic Security Server
Application Program Interface (GSS-API) (known as the GS2 family) Application Program Interface (GSS-API) (known as the GS2 family)
[RFC5801], Security Assertion Markup Language (SAML) [RFC5801], Security Assertion Markup Language (SAML)
[OASIS.saml-core-2.0-os], and the Authentication, Authorization, and [OASIS.saml-core-2.0-os], and the Authentication, Authorization, and
skipping to change at page 5, line 37 skipping to change at page 5, line 37
GS2 family, the Extensible Authentication Protocol (EAP) and SAML. GS2 family, the Extensible Authentication Protocol (EAP) and SAML.
The architecture addresses the problem of federated access management The architecture addresses the problem of federated access management
primarily for non-web-based services. It does so in a manner that primarily for non-web-based services. It does so in a manner that
will scale to large numbers of identity providers, relying parties, will scale to large numbers of identity providers, relying parties,
and federations. and federations.
1.1. Terminology 1.1. Terminology
This document uses identity management and privacy terminology from This document uses identity management and privacy terminology from
[I-D.iab-privacy-considerations]. In particular, this document uses [I-D.iab-privacy-considerations]. In particular, this document uses
the terms identity provider, relying party, (data) subject, the terms identity provider, relying party, identifier, pseudonymity,
identifier, pseudonymity, unlinkability, and anonymity. unlinkability, and anonymity.
In this architecture the IdP consists of the following components: an In this architecture the IdP consists of the following components: an
EAP server, a RADIUS or a Diameter server, and optionally a SAML EAP server, a RADIUS or a Diameter server, and optionally a SAML
Assertion service. Assertion service.
This document uses the term Network Access Identifier (NAI), as This document uses the term Network Access Identifier (NAI), as
defined in [RFC4282]. An NAI consists of a realm identifier, which defined in [RFC4282]. An NAI consists of a realm identifier, which
is associated with an IdP and a username which is associated with a is associated with an IdP and a username which is associated with a
specific client of the IdP. specific client of the IdP.
skipping to change at page 6, line 17 skipping to change at page 6, line 17
which maps the different terms into a single table. which maps the different terms into a single table.
+----------+-----------+--------------------+-----------------------+ +----------+-----------+--------------------+-----------------------+
| Protocol | Subject | Relying Party | Identity Provider | | Protocol | Subject | Relying Party | Identity Provider |
+----------+-----------+--------------------+-----------------------+ +----------+-----------+--------------------+-----------------------+
| ABFAB | Client | Relying Party (RP) | Identity Provider | | ABFAB | Client | Relying Party (RP) | Identity Provider |
| | | | (IdP) | | | | | (IdP) |
| | | | | | | | | |
| | Initiator | Acceptor | | | | Initiator | Acceptor | |
| | | | | | | | | |
| | | Server | |
| | | | |
| SAML | Subject | Service Provider | Issuer | | SAML | Subject | Service Provider | Issuer |
| | | | | | | | | |
| GSS-API | Initiator | Acceptor | | | GSS-API | Initiator | Acceptor | |
| | | | | | | | | |
| EAP | EAP peer | | EAP server | | EAP | EAP peer | | EAP server |
| | | | | | | | | |
| AAA | | AAA Client | AAA server | | AAA | | AAA Client | AAA server |
| | | | | | | | | |
| RADIUS | user | NAS | RADIUS server | | RADIUS | user | NAS | RADIUS server |
| | | | | | | | | |
| | | RADIUS client | | | | | RADIUS client | |
+----------+-----------+--------------------+-----------------------+ +----------+-----------+--------------------+-----------------------+
Note that in some cases a cell has been left empty, in these cases Note that in some cases a cell has been left empty, in these cases
there is no direct name that represents this concept. there is no direct name that represents this concept.
Note to reviewers - I have most likely missed some entries in the Note to reviewers - I have most likely missed some entries in the
table. Please provide me with both correct names from the protocol table. Please provide me with both correct names from the protocol
and missing names that are used in the text below. and missing names that are used in the text below.
1.1.1. Channel Binding
This document uses the term channel binding with two different
meanings.
EAP channel binding, also called channel binding, is used to provide
GSS-API naming semantics. Channel binding sends a set of attributes
from the peer to the EAP server either as part of the EAP
converstaion or as part of a secure association protocol. In
addition, attributes are sent in the baackend protocol from the
authenticator to the EAP server. The EAP server confirms the
consistency of these attributes and provides the confirmation back to
the peer.
GSS-API channel binding provides protection against man-in-the-middle
attacks when GSS-API is used for authentication inside of some
tunnel; it is similar to a facility called cryptographic binding in
EAP. The binding works by each side deriving a cryptographic value
from the tunnel itself and then using that cyrptographic value to
prove to the otherside that it knows the value.
See [RFC5056] for a discussion of the differences between these two
facilities.
Typically when considering channel binding, people think of channel
binding in combination with mutual authentication. This is
sufficiently common that without additional qualification channel
binding should be assumed to imply mutual authentication. Without
mutual authentication, only one party knows that the endpoints are
correct. That's sometimes useful. Consider for example a user who
wishes to access a protected resource from a shared whiteboard in a
conference room. The whiteboard is the initiator; it does not need
to actually authenticate that it is talking to the correct resource
because the user will be able to recognize whether the displayed
content is correct. If channel binding were used without mutual
authentication, it would in effect be a request to only disclose the
resource in the context of a particular channel. Such an
authentication would be similar in concept to a holder-of-key SAML
assertion. However, also note that while it is not happening in the
protocol, mutual authentication is happening in the overall system:
the user is able to visually authenticate the content. This is
consistent with all uses of channel binding without protocol level
mutual authentication found so far.
1.2. An Overview of Federation 1.2. An Overview of Federation
In the previous section we introduced the following actors: In the previous section we introduced the following actors:
o the Client, o the Client,
o the Identity Provider, and o the Identity Provider, and
o the Relying Party. o the Relying Party.
skipping to change at page 9, line 22 skipping to change at page 10, line 15
While it is possible to have a bilateral agreement between every IdP While it is possible to have a bilateral agreement between every IdP
and every RP; on an Internet scale this setup requires the and every RP; on an Internet scale this setup requires the
introduction of the multi-lateral federation concept, as the introduction of the multi-lateral federation concept, as the
management of such pair-wise relationships would otherwise prove management of such pair-wise relationships would otherwise prove
burdensome. burdensome.
The IdP will typically have a long-term relationship with the Client. The IdP will typically have a long-term relationship with the Client.
This relationship typically involves the IdP positively identifying This relationship typically involves the IdP positively identifying
and credentialing the Client (for example, at time of employment and credentialing the Client (for example, at time of employment
within an organization). The relationship will often be instantiated within an organization). When dealing with individuals, this process
within an agreement between the IdP and the Client (for example, is called identity proofing [NIST-SP.800-63]. The relationship will
within an employment contract or terms of use that stipulates the often be instantiated within an agreement between the IdP and the
appropriate use of credentials and so forth). Client (for example, within an employment contract or terms of use
that stipulates the appropriate use of credentials and so forth).
The nature and quality of the relationship between the Subject and The nature and quality of the relationship between the Subject and
the IdP is an important contributor to the level of trust that an RP the IdP is an important contributor to the level of trust that an RP
may attribute to an assertion describing a Client made by an IdP. may attribute to an assertion describing a Client made by an IdP.
This is sometimes described as the Level of Assurance. This is sometimes described as the Level of Assurance
[NIST-SP.800-63].
Federation does not require an a priori relationship or a long-term Federation does not require an a priori relationship or a long-term
relationship between the RP and the Client; it is this property of relationship between the RP and the Client; it is this property of
federation that yields many of its benefits. However, federation federation that yields many of its benefits. However, federation
does not preclude the possibility of a pre-existing relationship does not preclude the possibility of a pre-existing relationship
between the RP and the Client, nor that they may use the introduction between the RP and the Client, nor that they may use the introduction
to create a new long-term relationship independent of the federation. to create a new long-term relationship independent of the federation.
Finally, it is important to reiterate that in some scenarios there Finally, it is important to reiterate that in some scenarios there
might indeed be an Individual behind the Client and in other cases might indeed be an Individual behind the Client and in other cases
skipping to change at page 14, line 29 skipping to change at page 15, line 29
effort, etc.) is preferred and there may be a need to specify effort, etc.) is preferred and there may be a need to specify
multiple mechanisms to support the range of different deployment multiple mechanisms to support the range of different deployment
scenarios. scenarios.
There are a number of ways for encapsulating EAP into an application There are a number of ways for encapsulating EAP into an application
protocol. For ease of integration with a wide range of non-Web based protocol. For ease of integration with a wide range of non-Web based
application protocols the usage of the GSS-API was chosen. A application protocols the usage of the GSS-API was chosen. A
description of the technical specification can be found in description of the technical specification can be found in
[I-D.ietf-abfab-gss-eap]. Other alternatives exist as well and may [I-D.ietf-abfab-gss-eap]. Other alternatives exist as well and may
be considered later, such as "TLS using EAP Authentication" be considered later, such as "TLS using EAP Authentication"
[I-D.nir-tls-eap].[anchor7] [I-D.nir-tls-eap]. [anchor7]
The architecture consists of several building blocks, which is shown The architecture consists of several building blocks, which is shown
graphically in Figure 2. In the following sections, we discuss the graphically in Figure 2. In the following sections, we discuss the
data flow between each of the entities, the protocols used for that data flow between each of the entities, the protocols used for that
data flow and some of the trade-offs made in choosing the protocols. data flow and some of the trade-offs made in choosing the protocols.
+--------------+ +--------------+
| Identity | | Identity |
| Provider | | Provider |
| (IdP) | | (IdP) |
skipping to change at page 15, line 23 skipping to change at page 16, line 23
/// \\\ /// \\\
// \\ // \\
| Federation | | Federation |
| Substrate | | Substrate |
\\ // \\ //
\\\ /// \\\ ///
--^----------^-- --^----------^--
* EAP o RADIUS/ * EAP o RADIUS/
* o Diameter * o Diameter
+-------------+ +-v----------v--+ +-------------+ +-v----------v--+
| |<---------------->| | | | | |
| Client | EAP/EAP Method | Relying Party | | Client | EAP/EAP Method | Relying Party |
| Application |<****************>| (RP) | | Application |<****************>| (RP) |
| | GSS-API | | | | GSS-API | |
| |<---------------->| | | |<---------------->| |
| | Application | | | | Application | |
| | Protocol | | | | Protocol | |
| |<================>| | | |<================>| |
+-------------+ +---------------+ +-------------+ +---------------+
Legend: Legend:
skipping to change at page 16, line 5 skipping to change at page 17, line 5
2.1. Relying Party to Identity Provider 2.1. Relying Party to Identity Provider
Communications between the Relying Party and the Identity Provider is Communications between the Relying Party and the Identity Provider is
done by the federation substrate. This communication channel is done by the federation substrate. This communication channel is
responsible for: responsible for:
o Establishing the trust relationship between the RP and the IdP. o Establishing the trust relationship between the RP and the IdP.
o Determining the rules governing the relationship. o Determining the rules governing the relationship.
o Conveying EAP packets between the RP and IdP. o Conveying authentication packets from the client to the IdP and
back.
o Providing the means of establishing a trust relationship between
the RP and the client.
o Providing a means for the RP to obtain attributes about the client
from the IdP.
The ABFAB working group has chosen the AAA framework for the messages The ABFAB working group has chosen the AAA framework for the messages
transported between the RP and IdP. This allows for the current AAA transported between the RP and IdP. The AAA framework supports the
protocols to be used to establish the trust relationship between the requirements stated above as follows:
RP and the IdP. Future protocols that support the same framework but
do different routing may be used in the future. There is currently o The AAA backbone supplies the trust relationship between the RP
an effort to setup a framework that creates a trusted point-to-point and the IdP.
channel on the fly. The ABFAB protocol itself details the method of
establishing the trust relationship between the RP and the client. o The agreements governing a specific AAA backbone contains the
rules governing the relationships within the AAA federation.
o A method exists for carrying EAP packets within RADIUS [RFC3579]
and Diameter [RFC4072].
o The use of EAP channel binding [RFC6677] along with the core ABFAB
protocol provide the pieces necessary to establish the identities
of the RP and the client, while EAP provides the cryptographic
methods for the RP and the client to validate they are talking to
each other.
o A method exists for carrying SAML packets within RADIUS
[I-D.ietf-abfab-aaa-saml] and Diameter (work in progress) which
allows the RP to query attributes about the client from the IdP.
Future protocols that support the same framework but do different
routing may be used in the future. Once such effort is to setup a
framework that creates a trusted point-to-point channel on the fly.
2.1.1. AAA, RADIUS and Diameter 2.1.1. AAA, RADIUS and Diameter
Interestingly, for network access authentication the usage of the AAA Interestingly, for network access authentication the usage of the AAA
framework with RADIUS [RFC2865] and Diameter [RFC3588] was quite framework with RADIUS [RFC2865] and Diameter [RFC3588] was quite
successful from a deployment point of view. To map the terminology successful from a deployment point of view. To map the terminology
used in Figure 1 to the AAA framework the IdP corresponds to the AAA 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 server, the RP corresponds to the AAA client, and the technical
building blocks of a federation are AAA proxies, relays and redirect building blocks of a federation are AAA proxies, relays and redirect
agents (particularly if they are operated by third parties, such as agents (particularly if they are operated by third parties, such as
skipping to change at page 18, line 21 skipping to change at page 19, line 46
the principal to the RP and what policies govern the RP's use of this the principal to the RP and what policies govern the RP's use of this
information. While rules determination is ultimately a business information. While rules determination is ultimately a business
function, it has significant impact on the technical exchanges. The function, it has significant impact on the technical exchanges. The
protocols need to communicate the result of authorization. When protocols need to communicate the result of authorization. When
multiple sets of rules are possible, the protocol must disambiguate multiple sets of rules are possible, the protocol must disambiguate
which set of rules are in play. Some rules have technical which set of rules are in play. Some rules have technical
enforcement mechanisms; for example in some federations enforcement mechanisms; for example in some federations
intermediaries validate information that is being communicated within intermediaries validate information that is being communicated within
the federation. the federation.
ABFAB has not formally defined any part of discovery at this point. At the time of writing no protocol mechanism has been specified to
The process of specifying and evaluating the business rules and allow a AAA client to determine whether a AAA proxy will indeed be
technical policies is too complex to provide a simple framework. able to route AAA requests to a specific IdP. The AAA routing is
There is not currently a way to know if a AAA proxy is able to impacted by business rules and technical policies that may be quite
communicate with a specific IdP, although this may change with some complex and atpresent time, the route selection is based on manual
of the routing protocols that are being considered. At the present configuration.
time, the discovery process is going to be a manual configuration
process.
2.1.3. Routing and Technical Trust 2.1.3. Routing and Technical Trust
Several approaches to having messages routed through the federation Several approaches to having messages routed through the federation
substrate are possible. These routing methods can most easily be substrate are possible. These routing methods can most easily be
classified based on the mechanism for technical trust that is used. classified based on the mechanism for technical trust that is used.
The choice of technical trust mechanism constrains how rules The choice of technical trust mechanism constrains how rules
determination is implemented. Regardless of what deployment strategy determination is implemented. Regardless of what deployment strategy
is chosen, it is important that the technical trust mechanism be able is chosen, it is important that the technical trust mechanism be able
to validate the names of both parties to the exchange. The trust to validate the names of both parties to the exchange. The trust
skipping to change at page 20, line 11 skipping to change at page 21, line 33
Real-world deployments are likely to be mixtures of these basic Real-world deployments are likely to be mixtures of these basic
approaches. For example, it will be quite common for an RP to route 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 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 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 likely that rather than being directly reachable, the IdP may have a
proxy on the edge of its organization. Federations will likely proxy on the edge of its organization. Federations will likely
provide a traditional AAA proxy interface even if they also provide provide a traditional AAA proxy interface even if they also provide
another mechanism for increased efficiency or security. another mechanism for increased efficiency or security.
2.1.4. SAML Assertions 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 is the nodes
that the backbone consists of.
The default link security for RADIUS is showing it's age as it uses
MD5 and a shared secret to both obfuscate passwords and to provide
integrity on the RADIUS messages. 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.
TBD - Put in text - Not all nodes can be eliminated - proxy nodes may
be required Trust router looks for a way to shorten the list of inner
nodes. Reference DYNAMIC and say that it does or does not help and
why. Talk about Diameter in the same context - does it have the same
set of issues or not?
2.1.5. SAML Assertions
For the traditional use of AAA frameworks, network access, the only For the traditional use of AAA frameworks, network access, the only
requirement that was necessary to grant access was an affirmative requirement that was necessary to grant access was an affirmative
response from the IdP. In the ABFAB world, the RP may need to get response from the IdP. In the ABFAB world, the RP may need to get
additional information about the client before granting access. additional information about the client before granting access.
ABFAB therefore has a requirement that it can transport an arbitrary ABFAB therefore has a requirement that it can transport an arbitrary
set of attributes about the client from the IdP to the RP. set of attributes about the client from the IdP to the RP.
Security Assertions Markup Language (SAML) [OASIS.saml-core-2.0-os] Security Assertions Markup Language (SAML) [OASIS.saml-core-2.0-os]
was designed in order to carry an extensible set of attributes about was designed in order to carry an extensible set of attributes about
a subject. Since SAML is extensible in the attribute space, ABFAB a subject. Since SAML is extensible in the attribute space, ABFAB
has no immediate needs to update the core SAML specifications for our has no immediate needs to update the core SAML specifications for our
work. It will be necessary to update IdPs that need to return SAML work. It will be necessary to update IdPs that need to return SAML
assertions to IdPs and for both the IdP and the RP to implement a new assertions to IdPs and for both the IdP and the RP to implement a new
SAML profile designed to carry SAML assertions in AAA. The new SAML profile designed to carry SAML assertions in AAA. The new
profile can be found in RFCXXXX [I-D.ietf-abfab-aaa-saml]. profile can be found in RFCXXXX [I-D.ietf-abfab-aaa-saml]. As SAML
statements will frequently be large, RADIUS servers and clients that
deal with SAML statements will need to implement RFC XXXX
[I-D.perez-radext-radius-fragmentation]
There are two issues that need to be highlighted: There are several issues that need to be highlighted:
o The security of SAML assertions. o The security of SAML assertions.
o Namespaces and mapping of SAML attributes. o Namespaces and mapping of SAML attributes.
o Subject naming of entities.
o Making multiple queries about the subject(s).
o Level of Assurance for authentication.
SAML assertions have an optional signature that can be used to SAML assertions have an optional signature that can be used to
protect and provide origination of the assertion. These signatures protect and provide origination of the assertion. These signatures
are normally based on asymmetric key operations and require that the are normally based on asymmetric key operations and require that the
verifier be able to check not only the cryptographic operation, but verifier be able to check not only the cryptographic operation, but
also the binding of the originators name and the public key. In a also the binding of the originators name and the public key. In a
federated environment it will not always be possible for the RP to federated environment it will not always be possible for the RP to
validate the binding, for this reason the technical trust established validate the binding, for this reason the technical trust established
in the federation is used as an alternate method of validating the in the federation is used as an alternate method of validating the
origination and integrity of the SAML Assertion. origination and integrity of the SAML Assertion.
skipping to change at page 21, line 14 skipping to change at page 23, line 19
namespace, naming and semantic mappings as the assertion crosses the namespace, naming and semantic mappings as the assertion crosses the
different boundaries in the federation. If the proxies are modifying different boundaries in the federation. If the proxies are modifying
the SAML Assertion, then will obviously remove any signatures on the the SAML Assertion, then will obviously remove any signatures on the
SAML assertions as they would no longer validate. In this case the SAML assertions as they would no longer validate. In this case the
technical trust is the required mechanism for validating the technical trust is the required mechanism for validating the
integrity of the assertion. Finally, the attributes may still be in integrity of the assertion. Finally, the attributes may still be in
the namespace of the originating IdP. When this occurs the RP will the namespace of the originating IdP. When this occurs the RP will
need to get the required mapping operations from the federation need to get the required mapping operations from the federation
agreements and do the appropriate mappings itself. agreements and do the appropriate mappings itself.
As of this writing, no one has defined a SAML name format that
corresponds to the NAI structure defined by RFC 4282 [RFC4282]. This
means that there is no method to directly place the same NAI used in
RADIUS or Diameter as the subject name of a SAML assertion. It is a
requirement on the EAP server that it validate that the subject of
the SAML name, if any, is equivalent to the subject identified by the
NAI used in the RADIUS or Diameter session.
RADIUS has the ability to deal with multiple SAML queries for those
EAP Servers which follow RFC 5080 [RFC5080]. In this case a State
attribute will always been returned with the Access-Accept. The EAP
client can then send a new Access-Request with the State attribute
and the new SAML request Multiple SAML queries can them be done by
making a new Access-Request using the State attribute returned in the
last Access-Accept to link together the different RADIUS sessions.
Some RPs need to ensure that specfic criteria are met during the
authentication process. This need is met by using Levels of
Assurance. The way a Level of Assurance is communicated to from the
RP to the EAP server is by the use of a SAML Authentication Request
using the Authentication Profile from RFC XXX
[I-D.ietf-abfab-aaa-saml] When crossing boundaries between different
federations, either the policy specfied will need to be shared
between the two federations, the policy will need to be mapped by the
proxy server on the boundary or the proxy server on the boundary will
need to supply infomration the EAP server so that it can do the
required mapping. If this mapping is not done, then the EAP server
will not be able to enforce the desired Level of Assurance as it will
not understand the policy requirements.
2.2. Client To Identity Provider 2.2. Client To Identity Provider
Looking at the communications between the client and the IdP, the Looking at the communications between the client and the IdP, the
following items need to be dealt with: following items need to be dealt with:
o The client and the IdP need to mutually authenticate each other. o The client and the IdP need to mutually authenticate each other.
o The client and the IdP need to mutually agree on the identity of o The client and the IdP need to mutually agree on the identity of
the RP. the RP.
skipping to change at page 23, line 26 skipping to change at page 26, line 17
The client knows, in theory, the name of the RP that it attempted to The client knows, in theory, the name of the RP that it attempted to
connect to, however in the event that an attacker has intercepted the connect to, however in the event that an attacker has intercepted the
protocol, the client and the IdP need to be able to detect this protocol, the client and the IdP need to be able to detect this
situation. A general overview of the problem along with a situation. A general overview of the problem along with a
recommended way to deal with the channel binding issues can be found recommended way to deal with the channel binding issues can be found
in RFC 6677 [RFC6677]. in RFC 6677 [RFC6677].
Since that document was published, a number of possible attacks were Since that document was published, a number of possible attacks were
found and methods to address these attacks have been outlined in found and methods to address these attacks have been outlined in
[I-D.hartman-emu-mutual-crypto-bind]. [I-D.ietf-emu-crypto-bind].
2.3. Client to Relying Party 2.3. Client to Relying Party
The final set of interactions between parties to consider are those The final set of interactions between parties to consider are those
between the client and the RP. In some ways this is the most complex between the client and the RP. In some ways this is the most complex
set since at least part of it is outside the scope of the ABFAB work. set since at least part of it is outside the scope of the ABFAB work.
The interactions between these parties include: The interactions between these parties include:
o Running the protocol that implements the service that is provided o Running the protocol that implements the service that is provided
by the RP and desired by the client. by the RP and desired by the client.
o Authenticating the client to the RP and the RP to the client. o Authenticating the client to the RP and the RP to the client.
o Providing the necessary security services to the service protocol o Providing the necessary security services to the service protocol
that it needs beyond authentication. that it needs beyond authentication.
o Deal with client re-authentication where desired.
2.3.1. GSS-API 2.3.1. GSS-API
One of the remaining layers is responsible for integration of One of the remaining layers is responsible for integration of
federated authentication into the application. There are a number of federated authentication into the application. There are a number of
approaches that applications have adopted for security. So, there approaches that applications have adopted for security. So, there
may need to be multiple strategies for integration of federated may need to be multiple strategies for integration of federated
authentication into applications. However, we have started with a authentication into applications. However, we have started with a
strategy that provides integration to a large number of application strategy that provides integration to a large number of application
protocols. protocols.
skipping to change at page 26, line 5 skipping to change at page 28, line 32
o The transport needs to provide reliable transport of the messages. o The transport needs to provide reliable transport of the messages.
o The transport needs to ensure that tokens are delivered in order o The transport needs to ensure that tokens are delivered in order
during the negotiation process. during the negotiation process.
o GSS-API messages need to be delivered atomically. If the o GSS-API messages need to be delivered atomically. If the
transport breaks up a message it must also reassemble the message transport breaks up a message it must also reassemble the message
before delivery. before delivery.
2.3.3. Reauthentication
TBD.
3. Application Security Services 3. Application Security Services
One of the key goals is to integrate federated authentication into One of the key goals is to integrate federated authentication into
existing application protocols and where possible, existing existing application protocols and where possible, existing
implementations of these protocols. Another goal is to perform this implementations of these protocols. Another goal is to perform this
integration while meeting the best security practices of the integration while meeting the best security practices of the
technologies used to perform the integration. This section describes technologies used to perform the integration. This section describes
security services and properties required by the EAP GSS-API security services and properties required by the EAP GSS-API
mechanism in order to meet these goals. This information could be mechanism in order to meet these goals. This information could be
viewed as specific to that mechanism. However, other future viewed as specific to that mechanism. However, other future
skipping to change at page 26, line 34 skipping to change at page 29, line 34
providing (potentially anonymous or pseudonymous) identity to the providing (potentially anonymous or pseudonymous) identity to the
acceptor, the acceptor confirms its identity to the initiator. acceptor, the acceptor confirms its identity to the initiator.
Especially for the ABFAB context, this service is confusingly named. Especially for the ABFAB context, this service is confusingly named.
We still say that mutual authentication is provided when the identity We still say that mutual authentication is provided when the identity
of an acceptor is strongly authenticated to an anonymous initiator. of an acceptor is strongly authenticated to an anonymous initiator.
RFC 2743, unfortunately, does not explicitly talk about what mutual RFC 2743, unfortunately, does not explicitly talk about what mutual
authentication means. Within this document we therefore define it authentication means. Within this document we therefore define it
as: as:
o If a target name is supplied to the initiator, then the initiator o If a target name is configured for the initiator, then the
trusts that the supplied target name describes the acceptor. This initiator trusts that the supplied target name describes the
implies both that appropriate cryptographic exchanges took place acceptor. This implies both that appropriate cryptographic
for the initiator to make such a trust decision, and that after exchanges took place for the initiator to make such a trust
evaluating the results of these exchanges, the initiator's policy decision, and that after evaluating the results of these
trusts that the target name is accurate. exchanges, the initiator's policy trusts that the target name is
accurate.
o If no target name is supplied to the initiator, then the initiator o If no target name is configured for the initiator, then the
trusts that the acceptor name, supplied by the acceptor, correctly initiator trusts that the acceptor name, supplied by the acceptor,
names the entity it is communicating with. correctly names the entity it is communicating with.
o Both the initiator and acceptor have the same key material for o Both the initiator and acceptor have the same key material for
per-message keys and both parties have confirmed they actually per-message keys and both parties have confirmed they actually
have the key material. In EAP terms, there is a protected have the key material. In EAP terms, there is a protected
indication of success. indication of success.
Mutual authentication is an important defense against certain aspects Mutual authentication is an important defense against certain aspects
of phishing. Intuitively, users would like to assume that if some of phishing. Intuitively, clients would like to assume that if some
party asks for their credentials as part of authentication, party asks for their credentials as part of authentication,
successfully gaining access to the resource means that they are successfully gaining access to the resource means that they are
talking to the expected party. Without mutual authentication, the talking to the expected party. Without mutual authentication, the
acceptor could "grant access" regardless of what credentials are server could "grant access" regardless of what credentials are
supplied. Mutual authentication better matches this user intuition. supplied. Mutual authentication better matches this user intuition.
It is important, therefore, that the GSS-EAP mechanism implement It is important, therefore, that the GSS-EAP mechanism implement
mutual authentication. That is, an initiator needs to be able to mutual authentication. That is, an initiator needs to be able to
request mutual authentication. When mutual authentication is request mutual authentication. When mutual authentication is
requested, only EAP methods capabale of providing the necessary requested, only EAP methods capable of providing the necessary
service can be used, and appropriate steps need to be taken to service can be used, and appropriate steps need to be taken to
provide mutual authentication. A broader set of EAP methods could be provide mutual authentication. While a broader set of EAP methods
supported when a particular application does not request mutual could be supported by not requiring mutual authentication, it was
authentication. It is an open question whether the mechanism will decided that the client needs to always have the ability to request
permit this. it. In some cases the IdP and the RP will not support mutual
authentication, however the client will always be able to detect this
and make an appropriate security decision.
The AAA infrastructure MAY hide the peer's identity from the GSS-API The AAA infrastructure MAY hide the initiator's identity from the
acceptor, providing anonymity between the peer and initiator. At GSS-API acceptor, providing anonymity between the initiator and the
this time, whether the identity is disclosed is determined by EAP acceptor. At this time, whether the identity is disclosed is
server policy rather than by an indication from the peer. Also, determined by EAP server policy rather than by an indication from the
peers are unlikely to be able to determine whether anonymous initiator. Also, initiators are unlikely to be able to determine
communication will be provided. For this reason, peers are unlikely whether anonymous communication will be provided. For this reason,
to set the anonymous return flag from GSS_Init_Sec_context. initiators are unlikely to set the anonymous return flag from
GSS_Init_Sec_context.
3.2. GSS-API Channel Binding 3.2. GSS-API Channel Binding
[RFC5056] defines a concept of channel binding to prevent man-in-the- [RFC5056] defines a concept of channel binding to which is used
middle attacks. It is common to provide SASL and GSS-API with prevent man-in-the-middle attacks. The channel binding works by
another layer to provide transport security; Transport Layer Security taking a cryptographic value from the transport security and checks
(TLS) is the most common such layer. TLS provides its own server that both sides of the GSS-API conversation know this value.
authentication. However there are a variety of situations where this Transport Layer Security (TLS) is the most common transport security
authentication is not checked for policy or usability reasons. Even layer used for this purpose.
when it is checked, if the trust infrastructure behind the TLS
authentication is different from the trust infrastructure behind the It needs to be stressed that RFC 5056 channel binding (also called
GSS-API mutual authentication then confirming the end-points using GSS-API channel binding when GSS-API is involved) is not the same
both trust infrastructures is likely to enhance security. If the thing as EAP channel binding. GSS-API channel binding is used for
endpoints of the GSS-API authentication are different than the detecting Man-In-The-Middle attacks. EAP channel binding is used for
endpoints of the lower layer, this is a strong indication of a mututal authentication and acceptor naming checks. Details are
problem such as a man-in-the-middle attack. Channel binding provides discussed in the mechanisms specification [I-D.ietf-abfab-gss-eap].
a facility to determine whether these endpoints are the same. A fuller discription of the differences between the factilities cn be
found in RFC 5056 [RFC5056].
The use of TLS can provide both encryption and integrity on the
channel. It is common to provide SASL and GSS-API with these other
security services.
On of the benifits that the use of TLS provides, is that client has
the ability to validate the name of the server. However this
validation is predicated on on a couple of things. The TLS sessions
needs to be using certificates and not be an anonymous session. The
client and the TLS need to share a common trust point for the
certificate used in validating the server. TLS provides its own
server authentication. However there are a variety of situations
where this authentication is not checked for policy or usability
reasons. Even when it is checked, if the trust infrastructure behind
the TLS authentication is different from the trust infrastructure
behind the GSS-API mutual authentication then confirming the end-
points using both trust infrastructures is likely to enhance
security. If the endpoints of the GSS-API authentication are
different than the endpoints of the lower layer, this is a strong
indication of a problem such as a man-in-the-middle attack. Channel
binding provides a facility to determine whether these endpoints are
the same.
The GSS-EAP mechanism needs to support channel binding. When an The GSS-EAP mechanism needs to support channel binding. When an
application provides channel binding data, the mechanism needs to application provides channel binding data, the mechanism needs to
confirm this is the same on both sides consistent with the GSS-API confirm this is the same on both sides consistent with the GSS-API
specification. specification.
Typically when considering channel binding, people think of channel
binding in combination with mutual authentication. This is
sufficiently common that without additional qualification channel
binding should be assumed to imply mutual authentication. Without
mutual authentication, only one party knows that the endpoints are
correct. That's sometimes useful. Consider for example a user who
wishes to access a protected resource from a shared whiteboard in a
conference room. The whiteboard is the initiator; it does not need
to actually authenticate that it is talking to the correct resource
because the user will be able to recognize whether the displayed
content is correct. If channel binding were used without mutual
authentication, it would in effect be a request to only disclose the
resource in the context of a particular channel. Such an
authentication would be similar in concept to a holder-of-key SAML
assertion. However, also note that while it is not happening in the
protocol, mutual authentication is happening in the overall system:
the user is able to visually authenticate the content. This is
consistent with all uses of channel binding without protocol level
mutual authentication found so far.
RFC 5056 channel binding (also called GSS-API channel binding when
GSS-API is involved) is not the same thing as EAP channel binding.
EAP channel binding is also used in the ABFAB context in order to
implement acceptor naming and mutual authentication. Details are
discussed in the mechanisms specification [I-D.ietf-abfab-gss-eap].
3.3. Host-Based Service Names 3.3. Host-Based Service Names
IETF security mechanisms typically take the name of a service entered IETF security mechanisms typically take a host name and perhaps a
by a user and make some trust decision about whether the remote party service, entered by a user, and make some trust decision about
in an interaction is the intended party. GSS-API has a relatively whether the remote party in the interaction is the intended party.
flexible naming architecture. However most of the IETF applications This decision can be made by the use of certificates, pre-configured
that use GSS-API, including SSH, NFS, IMAP, LDAP and XMPP, have key information or a previous leap of trust. GSS-API has defined a
chosen to use host-based service names when they use GSS-API. In relatively flexible name convention, however most of the IETF
this model, the initiator names an acceptor based on a service such applications that use GSS-API (including SSH, NFS, IMAP, LDAP and
as "imap" or "host" (for login services such as SSH) and a host name. XMPP) have chosen to use a more restricted naming convention based on
the host name. The GSS-EAP mechanism needs to support host-based
service names in order to work with existing IETF protocols.
Using host-based service names leads to a challenging trust The use of host-based service names leads to a challenging trust
delegation problem. Who is allowed to decide whether a particular delegation problem. Who is allowed to decide whether a particular
hostname maps to an entity. The public-key infrastructure (PKI) used host name maps to a specific entity. Possible solutions to this
by the web has chosen to have a number of trust anchors (root problem have been looked at.
certificate authorities) each of which can map any name to a public
key. A number of GSS-API mechanisms, such as Kerberos [RFC1964],
split the problem into two parts. A new concept called a realm is
introduced. Then the mechanism decides what realm is responsible for
a given name. That realm is responsible for deciding if the acceptor
entity is allowed to claim the name. ABFAB needs to adopt this
approach.
Host-based service names do not work ideally when different instances The public-key infrastructure (PKI) used by the web has chosen to
of a service are running on different ports. Also, these do not work have a number of trust anchors (root certificate authorities) each
ideally when SRV record or other insecure referrals are used. of which can map any host name to a public key.
The GSS-EAP mechanism needs to support host-based service names in A number of GSS-API mechanisms, such as Kerberos [RFC1964], have
order to work with existing IETF protocols. split the problem into two parts. A new concept called a realm is
introduced, the realm is responsible for host mapping within that
realm. The mechanism then decides what realm is responsible for a
given name. This is the approach adopted by ABFAB.
3.4. Per-Message Tokens GSS-EAP defines a host naming convention that takes into account the
host name, the realm, the service and the service parameters. An
example of GSS-API service name is "xmpp/foo@example.com". This
identifies the XMPP service on the host foo in the realm example.com.
Any of the components, except for the service name may be omitted
from a name. When omitted, then a local default would be used for
that component of the name.
GSS-API provides per-message security services that can provide While there is no requirement that realm names map to Fully Qualified
confidentiality and integrity. Some IETF protocols such as NFS and Domain Names (FQDN) within DNS, in practice this is normally true.
SSH take advantage of these services. As a result GSS-EAP needs to Doing so allows for the realm portion of service names and the
support these services. As with mutual authentication, per-message portion of NAIs to be the same. It also allows for the use of DNS in
services will limit the set of EAP methods that are available. Any locating the host of a service while establishing the transport
EAP method that produces a Master Session Key (MSK) is able to channel between the client and the relying party.
support per-message security services described in [X].
GSS-API provides a pseudo-random function. While the pseudo-random It is the responsibility of the application to determine the server
function does not involve sending data over the wire, it provides an that it is going to communicate with, GSS-API has the ability to help
algorithm that both the initiator and acceptor can run in order to confirm that the server is the desired server but not to determine
arrive at the same key value. This is useful for designs where a the name of the server to use. It is also the responsibility of the
successful authentication is used to key some other function. This application to determine how much of the information identifying the
is similar in concept to the TLS extractor. No current IETF service needs to be validated by the ABFAB system. The information
protocols require this. However GSS-EAP supports this service that needs to be validated is used to build up the service name
because it is valuable for the future and easy to do given per- passed into the GSS-EAP mechanism. What information is to be
message services. Non-IETF protocols are expected to take advantage validated will depend on both what information was provided by the
of this in the near future. client, and what information is considered significant. If the
client only cares about getting a specific service, then the host and
realm that provides the service does not need to be validated.
4. Future Work: Attribute Providers In many cases applications may retrieve information about providers
of services from DNS. When Service Records (SRV) and Naming
Authority Pointer (NAPTR) records are used to help find a host that
provides a service, the security requirements on the referrals is
going to interact with the information used in the service name. If
the a host name is returned from the DNS referrals, and the host name
is to be validated by GS-EAP, then it makes sense that the referrals
themselves should be secure. On the other hand, if the host name
returned is not validated, i.e. only the service is passed in, then
it is less important that the host name be obtained in a secure
manner.
This architecture provides for a federated authentication and Another issue that needs to be addressed for host-based service names
authorization framework between IdPs, RPs, principals, and subjects. is that they do not work ideally when different instances of a
It does not at this time provide for a means to retrieve attributes service are running on different ports. If the services are
from 3rd parties. However, it envisions such a possibility. We note equivalent, then it does not matter. However if there are
that in any extension to the model, an attribute provider must be substantial differences in the quality of the service that
authorized to release specific attributes to a specific RP for a information needs to be part of the validation process. If one has
specific principal. In addition, we note that it is an open question just a host name and not a port in the information being validated,
beyond this architecture as to how the RP should know to trust a then this is not going to be a successful strategy.
particular attribute provider.
There are a number of possible technical means to provide attribute 3.4. Additional GSS-API Services
provider capabilities. One possible approach is for the IdP to
provide a signed attribute request to RP that it in turn will provide
to the attribute authority. Another approach would be for the IdP to
provide a URI to the RP that contains a token of some form. The form
of communications between the IdP and attribute provider as well as
other considerations are left for the future. One thing we can say
now is that the IdP would merely be asserting who the attribute
authority is, and not the contents of what the attribute authority
would return. (Otherwise, the IdP might as well make the query to
the attribute authority and then resign it.)
5. Privacy Considerations GSS-API provides per-message security services that can provide
confidentiality and/or integrity. Some IETF protocols such as NFS
and SSH take advantage of these services. As a result GSS-EAP needs
to support these services. As with mutual authentication, per-
message services will limit the set of EAP methods that can be used
to those that generate a Master Session Key (MSK). Any EAP method
that produces an MSK is able to support per-message security services
described in [RFC2743].
GSS-API provides a pseudo-random function. This function generates a
pseudo-random sequence using the shared private key as the seed for
the bytes generated. This provides an algorithm that both the
initiator and acceptor can run in order to arrive at the same key
value. The use of this feature allows for an application to generate
keys or other shared secrets for use in other places in the protocol.
In this regards, it is similar in concept to the TLS extractor (RFC
5705 [RFC5705].). While no current IETF protocols require this, non-
IETF protocols are expected to take advantage of this in the near
future. Additionally, a number of protocols have found the TLS
extractor to be useful in this regards so it is highly probably that
IETF protocols may also start using this feature.
4. Privacy Considerations
ABFAB, as an architecture designed to enable federated authentication ABFAB, as an architecture designed to enable federated authentication
and allow for the secure transmission of identity information between and allow for the secure transmission of identity information between
entities, obviously requires careful consideration around privacy and entities, obviously requires careful consideration around privacy and
the potential for privacy violations. the potential for privacy violations.
This section examines the privacy related information presented in This section examines the privacy related information presented in
this document, summarising the entities that are involved in ABFAB this document, summarising the entities that are involved in ABFAB
communications and what exposure they have to identity information. communications and what exposure they have to identity information.
In discussing these privacy considerations in this section, we use In discussing these privacy considerations in this section, we use
terminology and ideas from [I-D.iab-privacy-considerations]. terminology and ideas from [I-D.iab-privacy-considerations].
Note that the ABFAB architecture uses at its core several existing Note that the ABFAB architecture uses at its core several existing
technologies and protocols; detailed privacy discussion around these technologies and protocols; detailed privacy discussion around these
is not examined. This section instead focuses on privacy is not examined. This section instead focuses on privacy
considerations specifically related to overall architecture and usage considerations specifically related to overall architecture and usage
of ABFAB. of ABFAB.
5.1. Entities and their roles 4.1. Entities and their roles
In an ABFAB environment, there are four distinct types of entities In an ABFAB environment, there are four distinct types of entities
involved in communication paths. Figure 2 shows the ABFAB involved in communication paths. Figure 2 shows the ABFAB
architecture with these entity types. We have: architecture with these entity types. We have:
o The client application: usually a piece of software running on a o The client application: usually a piece of software running on a
user's device. This communicates with a service (the Relying user's device. This communicates with a service (the Relying
Party) that the user wishes to interact with. Party) that the user wishes to interact with.
o The Identity Provider: The home AAA server for the user. o The Identity Provider: The home AAA server for the user.
skipping to change at page 32, line 5 skipping to change at page 35, line 5
As described in detail earlier in this document, when a user wishes As described in detail earlier in this document, when a user wishes
to access a Relying Party, a secure tunnel is set up between their to access a Relying Party, a secure tunnel is set up between their
client application and their Identity Provider (via the Relying Party client application and their Identity Provider (via the Relying Party
and the federation substrate) through which credentials are and the federation substrate) through which credentials are
exchanged. An indication of success or failure, alongside a set of exchanged. An indication of success or failure, alongside a set of
AAA attributes about a principal is then passed from the Identity AAA attributes about a principal is then passed from the Identity
Provider to the Relying Party (usually in the form of a SAML Provider to the Relying Party (usually in the form of a SAML
assertion). assertion).
5.2. Relationship between user and entities 4.2. Relationship between user and entities
o Between User and Identity Provider - the identity Provider is an o Between User and Identity Provider - the identity Provider is an
entity the user will have a direct relationship with, created when entity the user will have a direct relationship with, created when
the organisation that operates the entity provisioned and the organisation that operates the entity provisioned and
exchanged the user's credentials. Privacy and data protection exchanged the user's credentials. Privacy and data protection
guarantees may form a part of this relationship. guarantees may form a part of this relationship.
o Between User and Relying Party - the Relying Party is an entity o Between User and Relying Party - the Relying Party is an entity
the user may or may not have a direct relationship with, depending the user may or may not have a direct relationship with, depending
on the service in question. Some services may only be offered to on the service in question. Some services may only be offered to
skipping to change at page 32, line 36 skipping to change at page 35, line 36
service. service.
o Between User and Federation substrate - the user is highly likely o Between User and Federation substrate - the user is highly likely
to have no knowledge of, or relationship with, any entities to have no knowledge of, or relationship with, any entities
involved with the federation substrate (not that the Identity involved with the federation substrate (not that the Identity
Provider and/or Relying Party may, however). Knowledge of Provider and/or Relying Party may, however). Knowledge of
attribute information about individuals for these entities is not attribute information about individuals for these entities is not
necessary, and thus such information should be protected in such a necessary, and thus such information should be protected in such a
way as to prevent access to this information from being possible. way as to prevent access to this information from being possible.
5.3. Data and Identifiers in use 4.3. Data and Identifiers in use
In the ABFAB architecture, there are a few different types of data In the ABFAB architecture, there are a few different types of data
and identifiers in use. and identifiers in use.
5.3.1. NAI 4.3.1. NAI
In order for the Relying Party to be able to route messages to enable In order for the Relying Party to be able to route messages to enable
an EAP transaction to occur between client application and the an EAP transaction to occur between client application and the
correct identity Provider, it is necessary for the client application correct identity Provider, it is necessary for the client application
to provide enough information to the Relying Party to enable the to provide enough information to the Relying Party to enable the
identification of the correct Identity Provider. This takes the form identification of the correct Identity Provider. This takes the form
of an Network Access Identifier (NAI) (as specified in [RFC4282]). of an Network Access Identifier (NAI) (as specified in [RFC4282]).
Note that an NAI can have inner and outer forms in a AAA Note that an NAI can have inner and outer forms in a AAA
architecture. architecture.
skipping to change at page 33, line 21 skipping to change at page 36, line 21
o The inner part of NAI is sent through the secure tunnel as o The inner part of NAI is sent through the secure tunnel as
established by the EAP protocol; this form of the NAI will contain established by the EAP protocol; this form of the NAI will contain
credentials for the user suitable for authenticating them credentials for the user suitable for authenticating them
successfully (e.g. a username and password). Since the entire successfully (e.g. a username and password). Since the entire
purpose of the secure tunnel is to protect communications between purpose of the secure tunnel is to protect communications between
client application (EAP client) and Identity Provider (EAP client application (EAP client) and Identity Provider (EAP
server), then it is considered secure from eavesdroppers or server), then it is considered secure from eavesdroppers or
malicious intermediaries and no further privacy discussion is malicious intermediaries and no further privacy discussion is
necessary. necessary.
5.3.2. Identity Information 4.3.2. Identity Information
As a part of the ABFAB process, after a successful authentication has As a part of the ABFAB process, after a successful authentication has
occurred between client application and Identity Provider, an occurred between client application and Identity Provider, an
indication of this success is sent to the Relying Party. Alongside indication of this success is sent to the Relying Party. Alongside
this message, information about the user may be returned through AAA this message, information about the user may be returned through AAA
attributes, usually in form of a SAML assertion. This information is attributes, usually in form of a SAML assertion. This information is
arbitrary and may include either only attributes that prevent an arbitrary and may include either only attributes that prevent an
individual from being identified by the Relying Party (thus enabling individual from being identified by the Relying Party (thus enabling
anonymous or pseudonymous access) or attributes that contain anonymous or pseudonymous access) or attributes that contain
personally identifiable information. personally identifiable information.
Depending on the method used, this information carried through AAA Depending on the method used, this information carried through AAA
attributes may or may not be accessible to intermediaries involved in attributes may or may not be accessible to intermediaries involved in
communications - e.g. in the case of RADIUS and unencrypted SAML, communications - e.g. in the case of RADIUS and unencrypted SAML,
these headers are plain text and could be seen by any observer, these headers are plain text and could be seen by any observer,
whereas if using RADSEC or encrypted SAML, these headers are whereas if using RADSEC or encrypted SAML, these headers are
protected from observers. Obviously, where the protection of the protected from observers. Obviously, where the protection of the
privacy of an individual is required then this information needs to privacy of an individual is required then this information needs to
be protected by some appropriate means. be protected by some appropriate means.
5.3.3. Accounting Information 4.3.3. Accounting Information
Alongside the core authentication and authorization that occurs in Alongside the core authentication and authorization that occurs in
AAA communications, accounting information about resource consumption AAA communications, accounting information about resource consumption
may be delivered as part of the accounting exchange during the may be delivered as part of the accounting exchange during the
lifetime of the granted application session. lifetime of the granted application session.
5.3.4. Collection and retention of data and identifiers 4.3.4. Collection and retention of data and identifiers
In cases where Relying Parties do not require to identify a In cases where Relying Parties do not require to identify a
particular individual when an individual wishes to make use of their particular individual when an individual wishes to make use of their
service, the ABFAB architecture enable anonymous or pseudonymous service, the ABFAB architecture enable anonymous or pseudonymous
access. Thus data and identifiers other than pseudonyms and access. Thus data and identifiers other than pseudonyms and
unlinkable attribute information need not be stored and retained. unlinkable attribute information need not be stored and retained.
However, in cases where Relying Parties require the ability to However, in cases where Relying Parties require the ability to
identify a particular individual (e.g. so they can link this identity identify a particular individual (e.g. so they can link this identity
information to a particular account in their service, or where information to a particular account in their service, or where
identity information is required for audit purposes), the service identity information is required for audit purposes), the service
will need to collect and store such information, and to retain it for will need to collect and store such information, and to retain it for
as long as they require. Deprovisioning of such accounts and as long as they require. Deprovisioning of such accounts and
information is out of scope for ABFAB, but obviously for privacy information is out of scope for ABFAB, but obviously for privacy
protection any identifiers collected should be deleted when they are protection any identifiers collected should be deleted when they are
no longer needed. no longer needed.
5.4. User Participation 4.4. User Participation
In the ABFAB architecture, by its very nature users are active In the ABFAB architecture, by its very nature users are active
participants in the sharing of their identifiers as they initiate the participants in the sharing of their identifiers as they initiate the
communications exchange every time they wish to access a server. communications exchange every time they wish to access a server.
They are, however, not involved in control of the set of information They are, however, not involved in control of the set of information
related to them that transmitted from Identity Provider to Relying related to them that transmitted from Identity Provider to Relying
Party for authorisation purposes. Party for authorisation purposes.
6. Deployment Considerations 5. Deployment Considerations
6.1. EAP Channel Binding 5.1. EAP Channel Binding
Discuss the implications of needing EAP channel binding. Discuss the implications of needing EAP channel binding.
6.2. AAA Proxy Behavior 5.2. AAA Proxy Behavior
Discuss deployment implications of our proxy requirements. Discuss deployment implications of our proxy requirements.
7. Security Considerations 6. Security Considerations
This document describes the architecture for Application Bridging for This document describes the architecture for Application Bridging for
Federated Access Beyond Web (ABFAB) and security is therefore the Federated Access Beyond Web (ABFAB) and security is therefore the
main focus. This section highlights the main communication channels main focus. This section highlights the main communication channels
and their security properties: and their security properties:
Client-to-RP Channel: Client-to-RP Channel:
The channel binding material is provided by any certificates and The channel binding material is provided by any certificates and
the final message (i.e., a cryptographic token for the channel). the final message (i.e., a cryptographic token for the channel).
skipping to change at page 38, line 5 skipping to change at page 41, line 5
Issues, Naming of Entities, Protection of passwords, Channel Binding, Issues, Naming of Entities, Protection of passwords, Channel Binding,
End-point-connections (TLS), Proxy problems End-point-connections (TLS), Proxy problems
When a psuedonym is generated as a unique long term identifier for a When a psuedonym is generated as a unique long term identifier for a
Subject by an IdP, care MUST be taken in the algorithm that it cannot Subject by an IdP, care MUST be taken in the algorithm that it cannot
easily be reverse engineered by the service provider. If it can be easily be reverse engineered by the service provider. If it can be
reversed then the service provider can consult an oracle to determine reversed then the service provider can consult an oracle to determine
if a given unique long term identifier is associated with a different if a given unique long term identifier is associated with a different
known identifier. known identifier.
8. IANA Considerations 7. IANA Considerations
This document does not require actions by IANA. This document does not require actions by IANA.
9. Acknowledgments 8. Acknowledgments
We would like to thank Mayutan Arumaithurai and Klaas Wierenga for We would like to thank Mayutan Arumaithurai and Klaas Wierenga for
their feedback. Additionally, we would like to thank Eve Maler, their feedback. Additionally, we would like to thank Eve Maler,
Nicolas Williams, Bob Morgan, Scott Cantor, Jim Fenton, Paul Leach, Nicolas Williams, Bob Morgan, Scott Cantor, Jim Fenton, Paul Leach,
and Luke Howard for their feedback on the federation terminology and Luke Howard for their feedback on the federation terminology
question. question.
Furthermore, we would like to thank Klaas Wierenga for his review of Furthermore, we would like to thank Klaas Wierenga for his review of
the pre-00 draft version. the pre-00 draft version.
10. References 9. References
10.1. Normative References 9.1. Normative References
[RFC2743] Linn, J., "Generic Security Service Application Program [RFC2743] Linn, J., "Generic Security Service Application Program
Interface Version 2, Update 1", RFC 2743, January 2000. Interface Version 2, Update 1", RFC 2743, January 2000.
[RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson, [RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson,
"Remote Authentication Dial In User Service (RADIUS)", "Remote Authentication Dial In User Service (RADIUS)",
RFC 2865, June 2000. RFC 2865, June 2000.
[RFC3588] Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J. [RFC3588] Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J.
Arkko, "Diameter Base Protocol", RFC 3588, September 2003. Arkko, "Diameter Base Protocol", RFC 3588, September 2003.
skipping to change at page 40, line 49 skipping to change at page 43, line 49
[I-D.ietf-abfab-aaa-saml] [I-D.ietf-abfab-aaa-saml]
Howlett, J. and S. Hartman, "A RADIUS Attribute, Binding Howlett, J. and S. Hartman, "A RADIUS Attribute, Binding
and Profiles for SAML", draft-ietf-abfab-aaa-saml-04 (work and Profiles for SAML", draft-ietf-abfab-aaa-saml-04 (work
in progress), October 2012. in progress), October 2012.
[RFC6677] Hartman, S., Clancy, T., and K. Hoeper, "Channel-Binding [RFC6677] Hartman, S., Clancy, T., and K. Hoeper, "Channel-Binding
Support for Extensible Authentication Protocol (EAP) Support for Extensible Authentication Protocol (EAP)
Methods", RFC 6677, July 2012. Methods", RFC 6677, July 2012.
10.2. Informative References 9.2. Informative References
[RFC2903] de Laat, C., Gross, G., Gommans, L., Vollbrecht, J., and [RFC2903] de Laat, C., Gross, G., Gommans, L., Vollbrecht, J., and
D. Spence, "Generic AAA Architecture", RFC 2903, D. Spence, "Generic AAA Architecture", RFC 2903,
August 2000. August 2000.
[I-D.nir-tls-eap] [I-D.nir-tls-eap]
Nir, Y., Sheffer, Y., Tschofenig, H., and P. Gutmann, "A Nir, Y., Sheffer, Y., Tschofenig, H., and P. Gutmann, "A
Flexible Authentication Framework for the Transport Layer Flexible Authentication Framework for the Transport Layer
Security (TLS) Protocol using the Extensible Security (TLS) Protocol using the Extensible
Authentication Protocol (EAP)", draft-nir-tls-eap-13 (work Authentication Protocol (EAP)", draft-nir-tls-eap-13 (work
skipping to change at page 41, line 24 skipping to change at page 44, line 24
Hardt, D., "The OAuth 2.0 Authorization Framework", Hardt, D., "The OAuth 2.0 Authorization Framework",
draft-ietf-oauth-v2-31 (work in progress), August 2012. draft-ietf-oauth-v2-31 (work in progress), August 2012.
[I-D.iab-privacy-considerations] [I-D.iab-privacy-considerations]
Cooper, A., Tschofenig, H., Aboba, B., Peterson, J., Cooper, A., Tschofenig, H., Aboba, B., Peterson, J.,
Morris, J., Hansen, M., and R. Smith, "Privacy Morris, J., Hansen, M., and R. Smith, "Privacy
Considerations for Internet Protocols", Considerations for Internet Protocols",
draft-iab-privacy-considerations-03 (work in progress), draft-iab-privacy-considerations-03 (work in progress),
July 2012. July 2012.
[I-D.perez-radext-radius-fragmentation]
Perez-Mendez, A., Lopez, R., Pereniguez-Garcia, F., Lopez-
Millan, G., Lopez, D., and A. DeKok, "Support of
fragmentation of RADIUS packets",
draft-perez-radext-radius-fragmentation-05 (work in
progress), February 2013.
[RFC4017] Stanley, D., Walker, J., and B. Aboba, "Extensible [RFC4017] Stanley, D., Walker, J., and B. Aboba, "Extensible
Authentication Protocol (EAP) Method Requirements for Authentication Protocol (EAP) Method Requirements for
Wireless LANs", RFC 4017, March 2005. Wireless LANs", RFC 4017, March 2005.
[RFC5106] Tschofenig, H., Kroeselberg, D., Pashalidis, A., Ohba, Y., [RFC5106] Tschofenig, H., Kroeselberg, D., Pashalidis, A., Ohba, Y.,
and F. Bersani, "The Extensible Authentication Protocol- and F. Bersani, "The Extensible Authentication Protocol-
Internet Key Exchange Protocol version 2 (EAP-IKEv2) Internet Key Exchange Protocol version 2 (EAP-IKEv2)
Method", RFC 5106, February 2008. Method", RFC 5106, February 2008.
[RFC1964] Linn, J., "The Kerberos Version 5 GSS-API Mechanism", [RFC1964] Linn, J., "The Kerberos Version 5 GSS-API Mechanism",
skipping to change at page 41, line 45 skipping to change at page 45, line 4
[RFC2203] Eisler, M., Chiu, A., and L. Ling, "RPCSEC_GSS Protocol [RFC2203] Eisler, M., Chiu, A., and L. Ling, "RPCSEC_GSS Protocol
Specification", RFC 2203, September 1997. Specification", RFC 2203, September 1997.
[RFC3645] Kwan, S., Garg, P., Gilroy, J., Esibov, L., Westhead, J., [RFC3645] Kwan, S., Garg, P., Gilroy, J., Esibov, L., Westhead, J.,
and R. Hall, "Generic Security Service Algorithm for and R. Hall, "Generic Security Service Algorithm for
Secret Key Transaction Authentication for DNS (GSS-TSIG)", Secret Key Transaction Authentication for DNS (GSS-TSIG)",
RFC 3645, October 2003. RFC 3645, October 2003.
[RFC2138] Rigney, C., Rigney, C., Rubens, A., Simpson, W., and S. [RFC2138] Rigney, C., Rigney, C., Rubens, A., Simpson, W., and S.
Willens, "Remote Authentication Dial In User Service Willens, "Remote Authentication Dial In User Service
(RADIUS)", RFC 2138, April 1997. (RADIUS)", RFC 2138, April 1997.
[RFC4462] Hutzelman, J., Salowey, J., Galbraith, J., and V. Welch, [RFC4462] Hutzelman, J., Salowey, J., Galbraith, J., and V. Welch,
"Generic Security Service Application Program Interface "Generic Security Service Application Program Interface
(GSS-API) Authentication and Key Exchange for the Secure (GSS-API) Authentication and Key Exchange for the Secure
Shell (SSH) Protocol", RFC 4462, May 2006. Shell (SSH) Protocol", RFC 4462, May 2006.
[RFC4422] Melnikov, A. and K. Zeilenga, "Simple Authentication and [RFC4422] Melnikov, A. and K. Zeilenga, "Simple Authentication and
Security Layer (SASL)", RFC 4422, June 2006. Security Layer (SASL)", RFC 4422, June 2006.
[RFC5056] Williams, N., "On the Use of Channel Bindings to Secure [RFC5056] Williams, N., "On the Use of Channel Bindings to Secure
Channels", RFC 5056, November 2007. Channels", RFC 5056, November 2007.
[RFC5080] Nelson, D. and A. DeKok, "Common Remote Authentication
Dial In User Service (RADIUS) Implementation Issues and
Suggested Fixes", RFC 5080, December 2007.
[RFC5705] Rescorla, E., "Keying Material Exporters for Transport
Layer Security (TLS)", RFC 5705, March 2010.
[RFC5801] Josefsson, S. and N. Williams, "Using Generic Security [RFC5801] Josefsson, S. and N. Williams, "Using Generic Security
Service Application Program Interface (GSS-API) Mechanisms Service Application Program Interface (GSS-API) Mechanisms
in Simple Authentication and Security Layer (SASL): The in Simple Authentication and Security Layer (SASL): The
GS2 Mechanism Family", RFC 5801, July 2010. GS2 Mechanism Family", RFC 5801, July 2010.
[RFC5849] Hammer-Lahav, E., "The OAuth 1.0 Protocol", RFC 5849, [RFC5849] Hammer-Lahav, E., "The OAuth 1.0 Protocol", RFC 5849,
April 2010. April 2010.
[RFC6614] Winter, S., McCauley, M., Venaas, S., and K. Wierenga,
"Transport Layer Security (TLS) Encryption for RADIUS",
RFC 6614, May 2012.
[OASIS.saml-core-2.0-os] [OASIS.saml-core-2.0-os]
Cantor, S., Kemp, J., Philpott, R., and E. Maler, Cantor, S., Kemp, J., Philpott, R., and E. Maler,
"Assertions and Protocol for the OASIS Security Assertion "Assertions and Protocol for the OASIS Security Assertion
Markup Language (SAML) V2.0", OASIS Standard saml-core- Markup Language (SAML) V2.0", OASIS Standard saml-core-
2.0-os, March 2005. 2.0-os, March 2005.
[RFC2904] Vollbrecht, J., Calhoun, P., Farrell, S., Gommans, L., [RFC2904] Vollbrecht, J., Calhoun, P., Farrell, S., Gommans, L.,
Gross, G., de Bruijn, B., de Laat, C., Holdrege, M., and Gross, G., de Bruijn, B., de Laat, C., Holdrege, M., and
D. Spence, "AAA Authorization Framework", RFC 2904, D. Spence, "AAA Authorization Framework", RFC 2904,
August 2000. August 2000.
[I-D.hartman-emu-mutual-crypto-bind] [I-D.ietf-emu-crypto-bind]
Hartman, S., Wasserman, M., and D. Zhang, "EAP Mutual Hartman, S., Wasserman, M., and D. Zhang, "EAP Mutual
Cryptographic Binding", Cryptographic Binding", draft-ietf-emu-crypto-bind-02
draft-hartman-emu-mutual-crypto-bind-00 (work in (work in progress), February 2013.
progress), March 2012.
[I-D.ietf-emu-eap-tunnel-method] [I-D.ietf-emu-eap-tunnel-method]
Zhou, H., Cam-Winget, N., Salowey, J., and S. Hanna, Zhou, H., Cam-Winget, N., Salowey, J., and S. Hanna,
"Tunnel EAP Method (TEAP) Version 1", "Tunnel EAP Method (TEAP) Version 1",
draft-ietf-emu-eap-tunnel-method-04 (work in progress), draft-ietf-emu-eap-tunnel-method-05 (work in progress),
October 2012. February 2013.
[I-D.ietf-radext-dtls]
DeKok, A., "DTLS as a Transport Layer for RADIUS",
draft-ietf-radext-dtls-03 (work in progress),
January 2013.
[WS-TRUST] [WS-TRUST]
Lawrence, K., Kaler, C., Nadalin, A., Goodner, M., Gudgin, Lawrence, K., Kaler, C., Nadalin, A., Goodner, M., Gudgin,
M., Barbir, A., and H. Granqvist, "WS-Trust 1.4", OASIS M., Barbir, A., and H. Granqvist, "WS-Trust 1.4", OASIS
Standard ws-trust-200902, February 2009, <http:// Standard ws-trust-200902, February 2009, <http://
docs.oasis-open.org/ws-sx/ws-trust/v1.4/ws-trust.html>. docs.oasis-open.org/ws-sx/ws-trust/v1.4/ws-trust.html>.
[NIST-SP.800-63]
Burr, W., Dodson, D., and W. Polk, "Electronic
Authentication Guideline", NIST Special
Publication 800-63, April 2006.
URIs URIs
[1] <http://www.openid.net> [1] <http://www.openid.net>
[2] <http://www.eduroam.org> [2] <http://www.eduroam.org>
Editorial Comments Editorial Comments
[anchor4] JLS: Should this be an EAP failure to the client as well? [anchor4] JLS: Should this be an EAP failure to the client as well?
 End of changes. 73 change blocks. 
226 lines changed or deleted 421 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/