Subject: Re: Section 3 (take 2) Kerberos Revisions for comment

From: Darren Moffat <[email-masked]>
Date: Thu, 30 Nov 2000 12:55:00 -0800 (PST)

>BTW, it is possible for a PAM module to change the user item in a PAM
>handle. PAM applications have to honor such changes though (some
>PAMified /bin/login's do, such as FreeBSD's). And it doesn't make sense
>for more than one change to occur, and it should be the first module
>that makes any such change, IMO.

I don't believe chaning the PAM_USER item should be restricted to the
first module, there is no code in the Solaris or Linux PAM framework to
ensure there is only one change - and there shouldn't be either.

There are no restrictions on what a PAM module may do depending on what
position in the stack it is configured, for example some sites put
pam_unix before pam_krb5 others do it the other way around and some
have only pam_krb5.  This means modules can't depend on where in the
stack they are placed - because they are not supposed to be able to
find out where in the stack they are (I do think how ever it would some
times be useful to know if you are the final module and if the authentication
is going to fail - but IMHO this breaks the module abstraction a bit and
could be open to abuse).

>But don't say that this is a problem with UPN canonicalization. It
>isn't. It's a problem with Kerberos itself, that PN->other names
>mappings are not part of Kerberos and therefore it's up to the
>implementors to design secure mapping systems.
>
>MS dealt with it by putting the Windows user profile info right into
>the ticket. How do you propose to deal with this problem.

I belive the proposal for storing KDC information in an LDAP database
makes mapping all the different user identies to and from the Kerberos
principle easier. Since the POSIX, NT, Kerberos stuff is all included
into a single LDAP object so if you get a hold of the object you know
the mapping and you can do it all ways (providing you trust your LDAP
server, but if your KDC data is in there you had better).

--
Darren J Moffat

---

From: Nicolas Williams <[email-masked]>
Date: Thu, 30 Nov 2000 17:33:32 -0500

> ensure there is only one change - and there shouldn't be either.

I understand that.

> is going to fail - but IMHO this breaks the module abstraction a bit and

But, imagine you have pam_unix first, then pam_krb5 and both are
required. Then imagine pam_krb5 changing the PAM_USER item after the
user has been authenticated and authorized by pam_unix and then pam_unix
does not get a chance to authenticate/authorize the new username. Is
this an oops?  Is this an example of mis-configuration?  It certainly
sounds like the problem that Derek Atkins and Ken Raeburn were talking
about?

That's why I suggested that modules that may change PAM_USER should come
first on the stack. I did say "IMO"... :)

> server, but if your KDC data is in there you had better).

Sortof. Except for one thing: with the MS approach you can use the
special SID meaning "Authenticated Users" in file, LDAP and other ACLs
and so you can limit anonymous access much more severely than before. To
implement this without doing the PAC-in-tickets thing MS did (and which
I dislike) should not be hard, but several extensions could make it
easier to do so.

To implement "Authenticated Users" not using the MS approach you'd have
to make sure clients always send a forwarded TGT or a set of proxied
service tickets for all the services that an app might have to access
on behalf of the user. This sucks. This is one reason I've proposed a
TGT restrictions extension; such an extension would allow a user/KDC to
specify SPN patterns such that the given TGT can be used to obtain
service tickets (or cross-realm tickets with the same restrictions) only
for SPNs that match the restriction list.

As a [Unix] sysadmin, I must say that I like the Win2k / AD security
models. I just dislike the way that MS went about implementing some of
them :/

MS has been roasted by various critics for allowing anonymous lookups in
NT4 of domain SAMs. They had to, given the security model of NT4. This
is fixed with Win2k / AD. Do you or Sun propose a system where anonymous
or semi-anonymous LDAP lookups are required?

I've also proposed an "other names" extension, an "additional
signatures" extension, and now I'm even thinking of a TGS_REQ flag with
a companion ticket flag for impersonating a user in a limited way (the
app would use a TGT for its own SPN, the new flag and the client's
ticket to request a service ticket in the remote user's name -- the
"additional signature" extension would be needed here, and the "TGT
restrictions" extension would help).

And while we're at it, one of the biggest problems with Unix, and thus
one of the biggest advantages of Win2k, in the security area, is the
fact that Unix username/UID/groupname/GID namespaces are flat. For this
reason the Kerberos multi-realm model doesn't map very well onto Unix,
whereas it works very well with Win2k because WinNT already had a
non-flat username/SID+RID namespace. This shouldn't be so hard to fix in
Unix since many modern Unices already treat process/thread credentials
somewhat opaquely within their kernels (Solaris and *BSD do, for
example, see the definition and useage of cred_t -- Linux doesn't).

I've not detailed all of these ideas on this list or other lists.
Some I've only discussed privately. Some of them are specifically aimed
at providing a clean replacement for the MS PAC-in-tickets hack that
enables the same security model Win2k provides, or better. I have no
idea wether MS will ever be interested in such a thing. But I do think
that other vendors could use it.

Perhaps I should put these proposals it all into a draft RFC. It seems
that that may be the best approach, short of writing a reference
implementation, for getting comments on those extensions.

I hope I don't come across as either arrogant or as a zealot.

Nico
--