Subject: Re: Java-GSS Manifesto (fwd)

From: Mayank Upadhyay <[email-masked]>
Date: Mon, 28 Jun 1999 17:49:49 -0700 (PDT)

There seem to be some misconceptions about java's provider model.  Please
read my response to Michael's mail below.  I have also discussed a couple
of other issues that he raised.

Regards,
Mayank

On Tue, 22 Jun 1999, Michael Smith wrote:

...
...

> 1) Perhaps it makes sense to start with an aspect
> of Jack's and Mayank's proposal which I confess I
> don't understand: namely, the connection with the
> Provider interface of the Java Cryptography
> Architecture. I make no claim to a deep understanding
> -- key generation, message digest, etc. In other words, 
> things lower even than the mechanism level. Finding 
> (high-level) GSS implementation(s) down alongside 
> these crypto-nuts and crypto-bolts seems surprising.

The class java.security.Provider does not have to deal with crypto
providers only.  It can be used to provide any sort of service where the
application wants a pluggable architecture with a choice between different
implementations.  Traditionally this class has been used for crypto
providers because there have been a number of different algorithms and
implementations available in that area. 

Today, many java developers who write any sort of security service, be it
an SSLSocket implementation, or be it a GSS implementation, would like to
see a java.security.Provider based architecture for applications to
install/remove/choose their implementation. 

> Was this decision taken as a way to enable applications
> to _find_ GSS implementations? If so, it seems to 
> be a rather heavyweight and yet incomplete solution. 

Please explain why you think it is incomplete.

> Mobile code (e.g. applets) may not want to take whatever
> the local GSSManager (assuming it's there) will give them.

You don't have to if you don't want to.  In a previous mail thread about
this topic between Joe Salowey and myself you might have read that you
will have direct access to the GSSFactory interface.  This will be useful
for developers who bundle a custom GSS-API implementation along with their
application. 

> GSSFactory implementations have to extend the Provider 
                               ^^^^^^^^^^^^^^^^^^^
> class and also, it seems, implement the GSSFactory 
> interface. I don't know how much bytecode bulk the 

I don't recall saying that GSSFactory needs to extend Provider. Please
read the provider doc on the Sun web site or read more about this in
draft-ietf-cat-gssv2-javabind-02.txt.  (We will send out a list of changes
included in this new version shorty.) 

> ... I don't know how much bytecode bulk the
> Provider class brings with it, but it extends Properties 
> which extends Hashtable, and it has quite a repertoire
> of methods; this is a source of overhead which writers 
> of applets may prefer to avoid. 

If this were true then your applet would also be carrying almost all of
the entire Java class libraries with it.  Fortuately all definitions of
standard classes and the entire repertoire of methods that come with them
is already in the JRE that your web browser includes.  Your mobile code
does not need to carry this burden. 

In any case, any GSS-API being downloaded with an applet would probably be
meant just for that applet to use.  It seems quite unlikely, if not
impossible, that code being dowloaded as an applet might want to be a
system-wide library on the client machine.  So you need not worry about
providing the entire GSS framework with your applet.

> Here, we use a very lightweight approach: we
> set a system property to the name of a class
> implementing our GSSImplementation interface.
> This is in turn the factory class for everything
> else. As far as I can tell, this seems to
> provide as much functionality as Jack & Mayank's
> approach, at a lower cost.

This approach binds an application to a single GSS-API implementation for
the duration of its entire lifetime.

My requirements are a little different. I'm coming from the point of view
that my GSS implementation will be installed on a system and will be
available for use to all applications that set their CLASSPATH to include
it.  Some applications may decide that they want to use another
implementation, one that supports more mechanisms than mine does.  Or they
may even want to use both the implementations at the same time to make use
of the union of the two sets of supported mechanisms.  The GSS bindings
should allow applications to do that seamlessly in my opinion. 

While this is possible if the application is aware of all the factory
classes of all GSS implementations available on the system, that defeats
the purpose of a GSS-API.  The built-in java Provider architecture
insulates our application from all these configuration issues while still
allowing the application the flexibility to switch between these
implementations at runtime.

> ....... Dynamic loading and registration 
> of mechanisms is addressed by the "service provider 
> interface" that's been discussed off-and-on over the
> years in this WG, and which some of us have actually 
> tried our hands at. For Java, we here at TIAA been 
> working on this topic, and there's even an I-D:
> <draft-ietf-cat-gssv2-javabind-spi-02.txt>. 
> (This version has just been submitted and should show 
> up soon, but version 01 will give the feel and it's
> already in the repository.) This gives us a "fanout"
> from GSS to mechanisms; I'm not sure we need to define 
> another fanout above that, from application to multiple 
> GSS-es, although I'd be interested to hear the case for 
> it. 
> 

If you recall, the original approach that we had advocated for the Java
bindings was to define the GSS-API as a framework of concrete classes that
would do the fan-out and leave the underlying mechanism level SPI to be
interfaces which would plug into the framework.

However, at the Minneapolis session it was decided that we had to have a
way of picking different GSS implementations before the lower level
mechanism SPI was actually defined.  Hence we essentially introduced a top
level SPI in the form of the interfaces that we are currently proposing.

> Caveat: As noted, I don't feel that I fully understand
> why J & M made this decision, and I imagine that 
> many of these questions will be answered in their 
> draft when it appears.

If you're talking about the introduction of higher level interfaces, that
decision was made in Minneapolis by us all.  Jack and I would like to
propose that we go one step ahead and access those interfaces the right
way for generic, portable applications. There's nothing new here, this
model is already in place in the java language. 

> 2) As I discussed in an earlier communication to 
> the list, we made some discoveries in the course 
> of working on the SPI which we thought ought to be 
> reflected in the design of the GSS binding. In 
> particular, multi-mechanism implementations
> (including, a fortiori, the dynamic multi-
> mechanism version provided by the SPI and its
> associated "shim" or fanout layer) need to have 
> available all the information relevant to mechanism
> choice at the time a context is created. In 
> J & M's proposal (as well as in our original
> one) this wasn't the case; we all did, and J & M  
> still do, create a context, set a bunch of parameters,
> and then "init" or "accept". For the multi-mechanism
> case, this implies an intermediate layer of code 
> that's always interposed between actual mechanism
> code and application code, since the "context" object
> is instantiated before a mechanism can be chosen.
>
> This seemed ugly and inefficient to us, so we defined
              ^^^^^^^^^^^^^^^^^^^^

