PRF comments

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

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

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.

   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?

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.

   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?

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.

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

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?

   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.

Ken

_______________________________________________
Kitten mailing list
Kitten@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/kitten