Subject: [stir] Can canonical phone numbers survive SBCs and other middle boxes?

From: "Rosen, Brian" <[email-masked]>
Date: Fri, 7 Jun 2013 17:20:24 +0000

The fundamental idea that we have here is that you sign a set of information with a credential, and you pass the signature and a pointer to the credential in SIP signaling.

We have some disagreements about what is signed.

Henning has proposed that we canonicalize the From and To phone numbers, we include a timestamp and some form of call-id, possibly the INSIPID id.

There are assertions that you can't use From/To, because middle boxes change them.  Some have suggested using P-A-I and other headers instead.

Hadriel wrote a draft about why From and To get modified:
http://tools.ietf.org/id/draft-kaplan-sip-uris-change-00.txt

After reading it, I am unclear if a canonicalized e.164 would make it through.  The reasons given seem to indicate they would.  They change domains, they change prefixes, but they don't seem to change the actual telephone number.

Can we come up with examples where a canonicalized e.164 would NOT pass end to end?

Brian

---

From: Bernard Aboba <[email-masked]>
Date: Fri, 7 Jun 2013 10:57:33 -0700

On Fri, Jun 7, 2013 at 10:20 AM, Rosen, Brian <[email-masked]> wrote:

> There are assertions that you can't use From/To, because middle boxes change
> them.  Some have suggested using P-A-I and other headers instead.
>

[ BA] Some PBXes appear to change the From: and To: headers when
implementing find-me-followme. Of course there are alternatives (e.g.
change only the Request-URI and use History-Info).

---

From: "Rosen, Brian" <[email-masked]>
Date: Fri, 7 Jun 2013 18:08:04 +0000

Yes, I'm asking if we can avoid using alternative headers.

I'll start a thread on call forward/follow-me.

I think presence of most prefixes would be pretty easy to deal with.  I would not expect to see the PBX prefixes (9-1-202-555-1212), because the downstream entities couldn't route if they were there.

Can anyone else on the list find examples where prefixes may confuse a canonicalization routine on From/To?

Brian
On Jun 7, 2013, at 1:58 PM, Hadriel Kaplan <[email-masked]> wrote:

> 
> On Jun 7, 2013, at 1:20 PM, "Rosen, Brian" <[email-masked]> wrote:
> 
> Depends on how you mean this - do you mean can we avoid putting a canonical version into a separate header, and instead keep it in the From/To?
> I don't know that we can really know the answer to that universally.
> 
> There are some times when the From/To username numbers are changed for reasons other than what I had in that old draft.  For example sometimes they're pre-pended with prefixes used for routing purposes, but the prefix is later removed before egressing the network.  That probably wouldn't matter so long as it got inserted after the signer and removed before the verifier, or the signer/verifier were aware of it.  Also the From number is sometimes replaced with a general company number, to hide the specific agent/attendant making a call; but that would hopefully happen before signing so it won't matter.  Sometimes the To is changed due to call forwarding/hunting/selection to be the new destination number, despite the RFCs that say otherwise.
> 
> -hadriel
>

---

From: Dave Crocker <[email-masked]>
Date: Fri, 07 Jun 2013 20:26:49 +0200

On 6/7/2013 7:20 PM, Rosen, Brian wrote:
> The fundamental idea that we have here is that you sign a set of
> information with a credential, and you pass the signature and a pointer
> to the credential in SIP signaling.
...

although you say 'credential' rather than 'signature', that all sounds 
pretty similar to DKIM...

the bit of difference probably hinges on whether the extra functionality 
of a credential is really required, and whether credentials can scale to 
this use.

d/

-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net

---

From: Dave Crocker <[email-masked]>
Date: Fri, 07 Jun 2013 20:29:26 +0200

...

d/

---

From: "Rosen, Brian" <[email-masked]>
Date: Fri, 7 Jun 2013 18:33:03 +0000

The idea is that the credential comes with the number delegation.

When you get a number (or a range of numbers if you are a service provider), you get a credential that authorizes use of that number.

That scales.

What is needed is a way to prove the provenance of the delegation.  The root of trust is the regulator, or a contractor of the regulator, which, in all countries, controls the number space.  There is a delegation path that exists for numbers.  We create a PKI that exactly mirrors that path.

In countries with number portability, there are some complications, but in all cases, there is a clear delegation path for the numbers, and the cert chain follows it.

Brian

On Jun 7, 2013, at 2:26 PM, Dave Crocker <[email-masked]> wrote:

> although you say 'credential' rather than 'signature', that all sounds pretty similar to DKIM...
> 
> the bit of difference probably hinges on whether the extra functionality of a credential is really required, and whether credentials can scale to this use.
> 
> d/
> 
> 
> -- 
> Dave Crocker
> _______________________________________________
> stir mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/stir

---

From: Dave Crocker <[email-masked]>
Date: Fri, 07 Jun 2013 20:36:42 +0200

> In countries with number portability, there are some complications, but in all cases, there is a clear delegation path for the numbers, and the cert chain follows it.

If you certify operators rather than number blocks, then you have a 
weaker model for /detecting/ misuse -- an operator can use a number that 
isn't delegated to them -- but you retain sufficient accountability and 
number portability isn't an issue.

d/

---

From: Dave Crocker <[email-masked]>
Date: Fri, 07 Jun 2013 20:37:05 +0200

d/

---

From: Hadriel Kaplan <[email-masked]>
Date: Fri, 7 Jun 2013 11:36:46 -0700 (PDT)

-hadriel

---

From: Henning Schulzrinne <[email-masked]>
Date: Fri, 7 Jun 2013 14:40:32 -0400

On forwarding, it would seem that, in many cases, the validation is done *before* the forwarding happens. For example, the typical follow-me on a PBX is done by my (trusted) PBX, and it would do the validation on the incoming call. Same for carriers that offer find-me/follow-me as a consumer feature.

---

From: "Rosen, Brian" <[email-masked]>
Date: Fri, 7 Jun 2013 18:43:16 +0000

I would say it's impossible to certify operators.

You could make a case for certifying AT&T.

But how do you decide which other carriers are good guys?

Probably impossible, at least in any reasonable deployment time frame.

Portability is actually fairly simple. You provide a service that validates that a number remains a part of a range and you get a new cert when a number ports.  It's a complication, but the solution is straightforward, scalable, and secure.  There are countries that have a forwarding model for portability where the range holder forwards calls to the current holder.  The cert path follows that path - the original number holder issues a cert to the current holder that it is authorized the use of the number.

Brian

On Jun 7, 2013, at 2:36 PM, Dave Crocker <[email-masked]> wrote:

> If you certify operators rather than number blocks, then you have a weaker model for /detecting/ misuse -- an operator can use a number that isn't delegated to them -- but you retain sufficient accountability and number portability isn't an issue.
> 
> d/
> -- 
> Dave Crocker

---

From: "Rosen, Brian" <[email-masked]>
Date: Fri, 7 Jun 2013 18:53:20 +0000

Sure, but can your forward-to device/service validate the call from your PBX?

It could not if the calling party number was the original party and not the PBX.  The problem is that when the forward-to device gets the call, the called party number is it's own, and the calling party number is the original calling party, not the PBX.  This is a different call, with a different To.  It should have a different From, but they are spoofing the From.  The device/service could not validate that because the actual originator, the PBX, doesn't have the credential for the number in From.

Brian

---

From: Dave Crocker <[email-masked]>
Date: Fri, 07 Jun 2013 20:53:29 +0200

> But how do you decide which other carriers are good guys?

By many measures, no one is a good guy.  But some guys are authorized. 
For example, anyone who is assigned a number block is authorized.

Certs tend to carry an implication of goodness.  My suggestion is more 
modest, to seek accountability through authenticity.

Have such folk register a signing domain in a table of authorized folk. 
  Anything signed has the name queried to that table.  This verifies 
that they are authorized as an operator.

It doesn't certify their goodness or even their authorization for a 
number block, but it means they are on the hook for their bad behavior, 
because you really do know who they are.

d/

---

From: Henning Schulzrinne <[email-masked]>
Date: Fri, 7 Jun 2013 14:54:49 -0400

I agree it's difficult to certify goodness, but traceability and accountability may be a bit easier, as these carriers register via NECA to get an OCN, and this requires significant paper work and $250 application fee. If a carrier with an OCN turns out to be a rogue, it is then relatively easy to blacklist them and I suspect NECA would not take kindly to an attempt to register hundreds of mailboxes.

---

From: Dave Crocker <[email-masked]>
Date: Fri, 07 Jun 2013 20:59:56 +0200

> I agree it's difficult to certify goodness, but traceability and accountability may be a bit easier, as these carriers register via NECA to get an OCN, and this requires significant paper work and…

The subversive design and operations message of the DKIM approach is 
that accountability is more tractable than building in 'reputation' to 
the core of the mechanism.

FWIW, there's been some effort to extract the core DKIM mechanisms out 
from DKIM, to make them easier to provide to other services:

    Doseta (DOmain SEcurity TAgging)

    www.trusteddomain.org/doseta.html

d/

---

From: Hadriel Kaplan <[email-masked]>
Date: Fri, 7 Jun 2013 11:58:48 -0700 (PDT)

> It could not if the calling party number was the original party and not the PBX.  The problem is that when the forward-to device gets the call, the called party number is it's own, and the calling…

Arguably they're not "spoofing" - they're just routing the call, similar to a transit.  Granted it's a new "call" at a SIP protocol level, but at the higher "who's calling me for this call?" level, the PBX should leave the From alone to be the original caller.

-hadriel

---

From: "Rosen, Brian" <[email-masked]>
Date: Fri, 7 Jun 2013 19:01:55 +0000

Okay, but what is "rogue"?

Suppose they do as Hadriel suggests, and accept a PRI without checking calling party number to see it's one of theirs.  Is that "rogue"?
As you say, some of these calls skate a line on whether they are legal or not.  But even if they are legal, then the caller still could have a reasonable expectation of the ID being accurate.

If you keep to the notion that we're not trying to designate good guys but instead trying to determine if the calling party number is accurate, then using the cert-follows-number-delegation makes things uniformly straightforward.

Brian

---

From: "Rosen, Brian" <[email-masked]>
Date: Fri, 7 Jun 2013 19:03:07 +0000

Actually they are not.  If they were, they would use redirect.

They are terminating the original call and originating a new call.

Brian

On Jun 7, 2013, at 2:58 PM, Hadriel Kaplan <[email-masked]> wrote:

> Arguably they're not "spoofing" - they're just routing the call, similar to a transit.  Granted it's a new "call" at a SIP protocol level, but at the higher "who's calling me for this call?" level, the PBX should leave the >From alone to be the original caller.
> 
> -hadriel
>

---

From: Hadriel Kaplan <[email-masked]>
Date: Fri, 7 Jun 2013 15:06:40 -0400

On Jun 7, 2013, at 2:53 PM, Dave Crocker <[email-masked]> wrote:

> By many measures, no one is a good guy.  But some guys are authorized. For example, anyone who is assigned a number block is authorized.
> Certs tend to carry an implication of goodness.  My suggestion is more modest, to seek accountability through authenticity.
> 
> Have such folk register a signing domain in a table of authorized folk.  Anything signed has the name queried to that table.  This verifies that they are authorized as an operator.
> It doesn't certify their goodness or even their authorization for a number block, but it means they are on the hook for their bad behavior, because you really do know who they are.

Essentially a reputation system, which will work so long as it's national operators doing this thing, because they're known and there aren't that many of them in any given country.

That was basically one of the premises behind this being useful:
http://tools.ietf.org/html/draft-kaplan-sip-asserter-identity-01

Although I admit it might get to the point of being this:
http://xkcd.com/1181/

-hadriel

---

From: "Rosen, Brian" <[email-masked]>
Date: Fri, 7 Jun 2013 19:08:48 +0000

But then we're creating a table owner, and a criteria to get on the table.

It also won't lead to the end state we really want which is the end device signs and the other end device verifies.  Delegation works perfectly fine right down to a single number.

It's reasonable to start with service providers signing and checking, but we'd like to evolve to end to end.

The cert is not carrying any notion of goodness whatsoever.  It doesn't even have to identify the holder in any way.  All it has to do is prove provenance for the number.

That's a pretty good model.

Brian

---

From: Hadriel Kaplan <[email-masked]>
Date: Fri, 7 Jun 2013 12:08:57 -0700 (PDT)

> They are terminating the original call and originating a new call.

As I said: at a SIP protocol level it's a new call.  But not at a user level.

---

From: "Rosen, Brian" <[email-masked]>
Date: Fri, 7 Jun 2013 19:14:03 +0000

Okay, but we're working on the SIP protocol.

If we are talking about user level, the user wants to know the difference between a call placed directly to his mobile and a call placed to his office and forwarded by his office to his mobile.

And I would not care to get into a discussion of what the UI to distinguish is :)

Brian

---

From: Dave Crocker <[email-masked]>
Date: Fri, 07 Jun 2013 21:17:34 +0200

> But then we're creating a table owner, and a criteria to get on the

Credentials have the same requirement.  Take a look at your summary of
the hierarchy.  At each level, it's another table owner.

 > It also won't lead to the end state we really want which is the end
 > device signs and the other end device verifies.

Sure it can, but not with the signature you've had in mind.

(Just to be clear, I'm suggesting consideration of an approach; I'm not 
sure it's the best one and I'm therefore not pushing for its adoption, 
merely that it be explored.)

Anyone can sign.  They sign with a domain they own.  So the signature 
goes with the operator, not with the content (number, message, whatever.)

For reference, the summary you gave (credential for a number block) is 
pretty much the same kind of thing, since it's really the referencing 
the owner of the block, rather than the number itself.

 > The cert is not carrying any notion of goodness whatsoever.  It
 > doesn't even have to identify the holder in any way.  All it has to
 > do is prove provenance for the number.
 >

It's excellent in theory, but has not had a promising history on the 
open and wooly Internet.

d/

---

From: Hadriel Kaplan <[email-masked]>
Date: Fri, 7 Jun 2013 15:34:09 -0400

> Okay, but we're working on the SIP protocol.

Not really - we're basically trying to work around the SIP protocol because it's use-in-practice doesn't match the expectations of the RFCs.  That's one of the things that made 4474 D.O.A. on day one, and why we have INSIPID, and STRAW, etc.

PBXes *should* use a 3xx redirect or record-route proxy model for call-forwarding, but they sometimes don't - not because the call truly is a new call, but rather because if they don't handle it as a B2BUA then the call will fail, or be billed incorrectly, etc.

> If we are talking about user level, the user wants to know the difference between a call placed directly to his mobile and a call placed to his office and forwarded by his office to his mobile.

Sure but that's what history-info/diversion was supposed to do, by identifying the original called number.

-hadriel

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 07 Jun 2013 15:38:07 -0400

> I think presence of most prefixes would be pretty easy to deal with.  I would not expect to see the PBX prefixes (9-1-202-555-1212), because the downstream entities couldn't route if they were ther…

Are we only talking about NANP, or numbers for anyplace?

If you take a valid E.164 number, without the "+", and maybe with or 
without the country code, and potentially prefixed with arbitrary 
garbage, I'm pretty sure there is no way to uniquely identify the E.164 
number.

But maybe you were assuming something else.

	Thanks,
	Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 07 Jun 2013 15:41:28 -0400

> In countries with number portability, there are some complications, but in all cases, there is a clear delegation path for the numbers, and the cert chain follows it.

We have a solution for that: ENUM.
If you deploy that with DNSSEC you have it all.

All you then need is to deploy ENUM that way. :-)

	Thanks,
	Paul

---

From: "Rosen, Brian" <[email-masked]>
Date: Fri, 7 Jun 2013 19:47:24 +0000

> the hierarchy.  At each level, it's another table owner.

Big difference between a single table of all service providers and each service provider maintaining a table of its customers.
We are asking number resellers to know their customer, but we can hold the reseller to account if he doesn't.

You are proposing a master table.  

I worry less about the owner of a master table (my employer is good at that sort of thing), but the criteria is very difficult.

> (Just to be clear, I'm suggesting consideration of an approach; I'm not sure it's the best one and I'm therefore not pushing for its adoption, merely that it be explored.)
> 
> Anyone can sign.  They sign with a domain they own.  So the signature goes with the operator, not with the content (number, message, whatever.)
> 
> For reference, the summary you gave (credential for a number block) is pretty much the same kind of thing, since it's really the referencing the owner of the block, rather than the number itself.
I don't agree.  It's referencing the block itself.

The delegator has to know who he is delegating to, but the cert does not have to identify the holder in any way.  The signing mechanism is dependent only on the delegation model, not the identity of the holder.

When things go awry, we will run down the chain asking each level who their customer is, but the chain itself does not contain that information.

> 
> It's excellent in theory, but has not had a promising history on the open and wooly Internet.

This isn't the open and wooly Internet.  It's the telephone network, running in part on mostly private IP networks.
Of course the solution works across the Internet, and many of us would be very pleased if there were lots of calls placed over the Internet with good end to end source identity.  But the problem we're solving is more short term, in a more restricted environment.

Brian

---

From: Henning Schulzrinne <[email-masked]>
Date: Fri, 7 Jun 2013 15:53:22 -0400

On Jun 7, 2013, at 3:38 PM, Paul Kyzivat <[email-masked]> wrote:

> If you take a valid E.164 number, without the "+", and maybe with or without the country code, and potentially prefixed with arbitrary garbage, I'm pretty sure there is no way to uniquely identify the E.164 number.

At least for countries with fixed-length numbers, such as the US, taking the last 10 digits would seem to work, if the number string is longer than that.

---

From: "Richard Shockey" <[email-masked]>
Date: Fri, 7 Jun 2013 16:11:29 -0400

> It's excellent in theory, but has not had a promising history on the open
and wooly Internet.

This isn't the open and wooly Internet.  It's the telephone network, running
in part on mostly private IP networks.
Of course the solution works across the Internet, and many of us would be
very pleased if there were lots of calls placed over the Internet with good
end to end source identity.  But the problem we're solving is more short
term, in a more restricted environment.
[RS> ] 
[RS> ] Brian is correct to point this out we are not right now talking about
the wild and woolly Internet.  TDM networks are dying but even the carrier
based SIP/IMS networks are closed and heavily "managed" for lots of reasons,
principally QoS and QoE.  

Brian

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 07 Jun 2013 16:17:07 -0400

> At least for countries with fixed-length numbers, such as the US, taking the last 10 digits would seem to work, if the number string is longer than that.

That's why I asked if this was just for NANP.
But even if we are only addressing concerns of the FCC, there are calls 
into the US from outside, and from inside to outside. So not all the 
numbers are going to be NANP numbers, and not all will be fixed length.

	Thanks,
	Paul

---

From: Bernard Aboba <[email-masked]>
Date: Fri, 7 Jun 2013 15:11:56 -0700

On Fri, Jun 7, 2013 at 11:40 AM, Henning Schulzrinne
<[email-masked]> wrote:

"On forwarding, it would seem that, in many cases, the validation is
done *before* the forwarding happens. For example, the typical
follow-me on a PBX is done by my (trusted) PBX, and it would do the
validation on the incoming call. "

[BA] Right. Presumably if the validation fails, the forwarding would
not occur.  But the question is whether the PBX will handle forwarding
in a way that would invalidate the signature and make it seem like the
forwarded call is spoofed when it is not.

---

From: Stephen Farrell <[email-masked]>
Date: Fri, 07 Jun 2013 23:20:52 +0100

On 06/07/2013 09:17 PM, Paul Kyzivat wrote:
>>
>> At least for countries with fixed-length numbers, such as the US,
>> taking the last 10 digits would seem to work, if the number string is
>> longer than that.
> 

IMO a solution that did not allow signatures over numbers from any
country to be validated reliably would simply be broken. If I were
still on the IESG when that came up, it'd be a guaranteed discuss
ballot from me. And not one that'd go away until the problem was
properly fixed.

There may well be issues to do with canonicalisation and there may
be discussion needed as to how that is split between signer and
verifier. But a country agnostic solution is definitely required
at the sign/verify/bind-to-cert level.

S.

---

From: Richard Barnes <[email-masked]>
Date: Fri, 7 Jun 2013 18:38:18 -0400

+1

---

From: "Richard Shockey" <[email-masked]>
Date: Fri, 7 Jun 2013 18:51:27 -0400

There are only a limited number of countries that still support variable
length dial plans. Germany is the worst case.

There are variations in localized dialing schemes but the solution for that
was always convert the local number to the full E.164 before look ups.

We went round and round on this in ENUM. 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Stephen Farrell
Sent: Friday, June 07, 2013 6:21 PM
To: Paul Kyzivat
Cc: [email-masked]; Henning Schulzrinne
Subject: Re: [stir] Can canonical phone numbers survive SBCs and other
middle boxes?

On 06/07/2013 09:17 PM, Paul Kyzivat wrote:
> But even if we are only addressing concerns of the FCC, there are 
> calls into the US from outside, and from inside to outside. So not all 
> the numbers are going to be NANP numbers, and not all will be fixed
length.

IMO a solution that did not allow signatures over numbers from any country
to be validated reliably would simply be broken. If I were still on the IESG
when that came up, it'd be a guaranteed discuss ballot from me. And not one
that'd go away until the problem was properly fixed.

There may well be issues to do with canonicalisation and there may be
discussion needed as to how that is split between signer and verifier. But a
country agnostic solution is definitely required at the
sign/verify/bind-to-cert level.

S.

---

From: Stephen Farrell <[email-masked]>
Date: Sat, 08 Jun 2013 00:04:27 +0100

> was always convert the local number to the full E.164 before look ups.

If that's the answer for both caller and callee numbers and it
works then that sounds ok. I'd not be surprised if there were
wrinkles, and that might be ok...depending. It'd not be ok if
the wrinkles overwhelmingly and significantly affected non-NANP
numbers for example.

> We went round and round on this in ENUM. 

No need to do it again then maybe:-) Or perhaps this context
is different if one needs to sign/verify both numbers rather
than just looking one up in the DNS. But the country-agnostic
requirement is I think clear enough, particularly at this
pre-chartering stage, i.e. I don't think there's a need to delve
into possible solutions(s) right now.

S.

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 07 Jun 2013 19:11:02 -0400

The sensible thing would be to expect the numbers to be "pure" E.164 
(with the +), before signing. But that might take some doing.

	Thanks,
	Paul

---

From: Henning Schulzrinne <[email-masked]>
Date: Fri, 7 Jun 2013 22:18:31 -0400

I'm trying to identify common cases, while still dealing with the others, possibly in more complicated ways. 

(1) We seem to agree that canonicalization should be possible, particularly from and to the edges of carrier networks, even beyond the +1 scope. I believe this is true since it would otherwise be nearly impossible to populate SS7 fields correctly, and I suspect that the tolerance of switches for SS7 field variations is a bit less than for SIP SBCs. In particular, since originating numbers are often used for intercarrier compensation, there are clear business reasons not to have too many variations that can't be understood by carriers that exchange traffic. I haven't looked at SS7 traces to see whether this is true in practice, but I suspect there are people on this list who have.

(2) For the forwarding/follow-me case, there seem to be two cases:

(a) The PBX creates a new call, but still uses the original From. In that case, the PBX could use its generic signature. The recipient very likely is a customer/employee of the PBX owner/operator, so it can easily recognize that this is "home" calling.

(b) The PBX can pass on the signature if the To is maintained and the call is routed based on the request-URI.

For (b), we have to decide whether To should be part of the signature. If not, the signature will survive forwarding, but this will obviously make abuse by replay much easier, at least for a few seconds until the Date fails the staleness test. I'm personally not very worried about replay, given the practical difficulties of intercepting "good" calls, if we ignore the NSA for the moment, but that requires more discussion.

Thus, one possibility is that, long-term, number-based certs are used for the most common "interdomain" calling cases, edge-to-edge, and "good guy" certs for the special cases where number certs are difficult to obtain.

Henning

---

From: "Richard Shockey" <[email-masked]>
Date: Sat, 8 Jun 2013 11:26:52 -0400

Correct.  There are some interesting tangential issues here that push that
process forward. I actually think the process might be easier that we might
imagine. 

If you look at the STIR problem statement in the larger context of PSTN
Transition this is actually the perfect time to consider this work.   

It has been clear to many of us for some time that that the carriers and the
NRA's were going to have to take a long look at the structure of National
Numbering Databases in general.  Ultimately those databases (and they are
not public) could contain URI data in order to facilitate all SIP
Interconnection.  There is a LOT of that going on right now.  Transition is
easier when you have national CDB structured for LNP like the NPAC or in the
case of the Netherlands COIN, Ireland, Sweden, Brazil, India, Pakistan etc.
I think you could make that argument that there is sufficient national
administrative expertise here facilitate the process going forward since the
lines of delegation are well understood. 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Paul
Kyzivat
Sent: Friday, June 07, 2013 7:11 PM
To: [email-masked]
Subject: Re: [stir] Can canonical phone numbers survive SBCs and other
middle boxes?

The sensible thing would be to expect the numbers to be "pure" E.164 (with
the +), before signing. But that might take some doing.

	Thanks,
	Paul

On 6/7/13 6:51 PM, Richard Shockey wrote:
> There are only a limited number of countries that still support 
> variable length dial plans. Germany is the worst case.
>
> There are variations in localized dialing schemes but the solution for 
> that was always convert the local number to the full E.164 before look
ups.
> From: [email-masked] [mailto:[email-masked]] On Behalf 
> Of Stephen Farrell
>>> taking the last 10 digits would seem to work, if the number string 
>>> is longer than that.
>>
>> calls into the US from outside, and from inside to outside. So not 
>> all the numbers are going to be NANP numbers, and not all will be 
>> fixed
> length.
>
> ballot from me. And not one that'd go away until the problem was properly
fixed.
> discussion needed as to how that is split between signer and verifier. 
> But a country agnostic solution is definitely required at the

---

From: Hadriel Kaplan <[email-masked]>
Date: Sat, 8 Jun 2013 13:41:35 -0400

> (1) We seem to agree that canonicalization should be possible, particularly from and to the edges of carrier networks, even beyond the +1 scope. I believe this is true since it would otherwise be n…

Yes, I think I misunderstood Brian and your questions about canonicalization.  I thought you meant can we define a canonical format of the To/From usernames that everyone must start using on-the-wire for this new mechanism, so we can sign the To/From URIs.  But really what you meant was the To/From can change constantly on-the-wire, so long as a signer/verifier can programmatically determine some canonical form from the non-canonical one received on-the-wire.  So you don't care what the literal strings are on-the-wire, right?

> (a) The PBX creates a new call, but still uses the original From. In that case, the PBX could use its generic signature. The recipient very likely is a customer/employee of the PBX owner/operator,…

I expect it to be rare for the endpoint phones to do the verification - it would be the terminating service provider, who won't know the PBX is a legitimate signer for someone else's phone number.
With the sip asserter identity draft, the PBX can create a new SIP call but use the same signature it received for the same original From (well, it's really a P-Asserted-Identity instead of From)

> For (b), we have to decide whether To should be part of the signature. If not, the signature will survive forwarding, but this will obviously make abuse by replay much easier, at least for a few se…

That's one of the reasons the sip asserter-identity draft put the original To in a new separate header and signed that instead.
The PBX can forward the call and change the To, and the signature doesn't break but still has replay protection.

-hadriel

---

From: Henning Schulzrinne <[email-masked]>
Date: Sat, 8 Jun 2013 14:01:27 -0400

Inline.

> Yes, I think I misunderstood Brian and your questions about canonicalization.  I thought you meant can we define a canonical format of the To/From usernames that everyone must start using on-the-wi…

Indeed. I only care about two operations:

(1) The caller edge node can extract E.164 numbers from the From and To, convert it into a tel: URI and include it in the signature. [The conversion to a tel URI isn't really necessary, but might be a good way to have a single logical representation for both the tel and non-tel cases.]

(2) The callee edge node can do the same and thus compare the signature.

> The PBX can forward the call and change the To, and the signature doesn't break but still has replay protection.

The question is whether History-Info can do the same thing. To the extent possible, it would seem to be nice to have a uniform mechanism that can handle both the direct call and redirected call case, rather than two completely separate ones.

---

From: Michael Hammer <[email-masked]>
Date: Sat, 8 Jun 2013 18:16:14 +0000

If we were to define new headers to be strictly E.164 numbers that must not
be modified no matter how many networks you hop through,
And those are the ones that get signed, then you would not even need the "+"
prefix.

The current headers are too over-loaded with usages at this point to be much
help here.

Mike

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

	Thanks,
	Paul

ups.
fixed.

---

From: Brian Rosen <[email-masked]>
Date: Mon, 10 Jun 2013 08:52:52 -0400

> The current headers are too over-loaded with usages at this point to be much
We have a hypothesis that numbers going between service providers are always convertible to e.164 programatically.  If you have relevant examples where that is not true, please send them.

I'd rather not have new headers if we can avoid it.

Brian

---

From: <[email-masked]>
Date: Mon, 10 Jun 2013 13:06:37 +0000

> Can we come up with examples where a canonicalized e.164 would NOT pass end to end?

I'm not sure the following would fall into your category but in addition to prefixing thaty's already been mentioned, you may also have cases where the conversion from the dialing plan to the numbering plan involves a "degree of complexity" that cannot be expected from some endpoints because it is more complex than just "replace the national prefix, aka 'trunk prefix', with the relevant geographic country code" to get the full E.164 canonical form. (for example, supposing 0 as a national trunk code, some dialing plans map 0-XXX to _several_ geographic country codes +CC-XXX depending on the value of XXX). 

One simple way to support these formats is to allow the endpoint (eg a PBX) to always send +CC-XXX with one given CC (and therefore potentially incorrect canonical form) and correct it with the right mapping downstream. On may argue that it is a bit of a hack to make up for the lack of support of a phone-context by the endpoints, but you generally have to make do without it. 

Regards,

Philippe Fouquart
Orange Labs Networks
+33 (0) 1 45 29 58 13

From: [email-masked] [mailto:[email-masked]] On Behalf Of Rosen, Brian
Sent: Friday, June 07, 2013 7:20 PM
To: [email-masked]
Subject: [stir] Can canonical phone numbers survive SBCs and other middle boxes?

Brian

_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
France Telecom - Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, France Telecom - Orange is not liable for messages that have been modified, changed or falsified.
Thank you.

---

From: "Rosen, Brian" <[email-masked]>
Date: Mon, 10 Jun 2013 13:27:36 +0000

If both the endpoints and their SPs understand the rules, then they can generate the signature and check it.
Might have problems with intermediaries that couldn't do that unless the To was rewritten at some point.   It would seem to me that in order to route these calls, that's what would have to happen unless you are using P-A-I passed between carriers to carry the decoded e.164.

Brian

---

From: <[email-masked]>
Date: Mon, 10 Jun 2013 14:09:18 +0000

Thanks. Am I then right in rephrasing this as "it isn't going to be a problem if and only if the intermediary that corrects the canonical form is also able to [re]sign the [corrected] number?" 

For CgPNs, I guess this would work for a pbx using numbers under ranges of their service provider (or ported to it), but may not easily work for (more interesting) cases where the CgPN is completely unrelated with the call centre that initiated the call (eg a concierge service using their customer's individual number, the "Permitted spoofing" case). 

Regards,

Philippe Fouquart
Orange Labs Networks
+33 (0) 1 45 29 58 13

-----Original Message-----
From: Rosen, Brian [mailto:[email-masked]] 
Sent: Monday, June 10, 2013 3:28 PM
To: FOUQUART Philippe OLNC/OLN
Cc: [email-masked]
Subject: Re: [stir] Can canonical phone numbers survive SBCs and other middle boxes?

Brian

---

From: "Rosen, Brian" <[email-masked]>
Date: Mon, 10 Jun 2013 14:14:28 +0000

I never thought about resigning.

Whatever element signs has to be authoritative for the e.164.  In your example, who do you think would do the initial signing and who would re-sign?

Brian

---

From: <[email-masked]>
Date: Mon, 10 Jun 2013 15:04:11 +0000

I assume the initial signing to be done by the endpoint, the pbx, which has authority over the full E.164 number.

If the canonical form is incorrect (the international format is incorrect or the number is only provided in national format), I would have imagined that the intermediary would have to provide a correct canonical form and (?) resign.  

Philippe Fouquart
Orange Labs Networks
+33 (0) 1 45 29 58 13

-----Original Message-----
From: Rosen, Brian [mailto:[email-masked]] 
Sent: Monday, June 10, 2013 4:14 PM
To: FOUQUART Philippe OLNC/OLN
Cc: Rosen, Brian; [email-masked]
Subject: Re: [stir] Can canonical phone numbers survive SBCs and other middle boxes?

Brian

---

From: "Rosen, Brian" <[email-masked]>
Date: Mon, 10 Jun 2013 15:25:20 +0000

In order for that to work, the intermediary has to be authoritative for
the number.  
Would that work?

Brian

On 6/10/13 11:04 AM, "[email-masked]"
<[email-masked]> wrote:

>I assume the initial signing to be done by the endpoint, the pbx, which
>has authority over the full E.164 number.
>
>If the canonical form is incorrect (the international format is incorrect
>or the number is only provided in national format), I would have imagined
>that the intermediary would have to provide a correct canonical form and
>(?) resign.  
>
>Philippe Fouquart
>Orange Labs Networks
>+33 (0) 1 45 29 58 13
>
>
>Whatever element signs has to be authoritative for the e.164.  In your
>example, who do you think would do the initial signing and who would
>re-sign?
>
>Brian
>
>> Thanks. Am I then right in rephrasing this as "it isn't going to be a
>>problem if and only if the intermediary that corrects the canonical form
>>is also able to [re]sign the [corrected] number?"
>> 
>> For CgPNs, I guess this would work for a pbx using numbers under ranges
>>of their service provider (or ported to it), but may not easily work for
>>(more interesting) cases where the CgPN is completely unrelated with the
>>call centre that initiated the call (eg a concierge service using their
>>customer's individual number, the "Permitted spoofing" case).
>> 
>> Regards,
>> 
>> Philippe Fouquart
>> Orange Labs Networks
>> +33 (0) 1 45 29 58 13
>> 
>> 
>> Might have problems with intermediaries that couldn't do that unless
>>the To was rewritten at some point.   It would seem to me that in order
>>to route these calls, that's what would have to happen unless you are
>>using P-A-I passed between carriers to carry the decoded e.164.
>> 
>> Brian
>> 
>> 
>>> I'm not sure the following would fall into your category but in
>>>addition to prefixing thaty's already been mentioned, you may also have
>>>cases where the conversion from the dialing plan to the numbering plan
>>>involves a "degree of complexity" that cannot be expected from some
>>>endpoints because it is more complex than just "replace the national
>>>prefix, aka 'trunk prefix', with the relevant geographic country code"
>>>to get the full E.164 canonical form. (for example, supposing 0 as a
>>>national trunk code, some dialing plans map 0-XXX to _several_
>>>geographic country codes +CC-XXX depending on the value of XXX).
>>> 
>>> One simple way to support these formats is to allow the endpoint (eg a
>>>PBX) to always send +CC-XXX with one given CC (and therefore
>>>potentially incorrect canonical form) and correct it with the right
>>>mapping downstream. On may argue that it is a bit of a hack to make up
>>>for the lack of support of a phone-context by the endpoints, but you
>>>generally have to make do without it.
>>> 
>>> Regards,
>>> 
>>> Philippe Fouquart
>>> Orange Labs Networks
>>> +33 (0) 1 45 29 58 13
>>> 
>>>Of Rosen, Brian
>>> Henning has proposed that we canonicalize the From and To phone
>>>numbers, we include a timestamp and some form of call-id, possibly the
>>>INSIPID id.  
>>> 
>>> There are assertions that you can't use From/To, because middle boxes
>>>change them.  Some have suggested using P-A-I and other headers instead.
>>> 
>>> After reading it, I am unclear if a canonicalized e.164 would make it
>>>through.  The reasons given seem to indicate they would.  They change
>>>domains, they change prefixes, but they don't seem to change the actual
>>>telephone number.
>>> 
>>>________________________________________________________________________
>>>_________________________________________________
>>> 
>>> Ce message et ses pieces jointes peuvent contenir des informations
>>>confidentielles ou privilegiees et ne doivent donc
>>> pas etre diffuses, exploites ou copies sans autorisation. Si vous avez
>>>recu ce message par erreur, veuillez le signaler
>>> a l'expediteur et le detruire ainsi que les pieces jointes. Les
>>>messages electroniques etant susceptibles d'alteration,
>>> This message and its attachments may contain confidential or
>>>privileged information that may be protected by law;
>>> As emails may be altered, France Telecom - Orange is not liable for
>>>messages that have been modified, changed or falsified.
>>> Thank you.
>>> 
>> 
>> 
>> 
>>_________________________________________________________________________
>>________________________________________________
>> 
>> Ce message et ses pieces jointes peuvent contenir des informations
>>confidentielles ou privilegiees et ne doivent donc
>> pas etre diffuses, exploites ou copies sans autorisation. Si vous avez
>>recu ce message par erreur, veuillez le signaler
>> a l'expediteur et le detruire ainsi que les pieces jointes. Les
>>messages electroniques etant susceptibles d'alteration,
>> This message and its attachments may contain confidential or privileged
>>information that may be protected by law;
>> As emails may be altered, France Telecom - Orange is not liable for
>>messages that have been modified, changed or falsified.
>> Thank you.
>> 
>__________________________________________________________________________
>Ce message et ses pieces jointes peuvent contenir des informations
>confidentielles ou privilegiees et ne doivent donc
>pas etre diffuses, exploites ou copies sans autorisation. Si vous avez
>recu ce message par erreur, veuillez le signaler
>a l'expediteur et le detruire ainsi que les pieces jointes. Les messages
>electroniques etant susceptibles d'alteration,
>This message and its attachments may contain confidential or privileged
>information that may be protected by law;
>As emails may be altered, France Telecom - Orange is not liable for
>messages that have been modified, changed or falsified.
>Thank you.
>

---

From: "Dwight, Timothy M \(Tim\)" <[email-masked]>
Date: Mon, 10 Jun 2013 11:39:50 -0400

I suppose it's possible that both the service provider to which the number was assigned by the numbering plan authority, and the 'user' to whom that service provider assigned it, may have access to the associated private key.  I am not comfortable with the security implications of that, though.  And (to Brian's subsequent question) I'm not sure it works in all configurations, particularly I'm thinking of one in which the entity to whom the number was assigned by the numbering plan authority, not being the one providing PSTN ingress/egress services to it.  If you follow the goings-on in the US FCC you're no doubt familiar with the recently-announced trial of that scenario.

I wonder if we're trying to solve the wrong problem.  There is already precedent for a 'user asserted' identity separate from a 'network asserted' identity.  Could we use the same / similar mechanisms for both, but keep them separate?  Or is there some underlying assumption that were the FROM header sufficiently trustworthy, there would be no further need for P-A-I?

I think keeping them separate, at least might simplify the issues arising from too many entities needing access to the same private key.  As they say, 3 people can keep a secret only if 2 are dead.

Cheers,

tim

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Monday, June 10, 2013 10:04 AM
To: Rosen, Brian
Cc: [email-masked]
Subject: Re: [stir] Can canonical phone numbers survive SBCs and other middle boxes?

Philippe Fouquart
Orange Labs Networks
+33 (0) 1 45 29 58 13

-----Original Message-----
From: Rosen, Brian [mailto:[email-masked]]
Sent: Monday, June 10, 2013 4:14 PM
To: FOUQUART Philippe OLNC/OLN
Cc: Rosen, Brian; [email-masked]
Subject: Re: [stir] Can canonical phone numbers survive SBCs and other middle boxes?

Brian

On Jun 10, 2013, at 10:09 AM, [email-masked] wrote:

>> _____________________________________________________________________
>> ____________________________________________________
>> 
>> confidentielles ou privilegiees et ne doivent donc pas etre diffuses, 
>> exploites ou copies sans autorisation. Si vous avez recu ce message 
>> par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, France Telecom - Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.
>> 
>> privileged information that may be protected by law; they should not be distributed, used or copied without authorisation.
> ______________________________________________________________________
> ___________________________________________________
> 
> confidentielles ou privilegiees et ne doivent donc pas etre diffuses, 
> exploites ou copies sans autorisation. Si vous avez recu ce message 
> par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, France Telecom - Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.
> 
> privileged information that may be protected by law; they should not be distributed, used or copied without authorisation.

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, France Telecom - Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law; they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, France Telecom - Orange is not liable for messages that have been modified, changed or falsified.
Thank you.

---

From: Henning Schulzrinne <[email-masked]>
Date: Mon, 10 Jun 2013 11:44:10 -0400

Also, with new headers you still have the same or similar problem - if you just insert a new block with its own set of numbers, the destination has to compare the To (and maybe From) headers with that block, to make sure that the numbers actually are the same. Otherwise, anybody could just cut-and-paste a legitimate signed block with some random call. If you can compare the identifiers, you could presumably used the original one.

The more identifiers you have, with overlapping definitions, the more challenging it gets to figure out what they mean.

---

From: "Rosen, Brian" <[email-masked]>
Date: Mon, 10 Jun 2013 15:47:13 +0000

Well, the PBX would have a sub delegation from the SP with a narrower scope.  For example, assume the SP was delegated +CC-NPA-NXX-1000 to ..1999.   It then may have delegated +CC-NPA-NXX-1300 to 1399 to the PBX.  The PBX could sign with its 1300-1399 cert and the SP could sign with it's 1000-1999 cert.

Brian

---

From: "Olle E. Johansson" <[email-masked]>
Date: Mon, 10 Jun 2013 17:54:05 +0200

> In order for that to work, the intermediary has to be authoritative for
Have we defined "authoritative" for a specific number?

/O

---

From: "Rosen, Brian" <[email-masked]>
Date: Mon, 10 Jun 2013 16:10:38 +0000

A proposal on the table is that the PKI for Telephone Numbers (TNs) follows the TN delegation chain.  The root of trust is the national regulator, or some contractor to it.  When numbers are delegated, a cert for that delegation goes with it.  Numbers can be subdelgated, certs with the sub delegation follow.  So you are "authoritative" for a number if you have been delegated (or sub delegated) that number, and have the cert for it.  Every country has a delegation system for numbers.

There is a complication with number portability that might cause a specific number in a range to no longer be valid, but there are simple solutions to that, depending on how a country implements number portability.

Brian

---

From: Hadriel Kaplan <[email-masked]>
Date: Mon, 10 Jun 2013 12:12:23 -0400

That depends on how the cert model works.  I don't think a PBX/Enterprise would want a single cert that says its authoritative for 1300-1399, because frequently Enterprises don't want all their numbers/range publicized.  So when they make a call from a number X, that's all they want the callee to see/know-about.

-hadriel

---

From: <[email-masked]>
Date: Mon, 10 Jun 2013 16:14:17 +0000

I guess this would be a good place to start. 

For cases where that number has to go through the entity that operates the intermediary, either because it was ported in or because it was assigned within a range of that entity, I can imagine it would have 'some authority' on the number depending indeed on how you define it. 

However, for cases where for (arguably) good reasons relative to the service (eg a call centre) that number may be any number provided by the customer of that service, I don't see how it could. Im' not even advocating it should, given the generality of the case, I'm just saying such cases do exist, which is where this thread started from.  

Philippe Fouquart
Orange Labs Networks
+33 (0) 1 45 29 58 13

-----Original Message-----
From: Olle E. Johansson [mailto:[email-masked]] 
Sent: Monday, June 10, 2013 5:54 PM
To: Rosen, Brian
Cc: Olle E. Johansson; FOUQUART Philippe OLNC/OLN; [email-masked]
Subject: Re: [stir] Can canonical phone numbers survive SBCs and other middle boxes?

/O

---

From: "Olle E. Johansson" <[email-masked]>
Date: Mon, 10 Jun 2013 18:14:47 +0200

> A proposal on the table is that the PKI for Telephone Numbers (TNs) follows the TN delegation chain.  The root of trust is the national regulator, or some contractor to it.  When numbers are delega…
Sounds like DNSsec for the enum domain.
> There is a complication with number portability that might cause a specific number in a range to no longer be valid, but there are simple solutions to that, depending on how a country implements nu…
Ok.
Thank you for the clarification.
/O

---

From: "Rosen, Brian" <[email-masked]>
Date: Mon, 10 Jun 2013 16:16:00 +0000

They could request individual certs from their upstream provider.  It's just bookkeeping.

Brian

---

From: "Rosen, Brian" <[email-masked]>
Date: Mon, 10 Jun 2013 16:22:51 +0000

We agree that there are permitted instances of number spoofing.  A call center calling on behalf of an enterprise could use the enterprise's numbers.
That would have to be explicitly permitted, either by the enterprise giving the call center a cert based on it's delegation, or the upstream service provider doing it based on a request from the enterprise.  Both of those look like sub delegations.

The other example is a doctor calling from his mobile but using his office number as the From.  Same answer - the doctor or his SP authorizes this use.

The fact that you sub delegated doesn't mean the upper level delegation is not still authoritative.  The SP can sign an a call from the enterprise, even if the SP delegated numbers and gave the SP a cert for that delegation.

Brian

---

From: Hadriel Kaplan <[email-masked]>
Date: Mon, 10 Jun 2013 12:23:46 -0400

> However, for cases where for (arguably) good reasons relative to the service (eg a call centre) that number may be any number provided by the customer of that service, I don't see how it could. Im'…

If the certificate-for-a-number model is used, then in theory the customer of the service provides the call center with its private key to sign outbound calls of its number. (or more likely, its service provider would need to do it)

-hadriel

---

From: Henning Schulzrinne <[email-masked]>
Date: Mon, 10 Jun 2013 12:28:18 -0400

Or, as discussed, there are two entries in the database for the same number, one for the assignee (call center customer) and one for the call center, each with the respective private keys. Thus, no need for the customer (assignee) to reveal its private key to the call center.

---

From: "Rosen, Brian" <[email-masked]>
Date: Mon, 10 Jun 2013 16:29:57 +0000

The customer, if it has a cert, can issue a cert to the call center.  It doesn't have to share it's private key.

Brian

---

From: "Dwight, Timothy M \(Tim\)" <[email-masked]>
Date: Mon, 10 Jun 2013 12:42:07 -0400

I guess that works as long as the number blocks are different, and it's clear to the recipient whose public key he needs to use (the SP's or that of the PBX).  How would he know?  Trial and error?

Also I don't know that it works in the "Vonage" scenario I referenced obliquely below.

Tim

-----Original Message-----
From: Rosen, Brian [mailto:[email-masked]] 
Sent: Monday, June 10, 2013 10:47 AM
To: Dwight, Timothy M (Tim)
Cc: [email-masked]; [email-masked]
Subject: Re: [stir] Can canonical phone numbers survive SBCs and other middle boxes?

Brian

On Jun 10, 2013, at 11:39 AM, "Dwight, Timothy M (Tim)" <[email-masked]>
 wrote:

> Of [email-masked]
>>> ____________________________________________________________________
>>> _ ____________________________________________________
>>> 
>>> confidentielles ou privilegiees et ne doivent donc pas etre 
>>> diffuses, exploites ou copies sans autorisation. Si vous avez recu 
>>> ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, France Telecom - Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.
>>> 
>> _ ___________________________________________________
>>

---

From: Richard Barnes <[email-masked]>
Date: Mon, 10 Jun 2013 12:51:27 -0400

The traditional approach is that a signed object carries an identifier for
the key that should be used to verify it, e.g., a hash of the public key.
 This is done in PKIX, S/MIME, JOSE, ...
--Richard

On Mon, Jun 10, 2013 at 12:42 PM, Dwight, Timothy M (Tim) <
[email-masked]> wrote:

> I guess that works as long as the number blocks are different, and it's
> clear to the recipient whose public key he needs to use (the SP's or that
> of the PBX).  How would he know?  Trial and error?
>
> Well, the PBX would have a sub delegation from the SP with a narrower
> scope.  For example, assume the SP was delegated +CC-NPA-NXX-1000 to
> ..1999.   It then may have delegated +CC-NPA-NXX-1300 to 1399 to the PBX.
>  The PBX could sign with its 1300-1399 cert and the SP could sign with it's
> 1000-1999 cert.
>
> Brian
>
> > I suppose it's possible that both the service provider to which the
> number was assigned by the numbering plan authority, and the 'user' to whom
> that service provider assigned it, may have access to the associated
> private key.  I am not comfortable with the security implications of that,
> though.  And (to Brian's subsequent question) I'm not sure it works in all
> configurations, particularly I'm thinking of one in which the entity to
> whom the number was assigned by the numbering plan authority, not being the
> one providing PSTN ingress/egress services to it.  If you follow the
> goings-on in the US FCC you're no doubt familiar with the
> recently-announced trial of that scenario.
> >
> > I wonder if we're trying to solve the wrong problem.  There is already
> precedent for a 'user asserted' identity separate from a 'network asserted'
> identity.  Could we use the same / similar mechanisms for both, but keep
> them separate?  Or is there some underlying assumption that were the FROM
> header sufficiently trustworthy, there would be no further need for P-A-I?
> >
> > I think keeping them separate, at least might simplify the issues
> arising from too many entities needing access to the same private key.  As
> they say, 3 people can keep a secret only if 2 are dead.
> >
> > Cheers,
> >
> > tim
> >
> >
> >
> > If the canonical form is incorrect (the international format is
> incorrect or the number is only provided in national format), I would have
> imagined that the intermediary would have to provide a correct canonical
> form and (?) resign.
> >
> > Philippe Fouquart
> > Orange Labs Networks
> > +33 (0) 1 45 29 58 13
> >
> >
> problem if and only if the intermediary that corrects the canonical form is
> also able to [re]sign the [corrected] number?"
> >>
> the To was rewritten at some point.   It would seem to me that in order to
> route these calls, that's what would have to happen unless you are using
> P-A-I passed between carriers to carry the decoded e.164.
> >>
> >> Brian
> >>
> >>
> prefix, aka 'trunk prefix', with the relevant geographic country code" to
> get the full E.164 canonical form. (for example, supposing 0 as a national
> trunk code, some dialing plans map 0-XXX to _several_ geographic country
> codes +CC-XXX depending on the value of XXX).
> >>>
> PBX) to always send +CC-XXX with one given CC (and therefore potentially
> incorrect canonical form) and correct it with the right mapping downstream.
> On may argue that it is a bit of a hack to make up for the lack of support
> of a phone-context by the endpoints, but you generally have to make do
> without it.
> >>>
> >>> Regards,
> >>>
> >>> Philippe Fouquart
> >>> Orange Labs Networks
> >>> +33 (0) 1 45 29 58 13
> >>>
> information with a credential, and you pass the signature and a pointer to
> the credential in SIP signaling.
> >>>
> >>> ce message par erreur, veuillez le signaler a l'expediteur et le
> detruire ainsi que les pieces jointes. Les messages electroniques etant
> susceptibles d'alteration, France Telecom - Orange decline toute
> responsabilite si ce message a ete altere, deforme ou falsifie. Merci.
> >>>
> >>> privileged information that may be protected by law; they should not
> be distributed, used or copied without authorisation.
> >> par erreur, veuillez le signaler a l'expediteur et le detruire ainsi
> que les pieces jointes. Les messages electroniques etant susceptibles
> d'alteration, France Telecom - Orange decline toute responsabilite si ce
> message a ete altere, deforme ou falsifie. Merci.
> >>
> >> privileged information that may be protected by law; they should not be
> distributed, used or copied without authorisation.
> exploites ou copies sans autorisation. Si vous avez recu ce message par
> erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les
> pieces jointes. Les messages electroniques etant susceptibles d'alteration,
> information that may be protected by law; they should not be distributed,
> used or copied without authorisation.

---

From: "Rosen, Brian" <[email-masked]>
Date: Mon, 10 Jun 2013 16:53:34 +0000

The URI to the cert used for signing comes in the signaling.

Some folks on the list have proposed to use P-Asserted-Identity instead of From.  Others want to be able to make the mechanism end to end (instead of SP to SP) and would prefer to base the sig on From rather than P-A-I.

Brian

---

From: Hadriel Kaplan <[email-masked]>
Date: Mon, 10 Jun 2013 12:56:58 -0400

Sure.  Either way.

-hadriel

---

From: Hadriel Kaplan <[email-masked]>
Date: Mon, 10 Jun 2013 13:09:30 -0400

> Some folks on the list have proposed to use P-Asserted-Identity instead of From.  Others want to be able to make the mechanism end to end (instead of SP to SP) and would prefer to base the sig on F…

P-A-I is not really just SP-to-SP.  It is sometimes sent to the PBX/callee as well, and there's no real reason for it not to be afaict, unless the call is anonymous/private.  It's just that most SPs don't let their customers generate one as a caller (or rather, don't believe it if they do).

But yes, the draft proposing to sign the PAI is definitely intended for SPs to do the signing/verifying.

-hadriel

---

From: "Richard Shockey" <[email-masked]>
Date: Mon, 10 Jun 2013 13:38:30 -0400

Correct.  In fact it would be useful to stop thinking about number blocks at
all.  LNP does create some issues but those can be dealt with as Brian
points out.  It should come as no surprise that some NRA's are looking at
the entire structure of E.164 allocation with an eye to single number
issuance in order to alleviate possible number exhaust issues, among other
things.   In the future it is not unreasonable to consider Phone Numbers as
"domain names".  

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Rosen, Brian
Sent: Monday, June 10, 2013 12:11 PM
To: Olle E. Johansson
Cc: [email-masked]; [email-masked]
Subject: Re: [stir] Can canonical phone numbers survive SBCs and other
middle boxes?

A proposal on the table is that the PKI for Telephone Numbers (TNs) follows
the TN delegation chain.  The root of trust is the national regulator, or
some contractor to it.  When numbers are delegated, a cert for that
delegation goes with it.  Numbers can be subdelgated, certs with the sub
delegation follow.  So you are "authoritative" for a number if you have been
delegated (or sub delegated) that number, and have the cert for it.  Every
country has a delegation system for numbers.

There is a complication with number portability that might cause a specific
number in a range to no longer be valid, but there are simple solutions to
that, depending on how a country implements number portability.

Brian

On Jun 10, 2013, at 11:54 AM, Olle E. Johansson <[email-masked]> wrote:

>> In order for that to work, the intermediary has to be authoritative 
>> for the number.
>> Would that work?
>>> I assume the initial signing to be done by the endpoint, the pbx, 
>>> which has authority over the full E.164 number.
>>> 
>>> incorrect or the number is only provided in national format), I 
>>> would have imagined that the intermediary would have to provide a 
>>> correct canonical form and
>>> (?) resign.  
>>> 
>>> Philippe Fouquart
>>> Orange Labs Networks
>>> +33 (0) 1 45 29 58 13
>>> 
>>> 
>>> Whatever element signs has to be authoritative for the e.164.  In 
>>> your example, who do you think would do the initial signing and who 
>>> would re-sign?
>>> 
>>> Brian
>>> 
>>>> Thanks. Am I then right in rephrasing this as "it isn't going to be 
>>>> a problem if and only if the intermediary that corrects the 
>>>> canonical form is also able to [re]sign the [corrected] number?"
>>>> 
>>>> For CgPNs, I guess this would work for a pbx using numbers under 
>>>> ranges of their service provider (or ported to it), but may not 
>>>> easily work for (more interesting) cases where the CgPN is 
>>>> completely unrelated with the call centre that initiated the call 
>>>> (eg a concierge service using their customer's individual number, the
"Permitted spoofing" case).
>>>> to route these calls, that's what would have to happen unless you 
>>>> are using P-A-I passed between carriers to carry the decoded e.164.
>>>> 
>>>> Brian
>>>> 
>>>> 
>>>>> addition to prefixing thaty's already been mentioned, you may also 
>>>>> have cases where the conversion from the dialing plan to the 
>>>>> numbering plan involves a "degree of complexity" that cannot be 
>>>>> expected from some endpoints because it is more complex than just 
>>>>> "replace the national prefix, aka 'trunk prefix', with the relevant
geographic country code"
>>>>> to get the full E.164 canonical form. (for example, supposing 0 as 
>>>>> a national trunk code, some dialing plans map 0-XXX to _several_ 
>>>>> potentially incorrect canonical form) and correct it with the 
>>>>> right mapping downstream. On may argue that it is a bit of a hack 
>>>>> to make up for the lack of support of a phone-context by the 
>>>>> endpoints, but you generally have to make do without it.
>>>>> 
>>>>> Regards,
>>>>> 
>>>>> Philippe Fouquart
>>>>> Orange Labs Networks
>>>>> +33 (0) 1 45 29 58 13
>>>>> 
>>>>> information with a credential, and you pass the signature and a 
>>>>> pointer to the credential in SIP signaling.
>>>>> 
>>>>> numbers, we include a timestamp and some form of call-id, possibly 
>>>>> the INSIPID id.
>>>>> 
>>>>> There are assertions that you can't use From/To, because middle 
>>>>> boxes change them.  Some have suggested using P-A-I and other headers
instead.
>>>>> After reading it, I am unclear if a canonicalized e.164 would make 
>>>>> it through.  The reasons given seem to indicate they would.  They 
>>>>> change domains, they change prefixes, but they don't seem to 
>>>>> change the actual telephone number.
>>>>> 
>>>>> __________________________________________________________________
>>>>> ______ _________________________________________________
>>>>> 
>>>>> detruire ainsi que les pieces jointes. Les messages electroniques 
>>>>> etant susceptibles d'alteration, France Telecom - Orange decline 
>>>>> toute responsabilite si ce message a ete altere, deforme ou 
>>>>> falsifie. Merci.
>>>>> 
>>>>> privileged information that may be protected by law; they should 
>>>>> not be distributed, used or copied without authorisation.
>>>>> If you have received this email in error, please notify the sender 
>>>>> and delete this message and its attachments.
>>>>> As emails may be altered, France Telecom - Orange is not liable 
>>>>> for messages that have been modified, changed or falsified.
>>>>> Thank you.
>>>>> 
>>>> 
>>>> 
>>>> 
>>>> ___________________________________________________________________
>>>> ______ ________________________________________________
>>>> 
>>>> detruire ainsi que les pieces jointes. Les messages electroniques 
>>>> etant susceptibles d'alteration, France Telecom - Orange decline 
>>>> toute responsabilite si ce message a ete altere, deforme ou 
>>>> falsifie. Merci.
>>>> 
>>>> privileged information that may be protected by law; they should 
>>>> not be distributed, used or copied without authorisation.
>>>> If you have received this email in error, please notify the sender 
>>>> and delete this message and its attachments.
>>> ______ _______________________________________________
>>> 
>>> detruire ainsi que les pieces jointes. Les messages electroniques 
>>> etant susceptibles d'alteration, France Telecom - Orange decline 
>>> toute responsabilite si ce message a ete altere, deforme ou 
>>> falsifie. Merci.
>>> 
>>> If you have received this email in error, please notify the sender 
>>> and delete this message and its attachments.

---

From: "Olle E. Johansson" <[email-masked]>
Date: Mon, 10 Jun 2013 20:31:36 +0200

> Some folks on the list have proposed to use P-Asserted-Identity instead of From.  Others want to be able to make the mechanism end to end (instead of SP to SP) and would prefer to base the sig on F…
I think we have to separate phone numbers (E.164) from e-mail style SIP uri's in this discussion. Just saying "The URI" is not enough.

If I understand correctly this discussion is focused on the E.164 plan, so either Tel: uri's or just a phone number
that has some kind of relationship to the caller. In the case of e-mail style SIP uri's the relationship
is quite clear. 

I think this is a reason why tel: was excluded from SIP identity - so we're looking to close that hole and in this work exclude the sip:/sips: URI's.

/O

---

From: "Rosen, Brian" <[email-masked]>
Date: Mon, 10 Jun 2013 18:35:29 +0000

Well, mostly, yes.  

The work is specifically aimed at telephone numbers as identifiers.  I think we would like to see a way to expand beyond that some day, but the target is telephone number based identifiers.

How you encode the number (as a tel: uri or a sip uri with user=phone) in To/From/P-A-I/... may not matter if this discussion on canonicalization works out.

Brian

---

From: "Olle E. Johansson" <[email-masked]>
Date: Mon, 10 Jun 2013 20:45:36 +0200

> things.   In the future it is not unreasonable to consider Phone Numbers as
If I'm correct a delegation in Germany more or less works that way.
If I get +468964020 in Sweden, that's one single number. In Germany,
it would be a prefix that can be extended arbitrary.

We have to be careful with PKIs. If we're going down that path, the 
verification process will be painful. Switchover during the porting process
will have to be instant - if we don't allow two certs for the same number.

How many verifications can happen during one call from Alice to Bob?

/O

---

From: "Rosen, Brian" <[email-masked]>
Date: Mon, 10 Jun 2013 18:58:10 +0000

Yeah, the basic variable length number is fairly easy to handle, but only
if you have the full number (no missing digits, other than perhaps the
country code).  If you have the full e.164, no problem.

All the existing number portability schemes have some kind of changeover
time measured in minutes, hours or days depending on the country.  The
cut-over doesn't have to be instantaneous.  Where there is a database, the
database could provide a validation ("is this specific TN still valid for
the range this cert covers?").  For countries that use forwarding schemes,
the original number holder would issue a cert to the gaining SP.

To stop the problem, I think we need to at least start with verification
across SP boundaries and the termination.  We want to get to the point
where an SP doesn't accept calls from a downstream SP that isn't
verifiable. Long term, that might be more of an audit between SPs, rather
than a 100% check, and I think we would see 100% verification at the end
of the call (ideally the end device, but perhaps the termination SP).

Brian

---

From: Henning Schulzrinne <[email-masked]>
Date: Mon, 10 Jun 2013 15:59:22 -0400

For reasons related to legitimate spoofing, you probably want multiple certs for the same number anyway.

---

From: Stephen Farrell <[email-masked]>
Date: Mon, 10 Jun 2013 21:21:38 +0100

Hi

> goes with the operator, not with the content (number, message, whatever.)

I'd also like to understand the argument here as to whether a DKIM
like approach to public key retrieval is good enough or not for this
application. (Note that this is orthogonal to any discussion about a
DKIM-like or 4474-like signature format, I'm just asking about public
key retrieval now.)

As with everything, I don't need to understand it now, but I do think
that a bunch of folks here are making assumptions about PKI that might
turn out to be a large amount of work later, e.g. that TN delegation
specific certificate chains exist, can be found and can be verified
efficiently.

One could easily argue that since ENUM exists and DKIM key records
exist (*) a DNS lookup could be the way to get signers' public keys
without requiring any 5280 processing at all at the signer or verifier.

One could further argue that that'd be sufficiently "secure" even
without DNSSEC, in that it'd be enough to mitigate your robocaller
issues on the basis that those robocallers aren't gonna MITM or
poison DNS at the verifier.

A similar argument was made for DKIM: since a bad DKIM signature is
the same as no signature on a mail message, there's no need to require
DNSSEC to get DKIM started.

While its not quite the same in this context, it may be that one
could argue that a reasonable threat model would not require the
signature verifier (someone/thing en-route to the callee) to
strongly verify the signing public key.

(Ok, I can't resist adding a feature:-) If the DKIM key selector
were modified (to put it in the key value) then you might also get
some level of traceability in that one could trawl the DNS for
signer's public keys. I don't know if that'd be good or bad.

Anyway, for now, can we make sure this gets discussed before we
plump for any specific key management solution? That could be now,
or at a DISPATCH session or BoF or after a WG is chartered, I
don't mind, so long as it is properly considered.

S.

(*) Yes, DKIM uses TXT RRs. But that's yet another orthogonal thing.
For the present discussion, just assume that the keys are in the
"correct" kind of RR.

---

From: Dave Crocker <[email-masked]>
Date: Mon, 10 Jun 2013 15:41:28 -0500

> signer's public keys. I don't know if that'd be good or bad.

This is a very specialized topic, given the overall posting, but I 
thought it worth noting for the archive that while I had missed the 
threat vector that predictable selectors pose, operators have not.

At an anti-abuse meeting last week, they were discussing selector naming 
schemes (in support of rotating keys under different selectors) that are 
less predictable, to make trolling more effort.

d/

---

From: "Rosen, Brian" <[email-masked]>
Date: Mon, 10 Jun 2013 20:47:05 +0000

ENUM does not exist.

We have an RFC, but we have essentially no deployment.

ENUM, as originally envisioned, was a public database.  That is a complete non-starter.

ENUM tried to evolve to a private database, but in most places, it was not possible to organize the relationships to make it work.

What works is number delegation, and centralized databases like the US NPAC.

The proposed basic mechanism doesn't depend on a database of certs.  The URL to the cert accompanies the signature.

One of the proposed mechanisms for handling the so-called "out of band" mechanism that gets around SS7 links and SPs that don't preserve the signed information does depend on such a database.  I think that is a weakness.  There are ways to create such a database which do not depend on DNS.

Brian

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 10 Jun 2013 16:49:22 -0400

> that has some kind of relationship to the caller. In the case of e-mail style SIP uri's the relationship

I don't know if you literally meant tel URIs, or if you just meant tel 
URI syntax, possibly in a sip uri.

For some reason I still don't grok many people seem to have an extreme 
phobia to TEL URIs. IMO they are the right thing to use if you don't 
know the domain that controls the number or if you don't care how the 
call is routed as long as it reaches something that is legitimately 
bound to that number. But it seems the fashion is most often to just 
paste the phone number onto any convenient domain that you hope has a 
clue how to handle phone numbers.

I only bring this up because we may need to consider the implications of 
one or the other. IMO sip:[email-masked] is a private uri 
belonging to example.com. It may be intended by example.com to represent 
a phone number, but I don't think anyone without special knowledge of 
example.com's policies can trust that assumption. Certainly example.com 
is free to use such a URI even if it has no rights to that phone number.

	Thanks,
	Paul

---

From: Dave Crocker <[email-masked]>
Date: Mon, 10 Jun 2013 15:50:35 -0500

On 6/10/2013 2:59 PM, Henning Schulzrinne wrote:
> legitimate spoofing

<nag>

Forgive me, but that oxymoronic phrase is not made reasonable by being 
so commonly used.  Spoofing is unauthorized use. (Mirriam Webster: 
deceive, hoax.) There is not such thing as legitimate unauthorized use.

This common mis-term has developed from a model that tries to impose 
constraints that are not valid, but rather highlight a variation from 
common practice.

The reason for nagging about the phrase is that it gets people into the 
frame of mind of thinking that the common practice actually is the 
model.  Then this inaccuracy is propagated out through the industry and 
the media.

Most of the time that people use the term, they mean something like 
'roaming use' or 'authorized third party use'.  These aren't as catchy 
as legitimate spoofing, but that have the minor benefit of being 
accurate characterizations.

</nag>

d/

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 10 Jun 2013 16:55:32 -0400

> country code).  If you have the full e.164, no problem.

Yes. The problem is if you have a number that has been prefixed in some 
way. If you know the number is from a fixed length numbering plan you 
can work right to left and figure out what the number is. But if there 
is an optional country code, or a variable length numbering plan that 
doesn't work.

	Thanks,
	Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 10 Jun 2013 16:58:00 -0400

> The proposed basic mechanism doesn't depend on a database of certs.  The URL to the cert accompanies the signature.

"The proposed basic mechanism"???

Did I miss something? Where is this proposal?

	Thanks,
	Paul

---

From: Dave Crocker <[email-masked]>
Date: Mon, 10 Jun 2013 15:58:46 -0500

> What works is number delegation, and centralized databases like the US NPAC.

Brian,

One of the things that would be especially helpful is to have consensus 
on some exemplar use cases that would aid in understanding which 
suggestions might be viable and which might not be.

It's clear that a few of you have a shared model for this activity, but 
unfortunately it hasn't been externalized, making it accessible to the 
rest of the IETF community.

So as of now, debating whether a DNS public-key mechanism is viable or 
can't be a debate.  Only one side knows the operational criteria.

d/

---

From: "Rosen, Brian" <[email-masked]>
Date: Mon, 10 Jun 2013 20:59:19 +0000

If a service let's a doctor place a call from his mobile, that appears to come from his office, then the source of the call is not actually the source of the call.  If the doctor wants that, and he and his service provider is okay with it, he can permit it, but it's still a form of intentional misdirection.  If he hid the source, that would be one thing, but if he substitutes his office for his mobile, that is identifier substitution, i.e. spoofing.

I don't really care what we call it, but it is substituting the real identifier.   The only difference between the service doing it and a scammer doing it is permission.

Brian
On Jun 10, 2013, at 4:50 PM, Dave Crocker <[email-masked]> wrote:

> Forgive me, but that oxymoronic phrase is not made reasonable by being so commonly used.  Spoofing is unauthorized use. (Mirriam Webster: deceive, hoax.) There is not such thing as legitimate unauthorized use.
> 
> This common mis-term has developed from a model that tries to impose constraints that are not valid, but rather highlight a variation from common practice.
> 
> The reason for nagging about the phrase is that it gets people into the frame of mind of thinking that the common practice actually is the model.  Then this inaccuracy is propagated out through the industry and the media.
> 
> Most of the time that people use the term, they mean something like 'roaming use' or 'authorized third party use'.  These aren't as catchy as legitimate spoofing, but that have the minor benefit of being accurate characterizations.
> 
> </nag>
> 
> 
> d/
> 
> -- 
> Dave Crocker

---

From: Stephen Farrell <[email-masked]>
Date: Mon, 10 Jun 2013 22:10:45 +0100

> We have an RFC, but we have essentially no deployment.

Fair point. OTOH, neither is there a TN-delegating RFC 5280
based PKI deployed.

I couldmaybe  buy that there'd be political issues with an ENUM
structured DNS approach. I've no idea why, nor if that'd be
fatal.

> ENUM, as originally envisioned, was a public database.  That is a complete non-starter.

Why? I mean for this application, not general phone numbers.

For this, I'd just want the signer's public key at the right
place in the DNS, where "right place" is maybe the delegation
point (sorry if that's the wrong term). Say if the caller's
phone is +353-1-896-1234 then the public key might be at
+353-1-896 in the DNS so my call from TCD to somewhere can
be signed by TCD.

And again, I'm not advocating for such a thing, just asking
why its broken.

> The proposed basic mechanism doesn't depend on a database of certs.  The URL to the cert accompanies the signature.

Sentences like that last fill me with worry. I just don't think
the PKI for that is at all easy, if its to be standardised and
work well. The RPKI has been a bunch of work and this'd be only
very slightly less IMO.

Cheers,
S.

---

From: Dan York <[email-masked]>
Date: Mon, 10 Jun 2013 21:13:29 +0000

On 6/10/13 4:59 PM, "Rosen, Brian" <[email-masked]> wrote:

>If a service let's a doctor place a call from his mobile, that appears to
>come from his office, then the source of the call is not actually the
>source of the call.  If the doctor wants that, and he and his service
>provider is okay with it, he can permit it, but it's still a form of
>intentional misdirection.  If he hid the source, that would be one thing,
>but if he substitutes his office for his mobile, that is identifier
>substitution, i.e. spoofing.
>
>I don't really care what we call it, but it is substituting the real
>identifier.   The only difference between the service doing it and a
>scammer doing it is permission.

Yes, but I agree with Dave that here is a place where words *do* matter.
Beyond the call centers and doctor example, there is also a part of the
industry building applications and other forms of automation that do
legitimately operate on behalf of the original caller, typically under
contract with that original caller.  There's a great deal of innovation
and activity happening in this space.

I really don't want to send us down a grammatical rathole, but to me,
"legitimate spoofing" casts a negative tone to this area and would be good
to be avoided.  Other options could be:

- authorized third party use
- delegated calls/calling   (thinking of the call center / app usage)
- roaming use (thinking of the doctor)
- authorized identifier substitution
- authorized identifier replacement

As Dave said in his nag, none of these are as catchy as "legitimate
spoofing", but I do think we should decide on one (of these above or that
someone else has) that we use.

My 2 cents,
Dan

--
Dan York
Senior Content Strategist, Internet Society
[email-masked] <mailto:[email-masked]>   +1-802-735-1624
Jabber: [email-masked] <mailto:[email-masked]>
Skype: danyork   http://twitter.com/danyork

http://www.internetsociety.org/deploy360/

---

From: Stephen Farrell <[email-masked]>
Date: Mon, 10 Jun 2013 22:13:55 +0100

> less predictable, to make trolling more effort.

Fair point. OTOH, for this application, if we're after "signed
by someone delegated to look after that part of the number space"
then maybe having the keys be findable could be a benefit. But
yes, very much a detail.

S.

---

From: "Rosen, Brian" <[email-masked]>
Date: Mon, 10 Jun 2013 21:26:15 +0000

Fair criticism, although use cases wouldn't help understanding why ENUM is not likely to work as part of the solution.

Here is a start

1. A robocaller on a SIP network places calls to unwitting victims where they intentionally obscure, drop or spoof the calling party number.   There is a SIP connection from end to end, although there are very often several service providers in the path.  The SP to which the robocaller is directly connected permits this use, perhaps by turning a blind eye to it rather than expressly countenancing it.  Assume that the service provider at the end of the call would be willing to check validity of the calling party identity.

2. A perpetrator places a call to a victim using the (spoofed) telephone number of the bank.  CallerId appears to be the bank.  The fisher claims the victim is the subject of an identity theft and the caller will help, but they need some verification information from the victim.  "If you could just confirm your social security number and date of birth please…".  Also SIP end to end.

3. A kid with a script fakes a call to the emergency number (1-1-2, 9-1-1, …) with a spoofed From and claims they see many armed intruders in a neighbors house.  Call out the SWAT team.  Also SIP end to end.

4. The above 3 cases where the called party is not on a SIP device, but there is a SIP path from the calling party to a vigilant service provider who is willing to verify the identity of the calling party.

5. The above 3 cases where the called party is on a SIP device (or its SP is SIP connected) but there are one or more hops where the identity authentication mechanism fails (that is, the identity or the identity checking information is dropped).  This might be an SS7 hop for example.

6. The originating and terminating end devices are SIP connected, and desire to authenticate the caller, but there are one or more hops (possibly including the first or last hops) where the identity authentication mechanism is dropped.

Brian

On Jun 10, 2013, at 4:58 PM, Dave Crocker <[email-masked]> wrote:

> One of the things that would be especially helpful is to have consensus on some exemplar use cases that would aid in understanding which suggestions might be viable and which might not be.
> 
> It's clear that a few of you have a shared model for this activity, but unfortunately it hasn't been externalized, making it accessible to the rest of the IETF community.
> 
> So as of now, debating whether a DNS public-key mechanism is viable or can't be a debate.  Only one side knows the operational criteria.
> 
> d/
> -- 
> Dave Crocker

---

From: "Rosen, Brian" <[email-masked]>
Date: Mon, 10 Jun 2013 21:40:22 +0000

I spent several years of my life flogging ENUM.

It has failed, pretty much across the board.

See the TERQ discussion for a lot of the reasons.

See inline for more
On Jun 10, 2013, at 5:10 PM, Stephen Farrell <[email-masked]>

> structured DNS approach. I've no idea why, nor if that'd be
ENUM depended on several things that turned out to be very hard to arrange:
1. The global root problem.  Using the ITU was problematic, but having said that, there isn't any other obvious answer either
2. Carrier cooperation.  Hasn't happened.
3. Regulator pressure.  Hasn't happened.  Actually the opposite - the regulator had to ask the ITU to delegate the country code.  Never happened.

> Why? I mean for this application, not general phone numbers.
Because no one wants ANY meta information about a number to actually be public.  
That is a consensus among the service providers and the regulators.  Even most privacy advocates say that.

> +353-1-896 in the DNS so my call from TCD to somewhere can
Number delegation doesn't work the way DNS works.  It's a bad fit.
You are much better off just querying a flat database.  We can do that. We have that in many countries.

> And again, I'm not advocating for such a thing, just asking
See TERQ

> work well. The RPKI has been a bunch of work and this'd be only
We have some advantages here, mostly that we have a big enough problem that workable solutions may be able to be deployed, where before they weren't.  However, we can't erase history, nor can we change fundamental things about how the number space is organized.  We can augment it, but not change it.  That's what we propose.

This is going to be a bunch of work to deploy.  No question about it.  We're looking for a path we think will succeed.  

Brian

---

From: Dan York <[email-masked]>
Date: Mon, 10 Jun 2013 21:48:04 +0000

>+353-1-896 in the DNS so my call from TCD to somewhere can

So in this scenario, the signer might be the corporate PBX, with the base
phone number at +353-1-896?

How does the validating recipient system know to query for only that part
of the phone number?  Would it need to try for the full phone number
first, then smaller parts of the number until it got back an answer?
(This would seem to introduce latency and added DNS queries.)    Or did I
miss somewhere in the 100+ messages over the last few days a suggestion
for a way to tie a part of a number to what to look up?

>And again, I'm not advocating for such a thing, just asking

I'm sure someone like Brian or Richard Shockey could give you a long list
of reasons ENUM failed.  A fundamental one to me is that a public ENUM
database gave carriers and everyone access to all the meta information
about what numbers were under a carrier's responsibility.  And it provided
a wonderful way for spammers to walk the DNS tree and build up a nice list
of everyone to bombard with telemarketing calls. (And there are a couple
of scripts out there that do exactly that.)

I realize you are not suggesting ENUM for the general case of phone
numbers, but even in an abbreviated form I think it would probably expose
far more info publicly than most people are comfortable with.

My 2 cents,
Dan

---

From: Dave Crocker <[email-masked]>
Date: Mon, 10 Jun 2013 16:53:28 -0500

Brian,

Thanks for circulating the cases.

(Purely OT:  The form of Cases 4 and 5 was interesting, by way of 
suggesting that you've been spending far too much time around patents...)

I assume that simplistic diagrams of actors for these cases is something 
like:

    PSTN>SIP G/W -->+                     +-> SIP>PSTN GW
                    |                     |
                    +-> SIP Op1..SIP OpN -+
                    |                     |
    Caller SIP UA ->+                     +- Callee SIP UA

(However I thought that SIP allows true peer-peer exchanges, too, 
without mediation by an operator?)

Using "signing" and "verifying" as generic terms here, who can do each? 
  If any SIP-related actor is prohibited, then why?

For example, I'd assume that a Callee SIP UA could do verification 
according to the architecture, even if that's not expected to be a 
typical operational mode.  If not, why not?

d/

---

From: Dave Crocker <[email-masked]>
Date: Mon, 10 Jun 2013 17:07:40 -0500

On 6/10/2013 3:59 PM, Rosen, Brian wrote:
> If a service let's a doctor place a call from his mobile, that
> appears to come from his office,

That's a reasonable description of many people's views about a phone 
number, but of course it's now quite wrong and has been for many years. 
  This demonstrates the difference between "common" and "required".

Phone numbers no longer are required to refer to a device, a geographic 
location, a network topological location or a service operator.  They've 
become a random string, whose meaning is established by use and entry 
into a database.  (Let's skip over the oddness of my reciting this to 
someone at a company that makes this fact workable.)

I made many 'local' phone calls last week, while I was in Austria.  By 
local I mean even the phone company thought I was 'home' in California. 
  They provide a WiFi-based Internet path for calls to/from my mobile 
phone and therefore don't care at all where I am physically.  (And my 
carrier charges according to home access.)

The phone number refers to the SIM card, in this case.

Had I made a call from a phone with a different SIM card but caused 
caller ID to show my original number, that would be mechanically 
interesting, but not at all interesting for the callee.  They'd see my 
number and I'm the one calling.

> scammer doing it is permission.

"real" identifier?

d/

---

From: "Rosen, Brian" <[email-masked]>
Date: Mon, 10 Jun 2013 22:09:54 +0000

Inline
On Jun 10, 2013, at 5:53 PM, Dave Crocker <[email-masked]> wrote:

> (Purely OT:  The form of Cases 4 and 5 was interesting, by way of suggesting that you've been spending far too much time around patents…)
Too true :)

> 
> I assume that simplistic diagrams of actors for these cases is something like:
> 
> 

That middle line today is often SIP Op1..Sip OpM ->SIP>PSTN GW -> SS7 -> PSTN>SIP GW -> SIP Op M+1.. SIP OpN
Most of the problem is SIP originated, PSTN terminated today, but that is changing

> 
> (However I thought that SIP allows true peer-peer exchanges, too, without mediation by an operator?)
Yeah, but that roughly never happens with telephone number based identities

> 
> Using "signing" and "verifying" as generic terms here, who can do each?  If any SIP-related actor is prohibited, then why?
In theory anyone with knowledge of the identity of the originator can sign.  In practice that means the endpoint, PBX or first SP.  Anyone can validate.
We would like to get to end to end validation, but we get a whole lot of value over any entity in the path doing the validation.  We would like to get to a state where we have SPs refusing calls from downstream SPs who don't have valid signatures. 

> 
> For example, I'd assume that a Callee SIP UA could do verification according to the architecture, even if that's not expected to be a typical operational mode.  If not, why not?
Ideally, yes.  There are discussions of how hard it is to get the information that is signed through the SIP network end to end in order that the endpoints can do the verification.  A shortcut may be to use information only visible to SPs.  I'd prefer not to do that, but it seems easier to some of the folks on the list.

A really typical path is bad guy to "pink" carrier to "green carrier" to some arbitrary path that is not all SIP.  If the "green" carrier verified, and didn't accept non valid calls from the pink SP,  it would stop the problem.  Sometimes there are a couple of SPs between pink and green (in both the call path and color).

Some of us really want the call to work if there is an SS7 hop in the middle, because that is where most calls are now.  If the carrier on the origination side of the SS7 hop verifies, great, but if all they do is pass along the verification info, we'd like to be able to have some out-of-band way to get it back.  There are a couple of ideas on how to do that.   There has been an argument that by the time we could get anything deployed, we will have eliminated that hop.  I'm sanguine about that.

---

From: Hadriel Kaplan <[email-masked]>
Date: Mon, 10 Jun 2013 18:55:00 -0400

> ENUM tried to evolve to a private database, but in most places, it was not possible to organize the relationships to make it work.

Not to pick too much on the above comment, because it doesn't matter too much in this conversation, but ISTM private use of ENUM is actually very successful.  
Hundreds of large service providers, including some of the largest mobile providers on the planet, use it a LOT, with multiple vendor implementations.
It just doesn't exit each provider's network (ie, it's neither Public nor Carrier ENUM). 

-hadriel

---

From: "Rosen, Brian" <[email-masked]>
Date: Mon, 10 Jun 2013 23:47:13 +0000

You explaining how telephone number based routing to me is like me trying to explain email routing to you :)

Typically, the SP serving the mobile is different from the one serving the office.  The mobile does not have the office number as one of the numbers in its SIM.
If the mobile has the office number in your SIM, then today, the service providers have to be the same in the office and the mobile, because today, routing of telephone number based calls depends on a mapping of telephone number to service provider.  That is mechanized in different ways in different countries often actually mapping from a telephone number to a switch owned by the SP, but increasingly, it really is mapping TN to SP Id.

If they did have the same SP, and the office number was in the SIM, then it's not spoofing at all, and the basic mechanisms we're discussing would all work fine.  The case we need extra mechanism for is when the mobile does not have the office number on its SIM, and especially the case where the mobile SP and the office SP are not the same. 

Brian

On Jun 10, 2013, at 6:07 PM, Dave Crocker <[email-masked]> wrote:

> That's a reasonable description of many people's views about a phone number, but of course it's now quite wrong and has been for many years.  This demonstrates the difference between "common" and "required".
> 
> Phone numbers no longer are required to refer to a device, a geographic location, a network topological location or a service operator.  They've become a random string, whose meaning is established by use and entry into a database.  (Let's skip over the oddness of my reciting this to someone at a company that makes this fact workable.)
> 
> I made many 'local' phone calls last week, while I was in Austria.  By local I mean even the phone company thought I was 'home' in California.  They provide a WiFi-based Internet path for calls to/from my mobile phone and therefore don't care at all where I am physically.  (And my carrier charges according to home access.)
> 
> Had I made a call from a phone with a different SIM card but caused caller ID to show my original number, that would be mechanically interesting, but not at all interesting for the callee.  They'd see my number and I'm the one calling.
> 
>

