Re: [kitten] Critical authorization data in Kerberos
Greg Hudson <ghudson@MIT.EDU> Sat, 02 August 2014 21:20 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 1E0FD1B29C8 for <kitten@ietfa.amsl.com>; Sat, 2 Aug 2014 14:20:12 -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 WK10Y_cDXmwD for <kitten@ietfa.amsl.com>; Sat, 2 Aug 2014 14:20:10 -0700 (PDT)
Received: from dmz-mailsec-scanner-2.mit.edu (dmz-mailsec-scanner-2.mit.edu [18.9.25.13]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 276C31B29C7 for <kitten@ietf.org>; Sat, 2 Aug 2014 14:20:09 -0700 (PDT)
X-AuditID: 1209190d-f79c06d000002f07-a8-53dd56083c13
Received: from mailhub-auth-1.mit.edu ( [18.9.21.35]) (using TLS with cipher AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-2.mit.edu (Symantec Messaging Gateway) with SMTP id D0.5D.12039.8065DD35; Sat, 2 Aug 2014 17:20:08 -0400 (EDT)
Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-1.mit.edu (8.13.8/8.9.2) with ESMTP id s72LK76d014217; Sat, 2 Aug 2014 17:20:08 -0400
Received: from [18.101.8.244] (vpn-18-101-8-244.mit.edu [18.101.8.244]) (authenticated bits=0) (User authenticated as ghudson@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id s72LK50v011940 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Sat, 2 Aug 2014 17:20:07 -0400
Message-ID: <53DD5605.3050901@mit.edu>
Date: Sat, 02 Aug 2014 17:20:05 -0400
From: Greg Hudson <ghudson@MIT.EDU>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0
MIME-Version: 1.0
To: "Nordgren, Bryce L -FS" <bnordgren@fs.fed.us>, "'kitten@ietf.org'" <kitten@ietf.org>
References: <x7d7g2r0w58.fsf@equal-rites.mit.edu> <82E7C9A01FD0764CACDD35D10F5DFB6E70E278@001FSN2MPN1-045.001f.mgd2.msft.net>
In-Reply-To: <82E7C9A01FD0764CACDD35D10F5DFB6E70E278@001FSN2MPN1-045.001f.mgd2.msft.net>
X-Enigmail-Version: 1.5.2
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrBIsWRmVeSWpSXmKPExsUixCmqrMsRdjfY4NE5c4urb36yWhzdvIrF gcnj9puzLB5LlvxkCmCK4rJJSc3JLEst0rdL4Mp4ubSdreC9cMX9U8eYGhhnCXQxcnJICJhI 9H9tZ4GwxSQu3FvP1sXIxSEkMJtJYmX/SUYIZwOjxI0HjVCZw0wSx28fZwdp4RVQk7i68yUb iM0ioCrx4t8UsFFsAsoSB89+A7NFBcIkHs85xwhRLyhxcuYTsLiIQKLE3e/PmEBsYQFbib5b 58BmCgnUSsy5cB0ozsHBKRAhMfehOMR1khLbFh0DK2EW0JF41/eAGcKWl9j+dg7zBEbBWUg2 zEJSNgtJ2QJG5lWMsim5Vbq5iZk5xanJusXJiXl5qUW6Rnq5mSV6qSmlmxjBASzJu4Px3UGl Q4wCHIxKPLwG+24HC7EmlhVX5h5ilORgUhLlXWZ1N1iILyk/pTIjsTgjvqg0J7X4EKMEB7OS CO95PaAcb0piZVVqUT5MSpqDRUmc9621VbCQQHpiSWp2ampBahFMVoaDQ0mCd0sIUKNgUWp6 akVaZk4JQpqJgxNkOA/Q8FMgNbzFBYm5xZnpEPlTjIpS4rzdwUAJAZBERmkeXC8swbxiFAd6 RZj3Pkg7DzA5wXW/AhrMBDS4xvA2yOCSRISUVANjotPh+3muDKv1IhxeLHkt/LslTcDNUu30 ba0Ph8/ddJMyD5Vme++w7nb3Ls7/r9QDCk4ZXw8NvBuaK3R9f8ShcLetT/I4Sg9dfNmdtezH sqXHJup/uCRWo7vwiaPS/l1F767PvGYQcOde9FaeDRIHOnu7d0W9uXna2uv44xcGGzpacyfs EQ17pMRSnJFoqMVcVJwIAHdJssMLAwAA
Archived-At: http://mailarchive.ietf.org/arch/msg/kitten/5V1rllSvGu7PO3PEjNHo-r5B3Ss
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: Sat, 02 Aug 2014 21:20:12 -0000
On 08/02/2014 03:59 PM, Nordgren, Bryce L -FS wrote: > 1] Mandatory auth data sounds to me like something that absolutely everything in the domain (including the KDC) needs to understand consistently, due to the fact that it is essentially broadcast to all domain services. It results in permitting or denying access by the holder of a service ticket (to all services? To some but not others?). Since permitting or denying access based on information possessed by the KDC could be implemented simply by not issuing a ticket, why communicate this to services at all? Are there some cases where the KDC is unaware of a critical piece of information to make the decision? RFC 4120 envisions authdata which is understood by the client and server, but not the KDC. Much as you can request a ticket for a shorter lifetime than the maximum lifetime, you could conceivably request a ticket that can only be used for specific purposes. Authorization can be finer-grained than completely denying access to a service, so it cannot always be implemented as a TGS policy. You could have access to an HTTP server but not access to all of its resources, for instance. Authorization data does not have to be broadcast to every service in a domain. It could be requested by the client in a TGS request or even in an AP request, or originated by the KDC for some service tickets and not others. > 2] Would the notion of "splitting the difference" be helpful? Keep the auth data processing out on the services, but have the KDC only encode mandatory auth data it expects a particular service to abide by. This approach has the domain-wide effect of "Mandatory if applicable", but the semantics of "Mandatory for you, Service X". It also puts the KDC in control of what is considered applicable to what services. I think this approach may allow service implementations to start obeying "mandatory" ad without fear of breaking all services in the entire domain. Making the KDC aware of software capabilities on each server is not always easy to administer, especially as there is no standard way for servers to communicate information like that to a KDC. > 3] What pieces of auth data have presented themselves as uniformly mandatory for all of a domain's web services, file servers, workstations, directory services, etc. to respect? I think I covered this in my post: nothing so far. The only standardized mandatory authdata element I'm aware of is AD-fx-fast-armor, and that is only intended to be mandatory for the KDC.
- [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