Re: Kerberos and HTTP / HTTPS - Could Kerberos tickets be intercepted and misused?

On Thu, 25 Aug 2016, Rick van Rein wrote: > >>> Forwarding a TGT is bad because it is unbounded impersonation. > >> Only when the corresponding key is supplied alongside! [I hope I'm > >> not taking anything out of context by saying that, I'm not sure about > >> that but will probably be

Re: Kerberos and HTTP / HTTPS - Could Kerberos tickets be intercepted and misused?

On Thu, 2016-08-25 at 20:38 +0200, Rick van Rein wrote: > Hi Simo, > > >> Careful though -- constrained delegation as done by Microsoft's > >> S4U2Self / S4U2Proxy can only be used within one realm -- because the > >> server is supposed to confine itself to the limitations setup (but not > >>

Re: Kerberos and HTTP / HTTPS - Could Kerberos tickets be intercepted and misused?

On Thu, 2016-08-25 at 13:26 -0400, Michael B Allen wrote: > On Thu, Aug 25, 2016 at 10:09 AM, Simo Sorce wrote: > > On Wed, 2016-08-24 at 22:05 -0400, Michael B Allen wrote: > >> But, again, the point is that the client would not be "joined" to a > >> domain, it would not be

Re: Kerberos and HTTP / HTTPS - Could Kerberos tickets be intercepted and misused?

On Thu, Aug 25, 2016 at 10:09 AM, Simo Sorce wrote: > On Wed, 2016-08-24 at 22:05 -0400, Michael B Allen wrote: >> But, again, the point is that the client would not be "joined" to a >> domain, it would not be required to have network access to a KDC, time >> on the client would

Re: Kerberos and HTTP / HTTPS - Could Kerberos tickets be intercepted and misused?

On Wed, 2016-08-24 at 22:05 -0400, Michael B Allen wrote: > But, again, the point is that the client would not be "joined" to a > domain, it would not be required to have network access to a KDC, time > on the client would not matter, the user would not necessarily have to > run the client

Re: Kerberos and HTTP / HTTPS - Could Kerberos tickets be intercepted and misused?

On Thu, 2016-08-25 at 01:09 +0200, Rick van Rein wrote: > Hey, > > >> To be clear, the whole point of what I'm proposing is that the > client > >> would have ZERO dependencies. Being able to do proper auth and then > >> get a TLS session that uses the crypto context established during > auth > >>

Re: Kerberos and HTTP / HTTPS - Could Kerberos tickets be intercepted and misused?

On Wed, Aug 24, 2016 at 7:09 PM, Rick van Rein wrote: > Hey, > >>> To be clear, the whole point of what I'm proposing is that the client >>> would have ZERO dependencies. Being able to do proper auth and then >>> get a TLS session that uses the crypto context established

Re: Kerberos and HTTP / HTTPS - Could Kerberos tickets be intercepted and misused?

Hey, >> To be clear, the whole point of what I'm proposing is that the client >> would have ZERO dependencies. Being able to do proper auth and then >> get a TLS session that uses the crypto context established during auth >> instead of traditional certificate would be a big deal. The general

Re: Kerberos and HTTP / HTTPS - Could Kerberos tickets be intercepted and misused?

On Wed, 2016-08-24 at 15:55 -0400, Michael B Allen wrote: > On Wed, Aug 24, 2016 at 3:12 PM, Simo Sorce wrote: > > On Wed, 2016-08-24 at 12:35 -0400, Michael B Allen wrote: > >> On Wed, Aug 24, 2016 at 2:36 AM, Rick van Rein > >> wrote: > >> > Hey Mike, >

Re: Kerberos and HTTP / HTTPS - Could Kerberos tickets be intercepted and misused?

On Wed, Aug 24, 2016 at 3:12 PM, Simo Sorce wrote: > On Wed, 2016-08-24 at 12:35 -0400, Michael B Allen wrote: >> On Wed, Aug 24, 2016 at 2:36 AM, Rick van Rein wrote: >> > Hey Mike, >> > >> >> But it would be even better if the client could (or had the

Re: Kerberos and HTTP / HTTPS - Could Kerberos tickets be intercepted and misused?

On Wed, 2016-08-24 at 12:35 -0400, Michael B Allen wrote: > On Wed, Aug 24, 2016 at 2:36 AM, Rick van Rein wrote: > > Hey Mike, > > > >> But it would be even better if the client could (or had the option to) > >> do authentication with the service directly and thus eliminate

Re: Kerberos and HTTP / HTTPS - Could Kerberos tickets be intercepted and misused?

On Wed, Aug 24, 2016 at 2:36 AM, Rick van Rein wrote: > Hey Mike, > >> But it would be even better if the client could (or had the option to) >> do authentication with the service directly and thus eliminate the >> numerous dependencies for clients (DNS, KDC access, stale

Re: Kerberos and HTTP / HTTPS - Could Kerberos tickets be intercepted and misused?

On 08/23/2016 10:52 PM, Russ Allbery wrote: > I think modern replay caches may no longer have this collision issue? At least the MIT krb5 one does not; the authenticator ciphertext (which has a random confounder) is hashed to create a secondary ID. But current replay cache implementations still

Re: Kerberos and HTTP / HTTPS - Could Kerberos tickets be intercepted and misused?

Hey Mike, > But it would be even better if the client could (or had the option to) > do authentication with the service directly and thus eliminate the > numerous dependencies for clients (DNS, KDC access, stale tickets, > time sync...). I doubt you could use Kerberos without these components

Re: Kerberos and HTTP / HTTPS - Could Kerberos tickets be intercepted and misused?

On Tue, Aug 23, 2016 at 10:24 AM, Rick van Rein wrote: > HTTP/Negotiate is indeed so sad that we've been working on an > alternative, that is to integrate Kerberos + Diffie-Hellman into TLS. > Then, once you get TLS going for your HTTPS, you would have established > mutual

Re: Kerberos and HTTP / HTTPS - Could Kerberos tickets be intercepted and misused?

Simo Sorce writes: > By default MIT's GSSAPI (and Heimdal's if I recall) enables the replay > cache, but some modules (notoriously mod_auth_kerb) just disable it. It's very challenging to use the replay cache with mod_auth_kerb and a typical web application and security

Re: Kerberos and HTTP / HTTPS - Could Kerberos tickets be intercepted and misused?

Hi, > The HTTP/Negotiate protocol unfortunately does not prevent replay > attacks, so It can be done if the other endpoint does not use a replay > cache. > HTTP/Negotiate is indeed so sad that we've been working on an alternative, that is to integrate Kerberos + Diffie-Hellman into TLS. Then,

RE: Kerberos and HTTP / HTTPS - Could Kerberos tickets be intercepted and misused?

> And not just for the server, on the user side too as a lot of client > applications do not even check if the reply from the server is genuine > (completing the context establishment phase for mutual authentication) > and just accept the 200 OK code as it comes This is actually the most

Re: Kerberos and HTTP / HTTPS - Could Kerberos tickets be intercepted and misused?

On Tue, 2016-08-23 at 06:24 +, Eichhorn, Thomas wrote: > Hi, > > We use Kerberos for SSO in our local intranet. We followed this tutorial: > http://www.grolmsnet.de/kerbtut/ > Everything works just fine. > > I have a question about security: > > Our intranet sites are delivered with HTTP.