Re: About the purpose of client host principals for NFS

[Simo Sorce]

On Sun, 2023-10-08 at 03:03 +0200, Marco Rebhan via Kerberos wrote:
> On Saturday, 7 October 2023 22:15:32 CEST Russ Allbery wrote:
> > [..]
> 
> That clears up a lot, thank you so much!

Keying clients is useful to allow mount at boot time, before any user
with valid credentials has logged in, as well as for NFS 4.0 only (doe
snot apply to earlier protocol version nor to 4.1 and later) to do some
callback calls to the server where the protocol does not know what user
to use.

It is not strictly needed, if you use autofs for homes for example you
can live w/o a client service principal.

HTH,
Simo.

-- 
Simo Sorce,
DE @ RHEL Crypto Team,
Red Hat, Inc






Kerberos mailing list   Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos

Re: About the purpose of client host principals for NFS

[Marco Rebhan via Kerberos]

On Saturday, 7 October 2023 22:15:32 CEST Russ Allbery wrote:
> [..]

That clears up a lot, thank you so much!

-Marco


signature.asc
Description: This is a digitally signed message part.

Kerberos mailing list   Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos

Re: About the purpose of client host principals for NFS

[Russ Allbery]

Marco Rebhan via Kerberos  writes:

> What purpose does the host principal for clients serve here? I assumed
> it would be either used to authenticate hosts before they're allowed to
> obtain a TGT, or authenticate for mounting NFS shares, but clearly
> that's not the case since it works without. Is it only used so that the
> network share can be mounted without a user TGT?

Yup, pretty much.  There is indeed no need to key clients if you're going
to obtain credentials after login with something like kinit and you don't
care about more sophisticated Kerberos network protection features like
FAST.

The other reason to key a client is so that it can verify that the
password that you enter is indeed a valid Kerberos credential so that you
can use Kerberos to control access to the system itself.  If the system
doesn't have any keys (and you don't have something like anonymous PKINIT
available), then the client computer can't tell the difference between
getting Kerberos credentials from a real KDC or from a fake KDC that
someone put on the same network.  This only matters in cases where someone
might be trying to log on to the client system with fake Kerberos
credentials, and doesn't really matter if you're logging on to the system
with local credentials and then getting Kerberos credentials later.

(This is mostly relevant for work computers that use central Kerberos to
authenticate all access, computer labs that have multiple users, and
similar sorts of cases.)

-- 
Russ Allbery (ea...@eyrie.org) 

Kerberos mailing list   Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos

About the purpose of client host principals for NFS

[Marco Rebhan via Kerberos]

Hey list,

I'm currently setting up Kerberos for my home network. The main motivation was 
to get secure NFS, and as such I've looked at various guides on how to set it 
up for that. They (for example, the Arch Wiki[1]) pretty much all tell you to 
create principals for the host and NFS service for both the NFS server and 
clients that want to connect.

However, after setting up the NFS server and my Linux PC like this, I tested 
the whole setup with my MacBook which doesn't have a host principal or any 
other krb5 configuration yet (it can find the KDC due to DNS), and to my 
surprise it can both obtain a TGT for my user and afterwards also mount the 
NFS share.

What purpose does the host principal for clients serve here? I assumed it 
would be either used to authenticate hosts before they're allowed to obtain a 
TGT, or authenticate for mounting NFS shares, but clearly that's not the case 
since it works without. Is it only used so that the network share can be 
mounted without a user TGT?

Thanks,
Marco

[1]: https://wiki.archlinux.org/title/Kerberos#NFS_security

signature.asc
Description: This is a digitally signed message part.

Kerberos mailing list   Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos