Subject: [MMUSIC] A proposal for comedia-06 security section

From: David Yon <[email-masked]>
Date: Fri, 14 Mar 2003 22:28:20 -0500

I've run a number of scenarios for the connection-hijack concern raised in 
comedia-fix, modeling the possible levels of connectivity between Alice, 
Bob, and Carol.  I believe that in every scenario except for one, this can 
be downgraded from a hijacking concern to a DoS concern.  I have PowerPoint 
prepared for Monday, but here is the discussion laid out in detail.

The backdrop is that Bob is assumed to follow the rules in section 4.4 (b) 
and (c), which means that a connection originating from Carol does *not* 
prevent Bob from attempting a connection.  This argues for 4.4 to be 
upgraded from RECOMMENDED to MUST.

Something not clarified in comedia-05 is that it would be helpful for an 
endpoint to extend the listener lifetime such that it maintains its 
listener for a short period of time after it received an initial connection 
in order to detect the possibility a duplicate connection may occur.  If a 
double
connect occurs that correlates to the session under negotiation, the 
endpoint SHOULD consider itself under attack and terminate the session.  In 
the case of bidirectional RTP/AVP, an endpoint that starts receiving two 
RTP streams from different addresses to the same port pair SHOULD consider 
itself under attack and terminate the session.

On the other side of the timeline, Bob should be mindful of the order in 
which an incoming connection occurs relative to providing an SDP reply to 
Alice.  If a connection arrives ahead of this event, Bob should be 
suspicious of the presence of Carol attempting to guess the address/port he 
is about to advertise in his reply.  The connection can either be discarded 
and Bob can continue, or he can opt to terminate the session.

Here are the connection scenarios:

FULL CONNECTIVITY:

Alice         Carol        Bob

Offer ----------------->
       <------CONNECT
??    <------------------ CONNECT
       <------------------ Answer
              CONNECT---->

=====================================

BOB/CAROL CANNOT CONNECT TO ALICE:

Alice         Carol        Bob

Offer ----------------->
            X--CONNECT
                       X-- CONNECT
       <------------------ Answer
              CONNECT---->
CONNECT ---------------->  ??

=====================================

ALICE/CAROL CANNOT CONNECT TO BOB:

Alice         Carol        Bob

Offer ----------------->
       <------CONNECT
??    <------------------ CONNECT
       <------------------ Answer
              CONNECT--X

=====================================

BOB CANNOT CONNECT TO ALICE:

Alice         Carol        Bob

Offer ----------------->
       <-------CONNECT
                       X-- CONNECT
       <------------------ Answer
              CONNECT---->
              Hijack!

=====================================

The ?? shows that Alice or Bob has detected a duplicate media connection 
and therefore has enough information to infer a possible attack.

The failure case is a common client/server scenario where the client 
(Alice) is behind a NAT/firewall and Bob (the server) is on the public 
Internet.  In many cases Bob knows that he is fully routable, and therefore 
SHOULD opt to advertise "connection:passive" which will cause Alice to 
discard Carol's connection once Alice receives Bob's SDP reply.

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

---

From: David Yon <[email-masked]>
Date: Mon, 17 Mar 2003 13:14:52 -0500

Jonathan brought up the issue of forked-INVITE WRT my examples and the 
ability of Alice or Bob to detect a hijack attempt.  Thinking this through, 
I'm not yet convinced this is a issue for the security issue, but rather 
the forked-INVITE scenario is not explicitly addressed in comedia-05.

Here's a normal forked-INVITE exchange without an attacker (Alice, Bob, and 
Dan, where Bob "wins" the forked-INVITE):

Alice           Proxy       Bob            Dan

Offer   ------->
                  Offer ---->
                        |
                        +------------------>

        <--------------------CONNECT
        <-----------------------------------CONNECT

                        <----Answer
        <---------Answer
                        <------------------Answer
                  Cancel------------------->
        <x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-DISCONNECT

So the problem that is not addressed in comedia is that there may be <n> 
connections arrive as a result of a forked-INVITE, that will eventually 
unwind back to a single connection.  The question is: when and how does 
Alice know which of the connections will be the actual connection used for 
the session?  This is a real problem (oh boy, another reason to delay 
comedia!), so I think the question needs to have an answer.

I would submit that if you can answer the above question, then the 
scenarios I presented at the meeting are still valid, albeit somewhat 
simplified.  I.e., *eventually* Alice will know that it should have one 
connection but has more, and therefore can detect the attack.

And to throw more wood on the fire, it starts to get non-trivial when you 
consider cases like Bob's connection setup being blocked but not 
Dan's.  For example:

Alice           Proxy       Bob            Dan

