IETF Logo Mail Archive

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

Michiko Short <michikos@microsoft.com> Wed, 18 March 2015 20:07 UTC

Return-Path: <michikos@microsoft.com>
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 00D9A1A00FA for <kitten@ietfa.amsl.com>; Wed, 18 Mar 2015 13:07:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.902
X-Spam-Level:
X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
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 bdRvLhaEtGMR for <kitten@ietfa.amsl.com>; Wed, 18 Mar 2015 13:07:19 -0700 (PDT)
Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0731.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:731]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E086D1A1B92 for <kitten@ietf.org>; Wed, 18 Mar 2015 13:07:18 -0700 (PDT)
Received: from BL2PR03MB212.namprd03.prod.outlook.com (10.255.230.151) by BL2PR03MB209.namprd03.prod.outlook.com (10.255.230.140) with Microsoft SMTP Server (TLS) id 15.1.118.15; Wed, 18 Mar 2015 20:06:57 +0000
Received: from BL2PR03MB212.namprd03.prod.outlook.com ([169.254.15.76]) by BL2PR03MB212.namprd03.prod.outlook.com ([169.254.15.76]) with mapi id 15.01.0112.000; Wed, 18 Mar 2015 20:06:57 +0000
From: Michiko Short <michikos@microsoft.com>
To: Greg Hudson <ghudson@mit.edu>, Sam Hartman <hartmans-ietf@mit.edu>
Thread-Topic: [kitten] I-D Action: draft-ietf-kitten-pkinit-freshness-01.txt
Thread-Index: AQHQXZiJ07vPZrskK0qMbSTckV74FZ0an2mggAAi1zCAAAm3AIAH5dPg
Date: Wed, 18 Mar 2015 20:06:57 +0000
Message-ID: <BL2PR03MB21236F79531492C086035BDD0000@BL2PR03MB212.namprd03.prod.outlook.com>
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>
In-Reply-To: <550339DA.6000109@mit.edu>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [2001:4898:80e8:ed31::3]
authentication-results: mit.edu; dkim=none (message not signed) header.d=none;
x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BL2PR03MB209;
x-forefront-antispam-report: BMV:1; SFV:NSPM; SFS:(10019020)(6009001)(13464003)(479174004)(377454003)(51704005)(93886004)(2656002)(551544002)(230783001)(76176999)(54356999)(50986999)(2171001)(87936001)(46102003)(19580405001)(19580395003)(106116001)(33656002)(86362001)(99286002)(62966003)(86612001)(76576001)(122556002)(2950100001)(92566002)(77156002)(2900100001)(102836002)(40100003)(74316001)(3826002); DIR:OUT; SFP:1102; SCL:1; SRVR:BL2PR03MB209; H:BL2PR03MB212.namprd03.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en;
x-microsoft-antispam-prvs: <BL2PR03MB209C20D7EAE2935AAF5A198D0000@BL2PR03MB209.namprd03.prod.outlook.com>
x-exchange-antispam-report-test: UriScan:;
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(5002010)(5005006); SRVR:BL2PR03MB209; BCL:0; PCL:0; RULEID:; SRVR:BL2PR03MB209;
x-forefront-prvs: 051900244E
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: microsoft.onmicrosoft.com
X-MS-Exchange-CrossTenant-originalarrivaltime: 18 Mar 2015 20:06:57.6578 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BL2PR03MB209
Archived-At: <http://mailarchive.ietf.org/arch/msg/kitten/sXBWz8jLJgxI2xTF9OeveoRnkmk>
Cc: "kitten@ietf.org" <kitten@ietf.org>
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: Wed, 18 Mar 2015 20:07:21 -0000

I think a KDC implementation can always choose to send a Freshness token, but that should be an implementation option not a requirement. Having a KDC only send the Freshness Token on client gives the option to limit generating Freshness tokens to just PKInit clients. 

-----Original Message-----
From: Greg Hudson [mailto:ghudson@mit.edu] 
Sent: Friday, March 13, 2015 12:26 PM
To: Michiko Short; Sam Hartman
Cc: Benjamin Kaduk; kitten@ietf.org
Subject: Re: [kitten] I-D Action: draft-ietf-kitten-pkinit-freshness-01.txt

On 03/13/2015 02:55 PM, Michiko Short wrote:
> Once the tool reopens then I will submit the version without the client request behavior. 
> 
> [Michiko Short] Creating a freshness token will be a crypto hit on the KDC, so sending freshness tokens to clients who will never use them will negatively impact KDC performance with no gains. If the PKInit client does not explicitly ask for the token, then clients using password authentication will also have freshness tokens generated and sent to them. 

That's worth considering.  Here are my thoughts:

* A freshness token doesn't have to be unique to a request or client; it just has to be unknown to an attacker far in advance of an AS exchange.
 A KDC could compute a new global freshness token every five minutes or so (by encrypting the current time in a TGS key, for instance) and use it for many requests.

* A KDC only needs to send a freshness token if it is offering PKINIT (or a future mechanism which also uses freshness tokens).  I guess it's unusual for that to be a per-client decision by the KDC; typically either the KDC is configured with PKINIT support or it isn't, and it offers PKINIT to all clients if it is.

* Is AES encryption a significant load factor on modern KDCs?  I don't have numbers for our KDC at the moment.  It probably depends a lot on whether AES-NI can be used.

* If a client wants to save the KDC the effort of computing a freshness token, it has to decide ahead of time whether it might be able to use PKINIT (or a future mechanism which also uses freshness tokens).  This is generally possible, but maybe a bit complex.

v2.23.0 | Report a Bug | By Email