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

Tom Yu <tlyu@mit.edu> Thu, 26 February 2015 20:40 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 043EF1A039B for <kitten@ietfa.amsl.com>; Thu, 26 Feb 2015 12:40:13 -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 fzDHMbJl4E1c for <kitten@ietfa.amsl.com>; Thu, 26 Feb 2015 12:40:11 -0800 (PST)
Received: from dmz-mailsec-scanner-6.mit.edu (dmz-mailsec-scanner-6.mit.edu [18.7.68.35]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 425161A1DE1 for <kitten@ietf.org>; Thu, 26 Feb 2015 12:40:11 -0800 (PST)
X-AuditID: 12074423-f79066d0000058b8-fd-54ef84aa8bc9
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-6.mit.edu (Symantec Messaging Gateway) with SMTP id 58.FD.22712.AA48FE45; Thu, 26 Feb 2015 15:40:10 -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 t1QKe4kC023081; Thu, 26 Feb 2015 15:40:04 -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 t1QKe12u017443; Thu, 26 Feb 2015 15:40:03 -0500
From: Tom Yu <tlyu@mit.edu>
To: Benjamin Kaduk <kaduk@mit.edu>
References: <x7d7fvo404h.fsf@equal-rites.mit.edu> <alpine.GSO.1.10.1502121341360.3953@multics.mit.edu> <54DD194D.2010201@mit.edu> <ldv1tluzpt6.fsf@sarnath.mit.edu> <alpine.GSO.1.10.1502181348460.3953@multics.mit.edu> <1424287116.6980.35.camel@willson.usersys.redhat.com> <alpine.GSO.1.10.1502201601450.3953@multics.mit.edu>
Date: Thu, 26 Feb 2015 15:40:01 -0500
In-Reply-To: <alpine.GSO.1.10.1502201601450.3953@multics.mit.edu> (Benjamin Kaduk's message of "Fri, 20 Feb 2015 16:04:44 -0500")
Message-ID: <ldv4mq8wgny.fsf@sarnath.mit.edu>
Lines: 51
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrEIsWRmVeSWpSXmKPExsUixCmqrLuq5X2Iwde13BZHN69isfgxdxGr A5PHkiU/mTze77vKFsAUxWWTkpqTWZZapG+XwJVx8nZhwT3Biss3rjM1ML7n7WLk5JAQMJHY 0fWAGcIWk7hwbz1bFyMXh5DAYiaJt5OOsEA4GxklXny5xQ7hvGGUmHKiD6yFTUBa4vjlXUwg toiAksTisy1sIDazgLHEmiffwWxhAReJAw9eMEI0n2WS2DJlCyNIgkVAVWLju2msIAlOgWZG iXVrt7KAJHgFdCU67i0H28AjwAm0bQ0bRFxQ4uTMJywQG7Qkbvx7yTSBUWAWktQsJKkFjEyr GGVTcqt0cxMzc4pTk3WLkxPz8lKLdM30cjNL9FJTSjcxgoKS3UV5B+Ofg0qHGAU4GJV4eHfk vgsRYk0sK67MPcQoycGkJMp7tul9iBBfUn5KZUZicUZ8UWlOavEhRgkOZiURXoZSoBxvSmJl VWpRPkxKmoNFSZx30w++ECGB9MSS1OzU1ILUIpisDAeHkgRvTjNQo2BRanpqRVpmTglCmomD E2Q4D9DwGyA1vMUFibnFmekQ+VOMilLivKtAEgIgiYzSPLheWNJ4xSgO9IowryVIFQ8w4cB1 vwIazAQ0+MDddyCDSxIRUlINjElGefOcupo1xBaHd7zY8zDmV+2hUNZ0zptR1XbLJ3xxXhQj cfXi1t3OpiqW77otBPjjJLhUJFIU9uqleQnzTEj1+7FJ6kyKVamYWV3jphvBJlfvqRYtc2QT bfof8uH1+/SuBL61jX/Y5jR6+jZKH7V6Or8jb158z9eeZokDxt1qd/xPr/yuxFKckWioxVxU nAgAYOdTU/UCAAA=
Archived-At: <http://mailarchive.ietf.org/arch/msg/kitten/Xe9zpk-4Ox9A7czna5HedC5NXrc>
Cc: kitten@ietf.org, Simo Sorce <simo@redhat.com>
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, 26 Feb 2015 20:40:13 -0000

Benjamin Kaduk <kaduk@MIT.EDU> writes:

> On Wed, 18 Feb 2015, Simo Sorce wrote:
>
>> On Wed, 2015-02-18 at 13:55 -0500, Benjamin Kaduk wrote:
>>
>> Would it make more sense to say something like:
>>
>>         The KDC MUST NOT make verbatim copies of CAMMAC contents into a
>>         new CAMMAC unless the original CAMMAC is authenticated by an
>>         originator that is fully trusted by the KDC.
>>         The KDC MAY choose to filter, transform, or propagate elements
>>         from the original CAMMAC according to local policy.
>
> It might.  Is this the first time we are using the word "trusted" in a
> Kerberos RFC, though?  And being concrete does have something going for
> it (we just have to get it right).

I prefer to avoid using the word "trusted" here.

The KDC makes a policy decision about which CAMMACs have contents that
are safe to copy verbatim into a new CAMMAC.  We can recommend that the
KDC limit verbatim CAMMAC copying to cases where only the local realm
KDCs know the key that authenticates the CAMMAC.

We could define a term "authenticated as originating from a local realm
KDC" to mean:

1. kdc-verifier is present and validates;

2. svc-verifier is present, validates, and uses a key known only to
   local realm KDCs; or

3. no verifiers are present, the ticket-encrypting key is known only to
   local realm KDCs, and all local realm KDCs properly filter out
   client-submitted CAMMACs

(I think I didn't include case 2 in my earlier message, and think it's
somewhat unlikely to get used in practice, but I think mentioning it
makes the definition more complete.)

We can say that the KDC SHOULD only make verbatim copies of CAMMAC
contents to a new CAMMAC when it has authenticated the CAMMAC as
originating from a local realm KDC.  We might also say that when the KDC
has not authenticated a CAMMAC as originating from a local realm KDC, it
SHOULD NOT apply a kdc-verifier to a new CAMMAC whose contents are a
verbatim copy from that first CAMMAC.  (The cross-realm case is somewhat
of an exception, though there generally should be some filtering.)

I guess "verbatim copying" is really shorthand for "verbatim copying
without a complete policy check on the copied stuff".