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

From: "Francois Audet" <[email-masked]>
Date: Tue, 19 Apr 2005 12:48:34 -0400

It starts to sound like P-Asserted-Identity.

> -----Original Message-----
> 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]'
> Subject: RE: [Sip] sip-identity-05: display-name woes
> 
> 
> 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?
> > 
> > > -----Original Message-----
> > > 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]
> > > Subject: RE: [Sip] sip-identity-05: display-name woes
> > > 
> > > 
> > > 
> > > Some notes inline.
> > > 
> > > Jon Peterson
> > > NeuStar, Inc.
> > > 
> > > > -----Original Message-----
> > > > From: Paul Kyzivat [mailto:[email-masked]]
> > > > Sent: Thursday, April 07, 2005 7:33 AM
> > > > To: Brian Rosen
> > > > Cc: Peterson, Jon; [email-masked]
> > > > Subject: Re: [Sip] sip-identity-05: display-name woes
> > > > 
> > > [snip]
> > > > 
> > > > 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?
> > > 
> > > 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. 
> > > 
> > > _______________________________________________
> > > 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
> 
_______________________________________________
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: Michael Thomas <[email-masked]>
Date: Tue, 19 Apr 2005 10:09:19 -0700

> 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