Subject: [Sip] Thoughts on SIP Identity issues

From: "Elwell, John" <[email-masked]>
Date: Tue, 29 Jul 2008 17:53:40 +0100

Throughout the ongoing discussions, and in particular at today's
meeting, I seem to encounter two separate, IMO flawed arguments.

Flawed argument 1:
RFC 4474 is not just for securing the DTLS-SRTP certificate fingerprint,
but also for securing any sort of SIP request, which might not even be
session-related (e.g., MESSAGE, SUBSCRIBE). Therefore we can't change
what is signed, because that would break these other usages, and even to
some extent it would break its usage with requests that do contain SDP
but do not involve DTLS-SRTP.

This is flawed, because it does not accept the possibility of signing a
different set of data when using DTLS-SRTP, whereby we ensure that
important things like the certificate fingerprint and codecs get signed,
but not things that might legitimately change en route, such as IP
addresses and ports. In other words, SIP requests carrying DTLS-SRTP
certificate fingerprints do not have the same requirements on integrity
protection as other SIP requests.

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.

This is flawed because it doesn't recognise the possibility of sending
both an email-style SIP URI and an E.164-based URI (SIP or tel), whereby
the former is authenticated, along with integrity protection of
appropriate parts of the message, and the latter is not (and hence can
be changed by intermediate domains). For example, email-style in From
and E.164-based in PAI.

Comments?

John
_______________________________________________
Sip mailing list  https://www.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [email-masked] for questions on current sip
Use [email-masked] for new developments on the application of sip

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 29 Jul 2008 10:12:19 -0700

At Tue, 29 Jul 2008 17:53:40 +0100,
> protection as other SIP requests.

Well, I was the one who offered an argument of this type, but it's
not quite what I'm saying.

Rather, I'm saying that Identity is not only to allow DTLS-SRTP, but
also to protect other usages, so if your proposal involves changing
fields which would render those other usages insecure, we have a
potential problem. For instance, as I understood Hadriel's comments at
the mike, he thinks he should be able change Call-Id in
non-offer/answer cases.  Before we consider that, we would need a
security analysis of the impact of changing Call-iD.

-Ekr

---

From: Cullen Jennings <[email-masked]>
Date: Tue, 29 Jul 2008 19:21:22 +0100

> where the request goes through service providers. Therefore there is

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>

---

From: Hadriel Kaplan <[email-masked]>
Date: Wed, 30 Jul 2008 06:33:12 -0400

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of Eric
> Rescorla
>
> non-offer/answer cases.

Yup.  In particular, I'm claiming that we should sign something else to provide cut/paste protection rather than the call-id and cseq header fields.
I say that because I believe 4474 is signing them for the purpose of cut/paste type protection, not because we actually care whether the call-id/cseq values are changed by a MitM.

> Before we consider that, we would need a

Yup, and CSeq, and Contact.

-hadriel

---

From: "Uzelac, Adam" <[email-masked]>
Date: Wed, 30 Jul 2008 07:05:41 -0400

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

> From: [email-masked] [mailto:[email-masked]] 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
>
>

---

From: Hadriel Kaplan <[email-masked]>
Date: Wed, 30 Jul 2008 08:33:08 -0400

Cullen,
I think there was some confusion or miscommunication - it was my impression that what you asked for previously was for just *one* use-case/scenario where 4474 doesn't work the way we'd like, so the WG could focus on that one case and decide if it's legitimate to drive for a different mechanism.  I think that's why John presented just one case.  But at the mic it sounded more like you wanted to know *all* scenarios we thought should be handled.

Which is it?

-hadriel

---

From: Dean Willis <[email-masked]>
Date: Wed, 30 Jul 2008 17:23:12 +0100

On Jul 30, 2008, at 12:05 PM, Uzelac, Adam wrote:

> 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.
>

This is more that sterring; the media is being terminated at a device  
that transcodes it. Then a new media stream flows out the other side.

When media transcoding is occurring, media integrity is hop-by-hop. I  
maintain that we have no need for an end-to-end identity  
representation when the media itself is hop by hop.

> 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.

Same as above. Although one should note that proper use of DTLS-SRTP  
to detect the lawful intercept.

--
Dean

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 30 Jul 2008 12:36:48 -0400

This is handled better if one of the UAs arranges for the transcoding, 
as specified in the RFC (number escapes me) that describes that.

