On Tue, Apr 15, 2014 at 2:22 PM, Will Fiveash <will.five...@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 -- ________________________________________________ Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos