rpcsec_gss and Kerberos 5
ro at TechFak.Uni-Bielefeld.DE
Mon Jun 3 07:49:00 EDT 2002
Ken Raeburn <raeburn at MIT.EDU> writes:
> Rainer Orth <ro at TechFak.Uni-Bielefeld.DE> writes:
> > Indeed. Besides, switching to RPCSEC_GSS instead of AUTH_GSSAPI would give
> > interoperability with Sun's SEAM kadmind which used RPCSEC_GSS from the
> > start.
> Assuming we use a similar enough protocol definition on top of RPC.
> The current MIT protocol has no ".x" file to feed to rpcgen, and in
> fact I don't think it's easy to create one. For one thing, we have a
> 32-bit value we transmit as 8 bits in one place.... Mistakes like
> that can be corrected when we're making such a significant
> incompatible protocol change.
Since a couple of Sun employees are watching (and posting to) this list,
they might be able to get you a copy of the .x file used in their
implementation. Unfortunately, the Sun SEAM sources are not yet publicly
available (not even to licensees of the full Solaris 8 sources), though
that might change when the Solaris 9 sources hit the streets (if they ever
> > Sun's TI-RPC implementation even allows for the registration of additional
> > authentication flavors via svc_auth_reg(3NSL) (something older TS-RPC based
> > implementations don't support), so it might even be possible to support
> > both flavors in a single kadmind (at least on Solaris systems).
> Maybe. I'm not sure if the way our gssrpc authentication works would
> fit properly into the rpcsec model. It's something to look into.
It doesn't need to fit: this function allows you to register a completely
different authentication flavor (parallel to AUTH_SYS, AUTH_DH, etc.), not
just a different GSSAPI mechanism.
More information about the krbdev