This is a PRIVATE message. If you are not the intended recipient, please delete without copying and kindly advise us by e-mail of the mistake in delivery.
NOTE: Regardless of content, this e-mail shall not operate to bind CSC to any order or other contract unless pursuant to explicit written agreement or government initiative expressly permitting the use of e-mail for such purpose. •
To: "'Jon Peterson'" <[email protected]>, "'Francois Audet'" <[email protected]>, "'Elwell, John'" <[email protected]>, "'Dean Willis'" <[email protected]>
From: "Dan Wing" <[email protected]>
Sent by: [email protected]
Date: 04/13/2009 01:38PM
cc: "'Cullen Jennings'" <[email protected]>, [email protected], "'DRAGE, Keith \(Keith\)'" <[email protected]>
Subject: Re: [Sip] francois' comments and why RFC4474 not used in the field
> -----Original Message-----
> From: [email protected] [mailto:[email protected]] On
> Behalf Of Jon Peterson
> Sent: Friday, April 10, 2009 12:28 PM
> To: Francois Audet; Elwell, John; Dean Willis
> Cc: Cullen Jennings; [email protected]; DRAGE,Keith (Keith)
> Subject: Re: [Sip] francois' comments and why RFC4474 not
> used in the field
>
> If I may quibble here:
>
> > The attack is not impersonation, it's interruption of media.
>
> The attack relies on impersonation to accomplish interruption
> of media. The
> attacker listens to Alice's INVITE, and then sends a cut-and-pasted
> re-INVITE saying "This is Alice again, would you mind sending
> my media here
> instead please."
The 'Alice again' attacker would need to prove Alice's identity which
the attacker cannot accomplish (unless the attacker knows Alice's
private key). This is true of RFC4474 and
draft-fischer-sip-e2e-sec-media and draft-wing-sip-identity-media.
All three of those require the attacker to sign SIP headers and,
in the case of the two I-D's, the attacker has to also perform
a handshake proving possession of Alice's private key.
I don't see the new attack that you are seeing.
-d
> Impersonation is almost always a tool that
> attackers use to
> accomplish some particular goal, even if it's just tricking you into
> accepting unwanted communications. I'm not sure I'd say
> impersonation is an
> attack as such, but by preventing it, we prevent whole
> categories of attacks
> and grant ourselves more powers in crafting authorization policies.
>
> Jon Peterson
> NeuStar, Inc.
>
> On 4/10/09 11:37 AM, "Francois Audet" <[email protected]> wrote:
>
> > Yes, this makes sense to me.
> >
> > The attack is not impersonnation, it's interuption of media.
> >
> > Verifying the address of the relay seems difficult to me. It could
> > be in source domain, destination domain, some intermediary. Or there
> > could even be more than one. Unless we do it hop by hop.
> >
> > I guess we could have another layer of TLS exchange between the
> > UA and the intermediary (where instead of a self-signed cert,
> > you would actually autenticate your intermediary). Wouldn't do
> > wonders for backward compatibility however, and I'm not sure
> > it would be simpler than TURN.
> >
> >> -----Original Message-----
> >> From: Jon Peterson [mailto:[email protected]]
> >> Sent: Friday, April 10, 2009 09:10
> >> To: Audet, Francois (SC100:3055); Elwell, John; Dean Willis
> >> Cc: Cullen Jennings; [email protected]; DRAGE,Keith (Keith)
> >> Subject: Re: [Sip] francois' comments and why RFC4474 not
> >> used in the field
> >>
> >>
> >> At a high level, when an intermediary is going to relay your
> >> media, the intermediary (not the UAC) is the source of the
> >> IP/port data that appears in SDP, and as such, I can accept
> >> alternatives to securing that data with a signature from the
> >> originating administrative domain (abstractly, that goes
> >> equally for SBCs and TURN, I suppose). I don't however
> >> believe it follows from this that it just doesn't matter at
> >> all who sets the IP/port data in SDP. I think it does matter,
> >> and it matters most when we consider approaches that defer
> >> security checks from the SIP layer to the media layer. For
> >> example, if relatively weak SIP-layer security facilitates
> >> cut-and-paste attacks, then an eavesdropper could listen to
> >> INVITEs, forge re-INVITEs with the same signature but set the
> >> IP/port to something unhelpful, and methodically tear down a
> >> target's calls five seconds after they start. So from my
> >> perspective, verifying the origin of IP/port data still has
> >> value, even if the origin of that data is not the originating
> >> administrative domain.
> >>
> >> Jon Peterson
> >> NeuStar, Inc.
> >>
> >>
> >> On 4/9/09 12:09 PM, "Francois Audet" <[email protected]> wrote:
> >>
> >>> So, at a high level, if we could "sign the blob" à-la-RFC
> 4474, but
> >>> exclude very specific elements (i.e., the IP:port), and combine it
> >>> with DTLS-SRTP (or TLS for non-real time media), in specific cases
> >>> where allowing Media Relays is desireable/necessary, then
> >> we may have
> >>> a solution, right?
> >>>
> >>> I'm interpreting your email as we should have an opt-out of
> >> integrity
> >>> protection (carefully used) instead of an opt-in (as per the
> >>> draft-wing-identity-media draft).
> >>>
> >>>
> >>>
> >>>> -----Original Message-----
> >>>> From: Jon Peterson [mailto:[email protected]]
> >>>> Sent: Thursday, April 09, 2009 11:50
> >>>> To: Elwell, John; Audet, Francois (SC100:3055); Dean Willis
> >>>> Cc: Cullen Jennings; [email protected]; DRAGE,Keith (Keith)
> >>>> Subject: Re: [Sip] francois' comments and why RFC4474 not
> >> used in the
> >>>> field
> >>>>
> >>>>
> >>>>> [JRE] If media is encrypted, sending it to the wrong IP
> >>>> address/port,
> >>>>> whilst it will cause the call to fail, will not reveal the
> >>>> information
> >>>>> to the recipient. Of course, if media is not encrypted,
> >>>> that has worse
> >>>>> consequences, but unencrypted media can be eavesdropped by other
> >>>>> mechanisms, or can be spoofed or modified. Knowing who told
> >>>> you which
> >>>>> IP address/port to send to only gives you a certain amount
> >>>> of protection.
> >>>>> We must ensure we do not lower the security available when
> >>>> encryption
> >>>>> is in use (losing the ability to authenticate the user we
> >> performed
> >>>>> key agreement with) by clinging on to mechanisms that give
> >>>> some minor
> >>>>> benefit to the unencrypted case.
> >>>>
> >>>> In fairness, I don't think the choice is between signing
> >> the IP/port
> >>>> and not signing the IP/port. It is between signing the
> entire MIME
> >>>> body as a blob the auth service does not have to
> >> understand, versus
> >>>> selecting a set of elements (understood here not to include the
> >>>> IP/port) and signing those exclusively. If we want to
> >> understand the
> >>>> benefits of the former approach, they go a bit beyond
> >> protecting the
> >>>> IP/port.
> >>>> Architecturally, signing the blob results in better future
> >>>> compatibility and better paths to extending SDP. If the
> >>>> authentication service needs to know what elements in SDP
> >> are to be
> >>>> included in the signature, then the authentication service
> >> behavior
> >>>> needs to change every time that clients start using SDP
> >> (or bodies,
> >>>> for that
> >>>> matter) in new ways.
> >>>>
> >>>> If someone wakes up tomorrow, invents a new media security
> >> model, and
> >>>> decides there is value in having an indicator in SDP
> that will let
> >>>> you correlate the rendezvous layer with media security
> >> keying, under
> >>>> the blob model that indicator can just get stuck in SDP, and the
> >>>> authentication service does not need to change its
> >> behavior in order
> >>>> to sign it.
> >>>> Taking this to its extreme, while I'm sure no one would
> >> stand up to
> >>>> defend SDPng these days, virtually everyone would say that
> >> SDP isn't
> >>>> the ideal tool for establishing complicated sessions; if
> >> we ever do
> >>>> get around to building something better, the
> >> authentication service
> >>>> in the blob signature model shouldn't need to understand
> >> it. This is,
> >>>> again, just a basic SIP layering architecture we've always
> >> followed,
> >>>> intended to maximize the ability of endpoints to innovate
> >> and reduce
> >>>> the brittleness of intermediaries.
> >>>>
> >>>> Even without looking to the future, I think there's
> >> reasonable value
> >>>> in signing most of the cruft in SDP. For example, as I've
> >> mentioned
> >>>> before, I think it's worth detecting various codec
> >> downgrade sorts of
> >>>> attacks. But speaking to the IP/port again specifically, I
> >> maintain
> >>>> that when sending media doesn't work, it is useful for UAS to
> >>>> ascertain who set the target IP/port, and if the IP/port
> >> shouldn't be
> >>>> tried anyway because they were inserted by an attacker, I
> >> think it's
> >>>> useful for the UAS to know that before it processes that
> >> re-INVITE,
> >>>> or begins altering for that initial INVITE, or what have you.
> >>>>
> >>>>>> broadly I
> >>>>>> think it doesn't address threats where an
> >>>> attacker/impersonator can
> >>>>>> accomplish their goals without ever establishing a
> >> session. If we
> >>>>>> think about, I suspect we'll find there are actually quite
> >>>> a few of those.
> >>>>> [JRE] So this suggests the need for two solutions: one for
> >>>> protecting
> >>>>> the rendez-vous layer and one for protecting the media
> layer. The
> >>>>> problem is that the mechanism for protecting the
> >> rendez-vous layer
> >>>>> (RFC
> >>>>> 4474) does not work in certain deployment situations, and
> >>>> because we
> >>>>> reuse that for authenticating the media layer (using it
> >> to sign the
> >>>>> fingerprint of the certificate used at the media layer) we
> >>>> are unable
> >>>>> to have protection of the media layer in those deployment
> >>>> situations.
> >>>>
> >>>> Certainly I agree that RFC4474 interprets "certain deployment
> >>>> situations" as security violations, and that is a
> >> limitation of its
> >>>> approach. I was merely pointing out that there are also
> >> limitations
> >>>> to an approach where we largely defer security to the
> media layer;
> >>>> namely, it no longer protects against classes of attacks
> >> that do not
> >>>> intend to establish sessions as such (this discussion would come
> >>>> around to things like early media and forking, for
> >> example; there are
> >>>> also applicability concerns here with media protocols other than
> >>>> RTP). If these were the only two possible solutions, they
> >> we'd debate
> >>>> their merits and flaws, pick one, and be done. I at least haven't
> >>>> given up on the idea that we can draw up some other candidate
> >>>> solutions; the real bar to doing so seems to me to be
> disagreement
> >>>> about the problem space.
> >>>> So for the moment, I am still trying to talk at a pretty
> >> high level
> >>>> about what sorts of qualities are desirable in a solution.
> >>>>
> >>>> Jon Peterson
> >>>> NeuStar, Inc.
> >>>>
> >>>>> John
> >>>>
> >>>>
> >>
> >>
>
> _______________________________________________
> Sip mailing list https://www.ietf.org/mailman/listinfo/sip
> This list is for NEW development of the core SIP Protocol
> Use [email protected] for questions on current sip
> Use [email protected] for new developments on the application of sip
>
_______________________________________________
Sip mailing list https://www.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [email protected] for questions on current sip
Use [email protected] for new developments on the application of sip
_______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use [email protected] for questions on current sip Use [email protected] for new developments on the application of sip
