Mechanism extensions and the GSSAPI

[Ken Hornstein]

>In this particular case we have two choices.  We can require the user
>to match the implementation features of their userspace against their
>kernel by hacking on krb5.conf.  Alternatively we can make matching
>these two implementation feature sets a problem for the
>implementations (and thus gssd).  If we make this issue a problem for
>gssd, then the user ends up with a better experience because the
>configuration information lives in the application and does not need
>to be manipulated by the user.  And the application is a better place
>for the configuration information to live in this case.

There is one additional thing to consider here with respect to configuration
information.

Right now the enctype configuration available in krb5.conf is global; it
affects all Kerberos applications.  But I have a real-world example
where global configuration isn't sufficient.

Due to policy requirements, for remote access to supercomputers within
our site we require the use of Kerberos with 3DES encryption.  However,
we have an exception for services that are not capable (like AFS).
I don't see a way to configure a client-side krb5.conf with a list of
enctypes that meet both requirements.  And I personally would be unhappy
to clamp the use of Kerberos enctypes at our site to the list of enctypes
that are supported by NFSv4.

I suppose it would be possible to configure a per-application enctype
list (although how you would implement that I'm not sure), but I think
that clearly the application is the best place to keep information
about application-specific encryption requirements.  That leads
(unfortunately) into requiring some way to configure that, which will
probably end up being a mechanism-specific API.

Just my $0.02.

--Ken