Subject: RE: [Sip] sip-identity-05: display-name woes

From: "Elwell, John" <[email-masked]>
Date: Wed, 06 Apr 2005 08:21:56 +0100

Jon,

I don't like A and D. Of the others, I am perhaps less negative to B than
you are (but we do need to make sure we don't go down the slippery slope).
With C, presumably the default string could be null. How often in practice
do we anticipate a domain having policies that will authorise display names
- if this is likely to be a rare thing, we might as well go with E.

John

> -----Original Message-----
> From: Peterson, Jon [mailto:[email-masked]] 
> Sent: 06 April 2005 00:39
> To: [email-masked]
> Subject: [Sip] sip-identity-05: display-name woes
> 
> 
> In Minneapolis, Jonathan raised the prospect that the 
> Identity header field should contain a signature over the 
> display-name portion of the >From header field value. This is 
> attractive because SIP user agent implementations might 
> render only that display-name to their users when an INVITE 
> is received. Accordingly, securing display-name is very 
> useful for human authorization decisions. After some 
> cajoling, I hastily agreed that we could do this for sip-identity-05.
> 
> As I've worked towards a revision, though, I've become 
> convinced that this is more complicated than I initially 
> thought. At the root of the problem is the extremely rigid 
> nature of the sip-identity mechanism. It is intentionally 
> hostile to being "configurable" in any way; there are 
> currently no reference indicators whose inclusion in the 
> Identity signature is optional. If a reference indicator is 
> present in the request, it appears in the identity-string 
> (which is hashed and signed to form the contents of the 
> Identity header field); if it isn't present in the request, 
> the corresponding field of the identity-string is blank.
> 
> This does not interact well with identity-string elements 
> that might or might not be added by the authentication 
> service depending on its policies or capabilities. 
> Unfortunately, it is difficult to anticipate how the operator 
> of an authentication service might decide whether or not a 
> human-readable free text field like the display-name is 
> appropriate, and accordingly, we can't expect every 
> authentication service operator to have such policies.
> 
> At a mechanism level, the problem is how we express all of 
> the following conditions in the identity string:
> 
> - The display-name is present in the request, and it is has 
> been authorized by the domain.
> - The display-name is present in the request, but the domain 
> has no authorization policies related to display-names.
> - The display-name is not present in the request.
> 
> Here are a few options as to how we might approach this:
> 
> (A) If the display-name is present, include it in the 
> identity string no matter what. Of course, then the problem 
> is that the verifier has no way of knowing whether or not the 
> domain actually employed any policies to validate the 
> display-name. Accordingly, it really doesn't add much value 
> for the verifier.
> 
> (B) If the display-name is present and authorized, include 
> it, and also include some other flag somewhere in the message 
> (in the Identity or Identity-Info headers, probably) noting 
> that this authentication service enforces display-name 
> policies. I am reluctant to start going down this path 
> because it introduces variable reference indicators, which 
> are a notorious source of bid-down attacks. That flag, 
> wherever it resides, must then also be secured by the 
> Identity header or it might be removed by someone replaying 
> the message. Once we start going down this path, it also 
> becomes something of a slippery slope - why not also have a 
> flag for other common SIP headers that might optionally be 
> included, and which could conceivably be evaluated by an 
> authentication service? All of this makes the verification 
> processing more complicated as well; the margin of error in 
> the regeneration of the hash and string increases.
> 
> (C) If the display-name is present and authorized, include 
> it. If the display-name is present but the domain has no 
> display-name policies, then rather than include it, include 
> some fixed value in the identity string like 
> 'no-display-policies' in the slot that would ordinarily be 
> occupied by the display-name value. That is kinda kludgey, 
> but gets the message across to the verifier loud and clear.
> 
> (D) If the display-name is present and authorized, include 
> it. If the display-name is present but unauthorized, then 
> don't include it in the identity-string, and also strip it 
> from the From header field of the request. This is 
> undesirable because proxy server should not be mucking with 
> the From header field unless they want to be called names 
> like 'B2BUA' or what have you. Simplest from a verification 
> perspective, though.
> 
> (E) Give up on including display-name. People should learn to 
> make user agents that render addr-specs to their users 
> instead of/in addition to display-names. Unlikely that any 
> domain will have policies about this anyway (it certainly 
> never caught on for email).
> 
> Any better ideas, or barring that, any preferences among the above?
> 
> Jon Peterson
> NeuStar, Inc.
> 
> _______________________________________________
> Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
> This list is for NEW development of the core SIP Protocol
> Use [email-masked] for questions on current sip
> Use [email-masked] for new developments on the application of sip
> 

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [email-masked] for questions on current sip
Use [email-masked] for new developments on the application of sip

---

From: "Peterson, Jon" <[email-masked]>
Date: Wed, 6 Apr 2005 16:06:36 -0400

The issue with C using null for "no policy" is disambiguating this from the case in from the display-name isn't actually present; e.g., where the From header field just contains sip:[email-masked] rather than "Jon Peterson" <sip:[email-masked]> or what have you. I would prefer to reserve null for that case.

Jon Peterson
NeuStar, Inc.

> From: [email-masked] [mailto:[email-masked]]On Behalf Of
> Elwell, John
> Sent: Wednesday, April 06, 2005 12:22 AM
> To: Peterson, Jon; [email-masked]
> Subject: RE: [Sip] sip-identity-05: display-name woes
> 
> 
> Jon,
>

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 07 Apr 2005 10:32:49 -0400

Brian Rosen wrote:
> Maybe we want to step back and ask:
> What is the purpose of a display name?
>    And
> What is the purpose of the Identity work?
> 
> We might find that there is no point in trying to assert anything about
> display name ever.

I agree it is worthwhile to thoughtfully consider the alternatives.

> A display name is something used to LABEL a caller.  It's displayed to the
> user.
> 
> Identity is used to Identify a caller, primarily to provide a reasonably
> reliable indication of who called, and how to call them back.

We have (at least) two precedents here that seem relevant to some degree:
- callerid in the public telephone network
- addressing in email

Superficially, sip at the protocol level looks more like email, so that 
perhaps might argue it is a better precedent. But operationally sip 
looks more like the telephone network. And significantly it must 
interoperate with the telephone network. That argues that the callerid 
precedent should be preferred.

> If you go to a telephone company and get a phone line, and you tell them
> that your name is George Bush, they might kid you, but they aren't going to
> give you the third degree because there really are a few other George Bush's
> out there.  It's more work than doing something with the display name on
> your SIP phone, maybe, but it's not something that is assertable. 

I find the difference here to be quite significant. You are on the 
record, in a way that can be used in a court, as having asserted your 
name is George Bush. And while they might not give you too hard a time 
saying that is your name, they would probably give you a much harder 
time if you tried to sign up as "George Bush, President of the United 
States".

And generally, when you sign up you are also tied to a billing or 
contact address, providing some accountability.

> The phone
> company REPORTS the name on appropriate caller ID, but does not assert it
> means anything.  The phone number, on the other hand, is an identifier, and
> it does mean something.

I think the phone company does assert it means something: it is a name 
that you have registered and attested to.

> Perhaps we simply do not ever include display name in the Identity
> signature.

The most immediate problem I can see comes when your call lands on a 
gateway to the PSTN. At that point the identification conventions of the 
SIP network must be interworked with those of the public telephone 
network. The gateway must decide whether to populate the calling name 
and number fields on the PSTN side. If it has no authentication that the 
information is correct, should it populate it?

On the PSTN side there is an expectation that "trusted" information is 
usually provided, for number and often for name. Calling systems that 
are not able to provide this are considered second rate. If we want sip 
systems to be considered first rate, then those systems had better be 
able to provide this information in a form that is as trustworthy as 
that from traditional phone systems.

If a gateway provides the information even though it isn't trusted, then 
it *will* be exploited. Once this starts to be generally known, the sip 
systems may be branded as "second rate", and there might even be legal 
action to force them to "fix the problem".

> I think our email experience suggests that there is not a lot of harm when
> you get a forged email display name.  We have harm with a forged email
> address.  There is probably more concern over indecent names than forged
> names, but as always YMMV. 

People have learned to live with this for email. But it does present 
problems to the more naive users. And it is compounded by email clients 
that display only the display name, not the actual address.

And the spam problem is very visible evidence of problems with the email 
implementation. I think there is some evidence that people are 
abandoning email because of problems with it. So it isn't necessarily a 
good precedent to follow. And, as I pointed out above, there are other 
reasons to think it is not the preferred precedent.

	Paul

> Brian
> From: [email-masked] [mailto:[email-masked]] On Behalf Of Paul
> Kyzivat
> Sent: Thursday, April 07, 2005 8:10 AM
> To: Peterson, Jon
> Cc: [email-masked]
> Subject: Re: [Sip] sip-identity-05: display-name woes
> 
> 
> 
> Peterson, Jon wrote:
> 
>>>The simple answer (but perhaps not a popular one) would be to mandate 
>>>that the authentication service *must* have a policy wrt display names. 
>>>(A degenerate policy would be that display names simply aren't permitted.)
>>
>>
>>I would feel more comfortable about that if anyone had any idea how a
> 
> domain might go about enforcing such policies and distributing legitimate
> display-names to users. Currently, we're taking it on faith that some
> domains will want to adopt such policies, and will figure out appropriate
> operational ways to execute them. Not a small thing to take on faith given
> the precedents in the email space, not to mention the fact that the domains
> themselves seem to gain little by enforcing these policies.
> 
> We shouldn't try to boil the ocean, but I think we should be looking to 
> put a framework in place that will let the players do the right thing.
> 
> I have the impression there is some appreciation that callerid (both 
> number and name) should be somewhat trustworthy. That notion just has to 
> be embraced for SIP.
> 
> If callee devices don't trust, and hence don't display, untrusted 
> display names, that might eventually provide a competitive advantage to 
> those that provide trusted names. ("Alice, when you call me your name is 
> never displayed. Why don't you switch to a service that provides the name?")
> 
> Or it may be that once there are some highly publicized abuses, there 
> will be legal action to require reliable callerid from IP phones.
> 
> 
>>>I suppose it is then necessary to be a little more demanding about what 
>>>sort of policy is acceptable. (A policy of "you can use any display name 
>>>you want" is probably not an acceptable policy.)
>>
>>
>>Well, it's about as acceptable as the policy "you can use any username in
> 
> the addr-spec portion of the From header field that you want", but that is
> effectively the state-of-the-art for SIP and email today. I doubt that
> sip-identity can have any appreciable effect on what policies domains want
> to use for this stuff. What is can do is specify a way, through mechanism,
> for a domain to communicate "my policies, however strict or lax, were
> followed with regards to this From header field". 
> 
>>
>>>Alternatively, perhaps there should be a standard way for discovering 
>>>the (human and/or machine readable) authentication policy of a 
>>>particular authentication service. It doesn't have to be part of the 
>>>request, just derivable from the authentication service credentials.
>>
>>
>>In the end analysis, I can't think of any way that the authorization
> 
> decision made by a recipient would change if it had this information. After
> all, a bad domain could lie about its policies, deluded domains will tell
> you they have a good policy even though it is routinely circumvented by
> clever users, and good domains will be good regardless of whether or not
> they tell you your policies. As a verifier, I might be willing to take the
> word of a third-party auditor, but I don't think we can incorporate that
> into our protocol specification.
> 
> I think I take advantage of such info by configuring my system about 
> what domains to accept names from.
> 
> In principle, I would think it might eventually be possible to arrange 
> things so that the signer of the authorization service's cert vouched 
> for the policy of the authentication service. Then it would be easier to 
> configure who you trust. (But in practice this sounds hard.)
> 
> Regarding lying about policy - at least being on the record provides the 
> basis for legal action against those that lie.
> 
> 	Paul
> 
> 
>>Jon Peterson
>>NeuStar, Inc.
>>
>>
>>
>>>	Paul
>>>
>>>Peterson, Jon wrote:
>>>
>>>
>>>>The problem with that, I think, is that it does not provide 
>>>
>>>for the case where the display-name is present, but the 
>>>authentication service has no policy with regard to 
>>>display-names. What does the authentication service do then, 
>>>and how is that behavior disambiguated from the other cases 
>>>at the verifier?
>>>
>>>
>>>>I agree that if the display-name is present and 
>>>
>>>unauthorized, then the authentication service shouldn't sign 
>>>the message. In fact, you don't even have to include the 
>>>display-name in the identity-string in order to structure the 
>>>mechanism like that. The mechanism in sip-identity-04 
>>>essentially reads:
>>>
>>>
>>>>(G) If the domain has policies about display-names, and the 
>>>
>>>display-name is present and unauthorized, decline to sign the 
>>>message, sending back a 4xx suggesting that the display-name 
>>>needs to be correct. Otherwise, sign the message (NOT 
>>>including the display-name) and forward it.
>>>
>>>
>>>>Ultimately, a signature over the display-name itself is not 
>>>
>>>necessary unless you are concerned that the message is going 
>>>to be modified in transit (which is outside the threat model 
>>>of sip-identity, since sip-identity is only concerned with 
>>>impersonation). Replaying the message with a differnt 
>>>display-name isn't really an option because the replay would 
>>>be exposed by the other reference indicators present in the 
>>>request. So at a high level, the fact that a message is 
>>>signed at all (with or without a display-name) could 
>>>plausibly signify that either the domain liked the 
>>>display-name or that it doesn't care about display-names, but 
>>>it could never plausibly signify that the domain had policies 
>>>about display-names and that it didn't like the display name, 
>>>regardless of whether or not the display-name itself is 
>>>included in the identity-string.
>>>
>>>
>>>>The issue with (G), of course, is that it does not 
>>>
>>>disambiguate the case where the domain has policies about 
>>>domain names and authorized this message from the case where 
>>>the domain doesn't have policies.
>>>
>>>
>>>>Jon Peterson
>>>>NeuStar, Inc.
>>>>
>>>>
>>>>
>>>>
>>>>>From: Paul Kyzivat [mailto:[email-masked]]
>>>>>Sent: Wednesday, April 06, 2005 2:31 PM
>>>>>To: Peterson, Jon
>>>>>Cc: [email-masked]
>>>>>Subject: Re: [Sip] sip-identity-05: display-name woes
>>>>>
>>>>
>>>>[snip]
>>>>
>>>>
>>>>
>>>>>I don't much like any of those alternatives.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>(F) If the display name is present but unauthorized, 
>>>>
>>>decline to sign the 
>>>
>>>
>>>>>message. If the display-name is present and authorized, include it.
>>>>>
>>>>
>>>>
>

---

From: "Gordon Ledgard" <[email-masked]>
Date: Tue, 19 Apr 2005 13:49:56 -0400

Now your talking.

________________________________

From: [email-masked] [mailto:[email-masked]] On Behalf Of
Francois Audet
Sent: Tuesday, April 19, 2005 1:13 PM
To: 'Michael Thomas'
Cc: [email-masked]'; 'Paul Kyzivat'; 'Peterson, Jon'
Subject: RE: [Sip] sip-identity-05: display-name woes

Agreed. That's what I meant: a secure P-Asserted-Identity. 

> From: Michael Thomas [mailto:[email-masked]] 
> Sent: Tuesday, April 19, 2005 10:09 
> To: Audet, Francois [SC100:9T51:EXCH] 
> Cc: [email-masked]'; 'Paul Kyzivat'; 'Peterson, Jon' 
> On Tue, 2005-04-19 at 09:48, Francois Audet wrote: 
> > It starts to sound like P-Asserted-Identity. 
> 
>   No. P-Asserted-Identity is forgery-4-free. A 
>   cryptographic means of establishing identity paired 
>   with the ability to bind it with authorization is 
>   what P-Asserted-Identity wants to be when it grows up. 
> 
>               Mike 
> 
> > 
> > > From: Michael Thomas [mailto:[email-masked]] 
> > > Sent: Monday, April 18, 2005 15:02 
> > > To: Audet, Francois [SC100:9T51:EXCH] 
> > > Cc: 'Peterson, Jon'; 'Paul Kyzivat'; 'Brian Rosen'; [email-masked]'

> > > On Mon, 2005-04-18 at 11:56, Francois Audet wrote: 
> > > > There is also the case where the ENUM database wouldn't 
> > > have the Name 
> > > > of the end-user because a block of phone numbers are assigned to

> > an 
> > > > organization (like 
> > > > a corporation). 
> > > > 
> > > > It this case, I'm assuming that the display name would be 
> > > provided by 
> > > > the organization itself, but the SIP service provider 
> would assert 
> > > > that the organization was allowed to populate the display name. 
> > > 
> > > This strikes me as most likely broken: it relies on transitive 
> > > trust, for one thing. And it also implies that there's 
> some sort of 
> > > trusted intermediary, which is not always the case; nor 
> should it be 
> > > *required* to be the case to get the desired authorization 
> > > characteristics. 
> > > 
> > > Much better would be for a way for the name space owner 
> > > to assert whether something using its name space is authorized or 
> > > not to be sending on its behalf. And DNSsec alone for 
> ENUM doesn't 
> > > provide this since DNSsec is a source authentication 
> scheme, not a 
> > > source authorization service. 
> > > 
> > > Of course, I think that sip-identity suffers from the 
> > > same problem... 
> > > 
> > >               Mike 
> > > 
> > > > 
> > > > Perhaps ENUM could be used to verify that, but it wouldn't 
> > > be used to 
> > > > derive the name itself (just the owner). 
> > > > 
> > > > Is this what you had in mind? 
> > > > 
> > > > > From: [email-masked] [mailto:[email-masked]] On 
> > > > > Behalf Of Peterson, Jon 
> > > > > Sent: Friday, April 08, 2005 12:54 
> > > > > To: Paul Kyzivat; Brian Rosen 
> > > > > Cc: [email-masked] 
> > > > > Some notes inline. 
> > > > > > Sent: Thursday, April 07, 2005 7:33 AM 
> > > > > > To: Brian Rosen 
> > > > > > Cc: Peterson, Jon; [email-masked] 
> > > > > > The most immediate problem I can see comes when your 
> > > call lands on 
> > > > a 
> > > > > Let's be careful, though. If I'm calling from 
> > > > > sip:[email-masked], what exactly does the gateway put in the 
> > > > > ISUP CgPN field, let alone what might it share as a textual 
> > > > > string in the GNP? That sort of SIP-ISUP mapping has bigger 
> > > > > problems than just how to deal with display-name. Clearly, if 
> > > > > the gateway is going to just make up a telephone number to 
> > > > > represent the calling party, all bets are off about how to 
> > > > > understand the GNP. 
> > > > > 
> > > > > Of course, the From header field of a SIP request 
> might contain 
> > > > > a tel URI, or a SIP URI with a tel URI user portion. 
> But in that 
> > > > > instance, provided it is a valid telephone number, 
> there is most 
> > > > > likely a CNAM record associated with it in the PSTN. 
> Gateways or 
> > > > > subsequent PSTN signaling elements can always do CNAM 
> queries to 
> > > > > recover the associated appropriate calling name to 
> populate the 
> > > > > GNP. But clearly there's no point in even getting the CNAM if 
> > > > > the telephone number itself can just trivially be 
> forged in SIP 
> > > > > From header fields. This gets into the whole question 
> of why a 
> > > > > gateway would ever trust an Identity header that asserts a 
> > > > > telephone number. As sip-identity-04 suggests, that 
> has to be a 
> > > > > subject for future work, but the only plausible lines 
> of thought 
> > > > > we have on this today are ENUM architectures. 
> > > > > 
> > > > > By launching an ENUM query, the story might go, the gateway 
> > > > > could learn who the number owner is, and thus who 
> should provide 
> > > > > the signature over the Identity information, and 
> conceivably the 
> > > > > gateway could also learn info like CNAM at the time. 
> This would 
> > > > > be tantamount to just reinventing CNAM in an IP context - 
> > > > > something that is probably inevitable if telephone 
> numbers are 
> > > > > to be used extensively in SIP, something that people are no 
> > > > > doubt noodling in various shops around the world today, and 
> > > > > something that probably wouldn't necessarily require 
> signing the 
> > > > > display-name in order for it to 
> > > > work. 
> > > > > 
> > > > > But until we boil that particular ocean, I feel that PSTN 
> > > > > interworking might not the best case on which to argue the 
> > > > > display-name issue one way or another. 
> > > > > 
> > > > > This list is for NEW development of the core SIP Protocol Use 
> > > > > [email-masked] for questions on current sip 
> > Use 
> > > > > [email-masked] for new developments on the 
> application of sip 
> > > > > 
> > > > > 
> > > > 
> > > > 
> > > > 
> > > > 
> > > 
> > 
> ______________________________________________________________________

> > > > This list is for NEW development of the core SIP Protocol Use 
> > > > [email-masked] for questions on 
> > > current sip Use 
> > > > [email-masked] for new developments on the application of sip 
> > > 
> > 
> > 
> > 
> > 
> ______________________________________________________________________

> > Use [email-masked] for questions on 
> current sip Use 
> > [email-masked] for new developments on the application of sip 
>

---

From: "Peterson, Jon" <[email-masked]>
Date: Tue, 19 Apr 2005 14:50:15 -0400

> Jon,
> 
> So what you are suggesting is:
> 
> - your identity draft is based on ability to determine
>    authenticator based on domain name in URI. It doesn't
>    work for phone numbers
> 
> - potentially that could be solved by having something
>    (e.g. enum) provide a specification for who the
>    authenticator should be for a particular tel: URI.
>    Given that, the identity draft could then provide
>    the authentication.

You have indeed hit the nail on the head.

> I think that makes a lot of sense as a potential way forward, though it 
> further increases the potential latency for a call.
> 
> And yes, this is just a bunch of hypotheticals. But a potentially 
> important bunch. It may form bhe beginning of a plan for where to go. 
> SIP is starting to get real traction in the consumer market now. This 
> stuff seems important for continued progress.

No doubt this is very significant, especially given that many SIP services in the marketplace use telephone numbers today.

> I think those hypotheticals need to include how meet perceived needs 
> such as display of calling name. Whether it comes from the display name 
> or from somewhere else can remain an open question for awhile.

Yes, we do need to have a story about display-names, and there is a (weak) one in the -04 version of sip-identity, even. I am increasingly of the opinion that we need a way to leave sip-identity-05 open about this as a topic of future work... I guess I'll make a proposal for that.

Jon Peterson
NeuStar, Inc.

> 	Paul
> 
> Peterson, Jon wrote:
> >  
> > Understand that most of what I wrote below was intended 
> only to support 
> > the design decision that identity for telephone numbers is 
> out of scope 
> > for the current sip-identity draft, and thus that TNs 
> wouldn't serve as 
> > a clear argument about display-names one way or another. 
> So, this is all 
> > just hypotheticals.
> >  
> > Currently, the ENUM database has no capability whatsoever 
> to provide 
> > names of end users; any such capability would need to be 
> invented before 
> > it could be leveraged. Presumably, if a block of phone numbers is 
> > delegated to an organization with ENUM, it is the 
> responsibility of that 
> > organization to populate any and all ENUM records, including any 
> > hypothetical records that assisted in providing names for 
> end users. 
> > Note that in many principalities, organizations are not 
> allowed to "own" 
> > telephone numbers, only carriers have that privilege. In 
> such contexts 
> > the idea of, say, an enterprise being responsible for this function 
> > wouldn't make any sense.
> >  
> > Strictly following my logic below, in a case where an 
> organization is 
> > responsible for a block of telephone numbers in ENUM, they 
> would be the 
> > appropriate signatory for any and all authentication service 
> > responsibilities when telephone numbers are used in the From header 
> > field of SIP requests. Thus, ENUM could be used to discover the 
> > organization responsible for the number, yes, and so to 
> determine who is 
> > eligible to provide an authentication service for the user 
> in question. 
> > While it could theoretically be used furthermore to derive the 
> > appropriate name, if we were to invent such a mechanism, 
> this would be a 
> > separable capability.
> >  
> > Jon Peterson
> > NeuStar, Inc.
> > 
> >     *From:* Francois Audet [mailto:[email-masked]]
> >     *Sent:* Monday, April 18, 2005 11:56 AM
> >     *To:* Peterson, Jon; 'Paul Kyzivat'; 'Brian Rosen'
> >     *Cc:* [email-masked]'
> >     *Subject:* RE: [Sip] sip-identity-05: display-name woes
> > 
> >     There is also the case where the ENUM database wouldn't have the
> >     Name of the
> >     end-user because a block of phone numbers are assigned to an
> >     organization (like
> >     a corporation).
> > 
> >     It this case, I'm assuming that the display name would 
> be provided
> >     by the organization itself, but the SIP service provider would
> >     assert that the organization was allowed to populate 
> the display name.
> > 
> >     Perhaps ENUM could be used to verify that, but it 
> wouldn't be used
> >     to derive the name itself (just the owner).
> > 
> >      > > The most immediate problem I can see comes when 
> your call lands
> >     on a
> >      > Of course, the From header field of a SIP request might
> >      > contain a tel URI, or a SIP URI with a tel URI user portion.
> >      > But in that instance, provided it is a valid telephone
> >      > number, there is most likely a CNAM record associated with it
> >      > in the PSTN. Gateways or subsequent PSTN signaling elements
> >      > can always do CNAM queries to recover the associated
> >      > appropriate calling name to populate the GNP. But clearly
> >      > there's no point in even getting the CNAM if the telephone
> >      > number itself can just trivially be forged in SIP From header
> >      > fields. This gets into the whole question of why a gateway
> >      > would ever trust an Identity header that asserts a telephone
> >      > number. As sip-identity-04 suggests, that has to be a subject
> >      > for future work, but the only plausible lines of thought we
> >      > have on this today are ENUM architectures.
> >      >
> >      > could learn who the number owner is, and thus who should
> >      > provide the signature over the Identity information, and
> >      > conceivably the gateway could also learn info like CNAM at
> >      > the time. This would be tantamount to just reinventing CNAM
> >      > in an IP context - something that is probably inevitable if
> >      > telephone numbers are to be used extensively in SIP,
> >      > something that people are no doubt noodling in various shops
> >      > around the world today, and something that probably wouldn't
> >      > necessarily require signing the display-name in 
> order for it to
> >     work.
> >      >
> >      > Use [email-masked] for questions on current
> >      > sip Use [email-masked] for new developments on the
> >      > application of sip
> >      >
> >      >
> > 
>

---

From: "Peterson, Jon" <[email-masked]>
Date: Tue, 19 Apr 2005 21:02:11 -0400

I agree with Paul that simply transposing a TEL URI into a SIP URI will not help certain classes of verifiers to make authorization decisions - most importantly PSTN gateways. An SS7 gateway doesn't want to take example.com's word that it is responsible for a given TN for the purposes of populating the corresponding ISUP fields, say. What this does provide is some degree of accountability for the source of the request, which is very important when handling certain uses of impersonation (finding someone to complain to about malicious or spam calls). sip-identity-05 does talk about the fact that assertion can be made for identities of the form sip:<tel>@<domain>. However, it is worth noting that source accountability is not the primary motivation for sip-identity - the primary motive is to allow a way for recipients of requests to make a verify requests with the signaling they have on hand.

To your second point:

> Ahh. This is a good point. Clearly, it makes little sense at a gateway 
> if the From field is sip:[email-masked]. It is for this reason I 
> believe that P-Asserted-ID allowed for multiple values, one SIP and one 
> tel. More abstractly, the problem is that I may in fact have MANY 
> identities, each within different namespaces. Which one of those 
> identities are meaningful to the recipient depends on who the recipient 
> is. Its nearly impossible for me to know ahead of time what is 
> meaningful to them, so P-A-ID allows me to include multiples.
>
> A similar problem arises in enterprise systems, whereby there is an 
> internal numbering plan which is effectively a different namespace from 
> e.164. One would ideally like to supply a caller ID in both namespaces, 
> so that internal phones can use the one from the private numbering plan, 
> and phones outside the enterprise can use the public one.
> 
> Unfortunately, RFC 3261 allows only a single value for the From header 
> field, and so this capability in P-A-ID cannot be readily extended to 
> sip-identity. That is the real problem, I think.

I'm not sure this is the real problem, and moreover, I'm not sure that going down the path of solving the problem in the context of sip-identity-05 would turn out to be practical anyway.

It is true that one may have many identities within different namespaces, and that potential recipients may have varying (possibly contradictory, even) policies about those identities. It goes beyond what is simply meaningful to the recipient - it is a question of what permissions will be applied by recipients. But, agreed that it is instructive to look at the case of different URI schemes, SIP and TEL, that might be a priority for different types of recipients.

The first issue I have is that my SIP service may not be associated with any telephone number. I have  several telephone numbers that are associated with me, of course, none of which I get from any SIP service provider, and consequently none that I might expect to be signed by an authentication service. The value of having my SIP service provider sign for these numbers is very small. Accordingly, inventing an Also-Known-As (AKA) header doesn't completely solve the problem for gateways.

If I do have a SIP service with a specifically associated telephone number, and I include it in an AKA header, this still leaves open the question of who should sign that AKA header. Even if my SIP service is responsible for that telephone number (whatever that means), how will a recipient ever know whether the SIP service is responsible or not? This is the real problem, from my perspective, with approaching telephone number identities.

Assuming the existance of AKA headers, arranging for the necessary authentication services to sign ten or fifteen identities is also a problem. If I have identities at iptel.org, fwd.net, neustar.biz, and so on, must I route each request through all of those services to get requisite signatures for AKA headers, on the hope that one of these identities might have a permission with a given recipient? Not an attractive architecture. 

It clearly isn't appropriate to include all possible AKAs for a given user in every call; users might not want to reveal the linkages between their various identities. But how can you decide which ones to include, given that you cannot anticipate the destination? Inventing the AKA header will not make it any easier for users to understand when they do and do not want to include particular identities.

>From a user interface perspective, I'm not sure how a user agent is supposed to render the presence of multiple AKAs if it understands all of them. Clearly only one thing should be rendered to a human recipient immediately (as opposed to what they can access if they are interested in inspecting the message in more detail). When the phone rings, though, you certainly can't render ten or fifteen identities as the caller.

I think users are accustomed to the idea of calling "as" someone, or accessing a service "as" someone. When I try to log in to Amazon, my eBay username doesn't work. When I talk to eBay, I am an eBay user. Similarly, when I place a call in the PSTN, I don't have multiple originating identities - I call from a specific number. Someone screening calls who does not receive or recognize my number may elect not to pick up the phone. My gmail account is not subscribed to the SIP mailing list, and I understand that if I send messages to [email-masked] from my gmail account, they will be held for moderator approval. This is not rocket science; users deal with this all the time.

Finally, let me conclude by saying that the problem of linking multiple identities together is a well studied one in the security industry. I hate to keep referring intractable problems for sip-identity to SAML, but SAML was born to link your various identities at various providers together. If there is a story to provide this capability, I'd like to suggest it probably lies in that work, and doesn't belong in sip-identity.

Jon Peterson
NeuStar, Inc.

> Sent: Tuesday, April 19, 2005 3:23 PM
> To: Jonathan Rosenberg
> Jonathan Rosenberg wrote:
> > inline.
> > 
> > Paul Kyzivat wrote:
> > 
> >> OK. I forgot that phone numbers were out of scope for this 
> discussion.
> > 
> > 
> > Yes and no. Identifiers that lack a domain structure are 
> out of scope. 
> > That means tel URI won't work. But, a SIP URL with the user 
> part as a 
> > phone number seems perfectly fine to me. There is the authorization 
> > issue, of whether you choose to trust that the domain asserting 
> > ownership of a phone number really does in fact own it. 
> Thats hard, and 
> > not really clear to me that it needs to be solved for sip 
> identity to be 
> > useful with phone numbers. The domain signature prevents the 
> > impersonation attacks we are primarliy concerned about.
> 
> Well, that is a partial solution, which is better than none. But it 
> presents the caller with a dilemma:
> 
> - using the sip form in From allows identity to work. But 
> using the sip 
> form also has the implied semantic that the caller can only be called 
> using SIP.
> 
> - using the tel form in From has no implied semantic about how the 
> caller may be called. Could be via SIP, but could be via PSTN, H.323, 
> whatever. But this form won't work with identity.
> 
> For instance, I can imagine a dual mode phone - SIP over WiFi plus 
> conventional cellular. I receive a call using SIP, and the phone 
> captures the from address URI in a directory. Later, when I only have 
> cellular coverage, I try to make a call using that directory 
> entry. If 
> it is a SIP URI it works. If it is a TEL URI it doesn't.
> 
> Of course the phone could go ahead and parse the sip uri for a phone 
> number and make a pstn call with it. But it isn't *supposed* to parse 
> the user part. If we want devices doing that, we should 
> change the rule 
> about interpretting the user part in the case when user=phone.
> 
> 	Paul
>

---

From: "Stastny Richard" <[email-masked]>
Date: Wed, 20 Apr 2005 09:57:13 +0200

Hi Jon,

Since I was not following this complicated thread completely,
I may not be up to date completely. Anyway:

> The first issue I have is that my SIP service may not be associated
with
> any telephone number. I have  several telephone numbers that are
> associated with me, of course, none of which I get from any SIP
service
> provider, and consequently none that I might expect to be signed by an
> authentication service. The value of having my SIP service provider
sign
> for these numbers is very small. Accordingly, inventing an
Also-Known-As
> (AKA) header doesn't completely solve the problem for gateways.

I agree what you stated here and with the rest of it. I just want to
point out from an emergency call point of view (this is out-of-scope
in ecrit), that if one wants to make an emergency call from a VoIP
account without an associated E.164 number to a PSAP on the PSTN, 
a CLI MUST be displayed at least to allow call-back. Therefore it
is required to generate a temporary CLI in the ESRP valid for some
time.

Some remarks on the ENUM stuff from previous posts:

I also want to note that ENUM is only for incoming calls, so a VoIP
provider may have no idea that an ENUM NAPTR is pointing to him.

I did not quite understand your proposal using ENUM for verification
of name for OUTGOING calls. The only way I could imagine is that a GW
to the PSTN before he inserts a E.164 CLI contained in the INVITE into 
the SS7 signaling to check if a corresponding NAPTR pointing to the
SIP URI contained in the From: Header exists. I have no idea how
truthworthy this is.

Of course one could enter a pointer to or directly a name in the ENUM
Domain (we did this for fun with a TXT record), but then you would have
the
privacy people again all over the place.

Regards
Richard

> Peterson, Jon
> Sent: Wednesday, April 20, 2005 3:02 AM
> To: Paul Kyzivat; Jonathan Rosenberg
> Cc: [email-masked]
> I agree with Paul that simply transposing a TEL URI into a SIP URI
will
> not help certain classes of verifiers to make authorization decisions
-
> most importantly PSTN gateways. An SS7 gateway doesn't want to take
> example.com's word that it is responsible for a given TN for the
purposes
> of populating the corresponding ISUP fields, say. What this does
provide
> is some degree of accountability for the source of the request, which
is
> very important when handling certain uses of impersonation (finding
> someone to complain to about malicious or spam calls). sip-identity-05
> does talk about the fact that assertion can be made for identities of
the
> form sip:<tel>@<domain>. However, it is worth noting that source
> accountability is not the primary motivation for sip-identity - the
> primary motive is to allow a way for recipients of requests to make a
> verify requests with the signaling they have on hand.
> 
> To your second point:
> 
> I'm not sure this is the real problem, and moreover, I'm not sure that
> going down the path of solving the problem in the context of
sip-identity-
> 05 would turn out to be practical anyway.
> 
> It is true that one may have many identities within different
namespaces,
> and that potential recipients may have varying (possibly
contradictory,
> even) policies about those identities. It goes beyond what is simply
> meaningful to the recipient - it is a question of what permissions
will be
> applied by recipients. But, agreed that it is instructive to look at
the
> case of different URI schemes, SIP and TEL, that might be a priority
for
> different types of recipients.
> 
> The first issue I have is that my SIP service may not be associated
with
> any telephone number. I have  several telephone numbers that are
> associated with me, of course, none of which I get from any SIP
service
> provider, and consequently none that I might expect to be signed by an
> authentication service. The value of having my SIP service provider
sign
> for these numbers is very small. Accordingly, inventing an
Also-Known-As
> (AKA) header doesn't completely solve the problem for gateways.
> 
> If I do have a SIP service with a specifically associated telephone
> number, and I include it in an AKA header, this still leaves open the
> question of who should sign that AKA header. Even if my SIP service is
> responsible for that telephone number (whatever that means), how will
a
> recipient ever know whether the SIP service is responsible or not?
This is
> the real problem, from my perspective, with approaching telephone
number
> identities.
> 
> Assuming the existance of AKA headers, arranging for the necessary
> authentication services to sign ten or fifteen identities is also a
> problem. If I have identities at iptel.org, fwd.net, neustar.biz, and
so
> on, must I route each request through all of those services to get
> requisite signatures for AKA headers, on the hope that one of these
> identities might have a permission with a given recipient? Not an
> attractive architecture.
> 
> It clearly isn't appropriate to include all possible AKAs for a given
user
> in every call; users might not want to reveal the linkages between
their
> various identities. But how can you decide which ones to include,
given
> that you cannot anticipate the destination? Inventing the AKA header
will
> not make it any easier for users to understand when they do and do not
> want to include particular identities.
> 
> >From a user interface perspective, I'm not sure how a user agent is
> supposed to render the presence of multiple AKAs if it understands all
of
> them. Clearly only one thing should be rendered to a human recipient
> immediately (as opposed to what they can access if they are interested
in
> inspecting the message in more detail). When the phone rings, though,
you
> certainly can't render ten or fifteen identities as the caller.
> 
> I think users are accustomed to the idea of calling "as" someone, or
> accessing a service "as" someone. When I try to log in to Amazon, my
eBay
> username doesn't work. When I talk to eBay, I am an eBay user.
Similarly,
> when I place a call in the PSTN, I don't have multiple originating
> identities - I call from a specific number. Someone screening calls
who
> does not receive or recognize my number may elect not to pick up the
> phone. My gmail account is not subscribed to the SIP mailing list, and
I
> understand that if I send messages to [email-masked] from my gmail
account,
> they will be held for moderator approval. This is not rocket science;
> users deal with this all the time.
> 
> Finally, let me conclude by saying that the problem of linking
multiple
> identities together is a well studied one in the security industry. I
hate
> to keep referring intractable problems for sip-identity to SAML, but
SAML
> was born to link your various identities at various providers
together. If
> there is a story to provide this capability, I'd like to suggest it
> probably lies in that work, and doesn't belong in sip-identity.
> 
> Jon Peterson
> NeuStar, Inc.
>

---

From: "Peterson, Jon" <[email-masked]>
Date: Wed, 20 Apr 2005 13:26:50 -0400

> Domain (we did this for fun with a TXT record), but then you would have the

I was thinking something along these lines, with a pointer to, say, an LDAP service rather than just a TXT record. All just speculation, of course; not suggesting that we propose this for ENUM, just saying that ENUM could conceivably be leveraged for something like this. If the gateway needs to do an ENUM lookup on the calling number anyway (to learn who is authoritative for the calling number, and consequently, who should be signing the SIP message), it might not even be that much extra work for the gateway.

Jon Peterson
NeuStar, Inc.