Subject: Re: [nfsv4] Path forward for flex-files

From: Rick Macklem <[email-masked]>
Date: Mon, 7 Aug 2017 23:03:44 +0000

Olga Kornievskaia wrote:
[lots of stuff snipped]
> That's the problem you need something in the structure to pass back
> the ticket (TGT is not necessary. service ticket would do). Besides
> the ticket you need to send the other pieces.
Oh, the reason I was thinking of using TGT tickets was related to my comment
at the end about deleting the synthetic principal to do fencing.

I was thinking of a TGT with a fairly long lifetime (as long as layouts need
to be valid) and a service ticket with a short lifetime, so that the client keeps
using the TGT to get a new service ticket/GSS-context.
Then, this would fail when the synthetic principal is deleted in the KDC.
(I don't think that renewable tickets are needed, that was a brain fart on my part.)

rick

---

From: Benjamin Kaduk <[email-masked]>
Date: Mon, 7 Aug 2017 18:29:25 -0500

> (I don't think that renewable tickets are needed, that was a brain fart on my part.)

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.  In the case where the KDC is involved, ticket
lifetimes and principal existence are somewhat annoying to manage -- in
order to have a long-lived TGT but get short-lived service tickets, with
(e.g.) an MIT krb5 KDC you'd either have to use a custom policy plugin to limit
the service ticket lifetime, or set the max lifetime on the data server's
service principal to that short lifetime (which has annoying effects for
anything that's supposed to be connecting to it directly).  As far as principal
management, the fencing would not be particularly instantaneous -- the
current ticket would have to expire, and the principal deletion/deactivation
would need to propagate to all KDCs in the realm.  IIRC it's also possible
to have a KDC that doesn't even pull up the client principal's database
entry when generating a service ticket from a TGT (i.e., it would not
actually notice the deleted client principal!), which of course would not
work for this use case.

-Ben

---

From: Rick Macklem <[email-masked]>
Date: Tue, 8 Aug 2017 00:20:26 +0000

Benjamin Kaduk wrote:
[stuff snipped]
> 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?

>  In the case where the KDC is involved, ticket
Oh well, doesn't sound like a good plan.

And I'm happy with a second version of XDR when this is done.

rick, who is glad he chose "tightly coupled";-)

---

From: Benjamin Kaduk <[email-masked]>
Date: Mon, 7 Aug 2017 19:25:48 -0500

> I'm not sure what you are thinking of w.r.t. synthesized using the data server's keytab,

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.

-Ben

---

From: Rick Macklem <[email-masked]>
Date: Tue, 8 Aug 2017 13:04:28 +0000

>communications, and it's exposed to some maintenance tools as well.
Ok, so a simple way of doing this would be to...
- Create the synthetic principals on the KDC and acquire keytab entries for them.
- Move the keytab entries to a file in the MDS.
Then the MDS could generate a service ticket for the synthetic principal by acquiring
a TGT for the synthetic principal and then letting gss_init_sec_context() do the rest?
(I think you can also do this for the principal "root@MYREALM" and the MDS can
 use that to gain "root" access to the DS for at least some Kerberized NFS servers.
 I believe I did this "root" trick in FreeBSD and it worked, although I wouldn't
 recommend it from a security point of view.)

Thanks for the info, rick