[36076] in Kerberos
Re: Windows KDC - Delegation Option
daemon@ATHENA.MIT.EDU (Greg Hudson)
Sat Apr 26 00:25:54 2014
Message-ID: <535B34CB.80203@mit.edu>
Date: Sat, 26 Apr 2014 00:23:39 -0400
From: Greg Hudson <ghudson@MIT.EDU>
MIME-Version: 1.0
To: Ben H <bhendin@gmail.com>
In-Reply-To: <CAAd7auawy6w7PxSV=wu_iPrjsAZ=tSscy1qdjKtoKv5BYG8gEA@mail.gmail.com>
Cc: kerberos@MIT.EDU
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Errors-To: kerberos-bounces@MIT.EDU
On 04/25/2014 11:49 PM, Ben H wrote:
> Based on your prior explanation I can't help but infer this means that
> although the new forwardable TGT session key may be different than my
> original TGT, it is still shared between all hosts that I delegate to,
> leading to a possible attack against all systems should one be
> compromised?
It's debatable whether this qualifies as an "attack." If one of the
target hosts goes rogue with the forwarded TGT, it can impersonate the
client principal and take arbitrary actions on that principal's behalf.
Being able to also decrypt the traffic of other target hosts is a
relatively small escalation in comparison, but it is an escalation of sorts.
> Is this the reason that MIT chooses to request a new TGT
> for each connection?
Yes, this is the main security concern we would have about changing the
MIT krb5 behavior to use one forwarded TGT for all forwarding
operations. It's possible that we might change it anyway, as it can
have a major impact on performance for HTTP negotiation.
________________________________________________
Kerberos mailing list Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos
