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

Benjamin Kaduk <kaduk@MIT.EDU> Thu, 12 February 2015 18:47 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 885761A1AA4 for <kitten@ietfa.amsl.com>; Thu, 12 Feb 2015 10:47:22 -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 7palQYzui0jT for <kitten@ietfa.amsl.com>; Thu, 12 Feb 2015 10:47:16 -0800 (PST)
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 2E6A61A1B0B for <kitten@ietf.org>; Thu, 12 Feb 2015 10:47:16 -0800 (PST)
X-AuditID: 1209190c-f79696d000005933-a6-54dcf5320646
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 CA.4B.22835.335FCD45; Thu, 12 Feb 2015 13:47:15 -0500 (EST)
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 t1CIlEEA020101; Thu, 12 Feb 2015 13:47:14 -0500
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 t1CIlCvN020053 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 12 Feb 2015 13:47:13 -0500
Received: (from kaduk@localhost) by multics.mit.edu (8.12.9.20060308) id t1CIlCgC027951; Thu, 12 Feb 2015 13:47:12 -0500 (EST)
Date: Thu, 12 Feb 2015 13:47:12 -0500 (EST)
From: Benjamin Kaduk <kaduk@MIT.EDU>
To: Greg Hudson <ghudson@MIT.EDU>
In-Reply-To: <x7d7fvo404h.fsf@equal-rites.mit.edu>
Message-ID: <alpine.GSO.1.10.1502121341360.3953@multics.mit.edu>
References: <x7d7fvo404h.fsf@equal-rites.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+NgFnrCIsWRmVeSWpSXmKPExsUixCmqrWv89U6IwZQZLBZHN69icWD0WLLk J1MAYxSXTUpqTmZZapG+XQJXRnNDN0vBDeGKzua7LA2Mj/i7GDk5JARMJK7uPs4KYYtJXLi3 nq2LkYtDSGAxk8SGI/dZIJyNjBK7Gp4zQTiHmCQmzdsM5TQwSjzobmUH6WcR0Jb4sOQWI4jN JqAiMfPNRjYQW0RAUeL3yrdgcWYBYYn152Ywg9jCAi4SBx68AItzChhJrN0/FczmFXCQePP3 A1iNkIChxOV398HiogI6Eqv3T2GBqBGUODnzCQvETC2J5dO3sUxgFJyFJDULSWoBI9MqRtmU 3Crd3MTMnOLUZN3i5MS8vNQiXUO93MwSvdSU0k2M4MCU5NnB+Oag0iFGAQ5GJR7eAOM7IUKs iWXFlbmHGCU5mJREeTk+A4X4kvJTKjMSizPii0pzUosPMUpwMCuJ8Kp/BMrxpiRWVqUW5cOk pDlYlMR5N/3gCxESSE8sSc1OTS1ILYLJynBwKEnwvgYZKliUmp5akZaZU4KQZuLgBBnOAzRc 6QvI8OKCxNzizHSI/ClGRSlx3rcgzQIgiYzSPLheWOJ4xSgO9Iow7zWQKh5g0oHrfgU0mAlo 8MQZt0EGlyQipKQaGNndzOf8ejN575KcUM7q7U+mfPuulLS65Jv690U58vMfNL+fMo1Jd9+s /Lj3P9W7WF9OD3rdLBdd0D6z/XaGFB9PTIzHjilV6mvCjRN+Mu3fyLGZ5ZnXxYuva9PkH2S9 v+0a3OB5677fsjZ+k8c/H2u3OtR97VmxL7l/MsOivdsvyaZ1L7l1vFKJpTgj0VCLuag4EQCV Gq5X9wIAAA==
Archived-At: <http://mailarchive.ietf.org/arch/msg/kitten/gcPjtc3oUmiXpQwEMi2zhzA-M7o>
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, 12 Feb 2015 18:47:25 -0000

On Wed, 11 Feb 2015, Greg Hudson wrote:

> draft-ietf-kitten-cammac is in the RFC editor queue, so I assume it's
> too late to make any non-trivial corrections, but we noticed an issue
> with the security considerations section when going over cross-realm
> scenarios.

It appears to not be too late.

% The document draft-ietf-kitten-cammac-01 has changed from RFC-EDITOR
% state to IESG state. We thought you'd like to know. You can also follow
% your document's state at
% <http://www.rfc-editor.org/queue2.html#draft-ietf-kitten-cammac>. For
% definitions of state names, please see:
% <http://www.rfc-editor.org/state_def.html>.

But, we should decide what new text we wish to insert.

> When we decided to make kdc-verifier optional, we provided guidance to
> KDC implementors to avoid attacks where services can forge CAMMAC data
> and get KDCs to put kdc-verifiers on them.  So we wrote:
>
>     The KDC MUST NOT create a new CAMMAC from an existing one unless the
>     existing CAMMAC has a valid kdc-verifier, with two exceptions:
>
>     1. [Local TGTs under certain assumptions about realm KDCs]
>
>     2. [Ticket modification requests, but the KDC] MUST NOT place a
>        kdc-verifier in the new CAMMAC.
>
> We missed a third case.  If the header ticket is an incoming cross-realm
> TGT, any CAMMACs in that ticket can only be verified with the
> svc-verifier; the kdc-verifier, if present, will be signed with the
> foreign realm's local TGS key.  (Section 4 makes it clear that the
> kdc-verifier always uses the local TGS key and the svc-veriifer uses the
> cross TGS key for cross-realm TGTs.)  Nevertheless, the KDC may choose
> to filter and propagate CAMMAC-signed authdata originating from the
> foreign realm.  For example, a KDC might choose to propagate
> authentication indicators, perhaps translating them into local realm
> indicator conventions, since only the foreign realm can know how the
> client originally authenticated.  If the local KDC is propagating
> authdata originating from the foreign realm, it must place a local realm
> kdc-verifier on the CAMMAC it produces if the issued ticket might be
> used in an S4U2Proxy request.
>
> I suspect we will have to submit an errata for this, amending "two
> exceptions" to "three exceptions" and adding a third exception to cover
> the case of incoming cross-realm requests.

Do you want to come up with a concrete proposal for new text?

I agree that the change is needed.

-Ben