kern/46305: RFC6056 implementation looks incorrect

[gson%gson.org@localhost (Andreas Gustafsson)]

>Number:         46305
>Category:       kern
>Synopsis:       RFC6056 implementation looks incorrect
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    kern-bug-people
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Fri Apr 06 19:20:01 +0000 2012
>Originator:     Andreas Gustafsson
>Release:        NetBSD-current
>Organization:
>Environment:
System: NetBSD
Architecture: i386
Machine: i386
>Description:

On March 15, I fixed a random kernel memory corruption issue caused by
a bug in src/sys/netinet/rfc6056.c.  While reading the code looking
for that bug, I noticed that it also appears to have another bug; that
other bug is the subject of this PR.

In RFC6056 section 3.3.4, the description of Algorithm 4 specifies the
use of two cryptographic hash functions F() and G() that use secret
keys secret_key1 and scret_key2 as part of their respective inputs:

  offset = F(local_IP, remote_IP, remote_port, secret_key1);
  index = G(local_IP, remote_IP, remote_port, secret_key2);

The implementation of Algorithm 4 in rfc6056.c is in the function
algo_doublehash().  From my reading of the code, it appears that the
hashes it calculates do not in fact include a secret key, but rather a
random number that is different for each call to algo_doublehash().

This is equivalent to changing the secret keys with every call to
algo_doublehash().  As discussed in RFC6056 section 3.4, changing the
secret keys can cause port collisions and should only be done "with
consideration" at carefully chosen points in time, such as at boot
time.  If the keys are changed with every call, the algorithm
effectively degrades to choosing the port number completely at random.

The algo_hash() function also appears to have the same problem.

>How-To-Repeat:

>Fix: