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

Tom Yu <tlyu@mit.edu> Thu, 26 February 2015 21: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 78FAD1A07BE for <kitten@ietfa.amsl.com>; Thu, 26 Feb 2015 13:40:32 -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 2lt6vthT6xqy for <kitten@ietfa.amsl.com>; Thu, 26 Feb 2015 13:40:30 -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 14FBE1A1B25 for <kitten@ietf.org>; Thu, 26 Feb 2015 13:40:29 -0800 (PST)
X-AuditID: 1209190f-f79546d000007593-a2-54ef92ccc170
Received: from mailhub-auth-4.mit.edu ( [18.7.62.39]) (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 27.33.30099.CC29FE45; Thu, 26 Feb 2015 16:40:28 -0500 (EST)
Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-4.mit.edu (8.13.8/8.9.2) with ESMTP id t1QLeMW1005446; Thu, 26 Feb 2015 16:40:23 -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 t1QLeL7K018630; Thu, 26 Feb 2015 16:40:22 -0500
From: Tom Yu <tlyu@mit.edu>
To: Simo Sorce <simo@redhat.com>
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> <ldv4mq8wgny.fsf@sarnath.mit.edu> <1424983676.640.21.camel@willson.usersys.redhat.com>
Date: Thu, 26 Feb 2015 16:40:20 -0500
In-Reply-To: <1424983676.640.21.camel@willson.usersys.redhat.com> (Simo Sorce's message of "Thu, 26 Feb 2015 15:47:56 -0500")
Message-ID: <ldvy4nkuzaz.fsf@sarnath.mit.edu>
Lines: 85
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrAIsWRmVeSWpSXmKPExsUixG6nrntm0vsQgztXLSyObl7FYvFj7iJW ByaPJUt+Mnm833eVLYApissmJTUnsyy1SN8ugSvj6NfjrAUdchVn5h5haWB8I97FyMkhIWAi certAjYIW0ziwr31QDYXh5DAYiaJ/Xf6mCCcjYwSk3rbGEGqhATeMErcWVoJYrMJSEscv7yL CcQWEVCQWNB/h6WLkYODWcBU4t8PK5CwsICLxIEHLxgh5qxglviy9TcrSIJFQFViRv9/ZhCb U6Be4umUOSwgNq+ArsSrnRfAZvIIcEoc+P+dCSIuKHFy5hOwGmYBLYkb/14yTWAUmIUkNQtJ agEj0ypG2ZTcKt3cxMyc4tRk3eLkxLy81CJdE73czBK91JTSTYyggOSU5N/B+O2g0iFGAQ5G JR7eHbnvQoRYE8uKK3MPMUpyMCmJ8j6d8D5EiC8pP6UyI7E4I76oNCe1+BCjBAezkghvcDdQ jjclsbIqtSgfJiXNwaIkzrvpB1+IkEB6YklqdmpqQWoRTFaGg0NJgrdmIlCjYFFqempFWmZO CUKaiYMTZDgP0PD/IIt5iwsSc4sz0yHypxgVpcR5K0CaBUASGaV5cL2whPGKURzoFWHeSyBV PMBkA9f9CmgwE9DgA3ffgQwuSURISTUwul7si/1p8Yjl27VkUyu99fanZy3cvmDpjsbCOf3N mYmHJx+6dnz5xz5TuV9691W3OC12l45MXvPAu/Xp7fnGEgweoiE37DYFGCRXFZQtmzr5A9dS 0/IVC0vfTxW9fFhxr8/7ipYABtN+TqGavRvzp1X6ckt2mYu9/n+s4sDRxJfTOl6k8Be9VWIp zkg01GIuKk4EACrDHFrzAgAA
Archived-At: <http://mailarchive.ietf.org/arch/msg/kitten/7Tvc-qtU5g69RqGqBCQyEZFSMto>
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, 26 Feb 2015 21:40:32 -0000

Simo Sorce <simo@redhat.com> writes:

> On Thu, 2015-02-26 at 15:40 -0500, Tom Yu wrote:
>> Benjamin Kaduk <kaduk@MIT.EDU> writes:
>> 
>> I prefer to avoid using the word "trusted" here.
>
> Can we use "authorized" or something similar ?

We could, or we could describe the concepts in terms of KDC policies.

>> 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
>
> This definition fails to include cross-realm tgts, because in (2) you
> say the key must be known only by the local realm KDCS and it is not the
> case fro cross-realm.

I think it's not necessary to include cross-realm in (2).  Almost by
definition, a cross-realm TGT doesn't originate from the local realm.
(I guess a local realm KDC could forge one, because it has the key, but
I think there's not much point in analyzing that use case.)

>> (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.)
>
> (2) is fundamental for the cross-realm case where the only thing you can
> verify in the local KDC is the svc-verifier, given the kdc-verifier uses
> a key you do not known (the other's realm tgt key).

The cross-realm key is also known to the KDCs of the remote realm, so I
think it doesn't call into this set of definitions.  We can consider the
cross-realm case when we describe policies for CAMMACs not authenticated
by local realm KDC-only principals.

> We need to state that it is ok consider the CAMMAC if local policy says
> you "trust" another REALM (you will probably not fully trust it, and
> perform some filtering, but that is local policy and is captured in the
> part that mentions filtering).

[...]

> I think we should say the KDC should apply policy but not dictate
> whether there should necessarily be any filtering.
> In a cross-realm case you may "fully-trust" the originating realm and
> decide to verbating copy the CAMMAC, in other cases you may have a
> different level of trust and apply filtering. The KDC should follow
> whatever policy the amdin applies, with reasonable defaults in
> implementations (but that is an implementation detail, we just need to
> tell implementors what to pay attention to).
>
> Simo.

You make a good point that there might be cases where a policy allows
the KDC to make verbatim copies of CAMMAC contents in cross-realm TGTs
from specific "trusted" remote realms.

We could provide examples of local policies that would allow verbatim
copying of CAMMAC not originating from a local realm KDC.  Some would
be:

1. svc-verifier is for a cross-realm TGS principal, and policy allows
   the KDC to copy that realm's CAMMAC contents verbatim.

2. kdc-verifier is absent, svc-verifier is present and valid, but is for
   a non-KDC service.  Typically only allow verbatim copying if the only
   possible consumer is the same service principal as the original
   ticket, but don't apply a kdc-verifier.  This is the use case where
   there's a policy that prohibits the service from using S4U2Proxy, and
   the KDC omits kdc-verifier to save space in the ticket.