Status of this Memo

This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026.

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 October 31, 2002.

Copyright Notice

Copyright (C) The Internet Society (2002). All Rights Reserved.

Abstract

This document describes extensions to SIP that enable a network of trusted SIP servers to assert the identity of end users or end systems, and to convey indications of end-user requested privacy. The use of these extensions are only applicable inside an administrative domain, or among federations of administrative domains with previously agreed-upon policies for usage of such information. This document does NOT offer a general privacy or identity model suitable for inter-domain use or use in the Internet at large.

Table of Contents

1.  Applicability Statement
2.  Conventions
3.  Introduction
4.  Overview
5.  Proxy Behavior
6.  User Agent Behavior
7.  Formal Syntax
7.1  The Network-Asserted-ID Header
7.2  The "nai" Privacy Type
7.3  Examples
7.3.1  Network Asserted Identity passed to trusted gateway
7.3.2  Network Asserted Identity withheld
8.  Comparison to Requirements
9.  Security Considerations
10.  IANA Considerations
10.1  Registration of "Network-Asserted-ID" SIP header
10.2  Registration of "nai" privacy type for SIP Privacy header
11.  Open Issues:
12.  Acknowledgments
§  Normative References
§  Informational References
§  Author's Address
§  Full Copyright Statement

1. Applicability Statement

This document describes extensions to SIP[1] that enable a network of trusted SIP servers to assert the identity of end users or end systems, and to convey indications of end-user requested privacy. The use of these extensions are only applicable inside an administrative domain, or among federations of administrative domains with previously agreed-upon policies for usage of such information. Such a "network" is explicitly trusted by its users and end-systems to either publicly assert the identity of each party, or be responsible for withholding that identity outside of the trusted domain or federation of domains if privacy is requested. The means by which the network determines the identity to assert is outside the scope of this document.

This document does NOT offer a general privacy or identity model suitable for inter-domain use or use in the Internet at large. Its assumptions about the trust relationship between the user and the network may not apply in many applications. For example, these extensions do not accommodate a model whereby end users can independently assert their identity by use of the extensions defined here. Furthermore, since the asserted identities are not cryptographically certified, they are subject to forgery, replay, and falsification in any architecture that does not provide full transitive trust. The asserted identities also lack an indication of who is asserting the identity, and therefore the assertions are not useful outside of the federation of domains, where such information would be crucial in order to determine the validity or value of the assertion.

Despite these limitations, there are sufficiently useful specialized deployments that meet the assumptions described above, and can accept the limitations that result, to warrant publication of this mechanism. An example deployment would be a closed network which emulates a traditional circuit switched telephone network.

It should be noted, that the mechanisms described in this draft are not intended to be used for user-asserted identity. As described above, the mechanisms are merely intended to enable trusted intermediaries to assert an identity for users.

2. Conventions

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC-2119[3].

For the purpose of definitions within this document, trust is a transitive property. If A trusts B and B trusts C, then A,B, and C are all in the same trust domain.

For one node to consider another node trusted, it means that the node is willing to delegate to all the nodes in that trust domain the requirements and responsibilities that this draft specifies. It also means the node is willing to share the private network identity information with all the nodes in the trust domain. For one node to trust another node, it must be sure that it is communicating with the correct node, that this node has been administratively added to the trust domain, and that this communication can not be intercepted, modified, or replayed by any node that is not part of the trust domain.

Throughout this document requirements for or references to proxy servers or proxy behavior apply similarly to other intermediaries (ex: B2BUAs).

3. Introduction

Various providers which attempt to offer a telephony service over IP networks have selected SIP as a base protocol. These environments require a way for trusted network elements (for example SIP proxy servers) to communicate the identity of users using such a service, yet also need to withhold this information from untrusted entities under certain circumstances. Such networks typically assume some level of transitive trust.

These networks need to interoperate with some basic telephony services and meet basic regulatory and public safety requirements. These include Calling Identity Delivery services, Calling Identity Delivery Blocking, and the ability to trace the originator of a call. While baseline SIP can support each of these services independently, certain combinations cannot be supported. For example, a caller that wants to maintain privacy and consequently provides unintelligible information in the SIP From header field will not be identifiable to SIP entities that do not directly perform SIP authentication. However, this will prevent certain services, e.g., call trace, from working in the PSTN or being performed at intermediaries not privy to the authenticated identity of the user.

