Subject: Re: [Sip] Alternative SIP Identity Approach (was re: Thoughts on SIP Identity)

From: Dean Willis <[email-masked]>
Date: Fri, 1 Aug 2008 11:05:15 +0100

On Jul 31, 2008, at 2:14 PM, Adam Roach wrote:

> On 7/31/08 1:49 PM, Dean Willis wrote:
>>
>> 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.
>
>
> 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.
>

Is the stack of "verified by" parameters in history-Info adequate, or  
do you want to be able to check each transitive crypto operation?

If the latter, we'd have to do something like add each pre-edit  
message as a sipfrag body onto the current message. That could make  
for some rather large SIP requests.  Maybe a diff format could make it  
better, but it is still going to get chunky.

--
Dean
_______________________________________________
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: Adam Roach <[email-masked]>
Date: Fri, 01 Aug 2008 11:08:42 +0100

On 8/1/08 11:05 AM, Dean Willis wrote:
>
>>
>> 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.
>>
>

How many editing boxes do you expect in the middle here?

/a

---

From: Dean Willis <[email-masked]>
Date: Fri, 1 Aug 2008 11:12:56 +0100

On Aug 1, 2008, at 11:08 AM, Adam Roach wrote:

>>> make an informed choice, we need it to be able to examine a chain  
>>> of custody for the identity, at the very least.
>>>
>>
>> Is the stack of "verified by" parameters in history-Info adequate,  
>> or do you want to be able to check each transitive crypto operation?
>>
>> for some rather large SIP requests.  Maybe a diff format could make  
>> it better, but it is still going to get chunky.
>

I have no idea. For media steering, four might be a typical case --  
originating, transit entry, transit exit, and terminating SBCs. Worst  
case? Who knows . . .

---

From: Adam Roach <[email-masked]>
Date: Fri, 01 Aug 2008 11:20:02 +0100

> originating, transit entry, transit exit, and terminating SBCs. Worst 

Four media-path relays, you say?

What kind of RTT latency are you envisioning? Is this for a phone-call 
type scenario, or are users expected to resort to saying "over" after 
each speech burst to prevent talking on top of each other?

/a

---

From: Eric Rescorla <[email-masked]>
Date: Fri, 01 Aug 2008 06:46:10 -0700

At Fri, 1 Aug 2008 09:36:36 +0100,
Dan Wing wrote:
> 
> > At Thu, 31 Jul 2008 20:54:43 -0400,
> > Hadriel Kaplan wrote:
> > > 
> > > 
> > > 
> > > > -----Original Message-----
> > > > From: Eric Rescorla [mailto:[email-masked]]
> > > >
> > > > 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.
> > > 
> > > 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.
> 
> 4474 allows intermediaries to change SDP, and re-create a new
> >From and a new signature. 

Well, it allows it in the sense that there's no known
cryptographic way to stop it in any system, then sure.

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

I don't agree with this analysis.

Let's say that [email-masked] sends [email-masked] an INVITE.
It's 4474 signed by atlanta.com. Now, some SBC in the middle
edits the SDP. This breaks the signature. 

At this point, when Bob gets the message, he knows:

(1) This message claims to be from Alice.
(2) The signature was broken.

He therefore has no knowledge of what happen. He can choose to
accept or reject the call, but can't reasonably infer that
the call came from Alice or anything else about Alice's 
intentions.

Now, if the SBC resigns, then Bob gets a valid message
from somebody else other than Alice. Effectively, the
SBC. Now, the SBC claims that it is connecting Bob to
Alice, but it could be lying. If Bob trusts the SBC,
he can accept the call, but he's trusting the SBC.
Sure, the SBC can edit the SDP to replace codecs, but
it can do *anything*. It could, for instance, replace
the DTLS-SRTP fingerprint. This isn't surprising, since
the SBC is really a B2BUA and this is a call from it.

The schemes being proposed here allow the RFC 4474 signature
to survive some editing of the message by the SBC. The
question here is the extent to which that enables *silent*
attacks by the SBC. To take an extreme case, if we allowed
editing of the fingerprint, then Bob could think he was
talking to Alice, but he was actually talking to the
SBC. Editing the codecs to allow this kind of traffic
analysis is a (much) less serious version of the same
threat. Again, this differs qualitatively from the former
case because Bob does not know he is under attack.

The question, then, when someone proposes exempting some
field from the signature, is what silent attacks it enables.
I have yet to see any satisfactory analysis along these
lines.

-Ekr

---

From: Ted Hardie <[email-masked]>
Date: Fri, 1 Aug 2008 15:24:28 +0100

>he can accept the call, but he's trusting the SBC.

This is a far more cogent description of what I suggested
at the mic as "you broke it, you bought it".   It retains
the property that 4474 is meant to provide (it shows
when an SDP was changed), but it provides a mechanism
to allow the SDP to continue to progress with an indication
of who caused the previous signature to break.

The obvious questions that arise ( "Why should I trust
mumblefratz.net's signature over sdp from [email-masked]',
when my provider is rassemfratchit.com"?) are ones we've
seen before in other contexts.  They may seem intractable,
but the blunt truth is that the cryptographic trust issue here
reflects the user trust issues. 

My two cents,
				Ted

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 01 Aug 2008 12:16:36 -0400

What if the SBC did the following:

- made whatever changes it wants to make to the incoming
   request to derive the message it wants to send.

- calculated the reverse diff the transforms its modified
   message into the message it received.

- affixed the reverse diff to the new message as another
   body part.

- signed the whole thing as itself.

- sent it on.

When the UAS receives this, it first validates the signature and decides 
if it trusts the signer.

If so, it may then use the reverse diff to reconstruct the unmodified 
message. It can then validate any signature that may contain to verify 
the actual caller. This can of course be applied recursively.

At any stage it can just decide to trust any assertions made by the 
intermediary.

	Paul

---

From: Padma Valluri <[email-masked]>
Date: Sun, 3 Aug 2008 11:32:05 -0400

I like this approach as this can even be used for inter-carrier-domain 
authentication where the signature introduced by a B2BUA in one domain can 
be trusted by the one in another domain by checking the intermediary IDs 
to say provide priority services. So if there is an RPH header associated 
with this request the receiving domain can honor that value. In the 
absence of such a thing as inter domain authentication, this can be used 
for that purpose without breaking 4474. 

regards,
Padma.

Computer Sciences Corporation 
Registered Office: 3170 Fairview Park Drive, Falls Church, Virginia 22042, 
USA
Registered in Nevada, USA No: C-489-59

-------------------------------------------------------------------------------------------------------------------------------------------------------------------------
This is a PRIVATE message. If you are not the intended recipient, please 
delete without copying and kindly advise us by e-mail of the mistake in 
delivery. 
NOTE: Regardless of content, this e-mail shall not operate to bind CSC to 
any order or other contract unless pursuant to explicit written agreement 
or government initiative expressly permitting the use of e-mail for such 
purpose.
-------------------------------------------------------------------------------------------------------------------------------------------------------------------------

Paul Kyzivat <[email-masked]> 
Sent by: [email-masked]
08/01/2008 12:16 PM

To
Eric Rescorla <[email-masked]>
cc
"'Cullen Jennings'" <[email-masked]>, "'SIP IETF'" <[email-masked]>, 
"'Uzelac,       Adam'" <[email-masked]>, "'Elwell, John'" 
<[email-masked]>, Dan Wing <[email-masked]>
Subject
Re: [Sip] Thoughts on SIP Identity issues

- sent it on.

                 Paul

---

From: "Elwell, John" <[email-masked]>
Date: Tue, 05 Aug 2008 10:01:16 +0100

Eric, 

> Sent: 01 August 2008 14:46
> To: Dan Wing
> Cc: 'Eric Rescorla'; 'Hadriel Kaplan'; 'Jonathan Rosenberg'; 
> Elwell, John; 'Cullen Jennings'; 'SIP IETF'; 'Uzelac, Adam'
> Subject: Re: [Sip] Thoughts on SIP Identity issues
> 
[JRE] I agree so far, but what I really would like to see is some
mechanism by which atlanta.com can sign the request from Alice and that
signature stands a fairly good chance of surviving harmless SBCs in
intermediate domains. We can't do anything about an intermediate domain
that insists on re-signing for the sake of it, or performs some action
that involves decryption of the media (e.g., transcoding, mixing). At
least in such cases Bob will see that the call is secured only as far as
the intermediate domain. But in cases where the intermediate domain is
performing less invasive actions such simple media steering, it should
have some way of doing so without breaking atlanta.com's signature. Then
Bob will not be misled into thinking the call is insecure (i.e., secured
only as far as the intermediate domain) when really it is secured all
the way to Alice's domain and he can indeed talk without fear of an
intermediary eavesdropping or injecting information.

John

---

From: "Elwell, John" <[email-masked]>
Date: Tue, 05 Aug 2008 10:01:16 +0100

Paul,

The problem is, what incentive does the SBC vendor have to go to these
lengths? I really think we need a solution that doesn't require the SBC
to do any more than pass information on transparently. RFC 4474 fits
this criterion, except that it won't work when SBCs do media steering or
make other "harmless" changes to signed information.

John

> From: Paul Kyzivat [mailto:[email-masked]] 
> Sent: 01 August 2008 17:17
> To: Eric Rescorla
> Cc: Dan Wing; 'Cullen Jennings'; 'Uzelac, Adam'; 'SIP IETF'; 
> Elwell, John

---

From: "Dan Wing" <[email-masked]>
Date: Tue, 5 Aug 2008 06:43:47 -0700

John,

I agree the intermediate service providers have no incentive to do more work.
This is especially true if we are expecting them to do lots of validation and
signing.  They will just do P-Asserted-Identity -- like they are doing today
by just extended the trust domain farther than the IETF had intended.

Paul's idea requires the service provider to disclose all of the SPs that
provided transit.  I do not expect a service provider to disclose that
information; the path of the SIP messages through the SIP network is one of
the pieces of information they consider proprietary.  Thing is, we don't need
to know the path, nor what every single entity changed along the path, in
order to provide end-to-end identity (neither of the two proposals on the
table require knowing the path).

-d

> From: Elwell, John [mailto:[email-masked]] 
> Sent: Tuesday, August 05, 2008 2:01 AM
> To: Paul Kyzivat; Eric Rescorla
> Cc: Dan Wing; Cullen Jennings; Uzelac, Adam; SIP IETF
> Subject: RE: [Sip] Thoughts on SIP Identity issues
> 
> Paul,
>

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 05 Aug 2008 09:47:13 -0400

> make other "harmless" changes to signed information.

Well, the issue is that it doesn't work in these cases, isn't it? What I 
suggest would solve that issue without fundamentally changing the way 
4474 works. (Without reducing the protection provided by the signature.)

Why would the SBC do it? So that the recipient wants a way to accurately 
verify the origin of the request. If the organization deploying the SBC 
doesn't want to honor the best interests of the sender and receiver then 
I guess it may choose not to do this. I guess this would be most likely 
in cases where a transit SP or the destination SP decides to obfuscate 
the originating address.

	Thanks,
	Paul

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 05 Aug 2008 07:59:45 -0700

At Tue, 05 Aug 2008 10:01:16 +0100,
> intermediary eavesdropping or injecting information.

Sure, but again, that requires examining every single piece of the message
which you wish to exampt from the signature and determine whether
there is some important attack that can be mounted by modifying
that section. As I noted above, those questions are not necessarily
immediately apparent.

-Ekr

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 05 Aug 2008 08:03:01 -0700

At Fri, 01 Aug 2008 12:16:36 -0400,
> At any stage it can just decide to trust any assertions made by the 

The problem I see with this approach is that it then requires the
UAS to make fairly sophisticated decisions about what changes are
OK and what are not. If we can't make those judgements here in
the SIP WG, I don't see how implementors can be expected to.

-Ekr

---

From: "Dan Wing" <[email-masked]>
Date: Tue, 5 Aug 2008 07:56:12 -0700

...
> that section. As I noted above, those questions are not necessarily

Implicit in that argument is that 4474 got it right.

We know it already isn't done correctly with RFC4474 for unidirectional media
(draft-kaplan-sip-baiting-attack).  To get bi-directional media, an attacker
would need to share a NAT or a TURN server with the identity they want to
spoof (e.g., a bank, a pizza restaurant, a political organization), and the
attacker would need to obtain the same UDP port from the NAT or TURN server
within RFC4474's replay window (which is recommended to be 10 minutes).

-d

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 05 Aug 2008 08:13:33 -0700

At Tue, 5 Aug 2008 07:56:12 -0700,
> Implicit in that argument is that 4474 got it right.

No, I don't think that's true. 4474 did the conservative thing: it
signed everything.

> within RFC4474's replay window (which is recommended to be 10 minutes).

I haven't spent a long time examining draft-kaplan-sip-baiting, but as
I recall, it's not the fault of 4474 failing to sign something that
it should have but rather that it's inherent in the message-oriented 
nature of SIP.

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.

-Ekr

---

From: "Dan Wing" <[email-masked]>
Date: Tue, 5 Aug 2008 08:54:16 -0700

> Sent: Tuesday, August 05, 2008 8:14 AM
> To: Dan Wing
> Cc: 'Eric Rescorla'; 'Elwell, John'; 'Hadriel Kaplan'; 
> 'Jonathan Rosenberg'; 'Cullen Jennings'; 'SIP IETF'; 'Uzelac, Adam'

That distinction is not relevant to the victim.

> extent there is one) in this case is that it doesn't protect

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.

-d

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 05 Aug 2008 09:11:09 -0700

At Tue, 5 Aug 2008 08:54:16 -0700,
> That distinction is not relevant to the victim.

No, the distinction is relevant to the people responsible for technically
addressing the issue, namely us.

> is far stronger than just using the IP address of the remote party 

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 and leaves the question of authenticating the media to other
parts of the system. 

-Ekr

---

From: Dean Willis <[email-masked]>
Date: Tue, 05 Aug 2008 11:17:14 -0500

> each speech burst to prevent talking on top of each other?

I'd expect a well-designed steering relay to have a latency just above
double the serialization delay of a packet across its interfaces. for
commercial-grade stuff, that's less than a millisecond.

That should work for everybody except perhaps an EKR talking to himself
on the phone.

Really, we're talking something that's basically a router. It just
learns its routing tables from an entirely different mechanism than OSPF
or BGP. Are the routers on the Internet cramping your speech style now?

--
Dean

---

From: Dean Willis <[email-masked]>
Date: Tue, 05 Aug 2008 11:20:36 -0500

> - signed the whole thing as itself.

That's more or less been proposed several times. It seems to solve all
requirements save one -- it doesn't work over SIP as we know it, because
the packets are going to get freaking huge.

Deprecate UDP now?

---

From: Dean Willis <[email-masked]>
Date: Tue, 05 Aug 2008 11:30:34 -0500

> make other "harmless" changes to signed information.

The problem is that if the SBC has the power to arbitrarily rewrite the
contents of the message, then  it is potentially doing much more than
just "pass information on transparently". If it was transparent, it
would be a proxy, not an SBC!

The "right" way to do what we seem to want here probably involves adding
a routing protocol layer to RTP. That, however, makes for a very
different architecture from what we have now.

---

From: "Dan Wing" <[email-masked]>
Date: Tue, 5 Aug 2008 10:26:26 -0700

> Sent: Tuesday, August 05, 2008 9:11 AM
> To: Dan Wing
> No, the distinction is relevant to the people responsible for 
> technically addressing the issue, namely us.

My interpretation of what you are saying is "SIP is message-
oriented, so SIP is vulnerable to baiting as described in
draft-kaplan-sip-baiting, and we can't fix it".  

I don't know if that is what you intended to say; if not, 
please clarify.

> SDP 

Which draft-kaplan-sip-baiting shows is insufficient at its intended
purpose.

> and leaves the question of authenticating the media to other
> parts of the system. 

-d

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 05 Aug 2008 13:47:56 -0700

>At Tue, 5 Aug 2008 10:26:26 -0700,
> I don't know if that is what you intended to say; if not, 

What I'm saying is that a message-oriented system like SIP inherently
has replay attacks. If you want to remove replay attacks, you'll
need to do it at a separate layer.

> Which draft-kaplan-sip-baiting shows is insufficient at its intended

Well, I guess that's one interpretation, but it's not mine.

-Ekr

---

From: "Dan Wing" <[email-masked]>
Date: Tue, 5 Aug 2008 13:57:34 -0700

> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Eric Rescorla
> Sent: Tuesday, August 05, 2008 1:48 PM
> To: Dan Wing
> Cc: 'Cullen Jennings'; 'Uzelac,Adam'; 'SIP IETF'; 'Elwell, John'

And both draft-fischer-sip-e2e-sec-media and draft-wing-sip-identity-media
provide the security at a separate layer:  the media layer.

> Well, I guess that's one interpretation, but it's not mine.

Yes, I understand it is not your view.

-d

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 05 Aug 2008 20:53:33 -0700

At Tue, 5 Aug 2008 13:57:34 -0700,
> provide the security at a separate layer:  the media layer.

Unfortunately, this is the same conflation of concerns that has
characterized discussion of these drafts from the beginning. Quoting
my review of -01 from 2007/11:

  This draft seems to do two distinct things:
  
  - One specify a variant of RFC 4474 which signs a lot fewer headers.
    [This should have said less of the message -- EKR]
  - Specify a set of mechanisms to cryptographically prove that a given media
    stream corresponds to a given SDP offer/answer.

These issues are wholly orthogonal and it just confuses the discussion
to try to discuss them together. If the WG thinks it's important to
prevent the Baiting attack then we can discuss mechanisms for that.
However, I'd note that I didn't see anyone arguing for that in Dublin,
so I question whether it is in fact something people care about
much. [For my part, I don't think that it's important to do so in the
absence of DTLS-SRTP, where it's more or less automatically blocked.]
However, those mechanisms can be introduced without modifying the
procedures of RFC 4474.

This brings us back to the idea of exempting more of the message
from the signature, which would require modifications to RFC 4474.
Again, this may (or may not) be something we need to do, but I
don't see that the Baiting attack is an argument for doing so.
(Though I would note that removing some properties of the message,
such as Call-Id, from the signature, will probably make replay
attacks easier to mount).

-Ekr

---

From: Cullen Jennings <[email-masked]>
Date: Tue, 5 Aug 2008 19:53:43 -0700

> Which draft-kaplan-sip-baiting shows is insufficient at its intended

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?

I'm trying to focus this conversation over to the requirements instead  
of the taking about solution mechanisms before we can agree what the  
problem is.

Cullen <in my individual contributor role>

---

From: Cullen Jennings <[email-masked]>
Date: Tue, 5 Aug 2008 20:05:34 -0700

On Aug 1, 2008, at 3:20 , Adam Roach wrote:

>> originating, transit entry, transit exit, and terminating SBCs.  
>> Worst case? Who knows . . .
>
> What kind of RTT latency are you envisioning? Is this for a phone- 
> call type scenario, or are users expected to resort to saying "over"  
> after each speech burst to prevent talking on top of each other?
>
> /a

Keep in mind it needs to work in the very common case where Alice and  
Bob both phone into a conference bridge. So I suspect it could be more  
like 9 hops.

---

From: Cullen Jennings <[email-masked]>
Date: Wed, 6 Aug 2008 06:50:26 -0700

On Jul 31, 2008, at 7:30 , Adam Roach wrote:

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

That might be the right property but on the other hand,  there is a  
big difference between the two following properties of a system.

1) the receiver can tell what intermediaries made changes and what  
changes were made

2) the sender was aware of, and authorized, the changes made by  
intermediaries

I can see ways we could build either of these. But right now it seem  
unclear on what we are even trying to accomplish.

Cullen <with my individual contributor hat on>

---

From: Cullen Jennings <[email-masked]>
Date: Tue, 5 Aug 2008 19:57:55 -0700

No, I was very clear on the conference calls we had on this that I  
want to get all the things that are broken on the table. Without  
understanding the whole picture, we will just build a hodge podge of  
solutions that can't be simultaneous combined to solve a bunch of the  
problems.

On Jul 30, 2008, at 5:33 , Hadriel Kaplan wrote:

>
> 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: [email-masked] [mailto:[email-masked]] On Behalf Of
>> Cullen Jennings
>>
>> 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: Cullen Jennings <[email-masked]>
Date: Wed, 6 Aug 2008 06:56:21 -0700

> different architecture from what we have now.

Our NAT traversal story for SIP more or less has formed a routing  
system for RTP so this might not be that far off.

---

From: "Dan Wing" <[email-masked]>
Date: Wed, 6 Aug 2008 09:29:51 -0700

> From: Cullen Jennings [mailto:[email-masked]] 
> Sent: Wednesday, August 06, 2008 6:50 AM
> To: Adam Roach
> Cc: Dan Wing; 'SIP IETF'; 'Adam Uzelac'; 'Dean Willis'
> Subject: Re: [Sip] Alternative SIP Identity Approach (was re: 
> Thoughts on SIP Identity)
> 
> 

I would like to accomplish end-to-end identity through SBCs, rather
than hop-by-hop identity that exists with today's RFC4474 through SBCs.

-d

---

From: "Dan Wing" <[email-masked]>
Date: Wed, 6 Aug 2008 09:29:13 -0700

> Sent: Tuesday, August 05, 2008 7:54 PM
> To: Dan Wing
> 'Jonathan Rosenberg'; 'SIP IETF'; 'Uzelac, Adam'

The purpose of 4474 is to identity the calling party.  I believe that
is its primary purpose.

The baiting draft describes how an attacker can use a validly-signed
4474 message to fool a victim into thinking the calling party is
calling them.

> Cullen <in my individual contributor role>

Thanks.

-d

---

From: Dean Willis <[email-masked]>
Date: Wed, 06 Aug 2008 11:51:28 -0500

Eric Rescorla wrote:

> to try to discuss them together. 

They may be wholly orthogonal from one point of view, but I don't think
they can be deployed independently. You have to have BOTH measures in
place to gain the benefit of the proposal.

--
dean

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 06 Aug 2008 10:18:01 -0700

At Wed, 06 Aug 2008 11:51:28 -0500,
> place to gain the benefit of the proposal.

I don't see how that's the case. Can you explain?

-Ekr

---

From: "Dan Wing" <[email-masked]>
Date: Wed, 6 Aug 2008 10:16:18 -0700

> place to gain the benefit of the proposal.

Right.

-d

---

From: "Uzelac, Adam" <[email-masked]>
Date: Wed, 6 Aug 2008 14:17:39 -0400

> than hop-by-hop identity that exists with today's RFC4474 through SBCs.

I agree with Dan here that end-to-end identity through SBCs should be the main driver. A world exists today where intermediaries are modifying signed information, and such modifications breaks RFC 4474 signatures. I understand that omitting elements that are signed leaves security gaps, but the reality is that these modifications are being done for reasons that are valid for all parties involved, mainly to complete the call.  Without permitting these changes to occur only ensure that 4474 will not enjoy mass adoption.

Adam

---

From: Dean Willis <[email-masked]>
Date: Wed, 06 Aug 2008 22:37:45 -0500

> I don't see how that's the case. Can you explain?

Signing LESS than what RFC 4474 signs opens up a whole can of worms
UNLESS the media-path key exchange is also used to prove that the
signaling and media correspond.

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 06 Aug 2008 21:20:43 -0700

At Wed, 06 Aug 2008 22:37:45 -0500,
> signaling and media correspond.

Hmm... In the absence of media layer encryption, I think it's a
mistake to assume that the signalling and media correspond 
even with 4474.

-Ekr

---

From: Eric Rescorla <[email-masked]>
Date: Thu, 07 Aug 2008 11:52:57 -0700

At Wed, 6 Aug 2008 09:29:13 -0700,
Dan Wing wrote:
> 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. 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.

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

-Ekr

---

From: "Dan Wing" <[email-masked]>
Date: Fri, 8 Aug 2008 19:20:14 -0700

> 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'
> of the media.

Yes, of course.

> For instance, if the attacker can convince Alice

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.

> draft-wing-sip-identity-media.

Yes, absolutely agreed.

> 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