Subject: RE: [Sip] Ciphersuites in SIP

From: "Samir Srivastava" <[email-masked]>
Date: Fri, 4 Aug 2006 18:00:22 -0500

Hi Eric,
  
>You do realize that people's phone numbers are basically public
>information and that you can buy CDs with lists of people's
>names and numbers, right?

I disagree. If I buy a privacy service from my provider, then it is not
available to public. I had earlier the service from the SBC with don't
list, alking caller name  when callerId cannot be found to avoid blank
calls.

You can argue for the Don't call list also. But these don't apply in
certain countries. It is big political issues to get it working there.
VoIP makes it lucrative for them to call from other countries... 
 
Apart from spammers, what about the call pattern tracking etc?

>I don't find this argument about cheating proxies at all convincing.

>Consider the following chain of SIP agents:

>Alice --- Atlanta --- Alberta --- Biloxi -- Bob

>Now, imagine that Alberta is a cheating proxy and wishes to use
>a weak cipher suite to connect to Biloxi. Because Biloxi inserts
>the information about what cipher suite was used, Bob is aware
>of the algorithms. However, he doesn't know what Alice actually
>wanted. Maybe Alice *wanted* those weak algorithms. On the
>other hand, Alice's only information about what algorithms were
>used comes through Alberta, so it can't tell that Alberta is
>cheating.

Your argument assumes that you are not using a separate header with
Alice's wish list. It assumes your intersection approach correct. Or Am
I missing something.

If Alberta is cheating, And Biloxi is watcher, then Biloxi can check by
comparing the actual cipher-suite used at the TLS layer, cipher suite
inserted in the via header, and the Alice supplied cipher-suite in a
header. Biloxi can reject the request. It doesn't go any further hops.
And Alice can know about this by inspecting the complete reverse
channel.  In the reverse channel we have the complete message trail from
the via header of the request.

>Once again, the basic assumption behind SIPS security is that
>the proxies are trusted. Attempts to patch this without using
>end-to-end mechanisms seem likely to fail.

Proxies should be trusted but up-to what level. We need to consider
which trust is breaking what. What about the misconfigured/buggy/bad
stuff. Do you want to say good bye to CS SIP and wait till we develop
pure P2P SIP ... Group what is your position ?

Thx
Samir

_______________________________________________
Sip mailing list  https://www1.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: Fri, 04 Aug 2006 16:15:44 -0700

> list, alking caller name  when callerId cannot be found to avoid blank

It's not purely a matter of what shows up on the caller-id
screen. You can buy databases of unlisted numbers as well.

> the via header of the request.

The proxy in the middle just changes the headers.

> stuff. 

What about it? As I stated previously, there are any number of
ways for such a proxy to screw up.

> Do you want to say good bye to CS SIP and wait till we develop

If you want to do P2P SIP, then you better find some way to get
an end-to-end channel to the peer.

-Ekr

---

From: "Samir Srivastava" <[email-masked]>
Date: Fri, 4 Aug 2006 19:39:07 -0500

Hi Eric,

> screen. You can buy databases of unlisted numbers as well.

It's like email spammers selling their attended email addresses. I don't
want to comment on the legality aspects of this here.

> The proxy in the middle just changes the headers.

This header should be part of hash computations like used in Identity.
So any middle-man tampering can be caught. Though it assumes that UAS is
most trustworthy. Providers providing the services (making money) have
more reasons to become cheater. End users don't have this motivation.

> ways for such a proxy to screw up.

My only argument here is that bugs at other places are no excuse for not
addressing the issues which have a solution on the table.
If proxy is generating the bad random numbers etc, then I *WISH* my
IDS/IPS should catch it. People might attack on these stuff when they
have other bigger issues sorted out.

Thx
Samir

---

From: "Hadriel Kaplan" <[email-masked]>
Date: Fri, 4 Aug 2006 21:47:11 -0400

> -----Original Message-----
> From: Samir Srivastava [mailto:[email-masked]]
> 
 
Spammers don't care about you.  If your number is not listed on any database
(fat chance of that, BTW), they won't call you.  That doesn't stop them from
spamming.  Their goal is broad coverage, not a specific individual.  If no
one's number was in a database, then few people would be able to
communicate.  And spamming would still be possible, since they can simply
war-dial/number-scan - the issue is how to detect+stop them, not hope you
keep lists of fixed-length numbers from them.  IMO, preventing Spam is an
orthogonal issue to ensuring end-end eavesdropping protection,
authentication, etc.

> header. Biloxi can reject the request. It doesn't go any further hops.

You're assuming Biloxi will do this, because you're assuming it has an
incentive to reject the request.  It's quite the opposite.  Biloxi has a
relationship with Alberta.  Biloxi makes money from Alberta.  If Alberta
doesn't want to use a ciphersuite of some UAC's choosing, Biloxi's going to
agree with Alberta, not the UAC.  

-hadriel

---

From: "Hadriel Kaplan" <[email-masked]>
Date: Fri, 4 Aug 2006 22:23:37 -0400

> want to comment on the legality aspects of this here.

Not to belabor the point of spamming, because I really don't think that's
the benefit of assured hop-by-hop encrypt, but email spamming needs lists
because the target name@domain is so variable. (yes, I know they probe too)

