RFC 7831
Application Bridging for Federated Access Beyond Web (ABFAB) Architecture
Pages: 46
Informational
Informational
Part 3 of 3 – Pages 29 to 46
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.
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]).
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.
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
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.
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
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.
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.
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
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
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.
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
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>.
[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>.
[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>.
[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>.
[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>.
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