Skip to main content

Last Call Review of draft-ietf-abfab-usecases-
review-ietf-abfab-usecases-secdir-lc-weis-2012-08-10-00

Request Review of draft-ietf-abfab-usecases
Requested revision No specific revision (document currently at 05)
Type Last Call Review
Team Security Area Directorate (secdir)
Deadline 2012-08-06
Requested 2012-08-01
Authors Rhys Smith
I-D last updated 2012-08-10
Completed reviews Secdir Last Call review of -?? by Brian Weis
Genart Last Call review of -?? by Suresh Krishnan
Assignment Reviewer Brian Weis
State Completed
Request Last Call review on draft-ietf-abfab-usecases by Security Area Directorate Assigned
Result Ready
Completed 2012-08-10
review-ietf-abfab-usecases-secdir-lc-weis-2012-08-10-00
I have reviewed this document as part of the security directorate's ongoing
effort to review all IETF documents being processed by the IESG. These comments
were written primarily for the benefit of the security area directors. Document
editors and WG chairs should treat these comments just like any other last call
comments.

This document describes several scenarios in which federated access could be
useful to non-web protocols. The use cases include federation between
supplier/consumers of resources (e.g., cloud services, high performance
computing, and grid), the sharing of content or resources between an
organization and selected outsiders (e.g., databases and directories, and
printing), and cooperation between multiple organizations (e.g., smart
objects). Each use case discusses the movement from non-federated identity to
the use of an ABFAB architecture.

The security considerations section states that necessary security
considerations will be documented as part of subsequent protocol
specifications. But typically there are higher level security considerations to
use cases unrelated to the details of protocols. In this case there are likely
effects of federation on the various actors within the case entities. I note
above that there are several classes of use cases, each of which has a
different trust model and set of actors either providing or validating
credentials. If converting to the ABFAB architecture in any of the use cases
results in a change of security considerations (positive or negative) from the
pre-existing non-federated case then it would be helpful to note this to
readers considering adopting one of the ABFAB use cases.

For example, when in federation between supplier/consumers of resources are
there changes in the trust model when a supplier re-designs/re-factors their
environment to use federation? Are there security considerations for a consumer
moving to federated identities from directly supplying IDs/authentication
material to previously non-federated services? This sort of characterization
would be valuable in understanding the effects of transitioning to federation.
I'm not suggesting a full blown threat analysis (although that would be
useful!) but rather a summary of how federation affects the security of both a
provider and consumer of a resource in the various use cases.

Brian