Subject: [BEHAVE] TURN security issue

From: Brian Hibbard <[email-masked]>
Date: Fri, 23 Feb 2007 15:25:21 -0600

Should the STUN Relay Usage specify that NONCE is required for all  
Allocate Requests, regardless of whether they are "signed" with short- 
term credentials or long-term credentials?

I brought this to the BEHAVE list  a while ago as an issue to  
possibly be addressed in the draft 3489bis, but Jonathan pointed out  
that NOT using NONCE with short-term credentials is not necessarily a  
vulnerability in every usage.  One consequence of not using a NONCE  
where short-term credentials are used is that a patient attacker  
could replay valid Allocate Requests for the lifetime of the short- 
term secret that was used to "sign" the replayed request.   This mode  
of attack could continue for as long as the client requests new  
credentials and subsequently sends new Allocate Requests.

For convenience, this the relevant text from sec 9.1.1 (page 25) of  
draft-rfc3489bis-05:

    When an error response is to be generated by the server as a
    consequence of authentication problems (error codes 401, 432, 434,
    435, 430 and 436, and the REALM is present in the response
    (signifying the usage of a long term credential), the server MUST
    include a NONCE attribute in the response.  The nonce includes a
    random value that the server wishes the client to reflect back in a
    subsequent request (and therefore include in the message integrity
    computation).  When the REALM is absent in the response, the server
    MAY include a NONCE in the response if it wishes to use nonces along
    with short-term shared secrets (with the exception of 435, where
    NONCE is mandatory even for short term credentials).  However, there
    is little reason to do so, since the short-term password is, by
    definition, short-term, and thus additional temporal scoping through
    the nonce is not needed.

For STUN Relay Usage, the "... MAY include a NONCE ..." should  
probably be "... SHOULD ..." or "...MUST..." ---at least for Allocate  
Requests.

_______________________________________________
Behave mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/behave