Subject: Re: Java Bindings do not need to be removed was Re: Proposed PRF changes to address Ken's comments

From: Seema Malkani <[email-masked]>
Date: Fri, 01 Jul 2005 15:05:55 -0700

Hello... back from JavaOne.

I would like to clarify few things here:

1) JCP Process
   When RFC 2853 was published, we went through Sun's JCP process for the
   Java GSS bindings before providing an implementation in the JDK.
   Any updates to the Java GSS Bindings would also need to go though
   the JCP process. Here is the JSR on the Java GSS bindings:
   http://www.jcp.org/en/jsr/detail?id=72

2) Other GSS extensions
   Address all the other GSS extensions before submitting any updates to 
the
   Java GSS API. In addition ensure any update made to Java GSS API does 
not
   break backward compatibility.

As for the PRF extension, we can consider extending the GSSContext 
Interface and add PRF to the new interface. For e.g.
   public interface GSSContextExt extends GSSContext {
         public byte[] prf(...);
   }

I would prefer to address all the GSS extensions for Java GSS bindings 
in a separate draft.

Seema

Jeffrey Altman wrote:

>Seema Malkani wrote:
>
>  
>
>>To answer Ken's question :
>>
>>Adding a new method to a standardized interface will break existing
>>applications. This means all classes that implement GSSContext interface
>>will now need to add the new method. All implementations of Java GSS
>>will NOT compile until the new method is added.
>>
>>Abstract classes don't have such a problem, since you can provide a
>>default (possibly empty) implementation, and existing implementations
>>will not break. It is easier to evolve an abstract class than to evolve
>>an interface. Since GSSContext was defined to be an interface, we cannot
>>change it.
>>
>>Alternatives ?
>>
>>We can possibly add the new method to GSSManager class, which is an
>>abstract class. This class serves as a factory for three GSS interfaces:
>>GSSName, GSSCredential, and GSSContext. The new method will have to be
>>invoked after the GSSContext has been established.
>>
>>GSSManager class:
>>public byte[] prf(GSSContext context, int prf_key, byte[] inBuf, int
>>outlen)
>>        throws GSSException
>>
>>GSSManager mgr = GSSManager.getInstance();
>>GSSName targetName = mgt.createName("service@host", ..);
>>GSSContext context = mgr.createContext(targetName, ..);
>>..
>>if (context.isEstablished()) {
>>  // define PRF key, input..
>>  int prf_key = ..
>>  ..
>>  byte[] prf_out = mgr.prf(context, prf_key, inBuf, outlen);
>>}
>>
>>Seema
>>    
>>
>
>I have given this subject much consideration.   I believe that the
>issues relating to Java and C# are no different than the issues related
>to the C binding.   What this document does is specify an
>"implementation specific extension" to GSS API version 2 update 1.
>As such, it is not going to be possible for a given application to be
>able to expect that this functionality exists without some
>implementation specific knowledge that it is there.  Simply knowing that
>we are using GSS API will not be enough.
>
>I do not believe it is appropriate for this document (or any other
>document specifying an extension to GSSAPI v2 u1 that Kitten publishes
>before GSSAPI v3) to describe the tools necessary for a caller to
>determine whether or not the function/method is implemented by a given
>implementation.   The mistake that the document makes is by specifying
>that the method belongs to the "GSSContext" interface.   It is perfectly
> reasonable for a Java class that implements the GSSContext interface to
>provide the prf() method even if it is not part of the GSSContext
>interface.  An application that expects to use the prf() prior to the
>availability of a GSSv3Context interface will need to obtain the
>GSSContext reference, use introspection on the resulting class to search
>for the method, and if it is found, use a class reference to access the
>method.
>
>I believe that adding this method to the GSSManager class would violate
>the abstraction model.  prf is the first of many extensions this working
>group will be proposing.  Continuously adding new methods to GSSManager
>would result in a class definition that is constantly in a state of flux
>without providing any real benefit.
>
>Jeffrey Altman
>
>
>  
>
>------------------------------------------------------------------------
>
>_______________________________________________
>Kitten mailing list
>[email-masked]
>https://www1.ietf.org/mailman/listinfo/kitten
>  
>

_______________________________________________
Kitten mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/kitten

---

From: Jeffrey Altman <[email-masked]>
Date: Fri, 01 Jul 2005 18:28:26 -0400

>   http://www.jcp.org/en/jsr/detail?id=72

IETF Standards Track documents are developed within the IETF and IETF
processes.  By working with IETF to develop a standards track
specification for JGSS, Sun has given up the right to utilize the JCP.

