Subject: RE: Objects as tokens

From: Jack Kabat <[email-masked]>
Date: Thu, 28 Oct 1999 12:25:01 -0700

Michael,

The main issue I see with your proposal is that
it leads to interoperability problems. If I use GSS
implementation Y, which supports object X, there is
no guarantee that implementation Z will also support
object X. This leads to an application being tied
to a particular implementation of JGSS - something
that we should not be encouraging.

GSS has always been clear about separating the application
protocol from GSS protocols.

The reason for my addition of streams into the JGSS
specification was precisely to solve the issue you are
tackling with and to take advantage of the OO encapsulation,
yet not to tie down to a particular implementation.
Notice that you are free to create your own stream class
which can handle any application protocol you desire. For
example, if I have my token embedded in RPC protocol, I
might create an XDR stream which I then supply into JGSS.
Now, every time JGSS does a read, my stream will perform the
necessary XDR decoding (and any other application protocol
specific processing). Because this is done in the stream
class, I can freely use any JGSS implementation.

Using streams allows the application to use protocol specific
objects directly in JGSS, but the logic is kept in the stream
implementation and not JGSS. This is rightly so, since the
protocol is application specific and not JGSS specific.

I agree with you that this functionality is useful and Java
lends itself well to supporting it, so we should take advantage
of it, but the logic should be supplied by the application
and not JGSS.

Regards,

Jack

> -----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 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]
> 
==========================================================================
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: Michael Smith <[email-masked]>
Date: Thu, 28 Oct 1999 16:00:14 -0500

At 12:25 PM 10/28/99 -0700, Jack Kabat <[email-masked]> wrote:
>to a particular implementation of JGSS

Well, it might lead to an application being dependent 
on a given implementation, or a given class of implementations,
of a given mechanism, but not on a given implementation
of JGSS. 

For the kind of cases that I'm trying to address here, this 
isn't a problem. My problem is supplying mechanism 
implementations -- really, of course, translation layers to 
existing infrastructure -- which acommodate known requirements
of applications in known environments. If I know that applications
require mechs to accept objects of type foo.bar.Blob as tokens,
I'm not going to deploy a mech that doesn't do that. But if 
I have GSS-API as an abstraction layer, I can swap out 
my.local.RACF in favor of mynewimproved.local.RACF or 
my.local.SomethingElse or even my.consultants.SnakeOil, and
if one of these implementers has blundered and forgotten
to support foo.bar.Blob as a token, I'll know about it 
right away -- I'll get a nice informative Exception. 
Whereas if they have a different understanding of the 
structure of a token in a byte array, I'll have some 
very fussy debugging to do. 

No doubt if I were a commercial supplier of mechanism 
implementations, I wouldn't take this approach -- 
particularly if the mechs were being shipped free-standing 
from any application protocols. I'd very likely just 
specify that you need to give me a byte array and no 
other kind of Object, and that would be that. Note 
that nothing in my suggestion prevents a mechanism 
implementer from doing precisely this.  

>which can handle any application protocol you desire
[....]
>but the logic should be supplied by the application
>and not JGSS.

Ah, but this is precisely the rub. There are many 
companies (and this is one of them) where there is 
considered to be a big difference between system 
programmers and application programmers. To say 
that functionality of this kind needs to be supplied
by the application would get me hanged from the 
nearest lamppost. 

Note, by the way, that I don't propose to have 
the functionality supplied "by JGSS", but by 
the mechanism implementation. All I need from JGSS
is to get the damn token object across the API. 
And I'm  beginning to think that Hannibal had an 
easier time getting his elephants across the Alps. 

--Michael Smith
  [email-masked]

---

From: Jack Kabat <[email-masked]>
Date: Thu, 28 Oct 1999 15:04:07 -0700

> of a given mechanism, but not on a given implementation

Not sure I see the distinction here?
 
....
> by the application would get me hanged from the 

I don't think anyone wants this :-)

Sounds like you are the developer for the JGSS, the
mechanism, and the protocol for some other group
of "application" developers. So there is nothing
stopping you from also developing a subclass of
stream that you supply with your packages and
protocol implementation. This should keep you
safe from any harm and keep the users happy. This
would also allow you to pass the
"damn token object across the API."

GSS tokens have a mechanism independent header which
identifies the mechanism and allows the implementation
to pass it to the correct mechanism. Not sure how this
would work with your approach?

jack

---

From: Michael Smith <[email-masked]>
Date: Fri, 29 Oct 1999 10:05:18 -0500

At 03:04 PM 10/28/99 -0700, Jack wrote:

[I had written:]
>Not sure I see the distinction here?

Well, recall that I have in mind ultimately that 
the local GSS implementation will be a "shim" and 
it will load mechanism implementations (MIs) dynamically. 
If an application is written so as to depend on the 
ability to pass an instance of foo.bar.Blob as a token, 
then the only MIs it can use, obviously, are those that 
know how to process such an object. That is, there's a 
functionality, or feature, requirement for MIs. This 
doesn't seem like quite the same thing as being bound 
to a particular JGSS implementation or even a particular 
mech implementation. 

> So there is nothing

If I understand what you're suggesting here, 
it's similar to Mayank's suggestion in an earlier
mail. Under this approach, an application would 
have know what (local) subclass of Stream to 
instantiate for a given combination of input 
token object and mech. How would it find out?
Whereas with my approach, which incorporates 
a means for mechs to inform applications what 
objects they will accept, less prior knowledge
is required of applications, and their code is 
cleaner. In any case, logic to process token 
information in various kinds of objects seems 
inextricably bound up with mechanism knowedge, 
and thus naturally belongs with mechanism 
implementation. 

Are we starting to repeat ourselves, I wonder? 
Should we defer further discussion of this 
matter to DC, when hopefully more people will 
get involved? 

--Michael Smith
  [email-masked]