[secdir] secdir review of draft-ietf-abfab-gss-eap-naming-05

Richard Barnes <rbarnes@bbn.com> Wed, 03 October 2012 21:11 UTC

Return-Path: <rbarnes@bbn.com>
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 04F431F0C49; Wed, 3 Oct 2012 14:11:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.504
X-Spam-Level:
X-Spam-Status: No, score=-106.504 tagged_above=-999 required=5 tests=[AWL=0.095, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uq5jF8Evpyw4; Wed, 3 Oct 2012 14:11:42 -0700 (PDT)
Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by ietfa.amsl.com (Postfix) with ESMTP id 2E6191F0421; Wed, 3 Oct 2012 14:11:42 -0700 (PDT)
Received: from ros-dhcp192-1-51-103.bbn.com ([192.1.51.103]:60631) by smtp.bbn.com with esmtps (TLSv1:AES128-SHA:128) (Exim 4.77 (FreeBSD)) (envelope-from <rbarnes@bbn.com>) id 1TJWE6-000Fjh-MP; Wed, 03 Oct 2012 17:11:30 -0400
From: Richard Barnes <rbarnes@bbn.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: quoted-printable
Date: Wed, 3 Oct 2012 17:11:30 -0400
Message-Id: <65E7D30E-A5B2-4980-BB9F-9784AF7FF89F@bbn.com>
To: SECDIR <secdir@ietf.org>, IESG IESG <iesg@ietf.org>, IETF discussion list <ietf@ietf.org>
Mime-Version: 1.0 (Apple Message framework v1283)
X-Mailer: Apple Mail (2.1283)
Cc: draft-ietf-abfab-gss-eap-naming@tools.ietf.org
Subject: [secdir] secdir review of draft-ietf-abfab-gss-eap-naming-05
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: Wed, 03 Oct 2012 21:11:48 -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 defines a method for assigning names to information from RADIUS and GSS-EAP, in particular SAML attributes received via the latter.

The security considerations in this document are difficult to evaluate because the general architecture is unclear to me, e.g., who attaches these names to things and who reads them.  (The naming scheme itself seems well defined.)  The text that causes me concern is the following:
"
These names MUST NOT be used for attributes issued by a party other than one closely associated with the source of credentials unless the source of credentials is re-asserting these attributes.
"
The use of "MUST NOT" here implies that the intent is for the application reading attributes to have assurance that they are "closely associated with the source".  However, the application has no way of verifying whether this MUST NOT has been adhered to, so the entity setting names is trusted in this regard.  The document should note this, and the corresponding risk that the namer will break this MUST NOT.  This risk is hard for the reader to evaluate because (AFAICT) the document doesn't specify who sets names in this system.  (Passive voice considered harmful.)  

If the names did not have this implied security semantic, then the identity of the namer wouldn't be an issue.  Then this document could just define the format of the names and move on.

This is a nonsense MUST: "a service MUST make a policy decision"

Editorial:
Page 7: "thatwe know"
Page 8: "MAy be absent" (or is this an update to RFC 2119?  :) )
Page 11: "mechansisms are permitted"
Page 13: "Sam hartman"