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

[Benjamin Kaduk]

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 corrected if I am.]
> >
> > The TGT is all you need. It gives you access to all the resources the
> > "real owner" has access to with no limitations. You do not need the long
> > term key at all (until the TGT expires of course).
> The TGT is a Ticket, holding EncryptedData.  That encrypted portion
> must be decrypted to get hold of the EncryptionKey contained in it.
> Passing a TGT verbatim does not release this information, right?
>
> In user-to-user Kerberos, it is also possible to pass a TGT from the
> service back to the client, and the client passes that verbatim without
> being able to make heads or tails of it.  That is what I meant.  But I
> may have been nitpicking, sorry about that.

You probably are nitpicking, yes, but I think the relevant key is the
session key that is contained in the TGT -- only KDCs would have the key
to decrypt the EncryptedData of the TGT (as opposed to the enc-part of the
AS-REP which is where the client gets it).

I assume that Simo is using "TGT" to mean "TGT and session key", as would
be in a user's ccache, and not in the strict protocol data structure
sense.

-Ben

Kerberos mailing list   Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos

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

[Simo Sorce]

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
> >> enforced) by the client realm.  This IMHO is a severe limitation on
> >> that particular model of constrained delegation.
> >
> > Can you be more specific about what limitation you see ?
> > S4U2Proxy can be enforced (and is in the FreeIPA case at least) in the
> > target service realm.
> 
> I hope I'm pulling this from the top of my head correctly; do let me
> know if I'm wrong though...
> 
> I'm thinking of realm crossover situations, where the realms fall
> under different control, and not necessarily with full mutual trust
> in each other's machines.
> 
> Consider a client in one realm, access a service in another.  The
> client's KDC supplies a TGT with enclosed PAC, and it is up to the
> service to use this only within the client KDC's intentions.  The
> TGT however, has been provided for the service's realm, and it is
> that realm that now enforces use and misuse according to the PAC.
> In short, the client realm relies on the service realm to be
> behaving properly.

Why would the client realm care what another realm does? The other realm
can make any info up the way it wants anyway ...

> This is the gist of what I've understood.  I hope I'm not messing
> up the details in how I wrote it down.  I do remember the clear
> conclusion that S4U2Self / S4U2Proxy do not enforce Constrained
> Delegation in a manner that is suitable for realm crossover.

I do not think this is true, the main problem you have is the service
realm can only trust any authorization data information from the client
realm in a limited way, because a crossover trust is not a situation in
which you want to fully trust what the client says in general.

But you do not have to, and I do not see anything in constrained
delegation that would be invalidated by this lack of trust.

S4u2self is just about getting a ticket in the client name to yourself.
The only thing you may want to do is to prevent a service in a random
realm to perform this operation to avoid information disclosure, but
that's about it.

S4U2Proxy between services of the same realm is perfectly fine
regardless of the client realm.

Now cross-realm s4u2proxy may be a little trickier, but again, assuming
proper access control and proper validation I do not see that it can't
be used across realm trusts, even crossover trusts conceptually.
You may want to add an AD to limit it for some uses cases, and you
probably want fine grained KDC enforcement of s4u2proxy (acls in the
kdc, we have them in freeipa).

> >>> 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 corrected if I am.]
> >
> > The TGT is all you need. It gives you access to all the resources the
> > "real owner" has access to with no limitations. You do not need the long
> > term key at all (until the TGT expires of course).
> The TGT is a Ticket, holding EncryptedData.  That encrypted portion
> must be decrypted to get hold of the EncryptionKey contained in it.
> Passing a TGT verbatim does not release this information, right?

Usually you delegate the decrypted TGT, just sending around the
encrypted TGT as obtained in the AS reply would be rather useless.

> In user-to-user Kerberos, it is also possible to pass a TGT from the
> service back to the client, and the client passes that verbatim without
> being able to make heads or tails of it.  That is what I meant.  But I
> may have been nitpicking, sorry about that.

user-to-user is a different protocol, it's not delegation, so I do not
understand how it relates.

Simo.

-- 
Simo Sorce * Red Hat, Inc * New York


Kerberos mailing list   Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos

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

