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

Benjamin Kaduk <kaduk@MIT.EDU> Wed, 29 April 2015 20:25 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 682591A1A78 for <>; Wed, 29 Apr 2015 13:25:07 -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 KT1GlQBW9vYy for <>; Wed, 29 Apr 2015 13:25:05 -0700 (PDT)
Received: from ( []) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id EB58B1A1A7C for <>; Wed, 29 Apr 2015 13:25:04 -0700 (PDT)
X-AuditID: 1209190e-f79a76d000000d1b-4c-55413e1fff41
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 C5.3A.03355.F1E31455; Wed, 29 Apr 2015 16:25:03 -0400 (EDT)
Received: from ( []) by (8.13.8/8.9.2) with ESMTP id t3TKP27I030754; Wed, 29 Apr 2015 16:25:03 -0400
Received: from ( []) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by (8.13.8/8.12.4) with ESMTP id t3TKP0QD007920 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 29 Apr 2015 16:25:02 -0400
Received: (from kaduk@localhost) by ( id t3TKP09K027135; Wed, 29 Apr 2015 16:25:00 -0400 (EDT)
Date: Wed, 29 Apr 2015 16:25:00 -0400 (EDT)
From: Benjamin Kaduk <kaduk@MIT.EDU>
To: Michiko Short <>
In-Reply-To: <>
Message-ID: <>
References: <> <> <> <> <> <> <> <> <> <>
User-Agent: Alpine 1.10 (GSO 962 2008-03-14)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrOIsWRmVeSWpSXmKPExsUixG6nritv5xhq8GiqhcXXtgdsFkc3r2Kx +NfN58DssWTJTyaP1h1/2T1WTj3NHsAcxWWTkpqTWZZapG+XwJWx/cELloK3XBU9uy+wNTCe 5+hi5OSQEDCR+DrnGjuELSZx4d56ti5GLg4hgcVMEosWr2aFcDYySkzt6WeHcA4xSTQePcMC 4TQwSqyZ+5cZpJ9FQFvi7r5mJhCbTUBFYuabjWwgtoiAlsSHC6dZQGxmgRKJ5edvgNnCAt4S D7fNBNvNKRAtsWrvXLA4r4CjxIwd/WC2kMAiFomTp1RBbFEBHYnV+6dA1QhKnJz5BGqmlsTy 6dtYJjAKzkKSmoUktYCRaRWjbEpulW5uYmZOcWqybnFyYl5eapGusV5uZoleakrpJkZQ+HJK 8u1g/HpQ6RCjAAejEg/vBmWHUCHWxLLiytxDjJIcTEqivGutHUOF+JLyUyozEosz4otKc1KL DzFKcDArifAe0APK8aYkVlalFuXDpKQ5WJTEeTf94AsREkhPLEnNTk0tSC2CycpwcChJ8H63 AWoULEpNT61Iy8wpQUgzcXCCDOcBGv4FpIa3uCAxtzgzHSJ/ilFRSpz3DUhCACSRUZoH1wtL L68YxYFeEebVtQWq4gGmJrjuV0CDmYAGn7/lADK4JBEhJdXAGP8pfiHXd6uCsLeidXOmdlhe 9DyXx7DwUQWrg9FU+/k50zfzHn6yXWWjUZjfgacMD2ecYGmtXJNWV7Ipykr2pfPqw7tWXLsY 97LS852wwsJ3Al0qiTtt5MrKmDu/8xTxuB6dWfL8XPyiH93cU5LlFvMLRc6PvzCrfM+W3sT9 k1ae4e7ZPkFguRJLcUaioRZzUXEiACpUc3MKAwAA
Archived-At: <>
Cc: "" <>, Sam Hartman <hartmans-ietf@MIT.EDU>
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: Wed, 29 Apr 2015 20:25:07 -0000

On Mon, 27 Apr 2015, Michiko Short wrote:

> Time for me to publish a new draft since this one is expiring.
> We found a use case in our implementation of PKInit where the client
> must request a freshness token or else they will get a principal not
> found error, so we need to keep the client behavior. I would prefer to
> not make that MS-PKCA Microsoft extension. It there any problem with
> keeping the client language as is? Also we would prefer to keep token
> generation limited to the public key case. Yes, we are hoping to expand
> the number of customers who use PKInit, but there will still be
> customers for a while who do not, have old servers, etc.

I think I've lost track of which client behavior is in question -- is this
just the part where the client sends an empty PA_AS_FRESHNESS padata to
indicate support of freshness tokens and prompt the KDC to send one (in
contrast to having the KDC always send a freshness token on all requests
or all requests being offered PKINIT)?

It does not seem like a bad scheme to me in the abstract, but it seems
that if we permit it, than all clients wishing to use freshness tokens
must be prepared to implement it, in case they encounter a KDC which does
not proactively provide freshness tokens.  That's probably fine, but we
should consciously take that choice instead of just falling into it.