* WGs marked with an * asterisk has had at least one new draft made available during the last 5 days

Abfab Status Pages

Application Bridging for Federated Access Beyond web (Concluded WG)
Sec Area: Roman Danyliw, Benjamin Kaduk | 2010-Oct-12 — 2016-Sep-30 
Chairs
 
 


2015-06-15 charter

Application Bridging for Federated Access Beyond web (abfab)
------------------------------------------------------------

 Charter

 Current Status: Active

 Chairs:
     Leif Johansson <leifj@sunet.se>
     Klaas Wierenga <kwiereng@cisco.com>

 Security Area Directors:
     Stephen Farrell <stephen.farrell@cs.tcd.ie>
     Kathleen Moriarty <Kathleen.Moriarty.ietf@gmail.com>

 Security Area Advisor:
     Stephen Farrell <stephen.farrell@cs.tcd.ie>

 Mailing Lists:
     General Discussion: abfab@ietf.org
     To Subscribe:       https://www.ietf.org/mailman/listinfo/abfab
     Archive:            https://mailarchive.ietf.org/arch/browse/abfab/

Description of Working Group:


    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
    Diameter.




Goals and Milestones:
  Done     - Submit Internet draft describing applicable use cases as initial WG item.
  Done     - Submit Internet draft describing the architecture as initial WG item.
  Done     - Submit Internet draft that updates the EAP applicability statement as initial WG item.
  Done     - Submit Internet draft for using EAP methods to provide authentication within the application as initial WG item.
  Done     - Submit Internet draft that describes GSS names and name attributes as initial WG item.
  Done     - Submit Internet draft for SAML messages in Radius and Diameter as an initial WG item.
  Done     - Submit Internet draft describing applicable use cases to the IESG for consideration.
  Done     - Submit Internet draft that updates the EAP applicability statement to the IESG for consideration.
  Done     - Submit Internet draft for using EAP methods to provide authentication within the application to the IESG for consideration.
  Done     - Submit Internet draft that describes GSS names and name attributes to the IESG for consideration.
  Sep 2013 - Submit Internet draft describing the architecture to the IESG for consideration.
  Oct 2013 - Submit Internet draft for usability and user-interface concerns as initial WG item.
  Dec 2013 - Submit Internet draft for usability and user-interface concerns to the IESG for consideration.
  Dec 2013 - Submit Internet draft for SAML messages in Radius and Diameter to the IESG for consideration.


All charter page changes, including changes to draft-list, rfc-list and milestones:



Generated from PyHt script /wg/abfab/charters.pyht Latest update: 24 Oct 2012 16:51 GMT -