[SIPForum-techwg] naming issues in PBX to SP interworking

Sun Sep 4 23:21:29 EDT 2005

On Sep 1, 2005, at 15:15, Chris Gatch wrote:

> Rohan,
>
> Clipping from your e-mail a few days ago with call flow examples
> regarding identity and naming conventions, you wrote
>
>> Acme's LA PBX gets a call to DC.  The PBX opens a TLS connection to
>> provider.net and provides its client certificate.  Acme sends an
>> INVITE that looks like this:
>>
>> INVITE sip:+12025551222 at provider.net;user=phone SIP/2.0
>> From: "Alice Andrews"
>> <sip:+13105554233 at lax-pbx.acemwidgets.com;user=phone>
>> Identity: # appropriate hash here #
>> Identity-Info:
>> <https://sec.acmewidgets.com/acme-cert.pem>;alg=rsa-sha1
>
> Regarding the use of the Indentity and Identity-Info fields, are you
> suggesting that we require support for draft-ietf-sip-identity-05?

While I think it is a good idea to encourage use of the Identity 
mechanism, I don't think it is essential that we use it in the first 
version of our spec.  However, I included it because it suggests a 
requirement that we offer a smooth migration path to that mechanism in 
the future.  If the enterprise includes an Identity header, this 
shouldn't break anything in the SP network or violate the spec in any 
way.  I also wanted to point out that having a certificate and using 
the Identity mechanism is not necessarily incompatible with having a 
domain name which you "borrow" from a service provider. The possible 
use of the Identity mechanism also has consequences for calls which are 
anonymous with respect to the PSTN or with respect to the ultimate 
recipient.  In my examples, the right-hand-side of the SIP URI is a 
domain name which provides information about the organization making 
the call, even if it does not reveal a specific user identity.  This 
should not be an issue when the call terminates on the PSTN, but it 
could be an issue if you have an IP to IP call.

> This
> seems to get back to the question of when it's OK to require support 
> for
> an IETF draft in a SIP Forum recommendation.

Regardless if we use the Identity mechanism in this spec, I am hoping 
that the identity mechanism is approved before our first recommendation 
is finalized.

> Second question, and forgive my basic understanding of TLS and the
> identity draft, but what would drive the billing identify in the 
> example
> above?  Is there anything in the cert that can be used or would the
> service provider need to use something from the SIP header such as the
> domain of the user in the FROM field or PAI header?

The SubjectName or SubjectAltName of the certificate will have the 
domain name or SIP URI (respectively):
  [sip:]lax-pbx.acemwidgets.com

The SP can use this to populate a PAI (if the From uses an anonymous 
right-hand-side) or to verify the right-hand-side of the From URI, just 
like it can use a digest username to do the same thing.

thanks,
-rohan

