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

From: David Yon <[email-masked]>
Date: Wed, 30 Apr 2003 18:51:12 -0400

At the risk of being rude, I'm reposting my analysis and request-for-input 
email that I submitted way back in March.

Feedback would be appreciated.

The sooner the MMUSIC group can get engaged on this, the sooner we can get 
it off our collective plate, and the sooner it can be used.

---------------------

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
                        <------------------Answer
                  Cancel------------------->

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?

At 01:14 PM 3/17/2003, David Yon wrote:

>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.

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

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