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

From: Magnus Westerlund <[email-masked]>
Date: Mon, 17 Sep 2007 11:55:01 +0200

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?

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?

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?

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.

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?

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?

Cheers

Magnus Westerlund

IETF Transport Area Director & TSVWG Chair
----------------------------------------------------------------------
Multimedia Technologies, Ericsson Research EAB/TVM/M
----------------------------------------------------------------------
Ericsson AB                | Phone +46 8 4048287
Torshamsgatan 23           | Fax   +46 8 7575550
S-164 80 Stockholm, Sweden | mailto: [email-masked]
----------------------------------------------------------------------

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

---

From: "Dan Wing" <[email-masked]>
Date: Mon, 17 Sep 2007 12:49:44 -0700

> -----Original Message-----
> From: Magnus Westerlund [mailto:[email-masked]] 
> Sent: Monday, September 17, 2007 2:55 AM
> To: [email-masked]; Behave WG
> Subject: [BEHAVE] AD comments on draft-ietf-behave-rfc3489bis-10
> 
> Hi,
> 

(Writing as an individual:)

RFC3489 doesn't do multiplexing -- multiplexing of STUN with other
protocols was introduced with RFC3489bis (not RFC3489).

Should we make a note of how this is not a problem, though?  Perhaps
something along the lines of:

  "Note:  Backwards compatibility with RFC3489 does not affect 
   multiplexing of STUN with other protocols (e.g., [ICE], 
   [SIP-OUTBOUND]), because such multiplexing was not available
   in RFC3489."

-d

---

From: Magnus Westerlund <[email-masked]>
Date: Tue, 18 Sep 2007 10:23:21 +0200

>    [SIP-OUTBOUND]), because such multiplexing was not available

Well, is that really obvious so that not anyone which have an 3489
implementation will try to apply it to a multiplexed case. I think
having a warning in this section which explains both why 3489 should not
be used, and therefore it really is not a problem.

"The RFC 3489 version of STUN lacks both the Magic Cookie and the
FINGERPRINT attribute that allows for a very high probablility of
correctly identifying STUN messages when multiplexed with other
protocols. Therefore, STUN implementations that are backwards compatible
with RFC 3489 SHOULD NOT be used in cases where STUN will be multiplexed
with another protocol. However, that should not be an issues as such
multiplexing was not available in RFC 3489."

Cheers

Magnus Westerlund