[14549] in Kerberos
Re: One way Cross-Realm Authentication
daemon@ATHENA.MIT.EDU (Booker C. Bense)
Fri Jun 8 10:38:38 2001
Date: Fri, 8 Jun 2001 07:30:22 -0700 (PDT)
From: "Booker C. Bense" <bbense@networking.stanford.edu>
To: John Rudd <jrudd@cats.ucsc.edu>
cc: <kerberos@mit.edu>
In-Reply-To: <3B200C14.189C5401@cats.ucsc.edu>
Message-ID: <Pine.GSO.4.33.0106080714370.8321-100000@shred.stanford.edu>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
On Thu, 7 Jun 2001, John Rudd wrote:
>
> We're planning to impliment Win2k and MIT compatability via cross-realm
> athentication here (for various reasons, one of whic is that the win2k
> desktops are admin'ed by a different group than the MIT KDC's). Right
> now we've set up two-way cross realm authentication, such that both
> realms have tickets of the form:
>
> krbtgt/THEM.UCSC.EDU@US.UCSC.EDU
> krbtgt/US.UCSC.EDU@THEM.UCSC.EDU
>
>
> However, I have a concern about security in US.UCSC.EDU ...
> specifically, I don't want THEM.UCSC.EDU principles to be valid on
> US.UCSC.EDU machines. It's not that I don't trust this particular group
> of admins (they're in our same department and we work closely with them
> often), but down the road we may offer this as a wider service so that
> any dept could do the same thing (each with their own locally
> administrated realm). I'd rather not have my realm vulnerable to their
> mistakes.
>
> So, the goal is that machines attached to and administrated by any
> random THEM.UCSC.EDU realm can have users authenticated against
> US.UCSC.EDU, and not visa versa.
>
> Can I accomplish that by deleting one of the above principles? If so,
> which one? I'm guessing it'd be the first one, but I'm not sure.
>
- I'm not commentting on the right/wrongness of this, but kerberos is
just an authentication service, not an authorization one. If you don't
put any THEM.UCSC.EDU principals on acl's[1] in the US.UCSC.EDU realm,
then cross-realm access doesn't get you anything.
- If there are resources you can accesss "just because you have a
kerberos principal" you will have problems in the future. Using
kerberos as an authorization service is almost always a mistake.
- Booker C. Bense
[1]- Of course, a .k5login is the most common acl and the least
controllable. Your policy will prevent the kind of abuse that
one could cause with plain old .rlogin files. Personally, I've
always believed that you should give users all the rope you can
stand and carry a big LART.
