Re: francois' comments and why RFC4474 not used in the field

 

> -----Original Message-----
> From: Jon Peterson [mailto:[email protected]] 
> Sent: Monday, April 13, 2009 11:20 AM
> To: Dan Wing; '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
> 
> 
> I don't think I'm describing any novel attack here, and 
> really I am trying
> to speak more to higher-level requirements than the properties of any
> specific proposal, but I'd like to understand what our 
> disconnect is.

I believe there is consensus that cut-and-paste attacks need
to be prevented.  You continue to raise that point, so I can
only assume that you believe there is a lack of consensus on
that point.

> I'm
> talking about an attack that is purely in the signaling 
> layer, so I'm not
> sure in what sense Alice has a private key applicable to that 
> layer (unless
> she is acting as her own authentication service, say). "This 
> is Alice again"
> here means that, for example, the re-INVITE is a clever 
> cut-and-paste attack
> that appears to have a valid signature to verifier. The 
> decision about where
> media is sent is always something negotiated in the 
> rendezvous layer; if the
> rendezvous layer is persuaded to send media somewhere 
> unhelpful, no amount
> of media layer security will prevent this disruption.
> 
> The only thing this attack is meant to illustrate is why it 
> does matter who
> sets the IP/port. I've gathered that some people in the 
> discussion reject
> the notion that there are any threats related to the setting 
> the IP/port in
> the signaling layer, so I'm trying to provide an example.

That is because, ** in conjunction with media-path validation **
(which is the important point), the attack is prevented.

-d

> Jon Peterson
> NeuStar, Inc.
> 
> 
> On 4/13/09 10:38 AM, "Dan Wing" <[email protected]> wrote:
> 
> > 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
> 

_______________________________________________
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