Subject: [nfsv4] caching rpcsec_gss context handles

From: [email-masked]
Date: Wed, 7 Dec 2005 11:54:53 -0500 (EST)

Currently, my server chooses to time out cached rpcsec_gss context handles,
using a tunable timeout value, that currently defaults to 30minutes.

When I did this, I had a vague notion that keeping a context handle for
too long might present a security risk (increased chance of someone
cracking the key, or ???). I'm a bit of a security weenie. Does such a
risk actually exist?

The reason this question is interesting is that it was suggested to me that
a client might want to continue to use a context handle after the TGT used
to get the context has expired. (At first, allowing the context to continue
to work after the TGT expires seemed like "cheating", but I can see an
argument that a session_key/context is more secure than a TGT in a
credentials cache, so it can be safely used for a longer period.)

I was just wondering what others think and what other current servers do
w.r.t. caching context handles?

Thanks in adavnce for any comments, rick

_______________________________________________
nfsv4 mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/nfsv4

---

From: Nicolas Williams <[email-masked]>
Date: Wed, 7 Dec 2005 11:28:08 -0600

> credentials cache, so it can be safely used for a longer period.)

Wrong layer.  It's the GSS-API mechanism's job to tell you that a
security context has expired, either because it has lived too long
(e.g., past ticket expiration time), or because it has been used too
much and using it more would ease cryptanalysis.

IOW, don't worry about this -- let the GSS-API do this for you.

The server should use memory pressure, LRU/LFU and such heuristics to
decide if and when to delete security contexts.

Nico
--