Understanding Kerberized NFSv4 Authorization

Articles such as this one seem to point out that Kerberizing NFS(v4) mounts not only prevents machines without a Kerberos service ticket from mounting the shared directory but also uses the user's Kerberos ticket to authorize user actions on the shared files.

I quote the relevant part:

Before NFSv4, security on NFS was pretty much non-existant. You could prevent unauthorized machines from connecting to NFS exports, but had to rely on user ID mappings being the same between systems to use the server's permissions to adequately protect files. Using Kerberos in this manner makes NFS much more secure than it used to be.

What I'm having trouble understanding is the following scenario, which seems to contradict this statement:

# mount /share #succeeds because I have a service ticket in my keytab
$ klist
klist: No credentials cache found (ticket cache FILE:....)
$ ls /share
ls: cannot access /share: Permission Denied
$ kinit
Password for joe@MYREALM:
$ ls /share
contents of share

So far so good, but when I do this:

$ kdestroy
$ ls /share
contents of share

What's happening here? I was able to access the NFS mountpoint even though I had no Kerberos credentials. Is this behavior expected or is my mount misconfigured?

Info

1. Running MIT Kerberos V on Debian Wheezy 7.0

2. My mount options:

   $ grep nfs4 /etc/fstab
   server.myrealm:/nfs_export /share nfs4 sec=krb5,user 0 0
   

3. My /etc/exports on the server:

   /nfs_export *(rw,sync,no_subtree_check,sec=krb5)
   

The nfs(5) page says that the GSS API supports two additional flavors of Kerberos security: krb5i to check data integrity and detect any tampering and krb5p to further ensure that all RPC calls are encrypted for security. I don't think enabling either of these will solve my problem.

Edit

As per dawud's suggestion I tried both krb5i and krb5p and the behavior persists.

My problem, again, is how to make sure the /share is inaccessible to anyone who currently holds no Kerberos ticket? Furthermore, can I use the user's Kerberos ticket for authorization purposes (i.e., control who can access what) as the article I referenced seems to imply?