Re: [kitten] draft-ietf-kitten-cammac kdc-verifier omission

Tom Yu <tlyu@mit.edu> Thu, 12 February 2015 23:13 UTC

Return-Path: <tlyu@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 D1C061A1B03 for <kitten@ietfa.amsl.com>; Thu, 12 Feb 2015 15:13:38 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.211
X-Spam-Level:
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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JCBWIZQIfoNL for <kitten@ietfa.amsl.com>; Thu, 12 Feb 2015 15:13:36 -0800 (PST)
Received: from dmz-mailsec-scanner-4.mit.edu (dmz-mailsec-scanner-4.mit.edu [18.9.25.15]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E70281A0368 for <kitten@ietf.org>; Thu, 12 Feb 2015 15:13:34 -0800 (PST)
X-AuditID: 1209190f-f79546d000007593-eb-54dd339d44e9
Received: from mailhub-auth-1.mit.edu ( [18.9.21.35]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-4.mit.edu (Symantec Messaging Gateway) with SMTP id 26.A2.30099.D933DD45; Thu, 12 Feb 2015 18:13:33 -0500 (EST)
Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-1.mit.edu (8.13.8/8.9.2) with ESMTP id t1CNDRH3031309; Thu, 12 Feb 2015 18:13:27 -0500
Received: from localhost (sarnath.mit.edu [18.18.1.190]) (authenticated bits=0) (User authenticated as tlyu@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id t1CNDPQQ013826; Thu, 12 Feb 2015 18:13:26 -0500
From: Tom Yu <tlyu@mit.edu>
To: Greg Hudson <ghudson@mit.edu>
References: <x7d7fvo404h.fsf@equal-rites.mit.edu> <alpine.GSO.1.10.1502121341360.3953@multics.mit.edu> <54DD194D.2010201@mit.edu>
Date: Thu, 12 Feb 2015 18:13:25 -0500
In-Reply-To: <54DD194D.2010201@mit.edu> (Greg Hudson's message of "Thu, 12 Feb 2015 16:21:17 -0500")
Message-ID: <ldv1tluzpt6.fsf@sarnath.mit.edu>
Lines: 94
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrEIsWRmVeSWpSXmKPExsUixCmqrDvX+G6IwYrjWhZHN69icWD0WLLk J1MAYxSXTUpqTmZZapG+XQJXxubps9kL3qpWNOxRaWCcJNfFyMkhIWAicX3TKWYIW0ziwr31 bCC2kMBiJon38/kg7I2MEmtml3YxcgHZbxglWrftBStiE5CWOH55FxOILSKgKPFs1VyWLkYO DmYBU4l/P6xAwsICLhIHHrxghJjTyijx41EuSAmLgKrE5lMuIGFOgTSJVStegk3kFdCVOLTt EdhEHgFOiZm9z1kh4oISJ2c+YQGxmQW0JG78e8k0gVFgFpLULCSpBYxMqxhlU3KrdHMTM3OK U5N1i5MT8/JSi3RN9HIzS/RSU0o3MYKDTpJ/B+O3g0qHGAU4GJV4eAOM74QIsSaWFVfmHmKU 5GBSEuVt57sbIsSXlJ9SmZFYnBFfVJqTWnyIUYKDWUmEV/0jUDlvSmJlVWpRPkxKmoNFSZx3 0w++ECGB9MSS1OzU1ILUIpisDAeHkgRvjBHQUMGi1PTUirTMnBKENBMHJ8hwHqDh5SA1vMUF ibnFmekQ+VOMilLivJEgCQGQREZpHlwvLCm8YhQHekWYNwqkigeYUOC6XwENZgIaPHHGbZDB JYkIKakGRpHvEseu+ej+mSVxdbbyNfWDHoHNfJWPp+/wr7DcWLO57l4w/4a3jrsVizhyQ3nW 9+g0tlekT2FtuVNzNu1nlaXdVb+dR3dM0zz8aqaOQ9PMkqi4W+ZCe35f9F590OruwljJs9eF VeTUTZaoHo/m6VVo2BQy9eCfE3P8zRemcmYvbZt07VTfFCWW4oxEQy3mouJEAALk22DlAgAA
Archived-At: <http://mailarchive.ietf.org/arch/msg/kitten/GUG9eAU8FMI3C0_-WKvEC4zPmnk>
Cc: kitten@ietf.org
Subject: Re: [kitten] draft-ietf-kitten-cammac kdc-verifier omission
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: Thu, 12 Feb 2015 23:13:39 -0000

Greg Hudson <ghudson@mit.edu> writes:

> On 02/12/2015 01:47 PM, Benjamin Kaduk wrote:
>> Do you want to come up with a concrete proposal for new text?
>
> Sure.  In section 8 (Security Considerations), replace "two exceptions"
> with "three exceptions," and add a third item to the list:
>
> ---
> 3. If the ticket server principal is a cross-realm TGS from a different
> realm, the CAMMAC's kdc-verifier cannot be validated because the
> checksum was made using the other realm's local TGS key.  If the
> CAMMAC's svc-verifier is valid, the CAMMAC contents can be safely
> assumed to have originated from the other realm.  The KDC SHOULD NOT
> blindly copy CAMMAC elements originating from another realm, but MAY
> choose to filter, transform, and propagate elements according to policy
> rules, and MAY place a kdc-verifier in the new CAMMAC containing the
> resulting authorization data elements.
> ---
>
> I use MUST NOT instead of SHOULD NOT because a KDC might be in a
> subsidiary relationship to a higher-security realm.  By "cross-realm TGS
> from a different realm," I mean an incoming cross-realm krbtgt principal
> like "krbtgt/MYKDCREALM@FOREIGNREALM," but I don't see a need to spell
> that out.

This seems backwards to me; you wrote "KDC SHOULD NOT blindly copy"
in your suggested text.  Which did you intend?

I would like to try to reason about this from a data origin
authentication standpoint.  This might help us come up with more clear
and generally applicable wording.  On the other hand, if we want to
minimize textual changes, reasoning about this might help us avoid
missing edge cases when we make the more minimal changes.

The kdc-verifier provides data origin authentication that the CAMMAC
contents originated from the KDC itself (or another KDC serving the same
local realm).  If the KDC successfully validates the kdc-verifier, it
can copy the CAMMAC contents knowing that either it or another KDC in
the realm originated the contents.  There is also the local TGT special
case.  In the other cases, where it can only validate the svc-verifier,
it must apply some policy about the provenance of the contents of the
CAMMAC to decide whether to copy the contents verbatim, filter, or
transform them.  This includes both the non-S4U2Proxy service tickets
and the cross-realm TGTs.

Exception (1) in the document is for the case where the
ticket-encrypting key is a key that only other KDCs in the local realm
know, and therefore provides the same properties of data origin
authentication that the kdc-verifier would.  Exception (2) is different,
because the KDC has no assurance that the CAMMAC contents originated
from it or another KDC serving the same local realm.  In this case, the
KDC makes a policy decision that the only consumers of the possibly
forged CAMMAC contents that it copies into a new CAMMAC are consumers
that would not suffer adverse effects from such a forgery.

In the cross-realm case, the local realm KDC can only validate the
svc-verifier (because the only remote realm KDC can validate the
kdc-verifier).  The local realm KDC makes a policy decision about how to
filter, transform, etc. the original CAMMAC contents to a new CAMMAC.

I guess this is a roundabout way of suggesting text that includes:

   The KDC SHOULD NOT make verbatim copies of CAMMAC contents into a new
   CAMMAC when it cannot validate the original CAMMAC as authentically
   originating from itself or another KDC in its local realm.  In such a
   situation, the KDC MAY choose to filter, transform, or propagate
   elements from the original CAMMAC to a new CAMMAC according to policy
   rules, and MAY place a kdc-verifier in the new CAMMAC containing the
   resulting authorization data elements.

   The two individually sufficient conditions for a KDC validating a
   CAMMAC as authentically originating from itself or another KDC in its
   local realm are:

      1. The KDC successfully validates the kdc-verifier of the CAMMAC; or

      2. The CAMMAC lacks a kdc-verifier, but the encryption key for its
         surrounding ticket is one known exclusively by the local realm
         KDCs (e.g., when the ticket is a local TGT), and all KDCs
         serving the realm are configured to filter out CAMMAC
         authorization data submitted by clients.

Then we would somehow modify existing explanatory text about the
specific use cases, e.g.:

1. omission of kdc-verifier to make TGTs, etc., smaller -- safe to make
   verbatim copies if the local realm KDCs are configured properly

2. omission of kdc-verifier when the only consumers of the CAMMAC are
   the original service principal of the ticket (no S4U2Proxy
   privileges) -- apply policy rules

3. incoming cross-realm TGTs -- apply policy rules