Re: Possible message multiplexing problem

[Michael B Allen <miallen@ioplex.com>]

On Mon, 23 Jun 2008 10:32:20 -0700
"Henry B. Hotz" <hotz@jpl.nasa.gov> wrote:

> 
> On Jun 23, 2008, at 9:42 AM, Michael B Allen wrote:
> 
> > On Mon, 23 Jun 2008 08:49:43 -0700
> > "Henry B. Hotz" <hotz@jpl.nasa.gov> wrote:
> >
> >>
> >> On Jun 22, 2008, at 3:06 PM, Michael B Allen wrote:
> >>
> >>> Hi,
> >>>
> >>> How does Heimdal match up responses with requests?
> >>>
> >>> Doesn't there have to be some kind of multiplex ID?
> >>>
> >>> I added a DNS cache and now my multi-process tourture-test is giving
> >>> me
> >>> a very occasional errors from gss_acquire_cred:
> >>>
> >>> GSS_S_FAILURE: Additional pre-authentication required
> >>>
> >>> Looking at a capture around the point of failure I see the  
> >>> following:
> >>>
> >>> ...
> >>> TGS-REQ
> >>> TGS-REP
> >>> AS-REQ (nonce: 2261734593)
> >>> AS-REQ (nonce: 2261734593)
> >>> KRB-ERROR: KRB5KDC_ERR_PREAUTH_REQUIRED
> >>> AS-REQ (nonce: 2261734593 + preauth)
> >>> KRB-ERROR: KRB5KDC_ERR_PREAUTH_REQUIRED
> >>> AS-REP
> >>> AS-REQ (nonce: 2260112736)
> >>> KRB-ERROR: KRB5KDC_ERR_PREAUTH_REQUIRED
> >>> ...
> >>>
> >>> Note there are multiple processes issuing requests from the same
> >>> source
> >>> port [1].
> >>>
> >>> Natrually MS returns KRB5KDC_ERR_PREAUTH_REQUIRED initially because
> >>> no preauth was supplied. That is normal. But it seems without the  
> >>> DNS
> >>> lookups things happen fast enough that two AS-REQs make it out  
> >>> within
> >>> 1/10th of a millisecond and AFAICT they are identical including the
> >>> nonce.
> >>>
> >>> So I have to wonder if the client is interpreting the second
> >>> KRB5KDC_ERR_PREAUTH_REQUIRED as the response to the retried AS-REQ  
> >>> of
> >>> the first process when in reality it was actually the response to  
> >>> the
> >>> AS-REQ of the second process.
> >>>
> >>> Can anyone concur or refute what is happening here?
> >>>
> >>> Mike
> >>>
> >>> [1] I suppose if the Kerberos library was not initialized until  
> >>> after
> >>> workers were forked the source port would be different.
> >>
> >> I'm not clear that it's possible to do the matchup like I think you
> >> want.  I thought the multi-thread model was that every thread that
> >> wanted to do Kerberos needed its own context.
> >
> > I do. I only create krb5_contexts transiently. And I'm using a
> > multi-process model.
> >
> > I trigger some libkrb5 actions in my Apache module initialization  
> > routine
> > and then Apache fork()s workers. Perhaps the workers are inheriting  
> > the
> > socket?
> 
> I think you know more than I do, but it sounds plausible.
> 
> Along the lines of what I first said:  I'm not clear that it's  
> possible to match up requests/responses when they share the same  
> client source port.  I don't know how the OS could determine which  
> thread/process to deliver a response to, and I don't think there is  
> anything in the Kerberos protocol messages intended to help with that.

Well since the name of my company is "IOPLEX" I have to declare the lack
of a multiplex id to be a flaw in the protocol. Maybe Kerberos 6 will
have one.

:-)

Mike

-- 
Michael B Allen
PHP Active Directory SPNEGO SSO
http://www.ioplex.com/