[secdir] Secdir review of draft-ietf-abfab-usecases-03

[Brian Weis <[e-mail]>]

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