Security Considerations

This section focuses on security considerations which are unique to SPIRITS. SIP security mechanisms are discussed in detail in the core SIP specification [5] and are outside the scope of this document. SPIRITS security mechanisms are based on and strengthen SIP security [5], for example, SPIRITS mandates the support of S/MIME. Beyond that, any other security solutions specified in [5], i.e., TLS or HTTP Digest authentication, may be utilized by SPIRITS operators.

As outlined in Chapter 9 (Security Consideration) of RFC3298 [4], the following security aspects are applicable to the SPIRITS protocol:

■ Authentication

■ Confidentiality

■ Non-repudiation

The SPIRITS architecture in Figure 1 contains 5 interfaces — A, B, C, D, and E. Of these, only two — B and C — are of interest to SPIRITS. Interfaces A and E are PINT interfaces and are thus assumed secured by the PINT RFC [8]. Security for interface D is out of scope in this document since it deals primarily with the PSTN infrastructure. We will discuss security aspects on interfaces B and C predicated on certain assumptions.

A driving assumption for SPIRITS security is that the SPIRITS gateway is owned by the same PSTN operator that owns the SPIRITS notifier. Thus, it is attractive to simply relegate security of interface C to the PSTN operator, and in fact, there are merits to doing just that since interface C crosses the IP Network and PSTN boundaries. However, a closer inspection reveals that both interfaces B and C transmit the SPIRITS protocol; thus, any security arrangement we arrive at for interface B can be suitably applied to interface C as well. This makes it possible to secure interface

C in case the SPIRITS gateway is not owned by the same PSTN operator that owns the SPIRITS notifier.

The ensuing security discussion assumes that the SPIRITS subscriber is communicating directly to the SPIRITS notifier (and vice-versa) and specifies a security apparatus for this arrangement. However, the same apparatus can be used to secure the communication between a SPIRITS subscriber and an intermediary (like the SPIRITS gateway), and the same intermediary and the SPIRITS notifier.

Confidentiality of the SPIRITS protocol is essential since the information carried in the protocol data units is of a sensitive nature and may lead to privacy concerns if revealed to non-authorized parties. The communication path between the SPIRITS notifier and the SPIRITS subscriber should be secured through S/MIME [18] to alleviate privacy concerns, as is described in the Security Consideration section of the core SIP specification [5].

S/MIME is an end-to-end security mechanism which encrypts the SPIRITS bodies for transit across an open network. Intermediaries need not be cognizant of S/MIME in order to route the messages (routing headers travel in the clear).

S/MIME provides all the security aspects for SPIRITS outlined at the beginning of this section: authentication, message integrity, confidentiality, and non-repudiation. Authentication properties provided by S/MIME would allow the recipient of a SPIRITS message to ensure that the SPIRITS payload was generated by an authorized entity. Encryption would ensure that only those SPIRITS entities possessing a particular decryption key are capable of inspecting encapsulated SPIRITS bodies in a SIP request.

All SPIRITS endpoints MUST support S/MIME signatures (CMS Signed-Data) and MUST support encryption (CMS EnvelopedData).

If the B and C interfaces are owned by the same PSTN operator, it is possible that public keys will be installed in the SPIRITS endpoints.

S/MIME supports two methods — issuerAndSerialNumber and subject-KeyIdentifier — of naming the public key needed to validate a signature. Between these, subjectKeyIdentifier works with X.509 certificates and other schemes as well, while issuerAndSerialNumber works with X.509 certificates only. If the administrator configures the necessary public keys, providing integrity through procedural means, then S/MIME can be used without X.509 certificates.

All requests (and responses) between SPIRITS entities MUST be encrypted.

When a request arrives at a SPIRITS notifier from a SPIRITS subscriber, the SPIRITS notifier MUST authenticate the request. The subscription (or registration) from a SPIRITS subscriber MUST be rejected if the authentication fails. If the SPIRITS subscriber successfully authenticated itself to the SPIRITS

notifier, the SPIRITS notifier MUST, at the very least, ensure that the SPIRITS subscriber is indeed allowed to receive notifications of the events it is subscribing to.

Note that this document does not proscribe how the SPIRITS-notifier achieves this. In practice, it could be through access control lists (ACL) that are populated by a service management system in the PSTN, or through a web interface of some sort.

Requests from the SPIRITS notifier to the SPIRITS subscribers MUST also be authenticated, lest a malicious party attempts to fraudulently pose as a SPIRITS notifier to hijack a session.

0 0

Post a comment