Re: [kitten] I-D Action: draft-ietf-kitten-pkinit-freshness-01.txt

Sam Hartman <hartmans-ietf@mit.edu> Mon, 04 May 2015 18:56 UTC

Return-Path: <hartmans@mit.edu>
X-Original-To: kitten@ietfa.amsl.com
Delivered-To: kitten@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 207A11ACDC7 for <kitten@ietfa.amsl.com>; Mon, 4 May 2015 11:56:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.235
X-Spam-Level:
X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_SOFTFAIL=0.665] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7tPO_hLcGR1X for <kitten@ietfa.amsl.com>; Mon, 4 May 2015 11:56:04 -0700 (PDT)
Received: from mail.painless-security.com (mail.painless-security.com [23.30.188.241]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 550731ACD63 for <kitten@ietf.org>; Mon, 4 May 2015 11:56:04 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mail.painless-security.com (Postfix) with ESMTP id 70372206FF; Mon, 4 May 2015 14:54:55 -0400 (EDT)
Received: from mail.painless-security.com ([127.0.0.1]) by localhost (mail.suchdamage.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1-aYlC3aoQSw; Mon, 4 May 2015 14:54:55 -0400 (EDT)
Received: from carter-zimmerman.suchdamage.org (unknown [10.1.10.105]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.painless-security.com (Postfix) with ESMTPS; Mon, 4 May 2015 14:54:54 -0400 (EDT)
Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id C2DC3812D1; Mon, 4 May 2015 14:56:01 -0400 (EDT)
From: Sam Hartman <hartmans-ietf@mit.edu>
To: Greg Hudson <ghudson@mit.edu>
References: <20150307024328.31740.75123.idtracker@ietfa.amsl.com> <alpine.GSO.1.10.1503111348200.3953@multics.mit.edu> <alpine.GSO.1.10.1503111405000.3953@multics.mit.edu> <5500AD51.5030902@mit.edu> <alpine.GSO.1.10.1503111725490.3953@multics.mit.edu> <BL2PR03MB2124E0360819B3162C9E48DD0060@BL2PR03MB212.namprd03.prod.outlook.com> <tsl38590yn0.fsf@mit.edu> <BL2PR03MB2127227DDC7941010BC26A6D0070@BL2PR03MB212.namprd03.prod.outlook.com> <550339DA.6000109@mit.edu> <BL2PR03MB21281E5DBF9A38B16C91338D0E90@BL2PR03MB212.namprd03.prod.outlook.com> <alpine.GSO.1.10.1504291620270.22210@multics.mit.edu> <tslbni0y0d2.fsf@mit.edu> <55478C61.2040601@mit.edu> <tsl4mnsuu3i.fsf@mit.edu> <5547BBE4.4000006@mit.edu>
Date: Mon, 04 May 2015 14:56:01 -0400
In-Reply-To: <5547BBE4.4000006@mit.edu> (Greg Hudson's message of "Mon, 04 May 2015 14:35:16 -0400")
Message-ID: <tslvbg8tbni.fsf@mit.edu>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain
Archived-At: <http://mailarchive.ietf.org/arch/msg/kitten/PfRli3btMc_N2eVKjRPoYYMwQVA>
Cc: "kitten@ietf.org" <kitten@ietf.org>, Michiko Short <michikos@microsoft.com>, Sam Hartman <hartmans-ietf@mit.edu>
Subject: Re: [kitten] I-D Action: draft-ietf-kitten-pkinit-freshness-01.txt
X-BeenThere: kitten@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Common Authentication Technologies - Next Generation <kitten.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/kitten>, <mailto:kitten-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/kitten/>
List-Post: <mailto:kitten@ietf.org>
List-Help: <mailto:kitten-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/kitten>, <mailto:kitten-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 04 May 2015 18:56:05 -0000

>>>>> "Greg" == Greg Hudson <ghudson@mit.edu> writes:

    Greg> On 05/04/2015 01:32 PM, Sam Hartman wrote:
    Greg> I think it's a little unfortunate, but if it will make
    Greg> Microsoft's life easier, an few extra bytes in each AS request
    Greg> won't break the world.
    >> 
    >> Well, it is kind of what RFC 4120 anticipates you'll do whenever
    >> you introduce a new option.

    Greg> The freshness token is a padata value in the method-data of a
    Greg> PREAUTH_REQUIRED error.  To an old client, it looks like like
    Greg> an unsupported preauth mech or a piece of unrecognized
    Greg> informational preauth data (which is what it is).  We have
    Greg> never required clients to indicate support for either of these
    Greg> things.  For instance, RFC 4120 requires KDCs to send
    Greg> ETYPE-INFO2 in method-data even if the request does not use a
    Greg> new enctype.

We require clients to indicate support for FAST and permit them to
indicate support for pkinit.
My point is that RFC 4120 anticipates people indicating support for
features when a KDC might wish to know whether the feature is supported
prior to generating a response.