Subject: RE: LOOKUPP and NFS4ERR_WRONGSEC

From: [email-masked]
Date: Fri, 7 Feb 2003 18:54:11 -0500

> >
> >
> >I think SECINFO as it stands now requires the parent export 
> and the child
> >export to share at least one common flavor. Otherwise, even 
> going downward
> >
> 
> That's going to really disappoint customers. But of course, I don't 
> agree with that
> interpretation.
> 
> >
> >using LOOKUP would not be possible. For example, suppose the 
> parent export
> >supports auth_unix and child supports krb5,
> >
> >PUTFH fh; LOOKUP "child_export" --> [auth_unix]
> >					  <-- NFS4ERR_WRONGSEC 
> (from LOOKUP)
> >PUTFH fh; SECINFO "child_export" --> [krb5i as required by SECINFO]
> >
> 
> The client can use whatever flavor it wants in SECINFO
> 

Isn't it true that the SECINFO call must use at least integrity
to prevent active attacks to lower security requirements?

> >
> >					  <-- "krb5"
> >PUTFH fh; LOOKUP "child_export" --> [krb5]
> >	   <-- NFS4ERR_WRONGSEC (from PUTFH since the parent does not
> >support krb5)
> >
> No, the server has to honor the request. The use of a putfh with wrong
> security doesn't require enforcement, since putfh doesn't involve any 
> access.
> 

But I remembered the spec indicated (in SECINFO impl notes) that PUTFH,
among other ops, was a checkpoint. Maybe it meant differently?

> The rule is ifSECINFO for { fh, name} returns flavor X, then
> a LOOKUP { fh, name} using flavor X MUST be accepted by ther server.
> 
>     -mre
> 
> 

Peng

---

From: Mike Eisler <[email-masked]>
Date: Fri, 07 Feb 2003 16:39:15 -0800

>to prevent active attacks to lower security requirements?

Yes, but the attack is against the client, so the server shouldn't be 
enforcing
it. Also, if the server supports krb5i, but the sys admin
hasn't configured Kerberos V5, what are we do? If the
sys admin only wants to use AUTH_SYS, an active attack to
lower security isn't of much use; it doesn't get much lower
than AUTH_SYS.

>among other ops, was a checkpoint. Maybe it meant differently?

I'll agree that the spec has a bit of self inconsistency since it
says at one place PUTFH can return WRONGSEC, and at another
that a fix a WRONGSEC error from LOOKUP, reissue the
PUTFH / LOOKUP with a different security flavor.
On the other hand, returning WRONGSEC to a PUTFH
is an implementation choice, just as allow
differing security flavors at each file object is an implementation
choice.

If implementors want to let a customer specify different and
disjoint sets of security flavors on different objects, then
the PUTFH can never return WRONGSEC. Conversely,
If PUTFH returns WRONGSEC, then it implies that the sets of security 
flavors on
each object are never disjoint. The third implementation choice is
to let the customer put his server into a useless state.

    -mre

---

From: "Sergey Klyushin" <[email-masked]>
Date: Sat, 8 Feb 2003 01:03:33 -0500

> -----Original Message-----
> From: [email-masked] [mailto:owner-nfsv4-
> [email-masked]] On Behalf Of Mike Eisler
> Sent: Friday, February 07, 2003 7:39 PM
> To: [email-masked]
> Cc: [email-masked]; [email-masked]
> Subject: Re: LOOKUPP and NFS4ERR_WRONGSEC
> 
> >
> >
> >>>

Paragraph 16 says "recommended", but not "MUST"

> says at one place PUTFH can return WRONGSEC, and at another

Don't we need to fix this inconsistency? The way I read protocol is 
"PUTFH MUST return WRONGSEC". What about interoperability?

> to let the customer put his server into a useless state.

I strongly believe that implementors don't have any choice here.
To allow different and disjoint security flavors at each file object 
is an ADMINISTRATOR (but not implementors) choice. 
So, PUTFH can never return WRONGSEC (see above).

Now, let's return to the original question about LOOKUPP.

> The rule is if SECINFO for { fh, name} returns flavor X, then
> a LOOKUP { fh, name} using flavor X MUST be accepted by the server.

I really like the rule, but there is no way to ask SECINFO of parent 
directory, because ".." doesn't have special meaning in NFSv4.
Now, please, be kind and don't kill me right away.
Because, SECINFO syntaxes is very close to LOOKUP, looks like we are
missing SECINFO_P (see the rule above). Otherwise there is no way
for administrator to specify different security flavors for parent and
child.
I understand that now is very bad time for new operation, so let's find 
another solution