Then, any integrity issues about the media are at the discretion of the 
UA that set it up. And in this case it presents no identity or signing 
issues.

	Paul

Dean Willis wrote:
>> 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
> 
>> 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.
>>
> 
> maintain that we have no need for an end-to-end identity representation 
> when the media itself is hop by hop.
> 
> 
>> requirements. Steering the media to something that will can intercept 
>> should that be a regulatory obligation.
> 
> 
> Same as above. Although one should note that proper use of DTLS-SRTP to 
> detect the lawful intercept.
> 
> -- 
> Dean

---

From: "Elwell, John" <[email-masked]>
Date: Wed, 30 Jul 2008 18:44:59 +0100

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

> From: Uzelac, Adam [mailto:[email-masked]] 
> 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
> 
> > > E.164-based SIP URIs. Therefore we can't do anything to 
> address the
> > > case

---

From: "Elwell, John" <[email-masked]>
Date: Thu, 31 Jul 2008 08:28:44 +0100

> From: Dean Willis [mailto:[email-masked]] 
> Sent: 30 July 2008 17:23
> To: Uzelac, Adam
> Cc: Cullen Jennings; Elwell, John; SIP IETF
> cases) that  
> "rules of  
> Intercept  
[JRE] Media steering is sufficient to accomplish LI. The encrypted
stream is delivered to the authorities. The authorities need to go to
the end domain to be able to have access to the encryption key and/or
the unencrypted stream. An intermediate domain cannot be held
responsible for encryption done by end domains.

John

---

From: "Dan Wing" <[email-masked]>
Date: Thu, 31 Jul 2008 10:49:31 +0100

What was clear from the SIP meeting is we have a communication problem.  We
have several drafts describing the problems.  We have several drafts proposing
solutions to those problems.  We spend time in SIP meetings discussing the
drafts.  

I have no understanding of the objections to John Elewll's scenarios that he
presented.

Cullen and Jon -- as individual contributors and as the authors of RFC4474 --
are you able to provide information to resolve this communication problem?

-d

> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Hadriel Kaplan
> Sent: Wednesday, July 30, 2008 1:33 PM
> I think there was some confusion or miscommunication - it was 
> my impression that what you asked for previously was for just 
> *one* use-case/scenario where 4474 doesn't work the way we'd 
> like, so the WG could focus on that one case and decide if 
> it's legitimate to drive for a different mechanism.  I think 
> that's why John presented just one case.  But at the mic it 
> sounded more like you wanted to know *all* scenarios we 
> thought should be handled.
> 
> Which is it?
> 
> -hadriel
>

---

From: "Uzelac, Adam" <[email-masked]>
Date: Thu, 31 Jul 2008 04:56:25 -0400

The point that I want to make is this - I think that end-to-end identity is important. John and Hadriel have pointed out problems with the methods available to attain end-to-end identity.  This is an important issue to address. Those intermediary devices are not only there to address a SSP subscriber's policy for termination or origination services, but also for just plain interoperability.

Adam

> Elwell, John
> Sent: Thursday, July 31, 2008 8:29 AM
> To: Dean Willis; Uzelac, Adam
> Cc: Cullen Jennings; SIP IETF

---

From: Jonathan Rosenberg <[email-masked]>
Date: Thu, 31 Jul 2008 06:22:00 -0400

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:
>> Behalf Of

-- 
Jonathan D. Rosenberg, Ph.D.                   499 Thornall St.
Cisco Fellow                                   Edison, NJ 08837
Cisco, Voice Technology Group
[email-masked]
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-masked] for questions on current sip
Use [email-masked] for new developments on the application of sip

---

From: Dean Willis <[email-masked]>
Date: Thu, 31 Jul 2008 13:49:43 +0100

On Jul 31, 2008, at 9:56 AM, Uzelac, Adam wrote:

> The point that I want to make is this - I think that end-to-end  
> identity is important. John and Hadriel have pointed out problems  
> with the methods available to attain end-to-end identity.  This is  
> an important issue to address. Those intermediary devices are not  
> only there to address a SSP subscriber's policy for termination or  
> origination services, but also for just plain interoperability.

RFC 4474 provides quite strong assurances that the intermediaries have  
acted appropriately.

Some of the things that RFC 4474 block some of the actions of SBCs and  
some other intermediaries. Thus, we have a call to reduce the strength  
of RFC 4474.

If we water-down RFC 4474 to the point that an evil intermediary  
device could "gain advantage" in a way that RC 4474 would have  
prevented, then we have ruined RFC 4474.

Thus the argument that any SBC that changes SDP, etc. forms a  
transitive trust boundary, It MIGHT not have altered the identity, but  
it also might have, and there really is no way for the end node to  
tell. All it can really do is trust that it wasn't screwed over by the  
SBC.

So here's an idea: an alternative to RFC-4474 that explicitly supports  
transitive assertion identities by verifying an existing assertion and  
then asserting the same identity with a new signature.

We might start with RFC 474 and sign the same things as IFC 4474 does,  
but change a couple of points:

1) Instead of Identity and Identity-Info header fields, we'd use some  
new header fields (names TBD) to the identity that was verified and   
the signer. I propose "Reasserted-Identity" and "Reasserted-Identity- 
info"

2) Relax the requirement that the subject of the signing cert match  
the domain of the From. An SBC would still need a cert, but just the  
one, not one for every possible domain.

3) Replace 4474's discussion of authentication with a discussion of  
verification of an existing identity or Reasserted-Identity header  
field.

4) Add some History-Info extensions to add information about the  
reassertion into the history.

5) Add some flags somewhere to describe different levels of  
verification, such as a) Valid Identity header, b) Learned from PSTN,  
c) unverifiable Identity header, d) from P-Asserted-Identity, etc.

Here's an example:

1) [email-masked] calls [email-masked]

2) The example.com AS authenticates Alice using a mechanism such as  
proxy-authenticate, then adds an appropriate Identity and Identity- 
Info header field.

3) Bob's B2BUA verifies the Identity header field

4) Bob's B2BUA checks the Identity value value against Bob's whitelist  
and chooses to allow the call.

5) But Bob is out, so the B2BUA wants to forward the call to Bob's  
mobile phone. But Bob's administrative policy requires recording the  
call.

Since Bob's administrative policy requires  recording the call, Bob's  
b2bua steers the media through a recorder. This requires either  
"editing the SDP"  or termination of media on the SBC. in either case,  
it is not reasonable to send the existing Identity header on to Bob,  
since it's going to be broken.

6) Bob's B2BUA elides the previous Identity and Identity-Info and adds  
a new Reasserted-Identity and Reasserted-Identity-Info header  field  
to the new request, adds a flag saying that the identity being re- 
asserted was learned from a verified Identity header, then sends it.

7) Bob's mobile sees the new request, knows that it trusts Bob's B2BUA  
as a re-asserter, then checks its whitelist policy and finds that it  
is willing to accept calls from [email-masked] as long as the  
assertion strength is either a direct Identity or a re-asserted  
Identity based on verified Identity.

---

From: "DRAGE, Keith \(Keith\)" <[email-masked]>
Date: Thu, 31 Jul 2008 14:36:53 +0200

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

> Behalf Of Jonathan Rosenberg
> Sent: Thursday, July 31, 2008 11:22 AM
> To: Elwell, John
> Cc: Cullen Jennings; SIP IETF; Uzelac,Adam
> 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.
> 
> 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.
> 
> 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,
> > 
> > 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
> > 
> 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.
> >>
> >> are situations (good, bad or indifferent) that necessitate 
> changes in 
> >> the SDP. John cited media steering as a use case. Another 
> use case is 
> >> engagement", like G729, 2833, t.38, etc.  Ent B and
> 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.
> >>
> >>> This list is for NEW development of the core SIP Protocol Use 
> >>> [email-masked] for questions on current sip Use 
> >>> [email-masked] for new developments on the application of sip
> > This list is for NEW development of the core SIP Protocol Use 
> > [email-masked] for questions on current sip Use 
> > [email-masked] for new developments on the application of sip
> > 
> 
> -- 
> This list is for NEW development of the core SIP Protocol Use 
> [email-masked] for questions on current sip

---

From: Dean Willis <[email-masked]>
Date: Thu, 31 Jul 2008 13:58:46 +0100

> Is this an ATTACK though? I don't think it is.

If the end user can't tell the difference between a malicious  
application of the technique and a beneficial application of the  
technique, then the technique itself is  an attack vector and should  
be eliminated from the protocol.

--
Dean

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 31 Jul 2008 09:06:10 -0400

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

---

From: Adam Roach <[email-masked]>
Date: Thu, 31 Jul 2008 14:14:12 +0100

On 7/31/08 1:49 PM, Dean Willis wrote:
> proxy-authenticate, then adds an appropriate Identity and 
> Identity-Info header field.
>
> to the new request, adds a flag saying that the identity being 
> re-asserted was learned from a verified Identity header, then sends it.
>

Here's the problem... if I trust a B2BUA, it doesn't necessarily mean 
that I'll trust everything it trusts. If Bob's UA is going to make an 
informed choice, we need it to be able to examine a chain of custody for 
the identity, at the very least.

/a

---

From: "Dan Wing" <[email-masked]>
Date: Thu, 31 Jul 2008 14:24:51 +0100

> of codec for 
> wideband codecs 
> the call if 

Thank you - this is the first description of a codec attack that
anyone has explained.

So a beneficial change (adding a codec and doing transcoding for
the user) is okay, but a non-benficial change (removing a good-
sounding codec for the end equipment [wideband] or for the network 
[iSAC]) is an attack?

-d

---

From: "Dan Wing" <[email-masked]>
Date: Thu, 31 Jul 2008 14:24:54 +0100

> security that is / is not associated with it.

So:  to create a requirements document?

-d

---

From: "Dan Wing" <[email-masked]>
Date: Thu, 31 Jul 2008 14:25:19 +0100

> be eliminated from the protocol.

Agreed.

-d

---

From: "DRAGE, Keith \(Keith\)" <[email-masked]>
Date: Thu, 31 Jul 2008 15:29:22 +0200

That is not impossible, but the prime aim of what is proposed is a BCP
giving guidelines for usage of the existing documents. 

If requirements for new work fall out of this, then well and good, in
fact excellent - but that is more along the lines of the BCP discovers
(and documents) that the current behaviour is x and discussion of that
resolves that we actually need y then at that point we have identified a
requirement, which we will want to find some way to document. 

Regards

Keith

> From: Dan Wing [mailto:[email-masked]] 
> Sent: Thursday, July 31, 2008 2:25 PM
> To: DRAGE, Keith (Keith); 'Jonathan Rosenberg'; 'Elwell, John'
> Cc: 'Cullen Jennings'; 'SIP IETF'; 'Uzelac,Adam'
> > 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.
> > 
> > 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.
>

---

From: "Dan Wing" <[email-masked]>
Date: Thu, 31 Jul 2008 14:32:24 +0100

> Behalf Of Dean Willis
> Sent: Thursday, July 31, 2008 1:50 PM
> To: Adam Uzelac; SIP IETF
> Subject: [Sip] Alternative SIP Identity Approach (was re: 
> Thoughts on SIPIdentity)
> 
> 

Any transit service provider could do that today:  they can
claim their equipment is configured to validate incoming
RFC4474 signatures and will modify the From URI to their own
domain and generate their own RFC4474 signature.  They
can claim their equipment will only create RFC4474 signatures
for traffic that already had a valid RFC4474 signature.

-d

---

From: "Dan Wing" <[email-masked]>
Date: Thu, 31 Jul 2008 14:38:51 +0100

> informed choice, we need it to be able to examine a chain of 
> custody for the identity, at the very least.

The chain would be good, but I would be happy with the first link: 
who (claims to have) injected the message into the SIP network.  Even
if the message transited over some itty-bitty ITSP in a country I had
never heard of, it wouldn't matter if I could verify the identity of
who injected the message into the SIP 'cloud'.

-d

---

From: "Dan Wing" <[email-masked]>
Date: Thu, 31 Jul 2008 14:40:45 +0100

> From: DRAGE, Keith (Keith) [mailto:[email-masked]] 
> Sent: Thursday, July 31, 2008 2:29 PM
> To: Dan Wing; Jonathan Rosenberg; Elwell, John

Gotcha.  That would be awesome.

-d

---

From: Adam Roach <[email-masked]>
Date: Thu, 31 Jul 2008 14:51:12 +0100

> who injected the message into the SIP 'cloud'.

Sorry, I was a bit unclear. When I talk about this "chain of custody," I 
mean everything that has performed an action that would invalidate a 
4474 signature; everything that has had to re-sign something. Those are 
the actions that require a level of trust. As long as the ITSP you 
mention doesn't change 4474-protected fields, I don't care who they are.

/a

---

From: "Dan Wing" <[email-masked]>
Date: Thu, 31 Jul 2008 14:56:11 +0100

> From: Adam Roach [mailto:[email-masked]] 
> Sent: Thursday, July 31, 2008 2:51 PM
> To: Dan Wing
> Cc: 'Dean Willis'; 'SIP IETF'; 'Adam Uzelac'
> Subject: Re: [Sip] Alternative SIP Identity Approach (was re: 
> Thoughts on SIP Identity)
> 

Oh, so something like:  "The original list of codecs was G.729,G.711" and to
convey it in such a way that I could re-insert G.729 and validate the original
4474 signature?  And something like "The original m/c line was 1.2.3.4/5678"?

-d

---

From: Adam Roach <[email-masked]>
Date: Thu, 31 Jul 2008 15:30:51 +0100

> 4474 signature?  And something like "The original m/c line was 1.2.3.4/5678"?

Yes, that has the right property -- enough information to reconstruct 
which changes were made, and by whom.

/a

---

From: Jonathan Rosenberg <[email-masked]>
Date: Thu, 31 Jul 2008 11:22:41 -0400

Hmm, well I think almost anything a proxy can legally do, can also be 
applied maliciously. For example, a proxy can:

* change the target of the request to someone not at all expected; e.g., 
I call the sales number for company 1 and it gets forwarded to company 2 
sales number. Frankly, this attack is far worse than any codec change.

* proxy can drop my requests and cause calls to fail

* proxy can insert via headers pointing to incorrect previous hops and 
launch dos attacks

* proxy can modify via fields, causing responses to bypass servers 
providing features, disrupting them

* proxy can discard record-routes in response; causing other servers to 
be bypasses for future requests. Consider the impact of this on a 
billing system that is built off another proxy which now never sees a BYE

and so on. My your metric, since I cannot differentiate legitimate from 
illegitimate uses of modification of these fields (rr, via, r-uri), all 
uses must be prevented.

Clearly this doesn't hold water.

-Jonathan R.

---

From: "Dan Wing" <[email-masked]>
Date: Thu, 31 Jul 2008 17:33:55 +0100

> From: Jonathan Rosenberg [mailto:[email-masked]] 
> Sent: Thursday, July 31, 2008 4:23 PM
> To: Dan Wing
> Cc: 'Dean Willis'; 'Cullen Jennings'; 'SIP IETF'; 
> 'Uzelac,Adam'; 'Elwell,John'

Good point.  I guess you're saying a proxy can be evil, and
a B2BUA can be evil.

4474 only allows detecting if a proxy is evil, based on the
stuff that 4474 signs and considers important.

I (continue to) suggest that we need a way to detect if an
SBC is evil, based on stuff that is signed and is considered
important.

-d

---

From: "Elwell, John" <[email-masked]>
Date: Thu, 31 Jul 2008 17:40:07 +0100

> Sent: 31 July 2008 11:22
> Cc: Uzelac, Adam; Cullen Jennings; SIP IETF
[JRE] I am not sure. But the important thing is that the user be aware
that there is intervention, i.e., that any media security is only as far
as the domain that does the conversion.

John

> think we have 
> only as far as

---

From: "Elwell, John" <[email-masked]>
Date: Thu, 31 Jul 2008 18:25:36 +0100

> Sent: 31 July 2008 13:50
[JRE] But it is still transitive trust, but with the improvement
(compared to PAI) that at least you see the chain of transitive trust.
In that respect, isn't it similar to Hadriel's proposal?

Maybe one situation where this might have some utility is the case where
the intermediary intervenes in the media in a way that involves
decryption, e.g., change of codecs, conference mixing, recording of the
clear media. In this situation we cannot do better than transitive
trust.

But for the case where media is encrypted e2e, identity authentication
needs to be e2e. I am uncomfortable with transitive trust, at least for
cases where one of the signers in the chain is an entity not known to me
or not trusted by me.

John

---

From: Hadriel Kaplan <[email-masked]>
Date: Thu, 31 Jul 2008 16:47:13 -0400

> From: [email-masked] [mailto:[email-masked]] On Behalf Of Dan
> Wing
>

I still don't buy it.  Honestly, exactly how much benefit does an attacker get by "downgrading" your codec?  If there is no benefit/motivation for an attacker, why is this a threat we care about?

Alternatively, there *is* motivation for removing codecs to *improve* your experience - this is in fact done right now in deployed networks, to force calls crossing low-bandwidth WAN links to use lower-bandwidth codecs (e.g., removing g711 in favor of g729, or re-re-ordering them in the m-line).  In those cases the removal is beneficial.

-hadriel

---

From: Eric Rescorla <[email-masked]>
Date: Thu, 31 Jul 2008 13:51:51 -0700

At Thu, 31 Jul 2008 16:47:13 -0400,
Hadriel Kaplan wrote:
> I still don't buy it.  Honestly, exactly how much benefit does an
> attacker get by "downgrading" your codec?  If there is no
> benefit/motivation for an attacker, why is this a threat we care
> about?

Funny you should mention that.

It's becoming increasingly clear that VBR codecs leak a fair
amount of information, even when they are encrypted [WBC+08].
So, if, for instance, you were planning to use a fixed-rate
codec and an attacker could force you into a VBR codec, that
might leak information.

-Ekr

[WBC+08] Charles Wright, Lucas Ballard, Scott Coull, Fabian Monrose,
Gerald Masson, "Spot me if you can: Uncovering spoken phrases in
encrypted VoIP conversations", IEEE Security 2008.
_______________________________________________
Sip mailing list  https://www.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [email-masked] for questions on current sip
Use [email-masked] for new developments on the application of sip

---

From: Hadriel Kaplan <[email-masked]>
Date: Thu, 31 Jul 2008 16:58:44 -0400

> From: [email-masked] [mailto:[email-masked]] On Behalf Of Paul
> Kyzivat
>

If you don't want media intercepted by intermediaries - you need to use DTLS-SRTP+fingerprint or something which prevents interception, or at least prevents interception for the purpose of rendering.

Just because you send your media to an IP Address indicated in the SDP by the far-end UA does NOT mean it is not being intercepted.  RFC 4474 does NOT provide you with media authentication or prevent eavesdropping by signing SDP.  You're not losing something because you didn't have it to begin with.

-hadriel

---

From: Hadriel Kaplan <[email-masked]>
Date: Thu, 31 Jul 2008 20:54:43 -0400

> From: Eric Rescorla [mailto:[email-masked]]
>

Fascinating paper. (truly)  But it sounds more like just a reason to fix SRTP for VBR, through random padding or whatever.

-hadriel

---

From: Eric Rescorla <[email-masked]>
Date: Thu, 31 Jul 2008 18:02:11 -0700

At Thu, 31 Jul 2008 20:54:43 -0400,
Hadriel Kaplan wrote:
> Fascinating paper. (truly) But it sounds more like just a reason to
> fix SRTP for VBR, through random padding or whatever.

I haven't studied the problem, but I suspect random padding
is of limited use because it averages out. Probably better
to use a fixed length codec.

However, I think focusing on that misses the larger point: the UAC and
UAS have certain desires as expressed in the messages/SDP
To the extent to which we allow the intermediaries to change
those messages, we need to carefully analyze each instance,
and this analysis may actually depend on facts yet to be 
discovered.
-Ekr
_______________________________________________
Sip mailing list  https://www.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [email-masked] for questions on current sip
Use [email-masked] for new developments on the application of sip

---

From: "Dan Wing" <[email-masked]>
Date: Fri, 1 Aug 2008 09:36:36 +0100

> and this analysis may actually depend on facts yet to be 

4474 allows intermediaries to change SDP, and re-create a new
>From and a new signature.  This (a) destroys end-to-end identity 
(which is the subject of this thread) *and* (b) allows 
intermediaries to perform the very downgrade attack you
cited ([WBC+08]).

This is why I want to improve upon 4474.

-d

---

From: Hadriel Kaplan <[email-masked]>
Date: Fri, 1 Aug 2008 04:47:15 -0400

> who injected the message into the SIP 'cloud'.

That was kinda my thought for the P-Asserter draft - as much as preventing all mitm cases would be great, not having anything is far worse.  Most of my customers don't care about preventing mitm for identity; if there's a malicious mitm, wrong identity is the *least* of their problems.  What they care more about (I think) is lying originators, open relays, and the like.

In other words they want to prevent SPAM and Phishing and such.  Having a proof of signaling originator Identity alone (ie, the From or something similar) with replay protection and non-repudiation is sufficient for them - they don't need SDP identity, or Call-Id Identity, or CSeq Identity.

-hadriel