rpcsec_gss and Kerberos 5

[Rainer Orth]

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
do).

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

	Rainer