Re: PRF comments

[Nicolas Williams <[e-mail]>]

On Thu, Jun 23, 2005 at 04:40:34PM -0400, Ken Raeburn wrote:
> Going over the -04 drafts today, I was struck by a few things:
> 
> draft-ietf-kitten-gssapi-prf-04.txt:
> 
>    Mechanisms MUST be able to consume all the provided prf_in input data
>    that is 2^14 or fewer octets.
> 
>    If a mechanism cannot consume as much input data as provided by the
>    caller, then GSS_Pseudo_random() MUST return GSS_S_FAILURE.
> 
> We should probably add explicitly: "Mechanism PRF specifications may
> not truncate the supplied input data."

I thought that "[m]echanisms MUST be able to consume all the provided
prf_in..." meant exactly that.

How could it mean otherwise?

>    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.
> 
> This makes "mechanism spec said to output only X bytes"
> indistinguishable from "out of resources".  If the output is being

Ah.

> used as protocol keying material or something comparable, then the
> exchange may eventually fail because one side generated less data than
> the other.
> 
> I'd suggest either this should fail, or return some magic error code
> that means "truncated output" and we provide some way to resume where
> it left off.  (Probably the former, though that may mean that
> small-memory systems simply cannot satisfy some requests.)

We have GSS_S_UNAVAILABLE.  So return that and still output prf_out.

> In fact, it's probably worth explicitly stating that the mechanism
> definitions must indicate what the only correct output length is, for
> a given input.

How would they?

>    Additional major status codes for the C-bindings:
> 
>    o  GSS_S_CALL_INACCESSIBLE_READ
> 
>    o  GSS_S_CALL_INACCESSIBLE_WRITE
> 
>    See [RFC2744].
> 
> These status codes are very poorly described in RFC 2744, and are not
> explicitly noted as status returns for any functions in RFC 2744, so I
> don't think they need to be called out specially here.  And why would
> they be "additional" major status codes?

RFC2743 doesn't define them -- they are an artifact of the C bindings,
needed to indicate calling errors where the caller passed in a NULL
pointer where a non-NULL pointer to a basic GSS type variable was
needed.

> I'm not sure when they could come up, anyways, unless you're checking
> memory mappings for validity of the supplied pointers.  It looks like
> the MIT code never returns them.

See above.  Solaris' libgss returns those errors as described above.

>    For Java GSS_Pseudo_random() maps to a GSSContext method, 'prf':
> 
> I'm not familiar with Java interface definitions.  Is it considered
> okay to simply add a new method to a standardized interface?

Seema, can you look at this?

> Add a comma after "Java".
> 
>    Callers of GSS_Pseudo_random() should avoid accidentally calling it
>    with the same inputs.
> 
> "... for different purposes [or uses]."  There are certainly cases
> where you'd want different calls to use the same inputs, and not by
> accident.

Right, but since those wouldn't be accidents I think no change is
needed.

>    presence of short cycles, etc), you limit the amount of the PRF
>    output used to the necessary minimum.
> 
> I think "minimum necessary" sounds better.  "Necessary minimum" sounds
> to me like it is necessary that a minimum exists, whereas we want the
> minimum amount of output that is necessary.  (I.e., "minimum" and
> "necessary" modify "amount"; "necessary" doesn't modify "minimum".)

Sure.

> 
> draft-ietf-kitten-krb5-gssapi-prf-04.txt:
> 
> Section 2, move [RFC3961] up to the first paragraph where the PRF
> function is first mentioned.  Should the [RFC1964] reference be
> updated to CFX?

Er, yes, now that CFX is at Proposed Standard.

>    The computational cost of computing this PRF+ may vary depending on
>    the Kerberos V encryption types being used, but generally the
>    computation of this PRF+ gets more expensive as the input and output
>    [...]
> 
> With some rewording ("a mechanism that uses a PRF+ construction...",
> or just "for many PRF constructions..."), this would be appropriate
> for draft-ietf-kitten-gssapi-prf instead.

Well, I suppose.  If one mechanism may have a PRF that gets slower the
longer the inputs and required outputs then so may others, and that's
worth warning about, so:

   For some mechanisms the computational cost of computing
   GSS_Pseudo_random() may increase exponentially 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.

Nico
-- 

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