Re: [nfsv4] review of draft-dnoveck-nfsv4-security-03

[David Noveck <[e-mail]>]

On Mon, Nov 29, 2021 at 11:35 AM Chuck Lever III <[e-mail]>
wrote:

> My immediate concerns are with the discussion of security flavors /
> connection types, so permit me to redact the other parts of this thread in
> the interest of clarity, and address your responses only in that area, with
> one quick detour into the ACL part of the thread.
>
>
> On Nov 26, 2021, at 10:43 AM, David Noveck <[e-mail]> wrote:
>
> On Wed, Nov 24, 2021 at 12:22 PM Chuck Lever III <[e-mail]>
> wrote:
>
>>
>> As above, it could be impossible to crisply describe ACL-to-mode
>> translation in the face of other, non-standard authorization mechanisms
>> that might restrict server security policy.
>>
>
> Could you give me an example of the difficulty you see? I see these issues
> as orthogonal.
>
>
> How do you propose to deal with a situation where a server uses multiple
> MAC labels (SMACK64, for example) or file capabilities ?
> https://linux.die.net/man/7/capabilities (and note that other OSes have
> their own flavors of capabilities).
>

Not all.  It is out of scope.


>
>
> There is a class of servers (eg OnTAP) that enable only remote access to
> files, and have only one physical file system implementation. The security
> document seems designed to address that case.
>

I don't think "designed" is the right word.  It is just that:

   - Discussion of local file access is out-of-scope in an NFSv4 spec.
   - Discussion of physical file systems is also out-of-scope.


> There is a class of servers (eg Linux, Solaris) that enable remote and
> local access to files, and have multiple independently-implemented file
> system types. Not all shares on such servers are guaranteed to implement
> the same set of access controls. Here, local users (or the server
> administrator) can set up additional access controls like capabilities,
> which are not visible to users on clients, and are not reflected in either
> the ACL or in the mode bits. Are you proposing that the nfsv4 WG mandate
> how these file systems update mode bits when those other access control
> mechanisms are put into place?
>

No I am not.   It is just that they affect modes and acls equally, and so
the mapping between these two is orthogonal.


