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
- [kitten] Critical authorization data in Kerberos Greg Hudson
- Re: [kitten] Critical authorization data in Kerbe… Nordgren, Bryce L -FS
- Re: [kitten] Critical authorization data in Kerbe… Greg Hudson
- Re: [kitten] Critical authorization data in Kerbe… Nordgren, Bryce L -FS
- Re: [kitten] Critical authorization data in Kerbe… Nico Williams
- Re: [kitten] Critical authorization data in Kerbe… Benjamin Kaduk
- Re: [kitten] Critical authorization data in Kerbe… Jeffrey Hutzelman
- Re: [kitten] Critical authorization data in Kerbe… Nico Williams
- Re: [kitten] Critical authorization data in Kerbe… Benjamin Kaduk
- Re: [kitten] Critical authorization data in Kerbe… D.Rogers