draft-ietf-sipping-nai-reqs-00.txt   draft-ietf-sipping-nai-reqs-01.txt 
Internet Draft Mark Watson Internet Draft Mark Watson
Document: draft-ietf-sipping-nai-reqs-00.txt Nortel Networks Document: draft-ietf-sipping-nai-reqs-01.txt Nortel Networks
Category: Informational Category: Informational
Expires November 2002 May 2002 Expires November 2002 May 2002
Short term requirements for Network Asserted Identity Short term requirements for Network Asserted Identity
Status of this Memo Status of this Memo
This document is an Internet-Draft and is in full conformance with This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026. all provisions of Section 10 of RFC2026.
skipping to change at page 1, line 33 skipping to change at page 1, line 33
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
Abstract Abstract
There is no requirement for identities identities asserted by a UA in
a SIP message to be anything other than the userÆs desired alias. An
authenticated identity of a user can be obtained using SIP Digest
authentication, however it is unlikely that the necessary Public Key
Infrastructure to facilitate this for UAs will be available soon.
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
draft describes short term requirements for the exchange of Network draft 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 to User Agents securely connected to such networks. trusted nodes and to User Agents securely connected to such networks.
General requirements for transport of Network Asserted Identities on
the Internet are out of scope of this draft.
Table of Contents Table of Contents
1. Introduction...................................................2 1. Introduction...................................................2
2. Definitions....................................................3 2. Definitions....................................................2
2.1 Identity...................................................3 2.1 Identity...................................................2
2.2 Network Asserted Identity..................................3 2.2 Network Asserted Identity..................................3
2.3 Trust Domains..............................................3 2.3 Trust Domains..............................................3
3. Generation of Network Asserted Identity........................5 3. Generation of Network Asserted Identity........................5
4. Transport of Network Asserted Identity.........................5 4. Transport of Network Asserted Identity.........................5
4.1 Sending of Network Asserted Identity within a Trust Domain.5 4.1 Sending of Network Asserted Identity within a Trust Domain.5
4.2 Receiving of Network Asserted Identity withing a Trust Domain 4.2 Receiving of Network Asserted Identity withing a Trust Domain
...............................................................5 ...............................................................5
4.3 Sending of Network Asserted Identity to entities outside a 4.3 Sending of Network Asserted Identity to entities outside a
Trust Domain...................................................5 Trust Domain...................................................5
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...................................................6 Trust Domain...................................................5
5. Parties with Network Asserted Identities.......................6 5. Parties with Network Asserted Identities.......................6
6. Types of Network Asserted Identity.............................6 6. Types of Network Asserted Identity.............................6
7. Privacy of Network Asserted Identity...........................6 7. Privacy of Network Asserted Identity...........................6
8. Next steps.....................................................7 8. Next steps.....................................................7
9. Security considerations........................................7 9. Security considerations........................................7
10. IANA Considerations...........................................8 10. IANA Considerations...........................................7
11. References....................................................8 11. References....................................................8
12. Acknowledgments...............................................8 12. Acknowledgments...............................................8
13. AuthorsÆ Addresses............................................8 13. AuthorsÆ Addresses............................................8
14. Full Copyright Statement......................................8 14. Full Copyright Statement......................................8
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, it is unlikely that the Authentication (or by other means). However, UAs do not always have
necessary Public Key Infrastructure to globally facilitate this for the necessary key information to authenticate another UA. .
users will be available soon.
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 draft
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 draft 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 draft. These short-term requirements provide only
for the exchange of Network Asserted Identitied within a Trust for the exchange of Network Asserted Identitied within a 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 draft.
2. Definitions 2. Definitions
2.1 Identity 2.1 Identity
An Identity, for the purposes of this draft, is a URI, and optionally An Identity, for the purposes of this draft, is a URI, and optionally
a Display Name. The URI MUST be meaningful to the domain identified a Display Name. The URI MUST be meaningful to the domain identified
in the URI when used as a SIP Request-URI. in the URI when used as a SIP Request-URI.
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
skipping to change at page 3, line 32 skipping to change at page 3, line 24
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
which owns a sip: or sips: URI. which owns a sip: or sips: URI.
2.2 Network Asserted Identity 2.2 Network Asserted Identity
A Network Asserted Identity is an identity derived by a SIP network A Network Asserted Identity is an identity derived by a SIP network
entity as a result of an authentication process. entity as a result of an authentication process.
The authentication process used, or at least itÆs The authentication process used, or at least it's
reliability/strength, is a known feature of the Trust Domain using reliability/strength, is a known feature of the Trust Domain using
the Network Asserted Identity mechanism i.e. in the language of 2.3 the Network Asserted Identity mechanism i.e. in the language of 2.3
below, it is defined in Spec(T). below, it is 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.
skipping to change at page 4, line 11 skipping to change at page 4, line 5
of the equipment they are using/deploying. In the simplest case, a of the equipment they are using/deploying. In the simplest case, a
Trust Domain is a set of devices with a single owner/operator who can Trust Domain is a set of devices with a single owner/operator who can
accurately know the behaviour of those devices. accurately know the behaviour of those devices.
Such simple Trust Domains may be joined into larger Trust Domains by Such simple Trust Domains may be joined into larger Trust Domains by
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 one node in the domain is ætrusted byÆ another if and We say that a node, A, in the domain is ætrusted byÆ a node, B, (or
only if: æB trusts AÆ) if and only if:
(i) there is a secure connection between the nodes, AND (i) there is a secure connection between the nodes, AND
(ii) they have configuration information to indicate that they are (ii) B has configuration information indicating that A is a member of
members of the same Trust Domain.
This most often applies to network intermediaries such as proxies in
the Trust Domain. the Trust Domain.
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
(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 and cannot be modified or inserted by third read by third parties, cannot be modified by third parties without
parties without detection. The level of security required is a detection and that B can be sure that the message really did come
feature of the Trust Domain i.e. it is defined in Spec(T). from A. The level of security required is a feature of the Trust
Domain i.e. it is defined in Spec(T).
We say that a node, A, in the domain is ætrusted byÆ a node, B, Within this context, SIP signaling information received by one node
outside the domain if and only if: FROM a node that it trusts is known to have been generated and passed
through the network according to the procedures of the particular
specification set Spec(T), and therefore can be known to be valid, or
at least as valid as specified in the specifications Spec(T).
(i) there is a secure connection between the nodes, AND Equally, a node can be sure that signaling information passed TO a
(ii) B has configuration information indicating that A is a member of node that it trusts will be handled according to the procedures of
the Trust Domain. Spec(T).
This most often applies to a UA which trusts a given network For these capabilities to be useful, Spec(T) must contain
intermediary (e.g. its home proxy). requirements as to how the Network Asserted Identity is generated,
how its privacy is protected and how its integrity is maintained as
it is passed around the network. A reader of Spec(T) can then make an
informed judgement about the authenticity and reliability of Network
Asserted Information received from the Trust Domain T.
The term ætrustedÆ (with respect to a given Trust Domain) can be The term ætrustedÆ (with respect to a given Trust Domain) can be
applied to a given node in an absolute sense û it is just equivalent applied to a given node in an absolute sense û it is just equivalent
to saying the node is a member of the Trust Domain. However, the node to saying the node is a member of the Trust Domain. However, the node
itself does not know whether another arbitrary node is ætrustedÆ, itself does not know whether another arbitrary node is ætrustedÆ,
even within the Trust Domain. It does know about certain nodes with even within the Trust Domain. It does know about certain nodes with
which it has secure connections as described above. which it has secure connections as described above.
With the definition above, statements such as æA trusted node SHALL With the definition above, statements such as æA trusted node SHALL
...Æ are just shorthand for æA node compliant to this specification ...Æ are just shorthand for æA node compliant to this specification
SHALL...Æ. SHALL...Æ.
Statements such as æWhen a node receives information from a trusted Statements such as æWhen a node receives information from a trusted
node...Æ are NOT valid, because one node does not have complete node...Æ are NOT valid, because one node does not have complete
knowledge about all the other nodes in the trust domain. knowledge about all the other nodes in the trust domain.
Statements such as æWhen a node receives information from another Statements such as æWhen a node receives information from another
node that it trusts...Æ ARE valid, and should be interpreted node that it trusts...Æ ARE valid, and should be interpreted
according to the criteria (i) and (ii) above. according to the criteria (i) and (ii) above.
Within this context, SIP signaling information received by one node
FROM a node that it trusts is known to have been generated and passed
through the network according to the procedures of the particular
specification set Spec(T), and therefore can be known to be valid, or
at least as valid as specified in the specifications Spec(T).
Equally, a node can be sure that signaling information passed TO a
node that it trusts will be handled according to the procedures of
Spec(T).
For these capabilities to be useful, Spec(T) must contain
requirements as to how the Network Asserted Identity is generated,
how its privacy is protected and how its integrity is maintained as
it is passed around the network. A reader of Spec(T) can then make an
informed judgement about the authenticity and reliability of Network
Asserted Information received from the Trust Domain T.
3. Generation of Network Asserted Identity 3. Generation of Network Asserted Identity
A Network Asserted Identity is generated by a network intermediary A Network Asserted Identity is generated by a network intermediary
following an Authentication process which authenticates the entity following an Authentication process which authenticates the entity
(UA) to be identified. (UA) to be identified.
The Authentication process(es) used are a characteristic feature of The Authentication process(es) used are a characteristic feature of
the Trust Domain, and MUST be specified in Spec(T). the Trust Domain, and MUST be specified in Spec(T).
It shall be possible for a UA to provide a prefered identity to the It shall be possible for a UA to provide a preferred identity to the
network intermediary, which MAY be used to inform the generation of network intermediary, which MAY be used to inform the generation of
the Network Asserted Identity according to the policies of the Trust the Network Asserted Identity according to the policies of the Trust
Domain. Domain.
4. Transport of Network Asserted Identity 4. Transport of Network Asserted Identity
4.1 Sending of Network Asserted Identity within a Trust Domain 4.1 Sending of Network Asserted Identity within a Trust Domain
It shall be possible for one node within a Trust Domain to securely It shall be possible for one node within a Trust Domain to securely
send a Network Asserted Identity to another node that it trusts. send a Network Asserted Identity to another node that it trusts.
4.2 Receiving of Network Asserted Identity withing a Trust Domain 4.2 Receiving of Network Asserted Identity withing a Trust Domain
It shall be possible for one node within a Trust Domain to receive a It shall be possible for one node within a Trust Domain to receive a
Network Asserted identity from another node that it trusts. Network Asserted identity from another node that it trusts.
4.3 Sending of Network Asserted Identity to entities outside a Trust 4.3 Sending of Network Asserted Identity to entities outside a Trust
Domain Domain
It shall be possible for a node within the Trust Domain to securely If a node, A, within the Trust Domain, is trusted by a node, B,
send a Network Asserted Identity to a node outside the trust domain. outside the Trust Domain, then it shall be possible for A to securely
send a Network Asserted Identity to B.
This is most often used to pass a Network Asserted Identity directly This is most often used to pass a Network Asserted Identity directly
to a UA. to a UA.
4.4 Receiving of Network Asserted Identity by a node outside the Trust 4.4 Receiving of Network Asserted Identity by a node outside the Trust
Domain Domain
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.
skipping to change at page 7, line 4 skipping to change at page 6, line 40
an INVITE identifies the party who has answered. an INVITE identifies the party who has answered.
6. Types of Network Asserted Identity 6. Types of Network Asserted Identity
Each party shall have at most one Network Asserted Identity. Each party shall have at most one Network Asserted Identity.
It shall be possible for the capability to transport multiple It shall be possible for the capability to transport multiple
identities associated with a single party to be introduced in future. identities associated with a single party to be introduced in 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 draft.
It shall be possible to indicate that a Network Asserted Identity is It shall be possible to indicate that a 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. other users.
In this case, the Network Asserted Identity specification shall It shall be possible to indicate that the user has requested that the
require that the mechanism of 3.2 SHALL NOT be used i.e. a trusted Network Asserted Identity be not passed to other users.
node shall not pass the identity to a node it does not trust.
However, the mechanism of 3.1 MAY be used to transfer the identity
within the trusted network.
It shall be possible to indicate whether the Network Asserted The mechanism shall support Trust Domain policies where the above two
Identity is private due to a request from the user/subscriber or for indications are equivalent, and policies where they are not.
another reason.
The Network Asserted Identity specification shall require that in the
case that the Network Asserted Identity cannot be passed to other
users, the mechanism of 3.2 SHALL NOT be used i.e. a trusted node
shall not pass the identity to a node it does not trust. However, the
mechanism of 3.1 MAY be used to transfer the 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. Next steps 8. Next steps
It is proposed to use draft-jennings-sipping-nai-00 [2] to implement It is has been agreed to adopt draft-jennings-sipping-nai-00 [2] as a
the requirements of this draft. working group item to implement the requirements of this draft.
9. Security considerations 9. Security considerations
The requirements in this draft are NOT intended to result in a The requirements in this draft 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
 End of changes. 

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