Subject: Java-GSS issues (NOT spi-related!)

From: Michael Smith <[email-masked]>
Date: Tue, 26 Oct 1999 12:35:58 -0500

I have a couple of suggestions for the Java binding, 
on the assumption that we have decided to proceed with 
Jack and Mayank's draft in substantially its present 
form. The second of these suggestions leads to a 
general observation. 

1) Objects as tokens

J & M at present provide two ways of giving tokens 
to context-establishment and per-message methods: byte 
array and InputStream. I'd like to suggest that input 
tokens be more broadly typed as Object. Here's why: 

There are existing security protocols which are 
highly intertwined with their application protocols. 
In such cases, security-related data may well 
be all mixed up with application data; a fair amount 
of manipulation may be needed to carve out a byte array 
representation of the information relevant to (e.g.) 
context establishment. Moreover, in an object-oriented 
language like Java, the application and security 
information may both be delivered to the application 
program encapsulated in some object representation. 

An actual example, encountered here at TIAA-CREF: 

We have an implementation of the DAA protocol for HTTP 
running under a local version of GSS. Now DAA works by 
setting certain headers in an HTTP request. In our case, 
this request arrives on the doorstep of our application 
code encapsulated in an object -- a ServletRequest, to 
be precise. 

It gets worse. We may have to swallow our pride and 
support Basic authentication for HTTP as well. Now Basic 
authentication also sets headers in HTTP, but in a different 
way. 

Moreover, we may decide to allow Basic authentication only
over an SSL connection, just to give ourselves an illusory
warm feeling. 

So if we want to deliver a byte array or stream token to 
(say) the context-acceptance method, our application needs 
to dig into the ServletRequest, determine whether it's Basic 
or DAA and if the former whether it arrived in a plain brown 
SSL wrapper or not, then quarry out some header contents and 
concatenate them into the array or the stream. Ugh! These are 
not details that the application programmers want to worry 
their pretty little heads about.

As it happens, however, we are using (at present) a version 
of the GSS bindings which allows us to pass an Object -- 
specifically, in this case, a ServletRequest -- as a token. 
Our HTTP authentication mechanism understands all about HTTP 
headers and can ascertain very quickly with a few operations 
directly on the ServletRequest whether the authenticated request 
is kosher or not -- without ever having to go through the 
rigmarole of serializing snippets of HTTP header information 
into a byte array, and then turning around and parsing it.

In short, I think that the repertoire of object types that 
it will be reasonable to pass to mechanisms will often depend
on protocol and/or application and system context, and we'd 
be better off not trying to shoehorn 'em all into a byte sequence
representation.  If a mech gets an Object of a type it can't 
handle as a token, it just throws a bad-token exception precisely 
as it would do (under J & M's present arrangement) if the 
application screws up its construction of the byte array.

A pleasing side effect would be to de-bloat the context interface 
by reducing the number of flavors of context-establishment and
per-message calls: typing the token as Object covers both the 
present byte-array and input-stream cases. In this case, the 
context-establishment calls and per-message calls would be typed
as returning a byte array (the output token) and taking a token 
input parameter of Object, with an (optionally null) OutputStream
parameter in case you want the output token on a stream rather 
than a byte array. 

2) Channel bindings

J & M at present define a ChannelBinding class which can incorporate
a couple of java.net.InetAddresses plus a catchall in the form of 
a byte array. Here agin, I think the goal would be achieved more 
simply by typing the channel-bindings parameters to context calls 
as Object.  

The reasoning is similar: applications may be communicating 
over protocols other than TCP/IP, or they may be using networking
classes other than java.net to do it, or their "channels" may 
actually be purely logical constructs unrelated to underlying 
transport -- for example, the kind of logical "sessions" that Web
applications keep track of (and that middleware vendors tend to 
serve up cookies for). And again, these "channels" real and logical 
are likely to be represented by an extensive menagerie of 
objects.

This generalization would give us a further de-bloat, to the 
extent of an entire interface! At this rate, the spec will be 
positively anorectic. 

3) A general observation

