doc: Add RFC documents

1 files changed, 2579 insertions, 0 deletions

diff --git a/doc/rfc/rfc7831.txt b/doc/rfc/rfc7831.txt
new file mode 100644
index 0000000..b026c34
--- /dev/null
+++ b/doc/rfc/rfc7831.txt
@@ -0,0 +1,2579 @@
+
+
+
+
+
+
+Internet Engineering Task Force (IETF)                        J. Howlett
+Request for Comments: 7831                                          Jisc
+Category: Informational                                       S. Hartman
+ISSN: 2070-1721                                        Painless Security
+                                                           H. Tschofenig
+                                                                ARM Ltd.
+                                                               J. Schaad
+                                                          August Cellars
+                                                                May 2016
+
+
+      Application Bridging for Federated Access Beyond Web (ABFAB)
+                              Architecture
+
+Abstract
+
+   Over the last decade, a substantial amount of work has occurred in
+   the space of federated access management.  Most of this effort has
+   focused on two use cases: network access and web-based access.
+   However, the solutions to these use cases that have been proposed and
+   deployed tend to have few building blocks in common.
+
+   This memo describes an architecture that makes use of extensions to
+   the commonly used security mechanisms for both federated and non-
+   federated access management, including the Remote Authentication
+   Dial-In User Service (RADIUS), the Generic Security Service
+   Application Program Interface (GSS-API), the Extensible
+   Authentication Protocol (EAP), and the Security Assertion Markup
+   Language (SAML).  The architecture addresses the problem of federated
+   access management to primarily non-web-based services, in a manner
+   that will scale to large numbers of Identity Providers, Relying
+   Parties, and federations.
+
+Status of This Memo
+
+   This document is not an Internet Standards Track specification; it is
+   published for informational purposes.
+
+   This document is a product of the Internet Engineering Task Force
+   (IETF).  It represents the consensus of the IETF community.  It has
+   received public review and has been approved for publication by the
+   Internet Engineering Steering Group (IESG).  Not all documents
+   approved by the IESG are a candidate for any level of Internet
+   Standard; see Section 2 of RFC 5741.
+
+   Information about the current status of this document, any errata,
+   and how to provide feedback on it may be obtained at
+   http://www.rfc-editor.org/info/rfc7831.
+
+
+
+Howlett, et al.               Informational                     [Page 1]
+
+RFC 7831                   ABFAB Architecture                   May 2016
+
+
+Copyright Notice
+
+   Copyright (c) 2016 IETF Trust and the persons identified as the
+   document authors.  All rights reserved.
+
+   This document is subject to BCP 78 and the IETF Trust's Legal
+   Provisions Relating to IETF Documents
+   (http://trustee.ietf.org/license-info) in effect on the date of
+   publication of this document.  Please review these documents
+   carefully, as they describe your rights and restrictions with respect
+   to this document.  Code Components extracted from this document must
+   include Simplified BSD License text as described in Section 4.e of
+   the Trust Legal Provisions and are provided without warranty as
+   described in the Simplified BSD License.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Howlett, et al.               Informational                     [Page 2]
+
+RFC 7831                   ABFAB Architecture                   May 2016
+
+
+Table of Contents
+
+   1. Introduction ....................................................4
+      1.1. Terminology ................................................5
+           1.1.1. Channel Binding .....................................6
+      1.2. An Overview of Federation ..................................8
+      1.3. Challenges for Contemporary Federation ....................11
+      1.4. An Overview of ABFAB-Based Federation .....................11
+      1.5. Design Goals ..............................................14
+   2. Architecture ...................................................15
+      2.1. Relying Party to Identity Provider ........................16
+           2.1.1. AAA, RADIUS, and Diameter ..........................17
+           2.1.2. Discovery and Rules Determination ..................19
+           2.1.3. Routing and Technical Trust ........................20
+           2.1.4. AAA Security .......................................21
+           2.1.5. SAML Assertions ....................................22
+      2.2. Client to Identity Provider ...............................24
+           2.2.1. Extensible Authentication Protocol (EAP) ...........24
+           2.2.2. EAP Channel Binding ................................26
+      2.3. Client to Relying Party ...................................26
+           2.3.1. GSS-API ............................................27
+           2.3.2. Protocol Transport .................................28
+           2.3.3. Re-authentication ..................................29
+   3. Application Security Services ..................................29
+      3.1. Authentication ............................................29
+      3.2. GSS-API Channel Binding ...................................31
+      3.3. Host-Based Service Names ..................................32
+      3.4. Additional GSS-API Services ...............................33
+   4. Privacy Considerations .........................................34
+      4.1. Entities and Their Roles ..................................35
+      4.2. Privacy Aspects of ABFAB Communication Flows ..............36
+           4.2.1. Client to RP .......................................36
+           4.2.2. Client to IdP (via Federation Substrate) ...........37
+           4.2.3. IdP to RP (via Federation Substrate) ...............38
+      4.3. Relationship between User and Entities ....................39
+      4.4. Accounting Information ....................................39
+      4.5. Collection and Retention of Data and Identifiers ..........39
+      4.6. User Participation ........................................40
+   5. Security Considerations ........................................40
+   6. References .....................................................41
+      6.1. Normative References ......................................41
+      6.2. Informative References ....................................42
+   Acknowledgments ...................................................46
+   Authors' Addresses ................................................46
+
+
+
+
+
+
+
+Howlett, et al.               Informational                     [Page 3]
+
+RFC 7831                   ABFAB Architecture                   May 2016
+
+
+1.  Introduction
+
+   Numerous security mechanisms have been deployed on the Internet to
+   manage access to various resources.  These mechanisms have been
+   generalized and scaled over the last decade through mechanisms such
+   as the Simple Authentication and Security Layer (SASL) with the
+   Generic Security Server Application Program Interface (GSS-API)
+   (known as the GS2 family) [RFC5801]; the Security Assertion Markup
+   Language (SAML) [OASIS.saml-core-2.0-os]; and the Authentication,
+   Authorization, and Accounting (AAA) architecture as embodied in
+   RADIUS [RFC2865] and Diameter [RFC6733].
+
+   A Relying Party (RP) is the entity that manages access to some
+   resource.  The entity that is requesting access to that resource is
+   often described as the client.  Many security mechanisms are
+   manifested as an exchange of information between these entities.
+   The RP is therefore able to decide whether the client is authorized
+   or not.
+
+   Some security mechanisms allow the RP to delegate aspects of the
+   access management decision to an entity called the Identity Provider
+   (IdP).  This delegation requires technical signaling, trust, and a
+   common understanding of semantics between the RP and IdP.  These
+   aspects are generally managed within a relationship known as a
+   "federation".  This style of access management is accordingly
+   described as "federated access management".
+
+   Federated access management has evolved over the last decade through
+   specifications like SAML [OASIS.saml-core-2.0-os], OpenID
+   (http://www.openid.net), OAuth [RFC6749], and WS-Trust [WS-TRUST].
+   The benefits of federated access management include:
+
+   Single or simplified sign-on:
+
+      An Internet service can delegate access management, and the
+      associated responsibilities such as identity management and
+      credentialing, to an organization that already has a long-term
+      relationship with the client.  This is often attractive, as RPs
+      frequently do not want these responsibilities.  The client also
+      requires fewer credentials, which is also desirable.
+
+
+
+
+
+
+
+
+
+
+
+Howlett, et al.               Informational                     [Page 4]
+
+RFC 7831                   ABFAB Architecture                   May 2016
+
+
+   Data minimization and user participation:
+
+      Often, an RP does not need to know the identity of a client to
+      reach an access management decision.  It is frequently only
+      necessary for the RP to know specific attributes about the client
+      -- for example, that the client is affiliated with a particular
+      organization or has a certain role or entitlement.  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
+      will check configuration and policy to determine if the attributes
+      are to be released.  There is currently no direct client
+      participation in this decision.
+
+   Provisioning:
+
+      Sometimes, an RP needs, or would like, to know more about a client
+      than an affiliation or a pseudonym.  For example, an RP may want
+      the client's email address or name.  Some federated access
+      management technologies provide the ability for the IdP to supply
+      this information, either on request by the RP or unsolicited.
+
+   This memo describes the Application Bridging for Federated Access
+   Beyond web (ABFAB) architecture.  This architecture addresses the
+   problem of federated access management primarily for non-web-based
+   services.  This architecture makes use of extensions to the commonly
+   used security mechanisms for both federated and non-federated access
+   management, including RADIUS, the Generic Security Service (GSS), the
+   Extensible Authentication Protocol (EAP), and SAML.  The architecture
+   should be extended to use Diameter in the future.  It does so in a
+   manner that is designed to scale to large numbers of IdPs, RPs, and
+   federations.
+
+1.1.  Terminology
+
+   This document uses identity management and privacy terminology from
+   [RFC6973].  In particular, this document uses the terms
+   "identity provider", "relying party", "identifier", "pseudonymity",
+   "unlinkability", and "anonymity".
+
+   In this architecture, the IdP consists of the following components:
+   an EAP server, a RADIUS server, and, optionally, a SAML Assertion
+   service.
+
+   This document uses the term "Network Access Identifier" (NAI) as
+   defined in [RFC7542].  An NAI consists of a realm identifier, which
+   is associated with a AAA server, and thus an IdP and a username, that
+   are associated with a specific client of the IdP.
+
+
+
+Howlett, et al.               Informational                     [Page 5]
+
+RFC 7831                   ABFAB Architecture                   May 2016
+
+
+   One of the problems some people have found with reading this document
+   is that the terminology sometimes appears to be inconsistent.  This
+   is because the various standards that we refer to use different terms
+   for the same concept.  In general, this document uses either the
+   ABFAB term or the term associated with the standard under discussion,
+   as appropriate.  For reference, we include Table 1 below, which
+   provides a mapping for these different terms.  (Note that items
+   marked "N/A" (not applicable) indicate that there is no name that
+   represents the entity.)
+
+   +----------+-----------+--------------------+-----------------------+
+   | Protocol | Client    | Relying Party      | Identity Provider     |
+   +----------+-----------+--------------------+-----------------------+
+   | ABFAB    | N/A       | Relying Party (RP) | Identity Provider     |
+   |          |           |                    | (IdP)                 |
+   |          |           |                    |                       |
+   |          | Initiator | Acceptor           | N/A                   |
+   |          |           |                    |                       |
+   |          | Client    | Server             | N/A                   |
+   |          |           |                    |                       |
+   | SAML     | Subject   | Service provider   | Issuer                |
+   |          |           |                    |                       |
+   | GSS-API  | Initiator | Acceptor           | N/A                   |
+   |          |           |                    |                       |
+   | EAP      | EAP peer  | EAP authenticator  | EAP server            |
+   |          |           |                    |                       |
+   | AAA      | N/A       | AAA client         | AAA server            |
+   |          |           |                    |                       |
+   | RADIUS   | user      | NAS                | N/A                   |
+   |          |           |                    |                       |
+   |          | N/A       | RADIUS client      | RADIUS server         |
+   +----------+-----------+--------------------+-----------------------+
+
+                           Table 1: Terminology
+
+1.1.1.  Channel Binding
+
+   This document uses the term "channel binding" in two different
+   contexts; this term has a different meaning in each of these
+   contexts.
+
+   EAP channel binding is used to implement GSS-API naming semantics.
+   EAP channel binding sends a set of attributes from the peer to the
+   EAP server either as part of the EAP conversation or as part of a
+   secure association protocol.  In addition, attributes are sent in the
+   back-end protocol from the EAP authenticator to the EAP server.  The
+
+
+
+
+
+Howlett, et al.               Informational                     [Page 6]
+
+RFC 7831                   ABFAB Architecture                   May 2016
+
+
+   EAP server confirms the consistency of these attributes and provides
+   the confirmation back to the peer.  In this document, channel binding
+   without qualification refers to EAP channel binding.
+
+   GSS-API channel binding provides protection against man-in-the-middle
+   attacks when GSS-API is used for authentication inside of some
+   tunnel; it is similar to a facility called "cryptographic binding" in
+   EAP.  The binding works by each side deriving a cryptographic value
+   from the tunnel itself and then using that cryptographic value to
+   prove to the other side that it knows the value.
+
+   See [RFC5056] for a discussion of the differences between these two
+   facilities.  These differences can be summarized as follows:
+
+   o  GSS-API channel binding specifies that there is nobody between the
+      client and the EAP authenticator.
+
+   o  EAP channel binding allows the client to have knowledge of such
+      EAP authenticator attributes as the EAP authenticator's name.
+
+   Typically, when considering both EAP and GSS-API channel binding,
+   people think of channel binding in combination with mutual
+   authentication.  This is sufficiently common that, without additional
+   qualification, channel binding should be assumed to imply mutual
+   authentication.  In GSS-API, without mutual authentication, only the
+   acceptor has authenticated the initiator.  Similarly, in EAP, only
+   the EAP server has authenticated the peer.  Sometimes, one-way
+   authentication is useful.  Consider, for example, a user who wishes
+   to access a protected resource for a shared whiteboard in a
+   conference room.  The whiteboard is the acceptor; it knows that the
+   initiator is authorized to give it a presentation, and the user can
+   validate that the whiteboard got the correct presentation by visual
+   means.  (The presentation should not be confidential in this case.)
+   If channel binding is used without mutual authentication, it is
+   effectively a request to disclose the resource in the context of a
+   particular channel.  Such an authentication would be similar in
+   concept to a holder-of-key SAML Assertion.  However, note also that
+   although it is not happening in the protocol, mutual authentication
+   is happening in the overall system: the user is able to visually
+   authenticate the content.  This is consistent with all uses of
+   channel binding without protocol-level mutual authentication found
+   so far.
+
+
+
+
+
+
+
+
+
+Howlett, et al.               Informational                     [Page 7]
+
+RFC 7831                   ABFAB Architecture                   May 2016
+
+
+1.2.  An Overview of Federation
+
+   In the previous section, we introduced the following entities:
+
+   o  the client,
+
+   o  the IdP, and
+
+   o  the RP.
+
+   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
+   situation, an Individual may or may not exist.  Clients can act as
+   front ends for Individuals, or clients may be independent entities
+   that are set up and allowed to run autonomously.  An example of such
+   an independent entity can be found in the Trust Router Protocol
+   (https://www.ietf.org/proceedings/86/slides/slides-86-rtgarea-0.pdf),
+   where the routers use ABFAB to authenticate to each other.
+
+   These entities and their relationships are illustrated graphically in
+   Figure 1.
+
+             ,----------\                        ,---------\
+             | Identity |       Federation       | Relying |
+             | Provider + <--------------------> + Party   |
+             `----------'                        '---------'
+                    <
+                     \
+                      \ Authentication
+                       \
+                        \
+                         \
+                          \
+                           \  +---------+
+                            \ |         |  O
+                             v| Client  | \|/ Individual
+                              |         |  |
+                              +---------+ / \
+
+                Figure 1: Entities and Their Relationships
+
+
+
+
+
+
+
+
+
+
+
+Howlett, et al.               Informational                     [Page 8]
+
+RFC 7831                   ABFAB Architecture                   May 2016
+
+
+   The relationships between the entities in Figure 1 are as follows:
+
+   Federation
+
+      The IdP and the RPs are part of a federation.  The relationship
+      may be direct (they have an explicit trust relationship) or
+      transitive (the trust relationship is mediated by one or more
+      entities).  The federation relationship is governed by a
+      federation agreement.  Within a single federation, there may be
+      multiple IdPs as well as multiple RPs.
+
+   Authentication
+
+      There is a direct relationship between the client and the IdP.
+      This relationship provides the means by which they trust each
+      other and can securely authenticate each other.
+
+   A federation agreement typically encompasses operational
+   specifications and legal rules:
+
+   Operational Specifications:
+
+      The goal of operational specifications is to provide enough
+      definition that the system works and interoperability is possible.
+      These include the technical specifications (e.g., protocols used
+      to communicate between the three parties), process standards,
+      policies, identity proofing, credential and authentication
+      algorithm requirements, performance requirements, assessment and
+      audit criteria, etc.
+
+   Legal Rules:
+
+      The legal rules take the legal framework into consideration and
+      provide contractual obligations for each entity.  The rules define
+      the responsibilities of each party and provide further
+      clarification of the operational specifications.  These legal
+      rules regulate the operational specifications, make operational
+      specifications legally binding to the participants, and define and
+      govern the rights and responsibilities of the participants.  The
+      legal rules may, for example, describe liability for losses,
+      termination rights, enforcement mechanisms, measures of damage,
+      dispute resolution, warranties, etc.
+
+
+
+
+
+
+
+
+
+Howlett, et al.               Informational                     [Page 9]
+
+RFC 7831                   ABFAB Architecture                   May 2016
+
+
+   The operational specifications can demand the usage of a specific
+   technical infrastructure, including requirements on the message
+   routing intermediaries, to offer the required technical
+   functionality.  In other environments, the operational specifications
+   require fewer technical components in order to meet the required
+   technical functionality.
+
+   The legal rules include many non-technical aspects of federation,
+   such as business practices and legal arrangements, which are outside
+   the scope of the IETF.  The legal rules can still have an impact on
+   the architectural setup or on how to ensure the dynamic establishment
+   of trust.
+
+   While a federation agreement is often discussed within the context of
+   formal relationships, such as between an enterprise and an employee
+   or between a government and a citizen, a federation agreement does
+   not have to require any particular level of formality.  For an IdP
+   and a client, it is sufficient for a relationship to be established
+   by something as simple as using a web form and confirmation email.
+   For an IdP and an RP, it is sufficient for the IdP to publish contact
+   information along with a public key and for the RP to use that data.
+   Within the framework of ABFAB, it will generally be required that a
+   mechanism exist for the IdP to be able to trust the identity of the
+   RP; if this is not present, then the IdP cannot provide the
+   assurances to the client that the identity of the RP has been
+   established.
+
+   The nature of federation dictates that there exists some form of
+   relationship between the IdP and the RP.  This is particularly
+   important when the RP wants to use information obtained from the IdP
+   for access management decisions and when the IdP does not want to
+   release information to every RP (or only under certain conditions).
+
+   While it is possible to have a bilateral agreement between every IdP
+   and every RP, on an Internet scale, this setup requires the
+   introduction of the multilateral federation concept, as the
+   management of such pair-wise relationships would otherwise prove
+   burdensome.
+
+   The IdP will typically have a long-term relationship with the client.
+   This relationship typically involves the IdP positively identifying
+   and credentialing the client (for example, at the time of employment
+   within an organization).  When dealing with Individuals, this process
+   is called "identity proofing" [NIST-SP.800-63-2].  The relationship
+   will often be instantiated within an agreement between the IdP and
+   the client (for example, within an employment contract or terms of
+   use that stipulate the appropriate use of credentials and so forth).
+
+
+
+
+Howlett, et al.               Informational                    [Page 10]
+
+RFC 7831                   ABFAB Architecture                   May 2016
+
+
+   The nature and quality of the relationship between the client and the
+   IdP are important contributors to the level of trust that an RP may
+   assign to an assertion describing a client made by an IdP.  This is
+   sometimes described as the level of assurance [NIST-SP.800-63-2].
+
+   Federation does not require an a priori relationship or a long-term
+   relationship between the RP and the client; it is this property of
+   federation that yields many of its benefits.  However, federation
+   does not preclude the possibility of a pre-existing relationship
+   between the RP and the client or the possibility that the RP and
+   client may use the introduction to create a new long-term
+   relationship independent of the federation.
+
+   Finally, it is important to reiterate that in some scenarios there
+   might indeed be an Individual behind the client and in other cases
+   the client may be autonomous.
+
+1.3.  Challenges for Contemporary Federation
+
+   As federated IdPs and RPs (services) proliferate, the role of an
+   Individual can become ambiguous in certain circumstances.  For
+   example, a school might provide online access for a student's grades
+   to their parents for review and to the student's teacher for
+   modification.  A teacher who is also a parent must clearly
+   distinguish their role upon access.
+
+   Similarly, as federations proliferate, it becomes increasingly
+   difficult to discover which IdP(s) a user 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 authentication systems are not
+   semantically rich enough on their own to allow for such ambiguities.
+   For instance, in the case of an email provider, SMTP and IMAP do not
+   have the ability for the server to request information from the
+   client, beyond the client NAI, that the server would then use to
+   decide between the multiple federations it is associated with.
+   However, the building blocks do exist to add this functionality.
+
+1.4.  An Overview of ABFAB-Based Federation
+
+   The previous section described the general model of federation and
+   the application of access management within the federation.  This
+   section provides a brief overview of ABFAB in the context of this
+   model.
+
+
+
+
+
+
+
+
+Howlett, et al.               Informational                    [Page 11]
+
+RFC 7831                   ABFAB Architecture                   May 2016
+
+
+   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
+   transaction.  In order for the client to mutually authenticate with
+   the server, the following steps are taken in an ABFAB architecture (a
+   graphical view of the steps can be found in Figure 2):
+
+   1.   Client configuration: The client is configured with an NAI
+        assigned by the IdP.  It is also configured with any keys,
+        certificates, passwords, or other secret and public information
+        needed to run the EAP protocols between it and the IdP.
+
+   2.   Authentication mechanism selection: The client is configured to
+        use the GSS-EAP GSS-API mechanism for authentication/
+        authorization.
+
+   3.   Client provides an NAI to RP: The client sets up a transport to
+        the RP and begins GSS-EAP authentication.  In response, the RP
+        sends an EAP request message (nested in GSS-EAP) asking for the
+        client's name.  The client sends an EAP response with an NAI
+        name form that, at a minimum, contains the realm portion of its
+        full NAI.
+
+   4.   Discovery of federated IdP: The RP uses preconfigured
+        information or a federation proxy to determine what IdP to use,
+        based on policy and the realm portion of the provided client
+        NAI.  This is discussed in detail below (Section 2.1.2).
+
+   5.   Request from RP to IdP: Once the RP knows who the IdP is, it (or
+        its agent) will send a RADIUS request to the IdP.  The RADIUS
+        Access-Request encapsulates the EAP 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 attributes, and it may send a
+        SAML request in a AAA attribute.  The AAA network checks to see
+        that the identity claimed by the RP is valid.
+
+   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
+        re-request the client's name in this message, but clients need
+        to 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 available and appropriate methods are discussed below
+        (Section 2.2.1).
+
+   7.   EAP is run: A bunch of EAP messages are passed between the
+        client (EAP peer) and the IdP (EAP server), until the result of
+        the authentication protocol is determined.  The number and
+        content of those messages depend on the EAP method selected.  If
+        the IdP is unable to authenticate the client, the IdP sends an
+
+
+
+Howlett, et al.               Informational                    [Page 12]
+
+RFC 7831                   ABFAB Architecture                   May 2016
+
+
+        EAP failure message to the RP.  As part of the EAP method, the
+        client sends an EAP channel-binding message to the IdP
+        (Section 2.2.2).  In the channel-binding message, the client
+        identifies, among other things, the RP to which it is attempting
+        to authenticate.  The IdP checks the channel-binding data from
+        the client against the data provided by the RP via the AAA
+        protocol.  If the bindings do not match, the IdP sends an EAP
+        failure message to the RP.
+
+   8.   Successful EAP authentication: At this point, the IdP (EAP
+        server) and client (EAP peer) have mutually authenticated each
+        other.  As a result, the client and the IdP hold two
+        cryptographic keys: a Master Session Key (MSK) and an Extended
+        MSK (EMSK).  At this point, the client has a level of assurance
+        regarding the identity of the RP, based on the name checking the
+        IdP has done, using the RP naming information from the AAA
+        framework and from the client (by the channel-binding data).
+
+   9.   Local IdP policy check: At this stage, the IdP checks local
+        policy to determine whether the RP and client are authorized for
+        a given transaction/service and, if so, what attributes, if any,
+        will be released to the RP.  If the IdP gets a policy failure,
+        it sends an EAP failure message to the RP and client.  (The RP
+        will have done its policy checks during the discovery process.)
+
+   10.  IdP provides the RP with the MSK: The IdP sends a success result
+        EAP to the RP, along with an optional set of AAA attributes
+        associated with the client (usually as one or more SAML
+        Assertions).  In addition, the EAP MSK is returned to the RP.
+
+   11.  RP processes results: When the RP receives the result from the
+        IdP, it should have enough information to either grant or refuse
+        a resource Access-Request.  It may have information that
+        associates the client with specific authorization identities.
+        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 an application-specific way.
+
+   12.  RP returns results to client: Once the RP has a response, it
+        must inform the client of the result.  If all has gone well, all
+        are authenticated, and the application proceeds with appropriate
+        authorization levels.  The client can now complete the
+        authentication of the RP by using the EAP MSK value.
+
+
+
+
+
+
+
+
+Howlett, et al.               Informational                    [Page 13]
+
+RFC 7831                   ABFAB Architecture                   May 2016
+
+
+        Relying         Client         Identity
+        Party                          Provider
+
+        |              (1)             | Client configuration
+        |               |              |
+        |<-----(2)----->|              | Mechanism selection
+        |               |              |
+        |<-----(3)-----<|              | NAI transmitted to RP
+        |               |              |
+        |<=====(4)====================>| IdP Discovery
+        |               |              |
+        |>=====(5)====================>| Access-Request from RP to IdP
+        |               |              |
+        |               |< - - (6) - -<| EAP method to client
+        |               |              |
+        |               |< - - (7) - ->| EAP exchange to authenticate
+        |               |              | client
+        |               |              |
+        |               |           (8 & 9) Local policy check
+        |               |              |
+        |<====(10)====================<| Results to RP
+        |               |              |
+      (11)              |              | RP processes results
+        |               |              |
+        |>----(12)----->|              | Results to client
+
+        Legend:
+
+          -----: Between client and RP
+          =====: Between RP and IdP
+          - - -: Between client and IdP (via RP)
+
+                   Figure 2: ABFAB Authentication Steps
+
+1.5.  Design Goals
+
+   Our key design goals are as follows:
+
+   o  Each party in a transaction will be authenticated, although
+      perhaps not identified, and the client will be authorized for
+      access to a specific resource.
+
+   o  The means of authentication is decoupled from the application
+      protocol 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
+      between clients and RPs.
+
+
+
+Howlett, et al.               Informational                    [Page 14]
+
+RFC 7831                   ABFAB Architecture                   May 2016
+
+
+   o  The system will scale to large numbers of IdPs, RPs, and users.
+
+   o  The system will be designed primarily for non-web-based
+      authentication.
+
+   o  The system will build upon existing standards, components, and
+      operational practices.
+
+   Designing new three-party authentication and authorization protocols
+   is difficult and fraught with the risk of cryptographic flaws.
+   Achieving widespread deployment is even more difficult.  A lot of
+   attention on federated access has been devoted to the web.  This
+   document instead focuses on a non-web-based environment and focuses
+   on those protocols where HTTP is not used.  Despite the growing trend
+   to layer every protocol on top of HTTP, there are still a number of
+   protocols available that do not use HTTP-based transports.  Many of
+   these protocols are lacking a native authentication and authorization
+   framework of the style shown in Figure 1.
+
+2.  Architecture
+
+   We have already introduced the federated access architecture, with
+   the illustration of the different actors that need to interact.  This
+   section expands on the specifics of providing support for
+   non-web-based applications and provides motivations for design
+   decisions.  The main theme of the work described in this document is
+   focused on reusing existing building blocks that have been deployed
+   already and to rearrange them in a novel way.
+
+   Although this architecture assumes updates to the RP, the client, and
+   the IdP, those changes are kept at a minimum.  A mechanism that can
+   demonstrate deployment benefits (based on ease of updates to existing
+   software, low implementation effort, etc.) is preferred, and there
+   may be a need to specify multiple mechanisms to support the range of
+   different deployment scenarios.
+
+   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
+   application protocols, GSS-API was chosen.  The technical
+   specification of GSS-EAP can be found in [RFC7055].
+
+   The architecture consists of several building blocks, as shown
+   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, and some of the trade-offs made in choosing the protocols.
+
+
+
+
+
+
+Howlett, et al.               Informational                    [Page 15]
+
+RFC 7831                   ABFAB Architecture                   May 2016
+
+
+                                    +--------------+
+                                    |   Identity   |
+                                    |   Provider   |
+                                    |    (IdP)     |
+                                    +-^----------^-+
+                                      * EAP      o RADIUS
+                                      *          o
+                                    --v----------v--
+                                 ///                \\\
+                               //                      \\
+                              |        Federation        |
+                              |        Substrate         |
+                               \\                      //
+                                 \\\                ///
+                                    --^----------^--
+                                      * EAP      o RADIUS
+                                      *          o
+   +-------------+                  +-v----------v--+
+   |             |                  |               |
+   | Client      |  EAP/EAP Method  | Relying Party |
+   | Application |<****************>|     (RP)      |
+   |             |  GSS-API         |               |
+   |             |<---------------->|               |
+   |             |  Application     |               |
+   |             |  Protocol        |               |
+   |             |<================>|               |
+   +-------------+                  +---------------+
+
+   Legend:
+
+     <****>: Client-to-IdP Exchange
+     <---->: Client-to-RP Exchange
+     <oooo>: RP-to-IdP Exchange
+     <====>: Protocol through which GSS-API/GS2 exchanges are tunneled
+
+                  Figure 3: ABFAB Protocol Instantiation
+
+2.1.  Relying Party to Identity Provider
+
+   Communication between the RP and the IdP is done by the Federation
+   Substrate.  This communication channel is responsible for:
+
+   o  Establishing the trust relationship between the RP and the IdP.
+
+   o  Determining the rules governing the relationship.
+
+   o  Conveying authentication packets from the client to the IdP
+      and back.
+
+
+
+Howlett, et al.               Informational                    [Page 16]
+
+RFC 7831                   ABFAB Architecture                   May 2016
+
+
+   o  Providing the means of establishing a trust relationship between
+      the RP and the client.
+
+   o  Providing a means for the RP to obtain attributes about the client
+      from the IdP.
+
+   The ABFAB working group has chosen the AAA framework for the messages
+   transported between the RP and IdP.  The AAA framework supports the
+   requirements stated above, as follows:
+
+   o  The AAA backbone supplies the trust relationship between the RP
+      and the IdP.
+
+   o  The agreements governing a specific AAA backbone contain the rules
+      governing the relationships within the AAA federation.
+
+   o  A method exists for carrying EAP packets within RADIUS [RFC3579]
+      and Diameter [RFC4072].
+
+   o  The use of EAP channel binding [RFC6677] along with the core ABFAB
+      protocol provide the pieces necessary to establish the identities
+      of the RP and the client, while EAP provides the cryptographic
+      methods for the RP and the client to validate that they are
+      talking to each other.
+
+   o  A method exists for carrying SAML packets within RADIUS [RFC7833];
+      this method allows the RP to query attributes about the client
+      from the IdP.
+
+   Protocols that support the same framework but do different routing
+   are expected to be defined and used in the future.  One such effort,
+   called the Trust Router, is to set up a framework that creates a
+   trusted point-to-point channel on the fly
+   (https://www.ietf.org/proceedings/86/slides/slides-86-rtgarea-0.pdf).
+
+2.1.1.  AAA, RADIUS, and Diameter
+
+   The usage of the AAA framework with RADIUS [RFC2865] and Diameter
+   [RFC6733] for network access authentication has been successful from
+   a deployment point of view.  To map the terminology used in Figure 1
+   to the AAA framework, the IdP corresponds to the AAA server; the RP
+   corresponds to the AAA client; and the technical building blocks of a
+   federation are AAA proxies, relays, and redirect agents (particularly
+   if they are operated by third parties, such as AAA brokers and
+   clearinghouses).  In the case of network access authentication, the
+   front end, i.e., the communication path between the end host and the
+   AAA client, is offered by link-layer protocols that forward
+
+
+
+
+Howlett, et al.               Informational                    [Page 17]
+
+RFC 7831                   ABFAB Architecture                   May 2016
+
+
+   authentication protocol exchanges back and forth.  An example of a
+   large-scale RADIUS-based federation is eduroam
+   (https://www.eduroam.org).
+
+   By using the AAA framework, ABFAB can be built on the federation
+   agreements that already exist; the agreements can then merely be
+   expanded to cover the ABFAB architecture.  The AAA framework has
+   already addressed some of the problems outlined above.  For example,
+
+   o  It already has a method for routing requests based on a domain.
+
+   o  It already has an extensible architecture allowing for new
+      attributes to be defined and transported.
+
+   o  Pre-existing relationships can be reused.
+
+   The astute reader will notice that RADIUS and Diameter have
+   substantially similar characteristics.  Why not pick one?  RADIUS and
+   Diameter are deployed in different environments.  RADIUS can often be
+   found in enterprise and university networks; RADIUS is also used by
+   operators of fixed networks.  Diameter, on the other hand, is
+   deployed by operators of mobile networks.  Another key difference is
+   that today RADIUS is largely transported over UDP.  The decision
+   regarding which protocol will be appropriate to deploy is left to
+   implementers.  The protocol defines all the necessary new AAA
+   attributes as RADIUS attributes.  A future document could define the
+   same AAA attributes for a Diameter environment.  We also note that
+   there exist proxies that convert from RADIUS to Diameter and back.
+   This makes it possible for both to be deployed in a single Federation
+   Substrate.
+
+   Through the integrity-protection mechanisms in the AAA framework, the
+   IdP can establish technical trust that messages are being sent by the
+   appropriate RP.  Any given interaction will be associated with one
+   federation at the policy level.  The legal or business relationship
+   defines what statements the IdP is trusted to make and how these
+   statements are interpreted by the RP.  The AAA framework also permits
+   the RP or elements between the RP and IdP to make statements about
+   the RP.
+
+   The AAA framework provides transport for attributes.  Statements made
+   about the client by the IdP, statements made about the RP, and other
+   information are transported as attributes.
+
+   One demand that the AAA substrate makes of the upper layers is that
+   they must properly identify the endpoints of the communication.  It
+   must be possible for the AAA client at the RP to determine where to
+   send each RADIUS or Diameter message.  Without this requirement, it
+
+
+
+Howlett, et al.               Informational                    [Page 18]
+
+RFC 7831                   ABFAB Architecture                   May 2016
+
+
+   would be the RP's responsibility to determine the identity of the
+   client on its own, without the assistance of an IdP.  This
+   architecture makes use of the Network Access Identifier (NAI), where
+   the IdP is indicated by the realm component [RFC7542].  The NAI is
+   represented and consumed by the GSS-API layer as GSS_C_NT_USER_NAME,
+   as specified in [RFC2743].  The GSS-API EAP mechanism includes the
+   NAI in the EAP Response/Identity message.
+
+   At the time of this writing, no profiles for the use of Diameter have
+   been created.
+
+2.1.2.  Discovery and Rules Determination
+
+   While we are using the AAA protocols to communicate with the IdP, the
+   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
+   different federations to use.  The federation selected must
+
+   o  be able to communicate with the IdP.
+
+   o  match the business rules and technical policies required for the
+      RP security requirements.
+
+   The RP needs to discover which federation will be used to contact the
+   IdP.  The first selection criterion used during discovery is going to
+   be the name of the IdP to be contacted.  The second selection
+   criterion used during discovery is going to be the set of business
+   rules and technical policies governing the relationship; this is
+   called "rules determination".  The RP also needs to establish
+   technical trust in the communications with the IdP.
+
+   Rules determination covers a broad range of decisions about the
+   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
+   encompasses the basic authorization decision.  Other factors are
+   included, such as what policies govern release of information about
+   the client to the RP and what policies govern the RP's use of this
+   information.  While rules determination is ultimately a business
+   function, it has a significant impact on the technical exchanges.
+   The protocols need to communicate the result of authorization.  When
+   multiple sets of rules are possible, the protocol must disambiguate
+   which set of rules are in play.  Some rules have technical
+   enforcement mechanisms; for example, in some federations,
+   intermediaries validate information that is being communicated within
+   the federation.
+
+
+
+
+
+
+Howlett, et al.               Informational                    [Page 19]
+
+RFC 7831                   ABFAB Architecture                   May 2016
+
+
+   At the time of this writing, no protocol mechanism has been specified
+   to allow a AAA client to determine whether a AAA proxy will indeed be
+   able to route AAA requests to a specific IdP.  The AAA routing is
+   impacted by business rules and technical policies that may be quite
+   complex; at the present time, the route selection is based on manual
+   configuration.
+
+2.1.3.  Routing and Technical Trust
+
+   Several approaches to having messages routed through the Federation
+   Substrate are possible.  These routing methods can most easily be
+   classified based on the mechanism for technical trust that is used.
+   The choice of technical trust mechanism constrains how rules
+   determination is implemented.  Regardless of what deployment strategy
+   is chosen, it is important that the technical trust mechanism be able
+   to validate the identities of both parties to the exchange.  The
+   trust mechanism must ensure that the entity acting as the IdP for a
+   given NAI is permitted to be the IdP for that realm and that any
+   service name claimed by the RP is permitted to be claimed by that
+   entity.  Here are the categories of technical trust determination:
+
+   AAA Proxy:
+      The simplest model is that an RP is a AAA client and can send the
+      request directly to a AAA proxy.  The hop-by-hop integrity
+      protection of the AAA fabric provides technical trust.  An RP can
+      submit a request directly to the correct federation.
+      Alternatively, a federation disambiguation fabric can be used.
+      Such a fabric takes information about what federations the RP is
+      part of and what federations the IdP is part of, and it routes a
+      message to the appropriate federation.  The routing of messages
+      across the fabric, plus attributes added to requests and
+      responses, together provide rules determination.  For example,
+      when a disambiguation fabric routes a message to a given
+      federation, that federation's rules are chosen.  Name validation
+      is enforced as messages travel across the fabric.  The entities
+      near the RP confirm its identity and validate names it claims.
+      The fabric routes the message towards the appropriate IdP,
+      validating the name of the IdP in the process.  The routing can be
+      statically configured.  Alternatively, a routing protocol could be
+      developed to exchange reachability information about a given IdP
+      and to apply policy across the AAA fabric.  Such a routing
+      protocol could flood naming constraints to the appropriate points
+      in the fabric.
+
+
+
+
+
+
+
+
+Howlett, et al.               Informational                    [Page 20]
+
+RFC 7831                   ABFAB Architecture                   May 2016
+
+
+   Trust Broker:
+      Instead of routing messages through AAA proxies, some trust broker
+      could establish keys between entities near the RP and entities
+      near the IdP.  The advantage of this approach is efficiency of
+      message handling.  Fewer entities are needed to be involved for
+      each message.  Security may be improved by sending individual
+      messages over fewer hops.  Rules determination involves decisions
+      made by trust brokers about what keys to grant.  Also, associated
+      with each credential is context about rules and about other
+      aspects of technical trust, including names that may be claimed.
+      A routing protocol similar to the one for AAA proxies is likely to
+      be useful to trust brokers in flooding rules and naming
+      constraints.
+
+   Global Credential:
+      A global credential such as a public key and certificate in a
+      public key infrastructure can be used to establish technical
+      trust.  A directory or distributed database such as the Domain
+      Name System is used by the RP to discover the endpoint to contact
+      for a given NAI.  Either the database or certificates can provide
+      a place to store information about rules determination and naming
+      constraints.  Provided that no intermediates are required (or
+      appear to be required) and that the RP and IdP are sufficient to
+      enforce and determine rules, rules determination is reasonably
+      simple.  However, applying certain rules is likely to be quite
+      complex.  For example, if multiple sets of rules are possible
+      between an IdP and RP, confirming that the correct set is used may
+      be difficult.  This is particularly true if intermediates are
+      involved in making the decision.  Also, to the extent that
+      directory information needs to be trusted, rules determination may
+      be more complex.
+
+   Real-world deployments are likely to be mixtures of these basic
+   approaches.  For example, it will be quite common for an RP to route
+   traffic to a AAA proxy within an organization.  That proxy could then
+   use any of the above three methods to get closer to the IdP.  It is
+   also likely that, rather than being directly reachable, the IdP may
+   have a proxy on the edge of its organization.  Federations will
+   likely provide a traditional AAA proxy interface even if they also
+   provide another mechanism for increased efficiency or security.
+
+2.1.4.  AAA Security
+
+   For the AAA framework, there are two different places where security
+   needs to be examined.  The first is the security that is in place for
+   the links in the AAA backbone being used.  The second are the nodes
+   that form the AAA backbone.
+
+
+
+
+Howlett, et al.               Informational                    [Page 21]
+
+RFC 7831                   ABFAB Architecture                   May 2016
+
+
+   The default link security for RADIUS is showing its age, as it uses
+   MD5 and a shared secret to both obfuscate passwords and provide
+   integrity on the RADIUS messages.  While some EAP methods include the
+   ability to protect the client authentication credentials, the MSK
+   returned from the IdP to the RP is protected only by RADIUS security.
+   In many environments, this is considered to be insufficient,
+   especially as not all attributes are obfuscated and can thus leak
+   information to a passive eavesdropper.  The use of RADIUS with
+   Transport Layer Security (TLS) [RFC6614] and/or Datagram Transport
+   Layer Security (DTLS) [RFC7360] addresses these attacks.  The same
+   level of security is included in the base Diameter specifications.
+
+2.1.5.  SAML Assertions
+
+   For the traditional use of AAA frameworks, i.e., granting access to a
+   network, an affirmative response from the IdP is sufficient.  In the
+   ABFAB world, the RP may need to get significantly more additional
+   information about the client before granting access.  ABFAB therefore
+   has a requirement that it can transport an arbitrary set of
+   attributes about the client from the IdP to the RP.
+
+   The Security Assertion Markup Language (SAML)
+   [OASIS.saml-core-2.0-os] was designed in order to carry an extensible
+   set of attributes about a subject.  Since SAML is extensible in the
+   attribute space, ABFAB 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 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 profile can be found in [RFC7833].  As
+   SAML statements will frequently be large, RADIUS servers and clients
+   that deal with SAML statements will need to implement [RFC7499].
+
+   There are several issues that need to be highlighted:
+
+   o  The security of SAML Assertions.
+
+   o  Namespaces and mapping of SAML attributes.
+
+   o  Subject naming of entities.
+
+   o  Making multiple queries about the subject(s).
+
+   o  Level of assurance for authentication.
+
+   SAML Assertions have an optional signature that can be used to
+   protect and provide the origination of the assertion.  These
+   signatures are normally based on asymmetric key operations and
+   require that the verifier be able to check not only the cryptographic
+
+
+
+Howlett, et al.               Informational                    [Page 22]
+
+RFC 7831                   ABFAB Architecture                   May 2016
+
+
+   operation but also the binding of the originator's name and the
+   public key.  In a federated environment, it will not always be
+   possible for the RP to validate the binding; for this reason, the
+   technical trust established in the federation is used as an alternate
+   method of validating the origination and integrity of the SAML
+   Assertion.
+
+   Attributes in a SAML Assertion are identified by a name string.  The
+   name string is either assigned by the SAML issuer context or scoped
+   by a namespace (for example, a URI or object identifier (OID)).  This
+   means that the same attribute can have different name strings used to
+   identify it.  In many cases, but not all, the federation agreements
+   will determine what attributes and names can be used in a SAML
+   statement.  This means that the RP needs to map from the SAML issuer
+   or federation name, type, and semantic to the name, type, and
+   semantics that the policies of the RP are written in.  In other
+   cases, the Federation Substrate, in the form of proxies, will modify
+   the SAML Assertions in transit to do the necessary name, type, and
+   value 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 Assertion, as changing the content
+   of the SAML Assertion 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 originating IdP.  When this occurs, the RP will need
+   to get the required mapping operations from the federation agreements
+   and do the appropriate mappings itself.
+
+   [RFC7833] has defined a new SAML name format that corresponds to the
+   NAI name form defined by [RFC7542].  This allows for easy name
+   matching in many 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 form, [RFC7833] also defines a pair of
+   implicit name forms corresponding to the client and the client's
+   machine.  These implicit name forms are based on the Identity-Type
+   enumeration defined in the Tunnel Extensible Authentication Protocol
+   (TEAP) specification [RFC7170].  If the name form returned in a SAML
+   statement is not based on the NAI, then it is a requirement on the
+   EAP server that it validate that the subject of the SAML Assertion,
+   if any, is equivalent to the subject identified by the NAI used in
+   the RADIUS or Diameter session.
+
+   RADIUS has the ability to deal with multiple SAML queries for those
+   EAP servers that follow [RFC5080].  In this case, a State attribute
+   will always be returned with the Access-Accept.  The EAP client can
+   then send a new Access-Request with the State attribute and the new
+
+
+
+Howlett, et al.               Informational                    [Page 23]
+
+RFC 7831                   ABFAB Architecture                   May 2016
+
+
+   SAML request.  Multiple SAML queries can then be done by making a new
+   Access-Request, using the State attribute returned in the last
+   Access-Accept to link together the different RADIUS sessions.
+
+   Some RPs need to ensure that specific criteria are met during the
+   authentication process.  This need is met by using levels of
+   assurance.  A level of assurance is communicated to the RP from the
+   EAP server by using a SAML Authentication Request, using the
+   Authentication Profile described in [RFC7833].  When crossing
+   boundaries between different federations, (1) the policy specified
+   will need to be shared between the two federations, (2) the policy
+   will need to be mapped by the proxy server on the boundary, or
+   (3) the proxy server on the boundary will need to supply information
+   to the EAP server so that the EAP server can do the required mapping.
+   If this mapping is not done, then the EAP server will not be able to
+   enforce the desired level of assurance, as it will not understand the
+   policy requirements.
+
+2.2.  Client to Identity Provider
+
+   Looking at the communications between the client and the IdP, the
+   following items need to be dealt with:
+
+   o  The client and the IdP need to mutually authenticate each other.
+
+   o  The client and the IdP need to mutually agree on the identity of
+      the RP.
+
+   ABFAB selected EAP for the purposes of mutual authentication and
+   assisted in creating some new EAP channel-binding documents for
+   dealing with determining the identity of the RP.  A framework for the
+   channel-binding mechanism has been defined in [RFC6677] that allows
+   the IdP to check the identity of the RP provided by the AAA framework
+   against the identity provided by the client.
+
+2.2.1.  Extensible Authentication Protocol (EAP)
+
+   Traditional web federation does not describe how a client interacts
+   with an IdP for authentication.  As a result, this communication is
+   not standardized.  There are several disadvantages to this approach.
+   Since the communication is not standardized, it is difficult for
+   machines to recognize which entity is going to do the authentication,
+   and thus which credentials to use and where in the authentication
+   form the credentials are to be entered.  It is much easier for humans
+   to correctly deal with these problems.  The use of browsers for
+   authentication restricts the deployment of more secure forms of
+   authentication beyond plaintext usernames and passwords known by the
+   server.  In a number of cases, the authentication interface may be
+
+
+
+Howlett, et al.               Informational                    [Page 24]
+
+RFC 7831                   ABFAB Architecture                   May 2016
+
+
+   presented before the client has adequately validated that they are
+   talking to the intended server.  By giving control of the
+   authentication interface to a potential attacker, the security of the
+   system may be reduced, and opportunities for phishing may be
+   introduced.
+
+   As a result, it is desirable to choose some standardized approach for
+   communication between the client's end host and the IdP.  There are a
+   number of requirements this approach must meet, as noted below.
+
+   Experience has taught us one key security and scalability
+   requirement: it is important that the RP not get possession of the
+   long-term secret of the client.  Aside from a valuable secret being
+   exposed, a synchronization problem can develop when the client
+   changes keys with the IdP.
+
+   Since there is no single authentication mechanism that will be used
+   everywhere, another associated requirement is that the authentication
+   framework must allow for the flexible integration of authentication
+   mechanisms.  For instance, some IdPs require hardware tokens, while
+   others use passwords.  A service provider wants to provide support
+   for both authentication methods and also for other methods from IdPs
+   not yet seen.
+
+   These requirements can be met by utilizing standardized and
+   successfully deployed technology, namely the EAP framework [RFC3748].
+   Figure 3 illustrates the integration graphically.
+
+   EAP is an end-to-end framework; it provides for two-way communication
+   between a peer (i.e., client or Individual) through the EAP
+   authenticator (i.e., RP) to the back end (i.e., IdP).  This is
+   precisely -- and conveniently -- the communication path that is
+   needed for federated identity.  Although EAP support is already
+   integrated in AAA systems (see [RFC3579] and [RFC4072]), several
+   challenges remain:
+
+   o  The first is how to carry EAP payloads from the end host to
+      the RP.
+
+   o  Another is to verify statements the RP has made to the client,
+      confirm that these statements are consistent with statements made
+      to the IdP, and confirm that all of the above are consistent with
+      the federation and any federation-specific policy or
+      configuration.
+
+   o  Another challenge is choosing which IdP to use for which service.
+
+
+
+
+
+Howlett, et al.               Informational                    [Page 25]
+
+RFC 7831                   ABFAB Architecture                   May 2016
+
+
+   The EAP method used for ABFAB needs to meet the following
+   requirements:
+
+   o  It needs to provide mutual authentication of the client and IdP.
+
+   o  It needs to support channel binding.
+
+   As of this writing, the only EAP method that meets these criteria is
+   TEAP [RFC7170], either alone (if client certificates are used) or
+   with an inner EAP method that does mutual authentication.
+
+2.2.2.  EAP Channel Binding
+
+   EAP channel binding is easily confused with a facility in GSS-API
+   that is also called "channel binding".  GSS-API channel binding
+   provides protection against man-in-the-middle attacks when GSS-API is
+   used for authentication inside of some tunnel; it is similar to a
+   facility called "cryptographic binding" in EAP.  See [RFC5056] for a
+   discussion of the differences between these two facilities.
+
+   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 protocol, the client and the IdP need to be able to detect this
+   situation.  A general overview of the problem, along with a
+   recommended way to deal with the channel-binding issues, can be found
+   in [RFC6677].
+
+   Since the time that [RFC6677] was published, a number of possible
+   attacks were found.  Methods to address these attacks have been
+   outlined in [RFC7029].
+
+2.3.  Client to Relying Party
+
+   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
+   complex set, since at least part of it is outside the scope of the
+   ABFAB work.  The interactions between these parties include:
+
+   o  Running the protocol that implements the service that is provided
+      by the RP and desired by the client.
+
+   o  Authenticating the client to the RP and the RP to the client.
+
+   o  Providing the necessary security services to the service protocol
+      that it needs, beyond authentication.
+
+   o  Dealing with client re-authentication where desired.
+
+
+
+
+Howlett, et al.               Informational                    [Page 26]
+
+RFC 7831                   ABFAB Architecture                   May 2016
+
+
+2.3.1.  GSS-API
+
+   One of the remaining layers is responsible for integration of
+   federated authentication with the application.  Applications have
+   adopted a number of approaches for providing security, so multiple
+   strategies for integration of federated authentication with
+   applications may be needed.  To this end, we start with a strategy
+   that provides integration with a large number of application
+   protocols.
+
+   Many applications, such as Secure Shell (SSH) [RFC4462], NFS
+   [RFC7530], DNS [RFC3645], and several non-IETF applications, support
+   GSS-API [RFC2743].  Many applications, such as IMAP, SMTP, the
+   Extensible Messaging and Presence Protocol (XMPP), and the
+   Lightweight Directory Access Protocol (LDAP), support the Simple
+   Authentication and Security Layer (SASL) [RFC4422] framework.  These
+   two approaches work together nicely: by creating a GSS-API mechanism,
+   SASL integration is also addressed.  In effect, using a GSS-API
+   mechanism with SASL simply requires placing some headers before the
+   mechanism's messages and constraining certain GSS-API options.
+
+   GSS-API is specified in terms of an abstract set of operations that
+   can be mapped into a programming language to form an API.  When
+   people are first introduced to GSS-API, they focus on it as an API.
+   However, from the perspective of authentication for non-web
+   applications, GSS-API should be thought of as a protocol as well as
+   an API.  When looked at as a protocol, it consists of abstract
+   operations such as the initial context exchange, which includes two
+   sub-operations (GSS_Init_sec_context and GSS_Accept_sec_context)
+   [RFC2743].  An application defines which abstract operations it is
+   going to use and where messages produced by these operations fit into
+   the application architecture.  A GSS-API mechanism will define what
+   actual protocol messages result from that abstract message for a
+   given abstract operation.  So, since this work is focusing on a
+   particular GSS-API mechanism, we generally focus on protocol elements
+   rather than the API view of GSS-API.
+
+   The API view of GSS-API does have significant value as well; since
+   the abstract operations are well defined, the information that a
+   mechanism gets from the application is well defined.  Also, the set
+   of assumptions the application is permitted to make is generally well
+   defined.  As a result, an application protocol that supports GSS-API
+   or SASL is very likely to be usable with a new approach to
+   authentication, including the authentication mechanism defined in
+   this document, with no required modifications.  In some cases,
+   support for a new authentication mechanism has been added using
+   plugin interfaces to applications without the application being
+   modified at all.  Even when modifications are required, they can
+
+
+
+Howlett, et al.               Informational                    [Page 27]
+
+RFC 7831                   ABFAB Architecture                   May 2016
+
+
+   often be limited to supporting a new naming and authorization model.
+   For example, this work focuses on privacy; an application that
+   assumes that it will always obtain an identifier for the client will
+   need to be modified to support anonymity, unlinkability, or
+   pseudonymity.
+
+   So, we use GSS-API and SASL because a number of the application
+   protocols we wish to federate support these strategies for security
+   integration.  What does this mean from a protocol standpoint, and how
+   does this relate to other layers?  This means that we need to design
+   a concrete GSS-API mechanism.  We have chosen to use a GSS-API
+   mechanism that encapsulates EAP authentication.  So, GSS-API (and
+   SASL) encapsulates EAP between the end host and the service.  The AAA
+   framework encapsulates EAP between the RP and the IdP.  The GSS-API
+   mechanism includes rules about how initiators and services are named
+   as well as per-message security and other facilities required by the
+   applications we wish to support.
+
+2.3.2.  Protocol Transport
+
+   The transport of data between the client and the RP is not provided
+   by GSS-API.  GSS-API creates and consumes messages, but it does not
+   provide the transport itself; instead, the protocol using GSS-API
+   needs to provide the transport.  In many cases, HTTP or HTTPS is used
+   for this transport, but other transports are perfectly acceptable.
+   The core GSS-API document [RFC2743] provides some details on what
+   requirements exist.
+
+   In addition, we highlight the following:
+
+   o  The transport does not need to provide either confidentiality or
+      integrity.  After GSS-EAP has finished negotiation, GSS-API can be
+      used to provide both services.  If the negotiation process itself
+      needs protection from eavesdroppers, then the transport would need
+      to provide the necessary services.
+
+   o  The transport needs to provide reliable transport of the messages.
+
+   o  The transport needs to ensure that tokens are delivered in order
+      during the negotiation process.
+
+   o  GSS-API messages need to be delivered atomically.  If the
+      transport breaks up a message, it must also reassemble the message
+      before delivery.
+
+
+
+
+
+
+
+Howlett, et al.               Informational                    [Page 28]
+
+RFC 7831                   ABFAB Architecture                   May 2016
+
+
+2.3.3.  Re-authentication
+
+   There are circumstances where the RP will want to have the client
+   re-authenticate itself.  These include very long sessions, where the
+   original authentication is time limited or cases where in order to
+   complete an operation a different authentication is required.
+   GSS-EAP does not have any mechanism for the server to initiate a
+   re-authentication, as all authentication operations start from the
+   client.  If a protocol using GSS-EAP needs to support
+   re-authentication that is initiated by the server, then a request
+   from the server to the client for the re-authentication to start
+   needs to be placed in the protocol.
+
+   Clients can reuse the existing secure connection established by
+   GSS-API, and run the new authentication in that connection, by
+   calling GSS_Init_sec_context.  At this point, a full
+   re-authentication will be done.
+
+3.  Application Security Services
+
+   One of the key goals is to integrate federated authentication with
+   existing application protocols and, where possible, existing
+   implementations of these protocols.  Another goal is to perform this
+   integration while meeting the best security practices of the
+   technologies used to perform the integration.  This section describes
+   security services and properties required by the EAP GSS-API
+   mechanism in order to meet these goals.  This information could be
+   viewed as specific to that mechanism.  However, other future
+   application integration strategies are very likely to need similar
+   services.  So, it is likely that these services will be expanded
+   across application integration strategies if new application
+   integration strategies are adopted.
+
+3.1.  Authentication
+
+   GSS-API provides an optional security service called "mutual
+   authentication".  This service means that in addition to the
+   initiator providing (potentially anonymous or pseudonymous) identity
+   to the acceptor, the acceptor confirms its identity to the initiator.
+   In the context of ABFAB in particular, the naming of this service is
+   confusing.  We still say that mutual authentication is provided when
+   the identity of an acceptor is strongly authenticated to an anonymous
+   initiator.
+
+
+
+
+
+
+
+
+Howlett, et al.               Informational                    [Page 29]
+
+RFC 7831                   ABFAB Architecture                   May 2016
+
+
+   Unfortunately, [RFC2743] does not explicitly talk about what mutual
+   authentication means.  Within this document, we therefore define
+   mutual authentication as follows:
+
+   o  If a target name is configured for the initiator, then the
+      initiator trusts that the supplied target name describes the
+      acceptor.  This implies that (1) appropriate cryptographic
+      exchanges took place for the initiator to make such a trust
+      decision and (2) after evaluating the results of these exchanges,
+      the initiator's policy trusts that the target name is accurate.
+
+   o  If no target name is configured for the initiator, then the
+      initiator trusts that the acceptor name, supplied by the acceptor,
+      correctly names the entity it is communicating with.
+
+   o  Both the initiator and acceptor have the same key material for
+      per-message keys, and both parties have confirmed that they
+      actually have the key material.  In EAP terms, there is a
+      protected indication of success.
+
+   Mutual authentication is an important defense against certain aspects
+   of phishing.  Intuitively, clients would like to assume that if some
+   party asks for their credentials as part of authentication,
+   successfully gaining access to the resource means that they are
+   talking to the expected party.  Without mutual authentication, the
+   server could "grant access" regardless of what credentials are
+   supplied.  Mutual authentication better matches this user intuition.
+
+   It is important, therefore, that the GSS-EAP mechanism implement
+   mutual authentication.  That is, an initiator needs to be able to
+   request mutual authentication.  When mutual authentication is
+   requested, only EAP methods capable of providing the necessary
+   service can be used, and appropriate steps need to be taken to
+   provide mutual authentication.  While a broader set of EAP methods
+   could be supported by not requiring mutual authentication, it was
+   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
+   authentication; however, the client will always be able to detect
+   this and make an appropriate security decision.
+
+   The AAA infrastructure may hide the initiator's identity from the
+   GSS-API acceptor, providing anonymity between the initiator and the
+   acceptor.  At this time, whether the identity is disclosed is
+   determined by EAP server policy rather than by an indication from the
+   initiator.  Also, initiators are unlikely to be able to determine
+   whether anonymous communication will be provided.  For this reason,
+   initiators are unlikely to set the anonymous return flag from
+   GSS_Init_sec_context (Section 2.2.1 of [RFC2743]).
+
+
+
+Howlett, et al.               Informational                    [Page 30]
+
+RFC 7831                   ABFAB Architecture                   May 2016
+
+
+3.2.  GSS-API Channel Binding
+
+   [RFC5056] defines a concept of channel binding that is used to
+   prevent man-in-the-middle attacks.  This type of channel binding
+   works by taking a cryptographic value from the transport security
+   layer and checks to see that both sides of the GSS-API conversation
+   know this value.  Transport Layer Security (TLS) [RFC5246] is the
+   most common transport security layer used for this purpose.
+
+   It needs to be stressed that channel binding as described in
+   [RFC5056] (also called "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 detecting man-in-the-middle attacks.  EAP
+   channel binding is used for mutual authentication and acceptor naming
+   checks.  See [RFC7055] for details.  A more detailed description of
+   the differences between the facilities can be found in [RFC5056].
+
+   The use of TLS can provide both encryption and integrity on the
+   channel.  It is common to provide SASL and GSS-API with these other
+   security services.
+
+   One of the benefits that the use of TLS provides is that a client has
+   the ability to validate the name of the server.  However, this
+   validation is predicated on a couple of things.  The TLS session
+   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
+   certificate used in validating the server.  TLS provides its own
+   server authentication.  However, there are a variety of situations
+   where, for policy or usability reasons, this authentication is not
+   checked.  When the TLS authentication is checked, if the trust
+   infrastructure behind the TLS authentication is different from the
+   trust infrastructure behind the GSS-API mutual authentication, then
+   confirming the endpoints using both trust infrastructures is likely
+   to enhance security.  If the endpoints of the GSS-API authentication
+   are different than the endpoints of the lower layer, this is a strong
+   indication of a problem, such as a man-in-the-middle attack.  Channel
+   binding provides a facility to determine whether these endpoints are
+   the same.
+
+   The GSS-EAP mechanism needs to support channel binding.  When an
+   application provides channel-binding data, the mechanism needs to
+   confirm that this is the same on both sides, consistent with the
+   GSS-API specification.
+
+
+
+
+
+
+
+
+Howlett, et al.               Informational                    [Page 31]
+
+RFC 7831                   ABFAB Architecture                   May 2016
+
+
+3.3.  Host-Based Service Names
+
+   IETF security mechanisms typically take a host name and perhaps a
+   service, entered by a user, and make some trust decision about
+   whether the remote party in the interaction is the intended party.
+   This decision can be made via the use of certificates, preconfigured
+   key information, or a previous leap of trust.  GSS-API has defined a
+   relatively flexible naming convention; however, most of the IETF
+   applications that use GSS-API (including SSH, NFS, IMAP, LDAP, and
+   XMPP) have chosen to use a more restricted naming convention based on
+   the host name.  The GSS-EAP mechanism needs to support host-based
+   service names in order to work with existing IETF protocols.
+
+   The use of host-based service names leads to a challenging trust
+   delegation problem.  Who is allowed to decide whether a particular
+   host name maps to a specific entity?  Possible solutions to this
+   problem have been looked at.
+
+   o  The Public Key Infrastructure (PKI) used by the web has chosen to
+      have a number of trust anchors (root certificate authorities),
+      each of which can map any host name to a public key.
+
+   o  A number of GSS-API mechanisms, such as Kerberos [RFC1964], have
+      split the problem into two parts.  [RFC1964] introduced a new
+      concept called a realm; the realm is responsible for host mapping
+      within itself.  The mechanism then decides what realm is
+      responsible for a given name.  This is the approach adopted by
+      ABFAB.
+
+   GSS-EAP defines a host naming convention that takes into account the
+   host name, the realm, the service, and the service parameters.  An
+   example of a GSS-API service name is "xmpp/foo@example.com".  This
+   identifies the XMPP service on the host foo in the realm example.com.
+   Any of the components, except for the service name, may be omitted
+   from a name.  When omitted, a local default would be used for that
+   component of the name.
+
+   While there is no requirement that realm names map to Fully Qualified
+   Domain Names (FQDNs) within DNS, in practice this is normally true.
+   Doing so allows the realm portion of service names and the portion of
+   NAIs to be the same.  It also allows for the use of DNS in locating
+   the host of a service while establishing the transport channel
+   between the client and the RP.
+
+   It is the responsibility of the application to determine the server
+   that it is going to communicate with; GSS-API has the ability to help
+   confirm that the server is the desired server but not to determine
+   the name of the server to use.  It is also the responsibility of the
+
+
+
+Howlett, et al.               Informational                    [Page 32]
+
+RFC 7831                   ABFAB Architecture                   May 2016
+
+
+   application to determine how much of the information identifying the
+   service needs to be validated by the ABFAB system.  The information
+   that needs to be validated is used to construct the service name
+   passed into the GSS-EAP mechanism.  What information is to be
+   validated will depend on (1) what information was provided by the
+   client and (2) what information is considered significant.  If the
+   client only cares about getting a specific service, then it does not
+   need to validate the host and realm that provides the service.
+
+   Applications may retrieve information about providers of services
+   from DNS.  Service Records (SRVs) [RFC2782] and Naming Authority
+   Pointer (NAPTR) [RFC3401] records are used to help find a host that
+   provides a service; however, the necessity of having DNSSEC on the
+   queries depends on how the information is going to be used.  If the
+   host name returned is not going to be validated by EAP channel
+   binding because only the service is being validated, then DNSSEC
+   [RFC4033] is not required.  However, if the host name is going to be
+   validated by EAP channel binding, then DNSSEC needs to be used to
+   ensure that the correct host name is validated.  In general, if the
+   information that is returned from the DNS query is to be validated,
+   then it needs to be obtained in a secure manner.
+
+   Another issue that needs to be addressed for host-based service names
+   is that they do not work ideally when different instances of a
+   service are running on different ports.  If the services are
+   equivalent, then it does not matter.  However, if there are
+   substantial differences in the quality of the service, that
+   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,
+   then this is not going to be a successful strategy.
+
+3.4.  Additional GSS-API Services
+
+   GSS-API provides per-message security services that can provide
+   confidentiality and/or integrity.  Some IETF protocols, such as NFS
+   and SSH, take advantage of these services.  As a result, GSS-EAP
+   needs to support these services.  As with mutual authentication,
+   per-message security services will limit the set of EAP methods that
+   can be used to those that generate a Master Session Key (MSK).  Any
+   EAP method that produces an MSK is able to support per-message
+   security services as described in [RFC2743].
+
+   GSS-API provides a pseudorandom function.  This function generates a
+   pseudorandom sequence using the shared session key as the seed for
+   the bytes generated.  This provides an algorithm that both the
+   initiator and acceptor can run in order to arrive at the same key
+   value.  The use of this feature allows an application to generate
+   keys or other shared secrets for use in other places in the protocol.
+
+
+
+Howlett, et al.               Informational                    [Page 33]
+
+RFC 7831                   ABFAB Architecture                   May 2016
+
+
+   In this regard, it is similar in concept to the mechanism (formerly
+   known as "TLS Extractors") described in [RFC5705].  While no current
+   IETF protocols require this feature, non-IETF protocols are expected
+   to take advantage of it in the near future.  Additionally, a number
+   of protocols have found the mechanism described in [RFC5705] to be
+   useful in this regard, so it is highly probable that IETF protocols
+   may also start using this feature.
+
+4.  Privacy Considerations
+
+   As an architecture designed to enable federated authentication and
+   allow for the secure transmission of identity information between
+   entities, ABFAB obviously requires careful consideration regarding
+   privacy and the potential for privacy violations.
+
+   This section examines the privacy-related information presented in
+   this document, summarizing the entities that are involved in ABFAB
+   communications and what exposure they have to identity information.
+   In discussing these privacy considerations in this section, we use
+   terminology and ideas from [RFC6973].
+
+   Note that the ABFAB architecture uses at its core several existing
+   technologies and protocols; detailed privacy discussion regarding
+   these topics is not examined.  This section instead focuses on
+   privacy considerations specifically related to the overall
+   architecture and usage of ABFAB.
+
+      +--------+       +---------------+       +--------------+
+      | Client | <---> |      RP       | <---> | AAA Client   |
+      +--------+       +---------------+       +--------------+
+                                                     ^
+                                                     |
+                                                     v
+                       +---------------+       +----------------+
+                       | SAML Server   |       | AAA Proxy      |
+                       +---------------+       | (or Proxies)   |
+                                ^              +----------------+
+                                |                       ^
+                                |                       |
+                                v                       v
+      +------------+       +---------------+       +--------------+
+      | EAP Server | <---> |   IdP         | <---> | AAA Server   |
+      +------------+       +---------------+       +--------------+
+
+                     Figure 4: Entities and Data Flow
+
+
+
+
+
+
+Howlett, et al.               Informational                    [Page 34]
+
+RFC 7831                   ABFAB Architecture                   May 2016
+
+
+4.1.  Entities and Their Roles
+
+   Categorizing the ABFAB entities shown in Figure 4 according to the
+   taxonomy of terms from [RFC6973] is somewhat complicated, as the
+   roles of each entity will change during the various phases of ABFAB
+   communications.  The three main phases of relevance are the
+   client-to-RP communication phase, the client-to-IdP (via the
+   Federation Substrate) communication phase, and the IdP-to-RP (via the
+   Federation Substrate) communication phase.
+
+   In the client-to-RP communication phase, we have:
+
+   Initiator:  Client.
+
+   Observers:  Client, RP.
+
+   Recipient:  RP.
+
+   In the client-to-IdP (via the Federation Substrate) communication
+   phase, we have:
+
+   Initiator:  Client.
+
+   Observers:  Client, RP, AAA Client, AAA Proxy (or Proxies), AAA
+      Server, IdP.
+
+   Recipient:  IdP
+
+   In the IdP-to-RP (via the Federation Substrate) communication phase,
+   we have:
+
+   Initiator:  RP.
+
+   Observers:  IdP, AAA Server, AAA Proxy (or Proxies), AAA Client, RP.
+
+   Recipient:  IdP
+
+   Eavesdroppers and attackers can reside on any or all communication
+   links between the entities shown in Figure 4.
+
+
+
+
+
+
+
+
+
+
+
+
+Howlett, et al.               Informational                    [Page 35]
+
+RFC 7831                   ABFAB Architecture                   May 2016
+
+
+   The various entities in the system might also collude or be coerced
+   into colluding.  Some of the significant collusions to look at are as
+   follows:
+
+   o  If two RPs are colluding, they have the information available to
+      both nodes.  This can be analyzed as if a single RP were 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, they can be treated as a
+      single node for analysis.
+
+   The Federation Substrate consists of all of the AAA entities.  In
+   some cases, the AAA proxies may not exist, as the AAA client can talk
+   directly to the AAA server.  Specifications such as the Trust Router
+   Protocol (https://www.ietf.org/proceedings/86/slides/
+   slides-86-rtgarea-0.pdf) and RADIUS dynamic discovery [RFC7585] can
+   be used to shorten the path between the AAA client and the AAA server
+   (and thus stop these AAA proxies from being observers); however, even
+   in these circumstances, there may be AAA proxies in the path.
+
+   In Figure 4, the IdP has been divided into multiple logical pieces;
+   in actual implementations, these pieces will frequently be tightly
+   coupled.  The links between these pieces provide the greatest
+   opportunity for attackers and eavesdroppers to acquire information;
+   however, as they are all under the control of a single entity, they
+   are also the easiest to have tightly secured.
+
+4.2.  Privacy Aspects of ABFAB Communication Flows
+
+   In the ABFAB architecture, there are a few different types of data
+   and identifiers in use.  The best way to understand them, and their
+   potential privacy impacts, is to look at each phase of communication
+   in ABFAB.
+
+4.2.1.  Client to RP
+
+   The flow of data between the client and the RP is divided into two
+   parts.  The first part consists of all of the data exchanged as part
+   of the ABFAB authentication process.  The second part consists of all
+   of the data exchanged after the authentication process has been
+   finished.
+
+
+
+
+
+Howlett, et al.               Informational                    [Page 36]
+
+RFC 7831                   ABFAB Architecture                   May 2016
+
+
+   During the initial communication phase, the client sends an NAI (see
+   [RFC7542]) to the RP.  Many EAP methods (but not all) allow the
+   client to disclose an NAI to the RP in a form that includes only a
+   realm component during this communication phase.  This is the minimum
+   amount of identity information necessary for ABFAB to work -- it
+   indicates an IdP that the principal has a relationship with.  EAP
+   methods that do not allow this will necessarily also reveal an
+   identifier for the principal in the IdP realm (e.g., a username).
+
+   The data shared during the initial communication phase may be
+   protected by a channel protocol such as TLS.  This will prevent the
+   leakage of information to passive eavesdroppers; however, an active
+   attacker may still be able to set itself up as a man-in-the-middle.
+   The client may not be able to validate the certificates (if any)
+   provided by the service, deferring the check of the identity of the
+   RP until the completion of the ABFAB authentication protocol (using
+   EAP channel binding rather than certificates).
+
+   The data exchanged after the authentication process can have privacy
+   and authentication using the GSS-API services.  If the overall
+   application protocol allows for the process of re-authentication,
+   then the same privacy implications as those discussed in previous
+   paragraphs apply.
+
+4.2.2.  Client to IdP (via Federation Substrate)
+
+   This phase includes a secure TLS tunnel set up between the client and
+   the IdP via the RP and Federation Substrate.  The process is
+   initiated by the RP using the realm information given to it by the
+   client.  Once set up, the tunnel is used to send credentials to the
+   IdP to authenticate.
+
+   Various operational information is transported between the RP and the
+   IdP over the AAA infrastructure -- for example, using RADIUS headers.
+   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 on this
+   information.  Some of this information may form identifiers or
+   explicit identity information:
+
+   o  The RP knows the IP address of the client.  It is possible that
+      the RP could choose to expose this IP address by including it in a
+      RADIUS header (e.g., using the Calling-Station-Id).  This is a
+      privacy consideration to take into account for the application
+      protocol.
+
+   o  The EAP MSK is transported between the IdP and the RP over the AAA
+      infrastructure -- for example, through RADIUS headers.  This is a
+      particularly important privacy consideration, as any AAA proxy
+
+
+
+Howlett, et al.               Informational                    [Page 37]
+
+RFC 7831                   ABFAB Architecture                   May 2016
+
+
+      that has access to the EAP MSK is able to decrypt and eavesdrop on
+      any traffic encrypted using that EAP MSK (i.e., all communications
+      between the client and RP).  This problem can be mitigated if the
+      application protocol sets up a secure tunnel between the client
+      and the RP and performs a cryptographic binding between the tunnel
+      and EAP MSK.
+
+   o  Related to the bullet point above, the AAA server has access to
+      the material necessary to derive the session key; thus, the AAA
+      server can observe any traffic encrypted between the client and
+      RP.  This "feature" was chosen as a simplification and to make
+      performance faster; if it was decided that this trade-off was not
+      desirable for privacy and security reasons, then extensions to
+      ABFAB that make use of techniques such as Diffie-Hellman key
+      exchange would mitigate this.
+
+   The choice of EAP method used has other potential privacy
+   implications.  For example, if the EAP method in use does not
+   support mutual authentication, then there are no guarantees that the
+   IdP is who it claims to be, and thus the full NAI, including a
+   username and a realm, might be sent to any entity masquerading as a
+   particular IdP.
+
+   Note that ABFAB has not specified any AAA accounting requirements.
+   Implementations that use the accounting portion of AAA should
+   consider privacy appropriately when designing this aspect.
+
+4.2.3.  IdP to RP (via Federation Substrate)
+
+   In this phase, the IdP communicates with the RP, informing it as to
+   the success or failure of authentication of the user and, optionally,
+   the sending of identity information about the principal.
+
+   As in the previous flow (client to IdP), various operation
+   information is transported between the IdP and RP over the AAA
+   infrastructure, and the same privacy considerations apply.  However,
+   in this flow, explicit identity information about the authenticated
+   principal can be sent from the IdP to the RP.  This information can
+   be sent through RADIUS headers, or using SAML [RFC7833].  This can
+   include protocol-specific identifiers, such as SAML NameIDs, as well
+   as arbitrary attribute information about the principal.  What
+   information will be released is controlled by policy on the IdP.  As
+   before, when sending this information through RADIUS headers, all AAA
+   entities on the path between the RP and IdP have the ability to
+   eavesdrop, unless additional security measures are taken (such as the
+   use of TLS for RADIUS [RFC6614]).  However, when sending this
+
+
+
+
+
+Howlett, et al.               Informational                    [Page 38]
+
+RFC 7831                   ABFAB Architecture                   May 2016
+
+
+   information using SAML as specified in [RFC7833], confidentiality of
+   the information should be guaranteed, as [RFC7833] requires the use
+   of TLS for RADIUS.
+
+4.3.  Relationship between User and Entities
+
+   o  Between user and IdP - The IdP is an entity the user will have a
+      direct relationship with, created when the organization that
+      operates the entity provisioned and exchanged the user's
+      credentials.  Privacy and data protection guarantees may form a
+      part of this relationship.
+
+   o  Between user and RP - The RP is an entity the user may or may not
+      have a direct relationship with, depending on the service in
+      question.  Some services may only be offered to those users where
+      such a direct relationship exists (for particularly sensitive
+      services, for example), while some may not require this and would
+      instead be satisfied with basic federation trust guarantees
+      between themselves and the IdP.  This may well include the option
+      that the user stays anonymous with respect to the RP (though,
+      obviously, never anonymous to the IdP).  If attempting to preserve
+      privacy via data minimization (Section 1), then the only attribute
+      information about Individuals exposed to the RP should be
+      attribute information that is strictly necessary for the operation
+      of the service.
+
+   o  Between user and Federation Substrate - The user is highly likely
+      to have no knowledge of, or relationship with, any entities
+      involved with the Federation Substrate (not that the IdP and/or RP
+      may, however).  Knowledge of attribute information about
+      Individuals for these entities is not necessary, and thus such
+      information should be protected in such a way as to prevent the
+      possibility of access to this information.
+
+4.4.  Accounting Information
+
+   Alongside the core authentication and authorization that occur in AAA
+   communications, accounting information about resource consumption may
+   be delivered as part of the accounting exchange during the lifetime
+   of the granted application session.
+
+4.5.  Collection and Retention of Data and Identifiers
+
+   In cases where RPs are not required to identify a particular
+   Individual when an Individual wishes to make use of their service,
+   the ABFAB architecture enables anonymous or pseudonymous access.
+   Thus, data and identifiers other than pseudonyms and unlinkable
+   attribute information need not be stored and retained.
+
+
+
+Howlett, et al.               Informational                    [Page 39]
+
+RFC 7831                   ABFAB Architecture                   May 2016
+
+
+   However, in cases where RPs require the ability to identify a
+   particular Individual (e.g., so they can link this identity
+   information to a particular account in their service, or where
+   identity information is required for audit purposes), the service
+   will need to collect and store such information, and to retain it for
+   as long as they require.  The de-provisioning of such accounts and
+   information is out of scope for ABFAB, but for privacy protection, it
+   is obvious that any identifiers collected should be deleted when they
+   are no longer needed.
+
+4.6.  User Participation
+
+   In the ABFAB architecture, by its very nature users are active
+   participants in the sharing of their identifiers, as they initiate
+   the communications exchange every time they wish to access a server.
+   They are, however, not involved in the control of information related
+   to them that is transmitted from the IdP to the RP for authorization
+   purposes; rather, this is under the control of policy on the IdP.
+   Due to the nature of the AAA communication flows, with the current
+   ABFAB architecture there is no place for a process of gaining user
+   consent for the information to be released from the IdP to the RP.
+
+5.  Security Considerations
+
+   This document describes the architecture for Application Bridging for
+   Federated Access Beyond web (ABFAB), and security is therefore the
+   main focus.  Many of the items that are security considerations have
+   already been discussed in Section 4 ("Privacy Considerations").
+   Readers should be sure to read that section as well.
+
+   There are many places in this document where TLS is used.  While in
+   some places (e.g., 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 network, 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 difficult problem in
+   general and is going to be even more difficult for kiosk
+   environments.
+
+   Selection of the EAP methods to be permitted by clients and IdPs is
+   important.  The use of a tunneling method such as TEAP [RFC7170]
+   allows other EAP methods to be used while hiding the contents of
+
+
+
+Howlett, et al.               Informational                    [Page 40]
+
+RFC 7831                   ABFAB Architecture                   May 2016
+
+
+   those EAP exchanges from the RP and the AAA framework.  When
+   considering inner EAP methods, the considerations outlined in
+   [RFC7029] about binding the inner and outer EAP methods need to be
+   taken into account.  Finally, one wants to have the ability to
+   support channel binding in those cases where the client needs to
+   validate that it is talking to the correct RP.
+
+   In those places where SAML statements are used, RPs will generally be
+   unable to validate signatures on the SAML statement, either because
+   the signature has been stripped off by the IdP or because the RP is
+   unable to validate the 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 that RPs can trust the AAA infrastructure to keep the
+   SAML statements valid.
+
+   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
+   easily be reverse-engineered by the service provider.  If it can be
+   reverse-engineered, then the service provider can consult an oracle
+   to determine if a given unique long-term identifier is associated
+   with a different known identifier.
+
+6.  References
+
+6.1.  Normative References
+
+   [RFC2743]  Linn, J., "Generic Security Service Application Program
+              Interface Version 2, Update 1", RFC 2743,
+              DOI 10.17487/RFC2743, January 2000,
+              <http://www.rfc-editor.org/info/rfc2743>.
+
+   [RFC2865]  Rigney, C., Willens, S., Rubens, A., and W. Simpson,
+              "Remote Authentication Dial In User Service (RADIUS)",
+              RFC 2865, DOI 10.17487/RFC2865, June 2000,
+              <http://www.rfc-editor.org/info/rfc2865>.
+
+   [RFC3579]  Aboba, B. and P. Calhoun, "RADIUS (Remote Authentication
+              Dial In User Service) Support For Extensible
+              Authentication Protocol (EAP)", RFC 3579,
+              DOI 10.17487/RFC3579, September 2003,
+              <http://www.rfc-editor.org/info/rfc3579>.
+
+   [RFC3748]  Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H.
+              Levkowetz, Ed., "Extensible Authentication Protocol
+              (EAP)", RFC 3748, DOI 10.17487/RFC3748, June 2004,
+              <http://www.rfc-editor.org/info/rfc3748>.
+
+
+
+
+Howlett, et al.               Informational                    [Page 41]
+
+RFC 7831                   ABFAB Architecture                   May 2016
+
+
+   [RFC4072]  Eronen, P., Ed., Hiller, T., and G. Zorn, "Diameter
+              Extensible Authentication Protocol (EAP) Application",
+              RFC 4072, DOI 10.17487/RFC4072, August 2005,
+              <http://www.rfc-editor.org/info/rfc4072>.
+
+   [RFC6677]  Hartman, S., Ed., Clancy, T., and K. Hoeper, "Channel-
+              Binding Support for Extensible Authentication Protocol
+              (EAP) Methods", RFC 6677, DOI 10.17487/RFC6677, July 2012,
+              <http://www.rfc-editor.org/info/rfc6677>.
+
+   [RFC7055]  Hartman, S., Ed., and J. Howlett, "A GSS-API Mechanism for
+              the Extensible Authentication Protocol", RFC 7055,
+              DOI 10.17487/RFC7055, December 2013,
+              <http://www.rfc-editor.org/info/rfc7055>.
+
+   [RFC7542]  DeKok, A., "The Network Access Identifier", RFC 7542,
+              DOI 10.17487/RFC7542, May 2015,
+              <http://www.rfc-editor.org/info/rfc7542>.
+
+   [RFC7833]  Howlett, J., Hartman, S., and A. Perez-Mendez, Ed., "A
+              RADIUS Attribute, Binding, Profiles, Name Identifier
+              Format, and Confirmation Methods for the Security
+              Assertion Markup Language (SAML)", RFC 7833,
+              DOI 10.17487/RFC7833, May 2016,
+              <http://www.rfc-editor.org/info/rfc7833>.
+
+6.2.  Informative References
+
+   [NIST-SP.800-63-2]
+              Burr, W., Dodson, D., Newton, E., Perlner, R., Polk, W.,
+              Gupta, S., and E. Nabbus, "Electronic Authentication
+              Guideline", NIST Special Publication 800-63-2,
+              August 2013, <http://dx.doi.org/10.6028/NIST.SP.800-63-2>.
+
+   [OASIS.saml-core-2.0-os]
+              Cantor, S., Kemp, J., Philpott, R., and E. Maler,
+              "Assertions and Protocols for the OASIS Security
+              Assertion Markup Language (SAML) V2.0", OASIS
+              Standard saml-core-2.0-os, March 2005,
+              <http://docs.oasis-open.org/security/saml/v2.0/
+              saml-core-2.0-os.pdf>.
+
+   [RFC1964]  Linn, J., "The Kerberos Version 5 GSS-API Mechanism",
+              RFC 1964, DOI 10.17487/RFC1964, June 1996,
+              <http://www.rfc-editor.org/info/rfc1964>.
+
+
+
+
+
+
+Howlett, et al.               Informational                    [Page 42]
+
+RFC 7831                   ABFAB Architecture                   May 2016
+
+
+   [RFC2782]  Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for
+              specifying the location of services (DNS SRV)", RFC 2782,
+              DOI 10.17487/RFC2782, February 2000,
+              <http://www.rfc-editor.org/info/rfc2782>.
+
+   [RFC3401]  Mealling, M., "Dynamic Delegation Discovery System (DDDS)
+              Part One: The Comprehensive DDDS", RFC 3401,
+              DOI 10.17487/RFC3401, October 2002,
+              <http://www.rfc-editor.org/info/rfc3401>.
+
+   [RFC3645]  Kwan, S., Garg, P., Gilroy, J., Esibov, L., Westhead, J.,
+              and R. Hall, "Generic Security Service Algorithm for
+              Secret Key Transaction Authentication for DNS (GSS-TSIG)",
+              RFC 3645, DOI 10.17487/RFC3645, October 2003,
+              <http://www.rfc-editor.org/info/rfc3645>.
+
+   [RFC4033]  Arends, R., Austein, R., Larson, M., Massey, D., and S.
+              Rose, "DNS Security Introduction and Requirements",
+              RFC 4033, DOI 10.17487/RFC4033, March 2005,
+              <http://www.rfc-editor.org/info/rfc4033>.
+
+   [RFC4422]  Melnikov, A., Ed., and K. Zeilenga, Ed., "Simple
+              Authentication and Security Layer (SASL)", RFC 4422,
+              DOI 10.17487/RFC4422, June 2006,
+              <http://www.rfc-editor.org/info/rfc4422>.
+
+   [RFC4462]  Hutzelman, J., Salowey, J., Galbraith, J., and V. Welch,
+              "Generic Security Service Application Program Interface
+              (GSS-API) Authentication and Key Exchange for the Secure
+              Shell (SSH) Protocol", RFC 4462, DOI 10.17487/RFC4462,
+              May 2006, <http://www.rfc-editor.org/info/rfc4462>.
+
+   [RFC5056]  Williams, N., "On the Use of Channel Bindings to Secure
+              Channels", RFC 5056, DOI 10.17487/RFC5056, November 2007,
+              <http://www.rfc-editor.org/info/rfc5056>.
+
+   [RFC5080]  Nelson, D. and A. DeKok, "Common Remote Authentication
+              Dial In User Service (RADIUS) Implementation Issues and
+              Suggested Fixes", RFC 5080, DOI 10.17487/RFC5080,
+              December 2007, <http://www.rfc-editor.org/info/rfc5080>.
+
+   [RFC5246]  Dierks, T. and E. Rescorla, "The Transport Layer Security
+              (TLS) Protocol Version 1.2", RFC 5246,
+              DOI 10.17487/RFC5246, August 2008,
+              <http://www.rfc-editor.org/info/rfc5246>.
+
+
+
+
+
+
+Howlett, et al.               Informational                    [Page 43]
+
+RFC 7831                   ABFAB Architecture                   May 2016
+
+
+   [RFC5705]  Rescorla, E., "Keying Material Exporters for Transport
+              Layer Security (TLS)", RFC 5705, DOI 10.17487/RFC5705,
+              March 2010, <http://www.rfc-editor.org/info/rfc5705>.
+
+   [RFC5801]  Josefsson, S. and N. Williams, "Using Generic Security
+              Service Application Program Interface (GSS-API) Mechanisms
+              in Simple Authentication and Security Layer (SASL): The
+              GS2 Mechanism Family", RFC 5801, DOI 10.17487/RFC5801,
+              July 2010, <http://www.rfc-editor.org/info/rfc5801>.
+
+   [RFC6066]  Eastlake 3rd, D., "Transport Layer Security (TLS)
+              Extensions: Extension Definitions", RFC 6066,
+              DOI 10.17487/RFC6066, January 2011,
+              <http://www.rfc-editor.org/info/rfc6066>.
+
+   [RFC6614]  Winter, S., McCauley, M., Venaas, S., and K. Wierenga,
+              "Transport Layer Security (TLS) Encryption for RADIUS",
+              RFC 6614, DOI 10.17487/RFC6614, May 2012,
+              <http://www.rfc-editor.org/info/rfc6614>.
+
+   [RFC6733]  Fajardo, V., Ed., Arkko, J., Loughney, J., and G. Zorn,
+              Ed., "Diameter Base Protocol", RFC 6733,
+              DOI 10.17487/RFC6733, October 2012,
+              <http://www.rfc-editor.org/info/rfc6733>.
+
+   [RFC6749]  Hardt, D., Ed., "The OAuth 2.0 Authorization Framework",
+              RFC 6749, DOI 10.17487/RFC6749, October 2012,
+              <http://www.rfc-editor.org/info/rfc6749>.
+
+   [RFC6973]  Cooper, A., Tschofenig, H., Aboba, B., Peterson, J.,
+              Morris, J., Hansen, M., and R. Smith, "Privacy
+              Considerations for Internet Protocols", RFC 6973,
+              DOI 10.17487/RFC6973, July 2013,
+              <http://www.rfc-editor.org/info/rfc6973>.
+
+   [RFC7029]  Hartman, S., Wasserman, M., and D. Zhang, "Extensible
+              Authentication Protocol (EAP) Mutual Cryptographic
+              Binding", RFC 7029, DOI 10.17487/RFC7029, October 2013,
+              <http://www.rfc-editor.org/info/rfc7029>.
+
+   [RFC7170]  Zhou, H., Cam-Winget, N., Salowey, J., and S. Hanna,
+              "Tunnel Extensible Authentication Protocol (TEAP)
+              Version 1", RFC 7170, DOI 10.17487/RFC7170, May 2014,
+              <http://www.rfc-editor.org/info/rfc7170>.
+
+
+
+
+
+
+
+Howlett, et al.               Informational                    [Page 44]
+
+RFC 7831                   ABFAB Architecture                   May 2016
+
+
+   [RFC7360]  DeKok, A., "Datagram Transport Layer Security (DTLS) as a
+              Transport Layer for RADIUS", RFC 7360,
+              DOI 10.17487/RFC7360, September 2014,
+              <http://www.rfc-editor.org/info/rfc7360>.
+
+   [RFC7499]  Perez-Mendez, A., Ed., Marin-Lopez, R., Pereniguez-Garcia,
+              F., Lopez-Millan, G., Lopez, D., and A. DeKok, "Support of
+              Fragmentation of RADIUS Packets", RFC 7499,
+              DOI 10.17487/RFC7499, April 2015,
+              <http://www.rfc-editor.org/info/rfc7499>.
+
+   [RFC7530]  Haynes, T., Ed., and D. Noveck, Ed., "Network File System
+              (NFS) Version 4 Protocol", RFC 7530, DOI 10.17487/RFC7530,
+              March 2015, <http://www.rfc-editor.org/info/rfc7530>.
+
+   [RFC7585]  Winter, S. and M. McCauley, "Dynamic Peer Discovery for
+              RADIUS/TLS and RADIUS/DTLS Based on the Network Access
+              Identifier (NAI)", RFC 7585, DOI 10.17487/RFC7585,
+              October 2015, <http://www.rfc-editor.org/info/rfc7585>.
+
+   [WS-TRUST] Lawrence, K., Kaler, C., Nadalin, A., Goodner, M., Gudgin,
+              M., Turner, D., Barbir, A., and H. Granqvist,
+              "WS-Trust 1.4", OASIS Standard ws-trust-2012-04,
+              April 2012, <http://docs.oasis-open.org/ws-sx/ws-trust/
+              v1.4/ws-trust.html>.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Howlett, et al.               Informational                    [Page 45]
+
+RFC 7831                   ABFAB Architecture                   May 2016
+
+
+Acknowledgments
+
+   We would like to thank Mayutan Arumaithurai, Klaas Wierenga, and Rhys
+   Smith for their feedback.  Additionally, we would like to thank Eve
+   Maler, Nicolas Williams, Bob Morgan, Scott Cantor, Jim Fenton, Paul
+   Leach, and Luke Howard for their feedback on the federation
+   terminology question.
+
+   Furthermore, we would like to thank Klaas Wierenga for his review of
+   the first draft version of this document.  We also thank Eliot Lear
+   for his work on early draft versions of this document.
+
+Authors' Addresses
+
+   Josh Howlett
+   Jisc
+   Lumen House, Library Avenue, Harwell
+   Oxford  OX11 0SG
+   United Kingdom
+
+   Phone: +44 1235 822363
+   Email: Josh.Howlett@ja.net
+
+
+   Sam Hartman
+   Painless Security
+
+   Email: hartmans-ietf@mit.edu
+
+
+   Hannes Tschofenig
+   ARM Ltd.
+   110 Fulbourn Road
+   Cambridge  CB1 9NJ
+   United Kingdom
+
+   Email: Hannes.tschofenig@gmx.net
+   URI:   http://www.tschofenig.priv.at
+
+
+   Jim Schaad
+   August Cellars
+
+   Email: ietf@augustcellars.com
+
+
+
+
+
+
+
+Howlett, et al.               Informational                    [Page 46]
+