Thanks,
Sergey

PS
I've just realized, that SETATTR doesn't return WRONGSEC. Why? 
Changing file's mode, ACL is the same danger as renaming file.

Why there is no AUTH_DH/AUTH_DES as available security flavor?

---

From: Mike Eisler <[email-masked]>
Date: Sat, 08 Feb 2003 01:29:31 -0800

>"PUTFH MUST return WRONGSEC". What about interoperability?

Well the notion of assigning different security triplets to different 
file objects
is an implementation decision. There is no MUST implement there. Thus 
why MUST it return
WRONGSEC?

PUTFH doesn't actaully compromise securitty so I don't see the issue.
Now what follows PUTFH can compromise security, and that's where
enforcement might be needed. E.g.

    COMPOUND { PUTFH  ; WRITE }

yes of course, the client better use the appropriate security.

As for interoperability, officially from an IETF perspective,
NFSv[23] don't exist. Practically they do. The measure of success
of NFSv4 will be when customers install our implementations
on their clients and servers, the clients and servers will
automatically negotiate to NFSv4, and won't notice
a thing.

If you interpret the specification your way and Peng's way, then
customers will notice a huge regression.

>>the PUTFH can never return WRONGSEC. Conversely,
To be clear, can never return WRONGSEC when it precedes a LOOKUP
that uses the fh that PUTFH injects.

>missing SECINFO_P (see the rule above). Otherwise there is no way

Yes. I've earlier proposed a SECINFO_CUR which would allow you to do the
same thing thing, plus let clients that do:

    PUTFH  fh; WRITE -->
    <--- WRONGSEC

figure out the right security withot knowing the directory the regular 
file (fh)
is in.

>for administrator to specify different security flavors for parent and

As I wrote before, this oversight just means that:

    - LOOKUPP has to be honored if the securirty triplet of the RPC 
matches that of the
        child directory, AND
    - a READDIR using any security flavor would need to be permitted 
regardess what the security
        triplet bound to the directory is.  However, thinking that 
through, it would necessarily
        have to be honored. If the client gets WRONGSEC on a PUTFH that 
precedes a READDIR or
        any other operation, and if it doesn't know the parent dir, and 
the name of the target fh, it
        could always try each security flavor it supports. The client 
should have an idea of
        what flavors the server might want ... just keep a record of 
each unique triplet used from
        the time the client mounted the server's directory.

>I understand that now is very bad time for new operation, so let's find 
So there are two classes of solutions. Implementation strategies versus 
protocol changes
that don't require another spin of the .x file (I think we have 
consensus that changing the .x
file, except to fix my utf8 screw up, are off the table).
Let's get consensus that we should solve it via an implementation 
strategy or via a (non .x file changing)
protocol modification.

>Changing file's mode, ACL is the same danger as renaming file.

For the same reason WRITE doesn't. And that reason is that consensus of 
the WG
was that they wanted WRONGSEC to be returned by just the operations that 
injected
new filehandles into the operation stream.

>Why there is no AUTH_DH/AUTH_DES as available security flavor?

I don't think the specification prohibits AUTH_DH, but it certainly
doesn't recommend it or mandate it. The reason why AUTH_DES is not RECOMMEND
is discussed in RFC2695, section 2. The details are in paper cited in 
RFC2695
by La Macchia and Odlyzko. In summary, the private key can be easily
derived via bruteforce from the public key, due to the 192 bit key length.

---

From: "Sergey Klyushin" <[email-masked]>
Date: Mon, 10 Feb 2003 10:47:19 -0500

> Sent: Saturday, February 08, 2003 4:30 AM
> To: Sergey Klyushin
> Cc: [email-masked]

Do you mean PUTFH precedes a LOOKUP or LOOKUPP?

> strategy or via a (non .x file changing)

Is it possible to include in implementation section of PUTFH operation your
comments?
Personally, I like the idea that client has to 
> keep a record of each unique triplet used from the time the client mounted

> the server's directory
In this case the only exception for NOT returning WRONGSEC from PUTFH will 
be PUTFH+LOOKUPP. The rest will stay the same as specified now.

Thanks,
Sergey

---

From: Mike Eisler <[email-masked]>
Date: Mon, 10 Feb 2003 08:22:11 -0800

>Is it possible to include in implementation section of PUTFH operation your
First I don't know that there is rough consensus in agreement with me.
Second, any substantial changes might result in further delay of
the document's issuance as an RFC. We are now on the verge of seeing a
second NFSv4.0 ship without an RFC, and I'm getting very uneasy.

    -mre