Subject: RE: [Sip] RE: connected-identity before 200 Ok

From: "Elwell, John" <[email-masked]>
Date: Tue, 20 Feb 2007 10:43:05 +0000

Dan,

I can see the benefit of doing a further SDP offer in an UPDATE request that
coveys connected-identity to prove that the security keys and other SDP
information do indeed come from the user identified in the From header
field. However, I seem to be missing the link to Rob's original question,
which was how to ensure that it comes from an entity that received the
INVITE request (and hence ensure that the SRTP comes from such an entity).

John

> -----Original Message-----
> From: Dan Wing [mailto:[email-masked]] 
> Sent: 19 February 2007 19:48
> To: Elwell, John; [email-masked]
> Cc: [email-masked]; 'Rob Raymond'
> Subject: RE: [Sip] RE: connected-identity before 200 Ok
> 
> 
> > The important thing is that there be evidence that the 18x has
> > reached the calling UA before sending an UPDATE request to the
> > calling UA. Otherwise the UPDATE request might receive a 481
> > response.  So I suppose the called UA could send an UPDATE request
> > and be prepared to repeat it (and the 18x response) if a 481
> > response is received.  This would be another example of "poor man's
> > PRACK". A problem could arise if the calling UA holds state to say
> > whether a 18x has been received reliably and rejects an UPDATE
> > request if not - I guess this depends on how it is implemented in
> > practice.  Also a calling UA that does not implement PRACK might
> > also be unable to accept UPDATE before answer, but the option tag
> > that indicates support for UPDATE will not tell you this.
> >
> > Another issue is whether the presence or absence of SDP offer in an
> > UPDATE request has impact on when it can/cannot be sent.
> 
> To detect the attacks that Rob brought up on the RTPSEC mailing list,
> we would want the UPDATE to contain the same SDP as it has in the
> 18x (183).
> 
> > If it contains an SDP offer, obviously it has to obey the strict
> > offer-answer rules, so clearly has to be sent after any previous
> > offer-answer sequence has completed.  Without waiting for the PRACK
> > it could be dangerous.  Consider the following slightly revised
> > sequence:
> > 
> >     Alice                      Bob
> >       |                         |
> >   1.  |--Invite with SDP offer->|
> >   1a  |<--18x without SDP answer|
> >   2.  |x--183 with SDP answer---|  (183 is unreliable)
> >   3.  |<--UPDATE with SDP-------|
> >   4.  |---Ack Update----------->|
> > 
> > The first 18x is send unreliably and established the early 
> dialog. The
> > second 183 containing SDP answer is lost. The UPDATE 
> request will not
> > receive a 481 response (because the early dialog is already 
> > established) but the SDP offer will be illegal. It is unclear what 
> > response Alice would give.
> 
> Ok.
> 
> > So in this particular case it is a lot safer to wait for the PRACK.
> > Therefore I think the 
> 
> [looks like something got cut off from your email.]
[JRE] Nothing missing - the last 4 words above should have been deleted.

> 
> > However, if the UPDATE request does NOT contain an SDP offer 
> > (which for connected-identity purposes it doesn't need to), 
> 
> That's my point:  it does need to contain SDP in order to protect
> against the very same attacks that Identity protected against:  
> if the SDP isn't included, the Connected-Identity isn't useful
> because anybody could send RTP to the calling party.  That RTP
> could be audio saying "your mother wears combat boots".  Because
> the SDP isn't signed, there isn't any assurance it's coming from
> the expected IP addresses, nor can we use a=fingerprint to create
> cryptographic assurance.
> 
> > the following are questionable:
> > - the need to wait for PRACK if the 18x is sent reliably;
> > - the need to send the 18x reliably
> > - the whether the UPDATE request can be sent even if the only 
> > 18x sent does not contain SDP answer;
> > - whether an UPDATE request containing an offer for early session
> > disposition can be sent before the normal answer has been 
> > sent or before it has been acknowledged through PRACK.
> > 
> > I don't think these points are covered by RFC3311.
> 
> Yes, we need this standardized somewhere.
> 
> -d
> 
> 
> > John
> > 
> > > -----Original Message-----
> > > From: Dan Wing [mailto:[email-masked]] 
> > > Sent: 17 February 2007 00:49
> > > To: [email-masked]
> > > Cc: [email-masked]; Elwell, John; Rob Raymond
> > > Subject: connected-identity before 200 Ok
> > > 
> > > 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 [email-masked] for questions on current sip
> > Use [email-masked] for new developments on the application of sip
> 

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [email-masked] for questions on current sip
Use [email-masked] for new developments on the application of sip

---

From: "Dan Wing" <[email-masked]>
Date: Tue, 20 Feb 2007 09:15:34 -0800

> I can see the benefit of doing a further SDP offer in an 
> UPDATE request that coveys connected-identity to prove that 
> the security keys and other SDP information do indeed come 
> from the user identified in the From header field. 

Ok.  And if the offerer is being paranoid, the connected-identity
would need to arrive before the called party's phone rings (in order
to avoid clipping).  We'll need to work on ways to indicate that;
perhaps PRACK is perfect for this, but as we know it isn't widely
implement due to both its complexity and the IPR arround it.

> However, I seem to be missing the link to Rob's original question,
> which was how to ensure that it comes from an entity that 
> received the INVITE request (and hence ensure that the SRTP 
> comes from such an entity).

IMO, that is resolved by the fact the offerer received an UPDATE
containing an Identity signature.  This is because sip-identity 
(and, hence, connected-identity) presume the network between the 
SIP UA and the authentication service are sufficiently secure 
against the threats on that network.  TLS is the simplest example,
but SIP Digest authentication with its integrity protection is 
sufficient for that threat.

-d