Re: [nfsv4] Stephen Farrell's Discuss on draft-ietf-nfsv4-rfc3530bis-26: (with DISCUSS and COMMENT)

["Haynes, Tom" <[e-mail]>]

Stephen,

Thanks for the review. We had some larger issues to iron out.

Tom

On May 28, 2013, at 9:07 AM, Stephen Farrell <[e-mail]> wrote:

> Stephen Farrell has entered the following ballot position for
> draft-ietf-nfsv4-rfc3530bis-26: Discuss
> 
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines. (Feel free to cut this
> introductory paragraph, however.)
> 
> 
> Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html
> for more information about IESG DISCUSS and COMMENT positions.
> 
> 
> 
> 
> ----------------------------------------------------------------------
> DISCUSS:
> ----------------------------------------------------------------------
> 
> 
> (The diff with 3530 wasn't very useful, so I just read as much
> of the draft as I could and commented as if this was new text
> describing a widely deployed protocol. Please feel free to argue
> that anything that is in 3530 that doesn't really need to
> change.)
> 
> (1) 3.2.1.1.1: RFC6649 is a BCP. I think you need to say that
> implementations MUST follow its guidance, and not just that 6649
> offers guidance.  
> 

We have existing implementations which have weak algorithms
and do not yet have strong ones. And this implementations might
never be updated.

Since they predated 6649, we've kept this as is.

(Full disclosure, I work for a company in such a situation for
one of its two NFSv4.0 implementations.)


> (2) 10.4.1, last para: "making private copies" of credentials
> sounds odd.  I assume you mean kerberos tickets but I'm not sure
> how that can work. I'd also guess its security mechanism
> specific.  Doesn't that need either some more text or to just
> say that it doesn't work? Or am I confused? (Quite possible;-)

Actually, it simply means UID and GID here.

As an example, there are scenarios in Solaris where when pages
get flushed to disk, the UID and GID from the original system
write have been lost and the page goes across the wire
with root credentials. This can be okay on a local file system
but not on a remote one.

> 
> (3) 15.33.5, 2nd last para: this says that if the server says
> AUTH_NONE then the client can try any mechanism it likes, but
> that then the client "SHOULD always be prepared" to fall back to
> AUTH_NONE.  That seems broken. If the client wanted AUTH_foo for
> some foo then why would AUTH_NONE be ok? Perhaps this ought say
> that the client "MUST be able to handle a failure and SHOULD NOT
> fall back to AUTH_NONE" instead?


If the server advertises AUTH_NONE, then it means it will accept
any flavor.

I.e., -sec=krb5:none

means that if the client flavor is krb5, then it gets krb5. Else the
server accepts the request and it is treated as AUTH_NONE.


> 
> 
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
> 
> 
> - general: Just wondering: Have we learned anything since 3530
> (10 years ago) about DoS vectors related to NFS and mitigations
> that is worth a mention?


No.

> 
> - general: Is there anything to be said on the
> size/randomness/difficulty-to-guess for numbers that are used in
> the protocol?  The ones where that might be useful that I
> spotted were: file handles, Client IDs, Stateid, Verifier,
> chaingid4 values, nfs_cookie4, nfs_locid4, verifier4, *.opaque
> (e.g. nfs_client_id4.opaque).  I'm not asking that you add a
> MUST or anything, but rather if it'd be good to say (for some of
> these) that implementations SHOULD or ought ensure that values
> have some good randomness, especially for cases where weaker or
> no security is used in a deployment.
> 


My guess would be in practice many implementations depend
on well known starting values. I could be wrong.


> - What replaced LIPKEY/SPKM-3?

Nothing, no one implemented it.

> 
> - Are seqid4 values supposed to start from a random value?

See Section 9.1.3.2.  Stateid Structure


> 
> - 3.3.2: What does "minimal security triple" mean? It could mean
> "a MTI triple" or "the weakest triple." I think you should
> clarify.

Going to let the kerberos experts in the WG alias jump in here.

> 
> - 4.2.4: Would it be worth mentioning that a server could
> encrypt (for itself) the boot-time, slot and generation number?
> 
> - section 5: I would guess that some commonly used named
> atrributes might have privacy considerations, e.g. geographic
> location or timing information associated with the file.  (Like
> image exif data for example.) Are those noted anywhere? Might be
> worth just a mention that there can be privacy issues with
> those.  Similarly, the standard owner and time_create attributes
> might be privacy sensitve. (I'm not suggesting NFS do anything
> about that, other than just note it.)
> 
> - 5.8.2.5: What's a privileged user in NFS or does this mean in
> one of or both the client or server OS? While I get what you
> mean, this seems somewhat vague.

Meant to be?

> 
> - 6.1, ACE is used before its expanded, but since the expansion
> is about 4 lines down, I forgive you:-)
> 
> - 6.2.1.4: I wondered what a server is supposed to do if an
> AUDIT or ALARM event is supposed to happen but the (server
> specific) logging or alarm actions doesn't work. Should the
> server behave as if no AUDIT or ALARM event happened or should
> it fail the operation or something else?
> 
> - 6.4: What does "much is made of" mean?

Fixed up

> 
> - 6.4: Why is there no reference for the withdrawn POSIX draft?
> I think there ought be a reference there.

Yes.

> 
> - 6.4.3: What does "implementors should standardize on..." mean?

Tried to fix this one up.

> 
> - 7.4: Could I use an NFS4ERR_MOVED error to trick someone into
> writing a file to my dodfy server? Put another way, do you need
> the same level of security for handling this error as for the
> server authentication for a write operation and is that security
> mechanism supposed to be the same for all server
> instances/replicas? Is that noted somewhere if there's a
> vulnerability? I guess referrals could pose a similar threat.
> (This isn't a discuss because I think you said earlier that the
> same security has to be used but I wanted to check. I've also
> probably garbled the terminology here, sorry;-)

The same security is used.


> 
> - 7.9: Is there a happy-eyeballs concept for how to handle the
> DNS name here? Should you refer to RFRC 6555 somewhere?

Very happy-eyeballs, very generic use of DNS here.

> 
> - 9.1.3.4: Am I right in thinking that guessing stateid field
> values might allow me to misbehave? Its hard to know given how
> complex this section is, but I have a suspicion that it might be
> the case;-)
> 

We close down on this in 5661, which ties the stateid more to the
client ID.

> - section 17: I'm not clear how TLS (5246) is relevant here.
> 

More chances for WG participation.

> - 17: "should definitely use" isn't 2119 language - did you mean
> "SHOULD use"?
> 
> 

Yes