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

Benjamin Kaduk <kaduk@MIT.EDU> Wed, 18 February 2015 18:55 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 698511A00E6 for <kitten@ietfa.amsl.com>; Wed, 18 Feb 2015 10:55:32 -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 a71O9pA8Gmnn for <kitten@ietfa.amsl.com>; Wed, 18 Feb 2015 10:55:27 -0800 (PST)
Received: from dmz-mailsec-scanner-7.mit.edu (dmz-mailsec-scanner-7.mit.edu [18.7.68.36]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 846181A00FB for <kitten@ietf.org>; Wed, 18 Feb 2015 10:55:27 -0800 (PST)
X-AuditID: 12074424-f79356d000004839-e4-54e4e01e5dc8
Received: from mailhub-auth-4.mit.edu ( [18.7.62.39]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-7.mit.edu (Symantec Messaging Gateway) with SMTP id E2.97.18489.E10E4E45; Wed, 18 Feb 2015 13:55:26 -0500 (EST)
Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-4.mit.edu (8.13.8/8.9.2) with ESMTP id t1IItP76027005; Wed, 18 Feb 2015 13:55:25 -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 t1IItNKd031798 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 18 Feb 2015 13:55:24 -0500
Received: (from kaduk@localhost) by multics.mit.edu (8.12.9.20060308) id t1IItM67010257; Wed, 18 Feb 2015 13:55:22 -0500 (EST)
Date: Wed, 18 Feb 2015 13:55:22 -0500 (EST)
From: Benjamin Kaduk <kaduk@MIT.EDU>
To: Tom Yu <tlyu@MIT.EDU>
In-Reply-To: <ldv1tluzpt6.fsf@sarnath.mit.edu>
Message-ID: <alpine.GSO.1.10.1502181348460.3953@multics.mit.edu>
References: <x7d7fvo404h.fsf@equal-rites.mit.edu> <alpine.GSO.1.10.1502121341360.3953@multics.mit.edu> <54DD194D.2010201@mit.edu> <ldv1tluzpt6.fsf@sarnath.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+NgFnrMIsWRmVeSWpSXmKPExsUixG6nriv34EmIwZVlQhZHN69icWD0WLLk J1MAYxSXTUpqTmZZapG+XQJXxv7tJ5gLmnQqLhz4x9LAeFmpi5GTQ0LAROJK701mCFtM4sK9 9WxdjFwcQgKLmSS+LXjDCOFsZJSYOPsMO4RziEni1tKrTCAtQgINjBKP9iaA2CwC2hK3b+wA i7MJqEjMfLORDcQWEZCUOPbkPNAKDg5mASOJC78yQMLCAi4SBx68YASxOQX0JPon7gVr5RVw kHjW944J6gpGiYMHW8GKRAV0JFbvn8ICUSQocXLmEzCbWUBLYvn0bSwTGAVnIUnNQpJawMi0 ilE2JbdKNzcxM6c4NVm3ODkxLy+1SNdcLzezRC81pXQTIzgsXVR2MDYfUjrEKMDBqMTD28H0 JESINbGsuDL3EKMkB5OSKO+2e0AhvqT8lMqMxOKM+KLSnNTiQ4wSHMxKIrw79gHleFMSK6tS i/JhUtIcLErivJt+8IUICaQnlqRmp6YWpBbBZGU4OJQkeN1BhgoWpaanVqRl5pQgpJk4OEGG 8wANTwGp4S0uSMwtzkyHyJ9iVJQS51UESQiAJDJK8+B6YWnjFaM40CvCvC0gVTzAlAPX/Qpo MBPQ4Pl/HoEMLklESEk1MM7PWvBjzvQHmXObfR76ahuoL5ndpZTekaIV29ItHfOw00gvtybG xfDN+hLOC3UJogtMFL0WqYtwbOQRna53VPSc2P8Ov8+dWQobr+hqn6qSkNf+ltL0ItXLyd2s +IDe5tz46RfSWk+qNz1lq/npv0Mvbp5Lt7qCZNsO74XrPuw3P6tXqBuixFKckWioxVxUnAgA Bwu2rvYCAAA=
Archived-At: <http://mailarchive.ietf.org/arch/msg/kitten/DNmZv_XJUhNg17VE1VXym5EoVw8>
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: Wed, 18 Feb 2015 18:55:32 -0000

On Thu, 12 Feb 2015, Tom Yu wrote:

> Greg Hudson <ghudson@mit.edu> writes:
>
> > On 02/12/2015 01:47 PM, Benjamin Kaduk wrote:
> >> Do you want to come up with a concrete proposal for new text?
> >
> > Sure.  In section 8 (Security Considerations), replace "two exceptions"
> > with "three exceptions," and add a third item to the list:
> >
> > ---
> > 3. If the ticket server principal is a cross-realm TGS from a different
> > realm, the CAMMAC's kdc-verifier cannot be validated because the
> > checksum was made using the other realm's local TGS key.  If the
> > CAMMAC's svc-verifier is valid, the CAMMAC contents can be safely
> > assumed to have originated from the other realm.  The KDC SHOULD NOT
> > blindly copy CAMMAC elements originating from another realm, but MAY
> > choose to filter, transform, and propagate elements according to policy
> > rules, and MAY place a kdc-verifier in the new CAMMAC containing the
> > resulting authorization data elements.
> > ---
> >
> > I use MUST NOT instead of SHOULD NOT because a KDC might be in a
> > subsidiary relationship to a higher-security realm.  By "cross-realm TGS
> > from a different realm," I mean an incoming cross-realm krbtgt principal
> > like "krbtgt/MYKDCREALM@FOREIGNREALM," but I don't see a need to spell
> > that out.
>
> This seems backwards to me; you wrote "KDC SHOULD NOT blindly copy"
> in your suggested text.  Which did you intend?
>
> I would like to try to reason about this from a data origin
> authentication standpoint.  This might help us come up with more clear
> and generally applicable wording.  On the other hand, if we want to
> minimize textual changes, reasoning about this might help us avoid
> missing edge cases when we make the more minimal changes.
>
> The kdc-verifier provides data origin authentication that the CAMMAC
> contents originated from the KDC itself (or another KDC serving the same
> local realm).  If the KDC successfully validates the kdc-verifier, it
> can copy the CAMMAC contents knowing that either it or another KDC in
> the realm originated the contents.  There is also the local TGT special
> case.  In the other cases, where it can only validate the svc-verifier,
> it must apply some policy about the provenance of the contents of the
> CAMMAC to decide whether to copy the contents verbatim, filter, or
> transform them.  This includes both the non-S4U2Proxy service tickets
> and the cross-realm TGTs.
>
> Exception (1) in the document is for the case where the
> ticket-encrypting key is a key that only other KDCs in the local realm
> know, and therefore provides the same properties of data origin
> authentication that the kdc-verifier would.  Exception (2) is different,
> because the KDC has no assurance that the CAMMAC contents originated
> from it or another KDC serving the same local realm.  In this case, the
> KDC makes a policy decision that the only consumers of the possibly
> forged CAMMAC contents that it copies into a new CAMMAC are consumers
> that would not suffer adverse effects from such a forgery.
>
> In the cross-realm case, the local realm KDC can only validate the
> svc-verifier (because the only remote realm KDC can validate the
> kdc-verifier).  The local realm KDC makes a policy decision about how to
> filter, transform, etc. the original CAMMAC contents to a new CAMMAC.
>
> I guess this is a roundabout way of suggesting text that includes:
>
>    The KDC SHOULD NOT make verbatim copies of CAMMAC contents into a new
>    CAMMAC when it cannot validate the original CAMMAC as authentically
>    originating from itself or another KDC in its local realm.  In such a

The SHOULD NOT here makes me slightly uncomfortable.  (I understand Greg's
reasons for suggesting it, though.)  Can we say something about MUST NOT
... as originating from itself or another KDC in its local realm or [some
other trusted KDC; wording TBD]?  This could potentially even include the
cross-realm case.

>    situation, the KDC MAY choose to filter, transform, or propagate

I think that what "such a situation" is potentially unclear and should be
specified more concretely.

>    elements from the original CAMMAC to a new CAMMAC according to policy
>    rules, and MAY place a kdc-verifier in the new CAMMAC containing the
>    resulting authorization data elements.
>
>    The two individually sufficient conditions for a KDC validating a
>    CAMMAC as authentically originating from itself or another KDC in its

That's a rather complicated sentence; I expect it would confuse some
readers.

>    local realm are:
>
>       1. The KDC successfully validates the kdc-verifier of the CAMMAC; or
>
>       2. The CAMMAC lacks a kdc-verifier, but the encryption key for its
>          surrounding ticket is one known exclusively by the local realm
>          KDCs (e.g., when the ticket is a local TGT), and all KDCs
>          serving the realm are configured to filter out CAMMAC
>          authorization data submitted by clients.
>
> Then we would somehow modify existing explanatory text about the
> specific use cases, e.g.:
>
> 1. omission of kdc-verifier to make TGTs, etc., smaller -- safe to make
>    verbatim copies if the local realm KDCs are configured properly
>
> 2. omission of kdc-verifier when the only consumers of the CAMMAC are
>    the original service principal of the ticket (no S4U2Proxy
>    privileges) -- apply policy rules

Would these involve changes outside section 8?


-Ben


> 3. incoming cross-realm TGTs -- apply policy rules
>