[modauthkerb] Negotiate on Windows with cross-realm trust ADand MIT Kereros.

[Douglas E. Engert]

Achim Grolms wrote:
> On Friday 27 July 2007 18:11, Douglas E. Engert wrote:
>> I stil think you have a client problem, of the client not delegating.
>

http://www.ietf.org/rfc/rfc1964.txt old and

http://www.ietf.org/rfc/rfc4121.txt

define the Kerberos/GSSAPI packets. With Kerberos the delegated cred
is sent in the same GSSAPI token as the authentication request.
So there is one token from the client to the server, then if
there is mutual there is a token back. These tokens are carried
by the TLS protocol which may add extra round trips.

The point being, the delegated cred was not in the  GSSAPI token in
the trace you sent, which make this look like a client problem to me.

> A client not delegating because mutal-auth has not finished it's roundtrips?

No, the client actually sends the cred before the client knows if the mutual worked.
If the mutual fails, it means the server could not decrypt the session key,
and thus could not decrypt the delegated cred either.

> The mod_auth_kerb code tries to store the deleg_cred *without* checking
> if mutal-auth is in progress or is finished.

But there is no additional information from the client so the server
can process the delegate cred, and send the mutual response to the client
at the same time. If the client does not like the mutual response it, it
can close the connection.

> But if mutal-auth is in  progess 'deleg_cred' is invalid...

I still question if FireFox is doing the right thing.

(I don't have a server these days doing SPNEGO, so can't test this.)


> 
> Achim
> 
> 

-- 

  Douglas E. Engert  <DEEngert at anl.gov>
  Argonne National Laboratory
  9700 South Cass Avenue
  Argonne, Illinois  60439
  (630) 252-5444