Point 2) above leads into this. I think it's a bad idea to 
build into our Java binding any unnecessary dependencies on 
non-fundamental elements of the Java developer's kit or 
particular runtime environments. (This was also part of my 
reason for taking a somewhat dim view of Providers in the SPI 
work; I don't mind using 'em if they're available, but I don't 
want to depend on 'em). There are a lot of cool gadgets in the 
JRE and the JDK, and I understand the impulse to put them 
through their paces. Nevertheless, there are certain virtues 
in orthogonality too. 

Don't misunderstand me: I'm not one of those people who thinks
that Java is "just another programming language." (Are there 
really any such people, I wonder?) Nevertheless, it isn't
a mere legalism to observe that we are trying to produce
a _language_ binding, not a binding to an entire, comprehensive,
soup-to-nuts environment. 

Of course we're all grateful to the developers of Java for 
providing developers with an underground railroad off the 
platform plantations.  Once they find themselves on free soil, 
however, many of them will just want to till their own forty 
acres in peace, rather than sign on at another big spread. 
And we IETF-niks surely don't want to sell them a cow 
when what they're looking for is just a glass of milk.  

--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: Joe Salowey <[email-masked]>
Date: Tue, 26 Oct 1999 10:12:09 -0700

Objects as tokens is BAD.  I see no way to have any level of
interoperability with this.  A byte array is a well  defined object that can
be dealt with is a known way.  Likewise as input stream is a well defined
object that has useful methods.  java.lang.Object is well defined, but it
does not have very many useful methods (unless you want to convert every
thing into an ASCII encoded string).  Just by knowing that something is an
Object there is very little I can do with it.  If you need to deal with
other objects this should be done in a layer outside the GSSAPI and pass
only the appropriate mechanism data in a byte array or input stream into the
GSSAPI.  If you allow generic objects then you GSSAPI mechanisms become
application specific which I do not think is the original intent.

Joe

> -----Original Message-----
> From: Michael Smith [mailto:[email-masked]]
> Sent: Tuesday, October 26, 1999 10:36 AM
> To: [email-masked]
> Subject: Java-GSS issues (NOT spi-related!)
> 
>

---

From: Michael Smith <[email-masked]>
Date: Tue, 26 Oct 1999 14:44:19 -0500

At 10:12 AM 10/26/99 -0700, Joe Salowey <[email-masked]> wrote:
>Objects as tokens is BAD.  
[....]
>A byte array is a well  defined object that can
>be dealt with is a known way. 

Well, yes and no. If the application has to build a byte array 
(or stream) from snips and snaps of information that it winkles 
out of some object, then presumably it has to know the token format 
(often very far from well-defined) required by whatever mechanism 
it's submitting the byte array to. The application's innocence has 
already, so to speak, been lost. I don't see that this is superior 
in any way to the loss of innocence involved in knowing that 
such-and-such a mechanism can accept, say, a ServletRequest or 
whatever. 

What we did here was define methods that returned an array of 
Class objects indicating what kinds of objects were acceptable as 
tokens. 

We could also, of course, mandate that all mechanisms must support 
AT LEAST a byte array as an input token, and (at their discretion)
other kinds of objects as well. This would preserve flexibility
AND interoperability. 

--Michael Smith
  [email-masked]

---

From: Joe Salowey <[email-masked]>
Date: Tue, 26 Oct 1999 12:43:43 -0700

> it's submitting the byte array to. The application's innocence has 

The token format for your home grown mechanism may be ill-defined, but
GSSAPI token formats are well defined and they are application and platform
independant (except for perhaps channel bindings)!!  Each mechanism has an
RFC or at least internet draft that describes this.  The point is a
mechanism given a byte array or an input stream knows how to extract the
data from them.  Given a java.lang.Object there is no method except perhaps
toString() (UGH!) which the mechanism can use to extract.  Although java is
a platform independent language, requiring all mechanisms (regardless of
what platform they are on) to deal with java objects is not a platform
independent solution. 

The mechanism you are dealing with seems very implementation specific.

-Joe

---

From: Michael Smith <[email-masked]>
Date: Tue, 26 Oct 1999 16:07:10 -0500

At 12:43 PM 10/26/99 -0700, Joe Salowey <[email-masked]> wrote:

>independant 

I can't take credit for DAA -- it's a IETF standard, as a matter of fact. 

> The point is a
>data from them.  

Yes, the mechanism might know, but the problem lies on the other 
side: with the application trying to construct it. 

>Given a java.lang.Object there is no method except perhaps
>toString() (UGH!) which the mechanism can use to extract.  

Not what I had in mind. To say that a mechanism implementation accepts, 
say, ServletRequest means that the mech. impl. understands how to 
use the methods of ServletRequest to get the information it needs. 

> Although java is

Again, the idea is that various mech. impl's might accommodate various
kinds of objects (and possibly advertise these accommodations) -- not that 
ANY impl. would accommodate ANY object. 

>The mechanism you are dealing with seems very implementation specific.

Very application-protocol-specific, anyway. But such things do 
happen. 

--Michael Smith
  [email-masked]

---

From: Jack Kabat <[email-masked]>
Date: Tue, 26 Oct 1999 14:54:36 -0700

I completely agree with Joe.
 
What ever is passed into the JGSS to represent tokens has
to have a clear API on how to read/write data to it.
Object class does not have this.

The reason for adding streams was precisely so that an
application can pass its own data processing stream
(but after removing application specific data). GSS-API
(Java and other) have always dealt with just GSS-API
tokens. Application tokens are processed by the application,
and GSS-API is responsible for only processing the GSS-API
part of the load. 
  
Mayank and I are open to changing the stream oriented methods
to take other objects but ones that have a clear interface
for reading and writing data. We used streams because they
fit this requirement.

Regards,
Jack

> From: Joe Salowey [mailto:[email-masked]]
> Sent: Tuesday, October 26, 1999 10:12 AM
> To: 'Michael Smith'; [email-masked]
> Subject: RE: Java-GSS issues (NOT spi-related!)
> 
>