Spamming e164's is far easier without a list, because the target is a very
finite set: fixed-length integers of specific pattern ranges.  What's worse,
they're generally allocated in blocks, so the range is not very big and the
domain can be inferred.  If we can get broad use of real alphanum sip uri's,
then we're back to lists becoming more useful.
Anyway... back on topic.

> more reasons to become cheater. End users don't have this motivation.

But you just pointed out the flaw.  Providers have an incentive to "cheat":
they want the call to succeed so they get paid. 

So imagine 2 providers in the middle.  They decide to connect over an L2 VPN
through a carrier, which they've been told is "secure".  A request comes
through that says "use TLS".  Do you think they're going to reject it?  No.
Then they find out some Via gave them away.  So do you think they're going
to set their proxies to remove/modify their Via's, or start using TLS
instead?  My guess is the former.  

Obviously some providers will do the right thing.  But those are the ones
that will probably use TLS or IPSec anyway and you don't need this mechanism
to defend against.

-hadriel

---

From: "Joel M. Halpern" <[email-masked]>
Date: Fri, 04 Aug 2006 23:23:12 -0400

In fact, what this example points out is that having the end user 
request that two intermediaries use TLS is actually making the wrong request.

1) If the user really wants to ensure that the call is protected on 
every hop, he should arrange for end-to-end protection.
2) If the user wants to request that proxies use security of 
appropriate strength, that is what should be requested.  The user 
ought not actually care whether the proxies used TLS, IPSec, or a new 
and different technique that is just as secure.

And, as has been pointed out, colluding pairs of proxies can lie 
about almost anything unless one uses end-to-end mechanisms.  So 
providing ways for one of a pair of proxies to check the other seems 
to address a small concern.

I think that the concern over excessive complexity for a solution to 
a small piece of a problem is well taken.

Yours,
Joel M. Halpern

---

From: "Vijay K. Gurbani" <[email-masked]>
Date: Tue, 05 Sep 2006 21:42:18 -0500

> an end-to-end channel to the peer.

sipsec URI?

- vijay
-- 
Vijay K. Gurbani  vkg@{lucent.com,research.bell-labs.com,acm.org}
Bell Laboratories, Lucent Technologies, Inc.
2701 Lucent Lane, Rm. 9F-546, Lisle, Illinois 60532 (USA)

---

From: Eric Rescorla <[email-masked]>
Date: Sat, 05 Aug 2006 19:47:55 -0700

>> an end-to-end channel to the peer.

Huh?

-Ekr

---

From: "Vijay K. Gurbani" <[email-masked]>
Date: Tue, 05 Sep 2006 21:50:58 -0500

> Huh?

Sorry; we had discussed this in the SIP security ad-hoc in
Montreal.  Establishing a security tunnel across proxies to
exchange certs end-to-end:
http://www.ietf.org/internet-drafts/draft-gurbani-sip-sipsec-00.txt

Thanks,

- vijay

---

From: "Samir Srivastava" <[email-masked]>
Date: Mon, 7 Aug 2006 14:07:46 -0500

Hi Vijay,

    As per our off-list discussion on the SIPSEC URI before the meeting,
you had one method CONNECT which traverses across the SIP proxies, what
information is passed in that. This information is of concern.

Thx
Samir 

> From: Vijay K. Gurbani [mailto:[email-masked]] 
> Sent: Tuesday, September 05, 2006 7:51 PM
> To: EKR
> Cc: [email-masked]
> Subject: Re: [Sip] Ciphersuites in SIP
> 
> Eric Rescorla wrote:
> > Huh?
> 
> This list is for NEW development of the core SIP Protocol Use 
> [email-masked] for questions on current sip

---

From: Michael Thomas <[email-masked]>
Date: Mon, 07 Aug 2006 12:09:03 -0700

> http://www.ietf.org/internet-drafts/draft-gurbani-sip-sipsec-00.txt

Speaking of which, have I missed the notes from that meeting?

       Mike

---

From: "Samir Srivastava" <[email-masked]>
Date: Mon, 7 Aug 2006 15:13:05 -0500

Hi Hadriel,

   Thx for your comments. See in -line below.

Thx
Samir

>  
> Spammers don't care about you.  If your number is not listed 
> on any database (fat chance of that, BTW), they won't call 
> you.  That doesn't stop them from spamming.  Their goal is 
> broad coverage, not a specific individual.  If no one's 
> number was in a database, then few people would be able to 
> communicate.  And spamming would still be possible, since 
> they can simply war-dial/number-scan - the issue is how to 
> detect+stop them, not hope you keep lists of fixed-length 
> numbers from them.  IMO, preventing Spam is an orthogonal 
> issue to ensuring end-end eavesdropping protection, 
> authentication, etc.

Writing email addresses in obfuscated form is temporarily measure for
avoiding spammers to learn the attended / valid email addresses from
scanning on the web etc. Email addresses also within a domain can be
found. Valid domain are known too everybody. And they can war emailed
too.  Spammers can do war-dialing too. But here they can know the
attended no / URI rightaway. Less secure hops open up the details which
can be used for various purposes, URI/no learning is one of it. If my
SBC can find out that a source is war dialing / scanning URI, then it
can right away stop those war dialing/ URI scanning requests. I would
expect this from the good edge protection device (SBC/Edge Firewalls
etc). This is very similar to port scanning, which is avoided by the
firewalls.

> You're assuming Biloxi will do this, because you're assuming 
> it has an incentive to reject the request.  It's quite the 
> opposite.  Biloxi has a relationship with Alberta.  Biloxi 
> makes money from Alberta.  If Alberta doesn't want to use a 
> ciphersuite of some UAC's choosing, Biloxi's going to agree 
> with Alberta, not the UAC.  
> 

Let me first draw the diagram

I don't agree with you here at all. Biloxi does support the cipher-suite
asked by Alice, these cipher-suites are ordered with qValued also.
Biloxi charges here more for AES256 (more resources etc) and it is
supported between Alberta and Biloxi. AES256 is the most preferred
cipher-suite by the UAC also as indicated in the header. If Alberta uses
the 40 bit or 3DES etc stuff, then biloxi is loosing the money. So why
Biloxi will co-operate with Alberta here ? Am I missing something here.

---

From: Dean Willis <[email-masked]>
Date: Mon, 7 Aug 2006 15:26:39 -0500

> Speaking of which, have I missed the notes from that meeting?

http://www.softarmor.com/sipwg/meets/ietf66/notes/minutes-sip- 
ietf66.html

--
Dean

---

From: "Vijay K. Gurbani" <[email-masked]>
Date: Mon, 07 Aug 2006 16:15:34 -0500

Samir Srivastava wrote:
> information is passed in that.

As much as, or as little as you want.  Since this is still a
work in progress, nothing is nailed down at this point in time.
I expect that future revisions of the draft will be more specific.

Thanks.

- vijay

---

From: "Hadriel Kaplan" <[email-masked]>
Date: Mon, 7 Aug 2006 18:57:04 -0400

Hi Samir, comments inline...

> can be used for various purposes, URI/no learning is one of it. 

I think I already mentioned why e164's just don't benefit from it as email
addresses do.  But even for email, do you think the spammers get their
addresses by sniffing SMTP links?  (I'm honestly curious - do they do that?)
I would think they'd just harvest them from lists-dealers and mailing-list
archives and such.  

> If my

I assume most SBCs can already do that. (it's not a new idea)  At least from
consumer phones they can.  But stopping this from peers is incredibly
difficult in the real world, with the exception of trivial spit scenarios;
and if you consider false-positives unacceptable (which I do).  Whether
numbers are public sniffed or not doesn't really help - it's really
orthogonal, IMHO.

> Biloxi will co-operate with Alberta here ? Am I missing something here.

Well, it would certainly be a new idea: let UACs else-where make Alberta pay
Biloxi more money by the ciphersuite they ask for.  In fact I sense a
money-making scheme here somewhere, like where Biloxi hires people to use
UACs expressly to do this all day long. :)  Unless you mean Alberta would
then charge more for it, and pass the costs back to Alice, which would
certainly discourage Alice from using strong ciphersuites.  Not so good. 

I really don't think we'd want to have a relationship between ciphersuites
to charging models, because it would be a dis-incentive; nor is there such a
model today AFAIK.  

Biloxi cooperates with Alberta because Alberta is Biloxi's customer, not
Alice.  The idea that Alice can co-opt Biloxi against Alberta is very
strange to me, and not one Alberta is going to allow anyway.  

-hadriel

---

From: "Samir Srivastava" <[email-masked]>
Date: Mon, 7 Aug 2006 18:16:26 -0500

Hi Hadriel,

   Response in line below.

Thx
Samir

> Not to belabor the point of spamming, because I really don't 
> think that's the benefit of assured hop-by-hop encrypt, but 
> email spamming needs lists because the target name@domain is 
> so variable. (yes, I know they probe too)
> 
> Spamming e164's is far easier without a list, because the 
> target is a very finite set: fixed-length integers of 
> specific pattern ranges.  What's worse, they're generally 
> allocated in blocks, so the range is not very big and the 
> domain can be inferred.  If we can get broad use of real 
> alphanum sip uri's, then we're back to lists becoming more useful.
> Anyway... back on topic.

In another thread. I responded on this.

> > So any middle-man tampering can be caught. Though it 
> assumes that UAS 
> > is most trustworthy. Providers providing the services 
> (making money) 
> > have more reasons to become cheater. End users don't have 
> this motivation.
> 
> So imagine 2 providers in the middle.  They decide to connect 
> over an L2 VPN through a carrier, which they've been told is 
> "secure".  A request comes through that says "use TLS".  Do 
> you think they're going to reject it?  No.
> Then they find out some Via gave them away.  So do you think 
> they're going to set their proxies to remove/modify their 
> Via's, or start using TLS instead?  My guess is the former.  
> 
  
  Extending this mechanism to IPSEC is an OPEN ISSUE as per the draft. I
am not an IPSEC expert. I don't know how difficult is to get
cipher-suite info from kernel space to user space etc..
On a side note, I view VPN tunnels as a temporarily measure. It is not
optimized for multimedia stuff. IMHO, eventually provider will move to
TLS and SRTP. There have been some discussions on this in VOIPSEC list
sometime back.

> Obviously some providers will do the right thing.  But those 
> are the ones that will probably use TLS or IPSec anyway and 
> you don't need this mechanism to defend against.
  
  Level of security is important stuff. 40 bit stuff is not equal to
AES256. And we have AES 128 as mandatory cipher-suite as per 3261. So
how can I get AES256 at each hop, without specifying explicitly.
  When I started looking into this, I was looking into the future
proofness of this stuff. Then I figured out this use also. I will open
another thread later for FUTURE proofness. It didn't get any
discussions.

---

From: "Hadriel Kaplan" <[email-masked]>
Date: Mon, 7 Aug 2006 22:01:57 -0400

Hi Samir, more comments...

> TLS and SRTP. There have been some discussions on this in VOIPSEC list

IPSEC is not only about VPN tunnels.  It has transport mode as well. (and
likewise, there are such things as SSL VPNs)  Even in tunnel mode ipsec may
be as secure as TLS, and only applied to signaling (and just as "optimized
for multimedia stuff"). 

I was actually using the L2-VPN as an example because it's considered secure
by some folks, yet others consider it not at all, and some of that depends
on the implementation details.  Even TLS somewhat depends on the
implementation details (e.g., there are TLS-off-loaders, which some people
think is secure while others not).  The point, though, is that there are
numerous implementation details no UAC would be able to articulate, and it's
a hop-by-hop decision what "secure" means - and that's the big rub.  

If you add IPSec as another option, and some UAC encodes only TLS while
another only IPSec, then a provider has to have both IPSec and TLS?? 
Will you specify key exchange and re-keying policies as well? 
And RNG algorithms?  And who the CA can be?  And where they store the
private keys?  And how they secure the box?  Etc., etc.  
Focusing on key-length seems odd to me.

> how can I get AES256 at each hop, without specifying explicitly.

You can't, and you won't, IMO.  If they're doing 40-bit vs. 128 there is
probably some legitimate reason (I hope).  I guess it would be novel to use
SIP as a "did you know there's 256-bit now?" notification check, for the
providers that decided to support the proxy-require mechanism, but I can't
imagine this would do anything but cause headaches for UACs and proxies and
providers and people would just turn it off.  I just think it raises another
bar to implementing hop-by-hop encrypt+auth, for which we're struggling to
get people past the first bar.  My 2 cents anyway.

-hadriel

---

From: "Samir Srivastava" <[email-masked]>
Date: Tue, 8 Aug 2006 02:54:53 -0500

Hi Hadriel,

   Thx for your comments.
   I will consider IPSEC issue, when group arrives on the consensus
(Even rough in IETF terms) for cipher-suite, Secure Transport Protocol
Name (TLS, DTLS, any other future...), versions etc exposed to SIP.
 
   Then I will see how TLS to IPSEC and vice versa and applicability to
IPSEC ..

Thx
Samir

> From: Hadriel Kaplan [mailto:[email-masked]] 
> Sent: Monday, August 07, 2006 7:02 PM
> To: Srivastava, Samir (SC100:8826)
> Cc: [email-masked]
> Subject: RE: [Sip] Ciphersuites in SIP
> 
> >   Extending this mechanism to IPSEC is an OPEN ISSUE as per 
> the draft. 
> > I am not an IPSEC expert. I don't know how difficult is to get 
> IPSEC is not only about VPN tunnels.  It has transport mode 
> as well. (and likewise, there are such things as SSL VPNs)  
> Even in tunnel mode ipsec may be as secure as TLS, and only 
> applied to signaling (and just as "optimized for multimedia stuff"). 
> 
> I was actually using the L2-VPN as an example because it's 
> considered secure by some folks, yet others consider it not 
> at all, and some of that depends on the implementation 
> details.  Even TLS somewhat depends on the implementation 
> details (e.g., there are TLS-off-loaders, which some people 
> think is secure while others not).  The point, though, is 
> that there are numerous implementation details no UAC would 
> be able to articulate, and it's a hop-by-hop decision what 
> "secure" means - and that's the big rub.  
> 
> If you add IPSec as another option, and some UAC encodes only 
> TLS while another only IPSec, then a provider has to have 
> both IPSec and TLS?? 
> And RNG algorithms?  And who the CA can be?  And where they 
> store the private keys?  And how they secure the box?  Etc., etc.  
> > > Obviously some providers will do the right thing.  But 
> those are the 
> > > ones that will probably use TLS or IPSec anyway and you 
> don't need 
> > > this mechanism to defend against.
> > 
> You can't, and you won't, IMO.  If they're doing 40-bit vs. 
> 128 there is probably some legitimate reason (I hope).  I 
> guess it would be novel to use SIP as a "did you know there's 
> 256-bit now?" notification check, for the providers that 
> decided to support the proxy-require mechanism, but I can't 
> imagine this would do anything but cause headaches for UACs 
> and proxies and providers and people would just turn it off.  
> I just think it raises another bar to implementing hop-by-hop 
> encrypt+auth, for which we're struggling to get people past 
> the first bar.  My 2 cents anyway.
> 
> -hadriel
> 
> 
>

---

From: "Samir Srivastava" <[email-masked]>
Date: Tue, 8 Aug 2006 03:02:50 -0500

Hi Hadriel,

  Sorry, I missed the second comment in the last response 

Thx
Samir

> the first bar.  My 2 cents anyway.

Let me draw some parallel, I feel more comfortable when my virus scanner
tells me it is up-to-date and there is no virus on my PC. The same will
apply to dynamic nature of security-level in TLS with different
versions/cipher-suites etc. It will be always N+1 game.

---

From: Cullen Jennings <[email-masked]>
Date: Tue, 8 Aug 2006 09:47:27 -0700

I have read this whole thread and I have to admit, I don't understand  
what people think the problem is that this would solve.

One problem I have seen is providing end to end security. I don' see  
how this could ever do that.

The other problem I have seen is that this would stop a proxy from  
using an TLS cipher on some middle hop that was unacceptable to the  
UAC. Again, I don't see how this would accomplish that or what  
piratical problem that solves.

---

From: Jonathan Rosenberg <[email-masked]>
Date: Tue, 08 Aug 2006 13:39:58 -0400

I just read this whole thread, and I think there are multiple problems 
being discussed here.

1. A proxy is misconfigured to use the wrong ciphersuite. How do we 
detect and fix this?

2. A malicious proxy has used an inadequate ciphersuite. How do we 
detect this?

3. How does a caller ensure that a call does not go through unless all 
proxies along the chain are using suffiently strong ciphersuites? You 
can break this into two subcases:

    a. misconfigured proxies
    b. malicious proxies

Firstly, I believe it is not useful to try and solve any problem related 
to malicious proxies. It is probably far easier for the proxy to just 
send a cleartext copy of a message somewhere, including spammers and 
other nefarious bad guys, than it is to just use a lower grade cipher. 
Consequently, I believe we should discard any use cases related to 
malicious proxies.

So, considering further misconfigured proxies. I personally remain 
unconvinced that this form of misconfiguration is common at all. 
Furthermore, of all of the misconfigurations that can happen, this 
hardly seems like the worst that can happen. Misrouting is far more 
disruptive to user experience, for example, and a very common 
configuration error.

I also think its important to separate out detction of this 
misconfiguration, from preventing of a call going forward if this 
misconfiguration exists. I think the latter is not so important. If you 
have a mecahnism to help diagnose this kind of misconfiguration, then as 
long as its eventually fixed, I do not see a strong need to prevent 
calls from happening if the network is misconfigured in this way. 
Indeed, there are lots of ways misconfiguration can cause a message to 
be visible to attackers. For example a far better one is when logging is 
enabled on a proxy, and there is no encryption of the logging messages 
to the logging server. Ditto for accounting or QoS authorization. 
Misconfiguration of the address of an accounting server could cause such 
accounting messages to even leave the network entirely.

For detection of the misconfiguration, I would much rather see us revive 
Jiri's old diagnostic message, which would allow a test call to be sent 
which reports what happened at each proxy. This includes the 
much-more-important routing behavior, but could also report the selected 
ciphersuites, accounting interfaces used and their security, and so on. 
This would be a reasonable feature of a diagnostic tool, IMHO.

-Jonathan R.

-- 
Jonathan D. Rosenberg, Ph.D.                   600 Lanidex Plaza
Cisco Fellow                                   Parsippany, NJ 07054-2711
Cisco Systems
[email-masked]                              FAX:   (973) 952-5050
http://www.jdrosen.net                         PHONE: (973) 952-5000
http://www.cisco.com

---

From: "Samir Srivastava" <[email-masked]>
Date: Tue, 8 Aug 2006 12:53:15 -0500

Hi Jonathan,

   I will digest other comments and reply later. But for the below one,
please find the response below in-line.

Thx
Samir
 
> This would be a reasonable feature of a diagnostic tool, IMHO.

How can you make sure that your test call traverses the same set of
proxies as that of the actual call due to alternate routes, booting
proxies etc. It is just the game of chances.

If cipher-suites etc are not exposed in via and UAC wished cipher-suites
in a separate header, your diagnostic tool is not going to work.

---

From: Jonathan Rosenberg <[email-masked]>
Date: Tue, 08 Aug 2006 14:46:42 -0400

Sure - call trace tools don't catch all problems. There are many 
techniques that are used to handle configuration problems. For example, 
audits and analyses on logs, tools that read and validate configurations 
across components based on criteria, and so on. Several of these would 
almost always catch this kind of problem.

My point is that I don't see the need to develop a new protocol 
mechanism to fix one very specific, not very common, not very-bad proxy 
misconfiguration. I'd rather develop tools that try and help 
troubleshoot SIP networks across a broader set of problems.

Thanks,
Jonathan R.

Samir Srivastava wrote:

>>For detection of the misconfiguration, I would much rather see us
> 
> revive
> 
>>Jiri's old diagnostic message, which would allow a test call to be
> 
> sent
> 
>>much-more-important routing behavior, but could also report the
> 
> selected
> 
>>ciphersuites, accounting interfaces used and their security, and so
> 
> on.
>

---

From: "Samir Srivastava" <[email-masked]>
Date: Tue, 8 Aug 2006 14:14:16 -0500

Hi Jonathan,

   Well, for the tool itself to work, we need to have the proposed
extensions.  Only looking into the log info is not sufficient? When one
should look and from which proxies etc in the real life deployment
scenarios is difficult. 

How can we differentiate 3DES (from the old ones), AES128 (3261), and
AES256 another new cipher-suite? They have different levels. They need
to be exposed irrespective of configuration errors etc. 

It should be noted that MTA add cipher-suite info too. 

Thx
Samir

> From: Jonathan Rosenberg [mailto:[email-masked]]
> Sent: Tuesday, August 08, 2006 11:47 AM
> Cc: Cullen Jennings; SIP

---

From: Jonathan Rosenberg <[email-masked]>
Date: Tue, 08 Aug 2006 15:24:23 -0400

Samir Srivastava wrote:

> extensions.

Not true. See below.

> Only looking into the log info is not sufficient? When one

I don't think so. One solution is to do a daily log analysis across all 
of the proxies in a domain, and see if any of them said they used a 
ciphersuite that the domain declares unacceptable. Similarly, every day 
or so you could read the configs across all proxies in the domain and 
check the configured ciphersuites. These kinds of config audit tools are 
commonplace.

> to be exposed irrespective of configuration errors etc. 

I don't understand what you are saying. The proxy would log and/or be 
configured with a specific ciphersuite.

-Jonathan R.

---

From: "Samir Srivastava" <[email-masked]>
Date: Tue, 8 Aug 2006 19:29:55 -0500

Hi Jonathan,
   Thx for your comments. Responses in-line below.
Thx
Samir

> 
> I don't think so. One solution is to do a daily log analysis across 
> all of the proxies in a domain, and see if any of them said they used 
> a ciphersuite that the domain declares unacceptable. Similarly, every 
> day or so you could read the configs across all proxies in the domain 
> and check the configured ciphersuites. These kinds of config audit 
> tools are commonplace.
> 
   Now your tool has changed from the call trace to log file analysis.
Here periodicity of checks will decide the time window where channel is
left less secure. This insecurity is related on the wire (Not like
misrouting etc),so we need to be very much careful.

> > AES256 another new cipher-suite? They have different levels. They 
> > need to be exposed irrespective of configuration errors etc.
> 
I intend to state that secure protocol versions, cipher-suites will be
varying in time. Now If I want to complete a request with AES256
cipher-suite (Bank a/c etc use case) only, I cannot do it without
specifying it explicitly. My home proxy provider being a best, is
up-to-date with AES256 but where the call needs to be terminated, that
path goes through other proxies which don't support AES256 but support
older/current mandatory cipher-suite AES128 and 3DES. My home proxy or
other proxies in between will downgrade it to AES128 or 3DES on the next
hop, if AES256 is not stated explicitly.

When I started looking into the cipher-suites, I was looking from the
future proof point. I think, following will be good data points 

1) How long it took to develop a cipher-suite, secure protocol etc
2) What was the computing power / technology /networking /parallelism
etc available at that time
3) As the time passed, Resources in 2 become cheap, and attackers have
more motivation to break the cipher-suites etc.
4) How long does it took to break the cipher-suites / secure protocols?
   
  We can very easily see this being a variable in future too. TLS itself
has two versions and another bis in progress. Security will be always
N+1 stuff.

  Now think out-side of the current limited /islands of the deployment
of SIP with the global equivalence of PSTN, It will be real difficult to
find all SIP entities up-to-date on the fly. People who care about
security, they will require it. 

Thx
Samir

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 08 Aug 2006 17:40:06 -0700

To: "Samir Srivastava" <[email-masked]>
Subject: Re: [Sip] Ciphersuites in SIP
Reply-to: EKR <[email-masked]>
X-Draft-From: ("nnmh:sip" 1334)
References: <[email-masked]>
From: Eric Rescorla <[email-masked]>
Gcc: nnmh+archive:sent
--text follows this line--
> hop, if AES256 is not stated explicitly.

So? 

You seem to be operating under the assumption that there's going to be
some situation where some cipher suite is really broken and yet the
proxies in the middle are still configured to only support it. I don't
believe that to be the case. With regard to the particular examples
you cite: AES-128 and 3DES are perfectly fine algorithms, well beyond
the range of any conceivable brute force attack. So, you have
to be imagining that some good analytic attack will be mounted in
which case people will TURN OFF THAT ALGORITHM. And if you don't
trust them to do so, then you shouldn't be trusting them to
route your traffic, since you can't trust them to keep their software
up to date and the vulnerability cycle for software is much shorter
than the vulnerability cycle for cryptographic algorithms.

-Ekr

---

From: "Joel M. Halpern" <[email-masked]>
Date: Tue, 08 Aug 2006 21:48:00 -0400

I think my basic problem with this is that it still confuses the 
users concerns with the operators concerns.
The user wants good security.  He ought not want specific security 
mechanisms between proxies, but rather, he wants the proxies to do a good job.
It is the operator's task to determine what the right mechanism 
(including crypto mechanism and crypto suite) to use at a given hop.

To be really clear, I do not think the user has the right to say 
"proxies along the chain must not use IPSec, and must use TLS, and 
must use a specific cipher suite."  The proxies don't belong to the 
end user.  Heck, with the way things work in practice, the end user 
may not even know about the proxies.  And very often neither end user 
has a contractual relationship with the intermediate proxies.

Yours,
Joel M. Halpern

---

From: Dean Willis <[email-masked]>
Date: Wed, 9 Aug 2006 00:27:47 -0500

On Aug 8, 2006, at 8:48 PM, Joel M. Halpern wrote:

> may not even know about the proxies.  And very often neither end  
> user has a contractual relationship with the intermediate proxies.

Worthy discussion points.

<playing "devil's advocate">

Now, let's say the "user" here is a large enterprise who writes into  
a contract with their ITSP that they expect such-and-such a cipher to  
be used on their links. And we know that enterprise IT organizations  
have to meet specific standards (in the US, under Sarbanes-Oxley) for  
protection of financial data or customer-privacy data (big in Europe).

Do they have the right to check up on whether their contract terms  
are being met??

What if the user is a government agency, who might be operating under  
a regulatory requirement? Have we seen regulatory requirements that  
make no sense before?

Don't misunderstand -- I'm not saying that this is a high-priority  
issue, and we're probably spending more time dismissing it than it  
deserves. But somewhere in there I believe there are legitimate use- 
cases that are probably important to somebody. We just haven't  
described them adequately.

<putting on chair hat. It's a big, Texas-style hat.>

Now, if somebody with either enough money to spend or an obvious use  
case wanted to step forward and claim the problem, perhaps our tune  
would change.

For now, however, I think we have ample evidence that we do not have  
a consensus on the presentation of the problem or on the proposed  
solution, so I'd like to ask the participants to step back and take a  
breather. If further reflection brings a real substantive change in  
the problem statement (and I suspect that the "diagnostic" approach  
may bear fruit) I'd welcome a new draft discussing it. But the  
current discussion is not getting us anywhere that we need to be  
going right now. So please, step back and give it some thought before  
continuing.

Thanks!

--
Dean

---

From: Cullen Jennings <[email-masked]>
Date: Fri, 18 Aug 2006 17:05:37 -0700

On Aug 8, 2006, at 6:48 PM, Joel M. Halpern wrote:

>   The proxies don't belong to the end user.  Heck, with the way  
> things work in practice, the end user may not even know about the  
> proxies.  And very often neither end user has a contractual  
> relationship with the intermediate proxies.

100% agree. That is why I don't see how you can't provide user  
security using a k,,hop by hop mechanism. If you want user integrity,  
you can get that to some degree with Identity. If you want  
confidentially as well, pretty much S/MIME is the only thing that  
might provide this today.

(And I agree with Dean's chair comment that we need a use case for  
the problem to solve before we get too excited about the solution :-)

---

From: Cullen Jennings <[email-masked]>
Date: Fri, 18 Aug 2006 17:05:37 -0700

---

From: "Samir Srivastava" <[email-masked]>
Date: Mon, 21 Aug 2006 13:02:22 -0500

Hi,

  As AD jumped into, my replies on the comments received so far.

1) I am looking into the Dean's comment from the regulatory perspective.
If Regulator's doesn't allow to view the cipher-suite of the earlier hop
to be viewed by the other proxies, then how MTA's are putting that ?  Or
they are not complying with this. As the complete message contents are
visible to the next hop proxy, viewing the cipher-suite used at the
earlier hop should not be an issue. It's my hunch only, I have to still
verify it.

2) There is cheater proxy case apart from the misconfiguration etc,
which I mentioned in the earlier arguments. It will be useful there.

3) I agree that end user doesn't have the contractual agreement with the
providers/proxies in the hops further down. But the security-level
agreement with the end user and his home proxy should be honored by the
middle hops if end-user is particular about the AES256 as of now. 

4) Jonathan suggested the usage of tool where Periodicity of check is
the bottleneck. Vendors have different way of logging. In the
multi-vendor deployment scenarios with upgrades etc, it will be real
hard to keep this information in sync without leaving a time window of
less secure hops. The other ways of sending the clear text messages by
the proxies can be fixed by configuration etc. But this needs a
mechanism in the protocol, if we agree on the problem definition.

5) The proposed solution is extensible to DTLS or any other future
extensions for security protocol, where SIPS in its current definition
of transport parameter is broken.  We can add a new parameter
secure-protocol in the URI definition or extend the transport parameter
to TLS+TCP, DTLS+DCCP, DTLS+UDP etc as suggested earlier in the wacky
thread.

6) How many S/MIME deployments are there ?

   I will modify the draft with the stress on the problem after having
definitive answer to 1), and see if group has further interest.

Thx
Samir

> From: Cullen Jennings [mailto:[email-masked]]
> Sent: Friday, August 18, 2006 5:06 PM
> To: Joel M. Halpern
> Cc: Srivastava, Samir (SC100:8826); Jonathan Rosenberg; SIP

---

From: "Samir Srivastava" <[email-masked]>
Date: Tue, 22 Aug 2006 13:45:38 -0500

Hi,

Regarding 3) Henry made a nice comment on the sipping list in the
different context today

"("the Internet is THE service") and the user must have choices and
control to exercise them. "

So from purists' point of view, proxies in middle need to honor the end
user wish. Or Am I missing something?

Thx
Samir

> From: Srivastava, Samir (SC100:8826)
> Sent: Monday, August 21, 2006 11:02 AM
> To: Cullen Jennings; Joel M. Halpern
> Cc: SIP

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 22 Aug 2006 12:13:52 -0700

> user wish. Or Am I missing something?

I think you're missing something. The Internet is a hop-by-hop
data switching service. In general, you get a fairly limited 
amount of control over the treatment that the intermediate
switches/routes give your packets provided that they're
routing them towards the destination. For instance, there's
no way in IP to ask routers not to send your packets over
a wireless link.

-Ekr

---

From: "Samir Srivastava" <[email-masked]>
Date: Tue, 22 Aug 2006 14:31:33 -0500

Hi Eric,

   IMHO, Level of Security is a choice available to user, so users
should have a control. 

User doesn't want to control the routing of packets. He cares about it
reaching to a particular destination. And here he cares about it
reaching with the desired level of security. 

Users have similar control on the HTTP with HTTPS or by sending a signed
documents etc on the email.

 I see security-level as a variable from the parallel of the anti-virus
products also. I care about the anti-virus product to be up-to-date.
IMHO, it goes similarly here for cipher-suites/secure protocol etc.

Thx
Samir

PS: I am not from a purist camp.

> From: Eric Rescorla [mailto:[email-masked]]
> Sent: Tuesday, August 22, 2006 12:14 PM
> Cc: Cullen Jennings; Joel M. Halpern; SIP

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 22 Aug 2006 12:40:27 -0700

"Henry Sinnreich" <[email-masked]> writes:

> Eric Rescorla writes:
>
>> For instance, there's no way in IP to ask routers not to send your 
>> packets over a wireless link.
>
> This is true but was not the point discussed here (the first Internet
> hop):
>
> The owner and user of a multimodal wireless device should have the
> control to select an access network of his/her choice and the handover
> should be controlled from the device, not from the "network".

Sure, but this isn't what Samir is arguing for in thuis case.

-Ekr

---

From: "Samir Srivastava" <[email-masked]>
Date: Tue, 22 Aug 2006 15:05:31 -0500

Hi Eric,

In line

Thx
Samir
 
> > He cares about it
> That's a perfectly fine argument, but it doesn't follow from
> the analogy you're making.

Thx you agreed. IMHO, HTTPS makes a closer analogy. On the anti-virus, I
was thinking of the secure managed service provided by the providers.

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 22 Aug 2006 13:09:11 -0700

"Samir Srivastava" <[email-masked]> writes:

> Thx you agreed.

Who said I agree? I'm just saying that it's a valid argument.

> IMHO, HTTPS makes a closer analogy.

But HTTPS operates exactly the opposite of the way you're
suggesting: the client ensures that he has an end-to-end
secure connection to the server with the claimed certificate.
What happens from there on isn't something it concerns
itself with.

-Ekr

---

From: "Samir Srivastava" <[email-masked]>
Date: Tue, 22 Aug 2006 15:14:45 -0500

Hi,

Inline

Thx
Samir

> Who said I agree? I'm just saying that it's a valid argument.
  
   Okay, I didn't read between the lines.

> What happens from there on isn't something it concerns
  
  Here client has control over the connection till the server. After
that Server is trusted.

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 22 Aug 2006 13:21:58 -0700

>   Here client has control over the connection till the server. After

Yes, and in SIP the proxy is trusted.

-Ekr

---

From: "Hadriel Kaplan" <[email-masked]>
Date: Tue, 22 Aug 2006 16:25:06 -0400

Riiiight.
And no email server should be allowed to detect email I send as spam or
filter virus attachments I add; if it's not my wish.  

And as for HTTP vs. HTTPS - users don't have control.  The admin of the web
server they want to access may give them control, by offering both, or not.
And when it comes to the SSL version or key length, I've been told users
(browsers) usually accept any/all blindly to a degree.  But they don't know
if there's really an SSL-offloader or not, whether the database backend is
secured or not, or much of anything past the other "end" of the TCP/SSL
connection.  The point is the user has some limited control over the "first
hop", and that's it.  It's true in SMTP, HTTP, FTP, SSH, BGP, etc.  All of
them are IETF defined protocols, and part of the "Internet".

And this is almost a silly discussion at some point - users don't know about
128 vs. 256 bit keys.  Trust me a vast majority of the users on the planet
Earth have no idea of what we speak.  They only "know" little icons of
locks, if that.  This is really an argument about UAs trusting proxies, and
neither are users.  Unless you're telling me UA's shouldn't/won't show a
lock icon because it's 128 vs. 256 bit keys, or because we don't have this
sip-security header, there's nothing much to argue over IMHO.

-hadriel

> Sent: Tuesday, August 22, 2006 3:32 PM
> To: EKR

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 22 Aug 2006 13:30:55 -0700

"Samir Srivastava" <[email-masked]> writes:

> Hi,
>
> I may go in the circle of arguments which I presented earlier.

You're already doing it, which is why I'm repeating my counterarguments.

> In short
> "Trust and Verify" idiom of Dean captures it clearly with respect to
> hop-by-hop nature of SIP.

And as I've observed repeatedly, there are a large number of ways
for the proxy to screw you so trying to verify this particular
one is of extremely limited value.

-Ekr

---

From: "Samir Srivastava" <[email-masked]>
Date: Tue, 22 Aug 2006 15:28:34 -0500

Hi,

I may go in the circle of arguments which I presented earlier. In short
"Trust and Verify" idiom of Dean captures it clearly with respect to
hop-by-hop nature of SIP.

Thx
Samir

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 22 Aug 2006 12:36:43 -0700

>    IMHO, Level of Security is a choice available to user, so users

It's available to the user in some settings, but not others.

For instance, you can choose to use WEP or WPA, but there's
no guarantee that your packets aren't being bridged over
some unencrypted wireless network somewhere in the middle
of the path.

> User doesn't want to control the routing of packets.

And yet both IP and SIP provide source routing.

-Ekr

---

From: "Henry Sinnreich" <[email-masked]>
Date: Tue, 22 Aug 2006 12:37:02 -0700

The Media Independent Handover work IEEE 802.21 can be found for example
at http://www.cs.tut.fi/kurssit/83180/83180_05_S9d.ppt  and explicitly
provides the option selection and handover control from the mobile
device.

Thanks, Henry

-----Original Message-----
From: Eric Rescorla [mailto:[email-masked]] 
Sent: Tuesday, August 22, 2006 2:14 PM
To: Samir Srivastava
Cc: Cullen Jennings; Joel M. Halpern; SIP
Subject: Re: [Sip] Ciphersuites in SIP

-Ekr