Subject: Java-GSS Manifesto

From: Michael Smith <[email-masked]>
Date: Tue, 22 Jun 1999 16:19:25 -0400

Several days ago John Linn suggested that the 
authors of the two Java-GSS bindings documents
should write to the list explaining their respective
approaches. Here's mine; although comparisons
are proverbially invidious, I'll compare the 
approach taken by Jack and Mayank with ours, 
by way of identifying the underlying design 
questions. 

Our approach here at TIAA-CREF took the form, 
right from the first, of a package of interfaces.
Jack's and Mayank's was originally a package
of concrete classes, but I gather that interfaces 
have now been "back-formed" from at least some of 
these in compliance with consensus expressed at 
Minneapolis in favor of an interface-based approach. 
These different ancestries have not prevented the 
two proposals from converging to their present 
state of overall similarity; the differences are 
largely differences of detail. But then the devil 
is in the details, as they say.

1) Perhaps it makes sense to start with an aspect 
of Jack's and Mayank's proposal which I confess I 
don't understand: namely, the connection with the 
Provider interface of the Java Cryptography 
Architecture. I make no claim to a deep understanding
of JCA, but it appears to me that the Provider interface
is designed for low-level providers of algorithms
-- key generation, message digest, etc. In other words, 
things lower even than the mechanism level. Finding 
(high-level) GSS implementation(s) down alongside 
these crypto-nuts and crypto-bolts seems surprising.
Moreover, the Provider class seems to bring with it
a good deal of baggage that isn't obviously useful
for GSS implementations or their customers. 

Was this decision taken as a way to enable applications
to _find_ GSS implementations? If so, it seems to 
be a rather heavyweight and yet incomplete solution. 
Apparently somebody has to create an instance of 
a GSSFactory, and map the Property name
"org.ietf.jgss.FactoryImplementation" to that instance.
Then Jack & Mayank's GSSManager class (which is still, 
I gather, a concrete class) can find it. 

Mobile code (e.g. applets) may not want to take whatever
the local GSSManager (assuming it's there) will give them.
In this case, applications can presumably request a specific 
implementation, rather than letting GSSManager find the 
"default" -- i.e. the one to which 
"org.ietf.jgss.FactoryImplementation" is mapped, if 
there is any such. However, in order to do this, they have 
to have a reference to a Provider instance, presumably 
consisting of a GSSFactory instance, and it isn't obvious 
how they're supposed to get that, other than just 
knowing the name of the class and instantiating 
it directly, which renders the whole provider-finding
machinery moot. 

GSSFactory implementations have to extend the Provider 
class and also, it seems, implement the GSSFactory 
interface. I don't know how much bytecode bulk the 
Provider class brings with it, but it extends Properties 
which extends Hashtable, and it has quite a repertoire
of methods; this is a source of overhead which writers 
of applets may prefer to avoid. 

Our approach here at TIAA didn't mandate a specific
means by which applications are supposed to be able
to find GSS implementation(s), although it does 
make suggestions about techniques that might be 
used. It's not clear to me that we necessarily 
_want_ to specify how implementations are to be 
found -- this would seem to involve us rather 
heavily in environment or even language definition 
issues, which I'd think we might want to stay away 
from. 

Here, we use a very lightweight approach: we
set a system property to the name of a class
implementing our GSSImplementation interface.
This is in turn the factory class for everything
else. As far as I can tell, this seems to 
provide as much functionality as Jack & Mayank's
approach, at a lower cost. 

As a general observation, it seems to me that what 
applications are likely to want is the ability 
to pick mechanisms, not the ability to pick 
GSS implementations. Dynamic loading and registration 
of mechanisms is addressed by the "service provider 
interface" that's been discussed off-and-on over the
years in this WG, and which some of us have actually 
tried our hands at. For Java, we here at TIAA been 
working on this topic, and there's even an I-D:
<draft-ietf-cat-gssv2-javabind-spi-02.txt>. 
(This version has just been submitted and should show 
up soon, but version 01 will give the feel and it's
already in the repository.) This gives us a "fanout"
from GSS to mechanisms; I'm not sure we need to define 
another fanout above that, from application to multiple 
GSS-es, although I'd be interested to hear the case for 
it. 

Caveat: As noted, I don't feel that I fully understand
why J & M made this decision, and I imagine that 
many of these questions will be answered in their 
draft when it appears.

2) As I discussed in an earlier communication to 
the list, we made some discoveries in the course 
of working on the SPI which we thought ought to be 
reflected in the design of the GSS binding. In 
particular, multi-mechanism implementations
(including, a fortiori, the dynamic multi-
mechanism version provided by the SPI and its
associated "shim" or fanout layer) need to have 
available all the information relevant to mechanism
choice at the time a context is created. In 
J & M's proposal (as well as in our original
one) this wasn't the case; we all did, and J & M  
still do, create a context, set a bunch of parameters,
and then "init" or "accept". For the multi-mechanism
case, this implies an intermediate layer of code 
that's always interposed between actual mechanism
code and application code, since the "context" object
is instantiated before a mechanism can be chosen.

This seemed ugly and inefficient to us, so we defined
an interface which we called GSSContextHatchery. 
Instances of this are produced by the factory 
class. Hatchery contains reasonable defaults for
all the init and accept parameters, and methods 
to set them all if other than default values are 
needed. When all the parameters are set to the 
application's liking, it calls Hatchery's
bindForInit() or bindForAccept() methods, which 
choose a mechanism from those available and 
return the mechanism's own implementation of 
GSSSecurityContext -- no intermediate code 
needed. 

A side benefit of this approach is that when 
an application needs to create multiple contexts
with the same parameters (class of service, credential, 
etc.) it need only set these parameters once; 
Hatcheries are infinitely reusable. With J & M's 
approach, the application has to set all the 
parameters every time it creates a context. 

3) We have an interface GSSMechName, corresponding
to the abstract GSS notion of a "name for mechanism,"
as well as a GSSName, which is the (potentially) 
multi-mechanism form. GSSMechName adds an export()
method to the base GSSName interface. J & M have 
only GSSName, and it's either a Name For Mechanism 
internally or not. If it is, then its export() 
method works; if not, not. This seems un-Javaish 
to me -- surely what one wants is that an object's 
"contract" with the outside world should be clear 
on its face, without having to know its history 
(e.g. was it produced by a canonicalize()?). 

Pleasingly, our distinction turned out to be 
very useful for our SPI as well; mechanism 
providers directly implement GSSMechName
(just as they directly implement 
GSSSecurityContext, as described above) and 
the "shim" or fanout layer implements GSSName
in the form of a container class for one or more
of these MechNames. 

4) Both J & M and we here had to figure out some way 
to handle the problem of "output parameters" in 
abstract GSS. Such things aren't very idiomatic 
to Java. We defined an interface called GSSStatus, 
which bundles together major and minor statuses, 
a general-purpose output byte array (for tokens), 
and flags relating to token status (gap, old
token, duplicate token, etc.) and continue-needed.
This interface gets extended by another interface 
called GSSperMessageCallResult, which adds QoP
and confidentiality flags. A GSSStatus object
is the return value of many calls (particularly 
context establishment ones), and its extension,
GSSPerMessagecallResult, is the return value of 
per-message calls. There's also a GSSStatus in the 
GSSException class. 

J & M took a different approach. AFAIR, they 
only return major and minor statuses as part 
of an Exception; the assumption otherwise is that 
the board is green. 

For per-message calls, J & M have a container class
called MessageProperties, which gets instantiated by the 
application, set with various message parameters
by the application, passed in as a parameter with 
the per-message calls, and then examined by the 
application afterwards for per-message-related results.

Our approach doesn't require the application to 
create and set up a MessageProperties object before
it makes per-message calls; our GSSStatus and 
GSSPerMessageCallResult are created and set up 
under the GSS API, by mechanism code, and are 
passed back as return values of the relevant calls. 
I think this is a bit simpler for the application 
programmer, and I think our GSSStatus better captures 
the design pattern of abstract GSS, with its sets 
of output parameters that tend to be found together. 

5) J & M define a ChannelBinding class which can 
only contain two java.net.InetAddress-es and a 
byte[] of application data. Their reasoning is that 
since InetAddress is the only kind of network address
Java supports, there's no need for anything else. 

We took the view that communications might well be 
handled, for some applications, outside the ambit 
of java.net.*, and that more flexibility was therefore
required. Methods that take a channel-bindings parameter,
in our proposal, define it simply as an array of 
Objects. Mechanism implementers are exhorted -- and 
perhaps we should change this to "commanded" -- to 
handle at least two kinds: a) an array of five 
objects corresponding to the five elements of the 
channel-binding structure in the "C" GSS bindings, 
and b) an array of three objects corresponding 
to J & M's two InetAddresses and one byte[]. 

*
Conclusion
*

There are a few other differences between our scheme 
and J & M's, but these seem to be the only moderately
interesting ones. 

I would certainly like to see other contributors weigh
in and express a preference on some of these points; 
neither J & M nor we here have been able to convince the
other(s) on these remaining areas of divergence. 

There's also the procedural question of how to 
advance the spec: pick one, combine the two, 
or have one of us produce an interface spec and 
the other a concrete class spec, as suggested 
at Minneapolis. Here again, opinions from persons
other than the document authors would be useful!

I apologize for the hasty character of this 
communication; I'll be leaving town for a few days
and expect to be back in touch after the weekend. 
Any and all comments will be gratefully received 
and replied to as soon as I return. 

--Michael Smith
  [email-masked]

==========================================================================
This message was posted through the Stanford campus mailing list
server.  If you wish to unsubscribe from this mailing list, send the
message body of "unsubscribe ietf-cat-wg" to [email-masked]

---

From: Dave Arnold <[email-masked]>
Date: Tue, 22 Jun 1999 15:14:21 -0700

We need to agree on an Interface.  Let's work towards an agreement to the
Java GSS Bindings, then move on to SPI.  

Dave

> -----Original Message-----
> From: Michael Smith [mailto:[email-masked]]
> Sent: Tuesday, June 22, 1999 1:19 PM
> To: [email-masked]
> Subject: Java-GSS Manifesto
> 
>

---

From: Michael Smith <[email-masked]>
Date: Tue, 22 Jun 1999 19:20:49 -0400

>Java GSS Bindings, then move on to SPI.  

Unquestionably. On the other hand, if looking ahead a little bit 
helps us design both a binding and an SPI that are better than they 
would otherwise be, surely this is a Good Thing? 

--Michael Smith
  [email-masked]

---

From: Dave Arnold <[email-masked]>
Date: Tue, 22 Jun 1999 16:49:35 -0700

Looking ahead is good--I agree.  I thought it be more expedient to focus on
one thing at a time.  

The Provider Interface is only used by implementors of the GSS Interface,
and it seems to me that we could treat them separately.

Dave

> Sent: Tuesday, June 22, 1999 4:21 PM
> Cc: Dave Arnold
> Subject: RE: Java-GSS Manifesto
> 
>