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

Sam Hartman <> Wed, 18 July 2012 17:05 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id EB25E21F8739; Wed, 18 Jul 2012 10:05:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -102.937
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id IoqtIWvzcfz4; Wed, 18 Jul 2012 10:05:39 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 75CD021F8733; Wed, 18 Jul 2012 10:05:39 -0700 (PDT)
Received: from ( []) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by (Postfix) with ESMTPS id 5451C203BA; Wed, 18 Jul 2012 13:06:49 -0400 (EDT)
Received: by (Postfix, from userid 8042) id 1EA5A41F0; Wed, 18 Jul 2012 13:06:05 -0400 (EDT)
From: Sam Hartman <>
To: Jeffrey Hutzelman <>
References: <> <> <>
Date: Wed, 18 Jul 2012 13:06:05 -0400
In-Reply-To: <> (Jeffrey Hutzelman's message of "Wed, 18 Jul 2012 12:45:22 -0400")
Message-ID: <>
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:,, Sam Hartman <hartmans-ietf@MIT.EDU>, The IESG <>, secdir <>
Subject: Re: [secdir] secdir review of draft-ietf-abfab-gss-eap-08
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Security Area Directorate <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 18 Jul 2012 17:05:40 -0000

>>>>> "Jeffrey" == Jeffrey Hutzelman <> writes:


    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.