Hi all,
The core rxgk document (which just had a last call period) has a normative
reference to RFC 4402 for the PRF+ construction, which is an algorithm to
get variable-length pseudo-random bytestrings from the RFC 3961 enctype's
pseudo_random() function. The construction is basically just to invoke
the underlying pseudo_random() function in counter mode.
However, there is an erratum [1] filed against RFC 4402, which notes that
the implementors of that specification for krb5 gss_pseudo_random()
started the counter at 0, even though the text of RFC 4402 mandates that
the counter start at 1.
Because of this ambiguity about what value the counter starts at, in order
to ensure interoperability of rxgk implementations, we should note/clarify
what behavior rxgk expects. It's probably easiest to do this by noting
directly in the document, i.e., issue a new I-D with just this change.
It's my understanding that if we have agreement on the list for the
clarification, no additional last call period is necessary.
It doesn't really matter whether rxgk starts at 0 or 1, it's just an
arbitrary choice and we have to pick one to ensure interoperability.
There's some argument for starting at 0, in that we'll be doing the same
thing as krb5. However, the krb5 libraries only export the RFC 4402
functionality as the gss routine, which requires a GSS security context in
order to be called. Thus, rxgk implementations would not be able to
easily share code with krb5 implementations for this matter. I have an
implementation of this PRF+ in OpenAFS gerrit for review; it's about 70
lines of code. The argument for starting at 1 is that we're citing RFC
4402 for the construction, and the actual text of RFC 4402 is to start at
1. Entries in the RFC series should never change, so citing RFC 4402 as a
normative reference means just that -- use the text that is there, not
some edited version from an erratum.
Does anyone have an opinion that might sway us to one side or the other?
-Ben
[1] http://www.rfc-editor.org/errata_search.php?rfc=4402
_______________________________________________
AFS3-standardization mailing list
[email protected]
http://lists.openafs.org/mailman/listinfo/afs3-standardization
