[nfsv4] FW: WG Review: Application Bridging for Federated Access Beyond web (abfab)

["David Harrington" <[e-mail]>]

Hi,

FYI. This proposed WG would address federated security, with NFS as
one proposed target environment.
Please look it over and send any comments to [e-mail] by Tuesday,
October 5, 2010

Thanks,
David Harrington
Director, IETF Transport Area
[e-mail] (preferred for ietf)
[e-mail]
[phone] (cell)


-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On Behalf
Of IESG Secretary
Sent: Tuesday, September 28, 2010 1:00 PM
To: [e-mail]
Cc: [e-mail]
Subject: WG Review: Application Bridging for Federated Access Beyond
web (abfab) 

A new IETF working group has been proposed in the Security Area.  The
IESG has not made any determination as yet. The following draft
charter was submitted, and is provided for informational purposes
only. Please send your comments to the IESG mailing list
([e-mail]) by Tuesday, October 5, 2010.  

Application Bridging for Federated Access Beyond web (abfab)
------------------------------------------------------------
Status: Proposed Working Group
Last updated: 2010-09-16 v7

Chairs
    Leif Johansson <[e-mail]>
    Klaas Wierenga <[e-mail]>

Security Area Directors:
    Sean Turner <[e-mail]>
    Tim Polk <[e-mail]>

Security Area Advisor:
    Sean Turner <[e-mail]>

Mailing Lists:
   General Discussion: [e-mail]
   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.