Subject: RE: todo list for RFC3010: SECINFO discussion

From: "Corbett, Peter" <[email-masked]>
Date: Thu, 24 May 2001 07:47:49 -0700

Section 3.3 of the spec states:

3.3.  Security Negotiation

   ...

   The security negotiation between client and server must be done with
   a secure channel to eliminate the possibility of a third party
   intercepting the negotiation sequence and forcing the client and
   server to choose a lower level of security than required or desired.

Later, section 14.2.31, describing the SECINFO operation says:

It is recommended that the client issue the SECINFO call protected
     by a security triple that uses either rpc_gss_svc_integrity or
     rpc_gss_svc_privacy service. The use of rpc_gss_svc_none would
     allow an attacker in the middle to modify the SECINFO results such
     that the client might select a weaker algorithm in the set allowed
     by server, making the client and/or server vulnerable to further
     attacks.

I believe that the description in 14.2.31 is correct.  There has been some confusion caused by the use of the word "must" (lower case) in Section 3.3.  I believe that the intent of the statement was to indicate that, in order to be certain that SECINFO results are not being spoofed, a secure channel must be used between client and server.  The implication is that it is best to perform SECINFO with the highest allowable security mechanism in use.  While this is good practice, it is not required of the client.

The question that was debated at connectathon is what mechanisms are allowed for SECINFO.  In particular, are higher level security mechanisms allowed for SECINFO operations, even when they are not allowed for other operations on the current file handle?

Here is some background on implementation that will clarify the issue.

SECINFO takes the current file handle as an implicit argument.  It also takes a component.  The response contains a list of security flavors allowed for the component.  The possible security attack is that this list can be shortened to include only the security flavors that the attacker knows how to crack.  There is no possible attack that would permit a low level (weak)security flavor (eg. AUTH_SYS) that is not already allowed for that export point.  So, if you only allow kerberos with privacy on an export point, there is no need to be concerned with middleman attacks on the SECINFO operations on that export point.

Let's use a secinfo call to get the security mechanisms allowed for directory B contained in directory A.

The question is: what security mechanisms should be allowed for the SECINFO call?  Remember that while the server is required to support many security mechanisms, the mechanisms allowed for any particular export point are determined by the administrator.  My reading of the spec was that the client already has access to the cfh for directory A, and therefore either stumbled onto an allowed security mechanism, or did a prior SECINFO call to determine what mechanisms are allowed for the export point containing A, and chose one of those mechanisms.  Given adequate permission, the client can do a readdir of A.  They should have search access to be able to do SECINFO on a component B contained in that directory.

The security mechanisms allowed for B are completely independent of those allowed for A, and can be higher, lower, or disjoint from them.  Now, it would be wise for the client to use the most secure possible mechanism allowed for A.  Clearly, for most operations on A, only those security mechanisms allowed for A should be accepted by the server.  For example, if the export says Kerberos Authentication is accepted, but not integrity or privacy, then that restriction must be respected by the client and enforced by the server.

I don't see any need to make an exception for SECINFO.  However, there is another opinion on the subject, shared by many implementors, that says that any high level security mechanism should be allowed, for the SECINFO call only.

I can see four possible behaviours.

1.	Only the specified mechanisms for the cfh are allowed for SECINFO, as they are for any other operation.  The client is recommended to use the most secure mechanism allowed.

2.	Any security mechanism is allowed for SECINFO, regardless of what the export information for the region containing cfh specifies.

3.	Any security mechanism equal to or higher than the lowest allowed mechanism is accepted.  For example, if AUTH_SYS is allowed for any operation on A, then any of kerberos, lipkey or spkm3 authentication, integrity or privacy is would be accepted for SECINFO calls on A, whether or not they are listed as allowed for A.  Furthermore, if kerberos integrity and lipkey privacy are the only accepted mechanisms listed for A, then any of kerberos, spkm3 or lipkey integrity or privacy is accepted for SECINFO operations on A.

4.	Any security mechanism equal to or higher than the lowest mechanism accepted for a particular flavor is accepted for SECINFO.  For example, if kerberos authentication and lipkey integrity are accepted for A, and AUTH_NONE and AUTH_SYS are not accepted, then for SECINFO operations on A, kerberos authentication, privacy and integrity and lipkey integrity and privacy are accepted, but neither any spkm3 mechanism nor lipkey authentication is accepted.

In my opinion, there is very little lost by enforcing behavior 1.  The security hole we are trying to close is a small one, and it is really an administrator's decision how well to protect secinfo operations.  As a practical matter, if a site chooses to enforce kerberos authentication on most filesystems, and kerberos privacy on the rest, then there is nothing an attacker can do to avoid the use of privacy on the critical filesystems that are protected with privacy.  The filesystem can never be accessed with a mechanism lower than the minimum specifed by the administrator.  And if there is some concern about an attacker forcing the use of a compromised mechanism, the possibility that the client could have chosen to use that mechanism in any case has already compromised that data.  To really close this security hole, the clients must be coded to always use the highest level of security allowed for any filesystem, and must not be able to be manipulated through any other means !
to use a different mechanism.  For example, it makes little sense to export a file system with both privacy and authentication flavors allowed for all clients, as any guarantees of privacy of data are lost.  It would not make sense for the server to discriminate by user what mechanism to use.  It does make sense to discriminate by source address or domain what mechanism to use, if the server is capable of that level of discrimination, and if the attacker is not able to spoof the addresses (which are not protected by the security mechanism in use).  However, the spec does not state that secinfo could return different results to different clients.  My reading of the spec is that secinfo returns a list of mechanisms that correspond to a cfh/component pair, without regard to what client is making the request.  The implication is that there is no way to discriminate among clients to force some clients to use different mechanisms from others.

A mixed mechanism environment makes more sense in the case of a mix of intranet and internet or extranet users.  For example, a user on the intranet may use kerberos authentication, but users on the internet may only use lipkey privacy.  Again, it would not be possible for the external client to get a kerberos ticket and force the use of authentication instead of privacy, so there is no possible compromise.

And if the administrator is concerned about SECINFO access to a directory, all he/she has to do is to limit the mechanisms allowed for the directory.  Ie. put A in a separate export, and limit its access to privacy.  This is quite feasible given that export points are usually at a few discreet, high levels in the file system name space.

Behavior 1 is simpler to implement and to describe in the spec, and ultimately, it is simpler to document for administrators.

A couple of other issues:

I think it can be inferred from the spec, but it is not stated anywhere, that the secinfo call should be performed using the user's identity, and not using root or any other identity associated with the client machine.  So, if SECINFO is performed by an upcall to a user space daemon, the identity used for the operation must be the user's.

There is nothing stated in the spec about this, but as a practical matter, it makes sense to allow any security mechanism, including AUTH_SYS (if supported:)) for the root of the psuedo file system.

SECINFO should only be allowed if the user has search access to the directory.  NFS4ERR_ACCES should be returned if not.  This removes the issue of a user getting information they should not get from the error code response to SECINFO in a similar way to what they could get from LOOKUP if LOOKUP did not enforce search access.  I.e., it should not be possible to determine the existence of a file based on NFS4ERR_WRONGSEC vs. NFS4ERR_NOENT error responses from SECINFO.