> Some access control mechanisms, such as Linux IMA, are policy-based rather
> than controlled by settings on individual files. The policy is specified by
> the administrator in control of the file system where files are stored (ie,
> the server's file systems). IMO the text at least needs to recognize the
> presence of overriding security policy that is not modifiable from NFS
> clients.
>

It already does that in describing read-only fs's.  I'm open to suggestions
for expansion.

>
>
> I missed the introduction and definition of the terms "forward-slope" and
>> "reverse-slope".
>>
>
> It's in section 7.3.1.  The Associated Consensus Item is #21.
>
>
> What I meant was: perhaps these terms could be added to the document's
> forward glossary. I did browse the text looking for these, and still missed
> their definitions.
>

will try to do this in -04.

>
>
> As it is a substantial piece of work, perhaps it needs its own charter
>> mandate.
>>
>
> I don't think so.  As part of the rfc5661bis effort, it fits under
> maintenance, just as internaiona;ization is.
>
>
> I don't recall a discussion of rewriting the ACL sections from the ground
> up when the WG was considering the scope of the rfc5661bis effort. Also, as
> you have carefully identified areas where a consensus discussion is needed,
> let me tactfully point out that we are possibly veering outside the realm
> of simple maintenance. AFAIK there have been no errata filed against the
> ACL section of RFC 5661.
>
> Mainly I want to keep this effort contained and feasible, as I'm sure you
> do also. As I stated in the introduction to my review, I'm concerned that
> the scope of the rfc5661bis effort is continuing to broaden without any WG
> discussion regarding whether that's a desirable thing to do given currently
> available resources.
>
>
> *Section 13.1:*
>>
>> I don't understand the motivation for replacing the historical term "RPC
>> authentication flavor".
>>
>
> It is because most of the "RPC 'authentication' flavors" don't do
> authentication.
>
>
>> Also, the term "RPC flavor" is generic enough to unhelpfully obscure its
>> meaning and purpose.
>>
>
> :-(
>
> I don't currently have an alternative term,
>>
>
> I'll look for one and address in -04.
>
>
>
>> but subsequent discussion in this section is able to successfully
>> distinguish between identification and authentication and state plainly
>> which authentication flavors provide one, both, or neither.
>>
>
> Right but I'm afraid the repetition of  "authentication flavor"  would
> undercut that.   "RPC 'authentication' flavor" is kind of ugly.  Sigh!  I
> think I will introduce the term "RPC auth-flavor", explain why
> "authentication flavor" is inaccurate, and proceed from there.
>
> I don't see a problem with keeping the traditional terminology.
>>
>
> I still feel it would contribute to confusion.
>
>
> "RPC auth flavor" seems like a fine abbreviation with plenty of precedent.
>
>
> *Section 13.4:*
>>
>> I find the linking of "connection type" with "RPC flavor" to be deeply
>> problematic
>>
>
> I don't understand why.
>
> The sentence in question says;
>
>    Depending on the connection type used, RPC may provide additional
>    means of authentication.  In contrast with the case of RPC flavors,
>    any authentication happens once, at connection establishment, rather
>    than on each RPC request.  As a result, it is the client and server
>    peers, rather than individual users that are authenticated
>
> Could you explain what is problematic about that?
>
>
> We already have RPC auth flavors that provide mutual peer authentication.
>

I don't think the client peer is included :-(


>
> We already have a mechanism by which the NFS server can request particular
> security services such as mutual peer authentication.
>
> We already have a mechanism by which the RPC layer can tell an upper layer
> "I can't perform the requested security service".
>
> We already have channel binding, by which an upper layer can determine
> whether a security service is provided by an underlying transport layer.
>
> Therefore, there is no clear use case that requires more than extending
> AUTH_SYS to include:
>
> "AUTH_SYS with mutual peer authentication is OK"
> "AUTH_SYS with encryption is OK"
> "AUTH_SYS with both is OK"
>
> Negotiating these does not require the server to stipulate the use of a
> specific connection type.
>

True.


> The client and server's RPC layers can figure out which types to use. If
> the NFS layer needs to butt in, the channel binding API is available.
>

Right, but the spec needs to describe how that is to be used.

>
>
> and without precedent.
>>
>
>  Perhaps so but, given the innovation that you and trond have provided,
> there will be many occasions to say things that were not said before.  *stare
> decisus *does not apply here.
>
>
> "many occasions" -- OK, let's see some specific real world examples. I'm
> not seeing any possible case where we need more than what I outlined above
> (Rick's additional exception noted).
>
> I believe strongly that we should narrowly define new protocol based on
> real needs, not expectations about what might happen. Expectations are
> almost always short-sighted or incorrect.
>
> The framework provided by the current IANA registration of RPC auth
> flavors is entirely adequate to do what we need for NFSv4 SECINFO and NFSv3
> MNT. It is up to new proposals to affirmatively demonstrate that the
> current framework is not adequate.
>
>
> First, and I cannot stress this enough, TLS IS NOT A CONNECTION TYPE.
>>
>
> You have already made that point and I believe it is addressed in -03,
> although it is possible there were some editing slip-ups.
>
> If you know of any, please point that out.
>
>>
>
>> For example, QUIC, which *is* a connection type, uses TLS just like TCP
>> does, though with QUIC TLS happens to always be enabled.
>>
>
> that is true but, given that there is no RPC-over-QUIC spec (even an
> individuaI-D), there are limits in what I can say about that in an I-D that
> is intended to morph into a standards-track RFC.
>
>
> You're making my point for me. A missing spec should be enough to give you
> pause before defining something more complicated than we know how to use
> today.
>
> Incidentally we do have a nascent personal draft for RPC-with-QUIC, but it
> has not been officially submitted to the IETF. We are waiting to understand
> the use cases for QUIC (over and above what is provided by existing
> technologies), as requested during the most recent previous WG meeting.
>
> https://github.com/chucklever/i-d-rpc-over-quicv1
>
>
> We will be better served if the RPC layer simply tells the upper layer:
>> yes I can authenticate the peer (eg: GSS or transport layer security is in
>> use), or no I can't; yes I can provide confidentiality (eg: GSS, IPsec, or
>> TLS is in use), or no I can't.
>>
>
> We might be better off but that would have required an  RPC
> connection-flavor abstraction paralleling the RPC auth-flavor abstraction.
>  We don't have that and the benefits of doing so, while real, do not
> justify  the substantial work do so now.
>
> As far as confidentiality goes, there have to be three choices, rather
> than two:
>
>    1. Yes you get this automatically for the connection (RPC-with-TLS and
>    eventually QUIC)  --> use this if you can.
>    2. You can get this, if you ask for it on a per request basis. (GSS
>    when connection-based encryption is not available) --> Needed if 1. not
>    available
>    3. No you can't get this (e.g. AUTH_SYS in the clear) --> run away as
>    fast as you can
>
> A simpler set of flavors will give us this flexibility. I don't see
> anything here that can't be done via what I proposed above.
>
>
> This section needs analysis of specific use cases and explicit rationale
>> for why negotiating connection types is necessary.
>>
>
> I'll provide that in the predraft and -04.
>
>
>> Since this is a proposed new feature, that analysis and rationale is
>> paramount.
>>
>
> It is not a new feature.  It is the adaptation of an existing feature to
> be useful in the new environment in which the RPC auth-flavor is no longer
> the sole determinant of security services, but the role of the connection
> characteristics is of equal or greater importance.
>
>
> Your proposal changes the operation of SECINFO to include BREAK and other
> control flow operations IIUC. This is no longer a matter of adding a
> pseudoflavor or new protocol element. You are changing the behavior of the
> operation, perhaps in ways that are not backwards compatible. That is why I
> bring up RFC 8178.
>
> And I wonder how pleased NFSv3 implementers will be that they would need
> to handle XPT_BREAK in a moribund MNT implementation.
>
>
> Burying this proposal in a large document with a broad scope will prevent
>> adequate discussion IMO.
>>
>
> We are having a discussion of this now.  I hope it is productive.  If it
> is inadequate, I don't see how putting it in a separate document would
> remedy that.
>
> I prefer to see these three sections split into their own document that
>> can proceed to publication as soon as possible rather than being chained to
>> the completion of the other potentially lengthier tasks in nfsv4-security.
>>
>
> I presume that you are referring here to sections 13-15.   Regarding these;
>
>    - Sections 13 and 14, which deal respectively with authentication and
>    the security of data  in flight are an integral part of the security
>    provided by  NFSv4.  They have a  critical role in the new security
>    architecture intended to take proper advantage of the work you and trond
>    did in RPC-with-TLS.   I don't understand the motivation for putting these
>    three pages anywhere other than draft-dnoveck-nfsv4-security or its
>    successor documents.
>    - Section 15 is made necessary is made necessary by the changes in
>    sections 13 and 14 so might make sense to deal with all these together,
>    except for the following considerations:
>       - these sections are a total of eleven pages.
>       - While 13 and 14 are tightly bound to 15, they are also
>       tightly bound to the rest of the spec, making any proposed surgery
>       difficult.
>       -  With regard to the suggestion that this will somehow accelerate
>       adoption I am inclined to be skeptical.   this is not only because you seem
>       to to feel theses changes not worth doing but also because you find some
>       matters now in section 13 to be deeply problematic.
>
> I don't see what is wrong with keeping these eleven pages with the rest of
> the security document.
>
>
> Implementers want a TLS flavor negotiation capability in a standard
> yesterday, and they want it to include NFSv3 (MNT). The WG has the ability
> to meet that goal by writing a document that simply defines the new
> AUTH_SYS pseudoflavors, and get it published ASAP.
>
>
> *Section 15:*
>>
>> I strongly urge reconsideration of adding connection types to security
>> negotiation. NFS should state the security services that are required, and
>> let the local RPC implementation figure out the mechanisms.
>>
>
> It needs to be noted that SECINFO's job is to allow the NFS server to tell
> the client what services to request. It could have been designed around
> abstract services, but it was designed around auth-flavors, which made
> sense then.   The problem is that, given the more limited role of
> auth-flavors, some chane is needed.
>
>
> I don't agree: it gives us everything we need. IMO your proposal needs to
> adequately justify the need to go outside the boundaries of what we have
> today. The document needs to explain why we can't get to where we need to
> go with channel binding and a handful of AUTH_SYS pseudoflavors.
>
>
> Section 15.4 and 15.4.1 belong in section 15.5. And again, because this
>> subsection is specifying protocol elements, it does not belong in an
>> architectural document, but instead should be either a separate smaller
>> document that will be replaced eventually by rfc5661bis,
>>
>
> I don't see the point of a separate, temporary document.
>
>
> We need something that covers more than just NFSv4.x, and we need it
> quickly.
>
> It might be helpful to have a contrasting proposal on the table. I can
> assemble a small document that makes an IANA request for the new AUTH_SYS -
> related RPC auth flavors.
>

If you do that, I think I could remove (or cut it way back) in a
subsequent draft.


>
>
> --
> Chuck Lever
>
>
>
>