Subject: RE: [Sipping] URIs for Gateways

From: "Peterson, Jon" <[email-masked]>
Date: Tue, 7 Jan 2003 06:35:17 -0500

First, it is possible, with the long-term identity mechanism, to assert two
identities in an authenticated identity body. So, you could have headers
corresponding to a telephone number and a SIP URI of a gateway or a user -
it strikes me that a telephone number is a good Reply-To, actually, when a
call comes from a gateway (originating in the PSTN, say) and the From header
field contains a SIP URI for the gateway, perhaps including some port
information. The identity that the gateway which handles a PSTN-SIP call
would assert needs to be its own, and recipients of calls from gateways need
to trust the telephone number provided by the gateway or not accordingly
(i.e. a signature from att.com vouching for such a request should be
acceptable).

Technologies like ENUM (when/where available) could enable gateways to
convert originating telephone numbers into URIs. Of course, a gateway
wouldn't be able to assert that identity to an intermediary unless it
possessed credentials appropriate to that URI, which is unlikely.

For outbound calls (SIP-PSTN), the gateway may or may not be able to map
(authenticated) SIP URIs representing originators to appropriate telephone
numbers via some sort of local tables as you suggested. If not, might also
pick a number from a pool, sure. The question of whether some authentication
service should be able to assert an originating telephone number (in an
authenticated identity body, say) that a gateway will use is also a trust
question - it is possible to put the tel URL in the AIB. If the gateway has
a reason to trust the authentication service, then certainly it should send
that number to the PSTN (when the protocol allows gateways to supply a
number, like with ISUP or Q.931). The gateway would be very ill advised to
take just any authentication service's word on this matter, though. 

The target of the calls for the PSTN should be identified with a telephone
number - at least, by the time the call arrives a gateway, it's Request-URI
should contain a tel URL or a SIP URI with a tel URL component. Whether the
originating UAC sets the To header field to a tel URL or a subsequent proxy
retargets the request doesn't seem to make much difference. ENUM can also
play a pretty obvious role here.

Jon Peterson
NeuStar, Inc.

