Subject: Proposed PRF changes to address Ken's comments

From: Nicolas Williams <[email-masked]>
Date: Fri, 24 Jun 2005 23:00:59 -0500

I propose the following changes to the PRF I-Ds to address Ken's
comments:

 - Change the reference to the Kerberos V mechanism to be a reference to
   the CFX I-D, rather than a reference to RFC1964.

 - Add the following to the Security Considerations of the base PRF I-D:

   For some mechanisms the computational cost of computing
   GSS_Pseudo_random() may increase significantly as the length of the
   prf_in data and/or the desired_output_length increase.  This means
   that if an application can be tricked into providing very large input
   octet strings and requesting very long output octet strings then that
   may constitute a denial of service attack on the application;
   therefore applications SHOULD place appropriate limits on the size of
   any input octet strings received from their peers without integrity
   protection.

 - In the base PRF I-D change:

-   If the implementation cannot produce the desired output due to lack
-   of resources then it MUST output what it can and still return
-   GSS_S_COMPLETE.

   to

+   If the implementation cannot produce the desired output due to lack
+   of resources then it MUST return GSS_S_FAILURE and MUST set a
+   suitable minor status code.

 - I see no value in saying anything more about minor_status.  I think
   RFCs 2743 and 2744, normative references that they are, should answer
   (or not) any questions about it.

 - I await a reply from Seema about Ken's Java bindings question.

Comments?

Nico
-- 

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

---

From: Seema Malkani <[email-masked]>
Date: Sun, 26 Jun 2005 10:42:26 -0700

> - I await a reply from Seema about Ken's Java bindings question.
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

---

From: Jeffrey Altman <[email-masked]>
Date: Mon, 27 Jun 2005 11:33:48 -0400

>   byte[] prf_out = mgr.prf(context, prf_key, inBuf, outlen);

Seema:

This will definitely be a much more generic issue for Java GSS support
than just the PRF.  There are a number of new methods that the work of
this group will require moving forward.   Adding them all to the
GSSManager class seems like an inappropriate thing to do.  Even if we
hold off defining a Java binding for PRF and wait for the majority of
this group's work to complete, we will still be faced with this issue.
I think we need to address the question of extensibility for the Java
bindings.   It would be unfortunate if everytime new GSS functionality
was defined the interfaces implementing one or more of the classes had
to be replaced.

Jeffrey Altman

---

From: Nicolas Williams <[email-masked]>
Date: Mon, 27 Jun 2005 13:50:47 -0500

> was defined the interfaces implementing one or more of the classes had

I propose removing the Java bindings from the PRF I-D and resolving this
problem separately.  No, I don't like this proposal, but it's either
that or wait to resolve the Java bindings extensibility issue first.

Nico
--

---

From: Jeffrey Altman <[email-masked]>
Date: Mon, 27 Jun 2005 15:24:09 -0400

> that or wait to resolve the Java bindings extensibility issue first.

Can someone speak to the question of whether or not C# is going to have
similar issues?

Jeffrey Altman

---

From: Jeffrey Altman <[email-masked]>
Date: Wed, 29 Jun 2005 19:58:25 -0400

>   byte[] prf_out = mgr.prf(context, prf_key, inBuf, outlen);

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

---

From: Nicolas Williams <[email-masked]>
Date: Thu, 30 Jun 2005 18:55:12 -0500

> without providing any real benefit.

I agree.  Thanks.  I'll make the necessary edits and resubmit.

Nico
--