WG Action: Application Bridging for Federated Access Beyond web (abfab)

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



A new IETF working group has been formed in the Security Area.  For
additional information, please contact the Area Directors or the WG
Chairs.

Application Bridging for Federated Access Beyond web (abfab)
------------------------------------------------------------
Current Status: Active Working Group

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

Security Area Directors:
    Sean Turner <turners@ieca.com>
    Tim Polk <tim.polk@nist.gov>

Security Area Advisor:
    Sean Turner <turners@ieca.com>

Mailing Lists:
   General Discussion: abfab@ietf.org
   To Subscribe: <https://www.ietf.org/mailman/listinfo/abfab>
   Archive: <http://www.ietf.org/mail-archive/web/abfab/>

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

Oct 2010   Submit Internet draft describing applicable use cases
           as initial WG item.

Oct 2010   Submit Internet draft describing the architecture as
           initial WG item.

Oct 2010   Submit Internet draft that updates the EAP applicability
           statement as initial WG item.

Oct 2010   Submit Internet draft for using EAP methods to provide
           authentication within the application as initial WG item.

Oct 2010   Submit Internet draft that updates the EMSK root key
           applicability statement as initial WG item.

Oct 2010   Submit Internet draft that describes GSS names and name
           attributes as initial WG item.

Oct 2010   Submit Internet draft for usability and user-interface
           concerns as initial WG item.

Oct 2010   Submit Internet draft for SAML messages in Radius and
           Diameter as an initial WG item.

Dec 2010   Submit Internet draft describing applicable use cases
           to the IESG for consideration.

Dec 2010   Submit Internet draft describing the architecture to the
           IESG for consideration.

May 2011   Submit Internet draft that updates the EAP applicability
           statement to the IESG for consideration.

May 2011   Submit Internet draft for using EAP methods to provide
           authentication within the application to the IESG for
           consideration.

Aug 2011   Submit Internet draft that updates the EMSK root key
           applicability statement to the IESG for consideration.

Aug 2011   Submit Internet draft that describes GSS names and name
           attributes to the IESG for consideration.

Aug 2011   Submit Internet draft for usability and user-interface
           concerns to the IESG for consideration.

Dec 2011   Submit Internet draft for SAML messages in Radius and
           Diameter to the IESG for consideration.
_______________________________________________
IETF-Announce mailing list
IETF-Announce@ietf.org
https://www.ietf.org/mailman/listinfo/ietf-announce


[Index of Archives]     [IETF]     [IETF Discussion]     [Linux Kernel]

  Powered by Linux