[jboss-jira] [JBoss JIRA] (SECURITY-921) SPNEGO authentication fails on Windows-KDC

[David Hanisch (JIRA)]

    [ https://issues.jboss.org/browse/SECURITY-921?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13179265#comment-13179265 ] 

David Hanisch commented on SECURITY-921:
----------------------------------------

I observed the same issue. The first mech in mechList is not the only accepted "Kerberos V5". I agree the proposed patch is not correct since the proviced mechToken is related to the first mech in list (defined this way by RFC).

There should be a new challenge to the browser with "Kerbors V5" as mech. I had a detailed look on it and found there is not. The next challenge is again a "Negotiate" without any token.

Seems to me the reason is here in NegotiationMechanism.java (line 122):

                    } finally {
                            negContext.clear();
                    }

This clears the perfectly prepared negTokenTarg from SPNEGOLoginModule.java.
When I change this to 

                    } finally {
                       {color:#f79232} if (!negContext.isContinuationRequired()) {{color}
                            negContext.clear();
                       {color:#f79232} }{color}
                    }

then the the 401 contains this token and there is another GET from the browser mit mech "Kerberos V5" and the authentication succeeds.


One more thing:
I would like to comment on something in SPNEGOLoginModule.java what I think is not quite correct:

           if( ({color:#f79232}(NegTokenTarg){color}negotiationContext.getResponseMessage()).getNegResult() != NegTokenTarg.REJECTED ) { 

The response message is not necessarily a NegTokenTarg, may also be a Kerberos message. 
I changed the if-then-elst to just:

      return super.loginOk;

and added setContinuationRequired() in AcceptSecContext.run() where needed:

                  negotiationContext.setResponseMessage(negTokenTarg);
                  {color:#f79232}negotiationContext.setContinuationRequired(kerberosSupported);{color}
                  return Boolean.FALSE;
...
            if (gssContext.isEstablished() == false)
            {
               {color:#f79232}negotiationContext.setContinuationRequired(true);{color}
               return Boolean.FALSE;
...
         catch (Exception e)
         {
            {color:#f79232}negotiationContext.setContinuationRequired(false);{color}
            return e;



> SPNEGO authentication fails on Windows-KDC
> ------------------------------------------
>
>                 Key: SECURITY-921
>                 URL: https://issues.jboss.org/browse/SECURITY-921
>             Project: PicketBox 
>          Issue Type: Bug
>          Components: Negotiation
>    Affects Versions: Negotiation_3_0_0_CR1
>         Environment: * 
>            Reporter: Harald Krause
>            Assignee: Darran Lofthouse
>              Labels: web_security
>
> Inside the "SPNEGOLoginModule" (3.0.0.CR2-SNAPSHOT) the run()-Method of inner class "AcceptSecContext" checks for existence of Kerberos-oid within the SPNEGO-Token. But it checks solely the first element of the mechanism-list:
> {code:java}
> 	if (mechList.get(0).equals(kerberos))
> 	{
> 	 gssToken = negTokenInit.getMechToken();
> 	}
> 	else
> 	{
> 	 boolean kerberosSupported = false;
> 	 ...
> {code}
> But SPNEGO-Token from Windows-KDC (2008 R2) supports four types of authentication (oids):
> * oid: 1.2.840.48018.1.2.2 (Windows Kerberos V5)
> * oid: 1.2.840.113554.1.2.2 (Kerberos V5 - we are looking for)
> * oid: 1.3.6.1.4.1.311.2.2.30 NegoEx
> * oid: 1.3.6.1.4.1.311.2.2.10 NTLM
> So Kerberos-check within run()-method should iterate the mechList until it founds Kerberos-V5-oid:
> {code:java}
>                for (Oid oid : mechList)
>                 {
>              	   if (oid.equals(kerberos))
>                    {
>             		   gssToken = negTokenInit.getMechToken();
>                            break;
>             	   }
>                }
> {code}



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)