Accessing Kerberos NFS version 4 (not 2, 3) via /net automounter with kinit only (no /etc/krb5.conf access)

Nico Williams nico at cryptonector.com
Tue Apr 15 15:34:11 EDT 2014


On Tue, Apr 15, 2014 at 2:22 PM, Will Fiveash <will.fiveash at oracle.com> wrote:
> But if this is a work laptop, which is typically a single user system
> and operates as a client in various contexts, requiring IT provision it
> with a keytab seems onerous to me.  Note that a Solaris NFS v3 client
> does not require root have a krb cred to operation, even when
> automounting -- it only requires the user that triggered the automount
> have a krb cred.

What should happen is that there should be a way to enroll a device.

That could be as simple as a kadm5 (or HTTP, or RFC3244 extension) API
that allows a user to create and key a principal of a form such as
device/<username>/<random>@<REALM> or just device/<random>@<REALM>.
The <random> should have no periods and should be illegal as a
hostname, and it should mostly be a base64 encoding of a few bytes of
/dev/urandom output.

(Roland's tools have a mechanism for joining a host to a realm using
multi-party ECDH to key it, and a site-local procedure for "blessing"
a host principal.  A similar but simplified approach could work here.)

> I think part of the problem is that the gss security context protecting
> the channel along with the user's krb cred could expire at any time.  I
> think that's why they wanted root to use a key stored in the keytab (I
> could be wrong of course).

No, that is a problem.  NFSv4.1 does something to address this, IIRC,
though I forget the details.

Nico
--


More information about the Kerberos mailing list