This document attempts to address this requirement using a very limited, simple mechanism, based on requirements in [5]. A previous attempt to solve this problem ([6]), from which this work was derived, has not generated working group consensus. A more comprehensive mechanism ([7]) which uses cryptography to address this problem is the subject of future analysis by the SIP working group.

Providing privacy in an IP network is more complicated than in the PSTN. In IP networks the participants in a session will normally exchange IP traffic directly. The IP addresses used for these sessions may themselves reveal some privacy. A general purpose mechanism for providing privacy in a SIP environment is discussed in [2]. This document extends these mechanism to compensate for the information it adds.

4. Overview

The mechanism proposed in this draft results in a header that looks like:

An authenticating proxy which receives a message can authenticate the user associated with the UAC using an appropriate mechanism (for example: Digest authentication, or TLS mutual authentication). The proxy then inserts a Network-Asserted-ID header in the message and forwards it on to other trusted proxies. A proxy that is about to forward a message to an untrusted proxy or UA, removes the Network-Asserted-ID header if the user requested that this information be kept private. Users can request this type of privacy by including a Privacy header with the "nai" privacy type in their request.

5. Proxy Behavior

When a proxy receives a message it may be from a trusted or untrusted SIP entity. When a proxy receives a request from a untrusted element, the proxy SHOULD authenticate the user, and using the identity which results from this authentication it MAY insert a Network-Asserted ID header. If a Network-Asserted-ID header is already present in the message, the proxy MAY use this information as a hint suggesting which of multiple valid identities for the authenticated user should be asserted. If such a hint does not correspond to any valid identity known to the proxy for that user, the proxy MUST discard the user-provided Network-Asserted-ID header. In this case, the proxy MAY add a Network-Asserted-ID header of its own construction, or it MAY refuse to forward the request and return a 403 Forbidden response instead. If no Network-Asserted-ID header is present in the request, and the user has multiple valid identities known to the proxy server, the proxy MAY use the From header as a similar hint.

If the proxy receives a message (request or response) from a trusted element, it MAY use the information in the Network-Asserted-ID header as if it had authenticated the user itself. For the received message to be trusted, the receiving proxy MUST be sure it came from a trusted SIP element, and that the message was not tampered with in transit.

When a proxy forwards a message to another element, it must first determine if that element is trusted or untrusted. If the element is trusted, the proxy MAY include the Network-Asserted-ID header. If the element is not trusted, then the proxy MUST examine the Privacy header (if present) to determine if the user requested that this information be kept private by specifying the "nai" privacy type. If so, the proxy MUST remove the Network-Asserted-ID header. In addition, for backward compatibility, the proxy SHOULD examine the From field for an anonymous value and similarly use this as an indication that the user would like this information to remain private. Otherwise the proxy is encouraged to remove the Network-Asserted-ID header but MAY choose not to.

6. User Agent Behavior

In general, a User Agent Client does not need to insert a Network-Asserted-ID header. If a UAC is confident that it is sending a request to a trusted outbound proxy, and it has multiple possible network asserted identities, it MAY place the identity that it wishes the proxy to assert for it as a hint in a Network-Asserted-ID header. TLS server authentication provides one possible mechanism by which the UAC can determine that the message is going to the correct proxy.

If a User Agent Server receives a message from an untrusted previous hop, it SHOULD ignore any Network-Asserted-ID header, but it MAY present the information to the user in the same manner as an unverified From address, with a warning that this information is not verified in any way. If a UAS receives a Network-Asserted-ID from a trusted entity, then it MAY use the information but it MUST ensure that it does not forward the information to any untrusted element. For example, in the case of an anonymous call going to a PSTN gateway, the gateway MAY pass the Network-Asserted-ID information to the PSTN but it must make sure the call is appropriately signaled so that this information will not be leaked outside of an appropriate trust boundary.

7. Formal Syntax

