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

Sam Hartman <hartmans-ietf@mit.edu> Wed, 18 July 2012 17:05 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 EB25E21F8739; Wed, 18 Jul 2012 10:05:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.937
X-Spam-Level:
X-Spam-Status: No, score=-102.937 tagged_above=-999 required=5 tests=[AWL=-0.672, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IoqtIWvzcfz4; Wed, 18 Jul 2012 10:05:39 -0700 (PDT)
Received: from permutation-city.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by ietfa.amsl.com (Postfix) with ESMTP id 75CD021F8733; Wed, 18 Jul 2012 10:05:39 -0700 (PDT)
Received: from carter-zimmerman.suchdamage.org (carter-zimmerman.suchdamage.org [69.25.196.178]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.suchdamage.org (Postfix) with ESMTPS id 5451C203BA; Wed, 18 Jul 2012 13:06:49 -0400 (EDT)
Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 1EA5A41F0; Wed, 18 Jul 2012 13:06:05 -0400 (EDT)
From: Sam Hartman <hartmans-ietf@mit.edu>
To: Jeffrey Hutzelman <jhutz@cmu.edu>
References: <1342587005.7190.56.camel@minbar.fac.cs.cmu.edu> <tsl1uk9njg6.fsf@mit.edu> <1342629922.17068.36.camel@destiny.pc.cs.cmu.edu>
Date: Wed, 18 Jul 2012 13:06:05 -0400
In-Reply-To: <1342629922.17068.36.camel@destiny.pc.cs.cmu.edu> (Jeffrey Hutzelman's message of "Wed, 18 Jul 2012 12:45:22 -0400")
Message-ID: <tslfw8pm22q.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: draft-ietf-abfab-gss-eap.all@tools.ietf.org, abfab@ietf.org, Sam Hartman <hartmans-ietf@MIT.EDU>, The IESG <iesg@ietf.org>, secdir <secdir@ietf.org>
Subject: Re: [secdir] secdir review of draft-ietf-abfab-gss-eap-08
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, 18 Jul 2012 17:05:40 -0000

>>>>> "Jeffrey" == Jeffrey Hutzelman <jhutz@cmu.edu> writes:


Yes.


    >> 
    Jeffrey> Why define a family of mechanisms parameterized by enctype, instead of
    Jeffrey> defining a single mechanism, specifying a mandatory-to-implement enctype,
    Jeffrey> and negotiating the enctype to be used as part of context establishment?
    Jeffrey> This would also work around a situation with SASL mechanism naming, which
    Jeffrey> is that you are effectively defining an entire family of GSs-API mechs but
    Jeffrey> specifying SASL mechanism names for only one member of that family.  This
    Jeffrey> means that either other enctypes cannot be used at all, or else they must
    Jeffrey> forever have non-friendly names encoded as per RFC5801 section 3.1.
    >> 
    Jeffrey> Alternately, you could register a family of SASL mechansim names, of the
    Jeffrey> form EAP-<enc> and EAP-<enc>-PLUS, where <enc> is a numeric enctype.  This
    Jeffrey> is a bit uglier than EAP-AES128[-PLUS], but prevents future
    Jeffrey> interoperability problems due to SASL mechanism name mismatches and at
    Jeffrey> least is reversible, unlike the RFC5801 section 3.1 encoding.
    >> 
    >> I think this one is informed WG consensus. One reason to do things as we
    >> have is that you run into an interop problem if policy or algorithm
    >> evolution ever disables a mandatory enctype.
    >> I think the implications have been discussed.

    Jeffrey> OK, fair enough.

    >> Since the SASL registry is FCFS, I don't see a problem with having to
    >> register each enctype separately to get a friendly name.

    Jeffrey> The only problem is that if someone starts using that enctype with this
    Jeffrey> mechanism before the friendly name is registered, they end up using the
    Jeffrey> unfriendly name, and then you eventually have a false interop problem,
    Jeffrey> where two implementations both support that enctype but don't know it.
    Jeffrey> Avoiding this is why we wanted friendly names registered when the
    Jeffrey> mechanism is defined, but RFC5801 doesn't really contemplate mechanism
    Jeffrey> families like this one.  


My assumption is that a implementation  will only include things for
which it has a friendly name in indicate_mechs output.