SPNEGO can be used for multiple auth types (hence the nego in spnego for
'negotiation mechanism'), currently supported are NTLM and Kerberos by IE. The
spnego ms implementation wraps the blob data from calls to SSPI rather than a
kerberos ticket directly Im assuming because multiple types are supported.
As for the ticket being granted..that part I 100% agree with but what about
during the negotiate and auth phase?
Reason being on:
http://www.ietf.org/internet-drafts/draft-jaganathan-kerberos-http-01.txt
it states:
"If an HTTP proxy is used between the client and server, it must take care to
not share authenticated connections between different authenticated clients to
the same server. "
NTLMSSP was an authenticated connection rather than a request, and you were
required to keep the connection open for the second and third auth phases or
the whole process needed to start again, since you were auth. a connection, not
the request. This stmt about making sure proxies don't share the connection
makes it sound like the same thing is happening. I emailed J. Brezak from
Microsoft (one of the writers of the draft) but received no response. Since
this is going to be used with MS (and others) browsers, it needs to be correct
: ) I can always sort through the code for the apache mod for spnego, but was
hoping I could get a direct answer here.
Thanks,
Adam Tuliper
www.secure-coding.com
-----Original Message-----
From: Saqib Ali
Sent: Fri, 19 May 2006 14:35:14
To: Adam Tuliper
Cc: webappsec@securityfocus.com
Subject: Re: http/spnego connections
Hi Adam,
As far as I understand SPNEGO is a kerberos implementation for web
browsers. So it works the same way as a kerberos client would, i.e.
once you get the ticket it is valid for certain amount of time. You
don't need a persistent connection.
The ticket that the client gets from the Ticket Granting Server has
the following syntax:
Ticket (client, service) : service, [client, client address, validity,
Key(client, service)]Key(client, TGS)
Where "service" is the the resource that the client is trying to
access. In this case, the Web application.
"Validity" tells how long the ticket should be valid for. You can
force expire tickets on kerborized applications/client.
On Active Directory you can the set the ticket lifetime in the
Kerberos Policy setting using Group Policy Managment Console.
--
Saqib Ali, CISSP, ISSAP
Support http://www.capital-punishment.net
-----------
"I fear, if I rebel against my Lord, the retribution of an Awful Day
(The Day of Resurrection)" Al-Quran 6:15
-----------
-------------------------------------------------
Sent using http://www.DWmail.net, a free service
Check your email [any email, anytime, anywhere]
-------------------------------------------------
Disclaimer: DWmail.net is not responsible for the content sent via it's
services. Additional header information is included regarding the source of an
email. If you believe an email is junk you should look for the 'Originating
IP' message header
-------------------------------------------------------------------------
Sponsored by: Watchfire
Watchfire named worldwide market share leader in web application security
assessment by leading market research firm. Watchfire's AppScan is the
industry's first and leading web application security testing suite, and
the only solution to provide comprehensive remediation tasks at every
level of the application. See for yourself.
Download a Free Trial of AppScan 6.0 today!
https://www.watchfire.com/securearea/appscansix.aspx?id=701300000007t9c
--------------------------------------------------------------------------
