GSSAPI Murder authentication and "The context has expired" on long proxyd sessions

[Paul M Fleming]

I had the same problems. if you google for this you'll find a discussion 
regarding how SASL context expires should be handled. Heimdal allows 
expired contexts to be used after expiration. MIT does not.

1) indefinitely long means the default lifetime of your KDC or the 
individual keys involved. The default also depends on your version of 
MIT kerberos. Older versions by default request 10 hour tickets 
regardless of the max lifetime set in the KDC config files or the 
principals themselves.

2&3) My opinion is this behavior is broken in SASL unfortunately I'm not 
sure if it can be "fixed" without major changes to the SASL library. I 
know the openldap list discussed work arounds to deal with an expired 
context. Lowering the client timeout levels in imap can also help but 
you still get deadlocks between front and back ends which users notice a 
a client connection lock up. I did not attempt to change the code for 
SASL or IMAP, but handling a "context expired" event as a fatal error 
makes sense when running MIT kerberos. My guess is CMU doesn't have this 
issue because they use Heimdal.

My solution was to change the keys involved in murder to have a 25hour 
max life and change the KDC to allow 25h tickets. Then instead of a 
period event in cyrus.conf use an at event to renew the ticket at 2:00AM 
when users are less likely to notice. The Cyrus timeouts kick in before 
start of business and most clients (Netscape, Thunderbird,etc) reconnect 
  automatically and the user doesn't notice a thing, but you still have 
to deal with the log messages. This solution solved the deadlock issues 
for my clients.



On 9/11/2007 1:29 PM, Nik Conwell wrote:

> My frontends authenticate to the backends using GSSAPI.  Every 5  
> hours the frontends do a kinit to get a TGT to talk to the backend  
> and all is good.
> 
> However, if the frontend imap (proxyd) is proxying a session for more  
> than 10 hours I get:
> 
>     imaps[3207]: GSSAPI Error: The context has expired (No error)
> 
> This seems to happen in cmd_idle() (probably spends most of its time  
> there).  The frontend is in cmd_idle() having just received something  
> from the user client to terminate the IDLE.  The frontend writes DONE 
> \r\n to the backend but the write gets the context has expired error  
> but it isn't checking for errors returns on the prot_printf().  The  
> frontend then does a pipe_until_tag() waiting for the backend.   
> Meanwhile the backend has seen nothing and so is still waiting for  
> the frontend to terminate the idle.  Hung.
> 
> So, my questions are:
> 
> 1) Should somebody (SASL?) be requesting an indefinitely long  
> context?  gss_init_sec_context has an arg of the duration of the  
> context.  My linux build (Thanks Simon) has 0 for the time_req which  
> is evidently defaulting to 10 hours.  It could take GSS_C_INDEFINITE  
> but it's not apparent that this wouldn't just end up being the life  
> of the ticket (10 hours, 21 hours?).  I'm game to try this if it's  
> not stupid.
> 
> 2) Should somebody (SASL?  frontend proxy?) be creating new contexts  
> automatically when the old ones expire?
> 
> 3) Should cmd_idle() be just handling the error on the write to the  
> backend and passing that back up to the client who will reconnect again?
> 
> 
> BTW - my imapd is CVS:1.509.  I browsed the changelog for newer stuff  
> but didn't see anything relevant.
> 
> Thanks for any info.
> -nik
> 
> Nik Conwell
> Information Technology
> Boston University
> 
> ----
> Cyrus Home Page: http://cyrusimap.web.cmu.edu/
> Cyrus Wiki/FAQ: http://cyrusimap.web.cmu.edu/twiki
> List Archives/Info: http://asg.web.cmu.edu/cyrus/mailing-list.html