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

Sam Hartman <hartmans-ietf@mit.edu> Wed, 03 October 2012 21:45 UTC

Return-Path: <hartmans@mit.edu>
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 D61DC1F0C4C; Wed, 3 Oct 2012 14:45:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -96.875
X-Spam-Level:
X-Spam-Status: No, score=-96.875 tagged_above=-999 required=5 tests=[AWL=-1.163, BAYES_00=-2.599, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FM_DDDD_TIMES_2=1.999, HELO_DYNAMIC_IPADDR=2.426, RDNS_DYNAMIC=0.1, 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 T8tr1FBVp4Zf; Wed, 3 Oct 2012 14:45:53 -0700 (PDT)
Received: from ec2-23-21-227-93.compute-1.amazonaws.com (ec2-23-21-227-93.compute-1.amazonaws.com [23.21.227.93]) by ietfa.amsl.com (Postfix) with ESMTP id 58ED81F0421; Wed, 3 Oct 2012 14:45:52 -0700 (PDT)
Received: from carter-zimmerman.suchdamage.org (c-98-217-126-210.hsd1.ma.comcast.net [98.217.126.210]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.suchdamage.org (Postfix) with ESMTPS id 6783720183; Wed, 3 Oct 2012 17:45:39 -0400 (EDT)
Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 2F644414A; Wed, 3 Oct 2012 17:45:42 -0400 (EDT)
From: Sam Hartman <hartmans-ietf@mit.edu>
To: Richard Barnes <rbarnes@bbn.com>
References: <65E7D30E-A5B2-4980-BB9F-9784AF7FF89F@bbn.com>
Date: Wed, 03 Oct 2012 17:45:42 -0400
In-Reply-To: <65E7D30E-A5B2-4980-BB9F-9784AF7FF89F@bbn.com> (Richard Barnes's message of "Wed, 3 Oct 2012 17:11:30 -0400")
Message-ID: <tsld30zjkl5.fsf@mit.edu>
User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/22.3 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Cc: IETF discussion list <ietf@ietf.org>, IESG IESG <iesg@ietf.org>, draft-ietf-abfab-gss-eap-naming@tools.ietf.org, SECDIR <secdir@ietf.org>
Subject: Re: [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:45:54 -0000

>>>>> "Richard" == Richard Barnes <rbarnes@bbn.com> writes:

    Richard> I have reviewed this document as part of the security
    Richard> directorate's ongoing effort to review all IETF documents
    Richard> being processed by the IESG.  These comments were written
    Richard> primarily for the benefit of the security area directors.
    Richard> Document editors and WG chairs should treat these comments
    Richard> just like any other last call comments.
    Richard> text that causes me concern is the following: " These names
    Richard> MUST NOT be used for attributes issued by a party other
    Richard> than one closely associated with the source of credentials
    Richard> unless the source of credentials is re-asserting these
    Richard> attributes.  " The use of "MUST NOT" here implies that the
    Richard> intent is for the application reading attributes to have
    Richard> assurance that they are "closely associated with the
    Richard> source".  However, the application has no way of verifying
    Richard> whether this MUST NOT has been adhered to, so the entity
    Richard> setting names is trusted in this regard.  The document
    Richard> should note this, and the corresponding risk that the namer
    Richard> will break this MUST NOT.  This risk is hard for the reader
    Richard> to evaluate because (AFAICT) the document doesn't specify
    Richard> who sets names in this system.  (Passive voice considered
    Richard> harmful.)

Yeah, we need more clarity around that as everyone who reads the
document brings up this issue.  I think it's OK because enforcing that
MUST NOT is a spec design issue in draft-ietf-abfab-aaa-saml, and a
couple of drafts in kitten.  I.E. if the IETF does its job, then
applications can depend on that MUST NOT being enforced.  We need to
make it more clear and we need to be careful when reviewing those other
specs.

So, I'll work on proposing text for this, but I think this is a clarity
issue rather than a security problem.