Subject: [BEHAVE] Re: AD comments on draft-ietf-behave-rfc3489bis-10

From: Jonathan Rosenberg <[email-masked]>
Date: Thu, 11 Oct 2007 17:34:58 -0400

Thanks for the review Magnus. I've updated the document based on yor 
comments. Responses below.

Magnus Westerlund wrote:
> Hi,
> 
> I have performed a combined AD-review / shepherding review and have some
> comments. I think some of these will require an updated version before
> proceeding. I hope this can be accomplished quickly to avoid to much delay.
> 
> 
> 1. Section 7.2.1:
> It is not obvious why the number 7900 ms is the end of listening for
> responses. How did one arrive on that number?

Well, its basically the same value we had from rfc3489. But its a 
reasonable number. The final request is sent at 6300ms, so this gives us 
1.6 seconds to wait for a response to that before giving up. In case 
this last packet does get through, we want to wait at least as long as a 
big RTT; 1.6 seconds provides lots of margin.

I added the note in parens to the following text:

    <t>Retransmissions continue until a response is received, or until
    a total of 7 requests have been sent.  If, after the last request,
    a duration equal to 16 times the RTO has passed without a response
    (providing ample time to get a response if only this final request
    actually succeeds),

> 
> 2. Section 12.2:
> "   A STUN server can detect when a given Binding Request message was
>    sent from an RFC 3489 [RFC3489] client by the absence of the correct
>    value in the Magic Cookie field.  When the server detects an RFC 3489
>    client, it SHOULD copy the value seen in the Magic Cookie field in
>    the Binding Request to the Magic Cookie field in the Binding Response
>    message, and insert a MAPPED-ADDRESS attribute instead of an XOR-
>    MAPPED-ADDRESS attribute."
> 
> I think this text should have some warning about what functionality
> issues regarding MUXing STUN with other protocols may have due to this
> backwards compatibility issue. If I understand things correctly, having
> 3489 compatibility means that demuxer only can use the two first bits
> and two last of the first word to separate STUN from normal data packets?

Per the rest of this thread, I added your proposed text verbatim to this 
section.

> 
> 3. Section 14.4:
> 
> "   The key used as input to HMAC is the password."
> 
> Section 10.2:
> 
>    "For STUN servers used in conjunction with SIP servers, it is
>    desirable to use the same credentials for authentication to the SIP
>    server and STUN server.  Typically, SIP systems utilizing SIP's
>    digest authentication mechanism do not actually store the password in
>    the database.  Rather, they store a value called H(A1), which is
>    computed as:
> 
>                 H(A1) = MD5(username ":" realm ":" password)
> 
>    If a system wishes to utilize this credential, the STUN password
>    would be computed by taking the user-entered username and password,
>    and using H(A1) as the STUN password.  It is RECOMMENDED that clients
>    utilize this construction for the STUN password."
> 
> Isn't these two in contradiction. In addition aren't they a potential
> for interoperability issues between client and server. This as the
> actual key used in the HMAC must be the same to allow correct integrity
> verification. So, how is it inteded to work? Is it something the usage
> needs to define?

I had intended that it each deployment could make a decision on this one 
way or another. But upon further consideration I agree this is a recipe 
for interop problems. Even if its not SIP there is no reason why you 
cannot use the H(A1) as the stun password. I've aligned the text around 
this, and moved the rules on computing the HMAC using H(A1) into the 
section on hmac computation itself, so that it is mandatory.

> 
> 4. Section 15.1.2:
> 
> "  A rogue client may use a STUN server as a reflector, sending it
>    requests with a falsified source IP address and port.  In such a
>    case, the response would be delivered to that source IP and port.
>    There is no amplification with this attack, and it is mitigated by
>    ingress source address filtering."
> 
> I think there is missing a clarification on what type of amplication
> that is not possible with STUN. To my understanding there can't be any
> packet rate amplification in this attack. However some percent of packet
> size amplification seems possible due to NONCE and other error
> indication added by the server. Maybe a clarification that there is no
> amplification in the number of packets is warrented.

Text now reads:

	  <t>
	    A rogue client may use a STUN server as a reflector,
	    sending it requests with a falsified source IP address and
	    port. In such a case, the response would be delivered to
	    that source IP and port. There is no amplification of the
	    number of packets with this attack (the STUN server sends
	    one packet for each packet sent by the client), though
	    there is a small increase in the amount of data, since
	    STUN responses are typically larger than requests. This
	    attack is mitigated by ingress source address filtering.  </t>

> 
> 5. Section 15.2:
> 
> "   Most of the attacks in this section revolve around an attacker
>    modifying the reflexive address learned by a STUN client through a
>    Binding Request/Binding Response transaction.  Since the usage of the
>    reflexive address is a function of the usage, the applicability and
>    remediation of these attacks is usage-specific.  In common
>    situations, modification of the reflexive address by an on-path
>    attacker is easy to do.  Consider, for example, the common situation
>    where STUN is run directly over UDP.  In this case, an on-path
>    attacker can modify the source IP address of the Binding Request
>    before it arrives at the STUN server.  The STUN server will then
>    return this IP address in the XOR-MAPPED-ADDRESS attribute to the
>    client.  Protecting against this attack by using a message-integrity
>    check is impossible, since a message-integrity value cannot cover the
>    source IP address, since the intervening NAT must be able to modify
>    this value.  Instead, one solution to preventing the attacks listed
>    below is for the client to verify the reflexive address learned, as
>    is done in ICE [I-D.ietf-mmusic-ice].  Other usages may use other
>    means to prevent these attacks."
> 
> I think there are a serious thinking error that affects most of the
> attack variants in this description. If on on-path attacker changes the
> source IP-address of the packet the packet will not be routed back to
> the client issuing the request. Thus they are looking like lost packets.
> To me the only attack being really viable is if the attacker changes the
> source address to itself and then forwards the packet to the client
> (target of the attack). This is of course assuming that the attacker is
> not sitting very closely to the server and can see all/most traffic to
> and from the server?

Actually thats exactly the assumption; you can rewrite the source IP to 
point to anyone that you'd naturally be on-path for a message from the 
STUN server to that IP. As you say, this is more valuable when the 
attacker is closest to the server, less so as it gets closer to the 
client. I could swear there was text on this somewhere at some point but 
its clearly not here now. I will mention this and then discuss how that 
limitation applies more in 15.2.1 and 15.2.2.

> 
> Can we be a bit clearer on when the attacks are possible. Thus I think
> that 15.2.1 and 15.2.2 are more difficult to achieve (assuming integrity
> checks between client and server) than 15.2.3 and 15.2.4.
> 
> 6. Section 15.3:
> 
> "   This specification uses SHA-1 for computation of the message
>    integrity. "
> 
> Shouldn't there be a HMAC before SHA-1 here?

Fixed.

Thanks,
Jonathan R.

-- 
Jonathan D. Rosenberg, Ph.D.                   600 Lanidex Plaza
Cisco Fellow                                   Parsippany, NJ 07054-2711
Cisco Systems
[email-masked]                              FAX:   (973) 952-5050
http://www.jdrosen.net                         PHONE: (973) 952-5000
http://www.cisco.com

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