[Simo Sorce]

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 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 application in the context of the principal (meaning
> >> they would not have to "login" as a specific user first), the client
> >> would not have to do fancy SRV queries to find the right KDC and the
> >> client would not submit huge tickets with every single request.
> >
> > It seem most of this is thought in the context of an Active
> > Directory-like setup.
> >
> > In the general kerberos case you do not have to be joined to a domain or
> > to login as a specific user to your local machine to perform an AS
> > request and get a TGT.
> >
> > You do have to locate a KDC to do it though, but with IAKERB you can
> > defer that to the server (at least if your user and the server have
> > identities in the same REALM, might get complicated, but still possible,
> > if not).
> >
> > If supported directly in the browser you could also have multiple
> > different identities, all you need is for the client to keep track of
> > which identity to use with each server, so it can select the right
> > credentials/REALM to construct the AS request.
> >
> > Finally, there is no requirement to send huge tickets with each request,
> > because we are talking about TLS this means you maintain an HTTP 1.1 or
> > HTTP/2 connection for multiple requests, this is something you always
> > want to do when using HTTPS and if this authentication is integrated
> > with TLS that's what you'd do to avoid expensive secure channel
> > establishment exchanges anyway. So the TLS layer would always keep track
> > of who the user is on the other side and provide that information to the
> > server.
> 
> That's all true. Your response was very informative and it has changed
> my understanding of this topic.
> 
> But not completely ...
> 
> Clients should not be required to have access to KDCs directly.
> Ideally KDCs should be on a separate network. Then make a hole for
> just the HTTPS server. Being able to put something "behind" a server
> and, more generally, partition networks by function is more secure.
> 
> Also, another thing is ticket security. Kerberos in it's current form
> is efficient in that tickets are cached on the client but that creates
> the potential for those tickets to be used in unintended ways. What
> happened to the principle of least privilege? If you take Kerberos and
> flip it inside-out (or outside-in rather) and push work into the
> server and only give the client the bare minimum necessary to create
> the TLS session, use the service securely and without fully
> re-authenticating frequently, that would be more secure.

The TGT is used to avoid to cache the long term key, in gneral
experience says that w/o a TGT you would have users store they long term
password in the browsers instead, that's much worse that a TGT which
expires after X hours.

> > In cases where TLS connections are terminated early (by some sort of
> > load balancer for example) and you want to "tunnel the user's identity"
> > you can use additionally other techniques:
> >
> > * the server provides a secure cookie (a bearer token of some sort) that
> > is provided at authentication time, but it is kind of useless given the
> > above.
> > * exchange a session key and provide a mush smaller proof of possession
> > than sending the whole ticket, again kind of pointless in the case you
> > base your TLS authentication on the user's credentials.
> 
> How could authentication be based on anything other than the user's
> credentials? Just to be clear about terminology, by "authentication"
> do you mean starting from scratch or is using a ticket which is a
> product of authentication that can be reused also considered
> "authentication"?

Well it really depends, if you have an established TLS channel
negotiated via "user credentials" (intentionally vague here) you should
not need any further authentication from the client.

However it is common deployment practice to use things like SSL
terminators in front of the actual servers that the user wants to
connect to as well as sometimes redirect users to other servers, so
there are "secondary authentications" involved sometimes. We do not
really need to discuss those here, as they are out of the purview of the
kerberos related authentication we are discussing here.

>  My scheme would be no different from Kerberos in
> this respect. You do full authentication and the client gets a 10 hour
> ticket for just the particular service. It never sees a TGT. The
> server would handle all of that (and maybe the server never sees a TGT
> either).

Interestingly enough this is something 

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

