Last Call Review of draft-ietf-abfab-usecases-
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