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.
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
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
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 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
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
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 "firstname.lastname@example.org". 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 |
+--------+ +---------------+ +--------------+
| SAML Server | | AAA Proxy |
+---------------+ | (or Proxies) |
+------------+ +---------------+ +--------------+
| 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:
Observers: Client, RP.
In the client-to-IdP (via the Federation Substrate) communication
phase, we have:
Observers: Client, RP, AAA Client, AAA Proxy (or Proxies), AAA
In the IdP-to-RP (via the Federation Substrate) communication phase,
Observers: IdP, AAA Server, AAA Proxy (or Proxies), AAA Client, RP.
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
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
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 (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
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
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
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
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
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
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.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,
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
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.
Lumen House, Library Avenue, Harwell
Oxford OX11 0SG
Phone: +44 1235 822363
110 Fulbourn Road
Cambridge CB1 9NJ