Re: [nfsv4] Request for WG Last Call

[Olga Kornievskaia <[e-mail]>]

On Thu, Jul 20, 2017 at 7:57 AM, Thomas Haynes <[e-mail]> wrote:
> One of my AIs from the IETF meeting was to inform the WG that I wanted the
> following two documents to be in WGLC:
>
> https://datatracker.ietf.org/doc/draft-ietf-nfsv4-flex-files/ - draft 12

Comments with respect to 15.1.1.

It is not a good idea to have a file server be a KDC as well. From MIT
folks: https://web.mit.edu/kerberos/krb5-devel/doc/admin/install_kdc.html
warning
....
"It is best to install and run KDCs on secured and dedicated hardware
with limited access. If your KDC is also a file server, FTP server,
Web server, or even just a client machine, someone who obtained root
access through a security hole in any of those areas could potentially
gain access to the Kerberos database."

15.1.1 is too short and unclear for such a strong suggestion. Is the
spec proposing to define a new kerberos realm specific for the
"synthetic" users (uids)? Non-pkinit Kerberos is password based so
what passwords are associated with the synthetic uids and how does the
user know them? The statement controlling access by "expiring ticket"
doesn't make sense. Once the Kerberos ticket is issued it's valid
until it expires. You can control it by issuing extremely short-lived
tickets but that would be a pain that your IO would be stopped because
the lifetime of the ticket is too short.

Also, if there is an assumption that MDS is the KDC and all other DSs
are a part of that realm, then why can't we start with an assumption
that MDS and DSs are a part of the "original" realm that user used to
authenticate to the KDC. If in loosely-coupled there is no control of
stateids or security, then (in my opinion) it can't use Kerberos as a
security mechanism. If DSs say reside in different Kerberos realms,
then there is such a thing as cross-domain Kerberos authentication and
it is being used in practice.

My suggestion is to scrap Kerberos from 15.1.1 loosely coupled and
just leave the synthetic uids fencing.