Subject: RE: [nfsv4] AUTH_GSS for Callbacks

From: "wurzl, mario" <[email-masked]>
Date: Wed, 29 Oct 2003 18:18:46 -0500

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Mike Eisler
> Sent: Wednesday, October 29, 2003 17:54
> To: [email-masked]
> Subject: Re: [nfsv4] AUTH_GSS for Callbacks
> 
> 
> 
> 
>  > -----Original Message-----
>  > From: [email-masked]
>  > [mailto:[email-masked]]
>  > Sent: Wednesday, October 29, 2003 2:16 PM
>  > To: [email-masked]
>  > Subject: [nfsv4] AUTH_GSS for Callbacks
>  >
>  >
>  > It's me, confused again:-)
>  >
>  > I've read Sec. 3.4 a couple of times and can't figure out
>  > quite what the
>  > server is supposed to do w.r.t. GSS authentication for 
> Callbacks.  >  > The first para. seems to state that the 
> server should use the same  > principal the client used when 
> doing the SetClientid. Later, it seems  > to state that the 
> server should use the form:
> 
> Here's an example of how it is intended to work with Kerberos 
> V5 according to my interpretation (intent really since I 
> contributed that section) of 3.4.
> 
> The client uses root/<fqdn of client host> as the initiator 
> principal when it did SETCLIENTID. Note that RFC3530 doesn't 
> mandate this form at all ... think of that lack of mandate it 
> as a concession to the camp of NFS client implementors that 
> think machine creds are evil. I suspect this means that 
> they'll be using AUTH_NONE for SETCLIENTID, but I digress. :-)
> 
> The target principal for SETCLIENITD is mandated to be 
> nfs@<fqdn of server host>.
> 
> When the server does the call back, the target and initiator 
> principals are simply reversed. The initiator principal is 
> nfs@<fqdn of server host>, and the target principal is 
> root/<fqdn of client host>.

This implies that a system administrator will have to generate keys for a
service 'root@client' and store it in the Kerberos keytab of all client
systems. I have a hard time imagining a system administrator doing this
process for a network with several thousand clients.
It may become even worse if the principal for SETCLIENTID could be any user.

> 
> It can't be any other way ... otherwise the server can't be 
> sure the client it is sending the callback to is the right 
> client (the one that owns the client id), and similarly, the 
> client can't be sure the server issuing the callback is the 
> one that granted the delegation.
> 
> 
> 
> _______________________________________________
> nfsv4 mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/nfsv4
> 

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

---

From: Nicolas Williams <[email-masked]>
Date: Wed, 29 Oct 2003 15:27:02 -0800

On Wed, Oct 29, 2003 at 06:18:46PM -0500, wurzl, mario wrote:
Mike> When the server does the call back, the target and initiator 
Mike> principals are simply reversed. The initiator principal is 
Mike> nfs@<fqdn of server host>, and the target principal is 
Mike> root/<fqdn of client host>.
> It may become even worse if the principal for SETCLIENTID could be any user.

Multi-user clients are all pretty much going to need to have a Kerberos
V host-based principal and key(s), unless they never authenticate users
logging in to them (no kerberized telnet, no Kerberos password
validation, etc...).  So if you have a client that has the typical
"host@fqdn" principal then that's enough and you should not need to have
a root@fqdn" principal also.  (Yes, I know, Solaris clients insist on
having a root@fqdn principal.)

Cheers,

Nico
--

---

From: "J. Bruce Fields" <[email-masked]>
Date: Wed, 29 Oct 2003 19:25:53 -0500

> process for a network with several thousand clients.

It's going to be difficult to make the clients as secure as they should
be without one.

Any unique principal should suffice for the client, since the server
probably doesn't care in practice who the client is (usually it will
only matter that the client can identify the server.)

So why not just have a cgi script (or whatever) that hands out tickets
for principals of the form "anonymous-host/38456@MYREALM" to whoever
asks for one?  As long as it never hands out the same key twice, and as
long as the keys are transmitted securely, I don't see any risk.

--Bruce Fields

---

From: Mike Eisler <[email-masked]>
Date: Wed, 29 Oct 2003 16:47:51 -0800

> It may become even worse if the principal for SETCLIENTID could be any user.

What's the alternative?

I'm having some trouble understanding this oft repeated
system administrator's environment, since he seems to be interested
in security. How does each client get an IP address assigned to it?
Since we reject a manual process for several thousand clients,
we are left with DHCP or something like it. How does the client then get
its OS installed for first time? Some kind of automatic network installation/boot,
such as JumpStart.

But how does the client authenticate the DHCP server, the install server, and
the boot server?  And how is this authentication made mutual ... after
all, you don't want attackers inject trojan horses into the
physical network that capture user passwords.

There's a fundamental boot stapping problem. Which is
not my problem to solve, but if it is solved, securely, then
if there can be a service that securely and automatically
hands out IP addresses and OS images (including configuration files, possibly customized ...
JumpStart can do it) to clients, then it follows that there can be a service
that securely and automatically hands out customized krb5.keytab files to clients.

If the sys admin isn't concerned about the bootstrap problem, then why would
he be worried about the machine cred problem? Thus he might as well
configure his client (when it netinstalled) to use AUTH_NONE for SECINFO.

	-mre

---

From: Kevin Coffman <[email-masked]>
Date: Thu, 30 Oct 2003 09:14:44 -0500

> its OS installed for first time? Some kind of automatic network installation/

In our environment there isn't one "he" who is "the" system
administrator.  I've been asked by the help desk people, "When are
we going to get rid of this Kerberos thing that causes so many
problems?"

The people offering the service, NFSv4 for instance, may be
concerned about security, but the users just see it as a nuisance.

I guess that is our job: to try to make it secure and less of a
"nuisance".

K.C.