[kitten] CAMMAC and ticket server principal binding
Greg Hudson <ghudson@MIT.EDU> Fri, 08 August 2014 20:21 UTC
Return-Path: <ghudson@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 631B91A02A2 for <kitten@ietfa.amsl.com>; Fri, 8 Aug 2014 13:21:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.202
X-Spam-Level:
X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] 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 RjRLtKKGr6fx for <kitten@ietfa.amsl.com>; Fri, 8 Aug 2014 13:21:56 -0700 (PDT)
Received: from dmz-mailsec-scanner-5.mit.edu (dmz-mailsec-scanner-5.mit.edu [18.7.68.34]) by ietfa.amsl.com (Postfix) with ESMTP id 3EA7C1A0109 for <kitten@ietf.org>; Fri, 8 Aug 2014 13:21:56 -0700 (PDT)
X-AuditID: 12074422-f79be6d000007518-85-53e531633761
Received: from mailhub-auth-3.mit.edu ( [18.9.21.43]) (using TLS with cipher AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-5.mit.edu (Symantec Messaging Gateway) with SMTP id A7.B0.29976.36135E35; Fri, 8 Aug 2014 16:21:55 -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 s78KLtFx009894 for <kitten@ietf.org>; Fri, 8 Aug 2014 16:21:55 -0400
Received: from localhost (equal-rites.mit.edu [18.18.1.59]) (authenticated bits=0) (User authenticated as ghudson@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id s78KLsHS018392 for <kitten@ietf.org>; Fri, 8 Aug 2014 16:21:54 -0400
From: Greg Hudson <ghudson@MIT.EDU>
To: kitten@ietf.org
Date: Fri, 08 Aug 2014 16:17:48 -0400
Message-ID: <x7dppgazqfn.fsf@equal-rites.mit.edu>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrOIsWRmVeSWpSXmKPExsUixCmqrZts+DTY4G+vgcXRzatYHBg9liz5 yRTAGMVlk5Kak1mWWqRvl8CV8W3LI7aChUIV8/b0MzUw3uTrYuTkkBAwkZh34BU7hC0mceHe erYuRi4OIYHZTBLP1zQwQjjHGCVOr1vOCuG0M0nsP7UErIVNQFni4NlvLCC2iICwxO6t75hB bGEBY4mL988xgtgsAqoSh+7/ZQKxeQUMJT5teMoOYQtKnJz5BKyXWUBL4sa/l0wTGHlmIUnN QpJawMi0ilE2JbdKNzcxM6c4NVm3ODkxLy+1SNdULzezRC81pXQTIyg82F2UdjD+PKh0iFGA g1GJh1eg+3GwEGtiWXFl7iFGSQ4mJVFeb72nwUJ8SfkplRmJxRnxRaU5qcWHGCU4mJVEeJ88 ehIsxJuSWFmVWpQPk5LmYFES531rbRUsJJCeWJKanZpakFoEk5Xh4FCS4PU3ABoqWJSanlqR lplTgpBm4uAEGc4DNNwKpIa3uCAxtzgzHSJ/ilFRSpxXVh8oIQCSyCjNg+uFxe8rRnGgV4R5 Y0HaeYCxD9f9CmgwE9BgWdXHIINLEhFSUg2MSeuVXgpYHFQOSbrGzH9j6vK54oaunxfH/HT4 8vPCpu7jT2Yax4q1KDb/edu0NnO+H+PjLfd/HojXP7Jg4Y423qV8ixk6/rW/+zj1csrG+RNP zJ52d1Yhx7QJWQbb/GPt06+HK/n9uc3yUaU5LCm/68eHGZ/y6w8e2Vl4N2HZCtbpj27IpJUm 31BiKc5INNRiLipOBACP14nuugIAAA==
Archived-At: http://mailarchive.ietf.org/arch/msg/kitten/323vy7IKba-oNn71rdd-a-6DAvQ
Subject: [kitten] CAMMAC and ticket server principal binding
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: Fri, 08 Aug 2014 20:21:58 -0000
In the current CAMMAC draft, the KDC verifier binds the CAMMAC contents to all the EncTicketPart fields, which includes the ticket client principal, all of the timestamps, and the ticket session key, but not the ticket server principal. Sam pointed this out in http://www.ietf.org/mail-archive/web/kitten/current/msg04774.html but I wanted a thread to discuss the issue specifically. With the current binding, a KDC cannot assume that the contents of a CAMMAC originated from a KDC in a ticket issued for the claimed service. The scope for potential tampering is narrow but extant. Imagine that I know the keys for two different services svc1 and svc2. I receive a ticket for svc1. I can extract the CAMMAC from that ticket, then print up a ticket for svc2 containing a CAMMAC with the same contents. If the new ticket uses the same session key, timestamps, and client principal, then the kdc-verifier in the CAMMAC will appear valid to the KDC, even though it originated in a ticket issued to svc1. (The svc-verifier would appear invalid if I simply copied it, but I can construct a valid svc-verifier using my knowledge of svc2's key.) As Sam noted, we have two options: we can add a ticket server binding, or we can document that there isn't one. Most of the people I have talked to are in favor of documenting, for these reasons: * All of the ways we could bind the ticket server add some additional complexity to the specification and to implementations. * The types we have so far proposed to put inside CAMMAC only make statements about the client or the means of client authorization, not the relationship between the client and a specific service. * The purpose of the kdc-verifier is to allow CAMMAC contents to be propagated to a ticket for a different service. If the CAMMAC contains a hypothetical authdata type which talks about the relationship between the client and the old service, it would need to discarded or recomputed for the new service. * A hypothetical authdata type which talks about the client-server relationship should probably bind to the service principal (perhaps just by naming it) independently of CAMMAC, in case a KDC ignorantly propagates it to a ticket for a different service. Do other people have conflicting opinions?
- [kitten] CAMMAC and ticket server principal bindi… Greg Hudson
- Re: [kitten] CAMMAC and ticket server principal b… Benjamin Kaduk
- Re: [kitten] CAMMAC and ticket server principal b… Jeffrey Hutzelman