From: Mike Eisler (mre@eng.sun.com)
Date: 07/14/98-03:20:01 PM Z
Date: Tue, 14 Jul 1998 13:20:01 -0700 (PDT) From: Mike Eisler <mre@eng.sun.com> Subject: Re: Questions on strawman draft Message-ID: <Roam.SIMC.2.0.6.900447601.11695.mre@eng.sun.com> > > > E. Error numbers > > > > > > NFS4ERR_WRONGSEC > > > What does this error provide that returning an RPC auth error > > > with RJ_why == AUTH_TOOWEAK does not provide? > > > > Hmmmm.. Yes, there does seem to be some overlap in the definitions. > The NFS4ERR_WRONGSEC deals with security negotiation and therefore the > negotiation should be done securely. The RPC error of AUTH_TOOWEAK says the > RPC authentication or security flavor is not appropriate at all for the > server. The WRONGSEC error is one step up and states that the client is > using a valid security flavor but the flavor is not appropriate for the > specific file handle in question. Right. An attacker in the middle could easily introduce an RPC auth error (since RPC auth errors are not protected with RPCSEC_GSS), but it would be much harder to introduce a bogus NFS4ERR_WRONGSEC, because it is an error at the level of the NFS layer and so protected with RPCSEC_GSS (if the client's RPC used RPCSEC_GSS). btw, section 9.28 (SECINFO) should state that the client can use any of the security triples specified in section 2.2.1 (Security mechanism) in the SECINFO call even if the security triple does not match how the security used on the target file system. Otherwise, we have a chicken/egg problem. -mre
This archive was generated by hypermail 2.1.2 : 03/04/05-01:45:57 AM Z CST