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