WebApp Sec mailing list archives
Re: http/spnego connections
From: "Adam Tuliper" <amt () gecko-software com>
Date: 19 May 2006 17:41:26 -0000
Looking at code from firefox for spnego, seems a connection does remain open for the auth portion, but this may simply be here for the ntlm requirement: // // Negotiate Auth creds should not be reused across multiple requests. // Only perform the negotiation when it is explicitly requested by the // server. Thus, do *NOT* use the "REUSABLE_CREDENTIALS" flag here. // // CONNECTION_BASED is specified instead of REQUEST_BASED since we need // to complete a sequence of transactions with the server over the same // connection. // *flags = CONNECTION_BASED | IDENTITY_IGNORED; return NS_OK; -----Original Message----- From: Adam Tuliper <amt () gecko-software com> Sent: Fri, 19 May 2006 17:09:04 To: webappsec () securityfocus com Subject: Re: http/spnego connections 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 ------------------------------------------------- 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 --------------------------------------------------------------------------
Current thread:
- Non SSL Bank Login Forms wilson . amajohn (May 18)
- Re: Non SSL Bank Login Forms Wil Clouser (May 18)
- Message not available
- Fwd: Non SSL Bank Login Forms John Kennedy (May 18)
- Message not available
- Message not available
- Fwd: Non SSL Bank Login Forms John Kennedy (May 18)
- Re: Non SSL Bank Login Forms Wil Clouser (May 18)
- Re: Non SSL Bank Login Forms Adam Tuliper (May 19)
- http/spnego connections Adam Tuliper (May 19)
- Re: http/spnego connections Saqib Ali (May 19)
- Re: http/spnego connections Adam Tuliper (May 19)
- Re: http/spnego connections Adam Tuliper (May 19)
- Re: Non SSL Bank Login Forms Don Jackson (May 19)
- <Possible follow-ups>
- RE: Non SSL Bank Login Forms James Strassburg (May 19)