[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?