[reSIProcate] Re: updates to stun code

[Cullen Jennings]

That is nice - it would be great if this work could be put back into  
the STUN stuff in resiprocate. The stuff we are mucking with right  
now really was about how the STUN state machine got mixed into  
resiprocate while much of this has to do with the actually stun  
functionality - I doubt there will be huge merge conflicts but would  
be nice to get this back in


On Jun 8, 2006, at 2:05 PM, Bruce Lowekamp wrote:

> 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