Subject: Java binding issues (response to Mayank)

From: Michael Smith <[email-masked]>
Date: Wed, 07 Apr 1999 11:54:37 -0400

At 11:12 AM 4/6/99 -0700, Mayank Upadhyay <[email-masked]> wrote:

>The return value from wrap/unwrap/getMIC is the output buffer.  We did not
>want to stick that payload into a return structure. If you do that then
>the output buffer field in it becomes redundant in the case where the user
>specifies streams for input and output. 

One could regard it as a redundancy, or as an option for the 
application programmer. Even qua redundancy, it seems harmless; 
if the application programmer has no use for it, he or she can 
just ignore it. 

Incidentally, I can't shake my reservations about the streams 
versions of the context calls. I'll try to articulate these 
reservations better in a response to Jack's note, which discusses
them in more detail. 

>Moreover, the user can just allocate one MessageProp object and use that
>all the time to pass in and get back QOP, privacy, and other information,
>so its not big deal. 

I agree that it's not a "big deal" in any case, but much was made, 
both at Minneapolis and on the list, of the importance of simplicity; 
a saving on "setup" costs for a call seems like a particularly 
nice increment of simplicity. 

>In light of the fact that Java has an "Exception" mechanism in place I
>would like to keep all fatal error codes in exceptions only. As a Java
>programmer, I would expect to catch an exception if a fatal error occurs. 
>The exception contains both the major and the minor status code.

No argument here; any fatal error should throw an exception. 

>Leaving GSS_S_COMPLETE and GSS_S_CONTINUE_NEEDED aside for the moment,
>getting an informatory status code during context establishment will also
>result in an exception because they are fatal when returned from
>GSS_Init_sec_context() and GSS_Accept_sec_context. 
>
>That leaves the informatory status codes from GSS_Unwrap() and
>GSS_VerifyMIC(). The equivalent of the informatory major code is returned
>in the MessageProp object for the caller to query. However, I realize that
>in this case there is no way to indicate a minor status code. That could
>easliy be added to MessageProp. 

Which is, essentially, part of what we did in our version. We went a bit
further, however, by assigning major and minor and informatory statuses 
to an object which keeps them together in an explicit way,
which seems to be the GSS style. GSS statuses, like New York cops, always
travel in pairs, so we gave them a patrol car and called it GSSStatus.
Since both context calls and per-message calls result in two of 
these officers showing up, we provided for a return of that portmanteau
object from both. Jack and Mayank's scheme provides no way for a minor status
to be returned on a successful context call, as mandated by GSS.
Mayank's suggestion of adding a minor status to MessageProp solves this 
problem (in a somewhat ad hoc way) for per-message 
calls but leaves it unaddressed for context calls. No doubt a different
solution could be devised for the context calls, but I think the 
GSS characteristic consistent design pattern of major and minor status 
and output token, common to per-message and context calls, ought to 
be preserved if possible, and find a reflection in the object 
architecture of the language binding; this is what we tried 
to do with our version. 

Also, I've just noticed that there doesn't seem to be any way, 
in Jack and Mayank's scheme, that the byte array flavor of 
context calls that fail (and throw an exception) can nevertheless 
return a token, as GSS states may occur. Have I overlooked 
something? In our scheme, of course, the output token, like the 
major and minor status, lives in GSSStatus, which is available 
as the function's return value on successful completion, or as 
part of the GSSException on failure. 

>As for GSS_S_COMPLETE and GSS_S_CONTINUE_NEEDED, the former is implicit
>when no exception is thrown, and the latter is part of the state of the
>context, not the individual unwrap/verifyMIC calls. (RFC page 65:
>GSS_S_CONTINUE_NEEDED should be returned only by GSS_Init_sec_context() 
>and GSS_Accept_sec_context()). This state of the context is returned by
>Context.isEstablished() in the Java bindings. 

Here again, then, it seems that semantics which GSS assigns to a value 
in the status field has been broken out as a separate special-purpose
method. Actually, we did this too, as a convenience to the programmer -- 
we have a getContinueNeeded method in GSSStatus. But we also provide the 
whole major status field, along with its bit mappings a la GSS, for 
programmers who prefer that idiom. 

I might observe, parenthetically, that the general difference between 
our approach on the one hand, and Jack and Mayank's on the other, 
might be characterized by saying that they have rearranged GSS more 
than we have in order to align it more with their sense of what is 
idiomatically Java-ish, while we have been a bit more conservative. 
It would be interesting to hear from other WG members where the sweet 
spot on this axis is thought to lie. 
 
>The GSSName constructor is equivalent to GSS_Import_name(). It takes an
>OID to indicate which nametype the object belongs to. Sometimes the
>nametype is GSS_C_NT_EXPORT_NAME in which case the resulting name object
>has to be an MN. If not, you can call canonicalize() on this name with a
>mechanism OID. That's pretty straightforward, not roundabout. 

Of course we had no constructors, because we specified 
interfaces rather than concrete classes, and interfaces don't 
have constructors. We have a method of the interface 
GSSImplementation, which simply maps GSS_Import_name in a very 
literal way. Presumably Mayank and Jack will have to do 
something similar when they convert to interfaces, but of 
course this doesn't answer the question whether the GSS 
notion of a Mechanism Name ought to map to a subclass of 
GSSName, or (on the other hand) to an instance of GSSName 
with some more or less hidden state. I think the former is 
preferable, since some GSS calls are specified to require or 
return Mechanism Names, and the obvious Java way to reflect 
this requirement is in the typing of the parameters or the 
return value. 

>As for subclassing GSSName for MN's like you suggested, the problem is
>that your GSSName constructor which is the equivalent of GSS_Import_name() 
>cannot then take GSS_C_NT_EXPORT_NAME as a nametype OID and expect to
>morph the GSSName object it creates into a GSSMechName subclass object.

Ah, but again: we have interfaces not classes, so no constructors. 
The way we get a GSSMechName is simply a ploddingly literal 
Javafication of the GSS calls: we either do an import() and a 
canonicalize(), or an import() of an output from a previous export(). 
The return value type of import is of course GSSName, so returning a 
subclass (GSSMechName) is entirely kosher. We would, of course, have 
the same problem Jack and Mayank had if we had tried to map import() 
using constructors, as they did, and I see now that this must be the 
reason they didn't want to sublass GSSName to get a Mechanism Name; 
but we were serendipitously saved from that pitfall by using the 
interface rather than class approach. The decision for an interface 
approach would seem to make this a non-problem, so the question 
to subclass, or not to subclass, can be answered without reference
to the issue of constructors. 

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