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

Sam Hartman <hartmans-ietf@mit.edu> Thu, 04 October 2012 21:06 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 8C45311E80A3; Thu, 4 Oct 2012 14:06:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -96.832
X-Spam-Level:
X-Spam-Status: No, score=-96.832 tagged_above=-999 required=5 tests=[AWL=-1.120, 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 85GFcdWQyoJz; Thu, 4 Oct 2012 14:06:32 -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 EAD7611E809A; Thu, 4 Oct 2012 14:06:31 -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 55FED2010F; Thu, 4 Oct 2012 17:06:18 -0400 (EDT)
Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 19ECE414A; Thu, 4 Oct 2012 17:06:19 -0400 (EDT)
From: Sam Hartman <hartmans-ietf@mit.edu>
To: Richard Barnes <rbarnes@bbn.com>
References: <65E7D30E-A5B2-4980-BB9F-9784AF7FF89F@bbn.com>
Date: Thu, 04 Oct 2012 17:06:19 -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: <tslr4pec5h0.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: Thu, 04 Oct 2012 21:06:35 -0000

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

    Richard> The security considerations in this document are difficult
    Richard> to evaluate because the general architecture is unclear to
    Richard> me, e.g., who attaches these names to things and who reads
    Richard> them.  (The naming scheme itself seems well defined.)  The
    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.)

I'd like to push back on this.
Text was adding in 05 making it clear that  in designing mechanisms
specifications we need to enforce that MUST not.
The full paragraph in question is as follows:

   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 the attributes.  For example, a
   source of credentials can consult whatever sources of attributes it
   chooses, but acceptors can assume attributes in the federated context
   are from the source of credentials.  This requirement is typically


   enforced in mechanism specifications.  For example
   [I-D.ietf-abfab-aaa-saml] provides enough information thatwe know the
   attributes it carries today are in the federated context.  Similarly,
   we know that the requirements of this paragraph are met by SAML
   mechanisms where the assertion is the means of authentication.


I actually think that's reasonably easy to analyze and that we're in the
process of doing the analysis for draft-ietf-abfab-aaa-saml and have
done the analysis for other mechanisms.