draft-ietf-sipping-nai-reqs-02.txt   rfc3324.txt 
SIP WG M. Watson Network Working Group M. Watson
Internet-Draft Nortel Networks Request for Comments: 3324 Nortel Networks
Expires: December 9, 2002 June 10, 2002 Category: Informational November 2002
Short Term Requirements for Network Asserted Identity Short Term Requirements for Network Asserted Identity
draft-ietf-sipping-nai-reqs-02.txt
Status of this Memo Status of this Memo
This document is an Internet-Draft and is in full conformance with This memo provides information for the Internet community. It does
all provisions of Section 10 of RFC2026. not specify an Internet standard of any kind. Distribution of this
memo is unlimited.
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 December 9, 2002.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2002). All Rights Reserved. Copyright (C) The Internet Society (2002). All Rights Reserved.
Abstract Abstract
A Network Asserted Identity is an identity initially derived by a
Session Initiation Protocol (SIP) network intermediary as a result of
an authentication process. This document describes short term
requirements for the exchange of Network Asserted Identities within
networks of securely interconnected trusted nodes and to User Agents
securely connected to such networks.
There is no requirement for identities asserted by a UA in a SIP There is no requirement for identities asserted by a UA in a SIP
message to be anything other than the user's desired alias. message to be anything other than the user's desired alias.
A Network Asserted Identity is an identity initially derived by a SIP
network intermediary as a result of an authentication process. This
draft describes short term requirements for the exchange of Network
Asserted Identities within networks of securely interconnected
trusted nodes and to User Agents securely connected to such networks.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 3
2.1 Identity . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 2.1 Identity . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
2.2 Network Asserted Identity . . . . . . . . . . . . . . . . . . 4 2.2 Network Asserted Identity . . . . . . . . . . . . . . . . . . 3
2.3 Trust Domains . . . . . . . . . . . . . . . . . . . . . . . . 4 2.3 Trust Domains . . . . . . . . . . . . . . . . . . . . . . . . 4
2.4 Spec(T) . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 2.4 Spec(T) . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
3. Generation of Networks Asserted Identity . . . . . . . . . . . 7 3. Generation of Networks Asserted Identity . . . . . . . . . . . 7
4. Transport of Network Asserted Identity . . . . . . . . . . . . 7 4. Transport of Network Asserted Identity . . . . . . . . . . . . 7
4.1 Sending of Networks Asserted Identity within a Trust Domain . 7 4.1 Sending of Networks Asserted Identity within a Trust Domain . 7
4.2 Receiving of Network Asserted Identity within a Trust Domain . 7 4.2 Receiving of Network Asserted Identity within a Trust Domain . 7
4.3 Sending of Network Asserted Identity to entities outside a 4.3 Sending of Network Asserted Identity to entities outside a
Trust Domain . . . . . . . . . . . . . . . . . . . . . . . . . 8 Trust Domain . . . . . . . . . . . . . . . . . . . . . . . . . 7
4.4 Receiving of Network Asserted Identity by a node outside the 4.4 Receiving of Network Asserted Identity by a node outside the
Trust Domain . . . . . . . . . . . . . . . . . . . . . . . . . 8 Trust Domain . . . . . . . . . . . . . . . . . . . . . . . . . 8
5. Parties with Network Asserted Identities . . . . . . . . . . . 8 5. Parties with Network Asserted Identities . . . . . . . . . . . 8
6. Types of Network Asserted Identity . . . . . . . . . . . . . . 8 6. Types of Network Asserted Identity . . . . . . . . . . . . . . 8
7. Privacy of Network Asserted Identity . . . . . . . . . . . . . 9 7. Privacy of Network Asserted Identity . . . . . . . . . . . . . 9
8. Security Considerations . . . . . . . . . . . . . . . . . . . 9 8. Security Considerations . . . . . . . . . . . . . . . . . . . 9
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 10 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 10
Normative References . . . . . . . . . . . . . . . . . . . . . 10 Normative References . . . . . . . . . . . . . . . . . . . . . 10
Author's Address . . . . . . . . . . . . . . . . . . . . . . . 10 Author's Address . . . . . . . . . . . . . . . . . . . . . . . 10
Full Copyright Statement . . . . . . . . . . . . . . . . . . . 11 Full Copyright Statement . . . . . . . . . . . . . . . . . . . 11
1. Introduction 1. Introduction
SIP [1] allows users to assert their identity in a number of ways SIP [1] allows users to assert their identity in a number of ways
e.g. using the From: header. However, there is no requirement for e.g., using the From: header. However, there is no requirement for
these identities to be anything other than the users desired alias. these identities to be anything other than the users desired alias.
An authenticated identity of a user can be obtained using SIP Digest An authenticated identity of a user can be obtained using SIP Digest
Authentication (or by other means). However, UAs do not always have Authentication (or by other means). However, UAs do not always have
the necessary key information to authenticate another UA. the necessary key information to authenticate another UA.
A Network Asserted Identity is an identity initially derived by a SIP A Network Asserted Identity is an identity initially derived by a SIP
network intermediary as a result of an authentication process. This network intermediary as a result of an authentication process. This
may or may not be based on SIP Digest authentication. This draft may or may not be based on SIP Digest authentication. This document
describes short term requirements for the exchange of Network describes short term requirements for the exchange of Network
Asserted Identities within networks of securely interconnected Asserted Identities within networks of securely interconnected
trusted nodes and also to User Agents with secure connections to such trusted nodes and also to User Agents with secure connections to such
networks. networks.
Such a network is described in this draft as a Trust Domain and we Such a network is described in this document as a Trust Domain and we
present a strict definition of trust and Trust Domain for the present a strict definition of trust and Trust Domain for the
purposes of this draft. These short-term requirements provide only purposes of this document. These short-term requirements provide
for the exchange of Network Asserted Identitied within a Trust Domain only for the exchange of Network Asserted Identity within a Trust
and to an entity directly connected to the trust domain. Domain and to an entity directly connected to the trust domain.
General requirements for transport of Network Asserted Identities on General requirements for transport of Network Asserted Identities on
the Internet are out of scope of this draft. the Internet are out of scope of this document.
2. Definitions 2. Definitions
2.1 Identity 2.1 Identity
An Identity, for the purposes of this draft, is a sip:, sips: or tel: An Identity, for the purposes of this document, is a sip:, sips: or
URI, and optionally a Display Name. tel: URI, and optionally a Display Name.
The URI MUST be meaningful to the domain identified in the URI (in The URI MUST be meaningful to the domain identified in the URI (in
the case of sip: or sips: URIs) or the owner of the E.164 number (in the case of sip: or sips: URIs) or the owner of the E.164 number (in
the case of tel: URIs), in the sense that when used as a SIP Request- the case of tel: URIs), in the sense that when used as a SIP
URI in a request sent to that domain/number range owner, it would Request-URI in a request sent to that domain/number range owner, it
cause the request to be routed to the user/line that is associated would cause the request to be routed to the user/line that is
with the identity, or to be processed by service logic running on associated with the identity, or to be processed by service logic
that user's behalf. running on that user's behalf.
If the URI is a sip: or sips: URI, then depending on the local policy If the URI is a sip: or sips: URI, then depending on the local policy
of the domain identified in the URI, the URI MAY identify some of the domain identified in the URI, the URI MAY identify some
specific entity, such as a person. specific entity, such as a person.
If the URI is a tel: URI, then depending on the local policy of the If the URI is a tel: URI, then depending on the local policy of the
owner of the number range within which the telephone number lies, the owner of the number range within which the telephone number lies, the
number MAY identify some specific entity, such as a telephone line. number MAY identify some specific entity, such as a telephone line.
However, it should be noted that identifying the owner of the number However, it should be noted that identifying the owner of the number
range is a less straightforward process than identifying the domain range is a less straightforward process than identifying the domain
skipping to change at page 4, line 23 skipping to change at page 4, line 7
authenticated entity in the sense defined in Section 2.1. authenticated entity in the sense defined in Section 2.1.
In the case of a sip: or sips: URI, the domain included in the URI In the case of a sip: or sips: URI, the domain included in the URI
MUST be within the Trust Domain. MUST be within the Trust Domain.
In the case of a tel: URI, the owner of the E.164 number in the URI In the case of a tel: URI, the owner of the E.164 number in the URI
MUST be within the Trust Domain. MUST be within the Trust Domain.
The authentication process used, or at least it's reliability/ The authentication process used, or at least it's reliability/
strength, is a known feature of the Trust Domain using the Network strength, is a known feature of the Trust Domain using the Network
Asserted Identity mechanism i.e. in the language of 2.3 below, it is Asserted Identity mechanism i.e., in the language of 2.3 below, it is
defined in Spec(T). defined in Spec(T).
2.3 Trust Domains 2.3 Trust Domains
A Trust Domain for the purposes of Network Asserted Identity is a set A Trust Domain for the purposes of Network Asserted Identity is a set
of SIP nodes (UAC, UAS, proxies or other network intermediaries) that of SIP nodes (UAC, UAS, proxies or other network intermediaries) that
are trusted to exchange Network Asserted Identity information in the are trusted to exchange Network Asserted Identity information in the
sense described below. sense described below.
A node can be a member of a Trust Domain, T, only if the node is know A node can be a member of a Trust Domain, T, only if the node is know
skipping to change at page 5, line 7 skipping to change at page 4, line 38
bi-lateral agreements between the owners/operators of the devices. bi-lateral agreements between the owners/operators of the devices.
We say a node is 'trusted' (with respect to a given Trust Domain) if We say a node is 'trusted' (with respect to a given Trust Domain) if
and only if it is a member of that domain. and only if it is a member of that domain.
We say that a node, A, in the domain is 'trusted by' a node, B, (or We say that a node, A, in the domain is 'trusted by' a node, B, (or
'B trusts A') if and only if: 'B trusts A') if and only if:
1. there is a secure connection between the nodes, AND 1. there is a secure connection between the nodes, AND
2. B has configuration information indicating that A is a member of 2. B has configuration information indicating that A is a member
the Trust Domain. of the Trust Domain.
Note that B may or may not be a member of the Trust Domain. For Note that B may or may not be a member of the Trust Domain. For
example, B may be a UA which trusts a given network intermediary, A example, B may be a UA which trusts a given network intermediary, A
(e.g. its home proxy). (e.g., its home proxy).
A 'secure connection' in this context means that messages cannot be A 'secure connection' in this context means that messages cannot be
read by third parties, cannot be modified by third parties without read by third parties, cannot be modified by third parties without
detection and that B can be sure that the message really did come detection and that B can be sure that the message really did come
from A. The level of security required is a feature of the Trust from A. The level of security required is a feature of the Trust
Domain i.e. it is defined in Spec(T). Domain i.e., it is defined in Spec(T).
Within this context, SIP signaling information received by one node Within this context, SIP signaling information received by one node
FROM a node that it trusts is known to have been generated and passed FROM a node that it trusts is known to have been generated and passed
through the network according to the procedures of the particular through the network according to the procedures of the particular
specification set Spec(T), and therefore can be known to be valid, or specification set Spec(T), and therefore can be known to be valid, or
at least as valid as specified in the specifications Spec(T). at least as valid as specified in the specifications Spec(T).
Equally, a node can be sure that signaling information passed TO a Equally, a node can be sure that signaling information passed TO a
node that it trusts will be handled according to the procedures of node that it trusts will be handled according to the procedures of
Spec(T). Spec(T).
skipping to change at page 6, line 32 skipping to change at page 6, line 30
. \\ / . . \\ / .
. \\ +------+ // . . \\ +------+ // .
. \\ | | // . . \\ | | // .
. \ | C |/ . . \ | C |/ .
. | | . . | | .
. +------+ . . +------+ .
. | Trust Domain. . | Trust Domain.
........................................ ........................................
| |
| |
|
+------+ +------+
| | | |
| D | | D |
| | | |
+------+ +------+
xxxxxx Insecure connection xxxxxx Insecure connection
------ Secure connection ------ Secure connection
...... ......
skipping to change at page 7, line 16 skipping to change at page 7, line 9
o since E knows that B is inside of the trust domain, E o since E knows that B is inside of the trust domain, E
o trusts B, but B does not trust E o trusts B, but B does not trust E
o B does not trust F, F does not trust B o B does not trust F, F does not trust B
2.4 Spec(T) 2.4 Spec(T)
An aspect of the definition of a trust domain is that all the An aspect of the definition of a trust domain is that all the
elements in that domain are compliant to a set of configurations and elements in that domain are compliant to a set of configurations and
specifications generally referrred to as Spec(T). Spec(T) is not a specifications generally referred to as Spec(T). Spec(T) is not a
specification in the sense of a written document; rather, its an specification in the sense of a written document; rather, its an
agreed upon set of information that all elements are aware of. agreed upon set of information that all elements are aware of.
Proper processing of the asserted identities requires that the Proper processing of the asserted identities requires that the
elements know what is actually being asserted, how it was determined, elements know what is actually being asserted, how it was determined,
and what the privacy policies are. All of that information is and what the privacy policies are. All of that information is
characterized by Spec(T). characterized by Spec(T).
3. Generation of Networks Asserted Identity 3. Generation of Networks Asserted Identity
A Network Asserted Identity is generated by a network intermediary A Network Asserted Identity is generated by a network intermediary
skipping to change at page 8, line 29 skipping to change at page 8, line 18
It shall be possible for a node outside the Trust Domain to receive a It shall be possible for a node outside the Trust Domain to receive a
Network Asserted Identity from a node that it trusts. Network Asserted Identity from a node that it trusts.
Network Asserted Identity received in this way may be considered Network Asserted Identity received in this way may be considered
valid, and used for display to the user, input data for services etc. valid, and used for display to the user, input data for services etc.
Network Asserted Identity information received by one node from a Network Asserted Identity information received by one node from a
node which it does not trust carries no guarantee of authenticity or node which it does not trust carries no guarantee of authenticity or
integrity because it is not known that the procedures of Spec(T) were integrity because it is not known that the procedures of Spec(T) were
followed to generate and transport the information. Such information followed to generate and transport the information. Such information
MUST NOT be used. i.e. it shall not be displayed to the user, MUST NOT be used. (i.e., it shall not be displayed to the user,
passed to other nodes, used as input data for services etc. passed to other nodes, used as input data for services, etc.)
5. Parties with Network Asserted Identities 5. Parties with Network Asserted Identities
A Network Asserted Identity identifies the originator of the message A Network Asserted Identity identifies the originator of the message
in which it was received. in which it was received.
For example, For example,
a Network Asserted Identity received in an initial INVITE (outside a Network Asserted Identity received in an initial INVITE (outside
the context of any existing dialog) identifies the calling party. the context of any existing dialog) identifies the calling party.
skipping to change at page 9, line 4 skipping to change at page 8, line 41
a Network Asserted Identity received in a 180 Ringing response to a Network Asserted Identity received in a 180 Ringing response to
such an INVITE identifies the party who is ringing. such an INVITE identifies the party who is ringing.
a Network Asserted Identity received in a 200 response to such an a Network Asserted Identity received in a 200 response to such an
INVITE identifies the party who has answered. INVITE identifies the party who has answered.
6. Types of Network Asserted Identity 6. Types of Network Asserted Identity
It shall be possible to assert multiple identities associated with a It shall be possible to assert multiple identities associated with a
given party (in a given message), provided that these are of distinct given party (in a given message), provided that these are of distinct
types. . types.
The types of identity supported shall be sip:, sips: and tel: URIs, The types of identity supported shall be sip:, sips: and tel: URIs,
all of which identify the user as described in Section 2.1. It is all of which identify the user as described in Section 2.1. It is
not required to transport both a sip: and sips: URI. not required to transport both a sip: and sips: URI.
It shall be possible for the capability to transport additional types It shall be possible for the capability to transport additional types
of identity associated with a single party to be introduced in of identity associated with a single party to be introduced in
future. future.
7. Privacy of Network Asserted Identity 7. Privacy of Network Asserted Identity
The means by which any privacy requirements in respect of the Network The means by which any privacy requirements in respect of the Network
Asserted Identity are determined are outside the scope of this draft. Asserted Identity are determined are outside the scope of this
document.
It shall be possible to indicate within a message containing a It shall be possible to indicate within a message containing a
Network Asserted Identity that this Network Asserted Identity is Network Asserted Identity that this Network Asserted Identity is
subject to a privacy requirement which prevents it being passed to subject to a privacy requirement which prevents it being passed to
other users. This indication should not carry any semantics as to other users. This indication should not carry any semantics as to
the reason for this privacy requirement. the reason for this privacy requirement.
It shall be possible to indicate that the user has requested that the It shall be possible to indicate that the user has requested that the
Network Asserted Identity be not passed to other users. This is Network Asserted Identity be not passed to other users. This is
distinct from the above indication, in that it implies specific user distinct from the above indication, in that it implies specific user
intent with respect to the Network Asserted Identity. intent with respect to the Network Asserted Identity.
The mechanism shall support Trust Domain policies where the above two The mechanism shall support Trust Domain policies where the above two
indications are equivalent (i.e. the only possible reason for a indications are equivalent (i.e., the only possible reason for a
privacy requirement is a request from the user), and policies where privacy requirement is a request from the user), and policies where
they are not. they are not.
In this case, the Network Asserted Identity specification shall In this case, the Network Asserted Identity specification shall
require that the mechanism of Section 4.3 SHALL NOT be used i.e. a require that the mechanism of Section 4.3 SHALL NOT be used i.e., a
trusted node shall not pass the identity to a node it does not trust. trusted node shall not pass the identity to a node it does not trust.
However, the mechanism of Section 4.3 MAY be used to transfer the However, the mechanism of Section 4.3 MAY be used to transfer the
identity within the trusted network. identity within the trusted network.
Note that 'anonymity' requests from users or subscribers may well Note that 'anonymity' requests from users or subscribers may well
require functionality in addition to the above handling of Network require functionality in addition to the above handling of Network
Asserted Identities. Such additional functionality is out of the Asserted Identities. Such additional functionality is out of the
scope of this document. scope of this document.
8. Security Considerations 8. Security Considerations
The requirements in this draft are NOT intended to result in a The requirements in this document are NOT intended to result in a
mechanism with general applicability between arbitrary hosts on the mechanism with general applicability between arbitrary hosts on the
Internet. Internet.
Rather, the intention is to state requirements for a mechanism to be Rather, the intention is to state requirements for a mechanism to be
used within a community of devices which are known to obey the used within a community of devices which are known to obey the
specification of the mechanism (Spec(T)) and between which there are specification of the mechanism (Spec(T)) and between which there are
secure connections. Such a community is known here as a Trust secure connections. Such a community is known here as a Trust
Domain. Domain.
The requirements on the mechanisms used for security and to initially The requirements on the mechanisms used for security and to initially
skipping to change at page 10, line 31 skipping to change at page 10, line 21
information has not been modified, or was even correct in the first information has not been modified, or was even correct in the first
place. place.
9. IANA Considerations 9. IANA Considerations
This document does not have any implications for IANA. This document does not have any implications for IANA.
10. Acknowledgments 10. Acknowledgments
Thanks are due to Jon Peterson, Cullen Jennings, Allison Mankin and Thanks are due to Jon Peterson, Cullen Jennings, Allison Mankin and
Jonathan Rosenburg for comments on this document. Jonathan Rosenberg for comments on this document.
Normative References Normative References
[1] Rosenberg, J. and H. Schulzrinne, "SIP: Session Initiation [1] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A.,
Protocol", draft-ietf-sip-rfc2543bis-09 (work in progress), Peterson, J., Sparks, R., Handley, M. and E. Schooler, "SIP: Session
February 2002. Initiation Protocol", RFC 3261, June 2002.
Author's Address Author's Address
Mark Watson Mark Watson
Nortel Networks Nortel Networks
Bray House
Maidenhead Office Park Maidenhead Office Park
Westacott Way Westacott Way
Maidenhead, BERKS SL6 3QH Maidenhead, BERKS SL6 3QH
UK UK
EMail: mwatson@nortelnetworks.com EMail: mwatson@nortelnetworks.com
Full Copyright Statement Full Copyright Statement
Copyright (C) The Internet Society (2002). All Rights Reserved. Copyright (C) The Internet Society (2002). All Rights Reserved.
 End of changes. 

This html diff was produced by rfcdiff 1.25, available from http://www.levkowetz.com/ietf/tools/rfcdiff/