Subject: RE: Objects as tokens

From: "Linn, John" <[email-masked]>
Date: Mon, 1 Nov 1999 14:08:33 -0500

I'm replying to this thread belatedly, having been traveling for the latter
part of last week just as the activity level on the WG list spiked to levels
not recently experienced.  I'm also replying at a level of generality,
deferring to others on the thread for superior Java expertise.  

This said, I believe that interoperability between GSS and JGSS is
fundamentally important.  To me, this implies either (a) that a JGSS
implementation must be able to accept and process tokens in the same form as
a GSS implementation would handle, or (b) that JGSS implementations accept
and process tokens in some other form *and* some other component resident
within the operational environment of all JGSS implementations will convert
back and forth between GSS form and that representation.  Case (b) seems to
introduce a dependency on a new component, and is less parallel with the GSS
model which explicitly decouples GSS from the communications layers with
which it's used; (a) appears to offer more simplicity and uniformity with
non-Java GSS.  It's possible, though, that implementations per (a) could
provide a facility which would sink and source non-GSS-formed tokens, but
I'd think that this should be optional and additional to supporting
GSS-formed tokens rather than alternative to them.  

If non-GSS token representations were to be used, it seems that there'd be
three choices for identifying those representations: 

(r1) agree universally on one or more object representations to be supported
uniformly across JGSS providers.  

(r2) register supported object definitions; this would be somewhat analogous
to GSS registration of supported name types.  It could work, but would add
another dimension to the prerequisites for matching an application with a
suitable JGSS provider.

(r3) dynamically declare or negotiate the object structure between
application and provider.  This could be very complex. 

Unless (r1) is feasible, portability across JGSS providers for non-GSS token
representations seems like it could be hard to achieve.  

--jl

==========================================================================
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: Mon, 01 Nov 1999 15:29:17 -0500

John -- 

At 02:08 PM 11/1/99 -0500, you wrote:

>back and forth between GSS form and that representation.  
[....]
>(a) appears to offer more simplicity and uniformity with

In essence, this was what I had in mind: acceptance of other token 
representations as a _supplementary_ function of Java GSS implementations,
not as something replacing OCTET STRING representations. The typing 
of token parameters as 'Object' is merely intended to facilitate this,
since a byte array is also an instance of 'Object'. Broadening
the type supports the superset, not the replacement of OCTET 
STRING. 

On the matter of interoperability, of course this is a sine qua non
of the design. I'm a little confused as to what kind of interoperability
John is alluding to above, though. The scenario of a JGSS and (say) a C-GSS
interoperating suggests to me that Java is at one end of the wire and 
'C' at the other; is that what you had in mind, John? If so it seems to 
be that the representation of tokens at the two ends is a purely local 
question for each end, provided only that the essential protocol information 
is present in some accessible form. (This doesn't extend to the wire protocol, 
of course, which has to be shared between the two ends.) That is (forgive
me if I'm repeating myself): the GSS-calling app on the 'C' end is 
likely to be seeing byte strings from its local transport, so it makes
sense for it to give byte-string representations of received tokens
to its local C-GSS implementation. But the Java GSS caller on the other
end is likely to be seeing some object encapsulation of the protocol, rather
than a naked socket. For cases like this, the supplementary support 
for other kinds of Object in addition to byte[] makes life easier for 
apps. (It shifts the burden to mech implementations, of course, but 
very often that's just where you want it.) 

>representations seems like it could be hard to achieve.  

I don't think (r1) _is_ feasible, since the kind of objects that might 
be usefully supported can't be foreseen. What I had in mind was closer to 
(r2), I think, if I'm taking John's meaning correctly. And yes, it adds 
a dimension to the process of matching app with provider, but not 
a very difficult one. My "shim" prototype does this (when it gets a 
non-byte[] token) essentially by asking its various registered 
mechanisms, "Can you do anything with this?" My SPI proposal 
defines the way to do this (the initable()/acceptable() methods). 
(For cases where the mechOID has been specified by the calling app, 
the shim only asks registered implementations that support that mech, 
obviously.)

I also have a component of John's (r3), above, since I provide
methods of GSS mechanisms that allow apps to query what kinds 
of objects can be passed as tokens. It isn't very complex -- but 
perhaps I've overlooked something! 

Portability is another one of those goals that means different 
things to different people. Let me distinguish in a broad-brush 
way between two polar types:

1) Mobile code that moves among systems of very different kinds, 
controlled by different authorities and provided by different vendors;

2) Sessile code which spends its entire life in systems controlled
by the same authority, but whose infrastructure may change over 
time. 

Clearly, supporting supplementary token representations is going 
to be fairly easy in case 2), perhaps less so in case 1). But 
case 2) is a significant set of applications. Particularly 
for us poor drudges in the end-user world!  

--Michael Smith
  [email-masked]