> Chris
>
>
>
>
>> -----Original Message-----
>> From: Chris Gatch
>> Sent: Friday, August 26, 2005 4:11 PM
>> To: 'Rohan Mahy'; 'SIP Forum Tech WG'
>> Subject: RE: [SIPForum-techwg] naming issues in PBX to SP interworking
>>
>> Wow, Rohan, thanks for the detailed example.
>>
>> It's hard to argue with the elegance of using TLS if everyone
>> is capable and willing to implement it, and the examples you
>> provided really make that clear.  I also like preserving the
>> PAI header for the scenario you described below rather than
>> using the FROM field for the billing identity and the PAI/PPI
>> field for user identity.  If at all possible, I believe we
>> should leave the FROM field alone.
>>
>> The only concern I have with the outline in your thread below
>> and the proposal from your previous e-mail on this subject is
>> allowing the PBX to optionally use digest authentication *or*
>> TLS to convey its billing identity.  This flexibility for the
>> enterprise means the service provider has to support both
>> methods.  Coming from a world where I know how hard and
>> expensive billing methodologies and systems are to implement,
>> I don't think this will be adopted broadly enough to get the
>> results we want in this TG.
>>
>> A model that accommodates the broadest range of currently
>> shipping systems, yet also moves us in the right direction would be ..
>>
>> 1) 	The enterprise MUST support TLS with server-side
>> authentication.  Rohan, I took this language from your
>> e-mail, and I assume you mean the ability to open a TLS
>> connection to/from the SP with verification by the PBX of the
>> cert  provided by the the SP, right?
>> 2) 	The Enterprise SHOULD support TLS client-side/mutual
>> authentication. Following on the last point, I took this to
>> mean the ability to open a TLS connection to/from the SP with
>> mutual authenication.  What's different from (1) is that the
>> PBX is able to provide its own cert to the SP for verification.
>> 3)	The enterprise MUST support the ability to respond to
>> Digest authentication challenges for any methods except
>> CANCEL and ACK.
>>
>> 4) 	The SP MUST support both TLS (including mutual
>> authentication) and Digest (as the challenging party)
>> 5)	The SP may derive billing identity from either the TLS
>> cert or digest authentication credentials.
>>
>> The way I see it, requiring the PBX and SP to support digest
>> authentication is sleeves off the vest for most implementers.
>>  It also provides an immediate standard approach that most
>> implementers can use. I know supporting digest forces an
>> enterprise with a disaggregated deployment to add an
>> additional system to support the digest capability, but
>> asking and industry of SPs to deploy the ability to derive
>> billing identity from both TLS and digest is a much higher hurdle.
>>
>> Thanks again for the on-going dialog.  I think at least a few
>> of us are getting close to some type of consensus.
>>
>> Chris
>>
>>> -----Original Message-----
>>> From: techwg-bounces at sipforum.org
>>> [mailto:techwg-bounces at sipforum.org] On Behalf Of Rohan Mahy
>>> Sent: Friday, August 26, 2005 1:59 PM
>>> To: SIP Forum Tech WG
>>> Subject: [SIPForum-techwg] naming issues in PBX to SP interworking
>>>
>>> Hi,
>>>
>>> We talked sometime back about Identities and naming and
>> addressing.  I
>>> think there are a bunch of subtle issues we haven't
>> discussed here.  I
>>> wanted to provide an example of my thinking to spur
>> discussion about
>>> these issues.  Many of these have to do with naming
>> conventions when
>>> addressing resources in the other administrative domain.
>>>
>>> Lets take two customers and a service provider to
>> participate in this
>>> example.  Each of them has reserved a domain name for web hosting.
>>> Big Provider has full control over their DNS.
>>> Acme Widgets has full control over their DNS.  Bob's
>> Billiards has DNS
>>> hosted by their Web and Mail provider and is very happy with the
>>> service, but doesn't have access to the DNS service, nor
>> any knowledge
>>> or interest to configure SRV records.
>>>
>>> Big Provider Networks, Inc.  ==> provider.net Acme Widgets
>> Corp.  ==>
>>> acmewidgets.com Bob's Billiard Shop ==> bobs-billards.com
>>>
>>> --------
>>>
>>> Acme Widgets signs up for PSTN access using SIP from Big
>> Provider.
>>> Acme gives each PBX a public IP address (either via a
>> mapping/pinholes
>>> through their NAT/FW and split DNS, or by putting the PBXes
>> in their
>>> DMZ), and they put the public IP addresses and appropriate
>> NAPTR and
>>> SRV records in their DNS zone file.  Acme gets a block of
>> numbers (+1
>>> 212 555 2xxx) for their New York PBX
>>> (nyc-pbx.acmewidgets.com) and another block of numbers (+1 310 555
>>> 4xxx) for their Los Angeles PBX (lax-pbx.acmewidgets.com).
>> The NY PBX
>>> has a cert for nyc-pbx.acmewidgets.com and the LA PBX has a
>> cert for
>>> lax-pbx.acmewidgets.com.  Big Provider sets up this
>> customer in their
>>> billing system and configures the Acme phone number blocks to
>>> correspond to the correct DNS names.
>>>
>>> Acme's LA PBX gets a call to DC.  The PBX opens a TLS connection to
>>> provider.net and provides its client certificate.  Acme sends an
>>> INVITE that looks like this:
>>>
>>> INVITE sip:+12025551222 at provider.net;user=phone SIP/2.0
>>> From: "Alice Andrews"
>>> <sip:+13105554233 at lax-pbx.acemwidgets.com;user=phone>
>>> Identity: # appropriate hash here #
>>> Identity-Info:
>>> <https://sec.acmewidgets.com/acme-cert.pem>;alg=rsa-sha1
>>>
>>> When Acme's New York PBX gets a calls to San Jose (with
>> anonymity), it
>>> opens a TLS connection to provider.net and provides its client
>>> certificate. Acme then sends an INVITE to Big Provider that looks
>>> something like this.
>>>
>>> INVITE sip:+14085557000 at provider.net;user=phone SIP/2.0
>>> To: <tel:+14085557000>
>>> From: "Anonymous" <sip:anonymous at acmewidgets.com>
>>> Privacy: id
>>> P-Preferred-Identity:
>>> <+12125552355 at nyc-pbx.acmewidgets.com;user=phone>
>>> Identity: # appropriate hash here #
>>> Identity-Info:
>>> <https://sec.acmewidgets.com/acme-cert.pem>;alg=rsa-sha1
>>>
>>> Big Provider takes these INVITEs and verifies that each
>> call was from
>>> a valid customer, and that this customer is allowed to use
>> the source
>>> telephone number in the From (if any) and that the customer
>> can call
>>> the target address.
>>>
>>> Big Provider uses P-Asserted-Identity to provide private
>> caller ID to
>>> the PSTN, so it adds a PAI header for the 2nd call.  If
>> Acme omitted
>>> the PPI header, Big Provider could still add a PAI header with the
>>> main number for Acme Widgets.
>>>
>>> Big Provider will do billing elsewhere in its network than
>> the first
>>> hop.  Big Provider could do accounting based on the
>> right-hand side of
>>> the From URI or the PAI URI.  Big Provider might want to
>> include other
>>> billing policy information in the INVITE.  It could
>> also/alternatively
>>> create an OSP token or some other billing header at its
>> first hop and
>>> use that inside its network.  It would need to delete the header
>>> before forwarding outside its domain or federation of domains.
>>>
>>> When Big Provider sends a call to Acme, it sends an INVITE
>> like this:
>>>
>>> INVITE sip:+12125552000 at nyc-pbx.acmewidgets.com;user=phone SIP/2.0
>>> To: <tel:+12125552000>
>>> From: <sip:+16165551289 at provider.net;user=phone>
>>> Identity: # appropriate hash here #
>>> Identity-Info: <https://id.provider.net/cert.pem>;alg=rsa-sha1
>>>
>>> Acme can verify that the call came from provider.net over an
>>> authenticated TLS connection
>>>
>>> ------
>>>
>>> Bob's Billiards moves to a larger warehouse and decides to get PSTN
>>> access using SIP. He signs up for service from Big Provider
>> and gets a
>>> block of 10 numbers (+1 312 555 145x).
>>> Big Provider creates a DNS subdomain
>>> (cust-bobbilliards.provider.net) that Bob can use since he doesn't
>>> have access to his own DNS.  Bob's NAT gets a dynamic IP
>> address from
>>> his DSL provider.  It changes every few weeks, since he turns the
>>> power off to the warehouse when he leaves for the weekend.
>>> Bob's phone equipment discovers the IP address when it boots up and
>>> uses Dynamic DNS Updates or an update message to an HTTPS server in
>>> Big Provider's network to update its DNS record.
>>>
>>> GET
>>> https://dyndns.provider.net/update?domain=cust-
>>> bobbilliards&ip=17.23.41.55&port=5061 HTTP/1.0
>>>
>>> Now one of Bob's salespeople gets a call. Big Provider
>>> (provider.net) uses regular DNS resolution to find
>>> cust-bobbilliards.provider.net, and opens a TLS connection to
>>> 17.23.41.55:5061.  It sends an INVITE like this (note that
>> Bob's PBX
>>> is the only server allowed to retarget in the
>>> cust-bobbilliards.provider.net, even though the DNS service
>> is run by
>>> the provider).
>>>
>>> INVITE sip:+13125551457 at cust-bobbilliards.provider.net;user=phone
>>> SIP/2.0
>>> To: <tel:+13125551457>
>>> From: "Amy's Bar and Grill"
>> <sip:+12165559080 at provider.net;user=phone>
>>> Identity: # appropriate hash here #
>>> Identity-Info: <https://id.provider.net/cert.pem>;alg=rsa-sha1
>>>
>>> Similarly and outgoing call might look like this:
>>>
>>> INVITE sip:+12165559080 at provider.net;user=phone
>>> To: <tel:+12165559080>
>>> From:  "Bob's Billiards"
>>> <sip:+13125551454 at cust-bobbilliards.provider.net;user=phone>
>>>
>>> Big Provide still uses the client certificate from the TLS
>> connection
>>> if it was provided to verify the customer is authentic.  If
>> Bob's PBX
>>> did not provide a client certificate, provider.net can
>> still challenge
>>> Bob's PBX for credentials.  In my example, the digest username is
>>> "cust-bobbilliards" and the realm is "provider.net".
>>>
>>> hope this helps.
>>> thanks,
>>> -rohan
>>>
>>> _______________________________________________
>>> techwg mailing list
>>> Send mail to: techwg at sipforum.org
>>> Unsubscribe or edit options at:
>>> http://sipforum.org/mailman/listinfo/techwg
>>>
>>