Might I ask what is ugly about another level of indirection that makes
things easier for the consumer? :-))

A multi mechanism GSS seemed to fit into a natural model of delegation
where an intermediate layer delegates everything to a mechamism specific
lower layer. 

In a multi mechanism GSS implementation you need the inefficiency of an
intermediate layer that processes your init binding. The intermediate GSS
code might need to go through your credentials and decide which mechanism
to instantiate based on what credentials you have acquired. 

At that point you then have the choice of returning this reference to the
user or you have the choice of storing it and delegating all future calls
to it. We chose the latter to keep the API uniform.  You will always have
to do that as far as the credentials and names calls are concerned because
they will almost always contain multiple elements.  We thought why not
keep the context related API consistent with that? 

As a side note I might also add that as far as efficiency is concerned, it
will be the crypto routines in the mechanisms that will make any
difference. 

> an interface which we called GSSContextHatchery. 
> Instances of this are produced by the factory 
> class. Hatchery contains reasonable defaults for
> all the init and accept parameters, and methods 
> to set them all if other than default values are 
> needed. When all the parameters are set to the 
> application's liking, it calls Hatchery's
> bindForInit() or bindForAccept() methods, which 
> choose a mechanism from those available and 
> return the mechanism's own implementation of 
> GSSSecurityContext -- no intermediate code 
> needed. 

Why couldn't the factory do this?

> A side benefit of this approach is that when 
> an application needs to create multiple contexts
> with the same parameters (class of service, credential, 
> etc.) it need only set these parameters once; 
> Hatcheries are infinitely reusable. With J & M's 
> approach, the application has to set all the 
> parameters every time it creates a context. 

Please recollect that there are overloaded versions of the constructors /
factory methods that assume commonly used default values.

> 3) We have an interface GSSMechName, corresponding
> to the abstract GSS notion of a "name for mechanism,"
> as well as a GSSName, which is the (potentially) 
> multi-mechanism form. GSSMechName adds an export()
> method to the base GSSName interface. J & M have 
> only GSSName, and it's either a Name For Mechanism 
> internally or not. If it is, then its export() 
> method works; if not, not. This seems un-Javaish 
> to me -- surely what one wants is that an object's 
> "contract" with the outside world should be clear 
> on its face, without having to know its history 
> (e.g. was it produced by a canonicalize()?). 

You're looking at the RFC defined MN and the RFC defined multi-element
internal name as different classes. GSSMechName (the MN)  should provide
an export() method while GSSName (multi-mech) should provide a
canonicalize(Oid)  method. And it is questionable if the GSSMechName
should then support canonicalize(Oid) while GSSName, at the same time,
cannot support calls to export() as you indicated. 

