[481] in Kerberos_Protocol

home help back first fref pref prev next nref lref last post

Re: Ticket extensions in Kerberos revisions

daemon@ATHENA.MIT.EDU (Nicolas Williams)
Thu May 4 11:44:31 2000

Date: Thu, 4 May 2000 11:39:16 -0400
From: Nicolas Williams <willian@ubsw.com>
To: cat-ietf@MIT.EDU, krb-protocol@MIT.EDU
Cc: Ken Hornstein <kenh@cmf.nrl.navy.mil>
Message-Id: <20000504113915.B1094@sm2p1386swk.wdr.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
In-Reply-To: <200005040419.AAA05937@ginger.cmf.nrl.navy.mil>

Date: Thu, 04 May 2000 00:19:04 -0400
From: Ken Hornstein <kenh@cmf.nrl.navy.mil>

On Thu, 04 May 2000, Ken Hornstein <kenh@cmf.nrl.navy.mil> wrote:
> >In Windows 2000 you don't have to do that. I think it's security
> >advantage not to have to run services with priviledges, though it's not
> >a perfect solution wrt untrusted software.
> You're forgetting one thing - Kerberos was designed to authenticate
> principals _across a network_, not through a third party on the same
> machine.  If it's on the same machine, it's explicitly outside of the
> Kerberos design criteria.

This is the reason for that KDC PAC signature in the MS spec. I propose
that it be done differently, but either way it doesn't cost much at
all (signatures are small).

> (It makes me wonder why the third-party app couldn't pass ticket +
> authenticator to a system service, where _he_ could verify it and give
> the appropriate privs to the third-party app).

Because the third-party app has to have access to its service principal
key and so can forge tickets to itself.

> --Ken


home help back first fref pref prev next nref lref last post