< draft-ietf-abfab-arch-10.txt   draft-ietf-abfab-arch-11.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: July 4, 2014 Painless Security Expires: August 15, 2014 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
December 31, 2013 February 11, 2014
Application Bridging for Federated Access Beyond Web (ABFAB) Application Bridging for Federated Access Beyond Web (ABFAB)
Architecture Architecture
draft-ietf-abfab-arch-10.txt draft-ietf-abfab-arch-11.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 access and web-based access. focused on two use cases: network access and web-based access.
However, the solutions to these use cases that have been proposed and However, the solutions to these use cases that have been proposed and
deployed tend to have few common building blocks in common. deployed tend to have few 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) the Generic Security Service (GSS), the In User Service (RADIUS) the Generic Security Service Application
Extensible Authentication Protocol (EAP) and the Security Assertion Program Interface (GSS-API), the Extensible Authentication Protocol
Markup Language (SAML). The architecture addresses the problem of (EAP) and the Security Assertion Markup Language (SAML). The
federated access management to primarily non-web-based services, in a architecture addresses the problem of federated access management to
manner that will scale to large numbers of identity providers, primarily non-web-based services, in a manner that will scale to
relying parties, and federations. large numbers of identity providers, relying parties, and
federations.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
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 July 4, 2014. This Internet-Draft will expire on August 15, 2014.
Copyright Notice Copyright Notice
Copyright (c) 2013 IETF Trust and the persons identified as the Copyright (c) 2014 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
skipping to change at page 2, line 44 skipping to change at page 2, line 44
2.1. Relying Party to Identity Provider . . . . . . . . . . . 15 2.1. Relying Party to Identity Provider . . . . . . . . . . . 15
2.1.1. AAA, RADIUS and Diameter . . . . . . . . . . . . . . 16 2.1.1. AAA, RADIUS and Diameter . . . . . . . . . . . . . . 16
2.1.2. Discovery and Rules Determination . . . . . . . . . . 18 2.1.2. Discovery and Rules Determination . . . . . . . . . . 18
2.1.3. Routing and Technical Trust . . . . . . . . . . . . . 19 2.1.3. Routing and Technical Trust . . . . . . . . . . . . . 19
2.1.4. AAA Security . . . . . . . . . . . . . . . . . . . . 20 2.1.4. AAA Security . . . . . . . . . . . . . . . . . . . . 20
2.1.5. SAML Assertions . . . . . . . . . . . . . . . . . . . 21 2.1.5. SAML Assertions . . . . . . . . . . . . . . . . . . . 21
2.2. Client To Identity Provider . . . . . . . . . . . . . . . 23 2.2. Client To Identity Provider . . . . . . . . . . . . . . . 23
2.2.1. Extensible Authentication Protocol (EAP) . . . . . . 23 2.2.1. Extensible Authentication Protocol (EAP) . . . . . . 23
2.2.2. EAP Channel Binding . . . . . . . . . . . . . . . . . 25 2.2.2. EAP Channel Binding . . . . . . . . . . . . . . . . . 25
2.3. Client to Relying Party . . . . . . . . . . . . . . . . . 25 2.3. Client to Relying Party . . . . . . . . . . . . . . . . . 25
2.3.1. GSS-API . . . . . . . . . . . . . . . . . . . . . . . 25 2.3.1. GSS-API . . . . . . . . . . . . . . . . . . . . . . . 26
2.3.2. Protocol Transport . . . . . . . . . . . . . . . . . 27 2.3.2. Protocol Transport . . . . . . . . . . . . . . . . . 27
2.3.3. Reauthentication . . . . . . . . . . . . . . . . . . 27 2.3.3. Reauthentication . . . . . . . . . . . . . . . . . . 27
3. Application Security Services . . . . . . . . . . . . . . . . 28 3. Application Security Services . . . . . . . . . . . . . . . . 28
3.1. Authentication . . . . . . . . . . . . . . . . . . . . . 28 3.1. Authentication . . . . . . . . . . . . . . . . . . . . . 28
3.2. GSS-API Channel Binding . . . . . . . . . . . . . . . . . 29 3.2. GSS-API Channel Binding . . . . . . . . . . . . . . . . . 29
3.3. Host-Based Service Names . . . . . . . . . . . . . . . . 30 3.3. Host-Based Service Names . . . . . . . . . . . . . . . . 30
3.4. Additional GSS-API Services . . . . . . . . . . . . . . . 32 3.4. Additional GSS-API Services . . . . . . . . . . . . . . . 32
4. Privacy Considerations . . . . . . . . . . . . . . . . . . . 32 4. Privacy Considerations . . . . . . . . . . . . . . . . . . . 32
4.1. Entities and their roles . . . . . . . . . . . . . . . . 33 4.1. Entities and their roles . . . . . . . . . . . . . . . . 33
4.2. Privacy Aspects of ABFAB Communication Flows . . . . . . 34 4.2. Privacy Aspects of ABFAB Communication Flows . . . . . . 35
4.2.1. Client to RP . . . . . . . . . . . . . . . . . . . . 34 4.2.1. Client to RP . . . . . . . . . . . . . . . . . . . . 35
4.2.2. Client to IdP (via Federation Substrate) . . . . . . 35 4.2.2. Client to IdP (via Federation Substrate) . . . . . . 36
4.2.3. IdP to RP (via Federation Substrate) . . . . . . . . 36 4.2.3. IdP to RP (via Federation Substrate) . . . . . . . . 37
4.3. Relationship between User and Entities . . . . . . . . . 37 4.3. Relationship between User and Entities . . . . . . . . . 37
4.4. Accounting Information . . . . . . . . . . . . . . . . . 37 4.4. Accounting Information . . . . . . . . . . . . . . . . . 38
4.5. Collection and retention of data and identifiers . . . . 37 4.5. Collection and retention of data and identifiers . . . . 38
4.6. User Participation . . . . . . . . . . . . . . . . . . . 38 4.6. User Participation . . . . . . . . . . . . . . . . . . . 38
5. Security Considerations . . . . . . . . . . . . . . . . . . . 38 5. Security Considerations . . . . . . . . . . . . . . . . . . . 39
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 39 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 40
7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 39 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 40
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 40 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 40
8.1. Normative References . . . . . . . . . . . . . . . . . . 40 8.1. Normative References . . . . . . . . . . . . . . . . . . 40
8.2. Informative References . . . . . . . . . . . . . . . . . 41 8.2. Informative References . . . . . . . . . . . . . . . . . 41
8.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 43
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 43 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 43
1. Introduction 1. Introduction
The Internet uses numerous security mechanisms to manage access to Numerous security mechanisms have been deployed on the Internet to
various resources. These mechanisms have been generalized and scaled manage access to various resources. These mechanisms have been
over the last decade through mechanisms such as Simple Authentication generalized and scaled over the last decade through mechanisms such
and Security Layer (SASL) with the Generic Security Server as Simple Authentication and Security Layer (SASL) with the Generic
Application Program Interface (GSS-API) (known as the GS2 family) Security Server Application Program Interface (GSS-API) (known as the
[RFC5801], Security Assertion Markup Language (SAML) GS2 family) [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
Accounting (AAA) architecture as embodied in RADIUS [RFC2865] and Accounting (AAA) architecture as embodied in RADIUS [RFC2865] and
Diameter [RFC6733]. Diameter [RFC6733].
A Relying Party (RP) is the entity that manages access to some A Relying Party (RP) is the entity that manages access to some
resource. The entity that is requesting access to that resource is resource. The entity that is requesting access to that resource is
often described as the Client. Many security mechanisms are often described as the Client. Many security mechanisms are
manifested as an exchange of information between these entities. The manifested as an exchange of information between these entities. The
RP is therefore able to decide whether the Client is authorized, or RP is therefore able to decide whether the Client is authorized, or
not. not.
skipping to change at page 4, line 17 skipping to change at page 4, line 17
Single or Simplified sign-on: Single or Simplified sign-on:
An Internet service can delegate access management, and the An Internet service can delegate access management, and the
associated responsibilities such as identity management and associated responsibilities such as identity management and
credentialing, to an organization that already has a long-term credentialing, to an organization that already has a long-term
relationship with the Client. This is often attractive as Relying relationship with the Client. This is often attractive as Relying
Parties frequently do not want these responsibilities. The Client Parties frequently do not want these responsibilities. The Client
also requires fewer credentials, which is also desirable. also requires fewer credentials, which is also desirable.
Data Minimization and User Participation: Data Minimization and User Participation:
Often a Relying Party does not need to know the identity of a Often a Relying Party does not need to know the identity of a
Client to reach an access management decision. It is frequently Client to reach an access management decision. It is frequently
only necessary for the Relying Party to know specific attributes only necessary for the Relying Party to know specific attributes
about the client, for example, that the client is affiliated with about the client, for example, that the client is affiliated with
a particular organization or has a certain role or entitlement. a particular organization or has a certain role or entitlement.
Sometimes the RP only needs to know a pseudonym of the client. Sometimes the RP only needs to know a pseudonym of the client.
Prior to the release of attributes to the RP from the IdP, the IdP Prior to the release of attributes to the RP from the IdP, the IdP
will check configuration and policy to determine if the attributes will check configuration and policy to determine if the attributes
skipping to change at page 4, line 48 skipping to change at page 4, line 48
unsolicited. unsolicited.
This memo describes the Application Bridging for Federated Access This memo describes the Application Bridging for Federated Access
Beyond the Web (ABFAB) architecture. This architecture makes use of Beyond the Web (ABFAB) architecture. This architecture makes use of
extensions to the commonly used security mechanisms for both extensions to the commonly used security mechanisms for both
federated and non-federated access management, including RADIUS, the federated and non-federated access management, including RADIUS, the
Generic Security Service (GSS), the Extensible Authentication Generic Security Service (GSS), the Extensible Authentication
Protocol (EAP) and SAML. The architecture should be extended to use Protocol (EAP) and SAML. The architecture should be extended to use
Diameter in the future. The architecture addresses the problem of Diameter in the future. The architecture addresses the problem of
federated access management primarily for non-web-based services. It federated access management primarily for non-web-based services. It
does so in a manner that will scale to large numbers of identity does so in a manner that designed to scale to large numbers of
providers, relying parties, and federations. identity providers, relying parties, 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
[RFC6973]. In particular, this document uses the terms identity [RFC6973]. In particular, this document uses the terms identity
provider, relying party, identifier, pseudonymity, unlinkability, and provider, relying party, identifier, pseudonymity, unlinkability, and
anonymity. 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 server, and optionally a SAML Assertion service. EAP server, a RADIUS server, and optionally a SAML Assertion service.
This document uses the term Network Access Identifier (NAI), as This document uses the term Network Access Identifier (NAI), as
defined in [I-D.ietf-radext-nai]. An NAI consists of a realm defined in [I-D.ietf-radext-nai]. An NAI consists of a realm
identifier, which is associated with an IdP and a username which is identifier, which is associated with an IdP and a username which is
associated with a specific client of the IdP. associated with a specific client of the IdP.
One of the problems people will find with reading this document is One of the problems some people have found with reading this document
that the terminology sometimes appears to be inconsistent. This is is that the terminology sometimes appears to be inconsistent. This
due the fact that the terms used by the different standards we are is due the fact that the terms used by the different standards we are
referencing are not consistent. In general the document uses either referencing are not consistent with each other. In general the
the ABFAB term or the term associated with the standard under document uses either the ABFAB term or the term associated with the
discussion as appropriate. For reference we include this table which standard under discussion as appropriate. For reference we include
maps the different terms into a single table. this table which maps the different terms into a single table.
+----------+-----------+--------------------+-----------------------+ +----------+-----------+--------------------+-----------------------+
| Protocol | Client | Relying Party | Identity Provider | | Protocol | Client | 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 | | | | | Server | |
skipping to change at page 6, line 13 skipping to change at page 6, line 13
Table 1. Terminology Table 1. Terminology
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 name that represents the entity. there is no name that represents the entity.
1.1.1. Channel Binding 1.1.1. Channel Binding
This document uses the term channel binding with two different This document uses the term channel binding with two different
meanings. meanings.
EAP channel binding is used to provide GSS-API naming semantics. EAP EAP channel binding is used to implement GSS-API naming semantics.
channel binding sends a set of attributes from the peer to the EAP EAP channel binding sends a set of attributes from the peer to the
server either as part of the EAP conversation or as part of a secure EAP server either as part of the EAP conversation or as part of a
association protocol. In addition, attributes are sent in the secure association protocol. In addition, attributes are sent in the
backend protocol from the EAP authenticator to the EAP server. The backend protocol from the EAP authenticator to the EAP server. The
EAP server confirms the consistency of these attributes and provides EAP server confirms the consistency of these attributes and provides
the confirmation back to the peer. In this document, channel binding the confirmation back to the peer. In this document, channel binding
without qualification refers to EAP channel binding. without qualification refers to EAP channel binding.
GSS-API channel binding provides protection against man-in-the-middle GSS-API channel binding provides protection against man-in-the-middle
attacks when GSS-API is used for authentication inside of some attacks when GSS-API is used for authentication inside of some
tunnel; it is similar to a facility called cryptographic binding in tunnel; it is similar to a facility called cryptographic binding in
EAP. The binding works by each side deriving a cryptographic value EAP. The binding works by each side deriving a cryptographic value
from the tunnel itself and then using that cryptographic value to from the tunnel itself and then using that cryptographic value to
skipping to change at page 6, line 40 skipping to change at page 6, line 40
facilities. However, the difference can be summarized as GSS-API facilities. However, the difference can be summarized as GSS-API
channel binding says that there is nobody between the client and the channel binding says that there is nobody between the client and the
EAP authenticator while EAP channel binding allows the client to have EAP authenticator while EAP channel binding allows the client to have
knowledge about attributes of the EAP authenticator (such as its knowledge about attributes of the EAP authenticator (such as its
name). name).
Typically when considering both EAP and GSS-API channel binding, Typically when considering both EAP and GSS-API channel binding,
people think of channel binding in combination with mutual people think of channel binding in combination with mutual
authentication. This is sufficiently common that without additional authentication. This is sufficiently common that without additional
qualification channel binding should be assumed to imply mutual qualification channel binding should be assumed to imply mutual
authentication. In GSS-API, without mutualtion only the acceptor has authentication. In GSS-API, without mutual authentication only the
authenticated the initator. Similarly in EAP, only the EAP server acceptor has authenticated the initiator. Similarly in EAP, only the
has authenticated the peer. That's sometimes useful. Consider for EAP server has authenticated the peer. That's sometimes useful.
example a user who wishes to access a protected resource for a shared Consider for example a user who wishes to access a protected resource
whiteboard in a conference room. The whiteboard is the acceptor; it for a shared whiteboard in a conference room. The whiteboard is the
knows that the initiator is authorized to give it a presentation and acceptor; it knows that the initiator is authorized to give it a
the user can validate the whitebord got the correct presentation by presentation and the user can validate the whitebord got the correct
visual means. (The presention should not be confiduatal in this presentation by visual means. (The presention should not be
case.) If channel binding is used without mutual authentication, it confidential in this case.) If channel binding is used without
is effectively a request to disclose the resource in the context of a mutual authentication, it is effectively a request to disclose the
particular channel. Such an authentication would be similar in resource in the context of a particular channel. Such an
concept to a holder-of-key SAML assertion. However, also note that authentication would be similar in concept to a holder-of-key SAML
while it is not happening in the protocol, mutual authentication is assertion. However, also note that while it is not happening in the
happening in the overall system: the user is able to visually protocol, mutual authentication is happening in the overall system:
authenticate the content. This is consistent with all uses of the user is able to visually authenticate the content. This is
channel binding without protocol level mutual authentication found so consistent with all uses of channel binding without protocol level
far. 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 entities: In the previous section we introduced the following entities:
o the Client, o the Client,
o the Identity Provider, and o the Identity Provider, and
o the Relying Party. o the Relying Party.
The final entity that needs to be introduced is the Individual. An The final entity that needs to be introduced is the Individual. An
Individual is a human being that is using the Client. In any given Individual is a human being that is using the Client. In any given
situation, an Individual may or may not exist. Clients can act situation, an Individual may or may not exist. Clients can act
either as front ends for Individuals or they may be independent either as front ends for Individuals or they may be independent
entities that are setup and allowed to run autonomously. An example entities that are setup and allowed to run autonomously. An example
of such an entity can be found in the trust routing protocol where of such an entity can be found in the trust routing protocol [2]
the routers use ABFAB to authenticate to each other. where the routers use ABFAB to authenticate to each other.
These entities and their relationships are illustrated graphically in These entities and their relationships are illustrated graphically in
Figure 1. Figure 1.
,----------\ ,---------\ ,----------\ ,---------\
| Identity | Federation | Relying | | Identity | Federation | Relying |
| Provider + <-------------------> + Party | | Provider + <-------------------> + Party |
`----------' '---------' `----------' '---------'
< <
\ \
skipping to change at page 8, line 18 skipping to change at page 8, line 18
Federation. The relationship may be direct (they have an explicit Federation. The relationship may be direct (they have an explicit
trust relationship) or transitive (the trust relationship is trust relationship) or transitive (the trust relationship is
mediated by one or more entities). The federation relationship is mediated by one or more entities). The federation relationship is
governed by a federation agreement. Within a single federation, governed by a federation agreement. Within a single federation,
there may be multiple Identity Providers as well as multiple there may be multiple Identity Providers as well as multiple
Relying Parties. Relying Parties.
Authentication Authentication
There is a direct relationship between the Client and the Identity There is a direct relationship between the Client and the Identity
Provider by which the entities trust and can securely authenticate Provider. This relationship provides the means by which they
each other. trust each other and can securely authenticate each other.
A federation agreement typically encompasses operational A federation agreement typically encompasses operational
specifications and legal rules: specifications and legal rules:
Operational Specifications: Operational Specifications:
These include the technical specifications (e.g. protocols used to These include the technical specifications (e.g. protocols used to
communicate between the three parties), process standards, communicate between the three parties), process standards,
policies, identity proofing, credential and authentication policies, identity proofing, credential and authentication
algorithm requirements, performance requirements, assessment and algorithm requirements, performance requirements, assessment and
skipping to change at page 10, line 18 skipping to change at page 10, line 18
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
the Client may be autonomous. the Client may be autonomous.
1.3. Challenges for Contemporary Federation 1.3. Challenges for Contemporary Federation
As the number of federated services has proliferated, the role of the As the number of federated IdPs and RPs (services) proliferats, the
individual can become ambiguous in certain circumstances. For role of the individual can become ambiguous in certain circumstances.
example, a school might provide online access for a student's grades For example, a school might provide online access for a student's
to their parents for review, and to the student's teacher for grades to their parents for review, and to the student's teacher for
modification. A teacher who is also a parent must clearly modification. A teacher who is also a parent must clearly
distinguish her role upon access. distinguish her role upon access.
Similarly, as the number of federations proliferates, it becomes Similarly, as the number of federations proliferates, it becomes
increasingly difficult to discover which identity provider(s) a user increasingly difficult to discover which identity provider(s) a user
is associated with. This is true for both the web and non-web case, is associated with. This is true for both the web and non-web case,
but is particularly acute for the latter as many non-web but is particularly acute for the latter as many non-web
authentication systems are not semantically rich enough on their own authentication systems are not semantically rich enough on their own
to allow for such ambiguities. For instance, in the case of an email to allow for such ambiguities. For instance, in the case of an email
provider, the use of SMTP and IMAP protocols do not have the ability provider, the SMTP and IMAP protocols do not have the ability for the
for the server to get additional information, beyond the clients NAI, server to request information from the client, beyond the clients
in order to provide additional input to decide between multiple NAI, that the server would then use to decide between the multiple
federations it may be associated with. However, the building blocks federations it is associated with. However, the building blocks do
do exist to add this functionality. exist to add this functionality.
1.4. An Overview of ABFAB-based Federation 1.4. An Overview of ABFAB-based Federation
The previous section described the general model of federation, and The previous section described the general model of federation, and
the application of access management within the federation. This the application of access management within the federation. This
section provides a brief overview of ABFAB in the context of this section provides a brief overview of ABFAB in the context of this
model. model.
In this example, a client is attempting to connect to a server in In this example, a client is attempting to connect to a server in
order to either get access to some data or perform some type of order to either get access to some data or perform some type of
transaction. In order for the client to mutually authenticate with transaction. In order for the client to mutually authenticate with
the server, the following steps are taken in an ABFAB architecture: the server, the following steps are taken in an ABFAB architecture (a
graphical view of the steps can be found in figure Figure 2):
1. Client Configuration: The Client Application is configured with 1. Client Configuration: The Client Application is configured with
an NAI assigned by the IdP. It is also configured with any an NAI assigned by the IdP. It is also configured with any
keys, certificates, passwords or other secret and public keys, certificates, passwords or other secret and public
information needed to run the EAP protocols between it and the information needed to run the EAP protocols between it and the
IdP. IdP.
2. Authentication mechanism selection: The GSS-EAP GSS-API 2. Authentication mechanism selection: The Client Application is
mechanism is selected for authentication/authorization. configured to use the GSS-EAP GSS-API mechanism for
authentication/authorization.
3. Client provides an NAI to RP: The client application sets up a 3. Client provides an NAI to RP: The client application sets up a
transport to the RP and begins the GSS-EAP authentication. In transport to the RP and begins the GSS-EAP authentication. In
response, the RP sends an EAP request message (nested in the response, the RP sends an EAP request message (nested in the
GSS-EAP protocol) asking for the Client's name. The Client GSS-EAP protocol) asking for the Client's name. The Client
sends an EAP response with an NAI name form that, at a minimum, sends an EAP response with an NAI name form that, at a minimum,
contains the realm portion of its full NAI. contains the realm portion of its full NAI.
4. Discovery of federated IdP: The RP uses pre-configured 4. Discovery of federated IdP: The RP uses pre-configured
information or a federation proxy to determine what IdP to use information or a federation proxy to determine what IdP to use
skipping to change at page 12, line 18 skipping to change at page 12, line 18
cryptographic keys: a Master Session Key (MSK), and an Extended cryptographic keys: a Master Session Key (MSK), and an Extended
MSK (EMSK). At this point the client has a level of assurance MSK (EMSK). At this point the client has a level of assurance
about the identity of the RP based on the name checking the IdP about the identity of the RP based on the name checking the IdP
has done using the RP naming information from the AAA framework has done using the RP naming information from the AAA framework
and from the client (by the channel binding data). and from the client (by the channel binding data).
9. Local IdP Policy Check: At this stage, the IdP checks local 9. Local IdP Policy Check: At this stage, the IdP checks local
policy to determine whether the RP and client are authorized for policy to determine whether the RP and client are authorized for
a given transaction/service, and if so, what if any, attributes a given transaction/service, and if so, what if any, attributes
will be released to the RP. If the IdP gets a policy failure, will be released to the RP. If the IdP gets a policy failure,
it sends an EAP failure message to the RP. (The RP will have it sends an EAP failure message to the RP.[CREF1] (The RP will
done its policy checks during the discovery process.) have done its policy checks during the discovery process.)
10. IdP provides the RP with the MSK: The IdP sends a positive 10. IdP provides the RP with the MSK: The IdP sends a positive
result EAP to the RP, along with an optional set of AAA result EAP to the RP, along with an optional set of AAA
attributes associated with the client (usually as one or more attributes associated with the client (usually as one or more
SAML assertions). In addition, the EAP MSK is returned to the SAML assertions). In addition, the EAP MSK is returned to the
RP. RP.
11. RP Processes Results: When the RP receives the result from the 11. RP Processes Results: When the RP receives the result from the
IdP, it should have enough information to either grant or refuse IdP, it should have enough information to either grant or refuse
a resource access request. It may have information that a resource access request. It may have information that
skipping to change at page 12, line 41 skipping to change at page 13, line 5
If additional attributes are needed from the IdP the RP may make If additional attributes are needed from the IdP the RP may make
a new SAML Request to the IdP. It will apply these results in a new SAML Request to the IdP. It will apply these results in
an application-specific way. an application-specific way.
12. RP returns results to client: Once the RP has a response it must 12. RP returns results to client: Once the RP has a response it must
inform the client application of the result. If all has gone inform the client application of the result. If all has gone
well, all are authenticated, and the application proceeds with well, all are authenticated, and the application proceeds with
appropriate authorization levels. The client can now complete appropriate authorization levels. The client can now complete
the authentication of the RP by the use of the EAP MSK value. the authentication of the RP by the use of the EAP MSK value.
An example communication flow is given below:
Relying Client Identity Relying Client Identity
Party App Provider Party App Provider
| (1) | Client Configuration | (1) | Client Configuration
| | | | | |
|<-----(2)----->| | Mechanism Selection |<-----(2)----->| | Mechanism Selection
| | | | | |
|<-----(3)-----<| | NAI transmitted to RP |<-----(3)-----<| | NAI transmitted to RP
| | | | | |
|<=====(4)====================>| Discovery |<=====(4)====================>| Discovery
skipping to change at page 13, line 35 skipping to change at page 13, line 35
|<====(10)====================<| IdP Assertion to RP |<====(10)====================<| IdP Assertion to RP
| | | | | |
(11) | | RP processes results (11) | | RP processes results
| | | | | |
|>----(12)----->| | Results to client app. |>----(12)----->| | Results to client app.
----- = Between Client App and RP ----- = Between Client App and RP
===== = Between RP and IdP ===== = Between RP and IdP
- - - = Between Client App and IdP (via RP) - - - = Between Client App and IdP (via RP)
Figure 2: ABFAB Authentication Steps
1.5. Design Goals 1.5. Design Goals
Our key design goals are as follows: Our key design goals are as follows:
o Each party of a transaction will be authenticated, although o Each party in a transaction will be authenticated, although
perhaps not identified, and the client will be authorized for perhaps not identified, and the client will be authorized for
access to a specific resource. access to a specific resource.
o Means of authentication is decoupled so as to allow for multiple o Means of authentication is decoupled from the application protocol
authentication methods. so as to allow for multiple authentication methods with minimal
changes to the application.
o The architecture requires no sharing of long term private keys o The architecture requires no sharing of long term private keys
between clients and servers. between clients and RPs.
o The system will scale to large numbers of identity providers, o The system will scale to large numbers of identity providers,
relying parties, and users. relying parties, and users.
o The system will be designed primarily for non-Web-based o The system will be designed primarily for non-Web-based
authentication. authentication.
o The system will build upon existing standards, components, and o The system will build upon existing standards, components, and
operational practices. operational practices.
Designing new three party authentication and authorization protocols Designing new three party authentication and authorization protocols
is hard and fraught with risk of cryptographic flaws. Achieving is hard and fraught with risk of cryptographic flaws. Achieving
widespread deployment is even more difficult. A lot of attention on widespread deployment is even more difficult. A lot of attention on
federated access has been devoted to the Web. This document instead federated access has been devoted to the Web. This document instead
focuses on a non-Web-based environment and focuses on those protocols focuses on a non-Web-based environment and focuses on those protocols
where HTTP is not used. Despite the increased excitement for where HTTP is not used. Despite the growing trend to layer every
layering every protocol on top of HTTP there are still a number of protocol on top of HTTP there are still a number of protocols
protocols available that do not use HTTP-based transports. Many of available that do not use HTTP-based transports. Many of these
these protocols are lacking a native authentication and authorization protocols are lacking a native authentication and authorization
framework of the style shown in Figure 1. framework of the style shown in Figure 1.
2. Architecture 2. Architecture
We have already introduced the federated access architecture, with We have already introduced the federated access architecture, with
the illustration of the different actors that need to interact, but the illustration of the different actors that need to interact, but
did not expand on the specifics of providing support for non-Web did not expand on the specifics of providing support for non-Web
based applications. This section details this aspect and motivates based applications. This section details this aspect and motivates
design decisions. The main theme of the work described in this design decisions. The main theme of the work described in this
document is focused on re-using existing building blocks that have document is focused on re-using existing building blocks that have
been deployed already and to re-arrange them in a novel way. been deployed already and to re-arrange them in a novel way.
Although this architecture assumes updates to the relying party, the Although this architecture assumes updates to the relying party, the
client application, and the Identity Provider, those changes are kept client application, and the IdP, those changes are kept at a minimum.
at a minimum. A mechanism that can demonstrate deployment benefits A mechanism that can demonstrate deployment benefits (based on ease
(based on ease of update of existing software, low implementation of update of existing software, low implementation effort, etc.) is
effort, etc.) is preferred and there may be a need to specify preferred and there may be a need to specify multiple mechanisms to
multiple mechanisms to support the range of different deployment 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 to encapsulate 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, GSS-API was chosen. The technical
description of the technical specification can be found in specification of GSS-EAP can be found in [RFC7055].
[I-D.ietf-abfab-gss-eap].
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 3. 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) |
+-^----------^-+ +-^----------^-+
* EAP o RADIUS * EAP o RADIUS
* o * o
skipping to change at page 15, line 40 skipping to change at page 15, line 42
| |<================>| | | |<================>| |
+-------------+ +---------------+ +-------------+ +---------------+
Legend: Legend:
<****>: Client-to-IdP Exchange <****>: Client-to-IdP Exchange
<---->: Client-to-RP Exchange <---->: Client-to-RP Exchange
<oooo>: RP-to-IdP Exchange <oooo>: RP-to-IdP Exchange
<====>: Protocol through which GSS-API/GS2 exchanges are tunneled <====>: Protocol through which GSS-API/GS2 exchanges are tunneled
Figure 2: ABFAB Protocol Instantiation Figure 3: ABFAB Protocol Instantiation
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.
skipping to change at page 16, line 37 skipping to change at page 16, line 39
o The use of EAP channel binding [RFC6677] along with the core ABFAB o The use of EAP channel binding [RFC6677] along with the core ABFAB
protocol provide the pieces necessary to establish the identities protocol provide the pieces necessary to establish the identities
of the RP and the client, while EAP provides the cryptographic of the RP and the client, while EAP provides the cryptographic
methods for the RP and the client to validate they are talking to methods for the RP and the client to validate they are talking to
each other. each other.
o A method exists for carrying SAML packets within RADIUS o A method exists for carrying SAML packets within RADIUS
[I-D.ietf-abfab-aaa-saml] which allows the RP to query attributes [I-D.ietf-abfab-aaa-saml] which allows the RP to query attributes
about the client from the IdP. about the client from the IdP.
Future protocols that support the same framework but do different Protocols that support the same framework, but do different routing
routing may be used in the future. One such effort is to setup a are expected to be defined and used the future. One such effort call
framework that creates a trusted point-to-point channel on the fly. the Trust Router is to setup a framework that creates a trusted
point-to-point channel on the fly [3].
2.1.1. AAA, RADIUS and Diameter 2.1.1. AAA, RADIUS and Diameter
Interestingly, for network access authentication the usage of the AAA The usage of the AAA framework with RADIUS [RFC2865] and Diameter
framework with RADIUS [RFC2865] and Diameter [RFC6733] was quite [RFC6733] for network access authentication has been successful from
successful from a deployment point of view. To map to the a deployment point of view. To map to the terminology used in
terminology used in Figure 1 to the AAA framework the IdP corresponds Figure 1 to the AAA framework the IdP corresponds to the AAA server,
to the AAA server, the RP corresponds to the AAA client, and the the RP corresponds to the AAA client, and the technical building
technical building blocks of a federation are AAA proxies, relays and blocks of a federation are AAA proxies, relays and redirect agents
redirect agents (particularly if they are operated by third parties, (particularly if they are operated by third parties, such as AAA
such as AAA brokers and clearing houses). The front-end, i.e. the brokers and clearing houses). The front-end, i.e. the end host to
end host to AAA client communication, is in case of network access AAA client communication, is in case of network access authentication
authentication offered by link layer protocols that forward offered by link layer protocols that forward authentication protocol
authentication protocol exchanges back-and-forth. An example of a exchanges back-and-forth. An example of a large scale RADIUS-based
large scale RADIUS-based federation is EDUROAM [2]. federation is EDUROAM [4].
By using the AAA framework, ABFAB gets a lot of mileage as many of By using the AAA framework, ABFAB can be built on the federation
the federation agreements already exist and merely need to be agreements already exist, the agreements can then merely be expanded
expanded to cover the ABFAB additions. The AAA framework has already to cover the ABFAB. The AAA framework has already addressed some of
addressed some of the problems outlined above. For example, the problems outlined above. For example,
o It already has a method for routing requests based on a domain. o It already has a method for routing requests based on a domain.
o It already has an extensible architecture allowing for new o It already has an extensible architecture allowing for new
attributes to be defined and transported. attributes to be defined and transported.
o Pre-existing relationships can be re-used. o Pre-existing relationships can be re-used.
The astute reader will notice that RADIUS and Diameter have The astute reader will notice that RADIUS and Diameter have
substantially similar characteristics. Why not pick one? RADIUS and substantially similar characteristics. Why not pick one? RADIUS and
Diameter are deployed in different environments. RADIUS can often be Diameter are deployed in different environments. RADIUS can often be
found in enterprise and university networks, and is also in use by found in enterprise and university networks, and is also in use by
fixed network operators. Diameter, on the other hand, is deployed by fixed network operators. Diameter, on the other hand, is deployed by
mobile operators. Another key difference is that today RADIUS is mobile operators. Another key difference is that today RADIUS is
largely transported upon UDP. We leave as a deployment decision, largely transported upon UDP. We leave as a deployment decision,
which protocol will be appropriate. The protocol defines all the which protocol will be appropriate. The protocol defines all the
necessary new AAA attributes as RADIUS attributes. A future document necessary new AAA attributes as RADIUS attributes. A future document
would define the same AAA attributes for a Diameter environment. We could define the same AAA attributes for a Diameter environment. We
also note that there exist proxies which convert from RADIUS to also note that there exist proxies which convert from RADIUS to
Diameter and back. This makes it possible for both to be deployed in Diameter and back. This makes it possible for both to be deployed in
a single federation substrate. a single federation substrate.
Through the integrity protection mechanisms in the AAA framework, the Through the integrity protection mechanisms in the AAA framework, the
identity provider can establish technical trust that messages are identity provider can establish technical trust that messages are
being sent by the appropriate relying party. Any given interaction being sent by the appropriate relying party. Any given interaction
will be associated with one federation at the policy level. The will be associated with one federation at the policy level. The
legal or business relationship defines what statements the identity legal or business relationship defines what statements the identity
provider is trusted to make and how these statements are interpreted provider is trusted to make and how these statements are interpreted
skipping to change at page 18, line 27 skipping to change at page 18, line 30
RP may have multiple federation substrates to select from. The RP RP may have multiple federation substrates to select from. The RP
has a number of criteria that it will use in selecting which of the has a number of criteria that it will use in selecting which of the
different federations to use: different federations to use:
o The federation selected must be able to communicate with the IdP. o The federation selected must be able to communicate with the IdP.
o The federation selected must match the business rules and o The federation selected must match the business rules and
technical policies required for the RP security requirements. technical policies required for the RP security requirements.
The RP needs to discover which federation will be used to contact the The RP needs to discover which federation will be used to contact the
IdP. The first selection criteria used during discovery is going to IdP. The first selection criterion used during discovery is going to
be the name of the IdP to be contacted. The second selection be the name of the IdP to be contacted. The second selection
criteria used during discovery is going to be the set of business criteria used during discovery is going to be the set of business
rules and technical policies governing the relationship; this is rules and technical policies governing the relationship; this is
called rules determination. The RP also needs to establish technical called rules determination. The RP also needs to establish technical
trust in the communications with the IdP. trust in the communications with the IdP.
Rules determination covers a broad range of decisions about the Rules determination covers a broad range of decisions about the
exchange. One of these is whether the given RP is permitted to talk exchange. One of these is whether the given RP is permitted to talk
to the IdP using a given federation at all, so rules determination to the IdP using a given federation at all, so rules determination
encompasses the basic authorization decision. Other factors are encompasses the basic authorization decision. Other factors are
skipping to change at page 20, line 41 skipping to change at page 20, line 44
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. AAA Security 2.1.4. AAA Security
For the AAA framework there are two different places where 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 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 the links in the AAA backbone being used. The second are the nodes
that the backbone consists of. that form the AAA backbone.
The default link security for RADIUS is showing its age as it uses The default link security for RADIUS is showing its age as it uses
MD5 and a shared secret to both obfuscate passwords and to provide MD5 and a shared secret to both obfuscate passwords and to provide
integrity on the RADIUS messages. While some EAP methods have integrity on the RADIUS messages. While some EAP methods include the
designed in the ability to protect the client authentication ability to protect the client authentication credentials, the MSK
credentials, the MSK returned from the IDP to the RP is protected returned from the IDP to the RP is protected only by the RADIUS
only by the RADIUS security. In many environments this is considered security. In many environments this is considered to be
to be insufficient, especially as not all attributes are obfuscated insufficient, especially as not all attributes are obfuscated and can
and can thus leak information to a passive eavesdropper. The use of thus leak information to a passive eavesdropper. The use of RADIUS
RADIUS with TLS [RFC6614] and/or DTLS [I-D.ietf-radext-dtls] with TLS [RFC6614] and/or DTLS [I-D.ietf-radext-dtls] addresses these
addresses these attacks. The same level of security is included in attacks. The same level of security is included in the base Diameter
the base Diameter specifications. specifications.
2.1.5. SAML Assertions 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.
skipping to change at page 22, line 5 skipping to change at page 22, line 7
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.
Attributes placed in SAML assertions can have different namespaces Attributes in a SAML assertion are identified by a name string. The
assigned to the same name. In many, but not all, cases the name string is either assigned by the SAML issuer context or is
federation agreements will determine what attributes can be used in a scoped by a namespace (for example a URI or object identifier (OID)).
SAML statement. This means that the RP needs to map from the This means that the same attribute can have different name strings
federation names, types and semantics into the ones that the policies used to identify it. In many, but not all, cases the federation
of the RP are written in. In other cases the federation substrate agreements will determine what attributes and names can be used in a
may modify the SAML assertions in transit to do the necessary SAML statement. This means that the RP needs to map from the SAML
namespace, naming and semantic mappings as the assertion crosses the issuer or federation name, type and semantic into the name, type and
different boundaries in the federation. If the proxies are modifying semantics that the policies of the RP are written in. In other cases
the SAML Assertion, then they will obviously remove any signatures as the federation substrate, in the form of proxies, will modify the
they would no longer validate. In this case the technical trust is SAML assertions in transit to do the necessary name, type and value
the required mechanism for validating the integrity of the assertion. mappings as the assertion crosses boundaries in the federation. If
the proxies are modifying the SAML Assertion, then they will remove
any signatures on the SAML as changing the content of the SAML
statement would invalidate the signature. In this case the technical
trust is the required mechanism for validating the integrity of the
assertion. (The proxy could re-sign the SAML assertion, but the same
issues of establishing trust in the proxy would still exist.)
Finally, the attributes may still be in the namespace of the Finally, the attributes may still be in the namespace of the
originating IdP. When this occurs the RP will need to get the originating IdP. When this occurs the RP will need to get the
required mapping operations from the federation agreements and do the required mapping operations from the federation agreements and do the
appropriate mappings itself. appropriate mappings itself.
The RADIUS SAML RFC [I-D.ietf-abfab-aaa-saml] has defined a new SAML The RADIUS SAML RFC [I-D.ietf-abfab-aaa-saml] has defined a new SAML
name format that corresponds to the NAI name form defined by RFC XXXX name format that corresponds to the NAI name form defined by RFC XXXX
[I-D.ietf-radext-nai]. This allows for easy name matching in many [I-D.ietf-radext-nai]. This allows for easy name matching in many
cases as the name form in the SAML statement and the name form used cases as the name form in the SAML statement and the name form used
in RADIUS or Diameter will be the same. In addition to the NAI name in RADIUS or Diameter will be the same. In addition to the NAI name
skipping to change at page 23, line 32 skipping to change at page 23, line 42
channel binding mechanism has been defined in RFC 6677 [RFC6677] that channel binding mechanism has been defined in RFC 6677 [RFC6677] that
allows the IdP to check the identity of the RP provided by the AAA allows the IdP to check the identity of the RP provided by the AAA
framework with that provided by the client. framework with that provided by the client.
2.2.1. Extensible Authentication Protocol (EAP) 2.2.1. Extensible Authentication Protocol (EAP)
Traditional web federation does not describe how a client interacts Traditional web federation does not describe how a client interacts
with an identity provider for authentication. As a result, this with an identity provider for authentication. As a result, this
communication is not standardized. There are several disadvantages communication is not standardized. There are several disadvantages
to this approach. Since the communication is not standardized, it is to this approach. Since the communication is not standardized, it is
difficult for machines to correctly enter their credentials with difficult for machines to recognize which entity is going to do the
different authentications, where Individuals can correctly identify authentication and thus which credentials to use and where in the
the entire mechanism on the fly. The use of browsers for authentication form that the credentials are to be entered. Humans
authentication restricts the deployment of more secure forms of have a much easier time to correctly deal with these problems. The
authentication beyond plaintext username and password known by the use of browsers for authentication restricts the deployment of more
server. In a number of cases the authentication interface may be secure forms of authentication beyond plaintext username and password
presented before the client has adequately validated they are talking known by the server. In a number of cases the authentication
to the intended server. By giving control of the authentication interface may be presented before the client has adequately validated
interface to a potential attacker, the security of the system may be they are talking to the intended server. By giving control of the
reduced and phishing opportunities introduced. authentication interface to a potential attacker, the security of the
system may be reduced and phishing opportunities introduced.
As a result, it is desirable to choose some standardized approach for As a result, it is desirable to choose some standardized approach for
communication between the client's end-host and the identity communication between the client's end-host and the identity
provider. There are a number of requirements this approach must provider. There are a number of requirements this approach must
meet. meet.
Experience has taught us one key security and scalability Experience has taught us one key security and scalability
requirement: it is important that the relying party not get requirement: it is important that the relying party not get
possession of the long-term secret of the client. Aside from a possession of the long-term secret of the client. Aside from a
valuable secret being exposed, a synchronization problem can develop valuable secret being exposed, a synchronization problem can develop
skipping to change at page 24, line 17 skipping to change at page 24, line 26
Since there is no single authentication mechanism that will be used Since there is no single authentication mechanism that will be used
everywhere there is another associated requirement: The everywhere there is another associated requirement: The
authentication framework must allow for the flexible integration of authentication framework must allow for the flexible integration of
authentication mechanisms. For instance, some IdPs require hardware authentication mechanisms. For instance, some IdPs require hardware
tokens while others use passwords. A service provider wants to tokens while others use passwords. A service provider wants to
provide support for both authentication methods, and other methods provide support for both authentication methods, and other methods
from IdPs not yet seen. from IdPs not yet seen.
These requirements can be met by utilizing standardized and These requirements can be met by utilizing standardized and
successfully deployed technology, namely by the Extensible successfully deployed technology, namely by the Extensible
Authentication Protocol (EAP) framework [RFC3748]. Figure 2 Authentication Protocol (EAP) framework [RFC3748]. Figure 3
illustrates the integration graphically. illustrates the integration graphically.
EAP is an end-to-end framework; it provides for two-way communication EAP is an end-to-end framework; it provides for two-way communication
between a peer (i.e. client or individual) through the EAP between a peer (i.e. client or individual) through the EAP
authenticator (i.e., relying party) to the back-end (i.e., identity authenticator (i.e., relying party) to the back-end (i.e., identity
provider). Conveniently, this is precisely the communication path provider). Conveniently, this is precisely the communication path
that is needed for federated identity. Although EAP support is that is needed for federated identity. Although EAP support is
already integrated in AAA systems (see [RFC3579] and [RFC4072]) already integrated in AAA systems (see [RFC3579] and [RFC4072])
several challenges remain: several challenges remain:
skipping to change at page 27, line 21 skipping to change at page 27, line 31
The transport of data between the client and the relying party is not The transport of data between the client and the relying party is not
provided by GSS-API. GSS-API creates and consumes messages, but it provided by GSS-API. GSS-API creates and consumes messages, but it
does not provide the transport itself, instead the protocol using does not provide the transport itself, instead the protocol using
GSS-API needs to provide the transport. In many cases HTTP or HTTPS GSS-API needs to provide the transport. In many cases HTTP or HTTPS
is used for this transport, but other transports are perfectly is used for this transport, but other transports are perfectly
acceptable. The core GSS-API document [RFC2743] provides some acceptable. The core GSS-API document [RFC2743] provides some
details on what requirements exist. details on what requirements exist.
In addition we highlight the following: In addition we highlight the following:
o The transport does not need to provide either privacy or o The transport does not need to provide either confidentiality or
integrity. After GSS-EAP has finished negotiation, GSS-API can be integrity. After GSS-EAP has finished negotiation, GSS-API can be
used to provide both services. If the negotiation process itself used to provide both services. If the negotiation process itself
needs protection from eavesdroppers then the transport would need needs protection from eavesdroppers then the transport would need
to provide the necessary services. to provide the necessary services.
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 2.3.3. Reauthentication
There are circumstances where the server will want to have the client There are circumstances where the RP will want to have the client
reauthenticate itself. These include very long sessions, where the reauthenticate itself. These include very long sessions, where the
original authentication is time limited or cases where in order to original authentication is time limited or cases where in order to
complete an operation a different authentication is required. GSS- complete an operation a different authentication is required. GSS-
EAP does not have any mechanism for the server to initiate a EAP does not have any mechanism for the server to initiate a
reauthentication as all authentication operations start from the reauthentication as all authentication operations start from the
client. If a protocol using GSS-EAP needs to support client. If a protocol using GSS-EAP needs to support
reauthentication that is initiated by the server, then a request from reauthentication that is initiated by the server, then a request from
the server to the client for the reauthentiction to start needs to be the server to the client for the reauthentiction to start needs to be
placed in the protocol. placed in the protocol.
skipping to change at page 28, line 31 skipping to change at page 28, line 41
GSS-API provides an optional security service called mutual GSS-API provides an optional security service called mutual
authentication. This service means that in addition to the initiator authentication. This service means that in addition to the initiator
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
as: mutual authentication as:
o If a target name is configured for the initiator, then the o If a target name is configured for the initiator, then the
initiator trusts that the supplied target name describes the initiator trusts that the supplied target name describes the
acceptor. This implies both that appropriate cryptographic acceptor. This implies both that appropriate cryptographic
exchanges took place for the initiator to make such a trust exchanges took place for the initiator to make such a trust
decision, and that after evaluating the results of these decision, and that after evaluating the results of these
exchanges, the initiator's policy trusts that the target name is exchanges, the initiator's policy trusts that the target name is
accurate. accurate.
o If no target name is configured for the initiator, then the o If no target name is configured for the initiator, then the
skipping to change at page 29, line 29 skipping to change at page 29, line 41
authentication, however the client will always be able to detect this authentication, however the client will always be able to detect this
and make an appropriate security decision. and make an appropriate security decision.
The AAA infrastructure may hide the initiator's identity from the The AAA infrastructure may hide the initiator's identity from the
GSS-API acceptor, providing anonymity between the initiator and the GSS-API acceptor, providing anonymity between the initiator and the
acceptor. At this time, whether the identity is disclosed is acceptor. At this time, whether the identity is disclosed is
determined by EAP server policy rather than by an indication from the determined by EAP server policy rather than by an indication from the
initiator. Also, initiators are unlikely to be able to determine initiator. Also, initiators are unlikely to be able to determine
whether anonymous communication will be provided. For this reason, whether anonymous communication will be provided. For this reason,
initiators are unlikely to set the anonymous return flag from initiators are unlikely to set the anonymous return flag from
GSS_Init_Sec_context. GSS_Init_Sec_context (Section 4.2.1 in [RFC4178].
3.2. GSS-API Channel Binding 3.2. GSS-API Channel Binding
[RFC5056] defines a concept of channel binding which is used prevent [RFC5056] defines a concept of channel binding which is used prevent
man-in-the-middle attacks. The channel binding works by taking a man-in-the-middle attacks. The channel binding works by taking a
cryptographic value from the transport security and checks that both cryptographic value from the transport security and checks that both
sides of the GSS-API conversation know this value. Transport Layer sides of the GSS-API conversation know this value. Transport Layer
Security (TLS) is the most common transport security layer used for Security (TLS) [RFC5246] is the most common transport security layer
this purpose. used for this purpose.
It needs to be stressed that RFC 5056 channel binding (also called It needs to be stressed that RFC 5056 channel binding (also called
GSS-API channel binding when GSS-API is involved) is not the same GSS-API channel binding when GSS-API is involved) is not the same
thing as EAP channel binding. GSS-API channel binding is used for thing as EAP channel binding. GSS-API channel binding is used for
detecting Man-In-The-Middle attacks. EAP channel binding is used for detecting Man-In-The-Middle attacks. EAP channel binding is used for
mutual authentication and acceptor naming checks. Details are mutual authentication and acceptor naming checks. Details are
discussed in the mechanisms specification [I-D.ietf-abfab-gss-eap]. discussed in the mechanisms specification [RFC7055]. A fuller
A fuller description of the differences between the facilities can be description of the differences between the facilities can be found in
found in RFC 5056 [RFC5056]. RFC 5056 [RFC5056].
The use of TLS can provide both encryption and integrity on the 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 channel. It is common to provide SASL and GSS-API with these other
security services. security services.
One of the benefits that the use of TLS provides, is that client has One of the benefits that the use of TLS provides, is that client has
the ability to validate the name of the server. However this the ability to validate the name of the server. However this
validation is predicated on a couple of things. The TLS sessions validation is predicated on a couple of things. The TLS sessions
needs to be using certificates and not be an anonymous session. The needs to be using certificates and not be an anonymous session. The
client and the TLS server need to share a common trust point for the client and the TLS server need to share a common trust point for the
skipping to change at page 31, line 36 skipping to change at page 31, line 49
application to determine how much of the information identifying the application to determine how much of the information identifying the
service needs to be validated by the ABFAB system. The information service needs to be validated by the ABFAB system. The information
that needs to be validated is used to build up the service name that needs to be validated is used to build up the service name
passed into the GSS-EAP mechanism. What information is to be passed into the GSS-EAP mechanism. What information is to be
validated will depend on both what information was provided by the validated will depend on both what information was provided by the
client, and what information is considered significant. If the client, and what information is considered significant. If the
client only cares about getting a specific service, then the host and client only cares about getting a specific service, then the host and
realm that provides the service does not need to be validated. realm that provides the service does not need to be validated.
Applications may retrieve information about providers of services Applications may retrieve information about providers of services
from DNS. Service Records (SRV) and Naming Authority Pointer (NAPTR) from DNS. Service Records (SRV) [RFC2782] and Naming Authority
records are used to help find a host that provides a service; however Pointer (NAPTR) [RFC2915] records are used to help find a host that
the necessity of having DNSSEC on the queries depends on how the provides a service; however the necessity of having DNSSEC on the
information is going to be used. If the host name returned is not queries depends on how the information is going to be used. If the
going to be validated by EAP channel binding, because only the host name returned is not going to be validated by EAP channel
service is being validated, then DNSSEC is not required. However, if binding, because only the service is being validated, then DNSSEC
the host name is going to be validated by EAP channel binding then [RFC4033] is not required. However, if the host name is going to be
DNSSEC needs to be use to ensure that the correct host name is validated by EAP channel binding then DNSSEC needs to be use to
validated. In general, if the information that is returned from the ensure that the correct host name is validated. In general, if the
DNS query is to be validated, then it needs to be obtained in a information that is returned from the DNS query is to be validated,
secure manner. then it needs to be obtained in a secure manner.
Another issue that needs to be addressed for host-based service names Another issue that needs to be addressed for host-based service names
is that they do not work ideally when different instances of a is that they do not work ideally when different instances of a
service are running on different ports. If the services are service are running on different ports. If the services are
equivalent, then it does not matter. However if there are equivalent, then it does not matter. However if there are
substantial differences in the quality of the service that substantial differences in the quality of the service that
information needs to be part of the validation process. If one has information needs to be part of the validation process. If one has
just a host name and not a port in the information being validated, just a host name and not a port in the information being validated,
then this is not going to be a successful strategy. then this is not going to be a successful strategy.
skipping to change at page 33, line 21 skipping to change at page 33, line 33
+---------------+ +--------------+ +---------------+ +--------------+
| SAML Server | | AAA Proxy(s) | | SAML Server | | AAA Proxy(s) |
+---------------+ +--------------+ +---------------+ +--------------+
^ ^ ^ ^
| | | |
v v v v
+------------+ +---------------+ +--------------+ +------------+ +---------------+ +--------------+
| EAP Server | <---> | IdP | <---> | AAA Server | | EAP Server | <---> | IdP | <---> | AAA Server |
+------------+ +---------------+ +--------------+ +------------+ +---------------+ +--------------+
Figure 3: Entities and Data Flow Figure 4: Entities and Data Flow
4.1. Entities and their roles 4.1. Entities and their roles
Categorizing the ABFAB entities shown in the Figure 3 according to Categorizing the ABFAB entities shown in the Figure 4 according to
the taxonomy of terms from [RFC6973] the entities shown in Figure 3 the taxonomy of terms from [RFC6973] the entities shown in Figure 4
is somewhat complicated as during the various phases of ABFAB is somewhat complicated as during the various phases of ABFAB
communications the roles of each entity changes. The three main communications the roles of each entity changes. The three main
phases of relevance are the Client to RP communication phase, the phases of relevance are the Client to RP communication phase, the
Client to IdP (via the Federation Substrate) phase, and the IdP to RP Client to IdP (via the Federation Substrate) phase, and the IdP to RP
(via the Federation Substrate) phase. (via the Federation Substrate) phase.
In the Client to RP communication phase, we have: In the Client to RP communication phase, we have:
Initiator: Client. Initiator: Client.
skipping to change at page 34, line 11 skipping to change at page 34, line 23
In the IdP to Relying party (via the Federation Substrate) In the IdP to Relying party (via the Federation Substrate)
communication phase, we have: communication phase, we have:
Initiator: RP. Initiator: RP.
Observers: IdP, AAA Server, AAA Proxy(s), AAA Client, RP. Observers: IdP, AAA Server, AAA Proxy(s), AAA Client, RP.
Recipient: IdP Recipient: IdP
Eavesdroppers and Attackers can reside on any communication link Eavesdroppers and Attackers can reside on any or all communication
between entities in Figure 3. links between entities in Figure 4.
The various entities in the system might also collude or be coerced
into colluding. Some of the significant collusions to look at are:
o If two RPs are colluding, they have the information available to
both nodes. This can be analyzed as if a single RP was offering
multiple services.
o If an RP and a AAA proxy are colluding, then the trust of the
system is broken as the RP would be able to lie about its own
identity to the IdP. There is no known way to deal with this
situation.
o If multiple AAA proxies are colluding, it can be treated as a
single node for analysis.
The Federation Substrate consists of all of the AAA entities. In The Federation Substrate consists of all of the AAA entities. In
some cases the AAA Proxies entities may not exist as the AAA Client some cases the AAA Proxies entities may not exist as the AAA Client
can talk directly to the AAA Server. Specifications such as the can talk directly to the AAA Server. Specifications such as the
Trust Router Protocol and RADIUS dynamic discovery Trust Router Protocol and RADIUS dynamic discovery
[I-D.ietf-radext-dynamic-discovery] can be used to shorten the path [I-D.ietf-radext-dynamic-discovery] can be used to shorten the path
between the AAA client and the AAA server (and thus stop these AAA between the AAA client and the AAA server (and thus stop these AAA
Proxies from being Observers); however even in these circumstances Proxies from being Observers); however even in these circumstances
there may be AAA Proxies in the path. there may be AAA Proxies in the path.
In Figure 3 the IdP has been divided into multiple logical pieces, in In Figure 4 the IdP has been divided into multiple logical pieces, in
actual implementations these pieces will frequently be tightly actual implementations these pieces will frequently be tightly
coupled. The links between these pieces provide the greatest coupled. The links between these pieces provide the greatest
opportunity for attackers and eavesdroppers to acquire information, opportunity for attackers and eavesdroppers to acquire information,
however, as they are all under the control of a single entity they however, as they are all under the control of a single entity they
are also the easiest to have tightly secured. are also the easiest to have tightly secured.
4.2. Privacy Aspects of ABFAB Communication Flows 4.2. Privacy Aspects of ABFAB Communication Flows
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. The best way to understand them, and the and identifiers in use. The best way to understand them, and the
skipping to change at page 38, line 27 skipping to change at page 39, line 9
related to them that transmitted from the IdP to RP for authorization related to them that transmitted from the IdP to RP for authorization
purposes; rather, this is under the control of policy on the IdP. purposes; rather, this is under the control of policy on the IdP.
Due to the nature of the AAA communication flows, with the current Due to the nature of the AAA communication flows, with the current
ABFAB architecture there is no place for a process of gaining user ABFAB architecture there is no place for a process of gaining user
consent for the information to be released from IdP to RP. consent for the information to be released from IdP to RP.
5. Security Considerations 5. 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. Many of the items that are security considerations have
and their security properties: already been discussed in the Privacy Considerations section.
Readers should be sure to read that section as well.
Client-to-RP Channel:
The channel binding material is provided by any certificates and
the final message (i.e., a cryptographic token for the channel).
Authentication may be provided by the RP to the client but a
deployment without authentication at the TLS layer is possible as
well. In addition, there is a channel between the GSS requestor
and the GSS acceptor, but the keying material is provided by a
"third party" to both entities. The client can derive keying
material locally, but the RP gets the material from the IdP. In
the absence of a transport that provides encryption and/or
integrity, the channel between the client and the RP has no
ability to have any cryptographic protection until the EAP
authentication has been completed and the MSK is transferred from
the IdP to the RP.
RP-to-IdP Channel:
The security of this communication channel is mainly provided by
the functionality offered via RADIUS and Diameter. At the time of
writing there are no end-to-end security mechanisms standardized
and thereby the architecture has to rely on hop-by-hop security
with trusted AAA entities or, as an alternative but possible
deployment variant, direct communication between the AAA client to
the AAA server. Note that the authorization result the IdP
provides to the RP in the form of a SAML assertion may; however,
be protected such that the SAML related components are secured
end-to-end.
The MSK is transported from the IdP to the RP over this channel.
As no end-to-end security is provided by AAA, all AAA entities on
the path between the RP and IdP have the ability to eavesdrop if
no additional security measures are taken. One such measure is to
use a transport between the client and the IdP that provides
confidentiality.
Client-to-IdP Channel: There are many places in this document where TLS is used. While in
some places (i.e. client to RP) anonymous connections can be used, it
is very important that TLS connections within the AAA infrastructure
and between the client and the IdP be fully authenticated and, if
using certificates, that revocation be checked as well. When using
anonymous connections between the client and the RP, all messages and
data exchanged between those two entities will be visible to an
active attacker. In situations where the client is not yet on the
net, the status_request extension [RFC6066] can be used to obtain
revocation checking data inside of the TLS protocol. Clients also
need to get the Trust Anchor for the IdP configured correctly in
order to prevent attacks, this is a hard problem in general and is
going to be even harder for kiosk environments.
This communication interaction is accomplished with the help of Selection of the EAP methods to be permitted by clients and IdPs is
EAP and EAP methods. The offered security protection will depend important. The use of a tunneling method such as TEAP
on the EAP method that is chosen but a minimum requirement is to [I-D.ietf-emu-eap-tunnel-method] allows for other EAP methods to be
offer mutual authentication, and key derivation. The IdP is used while hiding the contents of those EAP exchanges from the RP and
responsible during this process to determine that the RP that is the AAA framework. When considering inner EAP methods the
communication to the client over the RP-to-IdP channel is the same considerations outlined in [RFC7029] about binding the inner and
one talking to the IdP. This is accomplished via the EAP channel outer EAP methods needs to be considered. Finally, one wants to have
binding. the ability to support channel binding those cses where the client
needs to validate it is talking to the correct RP.
Partial list of issues to be addressed in this section: Privacy, In those places where SAML statements are used, RPs will generally be
SAML, Trust Anchors, EAP Algorithm Selection, Diameter/RADIUS/AAA unable to validate signatures on the SAML statement, either because
Issues, Naming of Entities, Protection of passwords, Channel Binding, it is stripped off by the IdP or because it is unable to validate the
End-point-connections (TLS), Proxy problems binding between the signer, the key used to sign and the realm
represented by the IdP. For these reasons it is required that IdPs
do the necessary trust checking on the SAML statements and RPs can
trust the AAA infrastructure to keep the SAML statement valid.
When a pseudonym is generated as a unique long term identifier for a When a pseudonym is generated as a unique long term identifier for a
client by an IdP, care must be taken in the algorithm that it cannot client 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.
6. IANA Considerations 6. IANA Considerations
skipping to change at page 40, line 31 skipping to change at page 40, line 43
3748, June 2004. 3748, June 2004.
[RFC3579] Aboba, B. and P. Calhoun, "RADIUS (Remote Authentication [RFC3579] Aboba, B. and P. Calhoun, "RADIUS (Remote Authentication
Dial In User Service) Support For Extensible Dial In User Service) Support For Extensible
Authentication Protocol (EAP)", RFC 3579, September 2003. Authentication Protocol (EAP)", RFC 3579, September 2003.
[RFC4072] Eronen, P., Hiller, T., and G. Zorn, "Diameter Extensible [RFC4072] Eronen, P., Hiller, T., and G. Zorn, "Diameter Extensible
Authentication Protocol (EAP) Application", RFC 4072, Authentication Protocol (EAP) Application", RFC 4072,
August 2005. August 2005.
[I-D.ietf-abfab-gss-eap] [RFC7055] Hartman, S. and J. Howlett, "A GSS-API Mechanism for the
Hartman, S. and J. Howlett, "A GSS-API Mechanism for the Extensible Authentication Protocol", RFC 7055, December
Extensible Authentication Protocol", draft-ietf-abfab-gss- 2013.
eap-09 (work in progress), August 2012.
[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,
Profiles, Name Identifier Format, and Confirmation Methods Profiles, Name Identifier Format, and Confirmation Methods
for SAML", draft-ietf-abfab-aaa-saml-08 (work in for SAML", draft-ietf-abfab-aaa-saml-08 (work in
progress), November 2013. progress), November 2013.
[I-D.ietf-radext-nai] [I-D.ietf-radext-nai]
DeKok, A., "The Network Access Identifier", draft-ietf- DeKok, A., "The Network Access Identifier", draft-ietf-
radext-nai-05 (work in progress), November 2013. radext-nai-05 (work in progress), November 2013.
skipping to change at page 43, line 5 skipping to change at page 43, line 10
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, Standard ws-trust-200902, February 2009,
<http://docs.oasis-open.org/ws-sx/ws-trust/v1.4/ <http://docs.oasis-open.org/ws-sx/ws-trust/v1.4/
ws-trust.html>. ws-trust.html>.
[NIST-SP.800-63] [NIST-SP.800-63]
Burr, W., Dodson, D., and W. Polk, "Electronic Burr, W., Dodson, D., and W. Polk, "Electronic
Authentication Guideline", NIST Special Publication Authentication Guideline", NIST Special Publication
800-63, April 2006. 800-63, April 2006.
Authors' Addresses [RFC4178] Zhu, L., Leach, P., Jaganathan, K., and W. Ingersoll, "The
Simple and Protected Generic Security Service Application
Program Interface (GSS-API) Negotiation Mechanism", RFC
4178, October 2005.
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security
(TLS) Protocol Version 1.2", RFC 5246, August 2008.
[RFC2782] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for
specifying the location of services (DNS SRV)", RFC 2782,
February 2000.
[RFC2915] Mealling, M. and R. Daniel, "The Naming Authority Pointer
(NAPTR) DNS Resource Record", RFC 2915, September 2000.
[RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S.
Rose, "DNS Security Introduction and Requirements", RFC
4033, March 2005.
[RFC6066] Eastlake, D., "Transport Layer Security (TLS) Extensions:
Extension Definitions", RFC 6066, January 2011.
8.3. URIs
[1] http://www.openid.net
[2] https://community.ja.net/system/files/288/Trust-Router-Overview-
IETF86.pptx
[3] https://commmunity.ja.net/system/files/288/Trust-Router-Overview-
IETF86.pptx
[4] http://www.eduroam.org
Editorial Comments
[CREF1] JLS: Should this be an EAP failure to the client as well?
Authors' Addresses
Josh Howlett Josh Howlett
JANET(UK) JANET(UK)
Lumen House, Library Avenue, Harwell Lumen House, Library Avenue, Harwell
Oxford OX11 0SG Oxford OX11 0SG
UK UK
Phone: +44 1235 822363 Phone: +44 1235 822363
Email: Josh.Howlett@ja.net Email: Josh.Howlett@ja.net
Sam Hartman Sam Hartman
 End of changes. 64 change blocks. 
237 lines changed or deleted 280 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/