Subject: [Sip] New I-D on RFC4474 and phone numbers

From: Jonathan Rosenberg <[email-masked]>
Date: Mon, 18 Feb 2008 00:06:35 -0500

I just submitted:
http://www.ietf.org/internet-drafts/draft-rosenberg-sip-rfc4474-concerns-00.txt

This is basically a discussion on the security properties of rfc4474 
with phone numbers, and a comparison to rfc3325 in this case. Also a 
discussion on what happens to dtls-srtp.

Comments welcome.

-Jonathan R.
-- 
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  http://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: Paul Kyzivat <[email-masked]>
Date: Mon, 18 Feb 2008 09:50:33 -0500

Jonathan,

I guess the time has come for this discussion, since John Ewell has also 
submitted a draft on this subject.

I thought the problem was already well known, but perhaps not. IMO the 
main thing now is to figure out the *solution* to the problem!
IMO a solution is to use a 4474-style approach, but where the 
certificate is tied to just the phone number, not to some arbitrary 
domain name. That of course would depend on a model where the "owner" of 
the phone number is the one who may obtain the certificate for that number.

My thought is that we already have an algorithmic mapping from an E.164 
phone number to a domain name, defined by enum. If the sender puts an 
E.164 number in From, and can sign it with a cert for the enum mapped 
domain name corresponding to that number, then that ought to be valid 
proof of the validity of the sender.

In those places where public enum is in operation, I think there is 
already a legal mechanism in place to give the owner of record of a 
particular phone number control over the contents of the corresponding 
DNS entry. That should also be sufficient to allow a certificate 
authority to assign a cert to that same owner.

Combine all that and you have a complete e2e identity model for phone 
numbers, based on public enum. And that can be true even if public enum 
isn't used to *route* the calls to that number. So it could be used for 
"unlisted" numbers.

To use this approach the From header should contain either a TEL URI, or 
a sip/sips URI containing the enum-mapped domain name corresponding to 
the phone number. (I would rather see the TEL used for this - it is more 
user friendly.)

	Thanks,
	Paul

---

From: "Henry Sinnreich" <[email-masked]>
Date: Mon, 18 Feb 2008 08:25:45 -0800

Paul,

>proof of the validity of the sender.

This seems indeed to be cutting the Gordian Knot!
(http://en.wikipedia.org/wiki/Gordian_Knot)

Should this not be a joint I-D with the ENUM WG, or have at least have
some coordination?
The exact mechanism to do this is certainly of interest to the ENUM
folks.

Henry

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Paul Kyzivat
Sent: Monday, February 18, 2008 8:51 AM
To: Jonathan Rosenberg
Cc: IETF SIP List
Subject: Re: [Sip] New I-D on RFC4474 and phone numbers

Jonathan,

the phone number is the one who may obtain the certificate for that
number.

user friendly.)

	Thanks,
	Paul

> I just submitted:
http://www.ietf.org/internet-drafts/draft-rosenberg-sip-rfc4474-concerns
-00.txt

---

From: "Joel M. Halpern" <[email-masked]>
Date: Mon, 18 Feb 2008 11:30:12 -0500

I have been pestering various people off list, and have decided to see 
whether someone else understands and can explain this in a way I can 
follow.  The following is somewhat longer than I like.  Sorry.

The pair of questions is:
When should the user part of a SIP URI be considered an E.164 number?
And what assertion is being made by such consideration?

Taking them backwards, as far as I can tell from reading the RFCs and 
the I-Ds, the assertion that is supposed to hold is that if a SIP URI 
can be properly understood to have an E.164 number in it's user part, 
and if it legitimately has that number, then the party the SIP URI 
represents can also be reached by calling the E.164 number on the PSTN.

There are some interesting ambiguities left even with that definition, 
but we can live with it.

So, when does the user part have an E.164 number, so that it is 
reasonable to ask if the assertion holds?
As far as I can tell, there are three cases:

Case 1 - No ;user=phone option
In the absence of a ;user=phone option, the user part of the SIP URI 
should be considered an opaque string.  It should not be considered an 
E.164 number, even if it is formatted as a telephone subscriber number. 
  I can legitimately use [email-masked] as a SIP URI.  And 
if the whitehouse.com deliberate confusion is still active, they could 
use [email-masked] as a SIP URI.
It is reported that some SIP devices will display the phone number 
without the domain for such URIs.  That is a UI error, not a protocol 
error.  The protocol can not make the UI do the right thing.

Case 2 - ;user=phone option present, no ;phone-context= option
I believe this is an assertion that the user part of the SIP URI is an 
E.164 number, and that if one is doing validation E.164 validation is 
appropriate.  The whole question of the meaning of the domain, and 
whether we are better off with tel: URIs applies to this form of SIP URI.
While it is possible (any character string is possible) to have a SIP 
URI with ;user=phone and no ;phone-context and not have the user part 
formatted as a telephone-subscriber number, such a mismatch looks to me 
to be a violation of RFC 3261.  The only reasonable handling is that if 
one is trying to perform E.164 validation, such validation will fail on 
such a SIP URI.

Case 3 - ;user=phone and ;phone-context= options present
The RFCs seem to say explicitly that the user part of the SIP URI can 
not be considered an E.164 number, and that one can not even expect to 
concatenate the phone context and the user part to get an E.164 number. 
  So there can be no E.164 validation because there is no E.164 number.

Some folks seem to have suggested that one should observe the format of 
the user part of the SIP URI in order to decide if an E.164 number is 
intended.  I sincerely hope that is note the case.

Yours,
Joel M. Halpern

---

From: "Frank W. Miller" <[email-masked]>
Date: Mon, 18 Feb 2008 10:07:47 -0700

I'm a little confused by the need to "sign" phone numbers.  I mean, whomever
uses the number makes a call to or from it right?  If the receiver of the
call doesn't want to talk to whomever calls, don't they just hang up?  This
seems like a lot of extra work for little gain.

Thanks,
FM

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Henry
Sinnreich
Sent: Monday, February 18, 2008 9:26 AM
To: Paul Kyzivat; Shockey, Richard
Cc: IETF SIP List
Subject: Re: [Sip] New I-D on RFC4474 and phone numbers

Paul,

Henry

-----Original Message-----

Jonathan,

user friendly.)

	Thanks,
	Paul

---

From: Dean Willis <[email-masked]>
Date: Mon, 18 Feb 2008 11:40:40 -0600

> the phone number is the one who may obtain the certificate for that  

You might take a look at "Identity Based Authentication in the Session  
Initiation Protocol",  draft-kupwade-sip-iba-00.

This draft is a bit incomplete, but it's the reduction of a far longer  
master's thesis that I'm familiar with.

It seems reasonably feasible to consider the phone number an  
"identity" within the domain of an identity-based private key  
generator.  The math is now available to handle multiple levels of PKG  
hierarchy, which allows key-generation delegation along the ENUM tree  
lines. On an operational basis, it seems a lot easier to work with  
than a CA model.

--
Dean

---

From: Hadriel Kaplan <[email-masked]>
Date: Mon, 18 Feb 2008 12:44:47 -0500

I think we're trying to get something out of the signature that currently isn't fully there: caller-id.  Currently rfc4474 just tells you that the signer sent the request to someone (not necessarily you), within the past hour, with the attached body unchanged between it and you.  Per rfc4474 that signer should have verified the authenticity of the AoR in the From before sending it.

If the signing domain didn't do strong verification of the From before signing an email-style URI, the impact of such is really against the signing domain.  In other words its in the signing domain's best interest to get it right, because it's affecting their own customers' identity legitimacy.  But when a signing domain signs an e164 that is not its own, it's affecting a global number's legitimacy - its spoofing the identity of someone outside of the signing domain.  Without some way to verify the signing domain *owns* that e164, you have no way to know if it's good or not.

For example, if a provider gets a call from a PSTN tandem trunk, and passes it on in SIP, they really shouldn't sign its From, because they have no way to verify the authenticity of its user part. (CLID spoofing is not a new phenomenon)  And likewise if an enterprise signs an e164 other than their own, it would be an error.  But there is currently no way to detect such errors or intentional mischief.

-hadriel

> Frank W. Miller
> Sent: Monday, February 18, 2008 12:08 PM
> To: 'Henry Sinnreich'; 'Paul Kyzivat'; 'Shockey, Richard'
> Cc: 'IETF SIP List'

---

From: "Frank W. Miller" <[email-masked]>
Date: Mon, 18 Feb 2008 10:49:05 -0700

Intesting point.  But again, I'll ask the question.  So what?  If the call
goes to or come from somewhere that's unintended, one or the other party
just hangs up (I do it all the time when the telemarketers call  ;)  ).  Why
do we need all this infrastructure if a simple operational usage solves this
problem well enough?

Thanks,
FM

-----Original Message-----
From: Hadriel Kaplan [mailto:[email-masked]] 
Sent: Monday, February 18, 2008 10:45 AM
To: Frank W. Miller; 'Henry Sinnreich'; 'Paul Kyzivat'; 'Shockey, Richard'
Cc: 'IETF SIP List'
Subject: RE: [Sip] New I-D on RFC4474 and phone numbers

I think we're trying to get something out of the signature that currently
isn't fully there: caller-id.  Currently rfc4474 just tells you that the
signer sent the request to someone (not necessarily you), within the past
hour, with the attached body unchanged between it and you.  Per rfc4474 that
signer should have verified the authenticity of the AoR in the From before
sending it.

If the signing domain didn't do strong verification of the From before
signing an email-style URI, the impact of such is really against the signing
domain.  In other words its in the signing domain's best interest to get it
right, because it's affecting their own customers' identity legitimacy.  But
when a signing domain signs an e164 that is not its own, it's affecting a
global number's legitimacy - its spoofing the identity of someone outside of
the signing domain.  Without some way to verify the signing domain *owns*
that e164, you have no way to know if it's good or not.

For example, if a provider gets a call from a PSTN tandem trunk, and passes
it on in SIP, they really shouldn't sign its From, because they have no way
to verify the authenticity of its user part. (CLID spoofing is not a new
phenomenon)  And likewise if an enterprise signs an e164 other than their
own, it would be an error.  But there is currently no way to detect such
errors or intentional mischief.

-hadriel

---

From: Dean Willis <[email-masked]>
Date: Mon, 18 Feb 2008 11:49:14 -0600

> seems like a lot of extra work for little gain.

How do they know who called? Can the thing being presented as caller- 
ID be trusted?

Example use case:

You get a call from "Memorial Hospital" at 999-454-5678. Your child  
was apparently injured at school and is claimed to be in ICU, but your  
signature is urgently needed before a life-saving procedure can be  
administered. You double-check by calling back 999-454-5678 and get  
the front desk at Memorial Hospital. Just to be sure, you look in the  
phone book, and yep, that's their number. Of course, you rush to the  
hospital.

While you're out, the burglar who faked the call cleans out your house.

Or even more fun: Your neighbors are having a really noisy party. Call  
911, faking their phone number as the source, and report a murder-in- 
progress. Stand by and wait for the SWAT team to show up.

--
Dean

---

From: "Frank W. Miller" <[email-masked]>
Date: Mon, 18 Feb 2008 10:52:38 -0700

K, got this just after my response.  Inline...

-----Original Message-----
From: Dean Willis [mailto:[email-masked]] 
Sent: Monday, February 18, 2008 10:49 AM
To: Frank W. Miller
Cc: IETF SIP List
Subject: Re: [Sip] New I-D on RFC4474 and phone numbers

Example use case:

FM: Call me crazy but I get weird caller-ids on my phones all the time now,
with the trusted PSTN.  You don't think that people won't figure out how to
circumvent what we do if they really want to?

FM: Any reasonable person would call the hospital back first before rushing
out.  Besides, this same trick can be done now with Private or Blocked in
the PSTN.

FM

---

From: Hadriel Kaplan <[email-masked]>
Date: Mon, 18 Feb 2008 13:14:56 -0500

Two reasons off the top of my head: SPIT and Phishing.

Phishing: how do you know who the caller is?  If a call comes in claiming your Bank's phone number, or the local Police, or whatever, would you hang up?  How would you know to?  You probably would be suspicious, being a technically savvy individual, but plenty of people click on the false PayPal links in email.  My wife did, for example, and needless to say two hours later the credit card company called saying there had been suspicious charges. (at which point I asked her how did she know it was the credit card company!)  If the Caller-id was at least verifiable, there'd be recourse for law enforcement to find the caller.

SPIT: Your phone rang, you answered, and then learned it was a telemarketer.  They succeeded.  You hung up, but many don't.  A "telemarketer" call actually isn't SPIT in my book, if they use a legitimate CLID. (for some people it still is though)  But if they can just pick random E.164's as CLIDs, SIP will turn into email, and that ain't good.  I don't want my phone to ring constantly.  Current email form of spam detection doesn't make sense for VoIP.  IF we can get a verifiable caller-id, then there's a chance of stopping it with blacklists/whitelists or reputation systems or whatever. (I think that task is rather daunting in itself, but that's the premise anyway)

-hadriel

> From: Frank W. Miller [mailto:[email-masked]]
> Sent: Monday, February 18, 2008 12:49 PM
> To: Hadriel Kaplan; 'Henry Sinnreich'; 'Paul Kyzivat'; 'Shockey, Richard'
> Cc: 'IETF SIP List'

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 18 Feb 2008 13:28:25 -0500

Frank,

So are you asserting that reliable callerid is not needed, or that it is 
not possible?

If its not needed, then I guess sip identity was a waste of time, as is 
P-Asserted-ID. From should be good enough.

The PSTN callerid is to a large extend based on transitive trust, and is 
reliable if the providers are careful. It breaks when providers trust 
sources that they shouldn't. Apparently that is becoming an increasingly 
common case.

If we create a cert-based mechanism similar to 4474 that works for phone 
numbers then there should be no way around it other than stealing the 
certs. So it should be better than the PSTN.

	Paul

---

From: "Frank W. Miller" <[email-masked]>
Date: Mon, 18 Feb 2008 11:33:37 -0700

Again, interesting.  Inline...

FM

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Hadriel Kaplan
Sent: Monday, February 18, 2008 11:15 AM
To: Frank W. Miller; 'Henry Sinnreich'; 'Paul Kyzivat'; 'Shockey, Richard'
Cc: 'IETF SIP List'
Subject: Re: [Sip] New I-D on RFC4474 and phone numbers

Phishing: how do you know who the caller is?  If a call comes in claiming
your Bank's phone number, or the local Police, or whatever, would you hang
up?  How would you know to?  You probably would be suspicious, being a
technically savvy individual, but plenty of people click on the false PayPal
links in email.  My wife did, for example, and needless to say two hours
later the credit card company called saying there had been suspicious
charges. (at which point I asked her how did she know it was the credit card
company!)  If the Caller-id was at least verifiable, there'd be recourse for
law enforcement to find the caller.

FM: I don't think we can equate email Phishing with Phishing in the phone
system.  There are two reasons.  First, email is just a lot easier to do
this with.  I don't mean its easier because its easier to disguise your
identity with email.  I mean its easier because it takes less effort
economically to actual fire off a million emails than it does to make a
million phone calls, even with automated systems.  Second, Phishing exists
in the PSTN now.  Yes it's a problem but, if we can't stop it there, what
makes you think we'll be able to stop it here.  While we can do lots of
fancy (and expensive) things to protect ourselves in the IP world, the
counterbalance is that hacking IP based systems is a lot easier than hacking
the PSTN.  The best thing to do is to tell your wife and kids what I've told
mine, never, ever, ever click on a link that you're not absolutely sure
where it came from or who it is.  Unsolicited emails don't fall into that
category.

SPIT: Your phone rang, you answered, and then learned it was a telemarketer.
They succeeded.  You hung up, but many don't.  A "telemarketer" call
actually isn't SPIT in my book, if they use a legitimate CLID. (for some
people it still is though)  But if they can just pick random E.164's as
CLIDs, SIP will turn into email, and that ain't good.  I don't want my phone
to ring constantly.  Current email form of spam detection doesn't make sense
for VoIP.  IF we can get a verifiable caller-id, then there's a chance of
stopping it with blacklists/whitelists or reputation systems or whatever. (I
think that task is rather daunting in itself, but that's the premise anyway)

FM: I'd luv to be able to do this but...   What do you do when a number
comes in that is just a number, i.e. it doesn't have a "caller id"
associated with it?  That happens all the time to me and would probably
happen all the time for IP systems as well.  It may be signed but so what?
You may not know where that number is, but what do you do?  Most people just
answer it.  If its SPIT, you hangup.  Why is that so hard?  If we're going
to stay with the anachronism of phone numbers, why can't we just stay with
the remedies that have been developed for it, Do-Not-Call lists and laws
governing telemarketers and legal action against them and such.  Those are
the things that modify the behavior of humans ultimately, not our
technology.

-hadriel

---

From: "Frank W. Miller" <[email-masked]>
Date: Mon, 18 Feb 2008 11:37:46 -0700

Inline...

-----Original Message-----
From: Paul Kyzivat [mailto:[email-masked]] 
Sent: Monday, February 18, 2008 11:28 AM
To: Frank W. Miller
Cc: 'Dean Willis'; 'IETF SIP List'
Subject: Re: [Sip] New I-D on RFC4474 and phone numbers

Frank,

FM: Not possible enough to justify the expense.

FM: Well, waste of time would not be the exact words I would use...  ;)

FM:  Yes and no.  Its definitely based on trust that we don't assume in IP
based systems.  And its still relatively easy to get around.

FM: Look, I'm sure this community is going to probably go off and spend a
lot of time doing this.  And there may ultimately be large, expensive
deployments of certs and signatures, etc. etc.  Just don't kid yourself that
its going to stop phishing or spit cuz it won't

---

From: Jonathan Rosenberg <[email-masked]>
Date: Mon, 18 Feb 2008 14:36:25 -0500

I agree that something along the lines of enum could solve this problem, 
and I believe there was a draft that proposed such a thing. This has 
been discussed since the start of rfc4474.

However, I fear that saying, 'use enum' is kind of like saying, we'll 
just use an All-Knowing Oracle, so lets figure out the interface 
protocol to the Oracle. The easy part is the interface (the enum 
mechanism). The actual hard problem is how to get those entries 
populated. The deployment of public enum has been - shall we say - less 
than spectacular. I'd hate for that to be our only solution. Not that 
its obvious what else to do; though I do suggest in my draft how domain 
based authentication, when combined with whitelists and blacklists, can 
help.

-Jonathan R.

---

From: Jonathan Rosenberg <[email-masked]>
Date: Mon, 18 Feb 2008 14:40:35 -0500

I don't think it is very clear anywhere in our current RFCs, that the 
presence of a +<number> in the user part, along with user=phone, 
actually implies that the user is reachable by that e164 directly. 
Overall this remains a messy area for us.

I took a stab at trying to sort some of it out in an I-D I published a 
while back:

http://www.watersprings.org/pub/id/draft-rosenberg-rai-phone-names-numbers-00.txt

and John's draft discusses similar issues.

-Jonathan R.

---

From: "Tschofenig, Hannes (NSN - FI/Espoo)" <[email-masked]>
Date: Mon, 18 Feb 2008 20:54:39 +0100

Hi Jonathan, 
Hi Paul,

thanks for raising the aspect of E.164 and ENUM usage. There was an offline discussion between Dan Wing, Klaus Darilion, Kai Fischer, David Schwartz, Hadriel Kaplan, John Elwell, and myself about E.164 and SIP Identity. As part of the discussion Klaus and I polished a former document of Alexander Mayrhofer on the usage of ENUM for E.164 numbers (see draft-mayrhofer-enum-domainkeys-00). As we moved along with the work we obviously came across a couple of problems (as one can easily imagine) and the document triggered a long discussion among us. Dispite a couple of challenges, we published the document today (see http://www.ietf.org/internet-drafts/draft-darilion-sip-e164-enum-00.txt). I learned a lot while working on that document. 

In addition to publishing the document a few of us have also worked on a document that captures some of our discussion on E.164 number ownership. I will publish it very soon -- just a bit more proof-reading. 

Ciao
Hannes 

> -----Ursprüngliche Nachricht-----
> Von: [email-masked] [mailto:[email-masked]] Im 
> Auftrag von ext Jonathan Rosenberg
> Gesendet: Montag, 18. Februar 2008 21:36
> An: Paul Kyzivat
> Cc: IETF SIP List
> Betreff: Re: [Sip] New I-D on RFC4474 and phone numbers
>

---

From: Hadriel Kaplan <[email-masked]>
Date: Mon, 18 Feb 2008 14:55:01 -0500

> Sent: Monday, February 18, 2008 1:34 PM
>
> million phone calls, even with automated systems.

Yes, there is no debate that cost/expense and closed networks have kept phone calls from being hammered like email.  Unfortunately/fortunately, that cost is dropping.  This topic isn't about today - it's about 5-20+ years from now.  If the call cost drops at the current rate, and if enough SIP providers peer with each other and/or it opens up more, then we'll have a problem.  For me, it's particularly the peering problem that concerns me. (for obvious reasons)

That's a lot of "ifs", but really the IETF's time has been spent on protocols and methods with far less chance of success or potential need.  ;)

With regard to performance, we already have a tool which can generate 1 Million call attempts, each to different targets, each with random From's, in approximately 5 seconds.  This tool is purely software running on MS Windows.  It can do it (and has) running on my laptop, which has a GigE interface.  The tool can send pre-recorded RTP media to as many destinations as 200K packets/sec can cover for the codec rate and ptime.  It's not able to complete dialogs, or make full calls, and trying to do so would reduce it immensely I'm sure.  But it would only have to do that for the calls that answer.

The only thing that stops such a thing from succeeding other than cost is that the SIP infrastructure can't deal with that kind of rate, so certain devices at provider borders are built to stop it.  But as the performance of the provider equipment increases, or more entry points are available, it's the per-call cost (or bulk cost) that will prevent it, and once that's down enough we could be in trouble without some form of strong identity.

> associated with it?

Then you know not to show a caller-id, and it is suspect.  In other words the signing de-values those that aren't signed.

> That happens all the time to me and would probably

Do-not-call-lists and legal action are only possible if the source is verifiable, no?  Calls originate and transit through providers outside of the local nationality, too.  The "if it's SPIT you hang up" model doesn't work if the rate of SPIT is even a fraction of email's spam.  You wouldn't put up with it, or at least most people wouldn't.

-hadriel

---

From: Hadriel Kaplan <[email-masked]>
Date: Mon, 18 Feb 2008 15:20:02 -0500

As part of an off-line discussion regarding Kai Fischer's draft on e2e-security-media and whether his From-URI copying tactic would succeed or not at a policy level, if rfc4474 fails to do so, I gave my 2 cents on what some providers had been telling me.  Dan asked me to write up a draft on it, in case people are interested.  This is the draft:
http://www.ietf.org/internet-drafts/draft-kaplan-sip-uris-change-00.txt

-hadriel

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 18 Feb 2008 15:49:59 -0500

Dean,

I took a look but didn't spend a lot of time. I can't understand it 
enough to figure out how it might apply.

To me the basic points are that enum provides the basis for a *legal* 
definition of ownership of numbers, which could be tied to a CA scheme. 
Enum also provides a mapping from numbers to domain names, which 
provides a direct way to map to DNS-based certs.

If this new scheme can be related to e.164 numbers then maybe it can 
apply as well. One thing I don't understand is how it would tie to a 
legal definition of ownership of the numbers.

	Paul

Dean Willis wrote:
> It seems reasonably feasible to consider the phone number an "identity" 
> within the domain of an identity-based private key generator.  The math 
> is now available to handle multiple levels of PKG hierarchy, which 
> allows key-generation delegation along the ENUM tree lines. On an 
> operational basis, it seems a lot easier to work with than a CA model.
> 
> -- 
> Dean
> 
>

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 18 Feb 2008 16:07:17 -0500

> represents can also be reached by calling the E.164 number on the PSTN.

The question about whether it "legitimately has that number" is troublesome.

And whether the person can be reached via the PSTN is also questionable. 
For instance, suppose you received a call with only MSRP as media from 
such an address, and tried to return the call. If you used MSRP they it 
would almost certainly fail. (Unless there was an MSRP - SMS GW.) If you 
used voice it might still fail if the owner has no voice terminal 
registered.

> error.  The protocol can not make the UI do the right thing.

I agree with you. But common practice is otherwise.

> appropriate. 

I always interpreted this as meaning that the *syntax* of the user part 
conformed to the TEL URI. IMO it is much less clear that you have any 
guarantee that this identifies the same place you would reach if you 
made a PSTN call.

> The whole question of the meaning of the domain, and 
> to be a violation of RFC 3261. 

Yes, syntax wise I agree.

> The only reasonable handling is that if 

Yes, I agree. This is more a question about TEL URIs in general than 
about sip URIs. IMO there is opportunity for further standardization of 
how to generate routing to TEL URIs with phone-context parameters. But 
that is for the future.

> intended.  I sincerely hope that is note the case.

Yes, I agree. IMO we have no business reserving that whole subset of the 
username space.

However there is a sticky point. Registration is done without regard for 
parameters in the user part of the AOR, and translations based on the 
location service also ignore the parameters. So its impossible for a 
domain to have both:

	sip:[email-masked];user=phone
	sip:[email-masked]

as distinct AORs. In practice that reserves the whole e.164 space in 
domains that want to honor e.164 numbers.

	Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 18 Feb 2008 16:39:31 -0500

I agree that the problem exists. But in the end for any signing based on 
number to work there must be a tie to the legal notion of ownership of 
e.164 numbers. There is no getting around that. Its just a matter of 
whether there is *one* system for tying to ownership, or two.

In this case it doesn't require that dns entries in the e164.ansi tree 
be populated. Rather it requires that some CAs support the legal 
framework for assigning certs, based on the same definitions of ownership.

It isn't essential that the certs be distributed to the end users owning 
the numbers. A SP could act as an agent for the user in managing the 
cert and doing the signing. (But an end user who wants to sign his own 
requests should be able to get the cert.)

	Paul

Jonathan Rosenberg wrote:
>> I guess the time has come for this discussion, since John Ewell has 
>> also submitted a draft on this subject.
>>
>> domain name. That of course would depend on a model where the "owner" 
>> of the phone number is the one who may obtain the certificate for that 
>> number.
>>
>> My thought is that we already have an algorithmic mapping from an 
>> E.164 phone number to a domain name, defined by enum. If the sender 
>> puts an E.164 number in From, and can sign it with a cert for the enum 
>> mapped domain name corresponding to that number, then that ought to be 
>> valid proof of the validity of the sender.
>>
>> numbers, based on public enum. And that can be true even if public 
>> enum isn't used to *route* the calls to that number. So it could be 
>> used for "unlisted" numbers.
>>
>> To use this approach the From header should contain either a TEL URI, 
>> or a sip/sips URI containing the enum-mapped domain name corresponding 
>> to the phone number. (I would rather see the TEL used for this - it is 
>> more user friendly.)
>>
>>     Thanks,
>>     Paul
>>

---

From: "Richard Shockey" <[email-masked]>
Date: Mon, 18 Feb 2008 17:17:27 -0500

So did you guys want a slot during the ENUM WG?

>  Tschofenig, Hannes (NSN - FI/Espoo)
>  Sent: Monday, February 18, 2008 2:55 PM
>  To: ext Jonathan Rosenberg; Paul Kyzivat
>  Cc: IETF SIP List
>  thanks for raising the aspect of E.164 and ENUM usage. There was an
>  offline discussion between Dan Wing, Klaus Darilion, Kai Fischer,
>  David Schwartz, Hadriel Kaplan, John Elwell, and myself about E.164
>  and SIP Identity. As part of the discussion Klaus and I polished a
>  former document of Alexander Mayrhofer on the usage of ENUM for E.164
>  numbers (see draft-mayrhofer-enum-domainkeys-00). As we moved along
>  with the work we obviously came across a couple of problems (as one
>  can easily imagine) and the document triggered a long discussion among
>  us. Dispite a couple of challenges, we published the document today
>  (see http://www.ietf.org/internet-drafts/draft-darilion-sip-e164-enum-
>  00.txt). I learned a lot while working on that document.
>  
>  In addition to publishing the document a few of us have also worked on
>  a document that captures some of our discussion on E.164 number
>  ownership. I will publish it very soon -- just a bit more proof-
>  reading.
>  
>  Ciao
>  Hannes
>

---

From: "Richard Shockey" <[email-masked]>
Date: Mon, 18 Feb 2008 17:22:05 -0500

In line 

>  protocol to the Oracle. 

Yea and lets end world hunger while we're at it ...

The easy part is the interface (the enum
>  populated. The deployment of public enum has been - shall we say -
>  less  than spectacular.

"less than spectacular .." now there is an understatement, if there ever was
one. Though private non DNS visible enum systems are going like gangbusters
as TCAP/SS7 replacements all over the place.

I find this entire discussion somewhat hilarious, almost side splitting,
considering what some us had to go through to get A. get public ENUM defined
B. then see what happened with delegations in the e164.arpa domain in the
intervening 6 years or so. 

The very idea that there is going to be some consensus on who "owns" a phone
number, much less a deployable system considering the various competing
interests here is a complete fantasy.  

I'd hate for that to be our only solution. Not that

---

From: Hadriel Kaplan <[email-masked]>
Date: Mon, 18 Feb 2008 17:23:15 -0500

Actually, I'm not even sure it really requires that.  It is debatable if you truly own your number, and certainly debatable if CA roots would be willing to sign off on certs that are given to direct end users if the SP acts as an agent middle-man. (that basically breaks their vetting process, no?)  On the other hand, if you'll allow solely for the UAC's and UAS's local providers/enterprise's to do the authentication *and* verification, and give up on the UAS being able to verify directly, then it may be more palatable and potentially succeed.

For example, if you are willing to ignore DNS' lack of security (assuming there is no dnssec), then all you really need is a DNS root to get ownership domain names from for the numbers, rather than certs per number or entry.  In other words let enum return the naptr identifying the owner's domain name, rather than a next-hop route resolution or certificate directly.  Then just check that the 4474-provided cert matches that name.  Obviously if DNS is subverted, or the DNS request intercepted or response spoofed, it breaks.  But it's a lot lighter weight and manageable than putting a cert per number into the DNS.  Heck, even using dnssec it would probably be lighter weight.

Whether providers would be willing to put that ownership info into a public dns tree I don't know.  But they might be willing to in a non-public tree only other providers could use. (since that info is essentially already available in SS7)  Or even exchange that info with each other.  I believe that is one possible logical outcome of Peppermint, for example.

-hadriel

> From: [email-masked] [mailto:[email-masked]] On Behalf Of Paul
> Kyzivat
> Sent: Monday, February 18, 2008 4:40 PM
> To: Jonathan Rosenberg
> Cc: IETF SIP List

---

From: Hadriel Kaplan <[email-masked]>
Date: Mon, 18 Feb 2008 17:29:30 -0500

> Sent: Monday, February 18, 2008 4:07 PM
>
> Joel M. Halpern wrote:

Definitely.  If the user part even smells like an e164, it's treated as one by a lot of folks. :(

-hadriel

---

From: "Richard Shockey" <[email-masked]>
Date: Mon, 18 Feb 2008 17:29:06 -0500

>  Frank,
>  
>  So are you asserting that reliable callerid is not needed, or that it
>  is not possible?
>  
>  If its not needed, then I guess sip identity was a waste of time, as
>  is  P-Asserted-ID. From should be good enough.
>  
>  The PSTN callerid is to a large extend based on transitive trust, and
>  is>  reliable if the providers are careful. It breaks when providers
trust
>  sources that they shouldn't. Apparently that is becoming an
>  increasingly common case.

Really ???  Transitive trust seems to have worked reasonable well for the
time being   .what examples have you found of sources that providers thought
they could trust but found they shouldn't have? 

>  If we create a cert-based mechanism similar to 4474 that works for
>  phone numbers then there should be no way around it other than stealing
the
>  certs. So it should be better than the PSTN.

<sigh>

---

From: "Richard Shockey" <[email-masked]>
Date: Mon, 18 Feb 2008 17:35:27 -0500

>  I agree that the problem exists. But in the end for any signing based
>  on number to work there must be a tie to the legal notion of ownership of

Well just as a small side bar here ... by International Treaty ...yes our
friends in Geneva, no one "owns" phone numbers. The governance of E.164
phone numbers are strictly nation state matters. So anything that touches
the namespace gets to be vetted by each and every country. See the IAB-ITU
agreements on e164.arpa for instance.

You are starting from a fallacy aka "ownership" already and fast going
downhill. "Right to usage" is even more a slippery slope...been there done
that.  :-) 
 
>  It isn't essential that the certs be distributed to the end users
>  owning  the numbers. A SP could act as an agent for the user in managing
the

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 18 Feb 2008 17:44:34 -0500

IMO its up to the owner of the UA and his SP whether the UA has the cert 
and does the signing, or the SP acts as an agent for the UA, holding the 
cert and doing the signing. While I would like it to be possible for a 
user to do this himself, most probably won't want to, and most providers 
won't want to let them. While sad, it would probably be good enough if I 
had to go looking for a provider that would let me manage my own cert.

Similarly, on the verification side I can see how many UASs would prefer 
to have a SP do the hard verification and just relay the results on via 
a P-A-ID header. It would however be good if a UAS *could* do the 
verification itself - which means that the public key must be accessible 
to it in some way.

IMO the part that gives me the most worry is if there is reluctance to 
*define* ownership. But I don't think I believe that is a real problem. 
I will bet that if somebody shows up with a warrant demanding the 
disclosure of the owner of some phone number, the SP will be willing and 
able to provide an answer, and defend it in court.

I presume the real reluctance is to *disclose* the ownership to anyone 
who asks, for both business and legal reasons. But if its not the 
identity, but simply the public key or cert that is disclosed, then I 
would hope it would be hard to justify keeping it private. But perhaps 
that is just wishful thinking on my part.

	Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 18 Feb 2008 17:46:38 -0500

> they could trust but found they shouldn't have? 

All the cases of callerid spoofing.

	Paul

---

From: Hadriel Kaplan <[email-masked]>
Date: Mon, 18 Feb 2008 17:47:08 -0500

In your experience would there be a quorum of incumbent providers who would be willing to publish their numbers in an infrastructure enum, available only to other "club members"?  Such a thing is essentially the logical conclusion of Peppermint, isn't it?  Just in a distributed form.

-hadriel

> Richard Shockey
> Sent: Monday, February 18, 2008 5:22 PM
> To: 'Jonathan Rosenberg'; 'Paul Kyzivat'
> Cc: 'IETF SIP List'

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 18 Feb 2008 17:54:45 -0500

> downhill. "Right to usage" is even more a slippery slope...been there done

I haven't been involved in the space like you have. I realize that 
"ownership" iss probably too strong a word. Pick whatever word you like. 
Some entity is entitled to have a phone associated with a particular 
number, and other entities are not entitled to have phones associated 
with that same number. Whatever you want to call that is ok with me.

When the feds show up with the warrant, what does the SP tell them? That 
is what defines it.

In those places where public enum is supported, some entity is entitled 
to give instructions on how it shall be populated for a given number. 
What do you call that entity?

	Thanks,
	Paul

---

From: "Henry Sinnreich" <[email-masked]>
Date: Mon, 18 Feb 2008 15:27:32 -0800

> If the receiver of the call doesn't want to talk to whomever calls, 
> don't they just hang up?  

It takes far more time to listen than deleting an email and is far more
annoying than email spam. IMO the efforts proposed here are fully
justified, though it will not be easy to accomplish.

One of the main reasons for giving up PSTN service may be to just get
relief from telemarketing calls.

Henry

-----Original Message-----
From: Frank W. Miller [mailto:[email-masked]] 
Sent: Monday, February 18, 2008 11:08 AM
To: Henry Sinnreich; 'Paul Kyzivat'; 'Shockey, Richard'
Cc: 'IETF SIP List'
Subject: RE: [Sip] New I-D on RFC4474 and phone numbers

I'm a little confused by the need to "sign" phone numbers.  I mean,
whomever
uses the number makes a call to or from it right?  If the receiver of
the
call doesn't want to talk to whomever calls, don't they just hang up?
This
seems like a lot of extra work for little gain.

Thanks,
FM

-----Original Message-----

Paul,

Henry

-----Original Message-----

Jonathan,

user friendly.)

	Thanks,
	Paul

---

From: "Richard Shockey" <[email-masked]>
Date: Mon, 18 Feb 2008 19:13:43 -0500

>  with that same number. Whatever you want to call that is ok with me.

That is the problem .. first you have the service provider of record that
actually issued the number under the authority of a nation state then the
entity that actually uses that number (consumer or enterprise) all of this
is complicated by the issue of Local Number Portability, of course and
lastly the fact that the number could be used by multiple applications,
delivered by different application service providers etc.

>  
>  When the feds show up with the warrant, what does the SP tell them?
>  That is what defines it.

Ah if it were only that simple :-) 

Well that's when you get into the real fun of the fact that numbers could be
issued by a wholesale service provider to a downstream application provider
so the carrier of record in many nation states is not the entity providing
the service ..aka Vonage and Level3 for instance. This is a problem that is
vexing our friends in the LEA's even as we speak. The numbering databases do
not completely reflect the reality of service deployments.

---

From: "Richard Shockey" <[email-masked]>
Date: Mon, 18 Feb 2008 19:19:17 -0500

>  In your experience would there be a quorum of incumbent providers who
>  would be willing to publish their numbers in an infrastructure enum,
>  available only to other "club members"?  Such a thing is essentially
>  the logical conclusion of Peppermint, isn't it?  Just in a distributed
>  form.
>  
>  -hadriel

Short answer NO but that is IMHO. Not in a global DNS tree, it's too fraught
with real politics and I mean REAL politics.

It not entirely clear the pain threshold has been reached on the overriding
identity problem you all are addressing and yes the ITU is definitely
looking at the issue. 

PEPPERMINT is not about the provisioning of public, infrastructure (carrier
of record) or private ENUM trees. It could easily encompass bilateral or
multilateral arrangements or PBX to SP data exchanges.

PEPPERMINT does not presume any business model for the exchange of data (
which certainly could include a cert tree ) only a standard methodology for
the exchange of data itself. 

And yes you all are welcome to come to the 2nd PEPPERMINT BOF, alas beer
will not be served.

>  > "less than spectacular .." now there is an understatement, if there
>  ever
>  > was
>  > The very idea that there is going to be some consensus on who "owns"
>  a
>  > phone
>  > >  based authentication, when combined with whitelists and
>  blacklists,
>  > >  can
>  > >  help.
>  > >
>  > >  -Jonathan R.
>  > >
>  >

---

From: [email-masked]
Date: Mon, 18 Feb 2008 21:33:52 -0500

From: Hadriel Kaplan <[email-masked]>

   Yes, there is no debate that cost/expense and closed networks have
   kept phone calls from being hammered like email.
   Unfortunately/fortunately, that cost is dropping.  This topic isn't
   about today - it's about 5-20+ years from now.

Of course, the entire economic driver of SIP adoption is the hope of
reducing the cost of phone calls ... to the point that SPIT would be
easy and inexpensive!

Dale

---

From: [email-masked]
Date: Mon, 18 Feb 2008 21:53:10 -0500

From: "Joel M. Halpern" <[email-masked]>

I would start by saying "the user part is never an E.164 number,
unless a particular domain uses it that way (and you have to route the
call to that domain for it to make that determination)".

I appear to be wrong, since RFC 3261 gives examples of SIP URIs with
user=phone and phone-context URI parameters.  But the best information
I can find is RFC 2848, and it appears that that RFC is about
identifying the user-part as a *dial string* to be interpreted within
the context of the dial plan at the specified SIP proxy.

Where is the normative description of when SIP user-parts are to be
interpreted as "phone numbers"?

Dale

---

From: Dean Willis <[email-masked]>
Date: Mon, 18 Feb 2008 21:05:11 -0600

> legal definition of ownership of the numbers.

That's on a different level of Dean;s 7-Layer Model -- the Political.

The simplest approach is that a top-level authority (say, ITU) operate  
a top-level PKG that then provides private keys to the national  
authorities, who then act as PKGs for lower-level delegations, and on  
down to the individual  phone number.

So, if you're in possession of a private key for your phone number,  
from the PKG that's authoritative for your phone number (according to  
whichever definition of that  authority we adopt), you are in  
possession of the identity indicated by that phone number.  Not all  
that different from enum, just a different algorithm for the key  
management and crypto.

--
Dean

---

From: "Joel M. Halpern" <[email-masked]>
Date: Mon, 18 Feb 2008 22:13:32 -0500

That, treating anything that smells like an E.164 like an E.164, may 
well be common practice.
But it seems to me
a) it is a practice which is inherently misleading and error prone
b) it is a practice we can not sensibly design for / around.
c) It is not the working group's problem to repair security flaws 
introduced by such behavior.  It is the vendor's problem.

Yours,
Joel M. Halpern

---

From: Hadriel Kaplan <[email-masked]>
Date: Mon, 18 Feb 2008 22:54:23 -0500

What you say sound like the arguments against dealing with consumer NATs.  :)
Inline...

> From: Joel M. Halpern [mailto:[email-masked]]
> Sent: Monday, February 18, 2008 10:14 PM
> To: Hadriel Kaplan
> Cc: Paul Kyzivat; IETF SIP List
> Subject: Re: [Sip] SIP & E.164 assertions
>

It works right now, because virtually all sip communication is E.164's, if the userpart is digits at all (and long enough, and following certain patterns).  In fact, I'd argue it works *better* than not doing it, for that reason.  Most of the time, maybe virtually ALL of the time, when there is no user=phone param, it's because a device screwed up not putting it there.
So you've got the incumbent/deployed boxes doing something that works.  If it ain't broke, no one is going to fix it.  Especially if fixing it breaks something already deployed.
(BTW, I'm talking about provider side - I don't know if this holds true in Enterprise SIP at all, given their funky dial plans, but my guess is for them it's a pattern match or external dial prefix match)

> b) it is a practice we can not sensibly design for / around.

I'm not sure we need to.  I didn't catch what the "problem" with this is with regard to E.164 assertions?  I mean let's pretend all of them have user=phone, and look just like a TEL username should or whatever.  What does that solve in terms of e164 identity?

> introduced by such behavior.  It is the vendor's problem.

And what exactly is the security flaw introduced?  You're not telling me that a user=phone parameter is somehow a security mechanism?  Is it like the evil bit or something?  ;)

-hadriel

---

From: Dean Willis <[email-masked]>
Date: Mon, 18 Feb 2008 22:12:22 -0600

On Feb 18, 2008, at 4:22 PM, Richard Shockey wrote:
> a phone

Counterargument: If I call phone number X, and the responding party  
can complete a media-path handshake against the published key for that  
number, then I'd claim they "own" it. Possession is, after all,  
9/10ths of the law.

In other words, to heck with the government -- who answers the phone?

--
dean

---

From: Hadriel Kaplan <[email-masked]>
Date: Mon, 18 Feb 2008 23:08:59 -0500

> From: Richard Shockey [mailto:[email-masked]]
> Sent: Monday, February 18, 2008 7:19 PM
> To: Hadriel Kaplan; 'Jonathan Rosenberg'; 'Paul Kyzivat'
> Cc: 'IETF SIP List'

I agree with you there.  I'm thinking something slightly less global, like local in fact.

> multilateral arrangements or PBX to SP data exchanges.

That's not how I meant it.  I meant, as it appears from the ESPP proposal, the idea is to exchange prefix and possibly unique number data reachability data.  It is not clear if it would encompass ported numbers too, or not.  Regardless, ESPP can't actually handle transit cases as written, but one possible outcome is that such data exchanged could let the providers learn the terminating provider domain, and thus if a call comes from it, what should have signed it. (sort of like uRPF in IP routing)  Doesn't matter anyway for now, just fantasizing. :)

> And yes you all are welcome to come to the 2nd PEPPERMINT BOF, alas beer

I would think it should be schnapps... peppermint that is.  If you guys can't come up with a better name. (please!)

-hadriel

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 18 Feb 2008 23:32:32 -0500

Hadriel,

> (BTW, I'm talking about provider side - I don't know if this holds true in Enterprise SIP at all, given their funky dial plans, but my guess is for them it's a pattern match or external dial prefix…

What you are describing is a "do what I mean" system rather than a "do 
what I say" system.

With enough brute force you can make this work, by configuring 
everything to understand the conventions of all its neighbors. (And I 
know that is the typical deployment style used by my own employer's 
products.) It is better than nothing, but it is far from ideal.

It of course then enhances the belief that peering arrangements must be 
bilateral, because you need to negotiate the mapping of dial strings. 
(And if your business is managing these boundaries then this may be a 
good thing.)

But a system where everyone uses E.164 numbers, and where they *say* 
they are E.164 numbers, would simplify a lot of that.

> I'm not sure we need to.  I didn't catch what the "problem" with this is with regard to E.164 assertions?  I mean let's pretend all of them have user=phone, and look just like a TEL username should…

I know of systems that assume a user part containing digits is a dial 
string. They don't quite "get it" that the dial string of one party may 
not be a vaid dial string for another party, or that even if it is it 
may denote a different destination. Is that a "problem"? I guess that 
depends.

Is this an appropriate thing to do? IMO no. But in a world where 
everybody decides for themselves what the user part of somebody else's 
phone number means, who is to say it is wrong?

	Paul

---

From: Hannes Tschofenig <[email-masked]>
Date: Tue, 19 Feb 2008 09:24:17 +0200

Hi Richard

I have thought about that. When I spoke to a couple of people about 
requesting a slot in ENUM they told me that ENUM is not the right place 
to discuss this.
Feedback from the ENUM WG would certainly be helpful. ;

Ciao
Hannes

Richard Shockey wrote:
>>  > blacklists, can

---

From: Hannes Tschofenig <[email-masked]>
Date: Tue, 19 Feb 2008 09:24:29 +0200

Hi Richard,

> Yea and lets end world hunger while we're at it ...
It sounds like a super big thing when someone talk about an "oracle". 
The DNS is in some sense such an oracle since it returns you an IP 
address when you give it the FQDN. Hence, we are talking about a 
distributed database in this case for providing E.164 ownership. It is, 
for sure, more complicated than other techniques (such as matching the 
content of certain fields in a certificate with fields in a protocol 
message) but if these simpler techniques don't  work what are you 
supposed todo?

Ciao
Hannes

---

From: "Dan Wing" <[email-masked]>
Date: Mon, 18 Feb 2008 23:55:37 -0800

> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Dean Willis
> Sent: Monday, February 18, 2008 8:12 PM
> To: Richard Shockey
> Cc: 'IETF SIP List'; 'Paul Kyzivat'

That is what draft-wing-sip-e164-rrc-01 does, except it does it
over the signaling path.  The same thing could be done over the 
media path (using TOTE, even, if we like), if doing RRC over the
media path is deemed better/stronger/faster.

-d

---

From: "Dan Wing" <[email-masked]>
Date: Tue, 19 Feb 2008 00:09:23 -0800

> deployments of certs and signatures, etc. etc.  Just don't 
> kid yourself that its going to stop phishing or spit cuz it won't

Nothing will stop phishing or spit.  Absolutely nothing.  Similar
attacks happen in the Real World with looks-like-real FedEx trucks
and Border Patrol vans,
http://abcnews.go.com/Blotter/popup?id=4154733&contentIndex=1&page=6

What strong identity will do is create ... strong identity.  With
that, we can build useful and reliable whitelists.  We can build
useful and reliable reputation systems.  We can build a lot of
things.

Without strong identity, SIP will behave very much like everyone's
inbox.  Except, unlike email, you cannot filter SIP using content 
filtering (because there is no message) so popular and relatively
effective tools like Bayesian filters and SpamAssassin will not 
work for SIP.

So SIP needs effective and functional identity.

Nobody believes identity, by itself, will stop spit or phishing.  
However, identity is necessary to build anything else of value.

-d

---

From: "Dan Wing" <[email-masked]>
Date: Tue, 19 Feb 2008 00:25:56 -0800

> >  Frank,
> >  
> >  So are you asserting that reliable callerid is not needed, 
> >  or that it is not possible?
> >  
> >  is>  reliable if the providers are careful. It breaks when 
> >  providers trust

The first page of http://www.google.com/search?q=caller+id+spoofing shows 4
companies that appear to provide caller ID spoofing for a fee.  Of course,
providers don't care much about Caller ID spoofing as that only fools
subscribers.

So, to your question:  providers do care about the ANI, which is used by their
own systems.  I will leave you to search the Internet to see if there are
companies and products that proport to sell or provide ANI spoofing.  I found
1 product and 3 service companies on the first page of my Google search.

-d

---

From: Hadriel Kaplan <[email-masked]>
Date: Tue, 19 Feb 2008 05:42:16 -0500

Hey Paul,
Inline...

> Sent: Monday, February 18, 2008 11:33 PM
>

Yes, but I should have been clearer - I'm not advocating we try to standardize it or some such.  It just is the reality.  So we can just continue assuming user=phone and such make it an e164, for the purpose of the identity mechanism for e614 (whatever the mechanism is).  Those who treat other things as e164 will just apply the same rules to them.  We may just need a "I signed this as e164" flag if the identity mechanism is different than for non-e164, or some such concept.

> (And if your business is managing these boundaries then this may be a

Actually, that is very much NOT in the best interest of those managing such things.  Any configuration whatsoever slows down peering bring-up time, and that does not help sell more border boxes.  It is in the best interest of border-box vendors to make it as plug-play/standard as possible.  (and I don't think peering is bilateral because of dial-string formats, but that's getting off-topic)

> they are E.164 numbers, would simplify a lot of that.

Yeah, no disagreement there.

-hadriel

---

From: "Richard Shockey" <[email-masked]>
Date: Tue, 19 Feb 2008 10:00:52 -0500

Well ENUM is on a short leash in Philadelphia with only 1 hour, we are
trying to slowly but deliberately wind things down. It might not be the best
time, but we certainly have large body of expertise in dealing with E.164
numbers and the history of trying to deal with number mappings in globally
distributed databases. :-) 

It's certainly something worth discussing the ENUM WG list from time to time
but the real issues are all layer 8 and above.

>  Hannes Tschofenig
>  Sent: Tuesday, February 19, 2008 2:24 AM
>  To: Richard Shockey
>  >>  > > In those places where public enum is in operation, I think
>  there
>  >>  is
>  >>  > > already a legal mechanism in place to give the owner of record
>  of
>  >>  a

---

From: "Richard Shockey" <[email-masked]>
Date: Tue, 19 Feb 2008 10:34:33 -0500

>  message) but if these simpler techniques don't  work what are you

I wish I knew. But I do know Patrik Faltstrom, I and the IAB-IESG have no
stomach for sitting around the ITU in Geneva for the next 5-7 years trying
to get them to buy into a solution involving another apex involving e164
numbers. 

We are still trying to resolve the issue regarding the concept of
Infrastructure ENUM ( which could involve certs BTW) and the associated
drafts we produced in the last couple of years.  We have been told that the
IAB is trying to finalize the liaison letter to ITU SG2 on that issue as we
speak.

You might recall Patrik and I sent a Memorandum on this very issue of
Infrastructure ENUM and related issues involving e164 numbers to the
IAB-IESG some time ago.

http://www.ietf.org/mail-archive/web/enum/current/msg05529.html

If there is going to be a solution to the SIP identity problem involving
e164 numbers, it will not IMHO be solved in the IETF.

---

From: Hannes Tschofenig <[email-masked]>
Date: Tue, 19 Feb 2008 17:49:18 +0200

> e164 numbers, it will not IMHO be solved in the IETF.
Interesting view. I obviously does not appear to be an easy thing;
in the draft I called this "There is non-neglectable deployment 
incentive challenge."

---

From: "Richard Shockey" <[email-masked]>
Date: Tue, 19 Feb 2008 11:19:54 -0500

This is not to say that the IETF could play a useful and essential role. We
can certainly develop and define the requirements, use cases etc. 

In addition the IETF can architect a solution but experience tells me that
deployment and implementation issues surrounding e164 issues will need the
cooperation of "other bodies" which is where the problem lies. It's not
really the ITU, in fact the ITU is a much easier place to get things done
these days. The complications arise with the ITU member states, who
jealously guard their diplomatic and political prerogatives.

This was the conclusion that we drew when the Infrastructure ENUM issues
first arose. We essentially said ..."Here is this problem, this is what we
(IETF) think, the solution is in your court. Have a nice day." 

>  From: Hannes Tschofenig [mailto:[email-masked]]
>  Sent: Tuesday, February 19, 2008 10:49 AM
>  To: Richard Shockey
>  Cc: 'IETF SIP List'; [email-masked]
>  Subject: Re: Infrastructure issues involving e164 numbers
>  
>

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 19 Feb 2008 11:31:50 -0500

Well, maybe that is what is needed. If there is to be anything 
approaching reliable callerid then there needs to be *something* that is 
directly tied to the "ownership" of E.164 numbers.

	Paul

---

From: "Dan Wing" <[email-masked]>
Date: Tue, 19 Feb 2008 10:04:12 -0800

Richard Shockey wrote:

> If there is going to be a solution to the SIP identity 
> problem involving e164 numbers, it will not IMHO be 
> solved in the IETF.

Please do not assume that the only path to E.164 enlightenment is
ENUM.  

I have one proposal on the table, draft-wing-sip-e164-rrc, which 
does not use ENUM.  My proposal may not be perfect, but it does 
not use ENUM.

-d

---

From: Hannes Tschofenig <[email-masked]>
Date: Tue, 19 Feb 2008 20:19:04 +0200

True.

There are other solution approaches that have a different ownership 
criteria.
draft-wing-sip-e164-rrc, for example, performs a return routability test.

---

From: "Francois Audet" <[email-masked]>
Date: Tue, 19 Feb 2008 12:50:10 -0600

Another "solution" is to not do it.

By that I mean, use RFC 4474 for domain-based security, and if you 
insist on using phone numbers, then it's not "secured that way".

Before the flaming start: by definition, if something is addressed by a phone
number,  it is something that is likely to be reacheable through the PSTN.

The way security works in the PSTN is completely different. The media is almost
never encrypted for one. So in the context of SIP, it means there is a gateway 
somewhere destroying the end-to-end nature of the encryption.

Even for the Identity, it's different. For one thing, the Identity assertion
is not end-to-end à-la-RFC 4474.

So, I'm proposing that if you are using phone numbers as your identity, then
it is not a design requirement of this group to re-invent a "better" identity
security system for the PSTN.

It's not because something is a problem that it necessarily needs to be solved.

My 2 cents.

> Behalf Of Jonathan Rosenberg
> Sent: Monday, February 18, 2008 11:36
> To: Paul Kyzivat
> Cc: IETF SIP List
> I agree that something along the lines of enum could solve 
> this problem, and I believe there was a draft that proposed 
> such a thing. This has been discussed since the start of rfc4474.
> 
> However, I fear that saying, 'use enum' is kind of like 
> saying, we'll just use an All-Knowing Oracle, so lets figure 
> out the interface protocol to the Oracle. The easy part is 
> the interface (the enum mechanism). The actual hard problem 
> is how to get those entries populated. The deployment of 
> public enum has been - shall we say - less than spectacular. 
> I'd hate for that to be our only solution. Not that its 
> obvious what else to do; though I do suggest in my draft how 
> domain based authentication, when combined with whitelists 
> and blacklists, can help.
> 
> -Jonathan R.
> 
> Paul Kyzivat wrote:
> > Jonathan,
> > 
> > of the phone number is the one who may obtain the 
> certificate for that number.
> > 
> > puts an
> This list is for NEW development of the core SIP Protocol Use 
> [email-masked] for questions on current sip

---

From: "Richard Shockey" <[email-masked]>
Date: Tue, 19 Feb 2008 14:10:22 -0500

Oh of course, but you would not get an argument from me if you asserted that
sure the path to damnation is through ENUM.

>  From: Dan Wing [mailto:[email-masked]]
>  Sent: Tuesday, February 19, 2008 1:04 PM
>  To: 'Richard Shockey'; [email-masked]; 'IETF SIP List'
>  Cc: [email-masked]
>  Subject: RE: [Sip] Infrastructure issues involving e164 numbers
>  
>  
>  
>  Richard Shockey wrote:
>

---

From: Alan Johnston <[email-masked]>
Date: Tue, 19 Feb 2008 13:18:46 -0600

Couldn't have put it better myself.

+1

Thanks,
Alan

Francois Audet wrote:
>>> I thought the problem was already well known, but perhaps 
>>>       
>> not. IMO the 
>>     
>>> domain name. That of course would depend on a model where 
>>>       
>> the "owner" 
>>     
>>> E.164 number in From, and can sign it with a cert for the 
>>>       
>> enum mapped 
>>     
>>> domain name corresponding to that number, then that ought 
>>>       
>> to be valid 
>>     
>>> particular phone number control over the contents of the 
>>>       
>> corresponding 
>>     
>>> Combine all that and you have a complete e2e identity model 
>>>       
>> for phone 
>>     
>>> To use this approach the From header should contain either 
>>>       
>> a TEL URI, 
>>     
>>> or a sip/sips URI containing the enum-mapped domain name 
>>>       
>> corresponding 
>>     
>>> to the phone number. (I would rather see the TEL used for 
>>>       
>> this - it is 
>>     
>>> more user friendly.)
>>>
>>>     Thanks,
>>>     Paul
>>>
>> http://www.ietf.org/internet-drafts/draft-rosenberg-sip-rfc4474-conce
>>     
>>>> rns-00.txt
>>>>
>>>>
>>>> This is basically a discussion on the security properties 
>>>>         
>> of rfc4474 
>>     
>>>> with phone numbers, and a comparison to rfc3325 in this 
>>>>         
>> case. Also a 
>>

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 19 Feb 2008 14:24:39 -0500

I think we don't need something *better* than the PSTN, though that 
would be nice. What I think we need is something that is *not worse* 
than the PSTN. The problem is defining what that means.

I think that means at least:

- when you connect via sip you get a callerid for at least those
   pstn callers where you would have gotten one if you had a pstn phone
   *and* that callerid was "correct".

- callerid is available to callees from sip callers with E.164 AORs
   when it hasn't been intentionally blocked and the caller is the
   legitimate "owner" of the number.

- the frequency with which "incorrect" (spoofed) callerid is delivered
   to callees is no worse, on average, than with pure pstn calls.

I realize this are a bit vague and hard to measure. But I think this is 
subjectively what will be required for sip to be widely accepted as a 
substitute for pstn phone service.

	Paul

---

From: "Francois Audet" <[email-masked]>
Date: Tue, 19 Feb 2008 13:43:41 -0600

I'm not sure I agree with that.

I think we want something that is better than the PSTN. I just don't think it's the
right question to ask.

And specifically, I don't think "identity" for PSTN numbers should be our mandate. 

> Sent: Tuesday, February 19, 2008 11:25
> To: Audet, Francois (SC100:3055)
> Cc: Jonathan Rosenberg; IETF SIP List
> I think we don't need something *better* than the PSTN, 
> though that would be nice. What I think we need is something 
> that is *not worse* than the PSTN. The problem is defining 
> what that means.
> 
> I realize this are a bit vague and hard to measure. But I 
> think this is subjectively what will be required for sip to 
> be widely accepted as a substitute for pstn phone service.
> 
> 	Paul
> 
> Francois Audet wrote:
> > Before the flaming start: by definition, if something is 
> addressed by 
> > a phone number,  it is something that is likely to be 
> reacheable through the PSTN.
> > 
> > The way security works in the PSTN is completely different. 
> The media 
> > is almost never encrypted for one. So in the context of 
> SIP, it means 
> > there is a gateway somewhere destroying the end-to-end 
> nature of the encryption.
> > 
> > Even for the Identity, it's different. For one thing, the Identity 
> > assertion is not end-to-end à-la-RFC 4474.
> > 
> > So, I'm proposing that if you are using phone numbers as your 
> > identity, then it is not a design requirement of this group to 
> > re-invent a "better" identity security system for the PSTN.
> > 
> >> Jonathan Rosenberg
> >> I agree that something along the lines of enum could solve this 
> >> problem, and I believe there was a draft that proposed 
> such a thing. 
> >> This has been discussed since the start of rfc4474.
> >>
> saying, we'll 
> obvious what 
> >> else to do; though I do suggest in my draft how domain based 
> >> authentication, when combined with whitelists and blacklists, can 
> >> help.
> >>
> >> -Jonathan R.
> >>
> >> Paul Kyzivat wrote:
> >>> Jonathan,
> >>>
> >> [email-masked] for questions on current sip Use 
> >> [email-masked] for new developments on the application of sip
> >>
> > 
>

---

From: "Joel M. Halpern" <[email-masked]>
Date: Tue, 19 Feb 2008 14:50:18 -0500

I am coming to the same conclusion from the discussion.
Yours,
Joel

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 19 Feb 2008 14:57:54 -0500

> I think we want something that is better than the PSTN. I just don't think it's the

I certainly *want* something better than PSTN. But perhaps we don't 
*need* that. I think we do *need* something "as good as" the PSTN.

But perhaps the first order of business is to come to agreement on what 
we need.

	Paul

---

From: "Francois Audet" <[email-masked]>
Date: Tue, 19 Feb 2008 13:59:47 -0600

I think we might be talking about two different aspects.

For "phone numbers", I agree with you that parity is ok.

For "email-looking addresses", I believe the bar is higher (and we
have it already with 4474).

> Sent: Tuesday, February 19, 2008 11:58
> > I think we want something that is better than the PSTN. I 
> just don't 
> > think it's the right question to ask.
> 
> But perhaps the first order of business is to come to 
> agreement on what we need.

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 19 Feb 2008 16:22:24 -0500

> have it already with 4474).

OK. THen we aren't far apart. I agree we want and have something better 
for email-style addresses where the domain is significant. It is the 
"phone number" addresses I am concerned with here. I think we must have 
parity, and ideally better when the PSTN isn't involved.

	Paul

---

From: "Henry Sinnreich" <[email-masked]>
Date: Tue, 19 Feb 2008 18:42:46 -0800

>"Here is this problem, this is what we

I believe this puts it in nutshell.

The telecom specific uses of ENUM technology are more appropriately
handled in the telecom standards organizations, such as the ITU-T, and
ETSI.

Let's move on and work with Internet and web addressing that I believe
have the real potential for the Internet standards development and where
IETF resources are better placed.

Thanks, Henry

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Richard Shockey
Sent: Tuesday, February 19, 2008 10:20 AM
To: [email-masked]
Cc: 'IETF SIP List'; [email-masked]
Subject: Re: [Sip] Infrastructure issues involving e164 numbers

This is not to say that the IETF could play a useful and essential role.
We
can certainly develop and define the requirements, use cases etc. 

In addition the IETF can architect a solution but experience tells me
that
deployment and implementation issues surrounding e164 issues will need
the
cooperation of "other bodies" which is where the problem lies. It's not
really the ITU, in fact the ITU is a much easier place to get things
done
these days. The complications arise with the ITU member states, who
jealously guard their diplomatic and political prerogatives.

This was the conclusion that we drew when the Infrastructure ENUM issues
first arose. We essentially said ..."Here is this problem, this is what
we
(IETF) think, the solution is in your court. Have a nice day."

---

From: Jonathan Rosenberg <[email-masked]>
Date: Tue, 19 Feb 2008 21:44:03 -0500

Actually what I am hoping to do is to just clearly document the 
applicability of RFC4474 to numbers and be much crisper with guidance on 
when to use it, when to not, what it buys you with numbers (since it 
does help a little even then - receivers can know the domain that 
asserts that number and use blacklists/whitelists to judge trustability).

I also want to make sure we are not basing SRTP security on integrity 
properties delivered with RFC4474, when said properties aren't really 
delivered so well with phone numbers.

-Jonathan R.

Paul Kyzivat wrote:
>>> From: Paul Kyzivat [mailto:[email-masked]] Sent: Tuesday, 
>>> February 19, 2008 11:58
>>> But perhaps the first order of business is to come to agreement on 
>>> what we need.
>>
>

---

From: "Joel M. Halpern" <[email-masked]>
Date: Tue, 19 Feb 2008 21:50:50 -0500

Well, it is a little hard to be crisp and clear about the usage of 4474 
with "numbers" when we don't know what a "number" is, nor do we know 
when we have one.
So I am not sure that your stated goal is achievable without first 
solving some other problems.

Yours,
Joel M. Halpern

---

From: [email-masked]
Date: Tue, 19 Feb 2008 23:06:46 -0500

From: Dean Willis <[email-masked]>

Whoever publishes the keys ipso facto defines who owns the numbers.
And there's no reason that there would be only one publisher.

Dale

---

From: Hadriel Kaplan <[email-masked]>
Date: Wed, 20 Feb 2008 00:09:11 -0500

> Francois Audet
> Sent: Tuesday, February 19, 2008 3:00 PM
>

Isn't that like saying we have created the best saddle for unicorns one could possible make?  (and I should note that the saddle isn't even made for all humans to sit in, and isn't even very sturdy)
Ok, maybe unicorn isn't quite right... maybe a Lipizzaner horse.
:)

-hadriel

---

From: Hannes Tschofenig <[email-masked]>
Date: Wed, 20 Feb 2008 09:59:40 +0200

Hi Henry,

there are two aspects to the story:

* Do you believe there is a problem for security when interworking 
between the PSTN and SIP?
(e.g., in the way how SIP Identity deals with E.164 numbers)

* If yes, do you think that someone should be investigating what todo 
about it?

Don't get hung-up in the details of a specific strawman proposal that, I 
believe, shows quite well some of the challenges around the aspect of 
E.164 number ownership.

Ciao
Hannes

---

From: "Elwell, John" <[email-masked]>
Date: Wed, 20 Feb 2008 09:24:18 +0000

Jonathan,

I agree with a lot of what this says. A few comments:

1. "Unfortunately, this problem is a FUNDAMENTAL PROPERTY OF PHONE
   NUMBERS.  No specifications or efforts on the part of IETF can fix
   this problem.  Phone numbers are fundamentally NOT scoped to a
   domain, and attempts to represent them in any other form are
   ultimately futile from an identification perspective."
But on the other hand, you can at least see what domain the request came
from, and if you trust that domain, this might be of value. The
particular value of the user part of the SIP URI may not be some
important, in some scenarios, as the domain part. This seems to be
acknowledged later when it talks about the "second model".

2. "However, in the second model, intermediate domains do not resign
   requests.  Furthermore, UA's utilize white lists and black lists of
   domains that are known to be trustworthy (or not).  Today, such lists
   do exist and are provided for email spam.  One can imagine a UA
   contacting such a service periodically, or upon an incoming call, to
   verify the signing domain against the list."
Or maybe the user is expecting a call from a particular domain (e.g.,
his bank) or answers the call and the caller announces that he/she is
from the bank. Of maybe the user has called his bank and uses
connected-identity to ensure that he really is connected to his bank.
These all seems to be situations akin to the second model with some
practical benefit.

3. "Thus, DTLS-SRTP still provides better security than Sdescriptions.
   However, when used with phone numbers, it is by no means ideal.  Most
   importantly, it does NOT provide guarantees that intermediaries have
   not been able to intercept and decrypt the media."
Not true. If you use DTLS-SRTP with RFC 4474 and an E.164 number in the
SIP URI, it DOES provide a guarantee that intermediaries between the
domain in the SIP URI and the UAS are unable to intercept and decrypt
media. This seems to be of value in some situations.

John

> Sent: 18 February 2008 05:07
> To: IETF SIP List
> Subject: [Sip] New I-D on RFC4474 and phone numbers
> 
> I just submitted:

---

From: "Elwell, John" <[email-masked]>
Date: Wed, 20 Feb 2008 09:35:55 +0000

Yes, I think this is the right direction. I would not want to prevent
investigations on how to do it better, e.g., based on the ENUM tree in
some way. But what you propose is a practical step that gives some value
in the short term, both in terms of anti-spam and DTLS-SRTP.

Perhaps we also need to do even more to promote email-style SIP URIs,
alongside Tel URIs for use when interworking with PSTN. This does not
necessarily prevent the use of numeric values in the user part of
email-style URIs (without user=phone), thereby making it easier to
correlate the a SIP URI with the telephone number that would need to be
used to contact the user from the PSTN. Perhaps it would be beneficial
to provide both an email-style SIP URI and a Tel URI in From, so that
the Tel URI can be used if the call breaks out to PSTN (where end-to-end
security is not achievable) and the SIP URI can be used in other cases.

John

> Sent: 20 February 2008 02:44
> To: Paul Kyzivat
> Cc: IETF SIP List; Francois Audet

---

From: "Elwell, John" <[email-masked]>
Date: Wed, 20 Feb 2008 10:13:26 +0000

Hannes,

I know the questions were directed at Henry. However, if I may
intervene:

> Behalf Of Hannes Tschofenig
> Sent: 20 February 2008 08:00
> To: Henry Sinnreich
> Cc: IETF SIP List; [email-masked]; Richard Shockey
[JRE] There are actually two separate situations: use of E.164 numbers
for communication within the SIP world; and use of E.164 numbers when
interworking between SIP and PSTN. Did you intentionally limit your
question to the second of these?
Assuming that was the intention, I would point out that we can never
achieve end-to-end security when interworking with PSTN. The best we can
do is achieve security across the local SIP part as far as the PSTN
gateway. There are different opinions as to whether the PSTN itself is
secure - I won't express an opinion on that aspect. However, what
happens beyond the PSTN? Another SIP hop? An H.323 hop? There is no way
of knowing whether that is secured or not. Some guarantee of security as
far as the gateway is the best we can achieve, and, importantly, the
user should be made aware of this - do not raise his expectations
concerning the end-to-end security of the call.

Let's concentrate on the end-to-end SIP case and provide a good security
solution for that. One possibility might be to use email-style URIs for
that.

John

> Behalf Of

---

From: "Horvath, Ernst" <[email-masked]>
Date: Wed, 20 Feb 2008 11:53:20 +0100

John,

> Behalf Of Elwell, John
> Sent: Wednesday, February 20, 2008 11:13 AM
> To: [email-masked]; Henry Sinnreich
>[...]

Unfortunately email-style URIs make identity portability harder. Number
portability is a regulatory requirement in many countries and solved for
E.164 numbers. I can imagine that regulators might require an equivalent
feature from SIP providers.

Ernst

---

From: "Elwell, John" <[email-masked]>
Date: Wed, 20 Feb 2008 11:39:23 +0000

Hadriel,

Thanks for this draft. One comments:

When talking about changing the host part of SIP URIs, are you referring
just to SIP URIs containing an E.164 number in telephone-subscriber
format (e.g.: [email-masked];user=phone)? Or are you also
talking about other forms of URI that look like E.164 number (e.g.,
[email-masked])? Presumably you are not talking about email
style URIs.

John

> Behalf Of Hadriel Kaplan
> Sent: 18 February 2008 20:20
> To: IETF SIP List
> Subject: [Sip] New I-D on why From/To-URIs are changed at 
> provider borders
> 
> As part of an off-line discussion regarding Kai Fischer's 
> draft on e2e-security-media and whether his From-URI copying 
> tactic would succeed or not at a policy level, if rfc4474 
> fails to do so, I gave my 2 cents on what some providers had 
> been telling me.  Dan asked me to write up a draft on it, in 
> case people are interested.  This is the draft:

---

From: "Elwell, John" <[email-masked]>
Date: Wed, 20 Feb 2008 11:48:37 +0000

Ernst,

In a separate message on this list earlier today I suggested email-style
along with TEL URIs. The latter would be used when interworking with
PSTN and would allow number portability to be achieved.

Also, for enterprises email-style still gives number portability - an
enterprise would keep its domain name even when changing the SIP
carrier. Admittedly that model doesn't work for an individual user that
relies on the carrier's domain.

John

> From: Horvath, Ernst 
> Sent: 20 February 2008 10:53
> To: Elwell, John; [email-masked]; Henry Sinnreich
> Unfortunately email-style URIs make identity portability 
> harder. Number portability is a regulatory requirement in 
> many countries and solved for E.164 numbers. I can imagine 
> that regulators might require an equivalent feature from SIP 
> providers.
> 
> Ernst
> 
> > 
> > John
> > 
> > > 
>

---

From: "PFAUTZ, PENN L, ATTCORP" <[email-masked]>
Date: Tue, 19 Feb 2008 10:43:29 -0500

Section 3.2 suggests there is no definition for Infrastructure ENUM. At least reference RFC 5067!

Section 3.3  wallet garden model? I like that :-)
 
Is there a reason why a carrier can't use infrastructure ENUM to certify a given populated caller ID using a general rather than a specific key? (If they were willing to)

Penn Pfautz
AT&T National Access Management
+1-732-420-4962

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Richard Shockey
Sent: Tuesday, February 19, 2008 10:01 AM
To: [email-masked]
Cc: 'IETF SIP List'; [email-masked]; 'Paul Kyzivat'
Subject: Re: [Enum] [Sip] New I-D on RFC4474 and phone numbers

>  >>  > this problem,
>  >>  > the "owner" of
>  >>  > a TEL URI, or

enum mailing list
[email-masked]
http://www.ietf.org/mailman/listinfo/enum

---

From: Hannes Tschofenig <[email-masked]>
Date: Wed, 20 Feb 2008 14:06:10 +0200

Hi John,

you are essentially suggesting to use an identifier like 
[email-masked];user=phone whereby example.com corresponds to the 
domain that operates the authentication service?

Ciao
Hannes

---

From: Patrik Fältström <[email-masked]>
Date: Wed, 20 Feb 2008 07:15:58 +0100

This should not be a surprise to anyone...

Due to the complex management of of E.164 numbers, which includes  
management, routing to, billing models and everything else, I have  
personally all the time thought sip-email-like addresses "win". That  
will be the format used for routing of "calls" in the future. Full stop.

What ENUM solves is something that can be viewed as an intermediary  
problem on mapping from the (old) E.164 addressing to the (new) domain  
name based.

Sure, E.164 numbers will be around for a Very Long Time, but domain  
based address is what the Internet use, and what people will use in  
the future. And btw, even more quickly grows the use of VCard like  
mechanisms (electronic business cards) which imply the end user have  
absolutely no idea what identifier is used to set up the call. The  
application select the fragment of the VCard that it can understand,  
and routing mechanisms (on application layer) must be smart enough to  
ensure the call setup actually works.

Because of this, of course E.164 based mechanisms MUST work also on  
the Internet, but it MUST at the same time be remembered that it is an  
old technology that will not grow anymore. Because of this I urge  
people to NOT base any service/application solutions on the function,  
working and deployment of E.164 numbers.

Please use Domain Name based addressing instead.

     Patrik

---

From: Jonathan Rosenberg <[email-masked]>
Date: Wed, 20 Feb 2008 09:25:30 -0500

> Perhaps we also need to do even more to promote email-style SIP URIs,

well, having tried to do that for something like ten years now, and 
having STILL seen the industry primarily doing pstn replacement which 
requires phone numbers, I am somewhat skeptical that there is anything 
IETF can do here.

> security is not achievable) and the SIP URI can be used in other cases.

Now that is a topic worth discussing.

 From can only have a single URI. Interestingly PAI does allow more; you 
can assert both a tel and a SIP URI. What would be really nice is to be 
able to assert both the phone number and the username in the From and 
have the domain covered by the 4474 signature. As my draft points out, 
there is some small value in the 4474 signature there.

One way to do this for example would be something horrible like this:

From: sip:[email-masked];user=composite

where "composite" means that the user part is a series of names within 
the domain, each one separated by "*".

Unfortunately that would work much better in theory than in practice 
since I think most implementations ignore the user attribute of the URI 
and would not know that they shouldn't render this weird looking user part.

Probably the better solution is some hybrid where PAI is used for the 
phone numbers and 4474 for the user@domain identifier. Thats another 
thing useful we could do, is to try and clarify how PAI and 4474 work in 
concert. Right now that is clear as mud.

-Jonathan R.

---

From: Michael Thomas <[email-masked]>
Date: Wed, 20 Feb 2008 07:18:22 -0800

> delivered so well with phone numbers.

I'd say that the sooner that we stop worrying about what happens
when the signaling and media streams cease to be transported by
IP, the sooner our sanity will seek us out again.  Or even less than
that. We can't possibly even enumerate all of the potential hazards
even within the IP realm like, oh say, media->email/MIME
attachments re-posted to Usenet.

       Mike

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 20 Feb 2008 10:18:24 -0500

It seems that we have two parallel worlds: one using email-style 
addresses and another using phone numbers. While there are some devices 
that can play in both worlds, the majority of devices can only play in 
one of the worlds, or at least are strongly biased towards one so that 
usability with the other form is compromised.

It seems essential that sip find a way to be successful in the phone 
number world - at least to the extent that a sip device in not perceived 
as being functionally worse than a comparable device using PSTN 
protocols. No amount of arguing that things would be better if you just 
used an email-style address will win the day there.

The alternative is to accept that sip is worse than native PSTN 
equipment for phone numbers, and hope that the parallel communications 
world based on email-style addresses will eventually win out. But that 
is like waiting for IPv4 to be replaced by IPv6.

	Paul

---

From: "Francois Audet" <[email-masked]>
Date: Wed, 20 Feb 2008 10:05:43 -0600

Sounds reasonable to me. 

> From: Jonathan Rosenberg [mailto:[email-masked]] 
> Sent: Tuesday, February 19, 2008 18:44
> To: Paul Kyzivat
> Cc: Audet, Francois (SC100:3055); IETF SIP List
> Actually what I am hoping to do is to just clearly document 
> the applicability of RFC4474 to numbers and be much crisper 
> with guidance on when to use it, when to not, what it buys 
> you with numbers (since it does help a little even then - 
> receivers can know the domain that asserts that number and 
> use blacklists/whitelists to judge trustability).
> 
> I also want to make sure we are not basing SRTP security on 
> integrity properties delivered with RFC4474, when said 
> properties aren't really delivered so well with phone numbers.
> 
> -Jonathan R.
> 
> Paul Kyzivat wrote:
> > 
> > 
> > Francois Audet wrote:
> > OK. THen we aren't far apart. I agree we want and have something 
> > better for email-style addresses where the domain is 
> significant. It 
> > is the "phone number" addresses I am concerned with here. I 
> think we 
> > must have parity, and ideally better when the PSTN isn't involved.
> > 
> >     Paul
> >

---

From: "Dan Wing" <[email-masked]>
Date: Wed, 20 Feb 2008 10:05:13 -0800

> media. This seems to be of value in some situations.

If the intermediary created the RFC4474 signature itself -- which
is necessary if the intermediary changed the SDP -- the intermediary
could have also changed the a=fingerprint.  Changing the a=fingerprint
allows the intermediary to perform the DTLS-SRTP handshake itself and
thus decrypt the SRTP packets to/from both callers.

draft-kaplan-sip-uris-change-00.txt describes reasons why an 
intermediary might want or need to change the SDP and the From URI.

Most intermediaries are service providers.  Most service providers
operate SBCs.  All SBCs change the SDP (otherwise, they would merely
be B2BUAs).

-d

---

From: "Francois Audet" <[email-masked]>
Date: Wed, 20 Feb 2008 15:28:28 -0600

I think it's time for a reality check...

In the PSTN, if you are an enterprise and have a trunk to a service provider,
you can pretty much put whatever you want in the Calling Party Number (you
can't do that from home with an individual line as the CO puts the Calling
Party Number for you). The network will pass it for you to the other end.

So, not only is the identity in PSTN "hop-by-hop" and not end-to-end, anybody 
with suitable trunk interface can spoof anybody else.

So again, I don't see why WE need to worry about phone number identity.

I agree with Jonathan that we should just document the limitations.

And personally, I don't mind if we restrict the usefulness end-to-end
identity (4474) to addresses where the domain name actually matters and is
not ignored (as is the case with user=phone type numbers).

> Behalf Of Paul Kyzivat
> Sent: Wednesday, February 20, 2008 07:18
> To: Elwell, John
> Cc: IETF SIP List; Henry Sinnreich; [email-masked]; Richard Shockey
> It seems that we have two parallel worlds: one using 
> email-style addresses and another using phone numbers. While 
> there are some devices that can play in both worlds, the 
> majority of devices can only play in one of the worlds, or at 
> least are strongly biased towards one so that usability with 
> the other form is compromised.
> 
> It seems essential that sip find a way to be successful in 
> the phone number world - at least to the extent that a sip 
> device in not perceived as being functionally worse than a 
> comparable device using PSTN protocols. No amount of arguing 
> that things would be better if you just used an email-style 
> address will win the day there.
> 
> The alternative is to accept that sip is worse than native 
> PSTN equipment for phone numbers, and hope that the parallel 
> communications world based on email-style addresses will 
> eventually win out. But that is like waiting for IPv4 to be 
> replaced by IPv6.
> 
> 	Paul
> 
> Elwell, John wrote:
> > Hannes,
> > 
> > achieve end-to-end security when interworking with PSTN. 
> The best we 
> > can do is achieve security across the local SIP part as far as the 
> > PSTN gateway. There are different opinions as to whether the PSTN 
> > itself is secure - I won't express an opinion on that 
> aspect. However, 
> > what happens beyond the PSTN? Another SIP hop? An H.323 
> hop? There is 
> > no way of knowing whether that is secured or not. Some guarantee of 
> > security as far as the gateway is the best we can achieve, and, 
> > importantly, the user should be made aware of this - do not 
> raise his 
> > expectations concerning the end-to-end security of the call.
> > 
> > Let's concentrate on the end-to-end SIP case and provide a good 
> > security solution for that. One possibility might be to use 
> > email-style URIs for that.
> > 
> > John
> > 
> >> Don't get hung-up in the details of a specific strawman proposal 
> >> that, I believe, shows quite well some of the challenges 
> around the 
> >> aspect of
> >> E.164 number ownership.
> >>
> >> Ciao
> >> Hannes
> >>
> >>
> >> Henry Sinnreich wrote:
> >>> done these days. The complications arise with the ITU 
> member states, 
> >>> who jealously guard their diplomatic and political prerogatives.
> >>>
> >>>>  > If there is going to be a solution to the SIP 
> identity problem  
> >>>> involving  > e164 numbers, it will not IMHO be solved in 
> the IETF.
> >>>>  >
> >>>>  >

---

From: Hadriel Kaplan <[email-masked]>
Date: Wed, 20 Feb 2008 16:39:44 -0500

As far as I know, both true E.164 and those that "look like" E.164 are being changed, as well as NANP/local-exchange format, emergency code, and some cellular-specific number formats, etc.  To be honest I really believe a lot of these truly are E.164 or non-local-scope numbers in nature/meaning, and just aren't using the exact format one would want.  In other words it's as Paul says "do what I mean, not what I say".

Really some of the rules are pretty simplistic, including even just change it regardless of username format.  But I would consider those just bad and need to be corrected, and will if email-style URI's start showing up.

Really though I don't think there's much/any email-style URIs crossing provider borders. (inside Enterprises or within a provider may be, but that doesn't need rfc4474)  Or maybe it's just my particular customers, or my kind of customers.  I dunno.  I find everyone on the IETF list has a different view of SIP, because they represent different users/markets.

-hadriel

> From: Elwell, John [mailto:[email-masked]]
> Sent: Wednesday, February 20, 2008 6:39 AM
> To: Hadriel Kaplan; IETF SIP List
> Subject: RE: [Sip] New I-D on why From/To-URIs are changed at provider
> borders
>
> Hadriel,
>

---

From: "Elwell, John" <[email-masked]>
Date: Wed, 20 Feb 2008 21:45:14 +0000

Paul,

That is not quite what I meant. I meant that for PSTN interworking there
is no point in trying to do anything more secure on the SIP hop than the
security provided by the PSTN hop and anything beyond the PSTN. Security
is only as good as the weakest link. So let's try to be as good, but not
better. In the SIP world we can try to be better.

Most devices today either don't support SRTP or support it using
Sdescriptions. As devices evolve to support DTLS-SRTP, they too must
evolve to exploit email-style URIs, because little benefit seems to be
achieved by using of DTLS-SRTP with E.164 numbers, especially if devices
display the number part and don't display, or don't give prominence to,
the domain part.

John

> Sent: 20 February 2008 15:18
> To: Elwell, John
> Cc: [email-masked]; Henry Sinnreich; IETF SIP 
> List; [email-masked]; Richard Shockey
> The best we can

---

From: "Elwell, John" <[email-masked]>
Date: Wed, 20 Feb 2008 21:56:08 +0000

Dan,

Well, yes, if the intermediary changes the From URI and resigns, at
least you know that you have security only as far as that intermediary.
If the originating URI is carried elsewhere in the header,
intermediaries might be less likely to change it, but if they do the
same consideration applies. Unfortunately, as noted on another thread,
there is the difficulty of bringing this fact (that security is only as
far as the intermediary) to the attention of the user.

John 

> Sent: 20 February 2008 18:05
> To: Elwell, John; 'Jonathan Rosenberg'; 'IETF SIP List'

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 20 Feb 2008 17:00:53 -0500

> Party Number for you). The network will pass it for you to the other end.

Why hasn't somebody sued a SP for providing false identity???

The SP *should* be restricting what the enterprise can put based on the 
numbers that the SP knows belong to the enterprise. (The SP doesn't need 
to care if the number is the precise one originating this call.)

But I knew this. In principle the reliability of the pstn callerid is 
nonexistent. But because it is somewhat difficult for most users to 
spoof, *on average* callerid is reasonably reliable. Enough so that many 
can/do make use of it.

(Admittedly the ease of spoofing is increasing, and so the average 
reliablility of callerid is probably going down.)

> I agree with Jonathan that we should just document the limitations.

The problem is that with sip phones if there is no form of authenticated 
identity in use, the ease of spoofing is much easier. So if we use 
nothing on sip phones then end user perceived reliability of callerid 
will be degraded. So the question is: how can we get the *perceived* 
reliability of callerid with sip and phone numbers up to the perceived 
level of the pstn?

Perhaps the solution *is* to wait for the perceived reliability on the 
pstn to go down. (When people stop believing callerid altogether they 
will be ready to by sip phone service.)

> not ignored (as is the case with user=phone type numbers).

I certainly don't mind if we have separate mechanisms for email-style 
addresses and phone number addresses, or that the guarantee is better 
for the email-style.

	Paul

---

From: Michael Thomas <[email-masked]>
Date: Wed, 20 Feb 2008 14:01:57 -0800

> better. In the SIP world we can try to be better.

Hold on a second. Doesn't SIP have the concept of redirection? That is,
even if I use a tel: URL I might get redirected to another device which
doesn't ever touch the PSTN?

It sure seems to me that the prudent thing to do is *always* use the
best security you can instead of trying to divine whether it's going
to end up being on a less secure path.

       Mike

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 20 Feb 2008 17:04:22 -0500

> Really though I don't think there's much/any email-style URIs crossing provider borders. (inside Enterprises or within a provider may be, but that doesn't need rfc4474)  Or maybe it's just my parti…

I expect you might get a different story from Microsoft. (But then they 
probably aren't a customer of yours.)

That is what I meant about it being two different worlds. Each world has 
its own set of SPs. And they aren't very good at peering with one another.

	Paul

---

From: "Dan Wing" <[email-masked]>
Date: Wed, 20 Feb 2008 14:07:20 -0800

Agreed.

-d

> Sent: Wednesday, February 20, 2008 1:56 PM
> To: Dan Wing; Jonathan Rosenberg; IETF SIP List

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 20 Feb 2008 17:11:58 -0500

I agree with Mike here.

People are clearly tolerating a less than ideal situation in the pstn. 
Many know that the mechanisms for securing the callerid (and the media) 
are not 100%, but they think they are also more than 0% and are willing 
to tolerate the level they get.

We ought to be pulling the percentages up, rather than down. E.g. being 
able to assert that the information is accurate back to the nearest PSTN 
gw is better than not.

	Paul

---

From: Dean Willis <[email-masked]>
Date: Wed, 20 Feb 2008 16:16:30 -0600

> reliablility of callerid is probably going down.)

It's also because the telephony service provider has additional  
logging records that can be used to back-trace the call if it turns  
out to have been fraudulently identified.

Try this experiment: Take your home ISDN BRI line. Add your own  
terminal adapter with POTS interface (if you don't have one, I'll be  
happy to sell you one of mine -- I have several that need to be  
eBayed). Dummy up your CPID field to whatever you want (this works, at  
least here on Verizon lines). Now place a crank call to somebody very  
important, and see how long it takes for the authorities to show  
up . . .

---

From: "Francois Audet" <[email-masked]>
Date: Wed, 20 Feb 2008 16:23:02 -0600

Now, repeat this experience at work.

Big difference. 

> Sent: Wednesday, February 20, 2008 14:17
> To: Paul Kyzivat
> Cc: Audet, Francois (SC100:3055); IETF SIP List; 
> [email-masked]; Henry Sinnreich; Elwell, John; Richard Shockey
> >> In the PSTN, if you are an enterprise and have a trunk to 
> a service 
> >> provider, you can pretty much put whatever you want in the Calling 
> >> Party Number (you can't do that from home with an 
> individual line as 
> >> the CO puts the Calling Party Number for you). The network 
> will pass 
> >> it for you to the other end.
> >
> > The SP *should* be restricting what the enterprise can put based on 
> > the numbers that the SP knows belong to the enterprise. (The SP 
> > doesn't need to care if the number is the precise one 
> originating this 
> > call.)
> >
> > spoof, *on average* callerid is reasonably reliable. Enough so that 
> > many can/do make use of it.
> >
> It's also because the telephony service provider has 
> additional logging records that can be used to back-trace the 
> call if it turns out to have been fraudulently identified.
> 
> Try this experiment: Take your home ISDN BRI line. Add your 
> own terminal adapter with POTS interface (if you don't have 
> one, I'll be happy to sell you one of mine -- I have several 
> that need to be eBayed). Dummy up your CPID field to whatever 
> you want (this works, at least here on Verizon lines). Now 
> place a crank call to somebody very important, and see how 
> long it takes for the authorities to show up . . .
> 
> --
> Dean
>

---

From: Dean Willis <[email-masked]>
Date: Wed, 20 Feb 2008 16:33:15 -0600

> to end up being on a less secure path.

Security can be reduced by such a sequence, but it can never be  
increased beyond that of the weakest link.

So if a call is coming from the PSTN, the trust anchor is the identity  
assertion of the PSTN, which is weak.  Putting really cleaver crypto  
on it makes it no stronger. However, it can mask the weakness of an  
assertion by making it look stronger, which could be its own sort of  
bad thing.

To paraphrase Postel's maxim:

Be appropriately secure in what you send, and suspicious of what you  
receive.

Good advice also comes from Shakepeare, who gave us the wise words of  
Polonious  to Hamlet that might be phrased applicably as:

Neither gild nor dross a message's integrity;
For  faux increase doth thy recipients faith offend;
And false discard dulls the edge of security.

--
Dean

---

From: Michael Thomas <[email-masked]>
Date: Wed, 20 Feb 2008 14:44:51 -0800

> increased beyond that of the weakest link.

I'm sorry, but I don't get this. If I send to a tel: URL in the clear 
because
I think it's going to hit an "insecure" link, I'm better off even if it 
turns
out that the tel: URL never made it to the PSTN? How does that make
any sense?

In fact, I'd expect that as VoIP becomes more prevalent, this sort of
situation will become more and more common since e.164 will be
more and more vestigial. This idea of trying to divine what happens
outside of the scope of SIP to affect SIP signaling is the path to
insanity.

But let's put it another way: who on earth would want to maintain
the crufty hacks and pretzel logic to implement this in 5 years time?

         Mike

---

From: [email-masked]
Date: Wed, 20 Feb 2008 21:26:35 -0500

I agree with you strongly.  If one wants to specify an E.164 number,
one should use a tel: URI (with the right qualifiers).  In a Sip: URI,
one can only map an E.164-like user-part into an E.164 number if one
knows that the policy of the specified domain is to do so.

It does sound like many systems make broader assumptions.

We may want to introduce the concept of using tel: URIs in SIP
systems, by which the UA delegates the proxy to choose the "best way"
to get to the specified E.164 destination.

Dale

---

From: Dean Willis <[email-masked]>
Date: Wed, 20 Feb 2008 21:47:54 -0600

> out that the tel: URL never made it to the PSTN? How does that make

It makes perfect sense to strongly assert an identity than one has  
high confidence in, and if we're lucky enough to have an end-to-end  
path that preserves the integrity of the assertion, then we're good.  
What happens if we aren't so lucky?

I'm more concerned about the "other direction" -- that is, an identity  
assertion that came from the PSTN is never going to be stronger than  
the PSTN, no matter how we package it. And by packaging it wrongly, we  
can give a false impression as to its validity.

A link that transitions "downward" on the axes of integrity protection  
doesn't need to inform the next hop of this downgrade; the next hop  
can assume that the integrity protection is no stronger than that  
provided by the immediately preceding link. It's when links try to  
upgrade the protections that errors are introduced.

It is entirely possible that our "security" mechanisms might be  
deployed in such a way that the eventual recipient is blinded to the  
weakness of such an assertion and therefore makes a mistake in  
trusting it. If the cryptographic envelope is "upgraded", we need some  
way to preserve the provenance of the assertion in order to keep this  
form happening.

The simplest approach is to always  consider a "tel:" assertion to be  
at the PSTN level of strength, even if it came from an IP source.

This would imply "use domain-level source addressing when you can; if  
coming from PSTN, use telephone addressing, and never convert back".

--
Dean

---

From: Hadriel Kaplan <[email-masked]>
Date: Wed, 20 Feb 2008 23:17:37 -0500

I think it depends on what you think the future looks like.

Yes a PBX PRI can spoof a CLID, though I would argue it's much harder to fake an ANI (because of who sets it).  But anyway, I think such a thing is more limited in scope on the PSTN simply because there is less benefit to doing it.  If you do it from a PRI, there is a physical link and switch records can be used to track back, and so your gain is limited - unless it's targeted at specific individuals (which makes that very insidious).  Add to that that it still costs money to make the calls usually, and the benefit goes down further.

But if you think in the future (a) call cost approaches zero or becomes bulk in nature, at least for voip-voip calls, and (b) voip peering grows and/or open providers are included, then the benefit of CLID spoofing grows to potentially make SPIT profitable or Phishing attacks untraceable.  It's not a near-term problem, and may never be a problem.  It's just that email has such a problem and so there's concern that SIP could too someday.

-hadriel

> Sent: Wednesday, February 20, 2008 4:28 PM
> To: Paul Kyzivat; Elwell, John

---

From: Hadriel Kaplan <[email-masked]>
Date: Thu, 21 Feb 2008 00:24:43 -0500

But since there's no way to stop the signer from simply converting to a sip-URI, or decide/not to sign things, what you're saying is the verifier/UAS  must not believe the ID of any signed request if the From is an E.164, regardless of sip|sips|tel, right?  And since the signer could just remove the user=phone param before signing, you're saying the UAS can't believe it if the username even looks like an E.164?

-hadriel

> From: [email-masked] [mailto:[email-masked]] On Behalf Of Dean
> Willis
> Sent: Wednesday, February 20, 2008 10:48 PM
> To: Michael Thomas
> Cc: IETF SIP List; Paul Kyzivat; Richard Shockey; Henry Sinnreich; Elwell,
> John; [email-masked]

---

From: "Elwell, John" <[email-masked]>
Date: Thu, 21 Feb 2008 07:46:36 +0000

Paul,

> to care if the number is the precise one originating this call.)
[JRE] The problem is a call that comes from a different part of a large
enterprise, with a number that is not within the range of numbers
reachable from that particular SP. Or a call that comes from outside the
enterprise and then is forwarded to the PSTN (say to the enterprise
user's home or mobile phone). This "unscreened" number can
advantageously be passed to the callee.

John

---

From: "Elwell, John" <[email-masked]>
Date: Thu, 21 Feb 2008 07:48:45 +0000

> From: Michael Thomas [mailto:[email-masked]] 
> Sent: 20 February 2008 22:02
> To: Elwell, John
> Cc: Paul Kyzivat; IETF SIP List; Henry Sinnreich; 
> [email-masked]; Richard Shockey
[JRE] I agree, but when a PSTN gateway is encountered we may have to
downgrade to the level of security appropriate to a mixed SIP-PSTN call.

John

---

From: "Elwell, John" <[email-masked]>
Date: Thu, 21 Feb 2008 08:38:55 +0000

> Sent: 20 February 2008 22:12
> To: Michael Thomas
> Cc: Elwell, John; IETF SIP List; Henry Sinnreich; 
[JRE] Agreed. But this is still a downgraded security, because the fact
that I have a secure connection to a PSTN gateway doesn't tell me
anything about the end-to-end security.

John

---

From: "DRAGE, Keith \(Keith\)" <[email-masked]>
Date: Thu, 21 Feb 2008 12:54:39 +0100

Just to put some background to what is happening here with caller id in
the PSTN.

If the calling terminal provides a caller id, then the public network
has two options:

-	it screens it (is this line entitled to use this number) and
puts it in the ISUP calling party number field
-	it does not screen it and puts it in the generic number
parameter. The calling party number has some sort of default number for
the access.

Which of these it does depends on a special arrangement. US providers
appear to give that special arrangement to everyone. European operators
will either give that special arrangement only to PBX customers (i.e.
they trust the PBX operator to configure the equipment to deliver
numbers to some level of trust), or they do not provide it at all (no
trust). The reason for this is based on history.

At the terminating side calling line identity is provided using the
content on the generic number if present, and then on the calling party
number (in ISDN both are delivered by the second may well be discarded).

Malicious call identification (the network recording call details) is
based primarily on the contents of the calling party number, and only
optionally records other identities. Therefore if the police do bother
to turn up, they will turn up to the address associated with the default
number for that line if the special arrangement exists.

And none of this is capable of being mimicked completely by RFC 3325 or
RFC 4474 so that provides yet another set of rules.

Regards

Keith

> Sent: Wednesday, February 20, 2008 10:17 PM
> To: Paul Kyzivat
> Cc: IETF SIP List; Francois Audet; Richard Shockey; Henry 
> Sinnreich; Elwell,John; [email-masked]

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 21 Feb 2008 10:00:26 -0500

Elwell, John wrote:
> reachable from that particular SP.

You are saying that the enterprise has numbers assigned/managed by 
multiple SPs, and the call is entering the PSTN from the enterprise via 
a GW attached to SP1 while the asserted number is managed by SP2?

In that case the enterprise in effect acting as a transit network. 
Either the SP must really *trust* the enterprise, or else it should have 
a list of all the numbers assigned to the enterprise, or else it should 
treat this as invalid or block the identity. The enterprise can solve 
this by entering the PSTN through the SP that can verify the ID.

> Or a call that comes from outside the

Only an issue if the call is hairpinned through the enterprise.

If it is, then again it is acting as a transit network, and trust is 
required.

Of course trust is a dangerous thing, especially in the last case. How 
did the enterprise verify this identity before reasserting it?

But I see your point. The SPs may have caved to demands from their 
customers to trade off accuracy vs functionality.

	Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 21 Feb 2008 10:02:55 -0500

John,

I agree. Taking the number learned from the PSTN and asserting it with 
something akin to sip identity would be asserting more than is known.

It seems that some weaker form of assertion is needed. (PSTN-grade 
security.)

	Paul

---

From: Michael Thomas <[email-masked]>
Date: Thu, 21 Feb 2008 08:34:55 -0800

> anything about the end-to-end security.

I think it might be worthwhile to keep in mind that there's more to
overall security than absolute guarantees that can be made to
individuals. Security is also about populations, and overall risk
management. Mainly what we're trying to do is get the bad guys
to find somebody else to annoy rather than hoping you can survive a
full frontal attack. Defending the SIP side of the house regardless of
any weaker links is just inviting the bad guys to go find something else
to do with their time which most likely has nothing to do with telephony
at all since the pstn side of this is already pretty well understood.

       Mike

---

From: Dean Willis <[email-masked]>
Date: Thu, 21 Feb 2008 10:42:37 -0600

On Feb 20, 2008, at 11:24 PM, Hadriel Kaplan wrote:

>
> But since there's no way to stop the signer from simply converting  
> to a sip-URI, or decide/not to sign things, what you're saying is  
> the verifier/UAS  must not believe the ID of any signed request if  
> the From is an E.164, regardless of sip|sips|tel, right?  And since  
> the signer could just remove the user=phone param before signing,  
> you're saying the UAS can't believe it if the username even looks  
> like an E.164?
>

That would be one way to handle it "by convention". There may be  
better solutions.

---

From: Michael Thomas <[email-masked]>
Date: Thu, 21 Feb 2008 08:59:56 -0800

> It seems that some weaker form of assertion is needed. (PSTN-grade 

With email and DKIM, there are really two kinds of assertions that can be
made:

1) this message came from me
2) this message passed through me

I actively don't want to sign messages that purport to come from me from
sources I don't trust (like, say, the internet). The second is more of a 
statement
of fact, essentially being a digitally signed received: (via) header.

I think that both are interesting assertions for filters, and it seems 
to me that
the same situation exists with SIP. For example, I may want to whitelist
anything coming through ietf.org even though I can't _really_ count on
the validity of the From: address. That's because experience tells me that
the likelihood of ietf.org being an attack vector is extremely low.

       Mike, hoping to get ietf.org dkim signing soon
>>> From: Paul Kyzivat [mailto:[email-masked]] Sent: 20 February 
>>> 2008 22:12
>>> To: Michael Thomas
>>> Cc: Elwell, John; IETF SIP List; Henry Sinnreich; [email-masked]; 
>>> Richard Shockey
>>> People are clearly tolerating a less than ideal situation in the 
>>> pstn. Many know that the mechanisms for securing the callerid (and 
>>> the media) are not 100%, but they think they are also more than 0% 
>>> and are willing to tolerate the level they get.
>>>
>>> We ought to be pulling the percentages up, rather than down. E.g. 
>>> being able to assert that the information is accurate back to the 
>>> nearest PSTN gw is better than not.

---

From: "Francois Audet" <[email-masked]>
Date: Thu, 21 Feb 2008 11:00:10 -0600

Exactly.

For example, me sitting in California can make a SIP call to somebody in Texas.
Internally, it will be routed through our internal network until it reaches
a PSTN gateway in Texas (least-cost routing). That gateway will insert my california
CLID in the ISDN message.

And yes, this is totally prone to abuse. But the benefits have been judged
by the industry to outweight the cost.

So, trying to fix the "phone number" assertion problem seems (a) out of scope
of what IETF's mandate is and (b) unlikely to be solveable.

That is why my thinking is that we should focus on things were we can actually
make a difference. "Email-looking addresses" or "Addresses where the domain
matters" fall in that category.

Putting a warning that if the system routes on the "user part" instead of the
"domain" (like is often the case with phone numbers), it breaks domain-based
identity assertion is a good start. 

> Sent: Wednesday, February 20, 2008 23:47
> To: Paul Kyzivat; Audet, Francois (SC100:3055)
> [JRE] The problem is a call that comes from a different part 
> of a large enterprise, with a number that is not within the 
> range of numbers reachable from that particular SP. Or a call 
> that comes from outside the enterprise and then is forwarded 
> to the PSTN (say to the enterprise user's home or mobile 
> phone). This "unscreened" number can advantageously be passed 
> to the callee.
> 
> John
>

---

From: Jonathan Rosenberg <[email-masked]>
Date: Mon, 25 Feb 2008 21:16:38 -0500

Thanks for putting this together.

I'll add another to your list. This is more of an enterprise thing, but 
oftentimes the From URI is changed because the caller identity needs to 
be set to the attendant number before going to another domain. For 
example, if anyone within example.com makes a call, and that call 
remains within example.com, the caller ID is unchanged. But if the 
request exits the domain, the display name is often changed (Example 
Org.) and the number is changed to the direct number for example.com. I 
personally think this practice is an artifact of days long gone but it 
remains common.

-Jonathan R.

---

From: Hadriel Kaplan <[email-masked]>
Date: Mon, 25 Feb 2008 22:00:14 -0500

Yeah good point - it is what I would include under number translation I guess.  Providers do it too in a way, when they remove internal routing prefix codes or "*" codes, fwiw.

-hadriel

> Sent: Monday, February 25, 2008 9:17 PM
> To: Hadriel Kaplan
> Cc: IETF SIP List
> Subject: Re: [Sip] New I-D on why From/To-URIs are changed at provider
> borders
>
> > As part of an off-line discussion regarding Kai Fischer's draft on e2e-
> security-media and whether his From-URI copying tactic would succeed or
> not at a policy level, if rfc4474 fails to do so, I gave my 2 cents on
> what some providers had been telling me.  Dan asked me to write up a draft
> on it, in case people are interested.  This is the draft: