Subject: Re: [nfsv4] caching rpcsec_gss context handles

From: [email-masked]
Date: Fri, 9 Dec 2005 12:55:13 -0500 (EST)

> 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.

Ok, I assume by the above that you mean I should use the "time_rec"
returned by gss_accept_sec_context()?

A quick test I did here shows that this is the time when the TGT for that user
expires for the 2 clients I have to test with.

This would not allow the context to be used beyond TGT expiry and I have
some indication that doing so would be desirable.

Any further opinions? rick

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

---

From: Mike Eisler <[email-masked]>
Date: Fri, 9 Dec 2005 10:27:54 -0800 (PST)

> > decide if and when to delete security contexts.

FWIW, some clients don't react well to contexts being
deleting well before their time. We've had problems with LRU,
memory pressure, etc. killing contexts.
> some indication that doing so would be desirable.

What gets returned by GSS in time rec is how long the
context is good for. Correct clients won't try to use an expired
context. It sounds like you are changing your GSS code to
allow expired contexts; my advice is to not do that.

Kerberos can be configured so that tickets can be renewed
past the original lifetime, but all this means
is that new RPCSEC_GSS context gets created. There's no
in-band context renewal of existing contexts.

---

From: Nicolas Williams <[email-masked]>
Date: Fri, 9 Dec 2005 13:39:54 -0600

> returned by gss_accept_sec_context()?

Nah, just wait until you get GSS_S_CONTEXT_EXPIRED from GSS_Wrap()/
GSS_Unwrap()/GSS_GetMIC()/GSS_VerifyMIC().

The expiration time from gss_accept_sec_context() is time based, not
usage based.

> some indication that doing so would be desirable.

Again, this is really up to the mechanism.  It might be that the
time_rec is advisory, but a GSS_S_CONTEXT_EXPIRED major status from the
per-message token functions is definitely mandatory.