I was about to say something similar.
Is not having my media intercepted by an intermediary a valid
expectation? If so, any change that facilitates that, when it otherwise
wouldn't be, is an attack.
Paul
DRAGE, Keith (Keith) wrote:
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
_______________________________________________
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