> -----Original Message-----
> From: Rosen, Brian [mailto:[email-masked]]
> Sent: Monday, January 06, 2003 1:22 PM
> To: 'Peterson, Jon'; 'Drage, Keith (Keith)'; Rosen, Brian; 'Henning
> Schulzrinne'
> Cc: [email-masked]'
> Subject: RE: [Sipping] URIs for Gateways
> 
> 
> I agree with this.  I'm confused by those who seem to think that
> P-Asserted-Identity is needed when the long term solution is
> fully baked.  If the UA knows its identity, which seems
> reasonable, then it can "assert" it, and have that assertion
> validated by a trusted entity using cryptographic means.
> That is the fundamental idea I get out of Jon's proposal.
> The only circumstance where that won't work is where the
> UA doesn't know its identity.  I don't see that as a problem
> on any network I'm aware of, but ...... keep reading.
> 
> I do think there is a problem which this whole thread talks about.
> The basic reality is that many users of SIP UAs will have two
> identities - a SIP URI and a telephone number.  It may be
> necessary to assert both identities in one call, because the
> originator of the call does not know which identity may be
> needed.  There is no current header to do this.  I think that 
> it is advantageous to have a proxy be able to assert the phone 
> number.  Otherwise EVERY UA will have to be able to understand 
> that two identities are possible, know them both by some 
> unspecified means, and assert them in every call on every UA.  
> This seems unreasonable.  I'm not sure that there is a reason
> to have both identities validated, but there could be.
> 
> Brian
> > -----Original Message-----
> > From: Peterson, Jon [mailto:[email-masked]]
> > Sent: Monday, January 06, 2003 2:06 PM
> > To: 'Drage, Keith (Keith)'; Rosen, Brian; 'Henning Schulzrinne'
> > Cc: [email-masked]'
> > Subject: RE: [Sipping] URIs for Gateways
> > 
> > 
> > 
> > RFC3325 was 'short-term' because it was achievable in the 
> > short-term and has
> > a more limited (but still useful) applicability. The 
> > long-term identity
> > solution must be a superset of the functionality of 
> > short-term - it must
> > address the short-term scope of applicability, but also 
> > encompass general
> > needs for network assertion (which SIP does have). 
> > Accordingly, it takes
> > longer to develop. At such a time as there is a workable 
> > long-term solution,
> > it would be pointless to allow both to be SIP standards 
> > except as part of a
> > transition plan. So in that sense, I disagree - one is a 
> > short-term solution
> > of the other.
> > 
> > Jon Peterson
> > NeuStar, Inc.
> > 
> > > -----Original Message-----
> > > From: Drage, Keith (Keith) [mailto:[email-masked]]
> > > Sent: Friday, January 03, 2003 8:20 AM
> > > To: Rosen, Brian; 'Henning Schulzrinne'
> > > Cc: [email-masked]'
> > > Subject: RE: [Sipping] URIs for Gateways
> > > 
> > > 
> > > Network asserted identity (RFC 3325) is the real network 
> > > asserted identity. It is a P header not because it is 
> > > preliminary, but because the whole idea of network assertion 
> > > is not generally applicable to all SIP architectures. For RFC 
> > > 3325 a trust domain needs to exist between proxies that use 
> > > the P-Asserted-Identity in order to guarantee the privacy, 
> > > this does not exist in all SIP networks. In does in 3GPP and 
> > > therefore 3GPP are using RFC 3325.
> > > 
> > > If you want to let the 1et outbound proxy assert identity on 
> > > your behalf then use RFC 3325. If you want to let application 
> > > servers with whom you have a secure relationship assert your 
> > > identity, then use Jon Petersons drafts, when they eventually 
> > > become RFCs. 
> > > 
> > > One is not a short term solution for the other.
> > > 
> > > Keith
> > > 
> > > Keith Drage
> > > Lucent Technologies
> > > Tel: +44 1793 776249
> > > Email: [email-masked] 
> > > 
> > > > -----Original Message-----
> > > > From: Rosen, Brian [mailto:[email-masked]]
> > > > Sent: 02 January 2003 20:49
> > > > To: 'Henning Schulzrinne'
> > > > Cc: [email-masked]'
> > > > Subject: RE: [Sipping] URIs for Gateways
> > > > 
> > > > 
> > > > Yeah, I actually thought of just allowing a display name in the
> > > > Request URI and using that, but it seems so foolish to make 
> > > a change,
> > > > and have that change not be exactly what we needed.
> > > > 
> > > > We could use NAI.  I suppose we could use a P-Asserted-Identity
> > > > with a tel URI:  
> > > > P-Asserted-Identity tel:+17247426826
> > > > 
> > > > What do we do when the "real" NAI happens?
> > > > 
> > > > Brian
> > > > 
> > > > > -----Original Message-----
> > > > > From: Henning Schulzrinne [mailto:[email-masked]]
> > > > > Sent: Thursday, January 02, 2003 3:10 PM
> > > > > To: Rosen, Brian
> > > > > Cc: [email-masked]'
> > > > > Subject: Re: [Sipping] URIs for Gateways
> > > > > 
> > > > > 
> > > > > > I'd like to get a new header for the calling party number on
> > > > > > an outbound call.  That way, the translator can be 
> a proxy and
> > > > > > add the header.  I'd recommend that gateways allow 
> the number
> > > > > > to be in the From.   
> > > > > 
> > > > > Generalized, you want something like the Request-URI 
> > that can be 
> > > > > modified or inserted. How about the NAI stuff?
> > > > > 
> > > > _______________________________________________
> > > > Sipping mailing list  
> > https://www1.ietf.org/mailman/listinfo/sipping
> > > > This list is for NEW development of the application of SIP
> > > > Use [email-masked] for questions on 
> current sip
> > > > Use [email-masked] for new developments of core SIP
> > > > 
> > > _______________________________________________
> > > Sipping mailing list  
> https://www1.ietf.org/mailman/listinfo/sipping
> > > This list is for NEW development of the application of SIP
> > > Use [email-masked] for questions on current sip
> > > Use [email-masked] for new developments of core SIP
> > > 
> > _______________________________________________
> > Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
> > This list is for NEW development of the application of SIP
> > Use [email-masked] for questions on current sip
> > Use [email-masked] for new developments of core SIP
> > 
> 
_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use [email-masked] for questions on current sip
Use [email-masked] for new developments of core SIP

---

From: "Dean Willis" <[email-masked]>
Date: Tue, 14 Jan 2003 18:04:03 -0600

Jon said:
> Technologies like ENUM (when/where available) could enable 
> gateways to convert originating telephone numbers into URIs. 
> Of course, a gateway wouldn't be able to assert that identity 
> to an intermediary unless it possessed credentials 
> appropriate to that URI, which is unlikely.

I think the magic subtlety here is that the gateway would be asserting the
PSTN number with its OWN credentials, meaning "I, Gateway, believe that I
got this call from +1234567890, which I appear to be able to enum map to
[email-masked]". I think this should prove quite useful.

--
Dean