Therefore, in being true to your object "contract" it doesn't seem clean
for either of them to subclass the other in this view of things. However,
GSSMechName and GSSName should have a common base type since both an MN
and a multi-element internal name are passed to other GSS-API routines
interchangeably. This basically means that you will need to introduce a
third interface that is their parent and pass this parent around to
GSS-API routines. Too much complexity for too little.

Instead, we prefer to think of an MN as a variation in state of the usual
GSSName object rather than a new class.  It is technically not incorrect
to call export() on a GSSName even if it were not an MN.  (See RFC 2078
update Section 2.4.15).  Moreover, in our Java bindings we have added an
export(Oid) in addition to just export(). The former would be the
equivalent of doing a canonicalize and then an export.  Also, we have
introduced a GSSName.isMN() call to help applications determine what they
are dealing with. 

I don't deny the need for a lower level SPI interface GSSMechName, one or
more of which will be contained within the GSSName object.  But I don't
see the need to expose that in these bindings to the application
programmer.  It will certainly be exposed to the mechanism implementor in
the SPI document. 

> Pleasingly, our distinction turned out to be 
> very useful for our SPI as well; mechanism 
> providers directly implement GSSMechName
> (just as they directly implement 
> GSSSecurityContext, as described above) and 
> the "shim" or fanout layer implements GSSName
> in the form of a container class for one or more
> of these MechNames. 
> 
> 4) Both J & M and we here had to figure out some way 
> to handle the problem of "output parameters" in 
> abstract GSS. Such things aren't very idiomatic 
> to Java. We defined an interface called GSSStatus, 
> which bundles together major and minor statuses, 
> a general-purpose output byte array (for tokens), 
> and flags relating to token status (gap, old
> token, duplicate token, etc.) and continue-needed.
> This interface gets extended by another interface 
> called GSSperMessageCallResult, which adds QoP
> and confidentiality flags. A GSSStatus object
> is the return value of many calls (particularly 
> context establishment ones), and its extension,

During context establishment any status code other than GSS_COMPLETE and
GSS_CONTINUE_NEEDED is bad news.  We throw a GSSException with the
relevant information in it.  Without any errors, GSS_COMPLETE and
GSS_CONTINUE_NEEDED indicate a binary state of the context: established or
not established.  GSSContext.isEstablished() gives you the same
information.  No other GSS-API call returns GSS_S_CONTINUE_NEEDED. 

> GSSPerMessagecallResult, is the return value of 
> per-message calls. There's also a GSSStatus in the 
> GSSException class. 
> 
> J & M took a different approach. AFAIR, they 
> only return major and minor statuses as part 
> of an Exception; the assumption otherwise is that 
> the board is green. 
> 
> For per-message calls, J & M have a container class
> called MessageProperties, which gets instantiated by the 
> application, set with various message parameters
> by the application, passed in as a parameter with 
> the per-message calls, and then examined by the 
> application afterwards for per-message-related results.
> 
> Our approach doesn't require the application to 
> create and set up a MessageProperties object before
> it makes per-message calls; our GSSStatus and 
> GSSPerMessageCallResult are created and set up 
> under the GSS API, by mechanism code, and are 
> passed back as return values of the relevant calls. 
> I think this is a bit simpler for the application 
> programmer, and I think our GSSStatus better captures 
> the design pattern of abstract GSS, with its sets 
> of output parameters that tend to be found together. 

It's a matter of preference. I might add, in our defense, that the same
MessageProp object can be used repeatedly for successive per-message
calls.

> 5) J & M define a ChannelBinding class which can 
> only contain two java.net.InetAddress-es and a 
> byte[] of application data. Their reasoning is that 
> since InetAddress is the only kind of network address
> Java supports, there's no need for anything else. 

The reasoning for this proposal was that applications that write their
custom socket implementation and do not use IP are free to insert any type
of address information in the application data field.

> 
> We took the view that communications might well be 
> handled, for some applications, outside the ambit 
> of java.net.*, and that more flexibility was therefore
> required. Methods that take a channel-bindings parameter,
> in our proposal, define it simply as an array of 
> Objects. Mechanism implementers are exhorted -- and 
> perhaps we should change this to "commanded" -- to 
> handle at least two kinds: a) an array of five 
> objects corresponding to the five elements of the 
> channel-binding structure in the "C" GSS bindings, 
> and b) an array of three objects corresponding 
> to J & M's two InetAddresses and one byte[]. 

Incidentally, the five elements corresponding to the C bindings form a
superset of the data we include in two inet addresses and a byte array.
You need not include the latter separately if you propose to include all
five of the original elements from the C bindings.

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