Re: [nfsv4] Path forward for flex-files

Benjamin Kaduk <> Tue, 08 August 2017 00:25 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 0E95A131D1E for <>; Mon, 7 Aug 2017 17:25:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.201
X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 87gTOZprZeNx for <>; Mon, 7 Aug 2017 17:25:54 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 732CE131CEA for <>; Mon, 7 Aug 2017 17:25:54 -0700 (PDT)
X-AuditID: 1209190e-041ff70000000db6-c7-598905110f60
Received: from ( []) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by (Symantec Messaging Gateway) with SMTP id 93.50.03510.11509895; Mon, 7 Aug 2017 20:25:53 -0400 (EDT)
Received: from (OUTGOING-AUTH-1.MIT.EDU []) by (8.13.8/8.9.2) with ESMTP id v780PpeL014912; Mon, 7 Aug 2017 20:25:52 -0400
Received: from ( []) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by (8.13.8/8.12.4) with ESMTP id v780PmxM009051 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 7 Aug 2017 20:25:51 -0400
Date: Mon, 07 Aug 2017 19:25:48 -0500
From: Benjamin Kaduk <>
To: Rick Macklem <>
Cc: "" <>, Thomas Haynes <>
Message-ID: <>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
User-Agent: Mutt/1.8.3 (2017-05-23)
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrMIsWRmVeSWpSXmKPExsUixCmqrCvI2hlpsK1Z0GL5nq3sFrPfP2K1 eLjsGpMDs8eSJT+ZPObPlfP4vXkvUwBzFJdNSmpOZllqkb5dAlfGvgNbWQq+cFXs+P6JvYHx LUcXIweHhICJxPXHeV2MXBxCAouZJDoPNrNBOBsYJbb9X80E4Vxhkrh24C9rFyMnB4uAisTW rlVsIDYbkN3QfZkZxBYRUJfYvLofzGYW8JW48fgamC0sYCCx7/h+NpBtvEDbbv/whJh5i1Fi T9M7RpAaXgFBiZMzn7BA9GpJ3Pj3kgmknllAWmL5Pw6QMKdArETTvu9gI0UFlCXm7VvFNoFR YBaS7llIumchdC9gZF7FKJuSW6Wbm5iZU5yarFucnJiXl1qka6yXm1mil5pSuokRHLaSfDsY JzV4H2IU4GBU4uFlyOyIFGJNLCuuzD3EKMnBpCTKy7kFKMSXlJ9SmZFYnBFfVJqTWnyIUYKD WUmE14WlM1KINyWxsiq1KB8mJc3BoiTOK67RGCEkkJ5YkpqdmlqQWgSTleHgUJLg5QNpFCxK TU+tSMvMKUFIM3FwggznARr+khlkeHFBYm5xZjpE/hSjopQ4rw1IswBIIqM0D64XlFYksvfX vGIUB3pFmHcqSDsPMCXBdb8CGswENPhNYivI4JJEhJRUA6PjCm+VgzJZZ3tP6he17hRk9FrA UFYzfyOXo4Pkh2mTHBW+shu+nVC6vXtzvNIOpXNp4iGprue9biSbBWx/sXdfxf62Q9FnF7+d vPxn+Y3aR+kXSqdMqtrx1lW0ONbK+nKyQ9ebzFi+6Z/fPDhfzKCYu1d0q8aMjBtHGDQFk+dv 0LQ1XPHh2EolluKMREMt5qLiRAAZwdM7BgMAAA==
Archived-At: <>
Subject: Re: [nfsv4] Path forward for flex-files
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NFSv4 Working Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 08 Aug 2017 00:25:56 -0000

On Tue, Aug 08, 2017 at 12:20:26AM +0000, Rick Macklem wrote:
> Benjamin Kaduk wrote:
> [stuff snipped]
> > The solution space looks rather different whether the synthetic principals
> > are actually being created/deleted on the KDC or synthesized using the
> > data server's keytab.
> I'm not sure what you are thinking of w.r.t. synthesized using the data server's keytab,
> but I am curious?

A service ticket is "just" some DER-encoded data encrypted+MAC'd in a symmetric
key shared between the KDC and the service principal (in the simple case).
When the service application receives a service ticket along with the client's
request, the service knows that the ticket came from the KDC because the
MAC verifies, generating/verifying the MAC requires that symmetric shared
key, and the service knows that it didn't generate the ticket itself.
Note the logical leap at the end -- it's assumed from the KDC because the
KDC is the only other party that's supposed to have the key material.
But really, anyone with the right key can encode the right data and encrypt+MAC
it using that key -- this allows one to print a ticket to onesself that
claims to be for a client principal that does not even exist in the
KDC's database.

We use this "ticket printing" technique in AFS for server-to-server
communications, and it's exposed to some maintenance tools as well.