Subject: Re: Java-GSS Manifesto

From: Michael Smith <[email-masked]>
Date: Fri, 02 Jul 1999 14:05:55 -0400

John had originally asked the Jack-Mayank team, and me, 
to write explanations of our own approaches. I don't want to 
turn this into a protracted exchange, but it may 
be helpful to respond to some of Mayank's comments.
Sorry if this seems like overkill.  

>>From: Mayank Upadhyay <[email-masked]>

>>The class java.security.Provider does not have to deal with crypto
>>providers only.  

My impression of Provider's purpose comes from the JCA spec
(available at 
<http://java.sun.com/products/jdk/1.2/docs/guide/security/
CryptoSpec.html>), which states: 

>The term "Cryptographic Service Provider" ("provider" for short) 
>is used to refer to a package or set of packages that supply a concrete
>implementation of a subset of the cryptography aspects of the 
>JDK Security API. 
[....]
>There are several types of services that can be implemented by 
>provider packages 
[viz.]
>MessageDigest - used to calculate the message digest (hash) of 
>specified data.
>
>Signature - used to sign data and verify digital signatures.
>
>KeyPairGenerator - used to generate a pair of public and private 
>keys suitable for a specified algorithm.
>
>KeyFactory - used to convert opaque cryptographic keys of type 
>Key into key specifications 
[...]
>CertificateFactory - used to create public key certificates and 
>Certificate Revocation Lists (CRLs).
>
>KeyStore - used to create and manage a keystore.
[...]
>AlgorithmParameters - used to manage the parameters for a particular 
>algorithm, 
[...]
>AlgorithmParameterGenerator - used to generate a set of parameters 
>suitable for a specified algorithm.
>
>SecureRandom - used to generate random or pseudo-random numbers. 

Mayank goes on to say: 

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

This point might usefully be elaborated upon. I personally 
come to this work both from the point of view of a developer 
of mechanisms under GSS and a developer of applications that 
call GSS. I really don't see what good the connection with Provider
does me in either capacity, so it would be useful to hear more from 
those who do. One is never too old to learn. 

Mayank asks: 

>>Please explain why you think it is incomplete.

I tried to explain this in my original post, as follows:

>Apparently somebody has to create an instance of 
>a GSSFactory, and map the Property name
>"org.ietf.jgss.FactoryImplementation" to that instance.
>Then Jack & Mayank's GSSManager class (which is still, 
>I gather, a concrete class) can find it. 
[or]
>[A]pplications can presumably request a specific 
>implementation, rather than letting GSSManager find the 
>"default" -- i.e. the one to which 
>"org.ietf.jgss.FactoryImplementation" is mapped, if 
>there is any such. However, in order to do this, they have 
>to have a reference to a Provider instance, presumably 
>consisting of a GSSFactory instance, and it isn't obvious 
>how they're supposed to get that, other than just 
>knowing the name of the class and instantiating 
>it directly, which renders the whole provider-finding
>machinery moot. 
[....]
>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. 

I don't know that re-stating this would be likely to make
it any clearer. I might add, however, that the 
"somebody" who creates the GSSFactory instance
and maps the "org.ietf" etc. Property name to 
a Property instance somehow connected with it, 
is not part of J & M's spec as far as I can see. 
Have I overlooked it? This was part of the "incompleteness"
I was thinking of. Presumably if we want to mandate 
a mechanism by which applications can find GSS 
implementations, and make that part of the spec, we
need to specify that mechanism from start to finish. 

Me: 

>>> GSSFactory implementations have to extend the Provider 
>>                               ^^^^^^^^^^^^^^^^^^^
>>> class 

To whom thus Mayank:

>>I don't recall saying that GSSFactory needs to extend Provider. 

Indeeed not; this was my conclusion, based on the fact that GSSManager
seems to have ways of getting to GSSFactory implementations when it 
is given instances of Provider. Perhaps Mayank envisions some other 
form of connection between the Provider instances and the GSSFactory
implementations, but I haven't been able to find where this connection
is discussed. Again, more detail would be welcome. 

Mayank:

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

Ah, if only 'twere so. My own experience with applets suggests
that the fewer assumptions one makes about what's in the browser, 
the better. 

It might be noted parenthetically that other kinds of "mobile
code" besides applets may need to be considered -- code
that travels in e-mails, for example. Complete uniformity 
among platforms remains elusive. 

Me: 

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

Mayank: 

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

Well, no. It simply provides one way for an application to get _an_ 
implementation without having to code the implementation's factory class 
name in source. It can easily coexist with other mechanisms for finding 
implementations, if needed, and if the developer doesn't mind coding the 
factory class name explicitly, that approach is always available. 

Mayank: 

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

This isn't quite the way I remember the Minneapolis discussion. 
I don't recall anything being said about specifying "ways to pick 
implementations"; perhaps I missed this. What I do recall is that 
we decided that GSS-API should be specified as interfaces, and that 
SPI work could and should wait until this was done. I don't disagree; 
my own work on a mechanism-level SPI was undertaken mainly 
with a view to anticipating SPI-level problems that might be eliminated
or ameliorated by appropriately foresightful approaches to the 
GSS interfaces proper while these were still unfrozen. As I 
noted in my earlier comment, I believe that in fact I did 
identify a few such issues which can be addressed now, 
in our GSS interfaces design, at no cost. 

Me: 

>>> multi-mechanism implementations
>>> [....] 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
>>              ^^^^^^^^^^^^^^^^^^^^
>>

Mayank:

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

There's an old joke to the effect that there is no computer-science
problem that can't be solved by introducing another layer of indirection,
and no performance problem that can't be solved by eliminating one. 

I think the extra "layer of indirection" is annoying, once a context is
established,  because it doesn't do anything for you -- it doesn't 
give you any "fanout." The extra overhead of another indirection 
layer is an acceptable cost if it does something for you, but that 
isn't the case here. Logically, once a context is created, it is 
bound to a mechanism. Having a multi-mechanism cocoon around it 
is all cost and no benefit at that point. To continue the 
lepidopteran metaphor, I think we should let the context emerge 
from its cocoon and spread its wings. 

Mayank:

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

Exactly. Processing your "init binding" is precisely where you _do_ need 
the multi-mechanism stuff, and _there_ it isn't inefficient at all. 
It is this difference between the state of affairs before context
creation (and mechanism binding), and after, which our innovation 
of GSSContextHatchery is designed to reflect. The cocoon has a use,
while the butterfly is still a larva (do I mean pupa?). 

Mayank: 

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

Simply because names and credentials are multi-mechanism by nature 
but contexts are not. It's a real difference in the logic of the 
API. 

Me:

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

Mayank:

>>Why couldn't the factory do this?

If the factory did it directly then a given factory 
instance could only have one context in process of creation 
at any given time. Our idea was that factory instances might 
well be used by multiple threads, but that GSSContextHatchery
(a dinky little thing) would be obtained in-line and only 
used within a given thread. 

Me:

>>> 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()?). 
>>

MayanK: 

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

Yes, a third, parent interface, without export() or canonicalize(), 
extended by Name and MechName with canonicalize() and export() 
respectively, would have been (dare I say it?) the pedantically 
correct way to go. But I agree with Mayank that this is too much. 
Dave Arnold, in a communication on this very topic, made the 
constructive suggestion that we simply make it explicit that 
canonicalize() in the case of a MN returns itself; this is on my 
list to add to the spec.  

--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: Michael Smith <[email-masked]>
Date: Thu, 08 Jul 1999 11:43:09 -0400

At 01:05 PM 7/6/99 -0400, "Linn, John" <[email-masked]> 
listed some outstanding issues about the Java-GSS binding:

>- means for locating mechanisms and/or implementations
>- means for supporting operations within multi-mechanism environments
>- issues about name types
>- approach for returning results
>- address representations

We might also add an item about how "free-standing" of other
Java packages the GSS binding should be -- in particular, does
the linkage with java.security.Provider etc., proposed by 
Jack and Mayank, buy us anything useful? (This is not a 
rhetorical question on my part -- I don't see it yet, but 
I'm open to persuasion.)  

--Michael Smith
  [email-masked]

---

From: [email-masked]
Date: Thu, 8 Jul 1999 10:04:10 -0700

1.  Provider Instantiation

Since java is used in several different environments (applet, 
application, servlet, ...) and since it is an evolving platform it is 
important to maintain flexibility in how providers may be instantiated.  
However, it is important to note that the interfaces are useless unless 
an implementation can be instantiated. Therefore it would help to publish 
several suggestions on how this MAY be done.  As the JAVA platform 
evolves these MAYs should turn into SHOULDs. This will provide guidance 
to implementors and users and provide a path for tighten up the 
specification based on real experience.  Both drafts provide a factory 
interface (GSSFactory in M&J and GSSImplementation in the TIA-CREF draft) 
which can be obtained manually to get implementations of the operational 
classes.  Where the two drafts on this topic is in how the recommend 
another method of instantiation.  

M&J recommend a GSSManager class that can "manage providers".  This seems 
to fit in well with the current direction of Java and it provides a user 
with a way to "discover" providers. I do not think the spec contains 
enough detail on how providers are stored as system properties. The JDK 
documentation describes how this is done with crypto providers not GSSAPI 
mechanisms.  It is also useful to note that the java.security packages 
are not available in all VM's (the current version of Netscape for 
example).  I think it is useful to try to reach a standard method of 
discovery and is a step in the right direction.  However, it will not be 
available on all platforms.

