< draft-ietf-abfab-arch-08.txt   draft-ietf-abfab-arch-09.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: May 7, 2014 Painless Security Expires: June 9, 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
November 3, 2013 December 6, 2013
Application Bridging for Federated Access Beyond Web (ABFAB) Application Bridging for Federated Access Beyond Web (ABFAB)
Architecture Architecture
draft-ietf-abfab-arch-08.txt draft-ietf-abfab-arch-09.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 common building blocks in common.
This memo describes an architecture that makes use of extensions to This memo describes an architecture that makes use of extensions to
skipping to change at page 2, line 10 skipping to change at page 2, line 10
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 May 7, 2014. This Internet-Draft will expire on June 9, 2014.
Copyright Notice Copyright Notice
Copyright (c) 2013 IETF Trust and the persons identified as the Copyright (c) 2013 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 33 skipping to change at page 2, line 33
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5
1.1.1. Channel Binding . . . . . . . . . . . . . . . . . . . 6 1.1.1. Channel Binding . . . . . . . . . . . . . . . . . . . 6
1.2. An Overview of Federation . . . . . . . . . . . . . . . . 7 1.2. An Overview of Federation . . . . . . . . . . . . . . . . 7
1.3. Challenges for Contemporary Federation . . . . . . . . . 11 1.3. Challenges for Contemporary Federation . . . . . . . . . 10
1.4. An Overview of ABFAB-based Federation . . . . . . . . . . 11 1.4. An Overview of ABFAB-based Federation . . . . . . . . . . 10
1.5. Design Goals . . . . . . . . . . . . . . . . . . . . . . 14 1.5. Design Goals . . . . . . . . . . . . . . . . . . . . . . 13
2. Architecture . . . . . . . . . . . . . . . . . . . . . . . . 15 2. Architecture . . . . . . . . . . . . . . . . . . . . . . . . 14
2.1. Relying Party to Identity Provider . . . . . . . . . . . 16 2.1. Relying Party to Identity Provider . . . . . . . . . . . 15
2.1.1. AAA, RADIUS and Diameter . . . . . . . . . . . . . . 17 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 . . . . . . . . . . . . . . . . . . . . 21 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) . . . . . . 24 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 . . . . . . . . . . . . . . . . . 26 2.3. Client to Relying Party . . . . . . . . . . . . . . . . . 25
2.3.1. GSS-API . . . . . . . . . . . . . . . . . . . . . . . 26 2.3.1. GSS-API . . . . . . . . . . . . . . . . . . . . . . . 25
2.3.2. Protocol Transport . . . . . . . . . . . . . . . . . 28 2.3.2. Protocol Transport . . . . . . . . . . . . . . . . . 27
2.3.3. Reauthentication . . . . . . . . . . . . . . . . . . 28 2.3.3. Reauthentication . . . . . . . . . . . . . . . . . . 27
3. Application Security Services . . . . . . . . . . . . . . . . 28 3. Application Security Services . . . . . . . . . . . . . . . . 28
3.1. Authentication . . . . . . . . . . . . . . . . . . . . . 29 3.1. Authentication . . . . . . . . . . . . . . . . . . . . . 28
3.2. GSS-API Channel Binding . . . . . . . . . . . . . . . . . 30 3.2. GSS-API Channel Binding . . . . . . . . . . . . . . . . . 29
3.3. Host-Based Service Names . . . . . . . . . . . . . . . . 31 3.3. Host-Based Service Names . . . . . . . . . . . . . . . . 30
3.4. Additional GSS-API Services . . . . . . . . . . . . . . . 33 3.4. Additional GSS-API Services . . . . . . . . . . . . . . . 32
4. Privacy Considerations . . . . . . . . . . . . . . . . . . . 33 4. Privacy Considerations . . . . . . . . . . . . . . . . . . . 32
4.1. Entities and their roles . . . . . . . . . . . . . . . . 34 4.1. Entities and their roles . . . . . . . . . . . . . . . . 33
4.2. Privacy Aspects of ABFAB Communication Flows . . . . . . 35 4.2. Privacy Aspects of ABFAB Communication Flows . . . . . . 34
4.2.1. Client to RP . . . . . . . . . . . . . . . . . . . . 35 4.2.1. Client to RP . . . . . . . . . . . . . . . . . . . . 34
4.2.2. Client to IdP (via Federation Substrate) . . . . . . 36 4.2.2. Client to IdP (via Federation Substrate) . . . . . . 35
4.2.3. IdP to RP (via Federation Substrate) . . . . . . . . 37 4.2.3. IdP to RP (via Federation Substrate) . . . . . . . . 36
4.3. Relationship between User and Entities . . . . . . . . . 38 4.3. Relationship between User and Entities . . . . . . . . . 37
4.4. Accounting Information . . . . . . . . . . . . . . . . . 38 4.4. Accounting Information . . . . . . . . . . . . . . . . . 37
4.5. Collection and retention of data and identifiers . . . . 38 4.5. Collection and retention of data and identifiers . . . . 37
4.6. User Participation . . . . . . . . . . . . . . . . . . . 39 4.6. User Participation . . . . . . . . . . . . . . . . . . . 38
5. Security Considerations . . . . . . . . . . . . . . . . . . . 39 5. Security Considerations . . . . . . . . . . . . . . . . . . . 38
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 40 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 39
7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 40 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 39
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 41 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 40
8.1. Normative References . . . . . . . . . . . . . . . . . . 41 8.1. Normative References . . . . . . . . . . . . . . . . . . 40
8.2. Informative References . . . . . . . . . . . . . . . . . 42 8.2. Informative References . . . . . . . . . . . . . . . . . 41
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 44 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 43
1. Introduction 1. Introduction
The Internet uses numerous security mechanisms to manage access to The Internet uses numerous security mechanisms to manage access to
various resources. These mechanisms have been generalized and scaled various resources. These mechanisms have been generalized and scaled
over the last decade through mechanisms such as Simple Authentication over the last decade through mechanisms such as Simple Authentication
and Security Layer (SASL) with the Generic Security Server and Security Layer (SASL) with the Generic Security Server
Application Program Interface (GSS-API) (known as the GS2 family) Application Program Interface (GSS-API) (known as the GS2 family)
[RFC5801], Security Assertion Markup Language (SAML) [RFC5801], Security Assertion Markup Language (SAML)
[OASIS.saml-core-2.0-os], and the Authentication, Authorization, and [OASIS.saml-core-2.0-os], and the Authentication, Authorization, and
Accounting (AAA) architecture as embodied in RADIUS [RFC2865] and Accounting (AAA) architecture as embodied in RADIUS [RFC2865] and
Diameter [RFC3588]. 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.
Some security mechanisms allow the RP to delegate aspects of the Some security mechanisms allow the RP to delegate aspects of the
access management decision to an entity called the Identity Provider access management decision to an entity called the Identity Provider
(IdP). This delegation requires technical signaling, trust and a (IdP). This delegation requires technical signaling, trust and a
common understanding of semantics between the RP and IdP. These common understanding of semantics between the RP and IdP. These
aspects are generally managed within a relationship known as a aspects are generally managed within a relationship known as a
'federation'. This style of access management is accordingly 'federation'. This style of access management is accordingly
described as 'federated access management'. described as 'federated access management'.
Federated access management has evolved over the last decade through Federated access management has evolved over the last decade through
specifications like SAML [OASIS.saml-core-2.0-os], OpenID [1], OAuth specifications like SAML [OASIS.saml-core-2.0-os], OpenID [1], OAuth
[RFC5849], [I-D.ietf-oauth-v2] and WS-Trust [WS-TRUST]. The benefits [RFC6749] and WS-Trust [WS-TRUST]. The benefits of federated access
of federated access management include: management include:
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.
skipping to change at page 5, line 8 skipping to change at page 5, line 8
and the Diameter protocols, the Generic Security Service (GSS), the and the Diameter protocols, the Generic Security Service (GSS), the
Extensible Authentication Protocol (EAP) and SAML. The architecture Extensible Authentication Protocol (EAP) and SAML. The architecture
addresses the problem of federated access management primarily for addresses the problem of federated access management primarily for
non-web-based services. It does so in a manner that will scale to non-web-based services. It does so in a manner that will scale to
large numbers of identity providers, relying parties, and large numbers of identity providers, relying parties, and
federations. federations.
1.1. Terminology 1.1. Terminology
This document uses identity management and privacy terminology from This document uses identity management and privacy terminology from
[I-D.iab-privacy-considerations]. In particular, this document uses [RFC6973]. In particular, this document uses the terms identity
the terms identity provider, relying party, identifier, pseudonymity, provider, relying party, identifier, pseudonymity, unlinkability, and
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 or a Diameter server, and optionally a SAML EAP server, a RADIUS or a Diameter server, and optionally a SAML
Assertion service. Assertion service.
This document uses the term Network Access Identifier (NAI), as This document uses the term Network Access Identifier (NAI), as
defined in [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 people will find with reading this document is
that the terminology sometimes appears to be inconsistent. This is that the terminology sometimes appears to be inconsistent. This is
due the fact that the terms used by the different standards we are 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. In general the document uses either
the ABFAB term or the term associated with the standard under the ABFAB term or the term associated with the standard under
discussion as appropriate. For reference we include this table which discussion as appropriate. For reference we include this table which
maps the different terms into a single table. maps the different terms into a single table.
+------------+-------------+---------------------+------------------+ +----------+-----------+--------------------+-----------------------+
| Protocol | Client | Relying Party | Identity | | Protocol | Client | Relying Party | Identity Provider |
| | | | Provider | +----------+-----------+--------------------+-----------------------+
+------------+-------------+---------------------+------------------+ | ABFAB | Client | Relying Party (RP) | Identity Provider |
| ABFAB | Client | Relying Party (RP) | Identity | | | | | (IdP) |
| | | | Provider (IdP) | | | | | |
| | | | | | | Initiator | Acceptor | |
| | Initiator | Acceptor | | | | | | |
| | | | | | | | Server | |
| | | Server | | | | | | |
| | | | | | SAML | Subject | Service Provider | Issuer |
| SAML | Subject | Service Provider | Issuer | | | | | |
| | | | | | GSS-API | Initiator | Acceptor | |
| GSS-API | Initiator | Acceptor | | | | | | |
| | | | | | EAP | EAP peer | EAP Authenticator | EAP server |
| EAP | EAP peer | EAP Authenticator | EAP server | | | | | |
| | | | | | AAA | | AAA Client | AAA server |
| AAA | | AAA Client | AAA server | | | | | |
| | | | | | RADIUS | user | NAS | RADIUS server |
| RADIUS | user | NAS | RADIUS server | | | | | |
| | | | | | | | RADIUS client | |
| | | RADIUS client | | +----------+-----------+--------------------+-----------------------+
+------------+-------------+---------------------+------------------+
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.
skipping to change at page 12, line 20 skipping to change at page 11, line 36
5. Request from Relying Party to IdP: Once the RP knows who the IdP 5. Request from Relying Party to IdP: Once the RP knows who the IdP
is, it (or its agent) will send a RADIUS/Diameter request to the is, it (or its agent) will send a RADIUS/Diameter request to the
IdP. The RADIUS/Diameter access request encapsulates the EAP IdP. The RADIUS/Diameter access request encapsulates the EAP
response. At this stage, the RP will likely have no idea who response. At this stage, the RP will likely have no idea who
the client is. The RP sends its identity to the IdP in AAA the client is. The RP sends its identity to the IdP in AAA
attributes, and it may send a SAML Attribute Request in a AAA attributes, and it may send a SAML Attribute Request in a AAA
attribute. The AAA network checks that the identity claimed by attribute. The AAA network checks that the identity claimed by
the RP is valid. the RP is valid.
6. IdP begins EAP with the client: The IdP sends an EAP message to 6. IdP begins EAP with the client: The IdP sends an EAP message to
the client with an EAP method to be used. The IdP SHOULD NOT the client with an EAP method to be used. The IdP should not
re-request the clients name in this message, but clients need to re-request the clients name in this message, but clients need to
be able to handle it. In this case the IdP MUST accept a realm be able to handle it. In this case the IdP must accept a realm
only in order to protect the client's name from the RP. The only in order to protect the client's name from the RP. The
available and appropriate methods are discussed below in this available and appropriate methods are discussed below in this
memo (Section 2.2.1). memo (Section 2.2.1).
7. The EAP protocol is run: A bunch of EAP messages are passed 7. The EAP protocol is run: A bunch of EAP messages are passed
between the client (EAP peer) and the IdP (EAP server), until between the client (EAP peer) and the IdP (EAP server), until
the result of the authentication protocol is determined. The the result of the authentication protocol is determined. The
number and content of those messages depends on the EAP method number and content of those messages depends on the EAP method
selected. If the IdP is unable to authenticate the client, the selected. If the IdP is unable to authenticate the client, the
IdP sends an EAP failure message to the RP. As part of the EAP IdP sends an EAP failure message to the RP. As part of the EAP
skipping to change at page 13, line 5 skipping to change at page 12, line 21
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.[[Should this be an it sends an EAP failure message to the RP.[] (The RP will have
EAP failure to the client as well?]] (The RP will have done its done its policy checks during the discovery process.)
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 17, line 25 skipping to change at page 16, line 44
[I-D.ietf-abfab-aaa-saml] and Diameter (work in progress) which [I-D.ietf-abfab-aaa-saml] and Diameter (work in progress) which
allows the RP to query attributes about the client from the IdP. allows the RP to query attributes about the client from the IdP.
Future protocols that support the same framework but do different Future protocols that support the same framework but do different
routing may be used in the future. One such effort is to setup a routing may be used in the future. One such effort is to setup a
framework that creates a trusted point-to-point channel on the fly. framework that creates a trusted point-to-point channel on the fly.
2.1.1. AAA, RADIUS and Diameter 2.1.1. AAA, RADIUS and Diameter
Interestingly, for network access authentication the usage of the AAA Interestingly, for network access authentication the usage of the AAA
framework with RADIUS [RFC2865] and Diameter [RFC3588] was quite framework with RADIUS [RFC2865] and Diameter [RFC6733] was quite
successful from a deployment point of view. To map to the successful from a deployment point of view. To map to the
terminology used in Figure 1 to the AAA framework the IdP corresponds terminology used in Figure 1 to the AAA framework the IdP corresponds
to the AAA server, the RP corresponds to the AAA client, and the to the AAA server, the RP corresponds to the AAA client, and the
technical building blocks of a federation are AAA proxies, relays and technical building blocks of a federation are AAA proxies, relays and
redirect agents (particularly if they are operated by third parties, redirect agents (particularly if they are operated by third parties,
such as AAA brokers and clearing houses). The front-end, i.e. the such as AAA brokers and clearing houses). The front-end, i.e. the
end host to AAA client communication, is in case of network access end host to AAA client communication, is in case of network access
authentication offered by link layer protocols that forward authentication offered by link layer protocols that forward
authentication protocol exchanges back-and-forth. An example of a authentication protocol exchanges back-and-forth. An example of a
large scale RADIUS-based federation is EDUROAM [2]. large scale RADIUS-based federation is EDUROAM [2].
skipping to change at page 22, line 4 skipping to change at page 21, line 18
designed in the ability to protect the client authentication designed in the ability to protect the client authentication
credentials, the MSK returned from the IDP to the RP is protected credentials, the MSK returned from the IDP to the RP is protected
only by the RADIUS security. In many environments this is considered only by the RADIUS security. In many environments this is considered
to be insufficient, especially as not all attributes are obfuscated to be insufficient, especially as not all attributes are obfuscated
and can thus leak information to a passive eavesdropper. The use of and can thus leak information to a passive eavesdropper. The use of
RADIUS with TLS [RFC6614] and/or DTLS [I-D.ietf-radext-dtls] RADIUS with TLS [RFC6614] and/or DTLS [I-D.ietf-radext-dtls]
addresses these attacks. The same level of security is included in addresses these attacks. The same level of security is included in
the base Diameter specifications. the base Diameter 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.
Security Assertions Markup Language (SAML) [OASIS.saml-core-2.0-os] Security Assertions Markup Language (SAML) [OASIS.saml-core-2.0-os]
was designed in order to carry an extensible set of attributes about was designed in order to carry an extensible set of attributes about
a subject. Since SAML is extensible in the attribute space, ABFAB a subject. Since SAML is extensible in the attribute space, ABFAB
has no immediate needs to update the core SAML specifications for our has no immediate needs to update the core SAML specifications for our
work. It will be necessary to update IdPs that need to return SAML work. It will be necessary to update IdPs that need to return SAML
assertions to RPs and for both the IdP and the RP to implement a new assertions to RPs and for both the IdP and the RP to implement a new
SAML profile designed to carry SAML assertions in AAA. The new SAML profile designed to carry SAML assertions in AAA. The new
profile can be found in RFCXXXX [I-D.ietf-abfab-aaa-saml]. As SAML profile can be found in RFCXXXX [I-D.ietf-abfab-aaa-saml]. As SAML
statements will frequently be large, RADIUS servers and clients that statements will frequently be large, RADIUS servers and clients that
deal with SAML statements will need to implement RFC XXXX deal with SAML statements will need to implement RFC XXXX
[I-D.perez-radext-radius-fragmentation] [I-D.ietf-radext-radius-fragmentation]
There are several issues that need to be highlighted: There are several issues that need to be highlighted:
o The security of SAML assertions. o The security of SAML assertions.
o Namespaces and mapping of SAML attributes. o Namespaces and mapping of SAML attributes.
o Subject naming of entities. o Subject naming of entities.
o Making multiple queries about the subject(s). o Making multiple queries about the subject(s).
skipping to change at page 26, line 14 skipping to change at page 25, line 28
The client knows, in theory, the name of the RP that it attempted to The client knows, in theory, the name of the RP that it attempted to
connect to, however in the event that an attacker has intercepted the connect to, however in the event that an attacker has intercepted the
protocol, the client and the IdP need to be able to detect this protocol, the client and the IdP need to be able to detect this
situation. A general overview of the problem along with a situation. A general overview of the problem along with a
recommended way to deal with the channel binding issues can be found recommended way to deal with the channel binding issues can be found
in RFC 6677 [RFC6677]. in RFC 6677 [RFC6677].
Since that document was published, a number of possible attacks were Since that document was published, a number of possible attacks were
found and methods to address these attacks have been outlined in found and methods to address these attacks have been outlined in
[I-D.ietf-emu-crypto-bind]. [RFC7029].
2.3. Client to Relying Party 2.3. Client to Relying Party
The final set of interactions between the parties to consider are The final set of interactions between the parties to consider are
those between the client and the RP. In some ways this is the most those between the client and the RP. In some ways this is the most
complex set since at least part of it is outside the scope of the complex set since at least part of it is outside the scope of the
ABFAB work. The interactions between these parties include: ABFAB work. The interactions between these parties include:
o Running the protocol that implements the service that is provided o Running the protocol that implements the service that is provided
by the RP and desired by the client. by the RP and desired by the client.
skipping to change at page 30, line 25 skipping to change at page 29, line 30
request mutual authentication. When mutual authentication is request mutual authentication. When mutual authentication is
requested, only EAP methods capable of providing the necessary requested, only EAP methods capable of providing the necessary
service can be used, and appropriate steps need to be taken to service can be used, and appropriate steps need to be taken to
provide mutual authentication. While a broader set of EAP methods provide mutual authentication. While a broader set of EAP methods
could be supported by not requiring mutual authentication, it was could be supported by not requiring mutual authentication, it was
decided that the client needs to always have the ability to request decided that the client needs to always have the ability to request
it. In some cases the IdP and the RP will not support mutual it. In some cases the IdP and the RP will not support mutual
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.
3.2. GSS-API Channel Binding 3.2. GSS-API Channel Binding
skipping to change at page 33, line 49 skipping to change at page 32, line 51
ABFAB, as an architecture designed to enable federated authentication ABFAB, as an architecture designed to enable federated authentication
and allow for the secure transmission of identity information between and allow for the secure transmission of identity information between
entities, obviously requires careful consideration around privacy and entities, obviously requires careful consideration around privacy and
the potential for privacy violations. the potential for privacy violations.
This section examines the privacy related information presented in This section examines the privacy related information presented in
this document, summarizing the entities that are involved in ABFAB this document, summarizing the entities that are involved in ABFAB
communications and what exposure they have to identity information. communications and what exposure they have to identity information.
In discussing these privacy considerations in this section, we use In discussing these privacy considerations in this section, we use
terminology and ideas from [I-D.iab-privacy-considerations]. terminology and ideas from [RFC6973].
Note that the ABFAB architecture uses at its core several existing Note that the ABFAB architecture uses at its core several existing
technologies and protocols; detailed privacy discussion around these technologies and protocols; detailed privacy discussion around these
is not examined. This section instead focuses on privacy is not examined. This section instead focuses on privacy
considerations specifically related to overall architecture and usage considerations specifically related to overall architecture and usage
of ABFAB. of ABFAB.
+--------+ +---------------+ +--------------+ +--------+ +---------------+ +--------------+
| Client | <---> | RP | <---> | AAA Client | | Client | <---> | RP | <---> | AAA Client |
+--------+ +---------------+ +--------------+ +--------+ +---------------+ +--------------+
skipping to change at page 34, line 29 skipping to change at page 33, line 32
v v v v
+------------+ +---------------+ +--------------+ +------------+ +---------------+ +--------------+
| EAP Server | <---> | IdP | <---> | AAA Server | | EAP Server | <---> | IdP | <---> | AAA Server |
+------------+ +---------------+ +--------------+ +------------+ +---------------+ +--------------+
Figure 3: Entities and Data Flow Figure 3: 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 3 according to
the taxonomy of terms from [I-D.iab-privacy-considerations] the the taxonomy of terms from [RFC6973] the entities shown in Figure 3
entities shown in Figure 3 is somewhat complicated as during the is somewhat complicated as during the various phases of ABFAB
various phases of ABFAB communications the roles of each entity communications the roles of each entity changes. The three main
changes. The three main phases of relevance are the Client to RP phases of relevance are the Client to RP communication phase, the
communication phase, the Client to IdP (via the Federation Substrate) Client to IdP (via the Federation Substrate) phase, and the IdP to RP
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.
Observers: Client, RP. Observers: Client, RP.
Recipient: RP. Recipient: RP.
In the Client to IdP (via the Federation Substrate) communication In the Client to IdP (via the Federation Substrate) communication
skipping to change at page 40, line 35 skipping to change at page 39, line 40
communication to the client over the RP-to-IdP channel is the same communication to the client over the RP-to-IdP channel is the same
one talking to the IdP. This is accomplished via the EAP channel one talking to the IdP. This is accomplished via the EAP channel
binding. binding.
Partial list of issues to be addressed in this section: Privacy, Partial list of issues to be addressed in this section: Privacy,
SAML, Trust Anchors, EAP Algorithm Selection, Diameter/RADIUS/AAA SAML, Trust Anchors, EAP Algorithm Selection, Diameter/RADIUS/AAA
Issues, Naming of Entities, Protection of passwords, Channel Binding, Issues, Naming of Entities, Protection of passwords, Channel Binding,
End-point-connections (TLS), Proxy problems End-point-connections (TLS), Proxy problems
When a 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
This document does not require actions by IANA. This document does not require actions by IANA.
7. Acknowledgments 7. Acknowledgments
skipping to change at page 40, line 46 skipping to change at page 40, line 4
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
This document does not require actions by IANA. This document does not require actions by IANA.
7. Acknowledgments 7. Acknowledgments
We would like to thank Mayutan Arumaithurai, Klaas Wierenga and Rhys We would like to thank Mayutan Arumaithurai, Klaas Wierenga and Rhys
Smith for their feedback. Additionally, we would like to thank Eve Smith for their feedback. Additionally, we would like to thank Eve
Maler, Nicolas Williams, Bob Morgan, Scott Cantor, Jim Fenton, Paul Maler, Nicolas Williams, Bob Morgan, Scott Cantor, Jim Fenton, Paul
Leach, and Luke Howard for their feedback on the federation Leach, and Luke Howard for their feedback on the federation
terminology question. terminology question.
Furthermore, we would like to thank Klaas Wierenga for his review of Furthermore, we would like to thank Klaas Wierenga for his review of
the pre-00 draft version. the pre-00 draft version.
8. References 8. References
8.1. Normative References 8.1. Normative References
[RFC2743] Linn, J., "Generic Security Service Application Program [RFC2743] Linn, J., "Generic Security Service Application Program
Interface Version 2, Update 1", RFC 2743, January 2000. Interface Version 2, Update 1", RFC 2743, January 2000.
[RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson, [RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson,
"Remote Authentication Dial In User Service (RADIUS)", RFC "Remote Authentication Dial In User Service (RADIUS)", RFC
2865, June 2000. 2865, June 2000.
[RFC3588] Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J. [RFC6733] Fajardo, V., Arkko, J., Loughney, J., and G. Zorn,
Arkko, "Diameter Base Protocol", RFC 3588, September 2003. "Diameter Base Protocol", RFC 6733, October 2012.
[RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. [RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H.
Levkowetz, "Extensible Authentication Protocol (EAP)", RFC Levkowetz, "Extensible Authentication Protocol (EAP)", RFC
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
skipping to change at page 41, line 42 skipping to change at page 40, line 47
August 2005. August 2005.
[I-D.ietf-abfab-gss-eap] [I-D.ietf-abfab-gss-eap]
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", draft-ietf-abfab-gss- Extensible Authentication Protocol", draft-ietf-abfab-gss-
eap-09 (work in progress), August 2012. 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-05 (work in for SAML", draft-ietf-abfab-aaa-saml-08 (work in
progress), February 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-02 (work in progress), January 2013. radext-nai-05 (work in progress), November 2013.
[RFC6677] Hartman, S., Clancy, T., and K. Hoeper, "Channel-Binding [RFC6677] Hartman, S., Clancy, T., and K. Hoeper, "Channel-Binding
Support for Extensible Authentication Protocol (EAP) Support for Extensible Authentication Protocol (EAP)
Methods", RFC 6677, July 2012. Methods", RFC 6677, July 2012.
8.2. Informative References 8.2. Informative References
[RFC2903] de Laat, C., Gross, G., Gommans, L., Vollbrecht, J., and [RFC6749] Hardt, D., "The OAuth 2.0 Authorization Framework", RFC
D. Spence, "Generic AAA Architecture", RFC 2903, August 6749, October 2012.
2000.
[I-D.nir-tls-eap]
Nir, Y., Sheffer, Y., Tschofenig, H., and P. Gutmann, "A
Flexible Authentication Framework for the Transport Layer
Security (TLS) Protocol using the Extensible
Authentication Protocol (EAP)", draft-nir-tls-eap-13 (work
in progress), December 2011.
[I-D.ietf-oauth-v2]
Hardt, D., "The OAuth 2.0 Authorization Framework", draft-
ietf-oauth-v2-31 (work in progress), August 2012.
[I-D.iab-privacy-considerations] [RFC6973] Cooper, A., Tschofenig, H., Aboba, B., Peterson, J.,
Cooper, A., Tschofenig, H., Aboba, B., Peterson, J.,
Morris, J., Hansen, M., and R. Smith, "Privacy Morris, J., Hansen, M., and R. Smith, "Privacy
Considerations for Internet Protocols", draft-iab-privacy- Considerations for Internet Protocols", RFC 6973, July
considerations-03 (work in progress), July 2012. 2013.
[I-D.perez-radext-radius-fragmentation] [I-D.ietf-radext-radius-fragmentation]
Perez-Mendez, A., Lopez, R., Pereniguez-Garcia, F., Lopez- Perez-Mendez, A., Lopez, R., Pereniguez-Garcia, F., Lopez-
Millan, G., Lopez, D., and A. DeKok, "Support of Millan, G., Lopez, D., and A. DeKok, "Support of
fragmentation of RADIUS packets", draft-perez-radext- fragmentation of RADIUS packets", draft-ietf-radext-
radius-fragmentation-05 (work in progress), February 2013. radius-fragmentation-02 (work in progress), November 2013.
[RFC4017] Stanley, D., Walker, J., and B. Aboba, "Extensible
Authentication Protocol (EAP) Method Requirements for
Wireless LANs", RFC 4017, March 2005.
[RFC5106] Tschofenig, H., Kroeselberg, D., Pashalidis, A., Ohba, Y.,
and F. Bersani, "The Extensible Authentication Protocol-
Internet Key Exchange Protocol version 2 (EAP-IKEv2)
Method", RFC 5106, February 2008.
[RFC1964] Linn, J., "The Kerberos Version 5 GSS-API Mechanism", RFC [RFC1964] Linn, J., "The Kerberos Version 5 GSS-API Mechanism", RFC
1964, June 1996. 1964, June 1996.
[RFC2203] Eisler, M., Chiu, A., and L. Ling, "RPCSEC_GSS Protocol [RFC2203] Eisler, M., Chiu, A., and L. Ling, "RPCSEC_GSS Protocol
Specification", RFC 2203, September 1997. Specification", RFC 2203, September 1997.
[RFC3645] Kwan, S., Garg, P., Gilroy, J., Esibov, L., Westhead, J., [RFC3645] Kwan, S., Garg, P., Gilroy, J., Esibov, L., Westhead, J.,
and R. Hall, "Generic Security Service Algorithm for and R. Hall, "Generic Security Service Algorithm for
Secret Key Transaction Authentication for DNS (GSS-TSIG)", Secret Key Transaction Authentication for DNS (GSS-TSIG)",
RFC 3645, October 2003. RFC 3645, October 2003.
[RFC2138] Rigney, C., Rigney, C., Rubens, A., Simpson, W., and S.
Willens, "Remote Authentication Dial In User Service
(RADIUS)", RFC 2138, April 1997.
[RFC4462] Hutzelman, J., Salowey, J., Galbraith, J., and V. Welch, [RFC4462] Hutzelman, J., Salowey, J., Galbraith, J., and V. Welch,
"Generic Security Service Application Program Interface "Generic Security Service Application Program Interface
(GSS-API) Authentication and Key Exchange for the Secure (GSS-API) Authentication and Key Exchange for the Secure
Shell (SSH) Protocol", RFC 4462, May 2006. Shell (SSH) Protocol", RFC 4462, May 2006.
[RFC4422] Melnikov, A. and K. Zeilenga, "Simple Authentication and [RFC4422] Melnikov, A. and K. Zeilenga, "Simple Authentication and
Security Layer (SASL)", RFC 4422, June 2006. Security Layer (SASL)", RFC 4422, June 2006.
[RFC5056] Williams, N., "On the Use of Channel Bindings to Secure [RFC5056] Williams, N., "On the Use of Channel Bindings to Secure
Channels", RFC 5056, November 2007. Channels", RFC 5056, November 2007.
skipping to change at page 43, line 32 skipping to change at page 42, line 13
Suggested Fixes", RFC 5080, December 2007. Suggested Fixes", RFC 5080, December 2007.
[RFC5705] Rescorla, E., "Keying Material Exporters for Transport [RFC5705] Rescorla, E., "Keying Material Exporters for Transport
Layer Security (TLS)", RFC 5705, March 2010. Layer Security (TLS)", RFC 5705, March 2010.
[RFC5801] Josefsson, S. and N. Williams, "Using Generic Security [RFC5801] Josefsson, S. and N. Williams, "Using Generic Security
Service Application Program Interface (GSS-API) Mechanisms Service Application Program Interface (GSS-API) Mechanisms
in Simple Authentication and Security Layer (SASL): The in Simple Authentication and Security Layer (SASL): The
GS2 Mechanism Family", RFC 5801, July 2010. GS2 Mechanism Family", RFC 5801, July 2010.
[RFC5849] Hammer-Lahav, E., "The OAuth 1.0 Protocol", RFC 5849,
April 2010.
[RFC6614] Winter, S., McCauley, M., Venaas, S., and K. Wierenga, [RFC6614] Winter, S., McCauley, M., Venaas, S., and K. Wierenga,
"Transport Layer Security (TLS) Encryption for RADIUS", "Transport Layer Security (TLS) Encryption for RADIUS",
RFC 6614, May 2012. RFC 6614, May 2012.
[OASIS.saml-core-2.0-os] [OASIS.saml-core-2.0-os]
Cantor, S., Kemp, J., Philpott, R., and E. Maler, Cantor, S., Kemp, J., Philpott, R., and E. Maler,
"Assertions and Protocol for the OASIS Security Assertion "Assertions and Protocol for the OASIS Security Assertion
Markup Language (SAML) V2.0", OASIS Standard saml- Markup Language (SAML) V2.0", OASIS Standard saml-
core-2.0-os, March 2005. core-2.0-os, March 2005.
[RFC2904] Vollbrecht, J., Calhoun, P., Farrell, S., Gommans, L., [RFC7029] Hartman, S., Wasserman, M., and D. Zhang, "Extensible
Gross, G., de Bruijn, B., de Laat, C., Holdrege, M., and Authentication Protocol (EAP) Mutual Cryptographic
D. Spence, "AAA Authorization Framework", RFC 2904, August Binding", RFC 7029, October 2013.
2000.
[I-D.ietf-emu-crypto-bind]
Hartman, S., Wasserman, M., and D. Zhang, "EAP Mutual
Cryptographic Binding", draft-ietf-emu-crypto-bind-03
(work in progress), March 2013.
[I-D.ietf-emu-eap-tunnel-method] [I-D.ietf-emu-eap-tunnel-method]
Zhou, H., Cam-Winget, N., Salowey, J., and S. Hanna, Zhou, H., Cam-Winget, N., Salowey, J., and S. Hanna,
"Tunnel EAP Method (TEAP) Version 1", draft-ietf-emu-eap- "Tunnel EAP Method (TEAP) Version 1", draft-ietf-emu-eap-
tunnel-method-05 (work in progress), February 2013. tunnel-method-09 (work in progress), September 2013.
[I-D.ietf-radext-dtls] [I-D.ietf-radext-dtls]
DeKok, A., "DTLS as a Transport Layer for RADIUS", draft- DeKok, A., "DTLS as a Transport Layer for RADIUS", draft-
ietf-radext-dtls-03 (work in progress), January 2013. ietf-radext-dtls-07 (work in progress), October 2013.
[I-D.ietf-radext-dynamic-discovery] [I-D.ietf-radext-dynamic-discovery]
Winter, S. and M. McCauley, "NAI-based Dynamic Peer Winter, S. and M. McCauley, "NAI-based Dynamic Peer
Discovery for RADIUS/TLS and RADIUS/DTLS", draft-ietf- Discovery for RADIUS/TLS and RADIUS/DTLS", draft-ietf-
radext-dynamic-discovery-06 (work in progress), February radext-dynamic-discovery-08 (work in progress), October
2013. 2013.
[WS-TRUST] [WS-TRUST]
Lawrence, K., Kaler, C., Nadalin, A., Goodner, M., Gudgin, Lawrence, K., Kaler, C., Nadalin, A., Goodner, M., Gudgin,
M., Barbir, A., and H. Granqvist, "WS-Trust 1.4", OASIS M., Barbir, A., and H. Granqvist, "WS-Trust 1.4", OASIS
Standard ws-trust-200902, February 2009, <http://docs Standard ws-trust-200902, February 2009,
.oasis-open.org/ws-sx/ws-trust/v1.4/ws-trust.html>. <http://docs.oasis-open.org/ws-sx/ws-trust/v1.4/
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 Authors' Addresses
Josh Howlett Josh Howlett
JANET(UK) JANET(UK)
 End of changes. 40 change blocks. 
140 lines changed or deleted 104 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/