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

Greg Hudson <> Fri, 13 March 2015 19:26 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id C59031A1B59 for <>; Fri, 13 Mar 2015 12:26:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.211
X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id XvXTg96QEq9N for <>; Fri, 13 Mar 2015 12:26:28 -0700 (PDT)
Received: from ( []) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id F27EC1A1AFC for <>; Fri, 13 Mar 2015 12:26:27 -0700 (PDT)
X-AuditID: 1209190f-f79546d000007593-01-550339e2e35e
Received: from ( []) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by (Symantec Messaging Gateway) with SMTP id 9B.B4.30099.2E933055; Fri, 13 Mar 2015 15:26:26 -0400 (EDT)
Received: from ( []) by (8.13.8/8.9.2) with ESMTP id t2DJQKv3005568; Fri, 13 Mar 2015 15:26:21 -0400
Received: from [] ( []) (authenticated bits=0) (User authenticated as ghudson@ATHENA.MIT.EDU) by (8.13.8/8.12.4) with ESMTP id t2DJQIvC029501 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Fri, 13 Mar 2015 15:26:19 -0400
Message-ID: <>
Date: Fri, 13 Mar 2015 15:26:18 -0400
From: Greg Hudson <>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0
MIME-Version: 1.0
To: Michiko Short <>, Sam Hartman <>
References: <> <> <> <> <> <> <> <>
In-Reply-To: <>
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: 8bit
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpileLIzCtJLcpLzFFi42IRYrdT131kyRxqsOWJjsXXtgdsFkc3r2Kx +NfN58DssWTJTyaP1h1/2T1WTj3NHsAcxWWTkpqTWZZapG+XwJWx7M4PtoJnPBUzLx1hamCc wdXFyMkhIWAi8X79ZXYIW0ziwr31bF2MXBxCAouZJPae6WeHcDYySix7/xkqc4RJYl/PNSaQ Fl4BNYmTP2ezgNgsAqoSu6buBIuzCShLrN+/FSwuKhAmMXvdRUaIekGJkzOfgMVFBCIkPv9q BKtnFnCXOP/zJVANB4ewgLfE6zW6ELs2M0vc2b6BDaSGUyBaYtqjs4wQ9XoSO67/YoWw5SWa t85mnsAoOAvJillIymYhKVvAyLyKUTYlt0o3NzEzpzg1Wbc4OTEvL7VI10QvN7NELzWldBMj KKg5Jfl3MH47qHSIUYCDUYmHt6OKKVSINbGsuDL3EKMkB5OSKO8TVeZQIb6k/JTKjMTijPii 0pzU4kOMEhzMSiK8jYpAOd6UxMqq1KJ8mJQ0B4uSOO+mH3whQgLpiSWp2ampBalFMFkZDg4l CV5uYPQKCRalpqdWpGXmlCCkmTg4QYbzAA3faQEyvLggMbc4Mx0if4pRUUqclx2kWQAkkVGa B9cLSzqvGMWBXhHmjQRp5wEmLLjuV0CDmYAG109nAhlckoiQkmpgNC56k2YbO3118HJ7dpap CZcvTt3A4VzEqBw9LWrRFttv/Lv2L2h5dLW1w85wTtCfBQknuO23dm55/j/13s8Jy3rXOitO 0XzJOIPpuF26lmjxqy8mpT9+tl3/zXi9ZL76bL0p7yZt7c5JS4z86C6g8XTXgkO2vr031F/I 7ozfsXlqlcW2v+d6LyqxFGckGmoxFxUnAgB32pyUFQMAAA==
Archived-At: <>
Cc: "" <>
Subject: Re: [kitten] I-D Action: draft-ietf-kitten-pkinit-freshness-01.txt
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Common Authentication Technologies - Next Generation <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 13 Mar 2015 19:26:29 -0000

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.