Re: [kitten] Critical authorization data in Kerberos

Jeffrey Hutzelman <jhutz@cmu.edu> Fri, 22 August 2014 00:43 UTC

Return-Path: <jhutz@cmu.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 40AFD1A06C1 for <kitten@ietfa.amsl.com>; Thu, 21 Aug 2014 17:43:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.868
X-Spam-Level:
X-Spam-Status: No, score=-4.868 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.668] 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 lDJB3xFapzsP for <kitten@ietfa.amsl.com>; Thu, 21 Aug 2014 17:43:54 -0700 (PDT)
Received: from smtp03.srv.cs.cmu.edu (smtp03.srv.cs.cmu.edu [128.2.217.202]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C07B41A0649 for <kitten@ietf.org>; Thu, 21 Aug 2014 17:43:54 -0700 (PDT)
Received: from [192.168.1.235] (184-195-240-202.pools.spcsdns.net [184.195.240.202]) (authenticated bits=0) by smtp03.srv.cs.cmu.edu (8.13.6/8.13.6) with ESMTP id s7M0hnIY006892 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Thu, 21 Aug 2014 20:43:50 -0400 (EDT)
Message-ID: <1408668228.5360.46.camel@destiny.pc.cs.cmu.edu>
From: Jeffrey Hutzelman <jhutz@cmu.edu>
To: Benjamin Kaduk <kaduk@MIT.EDU>
Date: Thu, 21 Aug 2014 20:43:48 -0400
In-Reply-To: <alpine.GSO.1.10.1408151401490.21571@multics.mit.edu>
References: <x7d7g2r0w58.fsf@equal-rites.mit.edu> <20140804161454.GH3579@localhost> <alpine.GSO.1.10.1408151401490.21571@multics.mit.edu>
Content-Type: text/plain; charset="UTF-8"
X-Mailer: Evolution 3.10.4-0ubuntu1
Mime-Version: 1.0
Content-Transfer-Encoding: 7bit
X-Scanned-By: mimedefang-cmuscs on 128.2.217.202
Archived-At: http://mailarchive.ietf.org/arch/msg/kitten/mn_vfeInJCooRODyz9ZOcwZhQ6A
Cc: kitten@ietf.org, jhutz@cmu.edu
Subject: Re: [kitten] Critical authorization data in Kerberos
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, 22 Aug 2014 00:43:56 -0000

On Fri, 2014-08-15 at 14:06 -0400, Benjamin Kaduk wrote:

> I think I am also fine with (1), but (4) does present a reasonably viable
> way forward, should we decide that we're interested in having actually
> mandatory/critical authdata at some point in the future.  The new
> container would contain things intended to be mandatory, with the
> understanding that much time would need to pass before consumers could
> rely on all peers actually respecting that intention.
> 
> The main question in my mind, deciding between (1) and (4), is: do we
> believe that we will want to specify authdata that are treated as critical
> by application servers, ever?  (What would such things look like?)  From
> the commentary in Bryce's email, it is unclear that we shoul have such an
> expectation.

The more I think about this, the more I think it's unrealistic to
believe we will ever be able to rely on application servers to treat AD
as critical.  Fortunately, I don't think that will actually be a
problem.  Any sort of restrictive authorization data likely to be
meaningful to an application will almost certainly have to be
application-specific.  The originator of such data, whether client or
KDC (or KDC administrator) will need to have some knowledge of the
service in order to construct it, and thus ought to know whether the
server is likely to be able to accept it.

That said, I can think of one class of uses for which critical AD would
be useful.  Specifically, suppose a user wishes to add AD to a ticket,
informing the server that the ticket should be usable only for a limited
subset of operations, and then forward that ticket to a third party.
The difficulty arises when the ability to do this has been added to an
application, and the user does not know whether the particular server is
new enough to support the new feature.  Resolving this basically
requires some negotiation mechanism within the application protocol.
But then, that's no different from what we have now.


In short, things might be a whole lot easier if we just give up on
critical AD and adopt (1), or a variation thereof.  Particularly, we can
update Kerberos to explicitly state that AD is non-critical, and give
KDC's permission to omit or strip AD-IF-RELEVANT in cases where the
server is known not to require it.  For example, the KDC might have a
per-service flag, or might infer this property for any service which is
known to support enctypes adopted after a particular date.

-- Jeff