[AFS3-std] rxgk and the RFC 4402 PRF+ function

Benjamin Kaduk kaduk@MIT.EDU
Wed, 19 Feb 2014 16:23:36 -0500 (EST)


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