Re: Possible message multiplexing problem

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

On Tue, 24 Jun 2008 14:28:05 -0400
Jeffrey Hutzelman <jhutz@cmu.edu> wrote:

> --On Monday, June 23, 2008 02:19:53 PM -0400 Michael B Allen 
> <miallen@ioplex.com> wrote:
> 
> > 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.
> 
> There is a multiplex ID; it is the IP address and port number of the socket 
> in use.  Multiple processes should not send requests from the same port, 
> because then the replies will go to the same port, and the OS will not know 
> which process should get which packet.  This is a fundamental design 
> property of UDP about which the Kerberos protocol can do nothing; separate 
> proceses need to use separate ports.

Protocols should not make assumptions about the process model.

I actually don't think a multiplex ID would (properly) fix this particular
issue (not sure exactly what the problem is yet) but it does allow you
to issue multiple async requests over the same transport UDP or otherwise.

A mutltiplex ID is very easy to generate and doesn't take up much space
so IMO every packet should have one even if the protocol authors don't
feel they need one.

Mike

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