[Michael B Allen]

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 not matter, the user would not necessarily have to
>> run the client application in the context of the principal (meaning
>> they would not have to "login" as a specific user first), the client
>> would not have to do fancy SRV queries to find the right KDC and the
>> client would not submit huge tickets with every single request.
>
> It seem most of this is thought in the context of an Active
> Directory-like setup.
>
> In the general kerberos case you do not have to be joined to a domain or
> to login as a specific user to your local machine to perform an AS
> request and get a TGT.
>
> You do have to locate a KDC to do it though, but with IAKERB you can
> defer that to the server (at least if your user and the server have
> identities in the same REALM, might get complicated, but still possible,
> if not).
>
> If supported directly in the browser you could also have multiple
> different identities, all you need is for the client to keep track of
> which identity to use with each server, so it can select the right
> credentials/REALM to construct the AS request.
>
> Finally, there is no requirement to send huge tickets with each request,
> because we are talking about TLS this means you maintain an HTTP 1.1 or
> HTTP/2 connection for multiple requests, this is something you always
> want to do when using HTTPS and if this authentication is integrated
> with TLS that's what you'd do to avoid expensive secure channel
> establishment exchanges anyway. So the TLS layer would always keep track
> of who the user is on the other side and provide that information to the
> server.

That's all true. Your response was very informative and it has changed
my understanding of this topic.

But not completely ...

Clients should not be required to have access to KDCs directly.
Ideally KDCs should be on a separate network. Then make a hole for
just the HTTPS server. Being able to put something "behind" a server
and, more generally, partition networks by function is more secure.

Also, another thing is ticket security. Kerberos in it's current form
is efficient in that tickets are cached on the client but that creates
the potential for those tickets to be used in unintended ways. What
happened to the principle of least privilege? If you take Kerberos and
flip it inside-out (or outside-in rather) and push work into the
server and only give the client the bare minimum necessary to create
the TLS session, use the service securely and without fully
re-authenticating frequently, that would be more secure.

> In cases where TLS connections are terminated early (by some sort of
> load balancer for example) and you want to "tunnel the user's identity"
> you can use additionally other techniques:
>
> * the server provides a secure cookie (a bearer token of some sort) that
> is provided at authentication time, but it is kind of useless given the
> above.
> * exchange a session key and provide a mush smaller proof of possession
> than sending the whole ticket, again kind of pointless in the case you
> base your TLS authentication on the user's credentials.

How could authentication be based on anything other than the user's
credentials? Just to be clear about terminology, by "authentication"
do you mean starting from scratch or is using a ticket which is a
product of authentication that can be reused also considered
"authentication"? My scheme would be no different from Kerberos in
this respect. You do full authentication and the client gets a 10 hour
ticket for just the particular service. It never sees a TGT. The
server would handle all of that (and maybe the server never sees a TGT
either).

> These could be backed in browser through a standard or implemented
> entirely as a server controlled mechanism via normal cookies and/or
> javascript code running on the client.

I am very much opposed to using cookies or JavaScript for security purposes.

Mike

-- 
Michael B Allen
Java Active Directory Integration
http://www.ioplex.com/

Kerberos mailing list   Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos

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

[Simo Sorce]

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 application in the context of the principal (meaning
> they would not have to "login" as a specific user first), the client
> would not have to do fancy SRV queries to find the right KDC and the
> client would not submit huge tickets with every single request.

It seem most of this is thought in the context of an Active
Directory-like setup.

In the general kerberos case you do not have to be joined to a domain or
to login as a specific user to your local machine to perform an AS
request and get a TGT.

You do have to locate a KDC to do it though, but with IAKERB you can
defer that to the server (at least if your user and the server have
identities in the same REALM, might get complicated, but still possible,
if not).

If supported directly in the browser you could also have multiple
different identities, all you need is for the client to keep track of
which identity to use with each server, so it can select the right
credentials/REALM to construct the AS request.

Finally, there is no requirement to send huge tickets with each request,
because we are talking about TLS this means you maintain an HTTP 1.1 or
HTTP/2 connection for multiple requests, this is something you always
want to do when using HTTPS and if this authentication is integrated
with TLS that's what you'd do to avoid expensive secure channel
establishment exchanges anyway. So the TLS layer would always keep track
of who the user is on the other side and provide that information to the
server.

In cases where TLS connections are terminated early (by some sort of
load balancer for example) and you want to "tunnel the user's identity"
you can use additionally other techniques:

* the server provides a secure cookie (a bearer token of some sort) that
is provided at authentication time, but it is kind of useless given the
above.
* exchange a session key and provide a mush smaller proof of possession
than sending the whole ticket, again kind of pointless in the case you
base your TLS authentication on the user's credentials.

These could be backed in browser through a standard or implemented
entirely as a server controlled mechanism via normal cookies and/or
javascript code running on the client.

