SEAM krb API

Nicolas Williams Nicolas.Williams at Sun.COM
Tue Apr 20 16:06:19 EDT 2004


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.

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
-- 


More information about the Kerberos mailing list