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

From: "Francois Audet" <[email-masked]>
Date: Tue, 19 Apr 2005 13:13:22 -0400

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

> -----Original Message-----
> 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'
> Subject: RE: [Sip] sip-identity-05: display-name woes
> 
> 
> 
> 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
> 
> > 
> > > -----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
> 
_______________________________________________
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:23:27 -0700

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

Oh, ok. I'm not a fan of P-A-I, so I thought you were
pressing one of my hot buttons :)

		Mike