Re: [kitten] I-D Action: draft-ietf-kitten-cammac-02.txt

Benjamin Kaduk <kaduk@MIT.EDU> Wed, 11 March 2015 21:24 UTC

Return-Path: <kaduk@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 5C0041A87D9 for <kitten@ietfa.amsl.com>; Wed, 11 Mar 2015 14:24:15 -0700 (PDT)
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 3dHtjxuT5jeX for <kitten@ietfa.amsl.com>; Wed, 11 Mar 2015 14:24:10 -0700 (PDT)
Received: from dmz-mailsec-scanner-1.mit.edu (dmz-mailsec-scanner-1.mit.edu [18.9.25.12]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9F5B41A87D2 for <kitten@ietf.org>; Wed, 11 Mar 2015 14:24:10 -0700 (PDT)
X-AuditID: 1209190c-f79696d000005933-66-5500b2796ef5
Received: from mailhub-auth-3.mit.edu ( [18.9.21.43]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-1.mit.edu (Symantec Messaging Gateway) with SMTP id E6.B0.22835.972B0055; Wed, 11 Mar 2015 17:24:09 -0400 (EDT)
Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-3.mit.edu (8.13.8/8.9.2) with ESMTP id t2BLO8qd008850 for <kitten@ietf.org>; Wed, 11 Mar 2015 17:24:09 -0400
Received: from multics.mit.edu (system-low-sipb.mit.edu [18.187.2.37]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id t2BLO7TQ027558 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for <kitten@ietf.org>; Wed, 11 Mar 2015 17:24:08 -0400
Received: (from kaduk@localhost) by multics.mit.edu (8.12.9.20060308) id t2BLO6ex018890; Wed, 11 Mar 2015 17:24:06 -0400 (EDT)
Date: Wed, 11 Mar 2015 17:24:06 -0400
From: Benjamin Kaduk <kaduk@MIT.EDU>
To: kitten@ietf.org
In-Reply-To: <54FE4340.4070400@mit.edu>
Message-ID: <alpine.GSO.1.10.1503111656410.3953@multics.mit.edu>
References: <20150309225924.25360.58204.idtracker@ietfa.amsl.com> <54FE4340.4070400@mit.edu>
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+NgFrrBIsWRmVeSWpSXmKPExsUixCmqrVu5iSHU4OJ1BYujm1exODB6LFny kymAMYrLJiU1J7MstUjfLoEr42VTN1vBXJmKzytb2RsYz4t1MXJySAiYSOzf95kFwhaTuHBv PVsXIxeHkMBiJomlE7uZIZzjjBKfPjSyQjg3mCSmfb7IBOE0MEr8P/+NFaSfRUBbYsaEy+wg NpuAisTMNxvZQGwRAWGJ3VvfMYPYwgKOEj96D4HVcwqoS2zYfRCsnlfAQeLT4yNgdwgJxEgc /PAcrEZUQEdi9f4pLBA1ghInZz4Bs5kFtCSWT9/GMoFRYBaS1CwkqQWMTKsYZVNyq3RzEzNz ilOTdYuTE/PyUot0DfVyM0v0UlNKNzGCA1CSZwfjm4NKhxgFOBiVeHhnzPofIsSaWFZcmXuI UZKDSUmU98YChlAhvqT8lMqMxOKM+KLSnNTiQ4wSHMxKIrxbK4FyvCmJlVWpRfkwKWkOFiVx 3k0/+EKEBNITS1KzU1MLUotgsjIcHEoSvC0bgRoFi1LTUyvSMnNKENJMHJwgw3mAhp8DqeEt LkjMLc5Mh8ifYlSUEufdCZIQAElklObB9cISxCtGcaBXhHkfbgCq4gEmF7juV0CDmYAGs1gD PclbXJKIkJJqYEzpKp6ZobtAP3fHa8e5jA/z0iSWXQkuPSY6f1KsLEfdkhaP94XyE6+dSixa zbgkIu8Tu3LKXLenp7kENINvS+ZbJLVYTXvsoioWtu7vo7OBtuuUdUUl8n8+sZi7huXSZcHH X9vsFghWcqxNTj256fbvziVLRI5OvhC65EPqjUD3q/v+azfd+6XEUpyRaKjFXFScCACgYAsF 6wIAAA==
Archived-At: <http://mailarchive.ietf.org/arch/msg/kitten/MZ6s59_hD4XjpeAgRHwtu-KIkeA>
Subject: Re: [kitten] I-D Action: draft-ietf-kitten-cammac-02.txt
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: Wed, 11 Mar 2015 21:24:15 -0000

On Mon, 9 Mar 2015, Greg Hudson wrote:

> On 03/09/2015 06:59 PM, internet-drafts@ietf.org wrote:
> > A diff from the previous version is available at:
> > http://www.ietf.org/rfcdiff?url2=draft-ietf-kitten-cammac-02
>
> I'm not sure the new wording is quite right.  The new draft contains:
>
>    A 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 [...]
>
>    When a KDC makes verbatim copies of CAMMAC contents to a new CAMMAC
>    without having authenticated the first CAMMAC as originating from a
>    local realm KDC, it SHOULD NOT apply a kdc-verifier to the new
>    CAMMAC.
>
> The first recommendation doesn't contain an exception for ticket
> modification requests, where it is safe to copy a CAMMAC with only an
> svc-verifier as long as the new CAMMAC also contains only an
> svc-verifier.  The second recommendation is confusing because it seems
> to apply only to a situation where the KDC is already violating the
> first SHOULD.

I'm not sure that we need to be in the business of saying when the KDC
SHOULD make verbatim copies at all.

What if we instead come at it from something along these lines:

========

The presence of a CAMMAC in a ticket indicates that the contents of the
CAMMAC have been validated and are certified by the KDC.  During TGS
processing, this validation may take the place of merely checking that the
existing CAMMAC was issued by a KDC in the local realm; this is the case
when any of the criteria below are true.  In this case the KDC just makes
a verbatim copy of the existing CAMMAC with no validation other than the
issuer validation.

[include 1, 2, and 3 from the -02]

This validation can also take the place of confirming that a foreign-realm
KDC has issued the existing CAMMAC in a cross-realm TGT.  Local policy may
grant certain foreign realms privileged status and allow verbatim copying
of CAMMACs issued by KDCs from those realms.  In other cases, local policy
may require filtering of the CAMMAC contents (e.g., to remove group
membership information) from cross-realm TGTs issued by foreign-realm
KDCs.  The nature of such filtering is entirely a matter of local policy.

The validation can also take the place of ensuring that the scope of the
generated CAMAMC is limited to the same or narrower scope than the entity
which generated the existing CAMMAC.  This is the case for a CAMMAC
containing a svc-verifier but no kdc-verifier, when the target service of
the containing ticket does not use the S4U2Proxy extension or realm policy
disallows the use of S4U2Proxy by that service, because the only entity
other than the KDC which could have generated the existing CAMMAC is that
target service, and the generated CAMMAC would only be usable by that same
target service.  It is safe to make a verbatim copy of the CAMMAC and
generate a new svc-verifier, but no kdc-verifier.  Note that in this
situation, adding a kdc-verifier to the generated CAMMAC would increase
the scope of the certification, since the kdc-verifier certifies that the
CAMMAC was validated by the KDC, but the input CAMMAC could have been
generated by the target service.  A kdc-verifier MUST NOT be included in
the generated CAMMAC in this case, in the absence of explicit policy
configuration (such as for cross-realm TGTs).

========

We would probably still need to say something about omitting the
kdc-verifier when all the KDCs in the local realm filter out
client-submitted CAMMACs.

-Ben