You wrote: > Put in the contrapositive, if a change is not noticeably by > the end users because they get exactly what they expected, > then its not an attack. Nothing bad happened, so why would it > be an attack? >
Part of the problem here is that the end user expectations have not been rigorously defined for RFC 4474. Parts of RFC 4474 allow things that the end user might not have expected, and so on. Part of what was on the slides on Tuesday was to create some sort of informational / BCP that does set out to detail what RFC 4474 and other identity drafts provide, i.e. when an identity is delivered, this is the security that is / is not associated with it. Regards Keith > -----Original Message----- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On > Behalf Of Jonathan Rosenberg > Sent: Thursday, July 31, 2008 11:22 AM > To: Elwell, John > Cc: Cullen Jennings; SIP IETF; Uzelac,Adam > Subject: Re: [Sip] Thoughts on SIP Identity issues > > Is this an ATTACK though? I don't think it is. > > One of the points of dispute at the mic is whether or not > 'unauthorized' > changes to signaling constitute an attack or not. I don't > think we have a very clear definition of what aspects of the > request are really and truly ones that are authorized to be > changed, and which are not. We've tried to draw this line at > headers/body and also outline certain headers which are and > are no immutable. However, those were based on the model of > which parts of SIP a PROXY needed to modify and which it > didn't, NOT based on whether a modification of that header > would truly be an attack. > > I would assert that the following is an important litmus test: > > Modification of a portion of the SIP message is an 'attack' if > and only if it results in an experience for the end user > which defies > their expectations. > > Put in the contrapositive, if a change is not noticeably by > the end users because they get exactly what they expected, > then its not an attack. Nothing bad happened, so why would it > be an attack? > > Another way to think about this, is the following litmus > test, "If an intermediary consistently makes this > modification, is it likely that some users will open trouble > tickets with their IT department to report a problem?". If > so, the modification is an attack. If not, its not. > > Modifying a message to cause it to be dropped clearly is an > attack, since user expectation is that, if I make a call, it > succeeds. So if a packet is consistently dropped, my calls > consistently fail, which defies my expectations. > > As another example that is more complicated, consider > changing codecs. > In one way, codecs are invisible to users. Indeed, a change > of codec for purposes of transcoding will allow a call to > succeed when it might otherwise fail, and is thus beneficial > to users and not harmful. > However, a downgrade of codecs - for example, removing > wideband codecs from a codec list - is harmful and noticeable > to users. If I have a softclient with iSAC and I call someone > else who does too, but we get only g729, frankly, this is > noticeable to the users. Indeed, one can imagine that if a > user of such a soft client sometimes gets wideband and > sometimes not, they may ask the person on the other end of > the call if they also have a softclient with the wideband > feature, and if that person does, not understand why there > was no wideband for the call. In this case, modifications of > codecs can be considered an attack without some indication to > the user why they are not getting wideband. > > Thanks, > Jonathan R. > > > > Elwell, John wrote: > > Adam, > > > > Thanks for your support. However, I do not accept > transcoding as a use > > case. To perform transcoding the service provider needs to > decrypt and > > re-encrypt, and therefore DTLS-SRTP will be terminated at the > > transcoder. Therefore the service provider will indeed need > to re-sign > > the SIP request (the certificate fingerprint will have > changed, among > > other things), and the user will see that media is secure > only as far > > as the service provider. I think this is the correct outcome. > > > > John > > > >> -----Original Message----- > >> From: Uzelac, Adam [mailto:[EMAIL PROTECTED] > >> Sent: 30 July 2008 12:06 > >> To: Cullen Jennings; Elwell, John > >> Cc: SIP IETF > >> Subject: RE: [Sip] Thoughts on SIP Identity issues > >> > >> I believe that the problem statement (and associated use > >> cases) that John presented in the WG session are valid. I > think it > >> was unfortunate that those use cases couldn't be discussed more in > >> the WG session. This email appears to me simply John trying to > >> further the discussions to bring out arguments. > >> > >> One particular note I would like to share - given a comment at the > >> mic regarding 4474 working as designed and desired - is that there > >> are situations (good, bad or indifferent) that necessitate > changes in > >> the SDP. John cited media steering as a use case. Another > use case is > >> media steering for transcoding. Use case below: > >> > >> Ent A--->SSP1--->Ent B > >> > >> In this use case, Ent A and SSP1 have established certain > "rules of > >> engagement", like G729, 2833, t.38, etc. Ent B and > >> SSP1 have established their own "rules of engagement", for > instance > >> G711 for voice, inband DTMF/FAX, etc. Being there's no common > >> denominator for the media, the SDP in INVITE "steers" to a device > >> that can trancode. > >> > >> Another use case, would be for those SSPs that have Lawful > Intercept > >> requirements. Steering the media to something that will > can intercept > >> should that be a regulatory obligation. > >> > >> Adam > >> > >>> -----Original Message----- > >>> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On > >> Behalf Of > >>> Cullen Jennings > >>> Sent: Tuesday, July 29, 2008 7:21 PM > >>> To: Elwell, John > >>> Cc: SIP IETF > >>> Subject: Re: [Sip] Thoughts on SIP Identity issues > >>> > >>> > >>> On Jul 29, 2008, at 17:53 , Elwell, John wrote: > >>> > >>>> Flawed argument 2: > >>>> The problem exists when we go through service providers. Service > >>>> providers use only E.164-based SIP URIs. We can't do > >> anything about > >>>> E.164-based SIP URIs. Therefore we can't do anything to > >> address the > >>>> case > >>>> where the request goes through service providers. > >> Therefore there is > >>>> nothing we can do. > >>> > >>> Hmm, I don't think anyone made quite that argument. > Personally, I'd > >>> rather spend time thinking about the problems that were presented > >>> today in the meeting than repeat previous discussions. > >>> > >>> Cullen <with my individual hat on> > >>> > >>> _______________________________________________ > >>> 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 > > > > -- > Jonathan D. Rosenberg, Ph.D. 499 Thornall St. > Cisco Fellow Edison, NJ 08837 > Cisco, Voice Technology Group > [EMAIL PROTECTED] > http://www.jdrosen.net PHONE: (408) 902-3084 > http://www.cisco.com > _______________________________________________ > 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
