Subject: Flexibility in implementing and deploying GSS-API extensions.

From: Matt Peterson <[email-masked]>
Date: Mon, 7 Mar 2005 14:12:15 -0700

Nicolas,

We've been watching the "kitten" WG for a while now.  I'm sending this 
email to you, in particular, because I believe that the work you've been 
doing with drafts to propse GSS-API extension APIs are an extremely 
important area of discussion. With your work on stackable-pseudo-mechs 
(which I need to read again) it appears as though you have flexibility 
in mind.  I've thought of writing a draft, but decided to email you and 
CC the list for input first.

The prospective of a namespace registry and ability to submit GSS-API 
extensions is an very significant step the right direction.  I was very 
pleased to see the draft.  However, from an implementation standpoint  
(i.e. from people who are investigating the inclusion of selected 
GSSAPI extensions in their products)  I'm still have a concern how 
extended API functionality would actually be deployed.  

I guess the main problem I'd like to avoid is application developers 
linking to a *particular* GSSAPI implemention for extension 
funtionality. The result, the system administrator would be left with 
only the flexability of the run-time linker's configuration when 
deploying the application.  Often times we see applications actually 
shipping product with their own GSSAPI implementation to ensure proper 
behavior -- which is sort of contrary to having written to an API 
abstraction in the first place. ;-/   You'd expect that 3rd party  
GSSAPI providers would be want the option of implementing the 
extensions (on their own time frame) and ship product that can be 
easiliy deployed with one (or more) applications.  Incidentally, I can 
seed the need for GSSAPI mplementations (even for the same mechanism 
OID) needing to coexist and be configured on a *per-application* basis.

What I'm thinking of is the ability for the system administrator (not 
the application developer) to select a GSSAPI implementation via 
configuration file that is suitable for a particular application (i.e. 
supports the GSS-API extensions that the application was written to).  
At the same time the application should be able to recover gracefully 
when configured to use a GSS-API implementation that lacks the 
necessary API extensions.  Basically, something that works a little 
like PAM, but allows plugability configuration for GSSAPI.

              +-------------+
              | Application |
              +------+------+
                     | (1)                      ,---------.
              +------+-------------+          ,`           `.
              | "pluggable" GSSAPI +---------.  pgssapi.conf )
          +---+    (pgssapi.so)    |   (2)    `.           ,'
      (3) |   +--------------------+            `---------'
          |
       d  |   +-------------------------------------+
       l  +---+ /usr/local/lib/mit/libgssapi.so     |
       o  |   +-------------------------------------+
       p  |
       e  |   +-------------------------------------+
       n  +---+ /usr/local/lib/heimdal/libgssapi.so |
          |   +-------------------------------------+
          |
          |   +-------------------------------------+
          +---+ /opt/xyz/lib/libxyz.so              |
              +-------------------------------------+

In the diagram above, pgssapi.conf would map application identifiers 
(similar to PAM) to a gssapi implementation.  The only requirement to 
make something like the above a reality would be a draft (which I'd 
write) describing 1) an API extension for pluggability that allows the 
application to specify the application identifier (similar to 
pam_start() pam_end() but simpler), 2) a recommendation for return code 
for NOT_IMPLEMENTED that allows the application to graceful fail (i.e. 
display or log a message that directs the system administrator to fix 
the gssapi configuration) 3) symantics (possibly syntax and grammar) of 
the config file.

In the end I think encouraging extension to the GSSAPI, as long as it 
follows proper namespace considerations, will be a very good thing for 
ubiquity of GSS.  If this is the case, system administrators and 
application developers would thank us if we provided an elegant way for 
them to deploy applications with a veriety (and mixture) of GSS API 
implementations.

