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

From: Joe Salowey <[email-masked]>
Date: Wed, 27 Oct 1999 13:56:49 -0700

I can see the value in passing a generic object in as a token, but I think
this behavior has a number of implications.  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.  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.  In my opinion the language binding is not the place
to intoduce this, it would require a revision to the GSSAPI spec (maybe v3).
I would like to hear opinions from people who have a deeper insight into
GSSAPI than I do.

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

-Joe

> -----Original Message-----
> From: Michael Smith [mailto:[email-masked]]
> Sent: Wednesday, October 27, 1999 9:45 AM
> To: [email-masked]
> Subject: Objects as tokens (was: GSSAPI issues...)
> 
> 
> At 02:54 PM 10/26/99 -0700, Jack Kabat <[email-masked]> wrote:
> 
> >What ever is passed into the JGSS to represent tokens has
> >to have a clear API on how to read/write data to it.
> >Object class does not have this.
> 
> I see that I've given both Jack and Joe the same mistaken 
> impression of what I had in mind; obviously I expressed 
> myself badly. May I ask the list's indulgence to re-state
> my suggestion in a (hopefully) clearer way? 
> 
> 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. This was not intended to 
> suggest that any mechanism could take any kind of object, 
> or that mechanisms would have to restrict themselves to
> the exiguous repertoire of methods that Object has, in 
> processing tokens. Rather, my idea was that particular
> mechanisms (or mech implementations, MIs) might well want 
> to support, as tokens, kinds of objects above and beyond
> byte arrays. The kinds of objects they'd want to support 
> would depend, perhaps, on the nature of the security protocol
> and/or the application protocol and on the repertoire of 
> object representations associated with these. It wouldn't 
> be the same list for every mechanism, or MI, and many 
> mechanisms, no doubt, would find that byte-array filled 
> all the requirements. 
> 
> An MI's implementation of one of these Object-typed 
> methods would begin by finding out exactly what _kind_
> of object was passed in as a token, and then going off
> to code written to process that particular kind of object, 
> using whatever methods that object supports. If it got 
> an object that it didn't support as a token, it would 
> throw an exception -- precisely as it would do if it 
> got a syntactically malformed token in a byte array. 
> 
> How would applications know what kinds of objects they 
> could use as tokens? Here, we added methods -- 
> 
> Class[] getContextTokenClasses()
>   and
> Class[] getMessageTokenClasses()
> 
> -- to advertise what the mechanisms could handle. 
> 
> Here's some code fragments, adapted from the stuff 
> we're using here:
> 
> /* 
> From a mechanism implementation  
> Heavily edited and not guaranteed to compile
> */
> 
> /**
> *  Utility function to tell callers what kinds of objects are 
> acceptable
> *  as context-establishment tokens. Note that byte [] is 
> always acceptable. 
> *
> */
> public Class[] getContextTokenClasses()
> {
> Class accepts[] = new Class[1] ;
> try
>    {
>    accepts [0] =
>       Class.forName("javax.servlet.http.HttpServletRequest");
>    }
> catch (Exception e)
>    {
>    Class [] nullaccepts = {};
>    return nullaccepts;
>    }
> return accepts;
> }
> 
> /* 
> I'm reluctant to show you any real mechanism 
> code, it's such a dog's breakfast, but here's 
> the general appearance of the logic that branches
> on token type:
> */
> 
> public void accept(Object token) throws GSSException
> {
> byte[] b = {1,2,3};
> Class bclass = b.getClass();
> Class sclass;
> try
>    {
>    sclass =
>       Class.forName("javax.servlet.http.HttpServletRequest");
>    }
> catch (Exception e)
>    {
>    sclass = null;
>    }
> if ((token.getClass()).equals(bclass))
>    {
>    // Do something with the byte array
>    return;
>    }
> if ((token.getClass()).equals(sclass))
>    {
>    // Do something with the ServletRequest
>    return;
>    }
> throw new GSSException
>    ( new BasicGSSStatus
>       (GSSStatus.GSS_S_BAD_TOKEN,
>       (short)0, // Revisit this and signal more detail?
>       (short)0,
>       null)
>    );
> 
> } 
> 
> --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: Mike Eisler <[email-masked]>
Date: Wed, 27 Oct 1999 14:55:18 -0700 (PDT)

> First the GSSv2 RFC defines
> binding is not wise since this was not considered in GSSv2

Presumably the object is still encapsulated as an OCTET STRING. This way, even
a non-Java GSS application can still decode the unwrapped object, if it knows
how to decide Java objects. 

If not, then the proposal is a non-starter.