Re: [nfsv4] Kerberos ticket expiration and NFSv4 state

cburnett@us.ibm.com

Subject: Re: [nfsv4] Kerberos ticket expiration and NFSv4 state
Message-ID: <OF7C15199F.F79A4103-ON87256DB0.006CC5D3@us.ibm.com>
From: Carl Burnett <cburnett@us.ibm.com>
Date: Mon, 29 Sep 2003 14:57:06 -0500

As Kevin mentions, the administrative overhead of having to maintain a 
client host principal with DCE/DFS was not popular. This is why later 
releases offered the option of slim client where the client did not have a 
host principal. The trade-off was some security exposure for host to host 
transactions with the benefit of reduced administration. Strong security 
for users accessing data still applied. Many environments that trusted 
their networks were willing to make this trade-off as DCE slim client was 
incredibly popular - especially for DFS installations. For environments 
with higher security requirements or application servers, host principals 
were often used. In addition, the DFS server could be set such that it 
required full DCE (krb5) authentication even for host to host transactions 
such as state management. You could even set the server to allow only 
integrity or privacy.

Carl Burnett
AIX Kernel Architecture - Network File System
(512) 838-8498, TL 678-8498
(please reply to cburnett@us.ibm.com)

Kevin Coffman <kwc@citi.umich.edu>
Sent by: nfsv4-admin@ietf.org
09/29/2003 02:31 PM

        To:     Mike Eisler <mike@eisler.com>, "J. Bruce Fields" <bfields@fieldses.org>, 
nfsv4@ietf.org
        cc: 
        Subject:        Re: [nfsv4] Kerberos ticket expiration and NFSv4 state

> On Mon, Sep 29, 2003 at 12:04:06PM -0700, Mike Eisler wrote:
> > J. Bruce Fields wrote:
> > 
> > >On Mon, Sep 29, 2003 at 10:37:43AM -0700, Mike Eisler wrote:
> > >>(who among clients uses Kerberos V5 for SETCLIENTID?
> > >>Don't all stand up at once. :-))
> > >
> > >Standing up, sheepishly....
> > >
> > >Using krb5 for the setclientid turns out to be a pain, though, since 
it
> > 
> > Why? Pick principal name, any principal name, preferablly host
> > instance specify, shove it into krb5.keytab, configure your
> > client to use that for SETCLIENTID. Done.
> > 
> > >means the client has to have some sort of machine or root creds 
around
> > >all the time.  I'd like to understand what the implications are of 
using
> > 
> > I'm failing to understand why machine creds make people unhappy.
> > I can't imagine how such people manage to run IPsec.
> 
> What bothers some users is the need for a host/<hostname>@<realm> princ
> for Kerberos V authentication + root/<hostname>@<realm> for NFS client
> support.  Arguably one should do - and it's true, it's just a small
> matter of programming/configuration.

What bothers administrators is that these host/root keys require
administrator action for each client.  As I recall, this was a
detriment to DCE/DFS.  And while it is true that a host key is
required to do K5 authentication correctly, it is often not done
correctly :-/

_______________________________________________
nfsv4 mailing list
nfsv4@ietf.org
https://www1.ietf.org/mailman/listinfo/nfsv4

_______________________________________________
nfsv4 mailing list
nfsv4@ietf.org
https://www1.ietf.org/mailman/listinfo/nfsv4