Proposal for New Section 11.1 PRNG

[Chris Lonvick <clonvick%cisco.com@localhost>]

Hi Everyone,

I'd like to suggest the following as a new section to call out the
importance of the PRNG to this effort.  Essentially the first paragraph of
the Replay section was removed from there to form this new section.  I'm
thinking it should just be a new Section 11.1 and then everything that had
been 11.1 (Transport) and below just move downwards.  Your comments on
this are requested.

Thanks,
Chris

===========================================================================

11.1 PRNG

   This protocol binds each session key to the session by including
   random data that is specific to the session in the hash used to
   produce session keys.  If the random data here (e.g., DH parameters)
   are pseudo-random then the PRNG should be cryptographically secure
   (i.e., its next output not easily guessed even when knowing all
   previous outputs) and, furthermore, the PRNG should be seeded with
   some truly random inputs, or as random as can be available.  RFC 1750
   [1750] contains more discussion on this and suggestions for
   randomness.  Implementors should note well the importance of truly
   random values where needed in this document.  They should also heed
   the well-meant, anecdotal warning that implementing PRNG functions are
   difficult to get right.

   The amount of entropy available to a given client or server sometimes
   may be less than what is needed to run the protocol.  In this case
   one must either resort to PRNGs anyways or refuse to run the protocol.
   In practice implementors will generally rely on some PRNG.

[1750] Eastlake, D., Crocker, S. and J. Schiller, "Randomness
       Recommendations for Security", RFC 1750, December 1994.