> -----Original Message-----
> From: Eric Rescorla [mailto:[EMAIL PROTECTED] 
> Sent: Thursday, August 07, 2008 11:53 AM
> To: Dan Wing
> Cc: 'Cullen Jennings'; 'Eric Rescorla'; 'Elwell, John'; 
> 'Hadriel Kaplan'; 'Jonathan Rosenberg'; 'SIP IETF'; 'Uzelac, Adam'
> Subject: Re: [Sip] Thoughts on SIP Identity issues
> 
> At Wed, 6 Aug 2008 09:29:13 -0700,
> Dan Wing wrote:
> > 
> >  
> > 
> > > -----Original Message-----
> > > From: Cullen Jennings [mailto:[EMAIL PROTECTED] 
> > > Sent: Tuesday, August 05, 2008 7:54 PM
> > > To: Dan Wing
> > > Cc: 'Eric Rescorla'; 'Elwell, John'; 'Hadriel Kaplan'; 
> > > 'Jonathan Rosenberg'; 'SIP IETF'; 'Uzelac, Adam'
> > > Subject: Re: [Sip] Thoughts on SIP Identity issues
> > > 
> > > 
> > > On Aug 5, 2008, at 10:26 , Dan Wing wrote:
> > > 
> > > >>>>
> > > >>>> With that said, ISTM that this cuts against your argument
> > > >>>> that we should
> > > >>>> be signing less of the message, since the failure of RFC
> > > >> 4474 (to the
> > > >>>> extent there is one) in this case is that it doesn't protect
> > > >>>> *enough* information.
> > > >>>
> > > >>> Neither draft-fischer-sip-e2e-sec-media and
> > > >>> draft-wing-sip-identity-media
> > > >>> simply "sign less" -- please do not mis-characterize the
> > > >>> proposals.  Both
> > > >>> proposals require a public key exchange with the remote
> > > >>> party -- which
> > > >>> is far stronger than just using the IP address of the 
> remote party
> > > >>> as is done by RFC4474.
> > > >>
> > > >> I don't actually think this characterization of 4474 is that  
> > > >> accurate.
> > > >> RFC 4474 does not use the IP address for 
> authenticating the media.
> > > >> Rather, it authenticates the IP address as well as the 
> rest of the
> > > >> SDP
> > > >
> > > > Which draft-kaplan-sip-baiting shows is insufficient at 
> its intended
> > > > purpose.
> > > 
> > > I probably disagree but to sort that out ... What exactly 
> do you see  
> > > as the purpose of 4474 which the baiting draft shows it 
> does not meet?
> > 
> > The purpose of 4474 is to identity the calling party.
> 
> Well, I wasn't an author of 4474, but that's not what I take to be its
> purpose. Rather, I think the purpose is to provide cryptographic
> data origin authentication and message integrity, which it does.
> 
> Here's what the abstract says:
> 
>    The existing security mechanisms in the Session Initiation Protocol
>    (SIP) are inadequate for cryptographically assuring the identity of
>    the end users that originate SIP requests, especially in an
>    interdomain context.  This document defines a mechanism 
> for securely
>    identifying originators of SIP messages.  It does so by 
> defining two
>    new SIP header fields, Identity, for conveying a signature used for
>    validating the identity, and Identity-Info, for conveying 
> a reference
>    to the certificate of the signer.
> 
> The identity of the message originator is a critical part of
> identifying the calling party, but I think it's also equally clear
> that it's necessary but not sufficient, since in the absence of
> cryptographic authentication for the media (i.e., SRTP), a
> sufficiently powerful (i.e., onpath) attacker can still cause
> mismatches between the displayed identity and the actual source
> of the media.

Yes, of course.

> For instance, if the attacker can convince Alice
> to call Bob, he can then hijack the media, no matter what 
> cryptographic authentication is applied to the signalling.
> So, providing accurate caller identification can't be the purpose
> of RFC 4474 since it's trivially apparent it can't fulfill it.

Er, well, Alice *really*did* call Bob.  That an attacker is sending
media (spoofing Alice's IP address and UDP port, I would expect) 
is not RFC4474's fault -- I agree that to prevent such an attack
you would need SRTP.

> I would observe that this is also true about the non-SRTP
> proof of identity mechanisms described in 
> draft-wing-sip-identity-media.

Yes, absolutely agreed.

> For instance, if you use the ICE exchange described in S 4.3,
> the attacker can simply allow the ICE exchange to complete but
> then hijack the media afterwards. What ICE is providing is
> a liveness test for the signalling but that serves to make this
> an on-path attack, not to block it entirely.

Yes, agreed.

But there is resistance to requiring SRTP in order to establish
identity -- which is why draft-wing-sip-identity-media includes
a non-SRTP identity mechanism.

-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

Reply via email to