---

From: Dave Crocker <[email-masked]>
Date: Mon, 10 Jun 2013 18:50:34 -0500

> Most of the problem is SIP originated, PSTN terminated today, but that is changing

Ahh.  Right.  So, a bit of a hack to represent, but to at least touch 
the additional issue:

       +---------------------------------------------+
       |                                             ^
       V                                             |
      SS7>SIP G/W -->+                      +-> SIP>SS7 GW -+
                     |                      |               |
                     +-> SIP Op1...SIP OpN -+               +-> Callee
                     |                      |               |
     Caller SIP UA ->+                      +-> SIP UA -----+

> Yeah, but that roughly never happens with telephone number based identities

OK.  That's what I assumed.

> We would like to get to end to end validation, but we get a whole lot of value over any entity in the path doing the validation.  We would like to get to a state where we have SPs refusing calls fr…

Glad to hear this.  But of course it makes the trust model messier, 
since you don't begin with trusted actors (like operators) controlling 
things.

And it means that there's potentially a key for each number.

/And/ you want to allow signing by folk who don't 'own' the number.

> Some of us really want the call to work if there is an SS7 hop in the middle, because that is where most calls are now.  If the carrier on the origination side of the SS7 hop verifies, great, but i…

FWIW, at a coarse, architectural level, what you are describing is quite 
similar to what DKIM confronts for email, including 'gatewaying' which 
in the email case is represented by mailing list processing -- which is 
formally a delivery to the list engine and a re-posting by it.  (I did 
said 'coarse'.)  For DKIM, the current view is that mailing lists need 
to re-sign the message; that would be an SS7>SIP gateway re-signing, 
here.  But, of course, it won't have the private key of the owner of the 
number...

Perhaps the SIP/SS7/SIP sequence can preserve meta-data better than 
mailing lists, but from the traffic I've seen here, it doesn't sound 
reliable.  At a minimum, you might want to specify the core stuff 
without specifying the SS7 relaying -- include it in the thinking but 
not the formal spec -- and specify ss7 gatewaying separately.  That's 
more than a documentation nuance.

It makes for a /far/ simpler spec, because the core model is kept quite 
simple. (I've always thought that, but watching the problems in the 
recent EAI wg with this solidified the point for me.)

d/

---

From: Dan York <[email-masked]>
Date: Tue, 11 Jun 2013 00:16:41 +0000

>If they did have the same SP, and the office number was in the SIM, then
>it's not spoofing at all, and the basic mechanisms we're discussing would
>all work fine.  The case we need extra mechanism for is when the mobile
>does not have the office number on its SIM, and especially the case where
>the mobile SP and the office SP are not the same.

And let's please keep in mind that the doctor calling the patient might
not necessarily be using a mobile phone and therefore would not have
access to a SIM.  They might be using a wired phone at their home - or
they might be using a softphone on a laptop or mobile device connected in
to some VoIP system.

I'd note that today they might not have the option of presenting an
alternate number - they might opt instead to simply block their number
from appearing (what a doctor friend of mine does, which has the amusing
side effect that I pretty much always know it is her when she calls).

Dan

---

From: Dave Crocker <[email-masked]>
Date: Mon, 10 Jun 2013 19:33:09 -0500

On 6/10/2013 7:16 PM, Dan York wrote:
> alternate number -

That raises another point probably worth making explicit:  To what 
extent is the goal essentially to emulate existing PSTN functionality 
and to what extent is it providing a new capability.

Since caller id is faked today in the PSTN, I assume the intent here is 
something /better/ than exists in the current phone service.

d/

---

From: "Richard Shockey" <[email-masked]>
Date: Mon, 10 Jun 2013 20:35:13 -0400

Ah excuse me .. Why oh why does this come back to haunt me ..

Like the Godfather III movie .. " once you think you are out, they pull you
back in." 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Rosen, Brian
Sent: Monday, June 10, 2013 4:47 PM
To: Stephen Farrell
Cc: [email-masked]; Dave Crocker; <[email-masked]>
Subject: Re: [stir] DKIM-like key mgmt approach (was: Re: Can canonical
phone numbers survive SBCs and other middle boxes?)

ENUM does not exist.
[RS> ] 
[RS> ]  It bloody well does exist.. not as e164.arpa but as private
instantiations all over the place as well as a access protocol to
Centralized Routing Databases internal to service provider networks.  The IP
SCP.   SIP Redirect is currently preferred but the protocols are still built
into the CSCF's. TCAP replacement.. duh let me know I can make up T-Shirts
for Berlin  .NO TCAP.     NeuStar runs the I-TRS database for the hearing
impaired for the FCC which is entirely based on 6116.  Brian .don't go
there.   Yes your company runs a government sponsored private instantiation
of 6116.  Look it up people. 

ENUM, as originally envisioned, was a public database.  That is a complete
non-starter.
[RS> ] 
[RS> ] In .arpa sure but the protocol is still in very active use.  The ENUM
WG declared success and I'm personally proud of that.  Well now that you
kindly bring up the subject. What if .. what if you  did actually looked at
reviving .e164.arpa but only as a tree for PKI and NO session establishment
data?  Well Hummmm maybe there is merit to that idea.  The structural
separation of PKI data from the underlying national numbering databases
could offer some interesting alternatives. Worth thinking about. Worth
discussing .. 

Granted I have some serious scars from the E2MD BOF's in 2010 but ..

Well it might be worth a trial .. WOW. Gee I think I need to make a filing
with the FCC as part of their DA 13-1016 filing.  

http://www.fcc.gov/document/technology-transitions-policy-task-force-seeks-c
omment-trials

Great Idea Brian thanks for the suggestion.  What a guy!!!  You are the
best! 

ENUM tried to evolve to a private database, but in most places, it was not
possible to organize the relationships to make it work.

The proposed basic mechanism doesn't depend on a database of certs.  The URL
to the cert accompanies the signature.

One of the proposed mechanisms for handling the so-called "out of band"
mechanism that gets around SS7 links and SPs that don't preserve the signed
information does depend on such a database.  I think that is a weakness.
There are ways to create such a database which do not depend on DNS.

Brian
On Jun 10, 2013, at 4:21 PM, Stephen Farrell <[email-masked]>
wrote:

>> (Just to be clear, I'm suggesting consideration of an approach; I'm 
>> not sure it's the best one and I'm therefore not pushing for its 
>> adoption, merely that it be explored.)
>> 
> issues on the basis that those robocallers aren't gonna MITM or poison 
> DNS at the verifier.
> 
> While its not quite the same in this context, it may be that one could 
> argue that a reasonable threat model would not require the signature 
> verifier (someone/thing en-route to the callee) to strongly verify the 
> signing public key.
> 
> (Ok, I can't resist adding a feature:-) If the DKIM key selector were 
> modified (to put it in the key value) then you might also get some 
> level of traceability in that one could trawl the DNS for signer's 
> public keys. I don't know if that'd be good or bad.
> 
> Anyway, for now, can we make sure this gets discussed before we plump 
> for any specific key management solution? That could be now, or at a 
> DISPATCH session or BoF or after a WG is chartered, I don't mind, so 
> long as it is properly considered.
> 
> S.
>

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 11 Jun 2013 01:52:43 +0100

FWIW - I have no idea how to interpret Rich's message
and as a result am also unsure how to interpret Brian's.
And that's about the 5th or 6th overly cryptic mail like
that in the last few days from various folks on this
list. So this isn't really aimed at either Brian or
Rich but is a general plea for clarity.

I'm sure there are a bunch of people on here who have
all the context for all this. But I'm not one of 'em.
And I bet I'm not alone.

Assuming a homogeneous audience who all share the same
painful history is yet another way to bugger up a BoF in
my experience. Just sayin.

S.

---

From: "Richard Shockey" <[email-masked]>
Date: Mon, 10 Jun 2013 21:07:55 -0400

Dave both..  we have to preserve protect and defend the existing structure
until the time comes for a real Transition and that time is now. 

 In short we .. The IETF won.  

There are no "flash cuts" here we have to Transition.  The US and the NANP
are going to have to deal with this first since the level of SIP in the US
and Canada network is pretty amazing. 

We, the IETF,  are now the actual stewards of the Public SIP Telephony
network. PSTN by another name. 

We want E.164 identifiers to link to advanced classes of services for all of
all types including P2P video etc and an all the things Unified
Communications promised for the last decade including a host of real M2M
applications as well.  This is not a national specific task. Though  there
are endless issues the IETF is not competent to address such as ICC/USF EC
based roaming charges and endless national specific issues. We do tools.
This work is part of that. 

E.164 identifiers are a great tool for lots of things no one has though of
.. this work is useful.  

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Dave
Crocker
Sent: Monday, June 10, 2013 8:33 PM
To: Dan York
Cc: Rosen, Brian; [email-masked]
Subject: Re: [stir] Can canonical phone numbers survive SBCs and other
middle boxes?

> I'd note that today they might not have the option of presenting an 

That raises another point probably worth making explicit:  To what extent is
the goal essentially to emulate existing PSTN functionality and to what
extent is it providing a new capability.

d/

---

From: Dan York <[email-masked]>
Date: Tue, 11 Jun 2013 01:51:45 +0000

Dave,

>something /better/ than exists in the current phone service.

Yes, the overall goal is to get to "caller ID" that is secure and can't be
faked. That is something *better* than what we have today.

Now, separately, my note was about the doctor wanting to make a call from
his/her mobile and present a number from his/her office.  This may be a
desired behavior but also may or may not be something that is commonly
available today - largely depending upon the doctor's setup and how he/she
is integrated with it.

There certainly *are* today contact centers that legitimately present
themselves as having the phone number of the
organization/company/enterprise for whom they are contracted.  And there
are application servers that legitimately present themselves as calling
from the number of the org/company/enterprise.  Both of those are  very
common cases where an entity is either making or receiving calls on behalf
of some other entity and is presenting the identification of the other
entity.

That is again *existing* functionality that we want to ensure continues to
work in a new setup.

Dan

---

From: Dave Crocker <[email-masked]>
Date: Mon, 10 Jun 2013 22:07:35 -0500

On 6/10/2013 8:51 PM, Dan York wrote:
> That is again*existing*  functionality that we want to ensure continues to
> work in a new setup.

To be pedantic about this, for the record:

      The goal is to preserve existing flexibility in assigning the 
caller id, but to add a mechanism -- not present in the current PSTN -- 
that permits handling agents to validate the use of the id.

d/

---

From: Hadriel Kaplan <[email-masked]>
Date: Tue, 11 Jun 2013 00:31:33 -0400

Well, it's a sensitive topic because in some ways and for some of us ENUM was a miserable failure, and for others a wild success.  I don't know how much context/background you need though.  I mean I don't know how much you don't already know, or what is useful to know.

Some background on the current state of ENUM as I see it:
As originally described/envisioned ENUM was just a usage of DNS, as you know... which from the IETF's perspective means 'The DNS', and thus not only the protocol but also the architecture and massive DNS deployment, query-able by any host on the Internet, etc.  This is what most people call "Public ENUM".  It was a miserable failure.

However, as DNS the *protocol* for querying numbers and getting back URIs and other stuff for various purposes, ENUM is very successful.  It's just that the "DNS" servers being queried for ENUM purposes are not in any way tied into 'The DNS', but are simply servers owned by the same service provider that owns the equipment performing the queries, and are not publicly reachable.  That's 'Private ENUM'.  It's only within Service Providers, not in Enterprises... think of it as the Service Provider's version of LDAP.

There is also 'Carrier ENUM' which is pseudo-private, in the sense that the servers are still not part of The DNS and are only query-able from certain providers based on a federation or some form of common agreement/relationship.  Carrier ENUM exists, but is not very successful afaik.

Some background on using ENUM for Caller-ID verification:
The topic has come up before, although I don't know if Rich or Brian remember it.  It was discussed about 5 years ago, back when we had massive email threads about the many SIP Identity problems/solutions on the mailing lists.

There were even some drafts about it...
This one discussed the general problem area:
http://tools.ietf.org/html/draft-schwartz-sip-e164-ownership-01

And this one discussed using ENUM/DNS for a PKI:
http://tools.ietf.org/html/draft-darilion-sip-e164-enum-00

-hadriel

---

From: "Olle E. Johansson" <[email-masked]>
Date: Tue, 11 Jun 2013 07:49:37 +0200

> of the call (ideally the end device, but perhaps the termination SP).

Great. Have we defined "service provider" ?

I see call centers suddenly starting to sell SIP trunks.

/O

---

From: Michael Hammer <[email-masked]>
Date: Tue, 11 Jun 2013 06:42:51 +0000

All these use cases suggest that the original caller is the perp.
Do you have a use case where the original caller is not the perp?

Part of my issue is the complexity being introduced on the network
components that would likely bog everything down.
Hence, my trying to focus on where the perp likely is.

Mike

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Rosen, Brian
Sent: Tuesday, June 11, 2013 12:26 AM
To: <[email-masked]>
Cc: [email-masked]; Stephen Farrell
Subject: Re: [stir] DKIM-like key mgmt approach

Fair criticism, although use cases wouldn't help understanding why ENUM is
not likely to work as part of the solution.

Here is a start

1. A robocaller on a SIP network places calls to unwitting victims where
they intentionally obscure, drop or spoof the calling party number.   There
is a SIP connection from end to end, although there are very often several
service providers in the path.  The SP to which the robocaller is directly
connected permits this use, perhaps by turning a blind eye to it rather than
expressly countenancing it.  Assume that the service provider at the end of
the call would be willing to check validity of the calling party identity.

2. A perpetrator places a call to a victim using the (spoofed) telephone
number of the bank.  CallerId appears to be the bank.  The fisher claims the
victim is the subject of an identity theft and the caller will help, but
they need some verification information from the victim.  "If you could just
confirm your social security number and date of birth please.".  Also SIP
end to end.

3. A kid with a script fakes a call to the emergency number (1-1-2, 9-1-1,
.) with a spoofed From and claims they see many armed intruders in a
neighbors house.  Call out the SWAT team.  Also SIP end to end.

4. The above 3 cases where the called party is not on a SIP device, but
there is a SIP path from the calling party to a vigilant service provider
who is willing to verify the identity of the calling party.

5. The above 3 cases where the called party is on a SIP device (or its SP is
SIP connected) but there are one or more hops where the identity
authentication mechanism fails (that is, the identity or the identity
checking information is dropped).  This might be an SS7 hop for example.

6. The originating and terminating end devices are SIP connected, and desire
to authenticate the caller, but there are one or more hops (possibly
including the first or last hops) where the identity authentication
mechanism is dropped.

Brian

On Jun 10, 2013, at 4:58 PM, Dave Crocker <[email-masked]> wrote:

>> ENUM tried to evolve to a private database, but in most places, it was
not possible to organize the relationships to make it work.
> One of the things that would be especially helpful is to have consensus on
some exemplar use cases that would aid in understanding which suggestions
might be viable and which might not be.
> It's clear that a few of you have a shared model for this activity, but
unfortunately it hasn't been externalized, making it accessible to the rest
of the IETF community.

---

From: "Hutton, Andrew" <[email-masked]>
Date: Tue, 11 Jun 2013 08:19:00 +0000

> network. PSTN by another name.

Just to be clear that is the WWPSTN "World Wide Public SIP Telephony Network" which I would shorten to WWSN or "World Wide SIP Network" as although the US/Canada may currently have a large slice of the WWSN the callerid problems are international. I am well aware from my own experience that a large percentage of nuisance calls in the UK don't originate in the UK.

Therefore any solution to this problem has to address the international case.

Andy

---

From: "Hutton, Andrew" <[email-masked]>
Date: Tue, 11 Jun 2013 08:41:43 +0000

> Olle E. Johansson
> Sent: 11 June 2013 06:50
> To: Brian Rosen; [email-masked]
> Cc: Olle E. Johansson

Yes one of the first things to do is to agree on terminology and probably at least for the IETF "Service Provider" is not the best choice. I am not sure of the correct terminology but we are probably talking about any trust boundary between SIP entities. Actually in IETF terms aren't we simply talking about UAC's and UAS's and maybe there is no need to define the term "Service Provider" in the IETF work.

Andy

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 11 Jun 2013 10:58:16 +0100

Thanks. That (and the terq draft [1]) were useful reads
for me.

S.

[1] http://tools.ietf.org/html/draft-peterson-terq-03

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 11 Jun 2013 11:19:24 +0100

So just following up on this to try to better understand
where it falls over... (there is a point to that, see the
end of this mail.)

For now, I'll stick with assuming public ENUM even if its
mythical since I think it has enough in common with any
public key retrieval mechanism for the current discussion.

> for a way to tie a part of a number to what to look up?

Speculating, let's say that the signed blob identifies the
signer by annotating the caller number, e.g. "+353-1-896/-1234"
where the "/" means that the signer is named in public ENUM
using the parts of the number to the left of the "/" i.e. in
this case that'd mean "+353-1-896" is the signer and I
should lookup _stirkey.6.9.8.1.3.5.3.e164.arpa (or similar)
to find the public key.

Anyway, my question then is: with that setup and a sensible
signature format, why doesn't that work for the use-cases
that Brian enumerated?

If the only reason this fails is that it requires a publicly
accessible database that exposes the binding between keys and
sets of caller numbers, then I think any 5280-based solution
will have the same problem, even if that's less obvious.

For example, the SSL observatory [1] has built up an ~11million
entry DB of TLS server certs. That plus another ~4million
SSH host keys [2] were used to detect some badness in key
generation (probably from embedded devices with bad PRNGs).
For DKIM, I don't know that someone's built up such a DB,
but there'd be nothing much stopping anyone who sees a bunch
of email doing so if they wanted to. And we're even starting
to see benefits from such large databases of public keys,
e.g. RFC 6962 is one experimental spec for a way to use
such a beast to mitigate bad CA (diginotar-like) behaviour.

And similarly, for stir, anyone who takes a bunch of calls
(or instruments a UAC to send reports of certs to a central
place) could do the same.

So it seems to me that its just in the nature of public key
crypto that if you deploy this, then someone can build up
that DB of public-keys-or-certs vs. caller-numbers. Or if
you set a hard requirement to avoid that, then lots of new
work would be needed to develop a PKI that tries to make
that hard.

Cheers,
S.

[1] https://www.eff.org/observatory
[2]
https://freedom-to-tinker.com/blog/nadiah/new-research-theres-no-need-panic-over-factorable-keys-just-mind-your-ps-and-qs/

---

From: Henning Schulzrinne <[email-masked]>
Date: Tue, 11 Jun 2013 07:53:52 -0400

I agree that the name "legitimate spoofing" is pejorative.

An alternate way of thinking about this is that a single number has multiple legitimate assignees. From a technical perspective and the callee, they are all the same. (I don't think we want the callee to be able to detect, for example, that it was the doctor rather than the office, calling.)

From a legal perspective, there's probably a principal that controls who else is on the "lease" and can revoke access. I think that's closer to the reality than implying some kind of OAuth model. As a very rough analogy, I'm thinking of a lease for an apartment or a bank account - in day-to-day affairs, all parties on the document are treated the same. 

If we keep this multiplicity in mind, we may not need elaborate terminology since, technically, they are all the same.

Henning

---

From: "Rosen, Brian" <[email-masked]>
Date: Tue, 11 Jun 2013 12:58:59 +0000

Inline for a little bit of info
On Jun 10, 2013, at 7:50 PM, Dave Crocker <[email-masked]> wrote:

> Ahh.  Right.  So, a bit of a hack to represent, but to at least touch the additional issue:
> 
> Glad to hear this.  But of course it makes the trust model messier, since you don't begin with trusted actors (like operators) controlling things.
Delegation is reasonably trustworthy - at least you can hold the delegator responsible.  The reason this is true is that there is a delegation from a number authority to a service provider that has some form of official recognition, and that entity has permission to enter calls into the PSTN.   That means it is subject to about as much regulation as possible.  If that entity delegates downward, the it can hold it's delegates to account, less it be left holding the bag.  Requiring the delegator to issue a cert is the new part.  If the delegator doesn't handle it's private key securely, then a compromise of that part of the number space is possible, but it's limited to what it has been delegated.  It would be better if the delegator contracted with an entity that was good at the job of being a CA, but we can't guarantee that will happen.

> And it means that there's potentially a key for each number.
Yes, we're heading in that direction, primarily due to number portability.  
> /And/ you want to allow signing by folk who don't 'own' the number.
Well, the whole scheme is authority to sign is delegated.  If an entity that 'owns' the number authorizes someone else to use it, it would be a form of delegation.  It would use it's key to issue a cert to the authorized entity.  In practice, that may be that the SP serving the end user is asked to issue that cert by the end user.  That looks like another level of delegation, which is just fine.

Some believe we should have other forms of certs in the system.  For example, someone proposed a "green carrier" cert that would work for all of calls it originates.  Others think that is not implementable (because it's too hard draw the line between a green carrier and a not-so-green one).  There are other thoughts of giving certs to thinks like border elements who get calls that are unsigned.  They could sign them with a cert that was "I don't know what happened before me, but here is what I got for an identity, and I'll sign it so it can be checked from here forward. That probably wouldn't be all that useful for the problem at hand.

> FWIW, at a coarse, architectural level, what you are describing is quite similar to what DKIM confronts for email, including 'gatewaying' which in the email case is represented by mailing list processing -- which is formally a delivery to the list engine and a re-posting by it.  (I did said 'coarse'.)  For DKIM, the current view is that mailing lists need to re-sign the message; that would be an SS7>SIP gateway re-signing, here.  But, of course, it won't have the private key of the owner of the number…
Yeah, sort of, if you squint hard enough.  I don't think the analogy is good enough though.  DKIM doesn't have a real delegation model like this one.

> 
> Perhaps the SIP/SS7/SIP sequence can preserve meta-data better than mailing lists, but from the traffic I've seen here, it doesn't sound reliable.  At a minimum, you might want to specify the core stuff without specifying the SS7 relaying -- include it in the thinking but not the formal spec -- and specify ss7 gatewaying separately.  That's more than a documentation nuance.
There is no doubt we need to get the basic mechanism done first.  There is wide agreement that there are two separate mechanisms, with separate documents.
> 
> It makes for a /far/ simpler spec, because the core model is kept quite simple. (I've always thought that, but watching the problems in the recent EAI wg with this solidified the point for me.)
We agree I believe

---

From: "Rosen, Brian" <[email-masked]>
Date: Tue, 11 Jun 2013 13:10:55 +0000

Yeah, you are correct.  It's one of the reasons we need to bring PBX/Sip Trunk into this discussion.  The notion of "Service Provider" is broad.  I'm not sure we need a new term, but it's not equivalent to "carrier".   It's any independent SIP or SS7 entity in the path.

Another way to look at it, it's any entity that might get a visit from a law enforcement agency tracking an illegal robocall/vish/swat that had a downstream entity they could pass the LE agency off on by showing the LE that identity was good when it got to the "SP".

Brian

---

From: "Rosen, Brian" <[email-masked]>
Date: Tue, 11 Jun 2013 13:13:02 +0000

I'm still okay with service provider.  It's not UAC/UAS for sure - a service provider that only had proxies could verify, and they could be in the delegation chain.

"Trust boundaries" is getting at the idea.

Brian

---

From: "Rosen, Brian" <[email-masked]>
Date: Tue, 11 Jun 2013 13:33:29 +0000

1. Number delegation doesn't follow a tree.  You can be delegated 25 numbers in a range.  We are rapidly evolving to a delegation of 1 number.  The tree than ENUM gives you doesn't match the delegation model, and thus the cert model.  You can force fit it by just expanding the whole tree out, but that is inefficient and silly.  We know how to do a simple web service query with a telephone number and return an answer.  Don't make things more complicated.
2. The global root of the tree (e164.arpa) has been a nightmare
3. SIP Identity sends the URI of the cert in the signaling with the call.  You don't need a database to retrieve it.  One of the proposed additional mechanisms did need a way for the originator to discover the cert for the termination.  
4. Unless there is some entity in a country that actually issues ALL the certs, putting the certs in a publicly accessible database raises privacy and business concerns that I (and a lot of other people) think are insurmountable.  You can't be able to tell which SP serves which numbers.  That might change over time, but right now, it's impossible.  I understand your observation about building up a DB of certs.  I expect it to happen.  But making the DB public today is a non-starter.  

Brian

---

From: Dave Crocker <[email-masked]>
Date: Tue, 11 Jun 2013 07:25:18 -0700

On 6/11/2013 5:58 AM, Rosen, Brian wrote:
>> since you don't begin with trusted actors (like operators)
>> controlling things.
>>
> Delegation is reasonably trustworthy - at least you can hold the
> delegator responsible.

I think I've heard different assertions of requirement on the list about 
that.

What you cite here is 'accountability', which means the ability do to 
post hoc (after the problem) followup.  I've heard others cite 
'prevention' as the requirement, which means a pre hoc capability.

Of course, these are hugely different constraints, with that latter 
being far more onerous, or at least technically and operationally demanding.

> The reason this is true is that there is a
> delegation from a number authority to a service provider that has
> some form of official recognition, and that entity has permission to
> enter calls into the PSTN.

This gets back to a question that has come up a few times:  Does the 
trust model encompass -- or, at least, rely on -- only a relatively 
small number of specially-authorized operators, who are very highly 
vetted and accountable; or does it potentially encompass anyone with a 
SIP client?  This is why I've pressed for clarifying the statement and 
depiction about actors in the STIR scenario.  I think you suggest the 
answer a bit farther down, but I wanted to call out the core question here.

If the requirement is to permit a calling SIP UA to assert the ID, then 
the set of participants is billions and accountability is an entirely 
different game.  An intermediate place is a model of ID assertion by any 
"organization"; that is, anyone operating a SIP server along the path. 
It could still be far more unruly that limiting to a relatively tiny, 
regulated core, but it's some orders of magnitude smaller than "everyone 
and every device".

Your note saying, "the notion of 'Service Provider' is broad.  I'm not 
sure we need a new term, but it's not equivalent to 'carrier'.   It's 
any independent SIP or SS7 entity in the path." frankly appears to match 
the current email operational model...

(By way of comparison, DKIM's architectural model allows anyone along 
the path to sign, including the author's UA; however the ID is a domain 
name, which best scales to hosts and not users -- generally.)

> That means it is subject to about as
> much regulation as possible.If that entity delegates downward, the
> it can hold it's delegates to account, less it be left holding the
> bag.

This excludes a true peer-to-peer operation, without regulated service 
providers.  I thought an earlier posting said the goal was to include P2P.

> Requiring the delegator to issue a cert is the new part.  If
> the delegator doesn't handle it's private key securely, then a
> compromise of that part of the number space is possible, but it's
> limited to what it has been delegated.  It would be better if the
> delegator contracted with an entity that was good at the job of being
> a CA, but we can't guarantee that will happen.
>
>>

dandy.

> Well, the whole scheme is authority to sign is delegated.  If an entity that 'owns' the number authorizes someone else to use it, it would be a form of delegation.  It would use it's key to issue a…

OK. This defines a trust model comprising a core of regulated and highly 
accountable operators that provide a base of assurance, but permitting 
delegation of trust down a hierarchy.  That seems to be different than 
your statement that I quoted, above.

However it does seem to match the current PSTN global model, but that it 
excludes true P2P.

> Some believe we should have other forms of certs in the system.  For example, someone proposed a "green carrier" cert that would work for all of calls it originates.  Others think that is not imple…

This moves the trust question from "assertion by fiat involving 
regulation" to one of "reputation".  Again, these impose vastly 
different design and operation requirements.

> Yeah, sort of, if you squint hard enough.  I don't think the analogy is good enough though.  DKIM doesn't have a real delegation model like this one.

It delegates name authentication, but not trust.  DKIM doesn't assert 
trust, except for a signer's assertion of the name.  Trust is an overlay 
mechanism, built up from the validation of the (domain) name use.

A detriment to that model is the need to then define the trust overlay. 
  The benefit of that model is that it allows exploring different 
instantiations of the trust layer.  Where trust is a complex topic, 
that's a win.  It might also be a necessity.

One concern is that efforts to create explicit 'trust' mechanisms over 
the global/public Internet has generally been highly problematic. Hence 
reliance on a model with a small, regulated core is appealing, but only 
if it really is the required long-term model.  As I've noted, I think 
some folk are asserting expectations that seems to call that model into 
question.  (For this round, I'm not trying to express my own 
architectural preferences, but merely get clarity on what's being said.)

>> It makes for a /far/ simpler spec, because the core model is kept quite simple. (I've always thought that, but watching the problems in the recent EAI wg with this solidified the point for me.)

uh oh...

d/

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 11 Jun 2013 15:45:33 +0100

Hi Brian,

So I didn't hear you say that the scheme outlined failed to
meet the use-cases other than in respect of the public key
retrieval aspect. That seems to imply that the role of any
CAs in a PKI here may differ a lot from e.g. TLS. Or to put
it another way, the level of assurance for public keys
needed may well be pretty modest, if the threat model does
not need to consider an on-path, MITM-type attacker.

I'm also confused as to why its a non-starter to have a
public database of public keys and phone numbers, but is ok
that anyone can build that database themselves, with fairly
modest effort. That seems odd to me anyway. (To be clear,
I do consider de-referencing a URL for a public key or
cert as a DB-lookup.)

My conclusion so far is that this effort should be quite
careful to not require a complex PKI if that's not really
needed.

S.

---

From: "Hutton, Andrew" <[email-masked]>
Date: Tue, 11 Jun 2013 14:53:21 +0000

Well I think we need to talk in terms of SIP entities and "service provider" is not really one and if we use that term then many companies might think the work does not apply to them when it really does.

Agree with your comments on proxies which can of course verify identity and we would need procedures to describe proxy behavior.

Regards
Andy

> Sent: 11 June 2013 14:13
> To: Hutton, Andrew
> Cc: Olle E. Johansson; Rosen, Brian; [email-masked]
> I'm still okay with service provider.  It's not UAC/UAS for sure - a
> service provider that only had proxies could verify, and they could be
> in the delegation chain.
> 
> Of
> >>> than a 100% check, and I think we would see 100% verification at
> the
> >> end
> > Yes one of the first things to do is to agree on terminology and
> probably at least for the IETF "Service Provider" is not the best
> choice. I am not sure of the correct terminology but we are probably
> talking about any trust boundary between SIP entities. Actually in IETF
> terms aren't we simply talking about UAC's and UAS's and maybe there is
> no need to define the term "Service Provider" in the IETF work.
> >
> >
> > Andy
> >
> >>
> >> /O

---

From: "Rosen, Brian" <[email-masked]>
Date: Tue, 11 Jun 2013 15:13:51 +0000

Our GOAL is to have valid identity put on the call at the outset, and at least potentially verifiable all along the path.  The GOAL is end to end verifiability.

To solve the immediate problem, it doesn't have to be end to end.  An SP early on the path may be able to add the identity.  It can to be some entity in the middle rejecting the call because it does not have a good identity.

We delegate numbers now.  This works well enough.  Delegation is changing (slowly), because we have more players.   Delegation works because the upstream entity gets a relatively large block of numbers, and then resells some smaller block of numbers to the downstream entity.   It's used the case that the initial delegation from the national number authority was very large (10,000 numbers for example). Today, it's common to get 1,000 at a time, but that is changing and soon the size of the allocation may be completely variable, or at least very variable, down to a request for one number.

Right at the moment, in nearly every case, the call path mirrors the delegation path.  That won't be true for much longer - some entities may be able to get numbers from the national number plan without having the call path mirror the delegation path and service providers of all kinds are making arrangements to exchange traffic that effectively short circuits the delegation path.  Need to keep that in mind.

Ultimately, delegation is traceable, although it's hard to do the trace.  However, at every step, there is some kind of transaction where the upstream entity grants the downstream entity use of a set of numbers.  Delegation works right down to the end user (which is a delegation of 1 number, recognizing that a PBX could be considered an "end user" and have more than one number delegated to it.   It really is very reasonable to enhance this delegation with certs.  When you get a cert from the upstream entity, it's proof that the transaction took place, and you are authorized to use the numbers.  "Trust" doesn't really mean much at this stage.  The cert is good proof if the keys are managed well, and it's meaningless if the keys are compromised.  There is a chain of keys, matching the delegation.  This is a pretty simple model, based on an existing, working process.  If the national number authority controls its process well enough, then misuse of keys is traceable down the chain to some point where someone has not handled their keys well.  The remedy is to invalidate the chain at that point, which only affects the number space below that point.  If the size of the original delegation is relatively small, that's a small set of numbers that have to have certs revoked and new ones issued.  This is going to happen, a bunch of times, until the SPs learn to handle their keys appropriately (probably by outsourcing).  But the scale of the problem introduced is small, and the fix is fairly simple to deploy.

I propose not to "trust" SPs.  We're going to issue certs matching number delegation and then check to make sure that the calls are signed with matching certs and keys.  A pink SP can not issue certs and accept calls from its customers unsigned.  Hopefully, its peers will refuse its calls.  The pink SP can issue certs for numbers it is delegated without regard to how those numbers are delegated by it.  If the cops come calling, following the chain, they will arrive at the pink SP, who can then decide what it will do when the "wrong" delegate was issued a cert and placed the call.  The pink cert can hand its private key out.  Same issue - the cops come to them following the chain.  Wherever there is a compromise, we can follow the chain to some entity that has not done the right thing.  The regulator or LE may be able to stop bad behavior, or the upstream entity might refuse calls from that SP, but only numbers delegated to that SP are open to abuse.  A fortunate observation is that most of the pink SPs don't get a small number of relatively large delegations - they get a large number of relatively small delegations.  This limits the size the problem introduced by a single key compromise.  If the SP has a database of keys, and the database is compromised, the problem is of course larger.

This process does not match any existing model I think.  It's not a "trust" model in the classical sense, and it's not a reputation model, although it has elements of both.

The delegation (and certs) can continue right down to the end user.  We don't trust them any more than we trust the SPs, but we can verify that they have gotten the number through a chain of delegations.  The chain could be compromised, as above.

Brian

On Jun 11, 2013, at 10:25 AM, Dave Crocker <[email-masked]> wrote:

> I think I've heard different assertions of requirement on the list about that.
> 
> What you cite here is 'accountability', which means the ability do to post hoc (after the problem) followup.  I've heard others cite 'prevention' as the requirement, which means a pre hoc capability.
> 
> Of course, these are hugely different constraints, with that latter being far more onerous, or at least technically and operationally demanding.
> 
> 
> This gets back to a question that has come up a few times:  Does the trust model encompass -- or, at least, rely on -- only a relatively small number of specially-authorized operators, who are very highly vetted and accountable; or does it potentially encompass anyone with a SIP client?  This is why I've pressed for clarifying the statement and depiction about actors in the STIR scenario.  I think you suggest the answer a bit farther down, but I wanted to call out the core question here.
> 
> If the requirement is to permit a calling SIP UA to assert the ID, then the set of participants is billions and accountability is an entirely different game.  An intermediate place is a model of ID assertion by any "organization"; that is, anyone operating a SIP server along the path. It could still be far more unruly that limiting to a relatively tiny, regulated core, but it's some orders of magnitude smaller than "everyone and every device".
> 
> Your note saying, "the notion of 'Service Provider' is broad.  I'm not sure we need a new term, but it's not equivalent to 'carrier'.   It's any independent SIP or SS7 entity in the path." frankly appears to match the current email operational model...
> 
> (By way of comparison, DKIM's architectural model allows anyone along the path to sign, including the author's UA; however the ID is a domain name, which best scales to hosts and not users -- generally.)
> 
> 
> This excludes a true peer-to-peer operation, without regulated service providers.  I thought an earlier posting said the goal was to include P2P.
> 
> 
> OK. This defines a trust model comprising a core of regulated and highly accountable operators that provide a base of assurance, but permitting delegation of trust down a hierarchy.  That seems to be different than your statement that I quoted, above.
> 
> However it does seem to match the current PSTN global model, but that it excludes true P2P.
> 
> 
> This moves the trust question from "assertion by fiat involving regulation" to one of "reputation".  Again, these impose vastly different design and operation requirements.
> 
> 
> It delegates name authentication, but not trust.  DKIM doesn't assert trust, except for a signer's assertion of the name.  Trust is an overlay mechanism, built up from the validation of the (domain) name use.
> 
> A detriment to that model is the need to then define the trust overlay.  The benefit of that model is that it allows exploring different instantiations of the trust layer.  Where trust is a complex topic, that's a win.  It might also be a necessity.
> 
> One concern is that efforts to create explicit 'trust' mechanisms over the global/public Internet has generally been highly problematic. Hence reliance on a model with a small, regulated core is appealing, but only if it really is the required long-term model.  As I've noted, I think some folk are asserting expectations that seems to call that model into question.  (For this round, I'm not trying to express my own architectural preferences, but merely get clarity on what's being said.)
> 
>

---

From: "Rosen, Brian" <[email-masked]>
Date: Tue, 11 Jun 2013 15:33:06 +0000

There certainly are people involved who want the result to stop MITM attacks, but it's not the stated problem.

I agree that the level of assurance for public keys needed is pretty modest.  See the reply I just sent to Dave.

Telephone number assignment has been around for a century.  It's built up a lot of infrastructure, regulation, bureaucracy and custom.  It has continuously evolved, and it's still evolving.  But there are things that are still hard to do.  Public databases of information about telephone numbers is currently a taboo.  That may change.  However, that's where we are today.    I really don't want to put changing that taboo in the way of succeeding.  Please?

Brian

---

From: "Richard Shockey" <[email-masked]>
Date: Tue, 11 Jun 2013 11:57:28 -0400

+1 exactly .. plus do remember we tried to extend the E2U model in ENUM to
E2MD  metadata at a couple of BOF's in 2010 and that got shredded pretty
quickly.  We know the limitations of ENUM and the DNS in general.  I fully
accept that.  As Hadriel points out 6116 as a replacement for TCAP queries
works wonders for the IMS/CSCF but so does SIP Redirect.  

Time it seems opens all old wounds.  

IMHO TERQ is a non starter here since the timelines for actually completing
that idea will not rationally match any real world need.  Maybe some time in
the distant future it will not solve the immediate problem we are presented
with. 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Hadriel Kaplan
Sent: Tuesday, June 11, 2013 12:32 AM
To: Stephen Farrell
Cc: [email-masked]
Subject: Re: [stir] clarity (was: Re: DKIM-like key mgmt approach)

Well, it's a sensitive topic because in some ways and for some of us ENUM
was a miserable failure, and for others a wild success.  I don't know how
much context/background you need though.  I mean I don't know how much you
don't already know, or what is useful to know.

Some background on the current state of ENUM as I see it:
As originally described/envisioned ENUM was just a usage of DNS, as you
know... which from the IETF's perspective means 'The DNS', and thus not only
the protocol but also the architecture and massive DNS deployment,
query-able by any host on the Internet, etc.  This is what most people call
"Public ENUM".  It was a miserable failure.

However, as DNS the *protocol* for querying numbers and getting back URIs
and other stuff for various purposes, ENUM is very successful.  It's just
that the "DNS" servers being queried for ENUM purposes are not in any way
tied into 'The DNS', but are simply servers owned by the same service
provider that owns the equipment performing the queries, and are not
publicly reachable.  That's 'Private ENUM'.  It's only within Service
Providers, not in Enterprises... think of it as the Service Provider's
version of LDAP.

There is also 'Carrier ENUM' which is pseudo-private, in the sense that the
servers are still not part of The DNS and are only query-able from certain
providers based on a federation or some form of common
agreement/relationship.  Carrier ENUM exists, but is not very successful
afaik.

Some background on using ENUM for Caller-ID verification:
The topic has come up before, although I don't know if Rich or Brian
remember it.  It was discussed about 5 years ago, back when we had massive
email threads about the many SIP Identity problems/solutions on the mailing
lists.

-hadriel

On Jun 10, 2013, at 8:52 PM, Stephen Farrell <[email-masked]>
wrote:

> 
> FWIW - I have no idea how to interpret Rich's message and as a result 
> am also unsure how to interpret Brian's.
> And that's about the 5th or 6th overly cryptic mail like that in the 
> last few days from various folks on this list. So this isn't really 
> aimed at either Brian or Rich but is a general plea for clarity.
> 
> I'm sure there are a bunch of people on here who have all the context 
> for all this. But I'm not one of 'em.
> And I bet I'm not alone.
> 
> Assuming a homogeneous audience who all share the same painful history 
> is yet another way to bugger up a BoF in my experience. Just sayin.
> 
> S.
> 
>> Like the Godfather III movie .. " once you think you are out, they 
>> pull you back in."
>> 
>> Subject: Re: [stir] DKIM-like key mgmt approach (was: Re: Can 
>> canonical phone numbers survive SBCs and other middle boxes?)
>> 
>> ENUM does not exist.
>> [RS> ]
>> [RS> ] In .arpa sure but the protocol is still in very active use.  
>> The ENUM WG declared success and I'm personally proud of that.  Well 
>> now that you kindly bring up the subject. What if .. what if you  did 
>> actually looked at reviving .e164.arpa but only as a tree for PKI and 
>> NO session establishment data?  Well Hummmm maybe there is merit to 
>> that idea.  The structural separation of PKI data from the underlying 
>> national numbering databases could offer some interesting 
>> alternatives. Worth thinking about. Worth discussing ..
>> 
>> Well it might be worth a trial .. WOW. Gee I think I need to make a 
>> filing with the FCC as part of their DA 13-1016 filing.
>> 
>> Great Idea Brian thanks for the suggestion.  What a guy!!!  You are 
>> the best!
>> 
>> 
>> 
>> ENUM tried to evolve to a private database, but in most places, it 
>> was not possible to organize the relationships to make it work.
>> 
>> The proposed basic mechanism doesn't depend on a database of certs.  
>> The URL to the cert accompanies the signature.
>> 
>> mechanism that gets around SS7 links and SPs that don't preserve the 
>> signed information does depend on such a database.  I think that is a
weakness.
>>>> Anyone can sign.  They sign with a domain they own.  So the 
>>>> signature goes with the operator, not with the content (number, 
>>>> message,
>>>> whatever.)
>>> 
>>> DKIM-like or 4474-like signature format, I'm just asking about 
>>> public key retrieval now.)
>>> 
>>> As with everything, I don't need to understand it now, but I do 
>>> think that a bunch of folks here are making assumptions about PKI 
>>> that might turn out to be a large amount of work later, e.g. that TN 
>>> delegation specific certificate chains exist, can be found and can 
>>> be verified efficiently.
>>> 
>>> the same as no signature on a mail message, there's no need to 
>>> require DNSSEC to get DKIM started.
>>> 
>>> or at a DISPATCH session or BoF or after a WG is chartered, I don't 
>>> mind, so long as it is properly considered.
>>> 
>>> S.
>>>

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 11 Jun 2013 17:06:35 +0100

> There certainly are people involved who want the result to stop MITM attacks, but it's not the stated problem.

Right. I think the putative wg will need to be clear about that.
That is, a threat-model is needed. (Bet you knew I'd say that:-)

> I agree that the level of assurance for public keys needed is pretty modest.  See the reply I just sent to Dave.

Good. That's an important point.

I have to say though that your response to Dave makes a fair
few assumptions about how to design the system - it basically
reads like a phone number analog to the RPKI. (And that's
fine - this work does need people proposing stuff after all.)
Now that could work I would guess, but it does bring a lot of
complexity. And I'm questioning whether all that's needed,
for the modest level of assurance required.

> Telephone number assignment has been around for a century.  It's built up a lot of infrastructure, regulation, bureaucracy and custom.  It has continuously evolved, and it's still evolving.  But th…

I do get the privacy concerns. And those need to be avoided
or addressed. But its not clear to me that an RPKI analog
would do that though, e.g. OCSP requests may well be needed
(or else no revocation) since I'm guessing it'd be unlikely
that pre-cooked OCSP responses or small CRLs could be stapled
to the SIP messages. And in the browser world those OCSP
transactions are both slow and privacy unfriendly. And as
I said, any PKI is liable to allow anyone to build a
reasonable version of the public-key/phone#-delegation DB.

Again, all of this needs working out, but it'd not be right
to start that from a position that the RPKI analog is the
solution IMO. It may turn out that way, or maybe it won't.

S.

PS: Just to be crystal clear - I'm not advocating for any
particular approach here. Mostly I' want to try help make
sure that what gets done here is deployable - I've wasted
too much of my own and other people's time over the years
on security stuff that didn't get used;-)

---

From: Hadriel Kaplan <[email-masked]>
Date: Tue, 11 Jun 2013 12:18:58 -0400

> 3. Regulator pressure.  Hasn't happened.  Actually the opposite - the regulator had to ask the ITU to delegate the country code.  Never happened.

I think the above is going to be true of anything we do: either the carriers and regulators and so on all cooperate for a given country, or we won't succeed.

I'm not even sure the above was really the problem for Public ENUM... more like the symptom not the cause.  The cause, imho, was that Public ENUM had no benefit for the stakeholders.  Imagine if every E.164 number was in The DNS.  So what?  You couldn't actually make a call directly to anyone, because people don't just blindly accept SIP requests directly from anyone on the public Internet.  And even if people suddenly went nuts and started wanting to, why would the Service Providers want to, or even the regulators want to?

But anyway... one real downside with having a Public ENUM for a PKI is that you could learn most or every number of an Enterprise or Service Provider by just iterating the numbers.  Even if the record reveals nothing personal, you'll know which numbers belong to which company/organization.  It's kinda like the concern people have with DNSSEC and the NSEC response, but much worse because an NSEC3-type thing won't help since the possible permutations of numbers are finite.

-hadriel

---

From: Dave Crocker <[email-masked]>
Date: Tue, 11 Jun 2013 09:23:02 -0700

On 6/11/2013 9:18 AM, Hadriel Kaplan wrote:
> But anyway... one real downside with having a Public ENUM for a PKI is that you could learn most or every number of an Enterprise or Service Provider by just iterating the numbers.  Even if the record reveals nothing personal, you'll know which numbers belong to which company/organization.

if the target model is true end-to-end validation of number use, that 
problem is going to be present, independent of the technical solution.

the only way to avoid that problem is to require that queries only be 
among a trusted, regulated core.  and from postings over the last couple 
of days, it sounds as if that's /not/ the goal.  (and irrelevantly i'll 
add that i'm glad...)

d/

---

From: "Rosen, Brian" <[email-masked]>
Date: Tue, 11 Jun 2013 16:42:09 +0000

> for the modest level of assurance required.
There might be another model that would work, but I haven't heard it yet.

> to the SIP messages.
We definitely need OCSP or something really similar.

Note that when you get a delegation for a range, in many countries that range is subject to porting.  And that means a specific TN in the range may not be valid for the range.  That's different from revoking a certificate for the range, but it could be done with one mechanism - is the cert for the range valid, and is the number still in the range?  We would not want to revoke the cert and issue several smaller ones leaving out the ported-out number.

"Porting out" has a complication.  The national porting mechanism has designated players, usually some form of carrier today, but that is evolving.  But the official porting database has the routing information among the "carriers" that participate.  Delegation involves those parties, but it also may have several levels of provider who are not participants in the national porting scheme.

Let me use an example:

Suppose Alice Carrier has two resellers, Bob and Charlie.  Bob and Charlie each have customers.  If a customer of Bob ports in a number from some other carrier other than Alice, then Alice has to complete the port in the national database on behalf of Bob.  

But suppose Bob ports a number in from Charlie?  From the national databases' point of view, there is no port, Alice is the SP of record before and after.  However, from Bob and Charlie's point of view, this is a port like any other port.  Alice has to make bookkeeping adjustments, and has to issue a cert for the ported in number to Bob.  Depending on how Charlie got the number before it ported to Bob, Alice may have to tell anyone that the cert it issued to Charlie for the number range is invalid for the number that was ported to Bob.

So, Alice needs to answer a query similar to that described above - it's not limited to the national porting database.

Brian

> And in the browser world those OCSP
There is a trade-off in how much work an SP wants to do itself, and what that reveals to other parties.  I think it will be common for one or more entities to provide an outsourcing service for the sub delegations. That might be used to regain some of the privacy that would be lost if the SP did the work itself.

> solution IMO. It may turn out that way, or maybe it won't.
It's close, but not the same.  Delegation doesn't work the same (not powers of 2 for example).  Different trust assumptions.  But "certs follow delegation" is similar.

> on security stuff that didn't get used;-)
Same here.  I know some stuff about what is deployable and what is not isn't exactly rational, but we do have a bunch of experience that we're trying to leverage.

Brian

---

From: Hadriel Kaplan <[email-masked]>
Date: Tue, 11 Jun 2013 12:54:44 -0400

> I do consider de-referencing a URL for a public key or

If the mechanism uses a URL for de-referencing, then the structure of the URL does not need to follow phone numbers in any way.  So you couldn't try to harvest them.  E.g., I call from +1-212-555-1212 and I sign it and in the SIP INVITE I tell you to go get the cert from:

http://callerid.att.com/cert/wbfpweirvqp9er7fg29374fg134ufb

The cert you download says it's for "+1-212-555-1212" (e.g., in the SAN field or something), and it's issuer is NANPA (North American Numbering Plan Administration), which you presumably have locally known root cert for and acceptance as a trusted CA.

So yes if you received the call from +1-212-555-1212 you'd know it's an AT&T number (because of the URL's domain), but you wouldn't be able to figure out what other numbers AT&T has - only those that called you.

Compare that to a DNS/DKIM/ENUM/DNSSEC model, where the "URL" follows a schema/format like "2.1.2.1.5.5.5.2.1.2.1.stir.ietf.org".  You don't even need to receive a call.  Just start querying all possible digits of the fixed length/depth.  For the 212 area code there are only 10 million possible numbers.  Even for all of the US it's only around a couple billion, because most area codes haven't been allocated, and the list of which ones have is public:
http://en.wikipedia.org/wiki/List_of_North_American_Numbering_Plan_area_codes

-hadriel
p.s. the above is not to say I think using HTTP is the right answer - you can do the same thing with other database query protocols.  The point is the query key need not follow any number-based or well-known schema.

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 11 Jun 2013 18:02:53 +0100

> The cert you download says it's for "+1-212-555-1212" (e.g., in the SAN field or something), and it's issuer is NANPA (North American Numbering Plan Administration), which you presumably have local…

Sure. I then send the cert to EFF and they add it to the
SSL observatory data set. Soon they'll have the mapping
for most keys to/from most phone numbers.

Yes, that'll get out of date if they don't keep up, but
the relationships that one can infer from that data set
is the only reason to not make it all public in the first
place.

I agree that a public ENUM thing would be easier to
walk. DKIM has selectors in the DNS names and you only
get those from email headers so DKIM is about the same
as an RPKI analog in this respect if the selectors and
URLs are equally unpredictable.

S.

---

From: Henning Schulzrinne <[email-masked]>
Date: Tue, 11 Jun 2013 14:32:33 -0400

I suspect access rules, both technical and legal, to any databases may vary among countries. If the database stores public key - number pairs, there is no particular need for an organization just to have one public key, if it doesn't want to provide clues to its holdings. 

In general, for service providers, the assignment of numbers isn't public, but it isn't a deep secret, either, at least among the entities that likely have some competitive interest in this. The LERG contains this information today, for example.

On Jun 11, 2013, at 12:23 PM, Dave Crocker wrote:

> if the target model is true end-to-end validation of number use, that problem is going to be present, independent of the technical solution.
> 
> the only way to avoid that problem is to require that queries only be among a trusted, regulated core.  and from postings over the last couple of days, it sounds as if that's /not/ the goal.  (and irrelevantly i'll add that i'm glad...)
> 
> 
> d/
> 
> -- 
> Dave Crocker

---

From: Henning Schulzrinne <[email-masked]>
Date: Tue, 11 Jun 2013 14:48:17 -0400

As a side note, there is no particular need to store the mapping in carrier-specific database. Today, databases are operated by various third parties (NeutralTandem and kin, Neustar, obviously), so there's plenty of opportunity to obscure this information, if desired.

---

From: Dave Crocker <[email-masked]>
Date: Tue, 11 Jun 2013 11:48:15 -0700

Brian,

Forgive me, but we haven't actually heard the one that you are working 
from, either.

We've heard bits about it, but no summary explication that can be 
compared against alternatives.

It's clear that you and some others are indeed working from a solid 
sense of a system architecture here, but the rest of us are left 
guessing.  Consequently, bits are getting elucidated piecemeal, causing 
fragmentation and possibly misunderstandings to the discussion about it.

I'm not talking about a detailed spec.  A common diagram style like I 
did earlier -- except specific to the proposal you have -- and summary 
of the interactions and exchanged objects would go a long way.  As I 
say, you've already offered bit of it; it's the integrated summary 
that's missing.

d/

ps. also wanted to thank your for:

> On 6/11/2013 8:13 AM, Rosen, Brian wrote:> Our GOAL is to have valid identity put on the call at the outset, and at least potentially verifiable all along the path.  The GOAL is end to end verifiability.

which is quite helpful.

---

From: "Rosen, Brian" <[email-masked]>
Date: Tue, 11 Jun 2013 19:10:23 +0000

I think I've said it a couple of times:

PKI based on number delegation, rooted in the national number authority.  Certs follow delegation.  If you have the number, you get a cert to sign with.

There is a SIP Identity-like header with a signature over the canonicalized To, From, timestamp and some kind of call id like the INSIPID id.  

There is a SIP Identity Info-like header with a URL to the cert that was used to create the signature.

A caller or SP serving the caller extracts the canonical To/From/timestamp/Call Id from the SIP header, computes the signature and adds the headers to the call.
Any SP or the endpoint validates by fetching the cert, validating it, extracting the info, and verifying the signature.   Validating the cert includes making sure the cert is still valid for the range.

There is some other mechanism that helps when the signature or the info used to compute the signature, is mangled in the path.

There is also a hash of the media description (SDP) included in the header and covered by the signature.  The media hash wouldn't validate for most calls today, but some day, if media wasn't anchored somewhere other than the endpoints, as it usually is today, you could tell if the media had been hijacked.  The signature would work if the SDP was altered, but verifying the hash would fail.

Brian

On Jun 11, 2013, at 2:48 PM, Dave Crocker <[email-masked]>
 wrote:

> Forgive me, but we haven't actually heard the one that you are working from, either.
> 
> We've heard bits about it, but no summary explication that can be compared against alternatives.
> 
> It's clear that you and some others are indeed working from a solid sense of a system architecture here, but the rest of us are left guessing.  Consequently, bits are getting elucidated piecemeal, causing fragmentation and possibly misunderstandings to the discussion about it.
> 
> I'm not talking about a detailed spec.  A common diagram style like I did earlier -- except specific to the proposal you have -- and summary of the interactions and exchanged objects would go a long way.  As I say, you've already offered bit of it; it's the integrated summary that's missing.
> 
> 
> d/
> 
>

---

From: Hadriel Kaplan <[email-masked]>
Date: Tue, 11 Jun 2013 15:25:19 -0400

> for most keys to/from most phone numbers.

I don't think that's a real concern.  For one, each cert for each E.164 would be unique; for another, it probably wouldn't be too hard to convince EFF not to make the info available but only use it for their own research purposes; third, it would take a large population of actors posting the info to the EFF to make it interesting, but I don't see commercial SIP devices doing that (and if they do they'd get themselves on malware lists).  I don't think that enough bad actors would receive enough calls from enough sources to make any list they create really useful.

Realistically it's not like the list is truly secret - at least for which carriers have which numbers, since any legitimate carrier can get the info today already from LERG/NPAC/etc., which probably means anyone can get a reasonably complete list for enough money today.  The carriers would like to keep it non-trivial (ie, prevent script kiddies).  For Enterprises it's even more of an issue/concern.  Although my guess is most of them wouldn't do this stuff themselves anyway, but have their carrier do it for them, and thereby avoid such a problem.

The above is assuming the cert databases are public to begin with, which they might not be.  I'm not even sure the signature with cert URL would really be sent all the way to the endpoints, either.

-hadriel

---

From: Wilhelm Wimmreuter <[email-masked]>
Date: Tue, 11 Jun 2013 21:32:18 +0200

These are important points on privacy!
 Do we need privacy for the users privacy or for service providers to hide competitive advantages?

I guess that all we need is a strong authentication of the originating /requesting entity.

 This in turn means to separate authentication and certificate attributes like identities such as phone numbers.

What will be left:
- A cert with a random Cname or alt-cname.
  Bound to a phone number / Caller-ID during enrollment
- A signature digest to sign the 
  * originating CallerID / phone number (not necessary canonical)
  * Unique Call/Request ID (random)
  * Possibly a timestamp

 These signed elements must not be modified throughout the call path. Therefore only a minimum set if attributes shall be signed.

Of course, such systems will break at the interworking with PSTN as mentioned before. However, the case is not hopeless as one could refer to external databases holding the original signatures and attributes stored before reaching a PSTN ingres point. This was already proposed by Brian at the begin of this discussion.

Such a system would allow to.
- Authenticate caller IDs
- Validate the signature at any point in the call path {except inside PSTN)
- Supress caller IDs where necessary e.g. subscribers, anonymous help-lines, ...
- Delegate authoritative use and signing e.g. for call-centers / PBXs
  ... legitimate spoofing ;-)
- Delegate authoritative signing to the service provider.
  For endpoints that can not sign service requests. e.g. old SIP or PSTN phones.
- Direct access to enrollment registration e.g. 11 PSAPs or other legitimate nosiness 
- ...

With that in mind, we possibly can resolve all other requirements like canonical numbers, DKIM wish-lists, authorization and RoboCall issues on top of such of such a base. 

Willi

---

From: Hadriel Kaplan <[email-masked]>
Date: Tue, 11 Jun 2013 15:47:14 -0400

Yup, but I'm not so sure carriers want to pay even more money to third-party database companies for the privilege of accessing their own data. ;)

Although maybe it could be managed by each country's numbering plan admin (e.g., NANPA)?  If that were the case, then storing it in a Public ENUM actually makes some sense.  There would be no identifying information - the cert wouldn't have the organization info in it, just the phone number and issuer being NANPA.  And from a DNS perspective each country code sub-domain would all be under one authority (e.g., *.1.stir.ietf.org would be NANPA), so they could split it out by subdomains for the purpose of scaling servers without worrying about authority problems.

-hadriel

---

From: "Rosen, Brian" <[email-masked]>
Date: Tue, 11 Jun 2013 19:46:25 +0000

Right at the moment, I don't think we need to get into the level of detail
over what is in the came/alt-cname.   We might need to be thinking of what
is in there, but maybe not where it goes.

We have been discussing canonicalization of the from and to to get out of
the problem that the actual from and to are changed by SBCs along the path.

"bound to the phone number during enrollment" is not quite right.  It's
bound to the delegation of the number.  That is not (necessarily) related
to enrollment.

Brian

On 6/11/13 3:32 PM, "Wilhelm Wimmreuter" <[email-masked]> wrote:

> These signed elements must not be modified throughout the call path.
>Therefore only a minimum set if attributes shall be signed.
>
>
>
>Of course, such systems will break at the interworking with PSTN as
>mentioned before. However, the case is not hopeless as one could refer to
>external databases holding the original signatures and attributes stored
>before reaching a PSTN ingres point. This was already proposed by Brian
>at the begin of this discussion.
>
>
>
>With that in mind, we possibly can resolve all other requirements like
>canonical numbers, DKIM wish-lists, authorization and RoboCall issues on
>top of such of such a base.
>
>
>Willi
>
>> I suspect access rules, both technical and legal, to any databases may
>>vary among countries. If the database stores public key - number pairs,
>>there is no particular need for an organization just to have one public
>>key, if it doesn't want to provide clues to its holdings.
>> 
>> In general, for service providers, the assignment of numbers isn't
>>public, but it isn't a deep secret, either, at least among the entities
>>that likely have some competitive interest in this. The LERG contains
>>this information today, for example.
>> 
>>>> But anyway... one real downside with having a Public ENUM for a PKI
>>>>is that you could learn most or every number of an Enterprise or
>>>>Service Provider by just iterating the numbers.  Even if the record
>>>>reveals nothing personal, you'll know which numbers belong to which
>>>>company/organization.
>>> 
>>> 
>>>among a trusted, regulated core.  and from postings over the last
>>>couple of days, it sounds as if that's /not/ the goal.  (and
>>>irrelevantly i'll add that i'm glad...)
>>> 
>>> 
>>> d/
>>> 
>>> -- 
>>> Dave Crocker

---

From: Wilhelm Wimmreuter <[email-masked]>
Date: Tue, 11 Jun 2013 21:49:30 +0200

See inline.
Willi

> I don't think that's a real concern.  For one, each cert for each E.164 would be unique; for another, it probably wouldn't be too hard to convince EFF not to make the info available but only use it…
I think we do not need one unique cert and private key for one E.164 number. We can have more signing certs for a given E.164 number. The only thing required is that the CA / RA performs a decent enrollment check on the CSR for each potential certificate being created for a given number. e.g. user, PABX, Service-provider, etc.

> Realistically it's not like the list is truly secret - at least for which carriers have which numbers, since any legitimate carrier can get the info today already from LERG/NPAC/etc., which probabl…
But this becomes an issue for legitimate anonymous identities / caller-IDs

> The above is assuming the cert databases are public to begin with, which they might not be.  I'm not even sure the signature with cert URL would really be sent all the way to the endpoints, either.
The cert databases shall be referred to as e.g. mentioned in RFC-4474. The CAs and their databases shall be freely selectable bay users or service-providers to allow competition and service-provider independent choice.

---

From: Brian Rosen <[email-masked]>
Date: Tue, 11 Jun 2013 16:00:02 -0400

If you put in in public enum, you have all of the problems of managing the tree that eluded us.  As a practical matter, you get carriers to pay a third party database company to manage the +1 tree, a la cc1enum.  

In the U.S., it could be NPAC that held the per-TN data.  It already does for most numbers.  Having NPAC provide an ENUM query in e164.arpa is certainly possible, but I think would be an enormous effort to get approved.  Having it supply a query to SPs based on a sane query protocol like a web service would be better and much easier to get fielded.  Way too much baggage in ENUM I think.

Brian

---

From: Wilhelm Wimmreuter <[email-masked]>
Date: Tue, 11 Jun 2013 22:01:45 +0200

> for most keys to/from most phone numbers.

Very true!
Why not just using a nickname or any anonymous identifier in the (alt-)Cname and leave it to the signer to sign the asserted Caller-ID number?

This could be further verified by anyone receiving the signature and the digest attributes later.
All authoritative / legitimate validation clients the can validate the asserted Caller-ID. All others can be sure the given Caller-ID was not modified on the call-path.

> URLs are equally unpredictable.

I guess that ENUM in that sense would break privacy requirements.

Willi

---

From: Wilhelm Wimmreuter <[email-masked]>
Date: Tue, 11 Jun 2013 22:26:15 +0200

> the problem that the actual from and to are changed by SBCs along the path.
Got it.
What if we avoid signing the to and from at all?
One also could sign the random Call-Reference instead.
The asserted Caller-ID then could be validated by authoritative validation clients through the registration-authorities databases only. All other client validations will only see that his request was generated by an authenticated user.

> bound to the delegation of the number.  That is not (necessarily) related
By enrollment I ment the Certificate signing / CSR validation by the CA and this is the process where the authority creates the certificate and enables the user or service-provider to sign for a given Caller-ID or in case of service providers, Call-Centers or PBXs for multiple Caller-IDs.

Willi

---

From: "Rosen, Brian" <[email-masked]>
Date: Tue, 11 Jun 2013 20:31:35 +0000

> One also could sign the random Call-Reference instead.
because you could use that in a cut/paste attack by sending a call with the same call id and completely different to/from

> The asserted Caller-ID then could be validated by authoritative validation clients through the registration-authorities databases only. All other client validations will only see that his request w…
in many countries, there are entities other than the ones known by the registration authorities who hand out numbers.  They get the numbers from a carrier known by the authorities, but resell them to an entity that is not known.  We have to handle that case.

> By enrollment I ment the Certificate signing / CSR validation by the CA and this is the process where the authority creates the certificate and enables the user or service-provider to sign for a gi…
Ah, I thought you meant enrollment in the SIP domain, sorry.

---

From: Wilhelm Wimmreuter <[email-masked]>
Date: Tue, 11 Jun 2013 23:21:37 +0200

> because you could use that in a cut/paste attack by sending a call with the same call id and completely different to/from

Yes, that is true.
So we have to include the to / from in the digest and forward the original to / from unmodified somehow. 
... do we need another "behave" WG for to/from header handling besides NAT ;-)

Sorry for taking my shortcuts to far.

> in many countries, there are entities other than the ones known by the registration authorities who hand out numbers.  They get the numbers from a carrier known by the authorities, but resell them…
Here I thought that we shall separate phone number registration authorities from Certificate Authorities that sign the certificate and in fact bind a certificate to one or multiple phone numbers / caller-IDs. of course, both RAs can be the same required and capable.

1.) Phone number assigned to 
    Handout number Phone number RA 

2.) Assign phone number to certificate for signing
        Certificate Authority & RA (sign the CSR)

3.) User or service provider on behalf of user signs the request.

4.) Validation
    - everyone in the call-path can validate the signature and message consistency
    - legitimate users can also validate the asserted Caller-ID, delegation etc.

5.) Out of band validation and optional re-signing across PSTN domains is possible.
    e.g. through dynamic (out of band) databases with stringent time constrains etc.

---

From: Hadriel Kaplan <[email-masked]>
Date: Tue, 11 Jun 2013 17:35:24 -0400

> If you put in in public enum, you have all of the problems of managing the tree that eluded us.  As a practical matter, you get carriers to pay a third party database company to manage the +1 tree,…

Not necessarily.  For each country code, you make their numbering plan admin the authority.  For example for +1, you make NANPA the authority (or maybe NANC or whatever it needs to be).  They're "responsible" for generating a unique key pair for each +1 E.164 signed by their root cert, giving the key pair to the org they give the number to, and hosting the pub key for each in a DNS structure.

Of course NANC/NANPA doesn't actually do the work, just like IANA/ICANN doesn't do the work for DNS.  NANPA contracts with someone else to do it, like Neustar (which as far as I know runs NANPA).  Since they're doing it all in bulk, then the per number entry it shouldn't cost anywhere near what normal domain name registrations do.  NANPA gets the money for it from the E.164 number allocation fee, annual maintenance fee, and change fee or whatever.

I'm not saying getting this done is easy - it's NOT - but nothing we do is going to be.  At least this way there's only one organization to deal with to get the cert-db part done, per country.

> In the U.S., it could be NPAC that held the per-TN data.  It already does for most numbers.  Having NPAC provide an ENUM query in e164.arpa is certainly possible, but I think would be an enormous e…