Also for the "big tickets" problem of the Active Directory case you
could simply request a TGT/ticket w/o the MS-PAC (it's an option in AS
and TGS requests IIRC), you'd just have to make sure the server knows
how to get the additional data in a different way, or not rely on it at
all.

Two constrains remain in any case.
- The server and the KDC have a shared secret between them.
- The user and the KDC have a share secret between them.

The user's KDC does not need to be the same as the server's KDC as long
as there is a way to create a trusted path between the two KDCs.

Simo.

-- 
Simo Sorce * Red Hat, Inc * New York


Kerberos mailing list   Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos

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

[Simo Sorce]

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
> >> instead of traditional certificate would be a big deal.
> 
> The general idea of IAKERB is that client-KDC traffic can travel over
> an unprotected link, which might involve the server.  It is still
> important however, to have the long-term secret (the "password")
> established between client and KDC to base the trust on.  That is not
> the pre-shared key scheme that I thought you were heading for.
> 
> >> I don't see why giving the server access to the TGT would be any
> >> different from delegation. It could be "constrained" to just the
> HTTP
> >> server(s), Sharepoint, or whatever stuff requires impersonation.
> >
> > Constrained delegation can be done without forwarding one's TGT.
> 
> 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
> enforced) by the client realm.  This IMHO is a severe limitation on
> that particular model of constrained delegation.

Can you be more specific about what limitation you see ?
S4U2Proxy can be enforced (and is in the FreeIPA case at least) in the
target service realm.

> > 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 corrected if I am.]

The TGT is all you need. It gives you access to all the resources the
"real owner" has access to with no limitations. You do not need the long
term key at all (until the TGT expires of course).

Simo.

-- 
Simo Sorce * Red Hat, Inc * New York


Kerberos mailing list   Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos

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

[Michael B Allen]

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 during auth
>>> instead of traditional certificate would be a big deal.
>
> The general idea of IAKERB is that client-KDC traffic can travel over an 
> unprotected link, which might involve the server.  It is still important 
> however, to have the long-term secret (the "password") established between 
> client and KDC to base the trust on.

Yes, the password would be required to get a service ticket. But it
would get it through the server and once it has a ticket it can skip
using the password for some time.

More specifically, the client would open a TCP connection to the IP of
the server, messages would be exchanged in a secure fashion using the
password "to base the trust on", the resulting crypto context would be
used instead of a traditional certificate for the TLS session and
finally the client gets a service ticket that it can use to skip
password authentication for 10 hours.

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 application in the context of the principal (meaning
they would not have to "login" as a specific user first), the client
would not have to do fancy SRV queries to find the right KDC and the
client would not submit huge tickets with every single request.

Mike

-- 
Michael B Allen
Java Active Directory Integration
http://www.ioplex.com/


Kerberos mailing list   Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos

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

[Rick van Rein]

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 idea of IAKERB is that client-KDC traffic can travel over an 
unprotected link, which might involve the server.  It is still important 
however, to have the long-term secret (the "password") established between 
client and KDC to base the trust on.  That is not the pre-shared key scheme 
that I thought you were heading for.

>> I don't see why giving the server access to the TGT would be any
>> different from delegation. It could be "constrained" to just the HTTP
>> server(s), Sharepoint, or whatever stuff requires impersonation.
>
> Constrained delegation can be done without forwarding one's TGT.

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 enforced) by the client 
realm.  This IMHO is a severe limitation on that particular model of 
constrained delegation.

> 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 corrected if I am.]

-Rick

Kerberos mailing list   Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos

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

