Subject: RE: Objects as tokens (was: GSSAPI issues...)

From: Michael Smith <[email-masked]>
Date: Thu, 28 Oct 1999 10:04:12 -0500

At 01:56 PM 10/27/99 -0700, Joe Salowey <[email-masked]> wrote:
> First the GSSv2 RFC defines
>tokens as OCTET STRINGs not objects, so changing this in the language
>binding is not wise since this was not considered in GSSv2.  

The transition from procedural languages to object-oriented 
ones is, as we all know, a big step. I think it's fair to say that 
GSS-API has its origins at a time when procedural languages 
were very much the dominant paradigm. In procedural languages 
-- and particularly, of course, in 'C' -- a series of bytes is 
about the least characterized, most abstract thing there is. A sequence
of bytes can be anything, and everything is in the last analysis a 
sequence of bytes. In Java, though, the least-characterized, most 
abstract thing is Object. In saying that tokens are OCTET STRINGS, the 
GSS-API spec places the least possible constraint, in a procedural 
language, on what can be passed as a token: it says, in effect, 
give the mech a blob and it's up to the mech to parse it. The equivalent 
in Java -- the least-characterized, most-abstract, minimal-constraint 
specification for tokens -- is Object. This follows from a fundamental 
difference between procedural and object-oriented languages. 

>There are a
>number of considerations that must be met to insure interoperability across
>implementations and platforms.  For example, object types must be
>standardized somewhere. 

I don't see that this follows. I can easily envision situations 
in which an implementation of protocol X has, on Ann's end of the 
wire, an object representation A of the state of that protocol, and 
the implementation on Bob's end has a totally different object 
representation B of X, or a representation which isn't object 
oriented at all (perhaps Bob is a 'C' monoglot). The only requirement 
is that Ann and Bob have, respectively, representations acceptable 
to their respective local implementations. 

Actually, I think that my proposal (with the methods to advertise
what kinds of objects are locally supported as tokens) is considerably
more helpful to applications than the OCTET STRING specification. 
With OCTET STRING, any Bob who needs to extract and/or
build a token from his protocol interactions with Ann needs prior
knowledge of how to do that: take one byte from column A, two from 
column B, etc. With my scheme, Bob can get a list of object types
which will will least give him something to go on in putting 
together a token. If the architect and/or administrator of the 
system Bob is running on have done their work well, he's quite 
likely to find that one of the objects supported just happens 
to be one he already has lying around, or knows how to construct. 

>It is also worthwhile to note that while DAA is in the IETF standards track
>it is NOT a GSSAPI mechanism.  

As are (are not?) many other protocols in very common use. 

My own perspective on this is a down-and-dirty one. The 
waters in which I sail are full of "legacy systems" wallowing
like icebergs, and "middleware" vendors plying their deadly 
craft like Barbary pirates. GSS-API actually offers me 
a very promising means to insulate applications from the 
morass of protocols in use in this so-called "application
infrastructure," and from its constant flux. The less
hospitable GSS is to mechanisms designed without GSS in mind, 
the less useful it is to me. 

--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: Mayank Upadhyay <[email-masked]>
Date: Thu, 28 Oct 1999 10:54:40 -0700 (PDT)

Michael,

I vaguely remember having a discussion with you about this mechanism
before. Mike Eisler and I had pointed out to you even then that as per the
GSS-API RFC, the first token has to have a mechanism independent part to
it which contains the Oid of the underlying mechanism that will be used.
In other words the first token is not just an opaque blob as you seem to
think. (See section 3.1 of RFC 2078bis.)

This mechanism independent Oid enables the application to determine which
single mechanism GSS it has to bind to, or it enables a multi-mechanism
GSS to determine which underlying mechanism it has to use. Therefore, as
you see the GSS-API is a little bit more than just another API, it also
has a small amount of protocol. 

Your idea of using a plain object and passing it blindly to a GSS-API that
supports just one mechanism, your mechanism, will work but it is against
the design principles of the GSS-API IMHO. 

A reasonable solution to this might be adding an interface that supports
"byte[] getToken()" and your "Object" then implement this interface.  (In
your case, you can construct an object that contains the servlet request
and also implements this method. Then the API does not violate the GSS-API
RFC while at the same time your mechanism specific GSS can accept some
object instead of just a byte[].

-Mayank

>.... A sequence