[OpenAFS] Re: SEAM krb API
Douglas E. Engert
deengert@anl.gov
Wed, 21 Apr 2004 09:53:28 -0500
Nico,
One of my long term goals is to use a vendor's provided Kerberos, if at
all possible. It looks like you are addressing most of the issues
with storing of the delegated credential being one of the big problems
along with a simple authz xxx_userok that can be used by daemons like sshd.
Another problem which is not being addressed, or not being addressed in
an agreed to manor is the use of the delegated credential by other software.
The AFS client is the one that comes to mind. It continues to evolve from
using only small Krb4 tickets with DES keys using des-cbc-crc, to today in
the OpenAFS CVS it can use large Krb5 tickets still with only DES keys but
can support des-cbc-md4 and des-cbc-md5.
But the AFS client code in the kernel still needs access to a kerberos ticket,
and the DES key. Solaris does not support this. If this is not corrected the
AFS client will still need its own Kerberos libraries.
Windows like Solaris does not have a Kerberos API, but it does allow
access to tickets and session keys. Solaris needs at least this. One could
argue that it has this via the ticket cache, but this then requires
more and more of some external Kerberos package.
In the defense of SEAM I should point out that the first thing I did with
Solaris 9 after installing AFS with Krb4 support, was to port the gssklog
which can use the SEAM gssapi to get an AFS token. But gssklog still requires
a gssklogd service to be run to "mint" the Kerberos/AFS token, and gssklog is
not widely accepted by the OpenAFS developers as a solution.
Sun is headed in the right direction, but is only exposing bits and pieces of
Kerberos to applications. You may not be exposing enough to get wide spread
acceptance of SEAM as the Kerberos of choice on Solaris.
Talking of wide spread acceptance, your sshd will need to be able to
use the delegated credential from the ietf-secsh methods to get an AFS token
to access a user's home directory in AFS. I am sure you are working on
this for NFSv4, and maybe AFS could use the same credentials and Kerberos
routines in the kernel.
Nicolas Williams wrote:
>
> On Tue, Apr 20, 2004 at 02:28:20PM -0500, Will Fiveash wrote:
> > On Tue, Apr 20, 2004 at 01:36:41PM -0500, Will Fiveash wrote:
> > > On Tue, Apr 20, 2004 at 01:58:31PM -0400, Wyllys Ingersoll wrote:
> > > > Ken Hornstein wrote:
> > > >
> > > > >For example, I was trying to help someone once who was trying to get
> > > > >Simon Wilkinson's GSSAPI patch for SSH going with Solaris & SEAM, and
> > > > >he ran into the problem that Solaris didn't export the krb5 API. He
> > > > >asked what I did, and I had to tell him that I didn't use SEAM, and
> > > > >that I advised him to do the same thing that I did (use the MIT
> > > > >library).
> > > > >
> > > > >
> > > > Talk to Nico about how he added GSSAPI to SSH for Solaris...
> > > > I think he looked into Simon's code and then went a different way
> > > > for various reasons.
> > >
> > > Yes, there are no direct dependencies on the krb5 API in Nico's SSH/GSS
> > > implementation. There are dependencies in sshd on libpam.so so I assume
> > > PAM is involved in the authorization.
> >
> > Actually, ignore what I wrote about PAM doing the authz for sshd. I was
> > wrong and I'm sure Nico will provide the correct details.
>
> <enter Nico stage right>
>
> Ken,
>
> Ok, so, we too have noticed that GSS-API applications on *nix tend to
> require additional functionality beyond what the GSS-API provides, and
> so we have addressed problem.
>
> _The_ major deficiency of the GSS-API in this area relates to the
> handling of delegated credentials. Enough ink^H^H^Hbandwidth has been
> spilt on this matter at the KRB and CAT WG lists so I won't repeat it
> all here -- suffice it to say that Solaris 10 will include support for
> GSS_Store_cred()[1].
>
> Next we have authorization of GSS-API principals to *nix usernames.
> This does NOT require any new interfaces, really, not to perform
> name-based authorization anyways. But a generic name-based
> authorization facility and interface which provides access control that
> is consistent with that provided by raw Kerberos applications (i.e.,
> consistent with krb5_kuserok()-type functions) is desirable.
>
> So Solaris 10 will provide such a facility as well, a generic version of
> krb5_kuserok(), we call it __gss_userok() and it will be a public
> interface.
I would like to see this as part of the gss-api, as 90% of the gss applications
need to use this. I know it sounds like heresy, but lets be practical too.
>
> This leaves a number of lesser problems that the GSS-API does not
> address. For example, ssh(1)/sshd(1M) must hardcode the OID of the
> SPNEGO mechanism in order to ensure that it is not used, well where the
> GSS framework supports multiple mechanisms anyways. I'll soon publish
> an Internet-Draft (which some here have seen previews of already) which
> addresses such issues.
>
> In fact, the Solaris 10 sshd(1M) will support draft-ietf-secsh-
> gsskeyex-07 without using any mechanism-specific interfaces, internal,
> private or or public. The only bit of mechanism-specific ugliness in it
> will be, as I mentioned, the hardcoding of the SPNEGO mechanism OID.
> And yet it will support delegated credentials and authorization
> facilities that are on par with kerberized in.telnetd/in.rlogind.
>
> I'm not sure which Solaris 10 beta or Solaris Express release this will
> show up in, but do look for it soon.
>
> I'll update this list as soon as I know which beta/SX this will appear in.
>
> [1] http://www.ietf.org/internet-drafts/draft-williams-gssapi-store-deleg-creds-00.txt
>
> Cheers,
>
> Nico
> --
> ________________________________________________
> Kerberos mailing list Kerberos@mit.edu
> https://mailman.mit.edu/mailman/listinfo/kerberos
--
Douglas E. Engert <DEEngert@anl.gov>
Argonne National Laboratory
9700 South Cass Avenue
Argonne, Illinois 60439
(630) 252-5444