> 2) Other GSS extensions
>   Address all the other GSS extensions before submitting any updates to the
>   Java GSS API. In addition ensure any update made to Java GSS API does not

As I stated in my e-mail, this document does not specify the inclusion
of the prf() method in any standard "interface".  It would be
inappropriate to include prf() in "GSSContextExt" because we would then
have "GSSContextExtExt" when the next new method is defined.
Implementors are free to implement prf() as part of their implementation
specific classes that also implement the GSSContext interface.  A new
interface should not be published until the GSSv3 spec is complete.

Jeffrey Altman

---

From: Nicolas Williams <[email-masked]>
Date: Fri, 1 Jul 2005 17:34:56 -0500

> interface should not be published until the GSSv3 spec is complete.

I agree -- and I think Seema meant that we should hold off on designing
new such Java interfaces until we get to the GSS-APIv3.

---

From: Jeffrey Altman <[email-masked]>
Date: Fri, 01 Jul 2005 18:50:49 -0400

> new such Java interfaces until we get to the GSS-APIv3.

Then we have consensus.  :)

---

From: Sam Hartman <[email-masked]>
Date: Mon, 11 Jul 2005 14:37:49 -0400

>>>>> "Jeffrey" == Jeffrey Altman <[email-masked]> writes:

    Jeffrey> Seema Malkani wrote:
    >> 1) JCP Process When RFC 2853 was published, we went through
    >> Sun's JCP process for the Java GSS bindings before providing an
    >> implementation in the JDK.  Any updates to the Java GSS
    >> Bindings would also need to go though the JCP process. Here is
    >> the JSR on the Java GSS bindings:

    Jeffrey> IETF Standards Track documents are developed within the
    Jeffrey> IETF and IETF processes.  

True.

    Jeffrey> By working with IETF to develop
    Jeffrey> a standards track specification for JGSS, Sun has given
    Jeffrey> up the right to utilize the JCP.

I don't think that follows at all.  I think that if Sun chooses to
continue working within the IETF to standardize Java GSS bindings then
Sun should plan to implement the results of IETF standards.

If that isn't going to work for Sun, then perhaps it is inappropriate
for this working group to standardize Java bindings for GSS
extensions.  Instead, we can standardize the abstract APIs.  Sun can
go through whatever process they choose to define Java bindings.  I'd
recommend that if Sun chooses that route they publish informational
RFCs notifying the IETF community what Java extensions they
standardize.

My hope is that Sun will find a way of working within the IETF process
to standardize Java GSS extensions.  However we need Sun's input on
this issue rather soon in order to know what to do with the current
draft.

Sam Hartman
Security Area Director

---

From: Seema Malkani <[email-masked]>
Date: Mon, 18 Jul 2005 11:17:40 -0700

>RFCs notifying the IETF community what Java extensions they
Java GSS was standardized at IETF in RFC 2853, and was also submitted to
the JCP in JSR 072.

Java GSS-API extensions would need to be standardized at IETF. In
addition, we would also need to go through the JCP process.

Seema

---

From: Jeffrey Altman <[email-masked]>
Date: Mon, 18 Jul 2005 15:25:11 -0400

>>this issue rather soon in order to know what to do with the current

There is nothing wrong with Sun and the Java Community using the JCP as
a means of obtaining additional review as part of the process of
submitting comments to this working group on its drafts.   Where there
is a potential conflict is if the working group comes to consensus on
decisions and after that consensus is reached the JCP produces
a conflicting decision.

>From my perspective as a working group chair, if the JCP is going to be
used, the participants in the JCP really should be active participants
in this forum.  Otherwise, there is tremendous potential for conflict.
It is acceptable for the JCP to rubberstamp the work of the IETF, it is
not acceptable for the IETF to rubberstamp the work of the JCP.

Jeffrey Altman

---

From: Sam Hartman <[email-masked]>
Date: Tue, 19 Jul 2005 13:37:13 -0400

>>>>> "Seema" == Seema Malkani <[email-masked]> writes:

    Seema> Java GSS-API extensions would need to be standardized at
    Seema> IETF. In addition, we would also need to go through the JCP
    Seema> process.

I'm not sure this is possible given current organizational
infrastructure.  What happens if the IETF approves a standard but JCP
does not?  The IETF has done joint work with other SDOs in the past,
but we are not set up to do that here and I'm not sure if the IAB and
IESG would approve such a relationship for kitten.  If that's the
route kitten wants to go we can certainly try it out and see what
happens.