RE: Early arriving media before 200 OK

["Dan Wing" <dwing@xxxxxxxxx>]

(Eric and I clarified my misunderstanding with a phone call.)

Thanks.  Rob's concern seemed to extend to on-path attackers
who could delay offers and even manipulate SDP.

Going back to Rob's original email:

    >
    >  1) Discard all media before the 200 OK - not acceptable,
    >     that early arriving media often includes the "hello"
    >     which if lost causes a very poor user call experience.
    >     Horrible in fact.  I'm already concerned by the amount
    >     of data loss during the round-trips for DTLS
    >     negotiation and the required SIP signaling for ICE
    >     before a path change, let alone adding to the trouble.
    >

Rob, are you aware that ICE-13 (and -12, I believe), implements what could
be called a 'poor-man's connectivity precondition', which delays alerting
the called party until the SDP answer is received?  See
http://tools.ietf.org/html/draft-ietf-mmusic-ice-13#section-12.1 which says:

   ...
   If an offer is received in an INVITE request, the callee SHOULD
   immediately gather its candidates and then generate an answer in a
   provisional response.  ICE requires that a provisional response with
   an SDP be transmitted reliably.  This can be done through the
   existing PRACK mechanism [9], or through an optimization that is
   specific to ICE.  With this optimization, provisional responses
   containing an SDP answer that begins ICE processing for one or more
   media streams can be sent reliably without RFC 3264.  To do this, the
   agent retransmits the provisional response with th exponential
   backoff timers described in RFC 3262.  Retransmits MUST cease on
   receipt of a STUN Binding Request for one of the media streams
   signaled in that SDP or on transmission of a 2xx response.  If no
   Binding Request is received prior to the last retransmit, the agent
   does not consider the session terminated.  Despite the fact that the
   provisional response will be delivered reliably, the rules for when
   an agent can send an updated offer or answer do not change from those
   specified in RFC 3262.  Specifically, if the INVITE contained an
   offer, the same answer appears in all of the 1xx and in the 2xx
   response to the INVITE.  Only after that 2xx has been sent can an
   updated offer/answer exchange occur.  This optimization SHOULD NOT be
   used if both agents support PRACK.  Note that the optimization is
   very specific to provisional response carrying answers that start ICE
   processing; it is not a general technique for 1xx reliability.
   ...

Back to Rob's original email:

    >
    >  I propose that the bar be raised and that this limitation
    >  be rejected in favour of something that ensures all early
    >  arriving media is at least the recipient of the INVITE.
    >

You can't be sure who legitimately received the Invite until you receive the
SDP answer, and that SDP answer needs to contain an a=fingerprint or
something functionally equivalent to the a=fingerprint.  

Otherwise, an attacker could passively observe the Invite and send the
necessary cookie to the offerer.  Based on your original post on this topic,
I don't think that provides adequate protection for the threats you are
considering, does it?

-d


> -----Original Message-----
> From: Eric Rescorla [mailto:ekr@xxxxxxxxxxxxxxxxxxxx] 
> Sent: Wednesday, February 07, 2007 1:22 PM
> To: Dan Wing
> Cc: robin@xxxxxxxxxxxxxxx; ietf-rtpsec@xxxxxxx
> Subject: Re: Early arriving media before 200 OK 
> 
> Dan Wing <dwing@xxxxxxxxx> wrote:
> > I read through RFC4279 ("PSK Ciphersuites for TLS") again, and I 
> > admit I still don't understand what you meant in your original 
> > reply when you wrote "key which is used to key TLS PSK mode".  You
> > meant something different from what I understood, because what I
> > understood was that you were going to send the PSK in SDP, which
> > would share most of the features and drawbacks of Security 
> > Descriptions.  You meant something else, but I can't tease apart
> > what you meant.
> 
> So, the basic point here is that you want to do a public key 
> exchange in the TLS channel but require that the TLS client
> (the SDP answerer) demonstrate possession of some secret sent
> in the SDP offer. This provides confidentiality against 
> passive attackers who observe the SDP (unlike SDES) because
> you would need to mount an MITM attack on the public key
> exchange.
> 
> So, if people consider this attack to be serious, what we want
> to do is:
> 
> 1. Include a secret in the SDP Offer that is required to complete
>    the handshake. This protects against active attacks before
>    the 200 by people who cannot see the SDP Offer.
> 2. Have both sides include authenticated commitments to their
>    public keys in the SDP offer. This allows you to do an
>    asymmetric key establishment in the media channel, thus 
>    protecting you against attackers who can passively see
>    the SDP exchange (including other members of the fork).
> 
> TLS PSK provides one way of doing that by allowing you to have
> an asymmetric key establishment (2) that's also authenticated by
> a shared key (1). It may or may not turn out to be the best way.
> 
> -Ekr