Subject: [nfsv4] Request for WG Last Call

From: Thomas Haynes <[email-masked]>
Date: Thu, 20 Jul 2017 11:57:32 +0000

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
https://datatracker.ietf.org/doc/draft-ietf-nfsv4-layout-types/ - draft 05

So this is that request...

---

From: Olga Kornievskaia <[email-masked]>
Date: Mon, 24 Jul 2017 17:13:45 -0400

> 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.

---

From: Thomas Haynes <[email-masked]>
Date: Mon, 24 Jul 2017 21:32:47 +0000

> On Jul 24, 2017, at 2:13 PM, Olga Kornievskaia <[email-masked]> wrote:
> 

And then I am stuck because it is very likely that during the IESG review will
most likely require that security be addressed.

fwiw - the KDC need not be on the same server as the MDS. 

My takeaway is that I need to rewrite the security sections.

Thanks

---

From: "Mkrtchyan, Tigran" <[email-masked]>
Date: Tue, 25 Jul 2017 10:13:57 +0200 (CEST)

Hi Tom, 

some typos: 

page 6: 
" A client presenting the 
wrong credential for the deisred access will get a NFS4ERR_ACCESS 
error." deisred -> desired 

page 7: 
"that would never be used to grant acccess." acccess -> access 

page 9: 
"OPEN_DOWNGRADE and CLOSE only require local execution on the 
metadata sever." sever -> server 

page 10: 
"2.3.2. Tighly Coupled Locking Model" Tighly -> Tightly 

"of the association between the metadata-sever-chosen stateid and" metadata-sever-chosen -> metadata-server-chosen 
"device aware of the association between the metadata-sever-chosen" metadata-sever-chosen -> metadata-server-chosen 

page 11: 
"rather than only to daya storage device that contain the locked" daya -> data 

page 19: 
" If an implementation needs a different statedid per file handle, then" statedid -> stateid 

page 20: 
" if the client could determine that there was a network diconnect" diconnect -> disconnect 

page 24: 
"client's responsibility with resepect to COMMIT is explained in" resepect -> respect 

page 36: 
"modifying the syntethic uid or gid on the data file." syntethic -> synthetic 

Regards, 
Tigran. 

> From: "Thomas Haynes" <[email-masked]>
> To: "NFSv4" <[email-masked]>
> Sent: Thursday, July 20, 2017 1:57:32 PM
> Subject: [nfsv4] Request for WG Last Call

> [ https://datatracker.ietf.org/doc/draft-ietf-nfsv4-flex-files/ |
> https://datatracker.ietf.org/doc/draft-ietf-nfsv4-flex-files/ ] - draft 12
> [ https://datatracker.ietf.org/doc/draft-ietf-nfsv4-layout-types/ |
> https://datatracker.ietf.org/doc/draft-ietf-nfsv4-layout-types/ ] - draft 05

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

---

From: Thomas Haynes <[email-masked]>
Date: Tue, 25 Jul 2017 18:26:38 +0000

Hi Tigran,

Thanks and as a fyi to all of you draft authors: https://tools.ietf.org/tools/idspell/webservice is nice, I know I should have used it more. :-)

Tom

On Jul 25, 2017, at 1:13 AM, Mkrtchyan, Tigran <[email-masked]<mailto:[email-masked]>> wrote:

Hi Tom,

some typos:

   page 6:

 page 7:

 page 9:

 page 10:

 page 11:

 page 19:

 page 20:

page 24:

 page 36:

Regards,
   Tigran.

________________________________
From: "Thomas Haynes" <[email-masked]<mailto:[email-masked]>>
To: "NFSv4" <[email-masked]<mailto:[email-masked]>>
Sent: Thursday, July 20, 2017 1:57:32 PM
Subject: [nfsv4] Request for WG Last Call
One of my AIs from the IETF meeting was to inform the WG that I wanted the following two documents to be in WGLC:

_______________________________________________
nfsv4 mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/nfsv4