But the NPAC only holds data for NANP-based numbers.  How does a US carrier authenticate a number from the UK or Germany or wherever?

-hadriel

---

From: Henning Schulzrinne <[email-masked]>
Date: Tue, 11 Jun 2013 22:09:37 -0400

All known bad actors are the original caller. It would be hard to scale up a MITM model - if you're a transit carrier, all the other entities would drop you immediately if it becomes obvious that you're hijacking calls (besides probably calling the Feds, as wiretapping and other criminal acts are likely to be involved). You'd have to advertise yourself as a cheap VoIP carrier, get consumer or small business customers and then perpetrate your MITM conversion. That seems like a very short-lived business plan.

That said, we do see one specific case of callerID alteration in the middle, for intercarrier compensation fraud. (Some carriers have been known to "convert" a landline call to a mobile or VoIP call, or intrastate to interstate, since they have lower ICC.) But that is also detectable by the next carrier in the chain, who would be the one being defrauded and thus very motivated to check the signature.

---

From: Wilhelm Wimmreuter <[email-masked]>
Date: Wed, 12 Jun 2013 11:04:47 +0200

I can confirm this MITM tweaking with a bunch of samples from PSTN carriers around the world.
This goes from 1.) Tweaks in routing to hide the class of service and origin, 2.) Premature answer or delayed release to increase revenues, 3.) Overflow routing through other carriers to avoid expensive termination fees, 5.) Not delivering calls because of expensive termination fees and many more. 
 The telecom-acts of different countries made up a myriad of new business cases for such tricks. And yes, they even introduced back-to-back-user-agents for PSTN to avoid roaming fees between mobile networks. This was done by introducing racks of mobile network personalities to interconnect networks without roaming. 
... of course they charged it to their customers ;-)

Willi

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 12 Jun 2013 11:14:37 +0100

Hi Henning,

On 06/12/2013 03:09 AM, Henning Schulzrinne wrote:
> All known bad actors are the original caller. It would be hard to
> scale up a MITM model - if you're a transit carrier, all the other
> entities would drop you immediately if it becomes obvious that you're
> hijacking calls (besides probably calling the Feds, as wiretapping
> and other criminal acts are likely to be involved). You'd have to
> advertise yourself as a cheap VoIP carrier, get consumer or small
> business customers and then perpetrate your MITM conversion. That
> seems like a very short-lived business plan.

On the MITM thing, it does seem that we don't need to worry so
much about it for these use-cases, which may lead to an easier to
implement/deploy key management model (or not, we'll see).

One concern I have though is whether or not it'd be ok to leave
open potential spoof calls launched from e.g. a zombied home router
to a callee on the home network. If the final model had exactly
the same security properties as DKIM, then that would be an issue.
If the final model were based on Brian's 5280-based ideas that
threat would probably not be an issue. Or there may be ways to
look up a signer public key over a TLS channel that'd work too.

So this is one detail (whether or not that threat is a concern)
that needs to be figured out when doing the threat model work.

S.

> 
> That said, we do see one specific case of callerID alteration in the
> middle, for intercarrier compensation fraud. (Some carriers have been
> known to "convert" a landline call to a mobile or VoIP call, or
> intrastate to interstate, since they have lower ICC.) But that is
> also detectable by the next carrier in the chain, who would be the
> one being defrauded and thus very motivated to check the signature.
> 
>> components that would likely bog everything down. Hence, my trying
>> to focus on where the perp likely is.
> 
> _______________________________________________ stir mailing list 
> [email-masked] https://www.ietf.org/mailman/listinfo/stir
>

---

From: "PFAUTZ, PENN L" <[email-masked]>
Date: Wed, 12 Jun 2013 12:32:41 +0000

I think Hadriel is on the right track.  As to the globalization issue, my takeaway from efforts to build an authoritative global enum tree is that you will need to work from national authorities up. If you get per country data sources it will not be hard to link them together/interwork.
This approach also provides some national flexibility.

Penn Pfautz
AT&T Access Management
+1-732-420-4962
-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Hadriel Kaplan
Sent: Tuesday, June 11, 2013 5:35 PM
To: Brian Rosen
Cc: [email-masked]; Henning Schulzrinne
Subject: Re: [stir] DKIM-like key mgmt approach

-hadriel

---

From: Hadriel Kaplan <[email-masked]>
Date: Wed, 12 Jun 2013 12:56:44 -0400

> look up a signer public key over a TLS channel that'd work too.

I understand what a "zombied home router" is and what a "callee on the home network" is, but I don't understand the case you're talking about.  Can you describe the scenario for how the attack would work/behave?

One type of attack that we might have to worry about, that might be called a MITM attack because the attacker becomes a type of MITM during the attack: a malicious callee receiving a call and using the received signature to initiate an outbound call during the short time the signature is valid, spoofing the original caller.  

This is described in:
http://tools.ietf.org/html/draft-kaplan-sip-baiting-attack-00

Basically it boils down to us needing to distinguish legitimate call-forwarding from malicious call-forwarding.  Unfortunately none of the possible solutions for it are very palatable, imho.

-hadriel

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 12 Jun 2013 18:13:21 +0100

> I understand what a "zombied home router" is and what a "callee on the home network" is, but I don't understand the case you're talking about.  Can you describe the scenario for how the attack woul…

I guess bad-guy hacks my home router, then initiates a call from
or via there to me in my living room making it look like the call
comes from my bank.

If the key management was precisely the same as DKIM's then he'd
be able to feed me a public key to make it look like his signature
is ok for the bank's telephone number since I use my home router
for DNS as well. (Assuming my UA doesn't insist on DNSSEC.)

> http://tools.ietf.org/html/draft-kaplan-sip-baiting-attack-00

Don't have time to read that right now, will look later.

S

---

From: Hadriel Kaplan <[email-masked]>
Date: Wed, 12 Jun 2013 14:19:52 -0400

> for DNS as well. (Assuming my UA doesn't insist on DNSSEC.)

Ahh, yeah I had kinda assumed that we weren't going to blindly trust DNS on the public Internet, at least not for general behavior in whatever RFC comes out of this work.  (but in practice I would expect there to be a lot of cases where just believing the DNS response's pub key info would be fine and all that's actually done)

-hadriel

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 12 Jun 2013 18:00:59 -0400

On 6/11/13 12:54 PM, Hadriel Kaplan wrote:
> So yes if you received the call from +1-212-555-1212 you'd know it's an AT&T number (because of the URL's domain),

I see no reason why the URL needs to mention att.
It could be an IP address, frequently changed.
Or the certs could be hosted by an intermediary for retrieval.

	Thanks,
	Paul

> but you wouldn't be able to figure out what other numbers AT&T has - only those that called you.
>

---

From: "Peterson, Jon" <[email-masked]>
Date: Wed, 12 Jun 2013 22:16:34 +0000

Agreed that it is better to work from the nation level up than to try to
trickle this down from a global root. There are technologies (like LoST,
used in ECRIT) that are designed to have allow a more opt-in structure for
navigating between trees like this. Perhaps we could look into technology
like that to help us figure out the right way to work this.

Jon Peterson
Neustar, Inc.

On 6/12/13 5:32 AM, "PFAUTZ, PENN L" <[email-masked]> wrote:

>I think Hadriel is on the right track.  As to the globalization issue, my
>takeaway from efforts to build an authoritative global enum tree is that
>you will need to work from national authorities up. If you get per
>country data sources it will not be hard to link them together/interwork.
>> If you put in in public enum, you have all of the problems of managing
>>the tree that eluded us.  As a practical matter, you get carriers to pay
>>a third party database company to manage the +1 tree, a la cc1enum.
>
>Not necessarily.  For each country code, you make their numbering plan
>admin the authority.  For example for +1, you make NANPA the authority
>(or maybe NANC or whatever it needs to be).  They're "responsible" for
>generating a unique key pair for each +1 E.164 signed by their root cert,
>giving the key pair to the org they give the number to, and hosting the
>pub key for each in a DNS structure.
>
>Of course NANC/NANPA doesn't actually do the work, just like IANA/ICANN
>doesn't do the work for DNS.  NANPA contracts with someone else to do it,
>like Neustar (which as far as I know runs NANPA).  Since they're doing it
>all in bulk, then the per number entry it shouldn't cost anywhere near
>what normal domain name registrations do.  NANPA gets the money for it
>from the E.164 number allocation fee, annual maintenance fee, and change
>fee or whatever.
>
>I'm not saying getting this done is easy - it's NOT - but nothing we do
>is going to be.  At least this way there's only one organization to deal
>with to get the cert-db part done, per country.
>
>
>> In the U.S., it could be NPAC that held the per-TN data.  It already
>>does for most numbers.  Having NPAC provide an ENUM query in e164.arpa
>>is certainly possible, but I think would be an enormous effort to get
>>approved.  Having it supply a query to SPs based on a sane query
>>protocol like a web service would be better and much easier to get
>>fielded.  Way too much baggage in ENUM I think.
>
>But the NPAC only holds data for NANP-based numbers.  How does a US
>carrier authenticate a number from the UK or Germany or wherever?
>
>-hadriel
>

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 12 Jun 2013 23:17:29 +0100

On 06/12/2013 11:00 PM, Paul Kyzivat wrote:
>>
>> So yes if you received the call from +1-212-555-1212 you'd know it's
>> an AT&T number (because of the URL's domain),
> 

Doesn't matter. Using certs the relationships are crystal clear
as an inherent part of certificate validation. If you want to
change that you'd need to re-invent a *lot* of PKI stuff.

S.

---

From: "Richard Shockey" <[email-masked]>
Date: Thu, 13 Jun 2013 10:42:02 -0400

+1 .. 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Peterson, Jon
Sent: Wednesday, June 12, 2013 6:17 PM
To: PFAUTZ, PENN L; Hadriel Kaplan; Brian Rosen
Cc: [email-masked]; Henning Schulzrinne
Subject: Re: [stir] DKIM-like key mgmt approach

Jon Peterson
Neustar, Inc.

On 6/12/13 5:32 AM, "PFAUTZ, PENN L" <[email-masked]> wrote:

>I think Hadriel is on the right track.  As to the globalization issue, 
>my takeaway from efforts to build an authoritative global enum tree is 
>that you will need to work from national authorities up. If you get per 
>> If you put in in public enum, you have all of the problems of 
>>managing the tree that eluded us.  As a practical matter, you get 
>>carriers to pay a third party database company to manage the +1 tree, a la
cc1enum.
>generating a unique key pair for each +1 E.164 signed by their root 
>cert, giving the key pair to the org they give the number to, and 
>hosting the pub key for each in a DNS structure.
>
>doesn't do the work for DNS.  NANPA contracts with someone else to do 
>it, like Neustar (which as far as I know runs NANPA).  Since they're 
>doing it all in bulk, then the per number entry it shouldn't cost 
>anywhere near what normal domain name registrations do.  NANPA gets the 
>money for it from the E.164 number allocation fee, annual maintenance 
>fee, and change fee or whatever.
>
>is going to be.  At least this way there's only one organization to 
>deal with to get the cert-db part done, per country.
>
>