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

From: Rick Macklem <[email-masked]>
Date: Sun, 6 Aug 2017 21:14:20 +0000

My Kerberos/RPCSEC_GSS is pretty rusty, but I think the following is a rough
description of something that might work for the "loose coupling" case.
(And now I finally know why the old draft referred to TGTs.;-)

First, I'll note that fattr4_owner and fattr4_owner_group isn't defined anywhere
and, if you just define is a opaque<>, with either "user@domain" or "<numeric-id>"
in it for the AUTH_SYS case, I doubt you will have to rev. the XDR. (Which makes the
path forward easier for us lazy implementors;-)

Anyhow, here goes...
Here's one way I think a "loose coupled" Flexible File Layout pNFS service
could use Kerberos/RPCSEC_GSS.
A few assumptions:
1 - The DS systems are vanilla NFSv3/4 servers that have Kerberos/RPCSEC_GSS
    support in them.
2 - This is Kerberos specific, which seems ok, since all extant servers
    will only support Kerberos mechanism.
3 - The MDS can somehow:
    - Create/delete entries from the password database (assuming DS servers
      implemented using POSIX-like users/uids/gids).
      (I know nothing about LDAP, but I'd guess this is doable?)
    - Create/delete User principals in the KDC with passwords that the
      MDS will know/set when these principals are created.

The MDS would create a synthetic user/uid/gid, adding it to the password
database. It would create an associated User principal of the same name
in the KDC.
- It would then acquire a "forwardable, renewable" TGT for this principal.
It could use this TGT to acquire an RPCSEC_GSS context for the DS, so it
could perform RPCs as this synthetic "user" against the DS.

When a client requests a layout:
- The MDS would reply with the TGT for the synthetic user in fatt4_owner, after
  encrypting it in the key for the RPCSEC_GSS context that the client has against the
  MDS for its LayoutGet RPC. (ie. It would GSS_Wrap() the TGT.)
  --> This is similar to what happens when a Kerberos client does a "kinit",
      except the ticket has been encrypted in the RPCSEC_GSS context key
      (which it knows) instead of a key based on the principal's password
      (which the client does not know).

The client takes the GSS_Wrap()'d TGT. GSS_Unwrap()s it and puts it in a
credential cache for the "synthetic user". (My Kerberos is rusty, so I can't
remember if the principal name is in the TGT? If not, it needs to be sent
along with the TGT to the client in the Layout.)

The client can then do the normal RPCSEC_GSS Init sequence against the DS
to get a context for the synthetic user. It can then use this context for
I/O RPCs against the DS.

If the Kerberos tickets have a short lifetime, but are renewable for a long
time, the RPCSEC_GSS context timeout will normally be set to that short
ticket lifetime and the client will regularily do the RPCSEC_GSS Init sequence again
to get new contexts.
--> This means that, once the MDS deletes the synthetic principal from the KDC,
    it won't work for long against the DSs, I think?
    (Deleting the principal from the KDC may be useful for fencing off, see
     below.)

I think the "gid" can be handled by using a second "synthetic principal" handled
in the same manner. (ie. It would not "own" the file but would have the "gid"
of the group for the file in the password database.)

One problem I see with is that the MDS may need "root" access to
the DS, if it is going to do fencing via a change in ownership.
(I think this is doable using Kerberos, but certainly weakens security.
 Something like putting a "root@REALM" user principal in the KDC and
 generating a keytab entry for it for the MDS. But having a keytab entry for
 "root@REALM" is pretty scary;-)
- An alternative that might be worth considering would be to have the MDS delete
  the synthetic principal in the KDC, so that clients can no longer use it to access
  the file on the DS?

rick

---

From: Rick Macklem <[email-masked]>
Date: Sun, 6 Aug 2017 21:27:48 +0000

Here's a couple of typo fixes for the last post, just in case it didn't make sense;-)

> and, if you just define is a opaque<>,
and,n if you just define it as a opaque<>,...

>      (which it knows) instead of a key based on the principal's password
(which the client knows) instead of a key based on the principal's password

> The client takes the GSS_Wrap()'d TGT. GSS_Unwrap()s it and puts it in a
The client takes the GSS_Wrap()'d TGT, GSS_Unwrap()s it, and puts it in a

> One problem I see with is that the MDS may need "root" access to
One problem I see with this is that the MDS may need "root" access to

rick

---

From: Olga Kornievskaia <[email-masked]>
Date: Mon, 7 Aug 2017 12:03:11 -0400

> First, I'll note that fattr4_owner and fattr4_owner_group isn't defined anywhere

dot-x defs: https://www.rfc-editor.org/rfc/rfc7531.txt

   typedef utf8str_mixed   fattr4_owner;
   typedef utf8str_mixed   fattr4_owner_group;

> - The MDS would reply with the TGT for the synthetic user in fatt4_owner, after

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.

> _______________________________________________
> nfsv4 mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/nfsv4

---

From: Olga Kornievskaia <[email-masked]>
Date: Mon, 7 Aug 2017 12:03:11 -0400

---

From: Rick Macklem <[email-masked]>
Date: Mon, 7 Aug 2017 19:19:10 +0000

>   typedef utf8str_mixed   fattr4_owner_group;
Oh well. I've never looked at that RFC.
The draft could just be changed to define the ffds_user and ffds_group as opaque<>
instead of utf8str_mixed? (I don't think this would affect extant implementations,
which will just assume a utf string is in there and can't handle/support Kerberos.)
[stuff snipped]
> the ticket you need to send the other pieces.
Well, maybe a service ticket would work, but it would require a lot more "hacking"
on the RPCSEC_GSS code, I think?
- During initialization, the RPCSEC_GSS l;ayer normally calls
  gss_init_sec_context(). In the vanilla Heimdal libraries, this works if there
  are valid credentials in the credential cache and those come from the TGT.
  (I'll admit my Kerberos is rusty. If you can easily get gss_init_sec_context() to work
   with a service ticket, then I believe you. Also, I've never worked with the MIT libraries.)

rick

---

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

>    with a service ticket, then I believe you. Also, I've never worked with the MIT libraries.)

No hacking needed; it works out of the box.

kaduk@prolepsis:~$ kinit -l5m -r5m -S host/rosebud2.mit.edu kaduk/root
Password for kaduk/[email-masked]: 
SAM Authentication
Challenge from authentication server
Duo login: Passcode/option or press return for options: 
kaduk@prolepsis:~$ ssh -o GSSAPIAuthentication=yes -o GSSAPIDelegateCredentials=no [email-masked]
Linux rosebud2 3.2.0-4-amd64 #1 SMP Debian 3.2.81-1 x86_64

The programs included with the Debian GNU/Linux system are free software;
the exact distribution terms for each program are described in the
individual files in /usr/share/doc/*/copyright.

Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent
permitted by applicable law.
Last login: Sun Aug  6 08:57:20 2017 from vpn-18-101-71-85.mit.edu
root@rosebud2:~# 

-Ben