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
- [kitten] I-D Action: draft-ietf-kitten-cammac-02.… internet-drafts
- Re: [kitten] I-D Action: draft-ietf-kitten-cammac… Greg Hudson
- Re: [kitten] I-D Action: draft-ietf-kitten-cammac… Benjamin Kaduk