[Simo Sorce]

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,
> >> >
> >> >> 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 involved.
> >> > You might forego DNS if you configured your client (which is certainly
> >> > not everyone's favourite solution).  You need the KDC to obtain a
> >> > short-lasting credential, which is pretty much a cornerstone of
> >> > Kerberos security.  The stale tickets and time sync come with that.
> >>
> >> I'm proposing clients use the server as a surrogate for the KDC. So
> >> the server would get a TGT on behalf of the client as well as a
> >> service ticket (for itself) and return it to the client. The client
> >> would then use that service ticket as normal. I understand that this
> >> would all warrant new commands and logic.
> >
> > The IAKERB mechanism was built for this scenario, but it seem like it
> > didn't really pick up, it worked by tunneling AS requests/replies, so it
> > is not the server that gets your TGT, which would be quite bad in the
> > general case.
> 
> Ah, yes, I thought there was something like this. I suspect I am just
> recalling IAKERB but twisted into my own fantasy.
> 
> 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.
> 
> I don't see why giving the server access to the TGT would be any
> different from delegation. It could be "constrained" to just the HTTP
> server(s), Sharepoint, or whatever stuff requires impersonation.

Constrained delegation can be done without forwarding one's TGT.
Forwarding a TGT is bad because it is unbounded impersonation.

Simo.

-- 
Simo Sorce * Red Hat, Inc * New York


Kerberos mailing list   Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos

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

[Michael B Allen]

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 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 involved.
>> > You might forego DNS if you configured your client (which is certainly
>> > not everyone's favourite solution).  You need the KDC to obtain a
>> > short-lasting credential, which is pretty much a cornerstone of
>> > Kerberos security.  The stale tickets and time sync come with that.
>>
>> I'm proposing clients use the server as a surrogate for the KDC. So
>> the server would get a TGT on behalf of the client as well as a
>> service ticket (for itself) and return it to the client. The client
>> would then use that service ticket as normal. I understand that this
>> would all warrant new commands and logic.
>
> The IAKERB mechanism was built for this scenario, but it seem like it
> didn't really pick up, it worked by tunneling AS requests/replies, so it
> is not the server that gets your TGT, which would be quite bad in the
> general case.

Ah, yes, I thought there was something like this. I suspect I am just
recalling IAKERB but twisted into my own fantasy.

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.

I don't see why giving the server access to the TGT would be any
different from delegation. It could be "constrained" to just the HTTP
server(s), Sharepoint, or whatever stuff requires impersonation.

Mike

Kerberos mailing list   Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos

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

[Simo Sorce]

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 the
> >> numerous dependencies for clients (DNS, KDC access, stale tickets,
> >> time sync...).
> >
> > I doubt you could use Kerberos without these components involved.
> > You might forego DNS if you configured your client (which is certainly
> > not everyone's favourite solution).  You need the KDC to obtain a
> > short-lasting credential, which is pretty much a cornerstone of
> > Kerberos security.  The stale tickets and time sync come with that.
> 
> I'm proposing clients use the server as a surrogate for the KDC. So
> the server would get a TGT on behalf of the client as well as a
> service ticket (for itself) and return it to the client. The client
> would then use that service ticket as normal. I understand that this
> would all warrant new commands and logic.

The IAKERB mechanism was built for this scenario, but it seem like it
didn't really pick up, it worked by tunneling AS requests/replies, so it
is not the server that gets your TGT, which would be quite bad in the
general case.

> Yes, this is all tangential to what you're doing.
> 
> >> I'm not sure if that is possible with HTTP being
> >> stateless, but if is, it could be the basis for proper Internet
> >> website security as well.
> >
> > It sounds to me like you are asking about preshared keys, which
> > are accepted to be far less secure than the Kerberos road.
> 
> Unfortunately I don't know all the nomenclature so I'll duck this one.

The problem is name resolution is still a problem in 2016, mostly
because of bad practices everywhere and a DNS system that has always
been hard to use for the general public.

Simo.

-- 
Simo Sorce * Red Hat, Inc * New York


Kerberos mailing list   Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos

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

[Michael B Allen]

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 tickets,
>> time sync...).
>
> I doubt you could use Kerberos without these components involved.
> You might forego DNS if you configured your client (which is certainly
> not everyone's favourite solution).  You need the KDC to obtain a
> short-lasting credential, which is pretty much a cornerstone of
> Kerberos security.  The stale tickets and time sync come with that.

I'm proposing clients use the server as a surrogate for the KDC. So
the server would get a TGT on behalf of the client as well as a
service ticket (for itself) and return it to the client. The client
would then use that service ticket as normal. I understand that this
would all warrant new commands and logic.

Yes, this is all tangential to what you're doing.

>> I'm not sure if that is possible with HTTP being
>> stateless, but if is, it could be the basis for proper Internet
>> website security as well.
>
> It sounds to me like you are asking about preshared keys, which
> are accepted to be far less secure than the Kerberos road.

Unfortunately I don't know all the nomenclature so I'll duck this one.

Mike

Kerberos mailing list   Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos

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

[Greg Hudson]

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 have other issues, including
performance.

More importantly, even a hypothetical perfect replay cache
implementation provides imperfect protection for a protocol as weak as
Negotiate.  If a passive attacker can replay a ticket and authenticator
in a new channel and have it work, then an active attacker can simply
suppress the original channel and use the ticket and authenticator in
their own.  This attack has higher prerequisites and is less subtle, but
it's still a terrible weakness.

(In better protocols, a good replay cache implementation can protect
against whole-session replays when no acceptor subkey is used.  But that
protection is very hard to achieve for clustered servers.)

TLDR: only use Negotiate auth over HTTPS.

Kerberos mailing list   Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos

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

[Rick van Rein]

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 involved.
You might forego DNS if you configured your client (which is certainly
not everyone's favourite solution).  You need the KDC to obtain a
short-lasting credential, which is pretty much a cornerstone of
Kerberos security.  The stale tickets and time sync come with that.

Do note that time sync is not always essential on the client; the
major concern for security is that the KDC and server are in time
sync; clients merely need time to be able to pick the right ticket,
but if they needed to (because they were embedded, say) they might
happily assume whatever ticket timing the KDC passed them and use
that to figure out how much longer a ticket would last.

> I'm not sure if that is possible with HTTP being
> stateless, but if is, it could be the basis for proper Internet
> website security as well.

It sounds to me like you are asking about preshared keys, which
are accepted to be far less secure than the Kerberos road.

-Rick


Kerberos mailing list   Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos

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

[Michael B Allen]

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 trust and perfect forward secrecy.

Hi Rick,

Using the Kerberos ticket as the certificate on which to build TLS
without using a CA and all of the work that goes with it seems much
cleaner. I'm glad to see people working on this.

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'm not sure if that is possible with HTTP being
stateless, but if is, it could be the basis for proper Internet
website security as well.

Mike

-- 
Michael B Allen
Java Active Directory Integration
http://www.ioplex.com/

Kerberos mailing list   Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos

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

[Russ Allbery]

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 configuration, since it redoes an
authentication on every page fetch and therefore generates a ton of
Kerberos authentication requests in a very small timeframe.  Historically,
this has caused replay cache collisions, which is why the replay cache is
always turned off, since otherwise most protected web sites became
inaccessible due to all the replay cache rejections.

I think modern replay caches may no longer have this collision issue?

-- 
Russ Allbery (ea...@eyrie.org)  

Kerberos mailing list   Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos

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

[Rick van Rein]

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, once you get TLS going for your HTTPS, you would have established
mutual trust and perfect forward secrecy.

This is work in active progress:
 - we're removing the last bugs from the GnuTLS-extension on
http://github.com/arpa2/gnutls-kdh
 - we hope to integrate the KDH branch into the TLS Pool soon from
https://github.com/arpa2/tlspool/tree/tls-kdh
 - we're preparing a HTTPS proxy on
https://github.com/arpa2/tlspool/blob/master/tool/https_proxy.py
 - we've got a generic TLS wrapper on
https://github.com/arpa2/tlspool/blob/master/tool/tlstunnel.c
 - we'll soon release a successor to
https://tools.ietf.org/html/draft-vanrein-tls-kdh-04

We also have plans for automatic realm crossover including client
identity pseudonymity.

But, alas, this is not ready to roll out yet.  We're still finishing the
work as we speak.


Cheers,

Rick van Rein
for the InternetWide.org / ARPA2.net project


Kerberos mailing list   Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos

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

[Osipov, Michael]

> 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 important point as Simo points out. As for client
libs: libcurl does not but libserf does fully establish the context.

Michael


Kerberos mailing list   Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos

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

[Simo Sorce]

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. Can someone intercept the 
> Kerberos ticket and use it for himself?

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.

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.

Use of HTTPS is recommend.

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

HTH,
Simo.

-- 
Simo Sorce * Red Hat, Inc * New York


Kerberos mailing list   Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos