TITLE:SIP RPH Signing Use Cases for NS/EP NGN-PS

TITLE:SIP RPH Signing Use Cases for NS/EP NGN-PS

ATIS PTSC

May8, 2017

Bellevue, MA (AMOC)

Contribution

TITLE:SIP RPH Signing Use Cases for NS/EP NGN-PS

SOURCE*:Vencore Labs, OEC

ISSUE NUMBER:

______

Abstract

This contribution discussesSIP RPH Signing Use Cases for NS/EP NGN-PS.

______

1Introduction

This contribution discussesSIP RPH Signing Use Cases for NS/EP NGN Priority Service (NGN-PS). Specifically, signing of the “ets” and “wps” namespaces.

2SIP RPH Signing Use Case Examples for NS/EP NGN-PS

This section discusses example use cases for signing of the SIP RPH “ets” and ‘wps” namespaces in support of NS/EP NGN-PS calls/sessions. The example use cases are organized as follows:

(a)NS/EP NGN-PS Access Number (AN) calls/sessions,

(b)NS/EP NGN-PS Feature Code (FC)and FC+AN call/sessions,

(c)NS/EP NGN-PS calls/sessions with anonymity (i.e., Number Translation (NT) calls/sessions).

2.1General Assumptions

The following are general assumptions:

  1. It is assumed that a PASSporT extension is defined and used for signing namespaces populated in the Session Initiation Protocol “Resource-Priority” Header (SIP RPH) field.
  2. Signing of telephone numbers (i.e., Calling Party Numbers) is independent of signing SIP RPH names spaces (e.g., “ets” and “wps”). A separate SIP identity header is used for SIP RPH namespace claims from that used for telephone number claims (i.e., SHAKEN assertion about CPN).
  3. An NS/EP NGN-PS Service Provider (e.g., authorized provider of GETS and WPS) would include a PASSPort token signing the namespaces populated in the SIP RPH field before it is sent across an Internet Protocol Network-to-Network Interconnection (IPNNI). For example, after performinga GETS PIN authentication and authorization, assertion about the ”ets” name space is included in a PASSPort in a SIP identity header. In the case of subscription-based authentication and authorization of a WPS call/session, assertion about the “wps” namespace is included in a PASSPort token.
  4. The procedures for GETS and WPS authentication and authorization, and SIP signaling involving populating and using the “ets” and “wps” namespace parameters of the SIP RPH field is part of normal SIP signaling and NS/EP NGN-PS defined procedures that is separate from the cryptographic authentication (i.e., signing) and verification of the “ets” and “wps” namespace parameters.
  5. Only RPH namespaces in SIP Invites are signed. SIP RPH are also populated and used in the backward direction (e.g., SIP response messages) for NS/EP NGN-PS signaling. However, signing of SIP RPH namespaces or the inclusion of the original signed token in the backward direction (e.g., response messages) is for further study.

Editor Note: RFC4474bis only specifies procedures for the SIP Invite.

  1. The PASSport extension mechanism for RPH signing is used by the NS/EP NGN-PS Service Provider as a security protection tool. Originating NS/EP NGN-PS Service Provider are responsible for signing all NS/EP NGN-PS SIP Invites. However, a receiving Service Provider may decide whether all signed tokens are valued or only selected token are validated based on their security policy and threat detection mechanisms.

2.2NS/EP NGN-PS AN Call/Sessions

This section discusses example use cases for NS/EP NGN-PS AN call/sessions. The following are assumptions:

  1. As part of normal NS/EP NGN-PS procedure, the Service Provider would populate the “ets” namespace parameter in a SIP RPH after performing a PIN authentication validatingthe Service User authorization for the NS/EP NGN-PS AN call/session.
  2. When the “ets” namespace is populated in a SIP RPH, an assertion for full attestation of the “ets” namespace is signed in a PASSPorT token and included in an identity header.
  3. If a service provider(e.g., LEC) is only responsible for routing a NS/EP NGN-PS AN call with priority based on the dialed digits to a NS/EP NGN-PS Service Provider for PIN verification, and the “ets” namespace is populated, options are (a) the “ets” namespace is not signed or (b) it is signed with a partial attestation of the “ets” namespace.

NS/EP NGN-PS Access Number (AN) calls/sessions
# / Call Scenario / RPH Namespace Signing / RPH Namespace Validation
1 / GETS-AN Origination in LEC: LEC is NS/EP Service Provider responsible for PIN validation / GETS-AN call originates in LEC network (e.g., residential or enterprise access). The LEC is a NS/EP NGN-PS Service Provider responsible for PIN verification:
  • NS/EP Service Provider performs GETS PIN validation and authorization and populate the “ets” namespace as part of normal NS/EP NGN-PS procedures.
  • NS/EP NGN-PS Service Provider signs an assertion for full attestation of the “ets” namespace in a PASSPorT token and includes it in a SIP identity header.
/ Service Provider receiving the SIP message acts on the information in the SIP identity header by validating the signed claim in the PASSporT token.
Successful validation of the signed attestation of the “ets” namespace provides the receiving NS/EP NGN-PS with assurance that the “ets” namespace is valid and priority treatment can be provided in completing the call/session.
If the validation of the signed “ets” namespace is not successful, the call/session should continue as a normal call.
2 / GETS-AN Origination in LEC; LEC is not NGN-PS Service Provider; call routed to NS/EP NGN-PS Service Provider (i.e., IXC) / GETS-AN call originates in a LEC network (e.g., residential or enterprise access). LEC is not a NS/EP NGN-PS Service Provider and routes call based on the dialed digits to an NS/EP NGN-PS Service Provider (i.e., IXC):
  • LEC routes call to NS/EP NGN-PS (IXC).
  • Receiving NS/EP Service Provider (IXC) performs GETS PIN validation and authorization and populates the “ets” namespace as part of normal NS/EP NGN-PS procedures.
  • NS/EP NGN-PS Service Provider signs an assertion for full attestation of the “ets” namespace in a PASSPorT token and includes it in a SIP identity header.
/ A Service Provider receiving the SIP message acts on the information in the SIP identity header by validating the signed claim in the PASSporT token.
Successful validation of the signed attestation of the “ets” namespace provides the receiving Service Provider with assurance that the “ets” namespace is valid and priority treatment can be provided in completing the call/session.
If the validation of the signed “ets” namespace is not successful, the call/session should continue as a normal call.
3 / GETS-AN Origination in LEC; LEC is not NGN-PS Service Provider responsible for PIN validation; call routed to NS/EP NGN-PS Service Provider (i.e., IXC) for PIN verification / GETS-AN call originates in a LEC network (e.g., residential or enterprise access). LEC is responsible for routing call with priority based on the dialed digits to an NS/EP NGN-PS Service Provider (i.e., IXC):
  • LEC routes call with priority to IXC. The “ets” namespace if populated is either (a) not signed or (b) signed with partial attestation
  • Receiving NS/EP Service Provider (IXC) performs GETS PIN validation and authorization and populates the “ets” namespace as part of normal NS/EP NGN-PS procedures.
  • NS/EP NGN-PS Service Provider signs an assertion for full attestation of the “ets” namespace in a PASSPorT token and includes it in a SIP identity header.
/ A Service Provider receiving the SIP message acts on the information in the SIP identity header by validating the signed claim in the PASSporT token.
Successful validation of the signed attestation of the “ets” namespace provides the receiving Service Provider with assurance that the “ets” namespace is valid and priority treatment can be provided in completing the call/session.
If the validation of the signed “ets” namespace is not successful, the call/session should continue as a normal call.

2.3NS/EP NGN-PS FCand FC+AN Call/Sessions

This section discusses example use cases for NS/EP NGN-PS FC call/sessions. The following are assumptions:

  1. As part of normal NS/EP NGN-PS procedure, the Service Provider would populate the “wps” namespace parameter in a SIP RPH after performing subscription-based verification of the Service User authorization for the NS/EP NGN-PS FC call/session (e.g., verification that the device is subscribed to WPS).
  2. When the “wps” namespace is populated in a SIP RPH, an assertion for full attestation of the “wps” namespace is signed in a PASSPorT token and included in an identity header.
  3. When a NS/EP NGN-PS Service User makes a FC+AN call/session, the originating WPS provider provides priority in the wireless access network and routes the call to a core network for PIN authentication. In this case, the “wps” namespace is populated by the wireless network and the “ets” namespace by the core network.

NS/EP NGN-PS Feature Code (FC) calls/sessions
# / Call Scenario / RPH Namespace Signing / RPH Namespace Validation
1 / FC Origination in NS/EP NGN-PS Service Provider Network / FC call originates in NS/EP NGN-PS Service Provider Network (i.e., wireless service provider is a WPS provider):
  • NS/EP Service Provider (Wireless Network) performs WPS authentication/authorization of the UE and populate the “wps” namespace as part of normal NS/EP NGN-PS procedures
  • NS/EP NGN-PS Service Provider signs an assertion for full attestation of the “wps” namespace in a PASSPorT token and includes it in a SIP identity header.
/ A Service Provider receiving the SIP message acts on the information in the SIP identity header by validating the signed claim in the PASSporT token.
Successful validation of the signed attestation of the “wps” namespace provides the receiving Service Provider with assurance that the “wps” namespace is valid and priority treatment can be provided in completing the call/session.
If the validation of the signed “wps” namespace is not successful, the call/session should continue as a normal call.
2 / NS/EP NGN-PS FC+AN Origination / In this example, a NS/EP NGN-PS Service User initiates a FC+ AN call:
  • NS/EP Service Provider (Wireless Network) performs WPS authentication/authorization of the UE and populate the “wps” namespace as part of normal NS/EP NGN-PS procedures
  • NS/EP NGN-PS Service Provider signs an assertion for full attestation of the “wps” namespace in a PASSPorT token and includes it in a SIP identity header and routes call to NS/EP Service Provider (IXC)
  • Receiving NS/EP Service Provider (IXC) performs GETS PIN validation and authorization and populates the “ets” namespace as part of normal NS/EP NGN-PS procedures.
  • NS/EP NGN-PS Service Provider signs an assertion for full attestation of the “ets” namespace in a PASSPorT token and includes it in a SIP identity header.
/ A Service Provider receiving the SIP message acts on the information in the SIP identity header by validating the signed claims in the PASSporT tokens.
Successful validation of the signed attestation of the “wps” and “ets” namespaces provide the receiving Service Provider with assurance that the namespacesare valid and priority treatment can be provided in completing the call/session.
If the validation of the signed “wps” and “ets” namespace are not successful, the call/session should continue as a normal call.

2.4NS/EP NGN-PS calls/sessions with anonymity (i.e., Number Translation (NT) calls/sessions)

This section discusses example use cases for NS/EP NGN-PS call/sessions with anonymity (i.e., NT calls/sessions). The following are assumptions:

  1. As part of normal NS/EP NGN-PS procedure, the Service Provider would populate the “wps” and “ets” namespace parameters in a SIP RPH after performing subscription-based and PIN verification of the Service User authorization for the NS/EP NGN-PS call/session respectively.
  2. If a SIP identity header with signed assertion of the CPN is received and the initially signaled CPN is modified by the NS/EP NGN-PS Service Provider for anonymity, the received SIP identity header is stripped.

Example NS/EP NGN-PS Calls with Anonymity
# / Call Scenario / RPH Namespace Signing / RPH Namespace Validation
1 / GETS-NT or GETS-PDN with Anonymity Origination in NS/EP Service Provider network / GETS-NT or GETS-PDN call originates in NS/EP Service Provider network (e.g., residential or enterprise access):
  • NS/EP NGN-PS Service Provider performs GETS PIN validation and authorization and populates the “ets” namespace as part of normal NS/EP NGN-PS procedures.
  • NS/EP NGN-PS modifies Caller-ID for anonymity as part of normal
  • NS/EP NGN-PS Service Provider signs an assertion for full attestation of the “ets” namespace in a PASSPorT token and includes it in a SIP identity header.
  • NS/EP NGN-PS Service Provider may sign an assertion for full attestation of the anonymityinformation in the CPN in a PASSPorT token and includes it in a SIP identity header.
/ Service Provider receiving the SIP message acts on the information in the SIP identity header by validating the signed claim in the PASSporT token.
Successful validation of the signed attestation of the “ets” namespace provides the receiving NS/EP NGN-PS with assurance that the “ets” namespace is valid and priority treatment can be provided in completing the call/session.
If the validation of the signed “ets” namespace is not successful, the call/session should continue as a normal call.
If a signed assertion for the anonymityinformation in the CPN field is received, it is validated and used to determine Display information.
2 / GETS-NT or GETS-PDN with Anonymity Origination in LEC network / GETS-NT or GETS-PDN call originates in a LEC network where the LEC is not a NS/EP Service Provider:
  • LEC signs attestation of the Caller-IDin a PASSPort token and includes it in a SIP identity header; and routes call to the NS/EP Service Provider (IXC).
  • Receiving NS/EP Service Provider (IXC) performs GETS PIN validation and authorization and populates the “ets” namespace as part of normal NS/EP NGN-PS procedures.
  • NS/EP NGN-PS modifies Caller-ID for anonymity as part of normal NS/EP NGN-PS procedures
  • NS/EP NGN-PS Service Provider signs an assertion for full attestation of the “ets” namespace in a PASSPorT token and includes it in a SIP identity header.
  • NS/EP NGN-PS Service Provider removes SIP identity header received from LEC with signed Caller-ID. NS/EP NGN-PS may sign an assertion for full attestation for the anonymity information in the CPN field in a PASSPorT token and includes it in a SIP identity header.
/ Service Provider receiving the SIP message acts on the information in the SIP identity header by validating the signed claim in the PASSporT token.
Successful validation of the signed attestation of the “ets” namespace provides the receiving NS/EP NGN-PS with assurance that the “ets” namespace is valid and priority treatment can be provided in completing the call/session.
If the validation of the signed “ets” namespace is not successful, the call/session should continue as a normal call.
If a signed assertion for the anonymityinformation in the CPN field is received, it is validated and used to determine Display information.
3 / FC+GETS-NT or GETS-PDN with Anonymity Origination / FC+GETS-NT or GETS-PDN call originates in NS/EP NGN-PS Service Provider network (or visited network) where WPS and GETS Providers are different:
  • WPS Provider performs authentication/authorization of the UE and populate the “wps” namespace as part of normal NS/EP NGN-PS procedures.
  • WPS Provider signs an assertion for full attestation of the “wps” namespace in a PASSPorT token and includes it in a SIP identity header.
  • WPS Provider signs an assertion for full attestation of the CPN in a PASSPorT token and includes it in a SIP identity header.
  • Receiving NS/EP Service Provider (IXC) performs GETS PIN validation and authorization and populates the “ets” namespace as part of normal NS/EP NGN-PS procedures.
  • Receiving NS/EP Service Provider (IXC) modifies Caller-ID for anonymity as part of normal NS/EP NGN-PS procedures
  • NS/EP NGN-PS Service Provider signs an assertion for full attestation of the “ets” namespace in a PASSPorT token and includes it in a SIP identity header.
  • NS/EP NGN-PS Service Provider (IXC) removes SIP identity header received from WPS Provider with signed Caller-ID. NS/EP NGN-PS may sign an assertion for full attestation for the anonymity information in the CPN field in a PASSPorT token and includes it in a SIP identity header.
/ Service Provider receiving the SIP message acts on the information in the SIP identity header by validating the signed claim in the PASSporT token.
Successful validation of the signed attestation of the “wps” and “ets” namespace provides the receiving NS/EP NGN-PS with assurance that the ”wps” and “ets” namespacesare valid and priority treatment can be provided in completing the call/session.
If the validation of the signed “wps” and “ets” namespacesare not successful, the call/session should continue as a normal call.
If a signed assertion for the anonymityinformation in the CPN field is received, it is validated and used to determine Display information.

3Proposal

It is proposed that the example use cases bediscussed to progress the work on SIP RPH Signing.

______

Top View