RE: [Sip] connected-identity before 200 Ok

["Dan Wing" <dwing@xxxxxxxxx>]

> I'm missing something here. I see nothing to prevent using UPDATE 
> (without SDP) for conveying connected identity before the 
> 200.

But we need the SDP signed.

1. Without SRTP:  The SDP answer needs to be signed for all the
   reasons the body (SDP offer) was signed in SIP-Identity.
   Otherwise, an attacker could send an SDP answer containing his own
   IP address, and the offerer would believe it.  This allows the
   attacker to play media to the calling party, and the calling party
   has no way to defend against such an attacker because there was
   never any signed SDP.

2. With crypto:  When we have cryptographic mechanisms to associate
   the signaling with the media path (such as with comedia-tls
   [RFC4572] and DTLS-SRTP), the problem is more acute, because it's a
   full-on requirement that an attacker be unable to inject malicious
   media into the path.  If we can't get the a=fingerprint signed
   using SIP-Identity, we cannot prevent that attack.

I understand everyone is happy with the state of (1), which is what
connected-identity permits today.  That's fine.  The reason I started
this thread was to clarify that we can, in the near future, extend the
protections we can get with Connected-Identity to protect us from
attackers when we are doing (2).

> Then the offer/answer can carry on as normal without PRACK.
> 
> Regarding the validity/non-validity of the call flow below, see 
> draft-ietf-sipping-sip-offeranswer-00.

Thanks for the pointer.  Its section 3.1 says:

   Therefore, to make implementations simple, a
   UA acting as a UAS for INVITE transaction is recommended not to send
   a UPDATE request with an offer until the reliable response with an
   answer to the offer in the INVITE request is acknowledged with PRACK
                                             ^^^^^^^^^^^^^^^^^^^^^^^^^^ 
   request.
   ^^^^^^^

Here, too, I would wonder aloud if ICE's "poor man's PRACK" is 
sufficient to meet the needs of the highlighted phrase.

-d


> 	Paul
> 
> Dan Wing wrote:
> > This message is a result of some offline discussions with 
> Rob and ample
> > caffeine consumption on my part.  The concern is if PRACK 
> is necessary in
> > order to use connected-identity before the call is answered 
> in order to
> > avoid some of the attacks Robin brought up on RTPSEC.
> > 
> > 
> > Reading RFC3311 (SIP UPDATE), it says:
> > 
> >       o  If the UPDATE is being sent before completion of 
> the initial
> >          INVITE transaction, and the initial INVITE 
> contained an offer,
> >          the UPDATE can contain an offer if the callee generated an
> >          answer in a reliable provisional response, and the 
> caller has
> >          received answers to any other offers it sent in 
> either PRACK or
> >          UPDATE, and has generated answers for any offers 
> it received in
> >          an UPDATE from the callee.
> > 
> > draft-ietf-sip-connected-identity seems to say you need to 
> use PRACK if you
> > want connected-identity before the 200 Ok:
> > 
> >    After an early dialog has been formed, if the 
> "from-change" option
> >    tag has been received in a Supported header field the UA 
> MAY issue an
> >    UPDATE request (RFC 3311 [4]) on the same dialog, 
> subject to having
> >    sent a reliable provisional response to the INVITE 
> request and having
> >    received and responded to a PRACK request. 
> > 
> > Which I interpret to mean that the following is illegal, 
> even if the SDP in
> > message 2 and 3 are identical:  
> > 
> >     Alice                      Bob
> >       |                         |
> >   1.  |--Invite with SDP offer->|
> >   2.  |<--183 with SDP answer---|  (183 is unreliable)
> >   3.  |<--UPDATE with SDP-------|
> >   4.  |---Ack Update----------->|
> > 
> > Please confirm that the above call flow is disallowed per 
> the rules of
> > RFC3311 and per the rules of draft-ietf-sip-connected-identity.
> > 
> > 
> > Question:  would ICE's "poor-man's PRACK" (as I call it) be 
> sufficient to
> > meet the needs of RFC3311 and -sip-connected-identity for a reliable
> > provisional response?  ICE's "poor-man's PRACK" is described in
> > 
> <http://tools.ietf.org/html/draft-ietf-mmusic-ice-13#section-1
> 2.1>, around
> > the middle of section 12.1.
> > 
> > -d
> > 
> > _______________________________________________
> > Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
> > This list is for NEW development of the core SIP Protocol
> > Use sip-implementors@xxxxxxxxxxxxxxx for questions on current sip
> > Use sipping@xxxxxxxx for new developments on the application of sip
> >