Subject: [abfab] Fwd: Secdir review of draft-ietf-abfab-usecases-03

From: Stephen Farrell <[email-masked]>
Date: Wed, 08 Aug 2012 17:23:37 +0100

Just posting to abfab list for visibility there.

S.

-------- Original Message --------
Subject: Secdir review of draft-ietf-abfab-usecases-03
Date: Mon, 6 Aug 2012 18:23:27 -0700
From: Brian Weis <[email-masked]>
To: [email-masked], The IESG <[email-masked]>
CC: [email-masked]

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

---

From: Sam Hartman <[email-masked]>
Date: Wed, 08 Aug 2012 13:48:40 -0400

I wonder whether addressing the higher-level security issues in
abfab-arch makes more sense.
It seems like the consideractions are architecture not use-case
specific.

---

From: "Jim Schaad" <[email-masked]>
Date: Wed, 8 Aug 2012 18:48:10 -0700

That would make sense to me.  And I am already trying to get as many of the
overall items as possible into that document.

Jim

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of Sam Hartman
> Sent: Wednesday, August 08, 2012 10:49 AM
> To: Stephen Farrell
> Cc: <[email-masked]>
> Subject: Re: [abfab] Fwd: Secdir review of draft-ietf-abfab-usecases-03
> 
> I wonder whether addressing the higher-level security issues in abfab-arch
> makes more sense.
> It seems like the consideractions are architecture not use-case specific.
> _______________________________________________
> abfab mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/abfab

---

From: Rhys Smith <[email-masked]>
Date: Wed, 15 Aug 2012 14:59:41 +0100

Thanks for the comments and suggestion. I think I agree with Sam and Jim that this should absolutely be addressed, but is probably better addressed in the arch document, as these are security considerations about using abfab architecture generally.
--
Dr Rhys Smith
Identity, Access, and Middleware Specialist
Cardiff University & Janet - the UK's education and research network

email: [email-masked] / [email-masked]
GPG: 0xDE2F024C