[reSIProcate] updates to stun code
This past semester Tiffany Broadbent did some work using STUN
(starting with 0.96 from Vovida/sourceforge) for her MS project, and a
major part of that was trying to incorporate some of the new features
in 3489bis into the code. We had hoped to finish the changes, but
haven't been able to make progress on it recently, and since I
understand people are now looking at how to improve the STUN support
in resip, I thought I should post this here, since it's an evolution
of the same code that's in resip. (we didn't try to reintegrate it
into resip, though, so it's probably not a drop-in).
Here is a list of changes. Many are of more interest to people trying
to run stun stand-alone, but quite a few should be interesting to
resip, as well:
1) Test program for STUN client and server
-stuntest.cxx, can run either client or server depending on the
command line flags set
2) Clearer client output
-now prints:
./stuntest -c 1.1.1.2 -i 192.168.0.2
STUN client version 0.96
Primary: Independent Mapping, Independent Filter, random port, will hairpin
Return value is 0x000002
-----MAPPED ADDRESS-------
1.1.1.1:60103
3) TLS support
-added a TLS client that reads in openssl certificates and keys and
creates a connection to a known TLS server, assumed to be running on
the same IP address as the UDP STUN server.
-all TLS client/server functionality is moved to tlsConnection.cxx
and included in the stun files
4) Shared Secret Request support
-with TLS connectivity valid Shared Secret messages can be constructed
-username and password needed for the MESSAGE-INTEGRITY attribute can
now be created
-TLS server sets an expiration timer of 30 minutes on each
username-password pair
-credentials are added to and checked by a list maintained by the server
-*NOTE the keys for the hash used to generate parts of the username
and password are still hardcoded
5) Message Integrity support
-the MESSAGE-INTEGRITY can now be correctly constructed using the
username and password generated from the Shared Secret Request
-the hash of the message is compared to the MESSAGE-INTEGRITY
attribute and, if invalid, is dropped
6) Error message handling
-Error messages are sent and displayed and responded to more thoroughly
-messages related to usernames and passwords prompt a regeneration of
the username and password and a retransmission of the request; all
other error messages end the client session and return control to the
user so they may remedy the error
7) Client security
-client tracks outstanding messages via their transaction IDs and if
an incoming message's transaction ID does not match one in the
client's list of outstanding IDs it is dropped
8) Revised RFC compatibility
-added the NONCE, REALM, and ALTERNATE-SERVER attributes
- added the "magic cookie" value
-the first two bytes of a message are set to 0b00 to identify it as
compatible with the revised guidelines
I believe that NONCE and REALM are included, but their functionality
isn't implemented.
The code is currently at:
http://www.cs.wm.edu/~lowekamp/tmp/stunWM.zip
It will be there for awhile, at least until the features are available
from somewhere else.
All modifications are provided under the same Vovida license as the original.
Bruce