Application Bridging for Federated Access Beyond web

Document Charter Application Bridging for Federated Access Beyond web WG (abfab)
Title Application Bridging for Federated Access Beyond web
Last updated 2010-10-12
State Approved
WG State Concluded
IESG Responsible AD Stephen Farrell
Charter Edit AD (None)
Send notices to (None)


Problem Statement

  Federated identity facilitates the controlled sharing of information
  about principals, commonly across organisational boundaries. This avoids
  redundant registration of principals who operate in multiple domains,
  reducing administrative overheads and improving usability while
  addressing privacy-related concerns and regulatory and statutory
  requirements of some jurisdictions. A number of such mechanisms are in
  use for the Web.  This working group will specify a federated identity
  mechanism for use by other Internet protocols not based on HTML/HTTP,
  such as for instance IMAP, XMPP, SSH and NFS. The design will combine
  existing protocols, specifically the Extensible Authentication Protocol
  (EAP - RFC 3748), Authentication, Authorization and Account Protocols
  (RADIUS - RFC 2865 and Diameter - RFC 3588), and the Security Assertion
  Markup Language (SAML).

  Specifically EAP will be used to authenticate the subject to a trusted
  party, AAA (RADIUS and Diameter) will be used to authenticate and convey
  information from that party to a relying party and SAML and SAML message
  formats are used to carry subject information that can be used for
  authorization and personalization by a relying party. Any change in the
  choices for these three technical roles is out of scope for this charter.


  Initially the working group will focus on using GSS-API (RFC2743) as a
  mechanism for integrating the developed solution for federated identity
  into application protocols but other technologies for application
  interface are in scope of the working group and may be adopted as
  deliverables subject to the normal IETF consensus and (re)charter

  In order to be usable in all current Internet protocols, GSS-API
  mechanism must provide the following features: mutual authentication, key
  confirmation, host-based service naming, per-message tokens ("security
  layers") and channel binding.  Support for Pseudo Random Function (PRF)
  is desirable, and generally feasible whenever per-message tokens are
  supported. As a result, all of those features are required for GSS-API
  mechanisms produced by this WG.  Note also that some of these
  requirements derive from SASL (RFC 4422) applications, which can use GSS-
  API mechanisms through GS2 (RFC5081).

  Other application integration strategies are very likely to mirror these
  constraints.  In particular, host-based service naming, mutual
  authentication and support for channel binding are likely to be important
  for defense against phishing attacks.

  The working group will ensure that any solution developed has technical
  controls for privacy protection.

  Other than a change to its applicability statement and the development of
  EAP mechanisms, the working group may not change EAP, RADIUS or Diameter
  without establishing consensus with the appropriate community within the

  The working group will use the following documents as a starting point
  for its work:

  - draft-howlett-eap-gss-00,
  - draft-howlett-radius-saml-attr-00
  - draft-hartman-gss-eap-naming-00

  Concerns have been raised that additional work is required in keying AAA
  associations in a federated environment. The working group is chartered
  to explore these concerns and if needed, specify protocols that use
  existing AAA key management mechanisms to address these concerns.

  Coordination with other SDOs

  The Working Group will work in conjunction with the IAB to establish
  appropriate liaison relationships with the OASIS Security Services
  Technical Committee (SSTC) and take care that any changes or profiling
  required in SAML can be properly coordinated across the different

  In particular coordination is required with respect to the SAML-RADIUS


  1. Descriptions of applicable use cases (informational).

  2. An architecture that describes how the components of the solution fit
  together to address the use cases and open issues that will require
  future changes to the architecture (informational).

  3. A standards-track update to the EAP applicability statement in RFC
  3748 describing the applicability of EAP to application authentication
  and placing appropriate requirements on this new EAP use case.

  4. A standards-track solution for using EAP methods to provide
  authentication within the application.

  5. A standards-track update to the EMSK root key applicability statement
  in RFC 5295.

  6. A standards-track description of GSS names and name attributes
  required by the solution.

  7. Descriptions of usability and user-interface concerns related to this
  work (informational).

  8. A standards-track protocol for carrying SAML messages in RADIUS and