Re: Mechanism extensions and the GSSAPI

[Sam Hartman <hartmans@mit.edu>]

>>>>> "Wyllys" == Wyllys Ingersoll <wyllys.ingersoll@sun.com> writes:

    Wyllys> Kevin Coffman wrote:
    >>> Shim around Ioctl
    >>> 
    >>> Mechanisms could provide a shim library that exports
    >>> mechanism-specific APIs that end up calling the appropriate
    >>> gss_ioctl function.  That means that the responsibility of
    >>> encoding the arguments is now the mechanism's rather than the
    >>> application's.  This proposal is as easy to use as the upcall
    >>> approach although it is as hard to write for mechanism authors
    >>> as the ioctl approach.
    >>> 
    >>> 
    >>> This has the same disadvantage of the ioctl approach if
    >>> multiple objects are used.
    >>> 
    >>> This approach solves the dynamic linking problem in that there
    >>> is no reason the shim cannot be in its own dynamic object.
    >>> 
    >>> 
    >>  I think I agree with Nico that this seems like the best
    >> option, but let me see if I fully comprehend.
    >> 
    >> - When building the application, you need to know whether it is
    >> linking against a single-mechanism gssapi implementation or a
    >> multi-mechanism glue layer.  Either way, it's interface doesn't
    >> change.
    >> 
    >> - If the app is linking directly with the single-mech
    >> implementation, and uses mech-specific functions, it all
    >> happily works.
    >> 
    >> - If the app is linking with the multi-mechanism "core glue"
    >> and uses mech-specific functions, it needs to know to link with
    >> the mech-specific "glue shim(s)" and not directly against the
    >> mech-specific library. (i.e. the "core glue" library shouldn't
    >> have to know about mech-specific glue shims.)
    >> 
    >> Is this what you were thinking?
    >> 
    >> 

    Wyllys> An app should never need to know or care that its linking
    Wyllys> against a single-mech GSSAPI or a multi-mech GSSAPI.  The

True.  But there are a large class of application that need to
configure mechanism-specific options for mechanisms that application
knows about.

If you are writing a generic application, you should not need any of
this.  If your application has mechanism-specific knowledge and is
attempting to act on that knowledge, you need some way of doing so.


    Wyllys>     Wyllys> API is standard and should not be broken or fractured
    Wyllys> among implementations.

    Wyllys> This sort of feature creep will start make it very hard to
    Wyllys> further the adoption of GSSAPI into various open source
    Wyllys> projects.  A project that wishes to use GSSAPI today needs
    Wyllys> to make some minor 'configuration' script edits to make
    Wyllys> sure the build environment has the correct path to the
    Wyllys> library and headers but doesn't need to really be
    Wyllys> concerned about features contained in the GSSAPI libs that
    Wyllys> it uses.  If the various implementations start adding
    Wyllys> major new interfaces like this, it will then force
    Wyllys> incompatibilities across the implementations and make
    Wyllys> applications less portable to the various implementations.

Here we disagree.  I'm not really interested in having the debate
about whether mechanism specific extensions are needed; I am already
certain they are.  I'd be happy to discuss with you off list why I
believe this is true, but I do not expect to be convinced I'm wrong.

I also believe that usability of applications by end users is far more
important in adoption of GSSAPI than the portability of GSSAPI
implementations.

I believe that when we have a choice between requiring a user to
configure some option and making things work without configuration, we
should avoid extra user configuration even if doing so introduces
complexity in our implementations.

Somewhere under this is a philosophical difference between how Sun's
architecture works and how the folks at MIT have come to view
usability.  Solaris seems to be able to get away with requiring
significantly more user configuration than we can on the Mac or
Windows.  My involvement in Debian suggests that the user base there
expects a configuration experience more similar to that of Mac or
Windows than that of Solaris.