The TIA-CREF draft suggests a simple method of retrieving a class name 
from a system property.  While this is usable it does not solve the 
problem of having a way to "discover" providers.  An alternate approach 
would be to specify a specific well known system property, such as 
org.ietf.JGSS.GSSFactory, this does not however allow providers to be 
changed on the fly without knowing their name a priori.

2.  Multiple Mechanisms

The addition of the GSSContextHatchery in the TIA-CREF draft is 
confusing.  I'm not sure that it gains the programmer much benefit.  The 
provided code sample seems to be just as complex either way.

3.  Names

The subtleties of the naming issues are beyond me, but in RFC2078bis 
GSS_Export_Name behaves as in M&J's spec, if a name is not a mechanism 
name then the call may return a GSS_S_NAME_NOT_MN.  It is also possible 
for an implementation to export a non-Mechanism Name. The extra interface 
in TIA-CREF draft suggests that only MN's can be exported which is 
different than in RFC2078bis (2.4.15)

4.  Output Parameters

I don't have too strong of an opinion about this.  Almost all of the 
information in messageprop is not set by the user, it is returned to the 
user so I favor the GSSStatus return value approach.  I am also more 
aligned with reducing the number of classes (as opposed to interfaces) 
that are specified.  GSSStatus is an interface as it stands now.  
MessageProp is a class that must be instantiated by the user, this seems 
like an extra unnecessary step. 

5.  Channel Bindings

Personally I wish channel bindings just consisted of a byte array passed 
from the application (it could contain address if the application 
wishes), but since this isn't the case addresses need to be supported and 
this should follow 5.11 (although Java may not support other address 
types, the peer may not be written in java).  However, I would rather not 
see something as loosely typed as an array of objects.  This opens up too 
many possibilities for application and mechanism developers to do 
something wacko, causing interoperability problems.  It would be better 
to provide a means to construct channel bindings. Three construction 
methods: (Inetaddress, InetAddress, byte[]), (int, byte[], int, byte[], 
byte[]) and (byte[]).  The channel bindings class will also need ways to 
access the stored address as type/address pairs.  

I think the M&J draft is further along than the  TIA-CREF draft and is 
pretty close to ready. The major area I think it needs is in the provider 
specification (At the very leat a reference to the JDK would help).  
Changes to the output parameters and Channel bindings seem reasonable. 

-Joe

---

From: [email-masked] (Ming Yung)
Date: Fri, 9 Jul 1999 18:15:40 +1000 (EST)

Hi all,

Just a few comments on Jack & Mayank's draft Java GSSAPI bindings, from
someone responsible for an actual implemention of it (version 00 thereof).

1. We, at the DSTC, decided to put a GSSAPI interface to a pure Java Kerberos
   library we had written. At the time there was only Jack's draft. We had
   certain reservations, mainly to do with the impossibility of having
   application source-level portability (let alone binary) because package
   names were left unspecified in that draft. Still, we went ahead with it,
   confident it would be fixed sooner or later. Most of the coding was done 
   by a summer student, Anthony Ho, who started out with us with neither 
   Java nor security expertise. What is currently available of this 
   implementation at

     http://security.dstc.edu.au/projects/java/release4.html

   is basically what was achieved in a 6 week time period.

2. It is pleasing for me to see that the latest draft does actually address
   the problem of binary-level portability. There is some concern in this
   working group that introducing the Java Provider mechanism is adding too
   much baggage. I share some of these concerns. But _only_ in the context of
   applets run in browsers.

   Our toolkit, JCSI, implements crypto algorithms and certificate classes
   to be used in the Provider framework. It also implements secure protocols
   which use this framework to locate and instantiate these classes (or
   third-party classes). It is a small step (and a logical one, I think) to
   then use it for applications to locate and instantiate implementations of
   secure protocols, such as is currently proposed.

   On the subject of applets run in browsers, I note that it is possible to
   bypass the Provider mechanism, by not implementing all the classes, and
   still get all the functionality of the GSSAPI. This seems to answer
   my reservation above.

Thanks,
Ming Yung,
DSTC