Offer   ------->
                  Offer ---->
                        |
                        +------------------>

                          X--CONNECT
        <-----------------------------------CONNECT

                        <----Answer
        <---------Answer
                        <------------------Answer
                  Cancel------------------->
        <x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-DISCONNECT
(Alice: now what do I do?)

If this was not a forked-INVITE, Alice would know that she needs to attempt 
a connection to Bob, as a connection hadn't arrived when the Answer arrives 
via the proxy.  But here we have a connect succeed from Dan, then a short 
time later it terminates.  So how does Alice differentiate this 
forked-INVITE scenario from a failed media setup scenario?

Are we having fun yet? :-)

Temporarily flipping to a SIP-centric worldview, wouldn't one answer be to 
map comedia section 4 (b/c) to the ACK message from Alice rather than the 
OK reply from Bob?  This doesn't answer the question for two-way 
handshakes, but it seems to for three-way.

At 10:28 PM 3/14/2003, you wrote:
>\

---

From: "Dan Wing" <[email-masked]>
Date: Mon, 17 Mar 2003 10:26:28 -0800

...
> forked-INVITE scenario from a failed media setup scenario?

Likewise, an attacker could actively prevent the media from being setup.

-d

---

From: David Yon <[email-masked]>
Date: Mon, 17 Mar 2003 13:30:14 -0500

Well, this maps to my scenario 4 (and all of my scenarios result in DoS as 
the best case), I don't see how forked-INVITE fundamentally changes the 
equation...

---

From: David Yon <[email-masked]>
Date: Mon, 17 Mar 2003 17:50:07 -0500

After talking this over with some of the folks here, it's clear that 
perhaps that the three-way handshake is the Grand Simplifying 
Notion(tm).  SIP has this property, and to date it is SIP that is the only 
protocol causing grief with the forking-INVITE.

So, my assertion is that forking-INVITE ceases to be a problem if the 
condition described in section 4 of comedia is defined to be the ACK 
message from Alice rather than the 200 response from Bob.  Taking my 
earlier forking INVITE example, here's what happens:

Alice           Proxy       Bob            Dan

Offer   ------->
                  Offer ---->
                        |
                        +------------------>
                        <----Answer
        <---------Answer

CONNECT ------------------->
ACK     ------------------->

By delaying the initiation of the connect-then-answer listed in section 
4(b/c) to the transmission of the ACK, we've allowed the fork to collapse 
back to a pair of endpoints before any connections are initiated.  So 
instead of dealing with the large permutations caused by the 1-to-n fan-out 
of Alice to possible destinations, we're back to just Alice and Bob (Bob 
being defined to always be the "winner" of the forked INVITE).

With this in mind, there are now five unique scenarios of Alice, Bob, and 
Carol:

1) FULL CONNECTIVITY (OR BOB CANNOT CONNECT TO ALICE):

Alice           Carol          Bob

Offer ------------------------>
       <-----------------------Answer
                CONNECT------->

CONNECT----------------------> ??
ACK   ----------------------->
       <--------CONNECT

2) ALICE CANNOT CONNECT TO BOB:

Alice           Carol          Bob

Offer ------------------------>
       <-----------------------Answer
                CONNECT------->

CONNECT----X
ACK   ----------------------->
       <--------CONNECT
                Hijack!

3) ALICE/CAROL CANNOT CONNECT TO BOB:

Alice           Carol          Bob

Offer ------------------------>
       <-----------------------Answer
                CONNECT--X

CONNECT----X
ACK   ----------------------->
       <--------CONNECT
??    <-----------------------CONNECT

4) CAROL CANNOT CONNECT TO ALICE (OR CAROL/BOB CANNOT CONNECT TO ALICE):

Alice           Carol          Bob

Offer ------------------------>
       <-----------------------Answer
                CONNECT------->

CONNECT----------------------> ??
ACK   ----------------------->
             X--CONNECT

5) CAROL CANNOT CONNECT TO BOB:

Alice           Carol          Bob

Offer ------------------------>
       <-----------------------Answer
                CONNECT--X

CONNECT---------------------->
ACK   ----------------------->
       <--------CONNECT

======================================

So there are two possible problems.  The first is #2, where the connection 
can be hijacked.  The second is #5, where the stakes are raised for Alice 
to choose correctly between the connection to Bob and the connection to 
Carol.

#2 has the same mitigation strategy as before---if Alice is on the public 
Internet and Bob is not, then Alice should use direction:passive.

#5 is trickier, any thoughts are welcomed.

Jonathan, you mentioned that there were some permutations of Offer/Answer 
that may upset this particular apple cart.  Now that this has been all laid 
out, what say you on this topic?