For simplicity in this email I've restricted my examples to C bindings 
and run-time shared object linkage.  However, I think that the concepts 
would apply to other interpreted language bindings (Java and C#)... 

Yes, I realize that Solaris has a gssapi.conf that allows per-mechanism 
OID configuration.  What I'm introducing here is per-application GSSAPI 
config which is different in an important way -- especially when 
considering the (new) ability to implement IANA registered extension 
APIs.

Please comment.

Thanks,

--
Matt Peterson
Vintela, Inc

_______________________________________________
Kitten mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/kitten

---

From: Nicolas Williams <[email-masked]>
Date: Mon, 7 Mar 2005 23:30:39 -0600

On Mon, Mar 07, 2005 at 02:12:15PM -0700, Matt Peterson wrote:
[...]
> easiliy deployed with one (or more) applications.

What you are talking about is language-specific bindings and compile-,
link- and/or run-time detection of extensions availability.  And,
really, you're talking about the C bindings specifically, as it's
typically easier to deal with run-time detection of API availability
portably in higher-level languages than in C.

We're aware of this.  My intention is to provide at least for
compile-time detection of extensions availability, as that's probably
the best we can do _portably_ -- that's C for you.  Of course, on
platforms that provide weak symbols and so on you can do much better,
and for a small set of platforms you can even do so portably, but I'm
not sure we can use that in our I-Ds.

Incidentally, my individual submission I-D on stackable mechanisms has
become two KITTEN WG work items which I did submit on time to the I-D
repository, but which unfortunately did not get published on time.

One of those drafts provides for extended intquiry functionality that
could be used to detect, at run-time, the availability of whatever the
application needs.  The extended inquiry functions don't solve the
problem that the C language doesn't have standard run-time linker/loader
environments though, but for most other languages it'll do quite well.

>                                                    Incidentally, I can 

I don't.

> supports the GSS-API extensions that the application was written to).  

I don't see why you'd want this.

> necessary API extensions.  

See above.

>                            Basically, something that works a little 

I don't understand this.

[...]
> would apply to other interpreted language bindings (Java and C#)... 

See above, particularly with respect to the extended inquiry functions.

> OID configuration.

/etc/gss/mech

And note that the OID really ought not have to be configured there, just
the mech shared objects.

Nico
--

---

From: Matt Peterson <[email-masked]>
Date: Tue, 8 Mar 2005 10:07:51 -0700

Nick,

On Monday 07 March 2005 10:30 pm, Nicolas Williams wrote:
> Incidentally, my individual submission I-D on stackable mechanisms
> has become two KITTEN WG work items which I did submit on time to the
> I-D repository, but which unfortunately did not get published on
> time.
>
> could be used to detect, at run-time, the availability of whatever
> the application needs.  The extended inquiry functions don't solve
> the problem that the C language doesn't have standard run-time
> linker/loader environments though, but for most other languages it'll
> do quite well.

Right, I didn't see the original draft because I only searched on 
"kitten" drafts.   Would it be possible for you to email the now 
separate kitten drafts?  I'd like to give them a good read before I 
comment further on this thread.

> >  Incidentally, I
> > can see the need for GSSAPI mplementations (even for the same
> > mechanism OID) needing to coexist and be configured on a
> > *per-application* basis.
>
> I don't.

I think there are important arguments (some more commercial than 
technical) for allowing this kind of flexibility.  With out it I think 
the GSSAPI is less attractive to prospective 3rd party (non-OS) 
implementors.  Your extended inquiry functions might just do the trick 
so I'll spare the rhetoric until I've had a chance to look through the 
draft.

> [...]
> > In the end I think encouraging extension to the GSSAPI, as long as
> > it follows proper namespace considerations, will be a very good
> > thing for ubiquity of GSS.  If this is the case, system
> > administrators and application developers would thank us if we
> > provided an elegant way for them to deploy applications with a
> > veriety (and mixture) of GSS API implementations.
>

Again, I think it would be best to read through the draft describing the 
extended inquiry functionality before I comment further.

Thanks,

--
Matt Peterson

---

From: Nicolas Williams <[email-masked]>
Date: Tue, 8 Mar 2005 11:45:59 -0600

[...]
> comment further on this thread.

Sure.

> so I'll spare the rhetoric until I've had a chance to look through the 

The C bindings for the GSS-API do not define an ABI, and I don't think
we can define one now, so I'm afraid that you can't just switch between
GSS-API implementations without recompiling C applications -- the best
we can do is let each platform vendor define a C ABI for the GSS-API for
their platform, then 3rd party GSS-API implementors could match said ABI
and then, on platforms with run-time linker/loaders, one could switch
between GSS implementations without recompiling.

Some RTLDs support fancy features such as weak symbols, RTLD interfaces
(e.g., dlopen(), dlsym(), etc...), filters, auxiliary filters, and so
on.  Where you have such features and a C ABI for the GSS-API then C
applications can detect the availability of GSS extensions at run-time
and act accordingly.

That's all good, but we're not going to describe all that in any KITTEN
Standards track document as C RTLD environments are not standardized.

Nico
--

---

From: Jeffrey Altman <[email-masked]>
Date: Tue, 08 Mar 2005 12:20:46 -0600

Nicolas Williams wrote:

> we can define one now

Construction of an ABI for GSS is out of scope for this working group.
The specification of an API for GSS is a rare exception for the IETF.
The IETF will not take the step of defining a standard ABI for GSS or
any other protocol implementation.

Jeffrey Altman

---

From: Martin Rex <[email-masked]>
Date: Tue, 8 Mar 2005 20:15:52 +0100 (MET)

> between GSS implementations without recompiling.

Although the GSS-API doesn't define an ABI, we have been successfully using
binary plug'n'play with multiple third-party GSS-API mechanisms
during the last 6 years.

The definitions in the sample gssapi.h Header file in the GSS-API
C-Bindings document provide most of the information for binary
plug'n'play interoperability (at least if you ignore the "xom.h"-nonsense).

> applications can detect the availability of GSS extensions at run-time

Our application uses runtime dynamic loading through dlopen()/dlsym() 
(and other platform-specific incarnations), and maybe except for
such exotic platforms as IBM OS/400 and IBM OS/390 Open Edition,
they're *extremely* similar.

There are a few gotchas, particularly on some of the Unix platforms,
related to the (s)brk-based heap management, global symbol space,
symbol overloading, thread local storage and shared library initialization,
which may cause one or the other headache.

On some Unix platforms there are incompatibilities between single-threaded
and multi-threaded code.  If you're lucky the System-loader prevents
incompatible combinations upfront (Reliant Unix), otherwise you may
receive strange program malfunctions or crashes (Digital Unix,
HP/Compaq Tru64).  Some vendors seem to have silently abandoned traditional
single-threaded code in newer OS Releases to hide the underlying
problem (AIX,Solaris,Linux) in many/most/all scenarios.

What Unix vendors unfortunately haven't fixed so far, is their habit
of constantly making incompatible changes to their OS-Releases
(system-libraries) and compilers, which amounts to a royal PITA.

On Windows NT, I can ship a single DLL that works on all Win32-Platforms
(starting with Win95A) up to W2K3, for use with single and multi-threaded
Apps.  For each of the Unix platforms we support, we have to provide
between 3 and 10 different binaries...

Unfortunately GNU GCC/glibc/libc++ is doing just as bad as all 
commercial Unix vendors.

> Standards track document as C RTLD environments are not standardized.

They may not be standardized, but they're sufficiently alike these days.

Figuring out the right compiler/linker options and figuring out
how shared library initialization works (which might be necessary
if one wants to put C++ code into a shared library) is significantly
harder that calling the platform-specific RTLD.

My gsstest program contains a simple abstraction for thr RTLD for
all of the platforms we support, and it seems that it can load
the Kerberos shared libraries that Unix vendors are shipping these
days (HP had initially goofed their 64-bit library, but they fixed it).

So the lack of an official ABI might be much less of a roadblock than
you think.

-Martin

---

From: Nicolas Williams <[email-masked]>
Date: Tue, 8 Mar 2005 14:09:19 -0600

[...]
> plug'n'play interoperability (at least if you ignore the "xom.h"-nonsense).

But we cannot standardize a C ABI for the GSS-API, not even on a
per-platform basis because some vendors may not want to provide
meaningful compatibility guarantees.

> (system-libraries) and compilers, which amounts to a royal PITA.

Mind you, Sun is very careful about such changes.  See attributes(5) and
the man pages for any interfaces you depend on to see what commitment
Sun makes as to future compatibility.

[...]
[...]

I think we can give implementors, and more specifically, platform
implementors, guidance, but we really cannot provide normative text on
this subject.

> So the lack of an official ABI might be much less of a roadblock than

It's not much of a roadblock for what you do, I know, but it is, IMO, a
significant roadblock to inclusion of normative text in a standards
track RFC.

Now, when the C language gains standardized linker and/or RTLD
interfaces and OS vendors commit to C ABIs for the GSS-API, then we can
standardize a C ABI here.  Until then the best we can do is give
informative guidance on this.

Nico
--