I wish Sun's customer base was the only set of customers I needed to
deal with.  IT would certainly make my life easier, but I do have to
support significant customer bases that require less configuration.


    Wyllys> I disagree that such an API should be necessary.
    Wyllys> Mechanism specific details like "ktypes" have no business
    Wyllys> anywhere in a generic GSSAPI interface.  

Agreed.  However they do have business in a GSSAPI implementation.

And details like whether to use a replay cache with Kerberos sadly do
influence the application protocol.  If replay caches are used,
certain requests that would otherwise be valid become invalid.  But
certain security attacks are closed by using a replay cache.  Some
applications will care about these details.  Some applications will
even want to depend on protocol details of the Kerberos mechanism like
the number of round trips.  Such applications are not generic GSSAPI
applications.  But they can be applications that use the Kerberos
mechanism.

    Wyllys> Just because
    Wyllys> Kerberos is the main GSSAPI mechanism today, doesn't mean
    Wyllys> it will be so forever and GSSAPI should maintain a design
    Wyllys> that will support new mechs in the future.  

Agreed.  It should support the mechanism-specific extensions of these
new mechanisms as well.  For example, I might want to tell SPKM how to
verify certificates, where CRLs live, what to do if a certificate
cannot be validated online, etc.  These items are all mechanism
specific.  For many applications--especially generic applications, the
application will want/need to use defaults.  But for some
applications, mechanism-specific knowledge will be the right decision.

    Wyllys> Besides,
    Wyllys> kerberos enctypes can be configured several ways that do
    Wyllys> not involve hacking up the GSSAPI interface in
    Wyllys> non-standard ways:

    Wyllys> - As Nico suggests, create your NFS principals with the
    Wyllys> desired enctypes in the first place.  

This is what you must do for the server.  But this only affects the
server.

I should not have to disable AES on my server just because I have a
server that supports AES but clients that do not.

    Wyllys> - Set the
    Wyllys> permitted_enctypes, default_tgs/tkt_enctypes settings in
    Wyllys> krb5.conf so that only the desired enctypes are used.

This technically speaking works in that it is possible to implement
and that if correctly implemented will produce correct results.
However I believe some of my customers would consider this unusable.


Remember I said a while back that enctypes were a mechanism detail of
the Kerberos mechanism.  Well, gssd is not a generic application.  IT
lives between several different mechanisms, part in user space and
part in kernel space.  IT needs to know how to shovel credentials and
other mechanism-specific data between two (in Citi's case independent)
implementations of the same mechanism.


In short it needs to know about mechanism details.

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.  After all
we're configuring the capabilities of the application (or at least the
kernel module called by the application).  Those capabilities only
change when the kernel code changes.  Let the developers who are
changing code be responsible for  updating the description of what
their code can do.  Don't force each and every user to be responsible
for this task.

But wait, you say, NFSV4 is not just about Kerberos; why are we making
an exception and adding Kerberos specific extensions when we don't
plan to do so for other mechanisms.  O don't worry; that will all come
in time.  AS the other mechanisms gain feature negotiation, you'll
need the same facilities there.


At this point it seems worth taking a step back and asking whether our
system is following expected software evolution trends.  IN
particular, we seem to be calling into question some of our basic
abstractions or at least providing mechanisms to get around them.

I don't know how good of an idea this trend is, but it is certainly a
trend I've seen in most systems I've worked on long enough.
Admittedly, I might be the cause.  Abstractions are nice for the
simple cases and for the common case.    When we start on an
application, we are not as concerned about performance, backward
compatibility, usability, robustness.

But as applications grow more complex and important, they begin to
stress the system.  The application starts needing to be aware of
performance details of the particular implementations of abstractions.
Usability concerns force you to start working on application-specific
configuration GUIs, understanding implementation-specific errors to
better handle error reporting, etc.  In order to add good failure
handling  you need to understand the failures at an implementation
layer.

I believe this discussion is consistent with that evolution.    We
agree that you can write generic GSSAPI applications; we agree that
when possible you should.  But we acknowledge that for some
applications that will be the wrong approach.

--Sam