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

Brian Weis <bew@cisco.com> Tue, 07 August 2012 01:23 UTC

Return-Path: <bew@cisco.com>
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id 376AB21F86BE; Mon, 6 Aug 2012 18:23:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -110.599
X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id Vz78n7yWpItI; Mon, 6 Aug 2012 18:23:07 -0700 (PDT)
Received: from mtv-iport-3.cisco.com (mtv-iport-3.cisco.com []) by ietfa.amsl.com (Postfix) with ESMTP id 4ECAD21F868A; Mon, 6 Aug 2012 18:23:07 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=bew@cisco.com; l=2459; q=dns/txt; s=iport; t=1344302587; x=1345512187; h=from:content-transfer-encoding:subject:date:message-id: cc:to:mime-version; bh=DqArR7PeDv7TRXSPasFUv3jm+evbr/wQeebxrsBzasM=; b=YzBddOhfyfhAWq8XtrjwcyF7EkcQdAFgNEul80G3+DiAIcTu7Qq0TnHH o+HlU9G+Xi7eIXZ6CW4brVd4vbXYK1pA1ERoIoGTaREhPc8ZNLs5slUHA cZxHZIcsn/pFa/VH1aaDmHwNUPwPmmOHN1kVMGqmyHP6NQaHYFduwoBsY 8=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Av0EAHltIFCrRDoG/2dsb2JhbAA8CblRgQeCOQEnPy19FAE0h2oBmyugOotbhXxgA4hNjHyOJoFmgn+BOCM
X-IronPort-AV: E=Sophos;i="4.77,723,1336348800"; d="scan'208";a="51708169"
Received: from mtv-core-1.cisco.com ([]) by mtv-iport-3.cisco.com with ESMTP; 07 Aug 2012 01:23:07 +0000
Received: from printer-xx-6080ee.cisco.com (printer-xx-6080ee.cisco.com []) by mtv-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id q771N6Cq014351; Tue, 7 Aug 2012 01:23:06 GMT
From: Brian Weis <bew@cisco.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: quoted-printable
Date: Mon, 6 Aug 2012 18:23:27 -0700
Message-Id: <F0A4343A-B71A-4314-87C5-9D53836C1138@cisco.com>
To: secdir@ietf.org, The IESG <iesg@ietf.org>
Mime-Version: 1.0 (Apple Message framework v1278)
X-Mailer: Apple Mail (2.1278)
Cc: draft-ietf-abfab-usecases.all@tools.ietf.org
Subject: [secdir] Secdir review of draft-ietf-abfab-usecases-03
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/secdir>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 07 Aug 2012 01:23:08 -0000

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.