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.    
Constraints   -----------     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   process.     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   IETF.     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   organizations.     In
particular coordination is required with respect to the SAML-RADIUS  
binding.     Deliverables   ------------     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