in Index   Prev   Next

RFC 7831

Application Bridging for Federated Access Beyond Web (ABFAB) Architecture

Pages: 46
Part 3 of 3 – Pages 29 to 46
First   Prev   None

Top   ToC   RFC7831 - Page 29   prevText

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   ToC   RFC7831 - 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   ToC   RFC7831 - 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   ToC   RFC7831 - 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/". This identifies the XMPP service on the host foo in the realm 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   ToC   RFC7831 - 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   ToC   RFC7831 - 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   ToC   RFC7831 - 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   ToC   RFC7831 - 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

   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

   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 (
   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   ToC   RFC7831 - 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   ToC   RFC7831 - 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   ToC   RFC7831 - 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   ToC   RFC7831 - 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   ToC   RFC7831 - 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, <>. [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, <>. [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, <>. [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, <>.
Top   ToC   RFC7831 - 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,

   [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,

   [RFC7055]  Hartman, S., Ed., and J. Howlett, "A GSS-API Mechanism for
              the Extensible Authentication Protocol", RFC 7055,
              DOI 10.17487/RFC7055, December 2013,

   [RFC7542]  DeKok, A., "The Network Access Identifier", RFC 7542,
              DOI 10.17487/RFC7542, May 2015,

   [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,

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, <>. [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, < saml-core-2.0-os.pdf>. [RFC1964] Linn, J., "The Kerberos Version 5 GSS-API Mechanism", RFC 1964, DOI 10.17487/RFC1964, June 1996, <>.
Top   ToC   RFC7831 - 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,

   [RFC3401]  Mealling, M., "Dynamic Delegation Discovery System (DDDS)
              Part One: The Comprehensive DDDS", RFC 3401,
              DOI 10.17487/RFC3401, October 2002,

   [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,

   [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,

   [RFC4422]  Melnikov, A., Ed., and K. Zeilenga, Ed., "Simple
              Authentication and Security Layer (SASL)", RFC 4422,
              DOI 10.17487/RFC4422, June 2006,

   [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, <>.

   [RFC5056]  Williams, N., "On the Use of Channel Bindings to Secure
              Channels", RFC 5056, DOI 10.17487/RFC5056, November 2007,

   [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, <>.

   [RFC5246]  Dierks, T. and E. Rescorla, "The Transport Layer Security
              (TLS) Protocol Version 1.2", RFC 5246,
              DOI 10.17487/RFC5246, August 2008,
Top   ToC   RFC7831 - Page 44
   [RFC5705]  Rescorla, E., "Keying Material Exporters for Transport
              Layer Security (TLS)", RFC 5705, DOI 10.17487/RFC5705,
              March 2010, <>.

   [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, <>.

   [RFC6066]  Eastlake 3rd, D., "Transport Layer Security (TLS)
              Extensions: Extension Definitions", RFC 6066,
              DOI 10.17487/RFC6066, January 2011,

   [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,

   [RFC6733]  Fajardo, V., Ed., Arkko, J., Loughney, J., and G. Zorn,
              Ed., "Diameter Base Protocol", RFC 6733,
              DOI 10.17487/RFC6733, October 2012,

   [RFC6749]  Hardt, D., Ed., "The OAuth 2.0 Authorization Framework",
              RFC 6749, DOI 10.17487/RFC6749, October 2012,

   [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,

   [RFC7029]  Hartman, S., Wasserman, M., and D. Zhang, "Extensible
              Authentication Protocol (EAP) Mutual Cryptographic
              Binding", RFC 7029, DOI 10.17487/RFC7029, October 2013,

   [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,
Top   ToC   RFC7831 - Page 45
   [RFC7360]  DeKok, A., "Datagram Transport Layer Security (DTLS) as a
              Transport Layer for RADIUS", RFC 7360,
              DOI 10.17487/RFC7360, September 2014,

   [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,

   [RFC7530]  Haynes, T., Ed., and D. Noveck, Ed., "Network File System
              (NFS) Version 4 Protocol", RFC 7530, DOI 10.17487/RFC7530,
              March 2015, <>.

   [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, <>.

   [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, <
Top   ToC   RFC7831 - Page 46


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: Sam Hartman Painless Security Email: Hannes Tschofenig ARM Ltd. 110 Fulbourn Road Cambridge CB1 9NJ United Kingdom Email: URI: Jim Schaad August Cellars Email: