Subject: RE: [Enum] E.164 communication assumptions/requirements

From: Ray Anderson <[email-masked]>
Date: Mon, 18 Jul 2005 16:36:46 -0400

At 13:45 18/07/2005, Pfautz, Penn L, NEO wrote:
Ray:
We could argue about whether these are ENUM requirements.  And use
of numbers within assigned E.164 country codes is largely a national
matter. But at least within the United States the reachability assumption
is likely to hold and use of NANP numbers for purposes such as you
describe (pure DNS indexes) are likely to be discouraged by regulators.

Penn
Pfautz
I believe that some regulators will allow "free issue" of large
blocks of ENUM "space" for non voice purposes
I also think that the ability to "change" your ENUM DNS records
is a good clue that you "own" that number, so
it is possible to use ENUM as a way of cost effectively verifying who
"owns" an E.164 number

_______________________________________________
enum mailing list
enum at ietf.org
https://www1.ietf.org/mailman/listinfo/enum

---

From: Thomas Jauch <[email-masked]>
Date: Mon, 18 Jul 2005 17:07:57 -0400

Ray,

Are you speaking about Public ENUM or Carrier ENUM? Don't forget the
User Opt-In requirenment in Public ENUM! And how would you "verifying
who "owns" an E.164 number" without a WHOIS database in place? WHOIS
would be even a bigger nightmare, from a privacy point of view, than
publishing name based URIs in connection with a phone number...

Regards,

Tom

On 7/18/05, Ray Anderson <ray at bango.net> wrote:
>  We could argue about whether these are ENUM requirements.  And use of
> numbers within assigned E.164 country codes is largely a national matter.
> But at least within the United States the reachability assumption is likely
> to hold and use of NANP numbers for purposes such as you describe (pure DNS
> indexes) are likely to be discouraged by regulators. 
>   
>  Penn Pfautz
>  I believe that some regulators will allow "free issue" of large blocks of
> ENUM "space" for non voice purposes
> 
>  I also think that the ability to "change" your ENUM DNS records is a good
> clue that you "own" that number, so

---

From: Jim Reid <[email-masked]>
Date: Mon, 18 Jul 2005 19:50:58 -0400

On Jul 18, 2005, at 22:06, Thomas Jauch wrote:
And how would you "verifying
who "owns" an E.164 number" without a WHOIS database in place?
whois is completely orthogonal to the DNS or ENUM. Please don't 
cross-contaminate these things. ENUM and the DNS work perfectly well 
without any whois service whatsoever. ENUM and the DNS do not depend on 
whois. And vice versa.

In the context of ENUM, whois is essentially pointless. The whole 
concept of whois was to provide contact data for the owner of some 
domain. In the early days of the internet, this was used so you could 
*phone* someone to tell them their DNS servers were broken => they 
couldn't receive email. With all the spamming that goes on these days, 
people try to obfuscate any whois data and registries are in an arms 
race with spammers to keep them away from their whois databases. So at 
best, whois is debatable for regular domain names. For ENUM, it's 
pointless because the contact data is already known: the phone number. 
So why look for that in some whois server? The best you could hope for 
from an ENUM whois server is some other possibly valid contact data for 
a broken domain.

As for verification and authentication of ENUM entries, whois data 
proves nothing. Unless of course it was authenticated and validated at 
the point where it was entered into that database. So we're back to 
where we started. And of course since whois and DNS are not necessarily 
tightly coupled, there's no guarantee that any data that's in the DNS 
for some zone is consistent with what's in the whois database for that 
zone.

WHOIS would be even a bigger nightmare, from a privacy point of view, 
than
publishing name based URIs in connection with a phone number...
Indeed. This is one of the reasons why ENUM in the UK does not (and 
probably never will have) a whois service. Or CRISP if that ever 
supplants whois.

---

From: Michael Haberler <[email-masked]>
Date: Mon, 18 Jul 2005 20:41:31 -0400

At 22:35 18.07.2005, Ray Anderson wrote:
At 13:45 18/07/2005, Pfautz, Penn L, NEO wrote:
Ray:
We could argue about whether these are ENUM requirements.  And use of 
numbers within assigned E.164 country codes is largely a national matter. 
But at least within the United States the reachability assumption is 
likely to hold and use of NANP numbers for purposes such as you describe 
(pure DNS indexes) are likely to be discouraged by regulators.

Penn Pfautz
I believe that some regulators will allow "free issue" of large blocks of 
ENUM "space" for non voice purposes
I havent heard of regulators doing that, it might be more the other way 
around - a number range allocated but nobody routes it in the PSTN.

That, by the way, is the case since a long time - have a look at the bottom 
of  http://www.itu.int/itudoc/itu-t/ob-lists/icc/e164_763.pdf - the ITU has 
allocated whole 'country codes' (actually private network codes) for, 
amongst others, ATM virtual circuit addressing. No, you cant call these 
numbers on the PSTN, but yes, they are E.164 numbers.

The  'E.164 number has to be "reachable"'' assumption is an extrapolation 
of experience with the subset of E.164 that is used for PSTN voice.

-Michael

---

From: Ray Anderson <[email-masked]>
Date: Tue, 19 Jul 2005 05:02:26 -0400

At 22:06 18/07/2005, Thomas Jauch wrote:
Ray,
Are you speaking about Public ENUM or Carrier ENUM? Don't forget the
User Opt-In requirenment in Public ENUM! And how would you "verifying
who "owns" an E.164 number" without a WHOIS database in place? WHOIS
would be even a bigger nightmare, from a privacy point of view, than
publishing name based URIs in connection with a phone number...
Regards,
Tom
Our requirement is to be able to determine who "has control" of a "phone 
number".
We plan to use ENUM to help us determine this by asking the user who claims 
to own
a phone number to do something with ENUM that means that somebody who controls
that bit of the E.164 numberspace has given them control over that number.

So, if I claim to own +441223472778 I might be asked to change the email 
address in the
ENUM record to banana at bango.com   If I can do that, it is assumed I am "all 
powerful"
with respect to that number.  The whole ENUM project should be causing 
E.164 owners
to put into place varying levels of verification systems that we can 
piggyback on top of.

---

From: Thomas Jauch <[email-masked]>
Date: Tue, 19 Jul 2005 05:40:17 -0400

> to put into place varying levels of verification systems that we can

If I understand you correctly you would like to use such a method as
described during a sign-up process, to make sure that the person who
signs-up is the owner of the number?

So you assume that every of your future customers would have choosen
already an ENUM registrar, proven his identity, published at least an
some sort of data into ENUM, etc. before he signs-up for your service?

When would you check the change made to the endpoint in the process of
signing-up? What about the TTL? Do you expect that the customer to
wait until the changes are visible to you and you could confirm the
ownership?

If you ask for a change of the email address, would you provide an
email account? What happens with the emails distributed to that
address during the "ownership check"? Does your customer have to log
into this new account and, after he has changed the email address back
to his personal email address, forward all incoming emails to his
personal email address?

Aren't there other ways like sending an SMS message to the handset
including a verification code, which your future customer has to enter
into a form within a given time frame? Do you consider this method as
not secure because a handset could have been stolen?

Tom

---

From: "Peter Williams" <[email-masked]>
Date: Tue, 19 Jul 2005 11:32:06 -0400

> that bit of the E.164 numberspace has given them control over that number.

Its more the other way around: which carrier of record, or which contracted
telco for an individual number assignment, is held responsible for
administering and managing the network when delivering the less well known
AND MANDATORY services for a PSTN-connected number.

Track-and-trace: relaying data, usually stored vs. real-time, on called and
calling parties, usually to police investigators

Interception: realtime relaying of the bit stream to the monitoring switch
node for that telco

Denial: intercept switching/reachability at the incoming interconnection
point between carriers. (e.g. stop detonation based on cell phone call
trigger)

Let's remember that, in the US, carriers are audited and fined if their
infrastructure and management controls are unable to meet the standards for
delivering the above PSTN-related services. Passing the audit (and avoiding
the sanctions) comes down to deploying business controls that guarantee the
timeliness aspects of the routing/switching database management, from
subscription through provisioning to publication.

For track-and-trace, carriers generally only work with other regulated (i.e.
audited) carriers as their own effectiveness when performing their
obligations generally depends on the quality of the carriers with whom they
have interconnect agreements.

---

From: Richard Shockey <[email-masked]>
Date: Tue, 19 Jul 2005 12:20:18 -0400

At 07:50 PM 7/18/2005, Jim Reid wrote:

In the context of ENUM, whois is essentially pointless.
not really ..
The whole concept of whois was to provide contact data for the owner of 
some domain. In the early days of the internet, this was used so you could 
*phone* someone to tell them their DNS servers were broken => they 
couldn't receive email. With all the spamming that goes on these days, 
people try to obfuscate any whois data and registries are in an arms race 
with spammers to keep them away from their whois databases. So at best, 
whois is debatable for regular domain names. For ENUM, it's pointless 
because the contact data is already known: the phone number. So why look 
for that in some whois server? The best you could hope for from an ENUM 
whois server is some other possibly valid contact data for a broken domain.
There may be all sorts of requirements from regulatory authorities for 
which a ENUM Contact-Database based on ..IRIS perhaps will be useful. In 
fact the US ENUM forum is going to specify the use if IRIS-EREG in its 
architecture. Which is one reason I want to bring the latest version to 
Last Call ASAP.

Richard Shockey, Director - Member of Technical Staff
NeuStar Inc.
46000 Center Oak Plaza  -   Sterling, VA  20166
sip:rshockey(at)iptel.org   sip:57141 at fwd.pulver.com
ENUM +87810-13313-31331
PSTN Office +1 571.434.5651 PSTN Mobile: +1 703.593.2683,  Fax: +1 815.333.1237
<mailto:richard(at)shockey.us> or <mailto:richard.shockey(at)neustar.biz>
<http://www.neustar.biz> ; <http://www.enum.org>
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
_______________________________________________
enum mailing list
enum at ietf.org
https://www1.ietf.org/mailman/listinfo/enum

---

From: Andrew Newton <[email-masked]>
Date: Tue, 19 Jul 2005 14:13:14 -0400

On Jul 19, 2005, at 12:19 PM, Richard Shockey wrote:
Which is one reason I want to bring the latest version to Last Call  
ASAP.
It has been submitted, and I think is ready for wglc.
-andy
_______________________________________________
enum mailing list
enum at ietf.org
https://www1.ietf.org/mailman/listinfo/enum

---

From: Bernie Hoeneisen <[email-masked]>
Date: Wed, 20 Jul 2005 08:09:24 -0400

On Tue, 19 Jul 2005, Richard Shockey wrote:
There may be all sorts of requirements from regulatory authorities for which 
a ENUM Contact-Database based on ..IRIS perhaps will be useful. In fact the 
US ENUM forum is going to specify the use if IRIS-EREG in its architecture. 
Which is one reason I want to bring the latest version to Last Call ASAP.
What kind of requirements have been set by the US authoities?
Is this an IRIS service which can be accessed by everybody,
or can only a restricted user group access such data,
e.g. law enforcement staff?
cheers,
 Bernie
_______________________________________________
enum mailing list
enum at ietf.org
https://www1.ietf.org/mailman/listinfo/enum

---

From: "Peter Williams" <[email-masked]>
Date: Sat, 23 Jul 2005 13:30:56 -0400

It will be intresting to see if this "third party reliance" (aka 
piggybacking) security practice is ever authorized, in reality. The last 3 
INTERNET infrastructures I worked in all denied this obvious practice. Once 
the infastructure player operates a branded (audited) process, the company 
will generally want any other companies who benefit from it to be paying for 
those reliance benefits....and come under the terms and conditions rules, 
etc.

If we look at other examples of switched online identity databases wth 
federated trust models and multi-provider interconnect practices:

(a) VISA will NOT let you use its accurate numbering, subscriber 
identification, privilege assignment, and switched trust system (VisaNet) as 
a way of verifying personal identity. That is, you cannot take a 1c visa 
purchase from a cardholder peter williams, and then claim you verified me as 
peter williams, with a 100k credit worthiness.

(b) VeriSign will NOT let you rely on a SSL merchant cert, and then issue 
you own cert to that website operator - claiming "well VeriSign issued a 
cert, having done due dligence concerning the right-to-use rules (ENUM query 
on a E.164 registry, DNS registration, usb.org registration, IANA/DARPA MIB 
schema organizations...), and therefore "i have verified that "peter.com is 
clearly peter.com" when listing said "verified" name in my own _reissued_ 
(i.e. non-VeriSign) cert.

(c) On the other hand, a variety of the practice is EXACTLY what many value 
added PSP providers do (in unauthorized fashion, generally) -  relying on 
the  email, paging company, or ISP provider's account management controls to 
boot up their own, independent trust model. We all respond to a email ping, 
and authenticate thereby to a new web site account. That is the website app 
relies on a third parties account accuracy representations when verifyng a 
new consumer's identity (i.e. those of the email service provider) when 
superimposing its own account susbcription/provisioning/publication 
processes.

---

From: Ray Anderson <[email-masked]>
Date: Tue, 26 Jul 2005 08:04:58 -0400

And two more examples where piggy-backing is used extensively:
(1) You send a text message, containing a pass-code to a user, and
piggyback on the fact that a Mobile Operator only shows it only to that
subscriber
(2) Mobile network operators do a 1p transaction on a credit card and use
it to validate that an over 18 year old person has therefore authorised
that phone to be used to see "adult only" content.
In a nutshell, we want to only issue a Bango Number (a number from our
proprietary database) to somebody who "owns" the equivalent
phone number.  We can't use text or voice messages, because the
number might not support either.  So, we plan to piggy-back on ENUM
- relying on teh fact that if somebody can "fiddle" with teh
ENUM DNS records, they have a lot of power over that number, so we give
them teh Bango Number.

At 18:30 23/07/2005, Peter Williams wrote:
It will be intresting to see if
this "third party reliance" (aka piggybacking) security
practice is ever authorized, in reality. The last 3 INTERNET
infrastructures I worked in all denied this obvious practice. Once the
infastructure player operates a branded (audited) process, the company
will generally want any other companies who benefit from it to be paying
for those reliance benefits....and come under the terms and conditions
rules, etc.
If we look at other examples of switched online identity databases wth
federated trust models and multi-provider interconnect
practices:
(a) VISA will NOT let you use its accurate numbering, subscriber
identification, privilege assignment, and switched trust system (VisaNet)
as a way of verifying personal identity. That is, you cannot take a 1c
visa purchase from a cardholder peter williams, and then claim you
verified me as peter williams, with a 100k credit worthiness.
(b) VeriSign will NOT let you rely on a SSL merchant cert, and then issue
you own cert to that website operator - claiming "well VeriSign
issued a cert, having done due dligence concerning the right-to-use rules
(ENUM query on a E.164 registry, DNS registration, usb.org registration,
IANA/DARPA MIB schema organizations...), and therefore "i have
verified that "peter.com is clearly peter.com" when listing
said "verified" name in my own _reissued_ (i.e. non-VeriSign)
cert.
(c) On the other hand, a variety of the practice is EXACTLY what many
value added PSP providers do (in unauthorized fashion, generally) - 
relying on the  email, paging company, or ISP provider's account
management controls to boot up their own, independent trust model. We all
respond to a email ping, and authenticate thereby to a new web site
account. That is the website app relies on a third parties account
accuracy representations when verifyng a new consumer's identity (i.e.
those of the email service provider) when superimposing its own account
susbcription/provisioning/publication processes.

So, if I claim to own
+441223472778 I might be asked to change the email address in the
ENUM record to banana at bango.com   If I can do that, it is
assumed I am "all powerful"
with respect to that number.  The whole ENUM project should be
causing E.164 owners
to put into place varying levels of verification systems that we can
piggyback on top of.

Ray Anderson   CEO Bango  
ray at bango.com   
www.bango.com
Mobile: +44 7768 454545  Fax: +44 20 7692 5558  
Come and see Bango at Mobile Entertainment Summit 2005,  Hilton Universal City, Los Angeles, USA   27-28 July www.ihollywoodforum.com