Subject: Re: draft-ietf-eisler-nfsv4-secinfo-00.txt

From: Mike Eisler <[email-masked]>
Date: Tue, 25 Feb 2003 15:31:19 -0800

Sergey Klyushin wrote:

> Mike,
>
> Thanks for great draft!
> Is possible to make it standard before NFSv4.0 approval -:)

There's a real chance that this could be sent to, and approved by IESG 
before
the RFC editor published the NFSv4.0-bis RFC. It depends
on how much we as wg want to do in minor version 1.

I suggest doing uncontentious, simple stuff in v4.1 so that as
implementors we get experience with dealing with multiple
minor versions.

>
> I've included some comments below, but before going there would not
> it be easily if NFS4ERR_WRONGSEC error returns secinfo4 also?

There are plusses and minusses to that. A plus is potentially
one less round trip. The minus is that unless the client issued the
operation with integrity on, the result won't have integrity, and
so the client will need to re-issue the result. The other minus is that 
every
operation that can return WRONGSEC would now have to be revised. By the
rules of minior versioning (which can certainly be altered by the wg),
we'd have issue a dozen or so new operations. It starts to
look ugly.

>>
>> Network Working Group M. Eisler
>> Internet-Draft Editor
>> Document: draft-eisler-nfsv4-secinfo-00.txt Network Appliance, Inc.
>> February 2003
>>
>
> Why this draft is within "Network Working Group", but not in
> "NFS version 4 Working Group"?

Two reasons. First, the guidelines for i-d authors says to use
Network Working group. Second, this is a personal i-d, as opposed
to a work item i-d authorized by the wg chairs.

>>
>>
>> mechanisms available, with an order corresponding to the
>> server's preferences, the most preferred being first in the
>> array. The client is free to pick whatever security mechanism it
>> both desires and supports, or to pick in the server's preference
>> order the first one it supports. The array entries are
>> represented by the secinfo4 structure. The field 'flavor' will
>> contain a value of AUTH_NONE, AUTH_SYS (as defined in
>> [RFC1831]), or RPCSEC_GSS (as defined in [RFC2203]).
>>
>
> Does it mean that 'flavor' is restricted to AUTH_NONE, AUTH_SYS and
> RPCSEC_GSS ONLY and AUTH_DH (AUTH_DES) can't be returned?

Good point. Any flavor can be returned; NFSv4 is architected to support
any flavor. I believeAUTH_DH and AUTH_KERB4
were mentioned at some point, but because they are not standards track,
they were probably removed. (At one point in the NFSv4 specification,
the per-flavor stuff was encoded into a byte array so that we wouldn't
have this problem. Oh well). How about text like this:

    The field 'flavor' will contain a value of AUTH_NONE,
    AUTH_SYS (as defined in [RFC1831]), or RPCSEC_GSS (as defined in
    [RFC2203]). The field flavor can also any other security flavor
    registered with IANA.

    For the flavors AUTH_NONE and AUTH_SYS, no additional security
    information is returned.  The same is true of many (if not most)
    other security flavors. For a return value of RPCSEC_GSS [...]

>>
>> o For PUTROOTFH and PUTPUBFH, the client will be unable to use
>> SECINFO or SECINFO_NO_NAME operations since te SECINFO
>
>
> te -> the

Thanks.

>
>
>> operations require a current filehandle and none exist for
>> PUTROOTFH and PUTPUBFH. Therefore, the client must iterate
>> through the security triples available at the client and
>> reattempt the PUTROOTFH or PUTPUBFH operation. In the
>> unfortunate event none of the MANDATORY security triples are
>> supported by the client and server, the client SHOULD try
>> using others that support integrity. Failing that, the client
>> can try using AUTH_NONE, but because such forms lack
>> integrity checks, this puts the client at risk. Nonetheless,
>> the server SHOULD allow the client to use whatever security
>> form the client requests and the server supports, since the
>> risks of doing so are on the client.
>>
>
> What you are saying is that Server SHOULD NOT return NFS4ERR_WRONGSEC 
> error
> from PUTROOTFH and PUTPUBFH even though Client uses AUTH_NONE and Server
> configured to export with Kerberos. Is it correct?

Well that's not what I was trying to say (which was text that came from 
NFSv4.0,
which I probably wrote). If the server exports its root with Kerberos, 
then it shouldn't
let the client access its root with AUTH_SYS, if that's what the server
policy is.

I suggest this text:

    For PUTROOTFH and PUTPUBFH, the client will be unable to
    use SECINFO or SECINFO_NO_NAME operations since the SECINFO
    operations require a current filehandle and none exist for
    PUTROOTFH and PUTPUBFH.  Therefore, the client must iterate
    through the security triples available at the client and
    reattempt the PUTROOTFH or PUTPUBFH operation. In the
    unfortunate event none of the MANDATORY security triples
    are supported by the client and server, the client SHOULD
    try using others that support integrity. Failing that, the
    client can try using other forms (e.g. AUTH_SYS and AUTH_NONE),
     but because such forms lack
    integrity checks, this puts the client at risk.

>
>
>> The READDIR operation will not directly return the
>> NFS4ERR_WRONGSEC error. However, if the READDIR request
>> included a request for attributes, it is possible that the
>> READDIR request's security triple does not match that of a
>> directory entry.
>
>
> Why "it is possible ..." only in the case when "READDIR request 
> included a
> request for attributes"? Do you mean by this that security violation 
> should
> be considered ONLY when Server returns file handle while returning 
> names and

Nothing new from NFSv4.0.

If the sec used in the readdir matches how the directory being resad is 
exported,
then it is ok to return all the entries. However, it is not ok to return 
an entry's attribute
if the security doesn't match what the server demands.

>
>
> and ANY other file attribute and violating security is OK?

No. I don't think that's what the spec says. Perhas this is clearer in
the READDIR description of the NFSv4.0 specification? If not,
if you can suggest some text that makes this clear enough that would
be great.

>
>
> >If this is the case and the client has
>
>> requested the rdattr_error attribute, the server will return the
>> NFS4ERR_WRONGSEC error in rdattr_error for the entry.
>>
>
> What if client did not request rdattr_error attribute and READDIR request
> included a request for attributes and/or file handle attribute?

This is discussed in the NFSv4.0 specification, under
the section on READDIR.

But the answer is, the server has no choice but return WRONGSEC for the 
entire
operation.

>>
>> 4. Clarification of Security Negotiation in NFSv4.1
>>
>> This section attempts to clarify NFSv4.1 security negotiation issues.
>>
>
> When you are talking about "PUTFH+..." in this section, does PUTFH 
> include
> PUTROOTFH and PUTPUBFH?

Good point. There's no reason why they shouldn't apply. I'll make that 
change.

Thanks for the comments.

    -mre