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

From: Michael Smith <[email-masked]>
Date: Thu, 28 Oct 1999 15:01:51 -0500

At 10:54 AM 10/28/99 -0700, Mayank Upadhyay <[email-masked]> wrote:
>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.

I remember the conversation well; the problem here is not my 
advancing age, but my application requirements. 

It remains the case that many protocols have been developed, and 
no doubt will be developed, without GSS in mind. As I mentioned 
earlier, if CAT decides to shut the GSS door on these, 
the usefulness of this work will be greatly compromised, both for 
me and for a good many other people. I understand the reasons 
for the token encapsulation requirement; unfortunately, it has painted
us into a corner somewhat, as the tangled history of interaction 
between, e.g., GSS and SASL and GSS and SOCKS may suggest. 

Interestingly, the broadening of type which I propose offers a way 
out of this corner, I think, at least for Java applications and mechanism
implementations. If mechs can indicate the types of objects 
that they accept as tokens, this provides a way of structuring the set
of potential input tokens, analogous to the structuring provided by 
Oid encapsulation, but considerably more powerful and less rigid. 

Incidentally, it probably isn't necessary to say this, but just in 
case: of course everyone realizes that if the token type is Object, 
a byte array can still be passed, if you have one (since byte arrays 
extend Object). In other words, my broadening of type doesn't in any 
way prevent protocols that have nice GSS-formatted tokens from passing
them as byte arrays if that's what they want to do. The idea of the 
broadening is to take advantage of (should I say "leverage"?) the 
power of the language's type system to make life less of a hassle for
applications which don't sit directly on the wire, and/or use protocols
that don't GSS-encapsulate tokens. And once more I stress that these 
protocols exist and will not go away. We are simply not in a position 
to dictate terms to protocol implementers. 

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

Not "blindly," and not a "plain object"; the idea is to find out what 
kinds of specific objects -- _extensions_ of "plain," or abstract, Object --
the mech supports and then pass one of those. Nor is this confined 
to single-mechanism implementations; it's perfectly compatible with 
multi-mechanism ones, and even SPI-based ones with a "shim". 

>A reasonable solution to this might be adding an interface that supports
>"byte[] getToken()" and your "Object" then implement this interface.  

Clever idea. The problem is that I need to associate the functionality 
of digesting the object containing the token with the mechanism implementation
rather than with the application. Of course one could always define some 
class, associated with the mech. impl., which would provide your method
byte[] getToken() -- but then the app would still have to have some way
of getting this class from the mech. impl., of determining what input classes 
it would accommodate to get the token, etc. -- in short, a roundabout way of 
achieving the same thing.  

--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 12:55:31 -0700 (PDT)

> advancing age, but my application requirements. 
...
...
> Oid encapsulation, but considerably more powerful and less rigid. 
....
....
> multi-mechanism ones, and even SPI-based ones with a "shim". 

Who creates one of these mechanism specific objects? Is that logic in the
application layer? 

If your application and your mechanism are joined at the hip, I'm
beginning to wonder what you're achieving by using the GSS-API. Maybe your
needs will be best served by directly programming to a mechanism specific
API. Have you considered this option? 

-Mayank