The following syntax specification uses the augmented Backus-Naur Form (BNF) as described in RFC-2234[4].

7.1 The Network-Asserted-ID Header

The Network-Asserted-ID header is used among trusted SIP entities (typically intermediaries) to carry the identity of the user sending a SIP message as it was verified by authentication with a trusted entity.

A Network-Asserted-ID header MUST contain exactly one name-addr or addr-spec. Only a single Network-Asserted-ID header can be present in a SIP message. It is worth noting that Proxies can (and will) add and remove this header.

This document adds the following entry to Table 2 of [1]:

7.2 The "nai" Privacy Type

This specification adds a new privacy type ("priv-value") to the Privacy header, defined in [2]. The presence of this privacy type in a SIP Privacy header indicates that the user would like the Network Asserted Identity to be kept private with respect to SIP entities outside the trust domain or trust federation with which the user authenticated. Note that a user requesting multiple types of privacy MUST include all of the requested privacy types in its Privacy header.

7.3 Examples

7.3.1 Network Asserted Identity passed to trusted gateway

In this example, proxy.cisco.com creates a Network-Asserted-ID header from an identity it discovered from SIP Digest authentication. It forwards this information to a trusted proxy which forwards it to a trusted gateway.

7.3.2 Network Asserted Identity withheld

In this example, the User Agent provides a hint to its first hop proxy, which it uses after verifying this identity with SIP Digest authentication. The first proxy creates a Network-Asserted-ID header and forwards it to a trusted proxy (outbound.cisco.com). The next proxy removes the Network-Asserted-ID header, and the request for Privacy before forwarding this request onward to the untrusted biloxi.com proxy server.

8. Comparison to Requirements

Some other approaches have suggested that the header should also include information about who asserted it. Inside the trust domain, this is well known, the trust domain asserted it. Outside the trust domain, this information can not be trusted and therefore should not be used. Since there was no use for it in either case, it was not included.

The requirements request that the identity of the calling and the called users are supported. This is determined from the context of the messages. If the message is going from the UAC to the UAS, then the network-ID header asserts the identity of the UAC while for messages going the other direction it asserts the identity of the UAS.

The requirements only require the ability to assert a single identity though they mention it may be possible to extend to more later. This was explicitly not done in this document because it is unnecessarily complicated.

9. Security Considerations

The mechanism provided in this document is a partial consideration of the problem of identity and privacy in SIP. For example, these mechanisms provide no means by which end users can conceal their identities from the network. Information which the user designates as 'private' can be inspected by any intermediaries participating in the trusted network. This information is passed by transitive trust, which is only as reliable as the weakest link in the chain of trust.

When a trusted entity has determined the identity information for a user that wishes to remain private, and the trusted entity then sends a message to any destination with that party's identity in a Network-Asserted-ID header, the entity MUST take precautions to protect the identity information from eavesdropping and interception to protect the confidentiality and integrity of that identity information. The use of transport or network layer hop-by-hop security mechanisms, such as TLS or IPSec, can satisfy this requirement.

Finally, a user agent or proxy can only assume that a privacy request will be honored if it is sent to a trusted entity. Thus, if a user agent or proxy does not know if its SIP message (request or response) is sent to a trusted entity (proxy or UA), it should assume that a privacy request for that message will not be honored.

10. IANA Considerations

10.1 Registration of "Network-Asserted-ID" SIP header

10.2 Registration of "nai" privacy type for SIP Privacy header

11. Open Issues:

Should an options tag be required so that the UA knows the proxy will support this? It seemed like if you know you could trust the proxy you would already know this so it did not seem valuable.

Should a proxy sending a message to a untrusted element be REQUIRED to remove the Network-ID header?

Would "Proxy-From" be a better name for this header?

12. Acknowledgments

Thanks to Bill Marshall and Flemming Andreason [6], Mark Watson [5], and Jon Peterson [7] for authoring drafts which represent the bulk of the text making up this document.

Normative References

Informational References

Author's Address

Full Copyright Statement

Copyright (C) The Internet Society (2002). All Rights Reserved.

This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.

The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.

This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Acknowledgement

Funding for the RFC Editor function is currently provided by the Internet Society.