tech-invite   World Map     

IETF     RFCs     Groups     SIP     ABNFs    |    3GPP     Specs     Gloss.     Arch.     IMS     UICC    |    Misc.    |    search     info

RFC 7831

 
 
 

Application Bridging for Federated Access Beyond Web (ABFAB) Architecture

Part 3 of 3, p. 29 to 46
Prev RFC Part

 


prevText      Top      ToC       Page 29 
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.

Top      Up      ToC       Page 30 
   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]).

Top      Up      ToC       Page 31 
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.

Top      Up      ToC       Page 32 
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

Top      Up      ToC       Page 33 
   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.

Top      Up      ToC       Page 34 
   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

Top      Up      ToC       Page 35 
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.

Top      Up      ToC       Page 36 
   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.

Top      Up      ToC       Page 37 
   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

Top      Up      ToC       Page 38 
      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

Top      Up      ToC       Page 39 
   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.

Top      Up      ToC       Page 40 
   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

Top      Up      ToC       Page 41 
   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>.

Top      Up      ToC       Page 42 
   [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>.

Top      Up      ToC       Page 43 
   [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>.

Top      Up      ToC       Page 44 
   [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>.

Top      Up      ToC       Page 45 
   [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>.

Top      Up      ToC       Page 46 
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