Session Initiation Protocol (SIP) Extensions for Blocking VoIP Spam Using PSTN Validation
draft-rosenberg-dispatch-vipr-sip-antispam-00

Abstract

Verification Involving PSTN Reachability (ViPR) is a new technique for inter-domain federation of SIP calls. ViPR makes use of a the PSTN as an introduction mechanism to verify the correctness of mappings from phone numbers to domains. The PSTN introduction mechanism can also be used as a techqnique for blocking spam - a SIP caller is only authorized when they're calling domain has previously called that same number over the PSTN. This document describes an extension to SIP which enables authorization of SIP calls based on a prior PSTN introduction.

Legal

This documents and the information contained therein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION THEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Status of this Memo

This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79.

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts.

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as “work in progress.”

The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt.

The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html.

This Internet-Draft will expire on May 13, 2010.

Copyright Notice

Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved.

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the BSD License.

Table of Contents

1.  Introduction
2.  Terminating Side Procedures
3.  Originating Side Procedures
4.  Tickets
5.  Security Considerations
6.  IANA Considerations
7.  References
    7.1.  Normative References
    7.2.  Informative References
§  Authors' Addresses

1.  Introduction

The anti-spam tickets described in this specification are the key security mechanism in ViPR for mitigation of SPAM. The domain originating a call inserts a ticket in the SIP INVITE sent to the other domain. The Border Element in the domain receiving the call (see Figure 1 (Architecture ) can check the ticket to ensure that this originating domain has been authorized by the terminating domain. This document relies heavily on the concepts and terminology defined in [I‑D.rosenberg‑dispatch‑vipr‑overview] (Rosenberg, J. and C. Jennings, “Verification Involving PSTN Reachability: Requirements and Architecture Overview,” November 2009.) and will not make sense if you have not read that document first.

                    +-+            +-+
                    | |            | |   +------+
                    | |      +-----| |---|Enroll|
                    | |      |     | |   +------+
                    |I|      |     |I|
                    |n|   +-----+  |n|
             VAP    |t|   | ViPR|  |t|
         +----------|r|---|Srvr |--|e|-----------------
         |          |a|   |     |  |r|   P2P-Validation
         |          |n|   +-----+  |n|
         |          |e|            |e|
         |          |t|            |t|
      +-----+  SIP  | |   +-----+  | |
      | CA  |-------|F|---|     |--|F| ---------------
      +-----+       |i|   |     |  |i|  SIP/TLS
         .          |r|   |  .  |  |r|
  SIP/   .          |e|   |     |  |e|
  MGCP/  .          |w|   | BE  |  |w|
  TDM    .          |a|   |     |  |a|
         .          |l|   |     |  |l|
      +-----+       |l|   |     |  |l|
      | UA  |-------| |---|     |--| |-----------------
      +-----+       | |   +-----+  | |   SRTP
                    | |            | |
                    +-+            +-+
 |                                      |
 +--------------------+-----------------+
                      |
         Single administrative domain

2.  Terminating Side Procedures

The Border Element will receive the TLS ClientHello which begins the TLS handshake. The Border Element will present its own configured cert. Once TLS handshaking is complete, the Border Element notes the domain from the SubjectAltName on the other side of the TLS connection, and associates it with that connection.

Next, the Border Element will receive an INVITE. This INVITE will contain a ticket in the X-Cisco-ViPR-Ticket header field value. The Border Element extracts this header field. This call flow assumes it is present. The Border Element parses it, and obtains the epoch value encoded in the ticket. This is matched against the current epoch value for the configured password. If they match, processing continues. The Border Element verifies the signature is correct. Next, it examines the start and stop time of the validity. If the current time is between the start and stop times, the check is passed. Next, the Border Element checks the issued-to domain in the ticket. It compares that domain against the domain name in the SubjectAltName of the peer on the other side of the TLS connection, as noted above. Next, it takes the Request-URI of the SIP INVITE. That will be of the form sip:+number@domain. If it is not in that form, and if the number does not begin with a plus, the request is dropped. The value, including the plus, is then compared Number in the ticket. If it is equal, the check has passed. The Border Element leaves the header field in the request, but forwards to the Call Agent.

In addition, the Border Element will typically be configured to apply its SIP message validation logic, and enforce restrictions on the sizes of various SIP header fields. This provides an additional layer of security in case malicious SIP messages are sent.

The Border Element will also apply port forwarding in the case of NAT, so that the incoming request is forwarded to the appropriate Call Agent node.

The Call Agent will receive incoming SIP INVITEs. The Request-URI of the INVITE will contain an E.164 number as indicated by a leading plus. If the Request-URI is not an E164, the request must be rejected with a 403. Only E164 numbers can be accepted on a ViPR trunk.

3.  Originating Side Procedures

The routes stored to other domains in the Call Agent will each store a ticket to utilize with calls to that route. The Call Agent learns about these routs and the information needed to construct the ticket from the VAP protocol (Rosenberg, J. and C. Jennings, “Validation Access Protocol (VAP),” November 2009.) [I‑D.draft‑rosenberg‑dispatch‑vipr‑vap]. When sending a SIP request to one of these domains, the Call Agent MUST include the ticket in any dialog forming request or request that is not in an existing dialog.

4.  Tickets

This ticket is a sequence of characters. These MUST be placed into a X-Cisco-ViPR-Ticket SIP header field value. Consequently the format for this header field is:

Ticket = "X-Cisco-ViPR-Ticket" HCOLON ticket-val
ticket-val = 1*alphanum

This header field MUST be utilized in all INVITE requests and all out-of-dialog requests. It is not utilized in responses. The ticket-value is a base64 encoded version of an object that is composed of a series of TLVs. Each TLV is a 16 bit type, a 16 bit length, and a variable length value. The length field refers to the length of the value portion of the TLV, measured in bytes. The following TLV types are defined:

1. Ticket Unique ID: This TLV has a type of 0x0001. It contains a 128 bit ID that has a unique identifier for this ticket. The value MUST contain a 128 bit UUID defined by [RFC4122] (Leach, P., Mealling, M., and R. Salz, “A Universally Unique IDentifier (UUID) URN Namespace,” July 2005.). This TLV MUST be present. However at this time it is used for diagnostic purposes only.
2. Salt: This TLV has a type of 0x0002. It contains a value which MUST be at least 32 bits, and contains a random number. Its presence ensures that each ticket contains sufficient randomness. This TLV MUST be present.
3. Validity: This TLV has a type of 0x0003. It contains two 64 bit NTP times. The first is the start of the validity of the ticket, the next is the end time for the validity of the ticket. This TLV MUST be present.
4. Number: This TLV has a type of 0x0004. It contains a string which has an E164 number, included the "+", which may be called using this ticket. This TLV MUST be present.
5. Granting Node: This TLV has a type of 0x0005. It contains a 128 bit value which is the nodeID of the node which granted the ticket. This TLV MUST be present.
6. Granting Domain: This TLV has a type of 0x0006. The domain which granted the ticket. A string, up to 256 characters, each of which must be a valid domain name character. The TLV has variable length. This TLV MUST be present.
7. Granted-To Domain: This TLV has a type of 0x0007. The domain to which the ticket is granted. A string, up to 256 characters, each of which must be a valid domain name character. The TLV has a variable length. This TLV MUST be present.
8. Epoch: This TLV has a type of 0x0008. It contains a 16 bit epoch value. It is used to select a key. This TLV MUST be present.
9. Integrity: This TLV has a type of 0x0009. It contains a 160 bit integrity value, computed using HMAC-SHA1. This TLV MUST be present.

The base64 encoding uses the bas64url encoding from RFC4648 (Josefsson, S., “The Base16, Base32, and Base64 Data Encodings,” October 2006.) [RFC4648], with the exception of the pad character, which is a "." instead of an "=". This ensures that the output is a valid SIP token.

To compute the MAC, the following is done. First, the key is obtained. The key is actually a 128 bit key, configured into the system. The key, P, is then used to compute Km:

Km = HMAC-SHA1(P, S | Epoch)

Based on PBKDF2 from PKCS #5 (Kaliski, B., “PKCS #5: Password-Based Cryptography Specification Version 2.0,” September 2000.) [RFC2898] with HMAC-SHA1 as PRF and iteration count of 1. Where S is the 32 bit salt and Epoch is the 32 bit Epoch, from the ticket. This produces a 160 bit Km. The MAC is then computed as another HMAC-SHA1, over the entire ticket up to but not including the Integrity itself, using Km as the key. This produces the 160 bit MAC.

5.  Security Considerations

TBD

6.  IANA Considerations

TBD - Register SIP Header

TBD - Form IANA registry for Ticket TLVs

7.  References

7.1. Normative References

7.2. Informative References

Authors' Addresses