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

From: Michael Smith <[email-masked]>
Date: Wed, 27 Oct 1999 13:01:42 -0500

At 09:37 AM 10/27/99 -0700, Mike Eisler <[email-masked]> wrote:

> [You wrote]
>> My idea was simply to TYPE (forgive the caps) the token 
>> parameters, in the interfaces, as Object, solely so as 
>> not to constrain what kind of objects could, in particular 
>> cases, be used as tokens. 
[...]
>Would a peer, bound to the C-bindings GSS-API be able to accept and process
>these tokens?

It would, presumably, never see them. I don't imagine that 
in general, object encapsulations of protocols and protocol 
elements will be what are sent over the wire. 

Protocols define sequences of bytes, but in the OO world, 
we program to object interfaces which encapsulate protocols 
and other things.  

Traditionally, GSS has presupposed -- without being completely
explicit about it -- that the GSS caller, or user or whatever, 
is some entity that's getting stuff right off the wire. But 
it ain't necessarily so. Applications in the OO world often 
see stuff "off the wire" in a highly mediated form. 

Presumably "a peer, bound to the C-bindings GSS-API" is written
in C and is thus not (particularly) object-oriented, and therefore
not likely to be seeing stuff off the wire in an object-mediated
form. 

An analogy: Unix sockets and "Winsock" are not the same 
software representation of UDP and TCP wire protocols, 
but they can interoperate (or at least that's the idea). 

--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: Thu, 28 Oct 1999 11:15:00 -0700

GSSAPI allows an application developer to upgrade or change its security
layer without having the application modify large amounts of code (yes, I
know in practice this is not always true, but I see no reason to make it
worse).  

You have a mechanism from company A that takes an object like things.Stuff
as its token because it is convenient for a very specific application.  It
is found the implementation provided by company A does not work well and is
insufficient for the current security requirements for your project so you
obtain a more reliable more secure implementation from company B.
Unfortunately, company B's implementation does not know anything about
things.stuff so you have to spend months rewriting you application so it
uses other.Stuff instead.  One of the values of using GSSAPI is lost.  

If you are going to allow other objects you must at the very least
standardize on what objects are allowed.   

-Joe

> -----Original Message-----
> From: Michael Smith [mailto:[email-masked]]
> Sent: Thursday, October 28, 1999 8:04 AM
> To: [email-masked]
> Cc: Joe Salowey
> Subject: RE: Objects as tokens (was: GSSAPI issues...)
> 
> 
> 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 is a fundamental difference between a blob of bytes and an object.

> >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.