Internet Draft Mark Watson
Document: draft-watson-sipping-nai-reqs-00.txt Nortel Networks
Category: Informational
Expires November 2002 May 2002
Short term requirements for Network Asserted Identity
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.
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
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 obtained 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.
General requirements for transport of Network Asserted Identities on
the Internet are out of scope of this draft.
Table of Contents
1. Introduction
Watson Expires - November 2002 [Page 1]
Network Asserted Identity û short term requirements May 2002
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
these identities to be anything other than the users desired alias.
An authenticated identity of a user can be obtained using SIP
Authentication (or by other means). However, it is unlikely that the
necessary Public Key Infrastructure to globally facilitate this for
users will be available soon.
A Network Asserted Identity is an identity obtained by a SIP network
intermediary as a result of an authentication process. This may or
may not be based on SIP authentication. This draft describes short
term requirements for the exchange of Network Asserted Identities
within networks of securely interconnected trusted nodes and also to
User Agents with secure connections to such networks.
Such a network is described in this draft as a Trust Domain. These
short-term requirements provide only for the exchange of Network
Asserted Identitied within a Trust Domain.
General requirements for transport of Network Asserted Identities on
the Internet are out of scope of this draft.
2. Trust Domains
A Trust Domain for the purposes of Network Asserted Identity is a set
of SIP nodes (UAC, UAS, proxiesor other network intermediaries) that
are known to be compliant to SIP specifications for Network Asserted
Identity.
This document presents requirements for such specifications.
Trust Domains are constructed by human beings who know the properties
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
accurately know the behaviour of those devices.
Such simple Trust Domains may be joined into larger Trust Domains by
bi-lateral agreements between the owners/operators of the devices.
We say a node is ætrustedÆ (with respect to a given Trust Domain) if
it is a member of that domain.
We say that one node in the domain is ætrusted byÆ another if:
(i) there is a secure connection between the nodes, AND
(ii) they have configuration information to indicate that they are
members of the same Trust Domain.
Watson Expires - NovemberOctober 2002 [Page 2]
Network Asserted Identity û short term requirements May 2002
This most often applies to network intermediaries such as proxies in
the Trust Domain.
A æsecure connectionÆ in this context means that messages cannot be
read by third parties and cannot be modified or inserted by third
parties without detection (e.g. IPSEC, TLS etc.).
We say that a node, A, in the domain is ætrusted byÆ a node, B,
outside the domain if:
(i) there is a secure connection between the nodes, AND
(ii) B has configuration information indicating that A is a member of
the Trust Domain.
This most often applies to a UA which trusts a given network
intermediary (e.g. its home proxy).
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
to saying the node is a member of the Trust Domain. However, the node
itself does not know whether another arbitrary node is ætrustedÆ,
even within the Trust Domain. It does know about certain nodes with
which it has secure connections as described above.
With the definition above, statements such as æA trusted node SHALL
...Æ are just shorthand for æA node compliant to this specification
SHALL...Æ.
Statements such as æWhen a node receives information from a trusted
node...Æ are NOT valid, because one node does not have complete
knowledge about all the other nodes in the trust domain.
Statements such as æWhen a node receives information from another
node that it trusts...Æ ARE valid, and should be interpreted
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, and therefore can be known to be valid, or at
least as valid as specified in the specifications.
3. Transport of Network Asserted Identity
3.1 Passing of Network Asserted Identity within a Trust Domain
It shall be possible for one node within a Trust Domain to securely
pass a Network Asserted Identity to another node that it trusts.
Watson Expires - NovemberOctober 2002 [Page 3]
Network Asserted Identity û short term requirements May 2002
3.2 Passing of Network Asserted Identity to entities outside a Trust
Domain
It shall be possible for a node within the Trust Domain to securely
pass a Network Asserted Identity to a node outside the trust domain.
This is most often used to pass a Network Asserted Identity directly
to a UA.
A node SHOULD disregard Network Asserted Identity received from a
node it does not trust.
Note that a node outside the Trust Domain receiving this information
MAY pass it on to other nodes. However, such information SHOULD NOT
be treated as valid, since nodes outside the Trust Domain are not
guaranteed to operate according to the Network Asserted Identity
specification, and so may have modified the Network Asserted
Identity.
4. Parties with Network Asserted Identities
4.1 Calling user
A Network Asserted Identity of the calling user shall be supported.
4.2 Called user
A Network Asserted Identity of the called user shall be supported.
4.3 Extensibility
It shall be possible to define further parties to whom Network
Asserted Identities may relate in future.
5. Types of Network Asserted Identity
Each party shall have at most one Network Asserted Identity.
It shall be possible for the capability to transport multiple
identities associated with a single party to be introduced in future.
6. Privacy of Network Asserted Identity
The means by which any privacy requirements in respect of the Network
Asserted Identity are determined are outside the scope of this draft.
It shall be possible to indicate that a Network Asserted Identity is
subject to a privacy requirement which prevents it being passed to
other users.
Watson Expires - NovemberOctober 2002 [Page 4]
Network Asserted Identity û short term requirements May 2002
In this case, the Network Asserted Identity specification shall
require that 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.
It shall be possible to indicate whether the Network Asserted
Identity is private due to a request from the user/subscriber or for
another reason.
Note that æanonymityÆ requests from users or subscribers may well
require functionality in addition to the above handling of Network
Asserted Identities. Such additional functionality is out of the
scope of this document.
7. Next steps
It is proposed to rapidly specify a mechanism to meet the
requirements of this draft.
It should be noted that the mechanisms of [2] meet all the above
requirements (and some others).
8. Security considerations
The requirements in this draft are NOT intended to result in a
mechanism with general applicability between arbitrary hosts on the
Internet.
Rather, the intention is to state requirements for a mechanism to be
used within a community of devices which are known to obey the
specification of the mechanism and between which there are secure
connections. Such a community is known as a Trust Domain.
Such devices may be hosts on the Internet.
The requirements also support the transfer of information from a node
within the Trust Domain, via a secure connection to a node outside
the Trust Domain.
Use of this mechanism in any other context has serious security
shortcomings, namely that there is absolutely no guarantee that the
information has not been modified, or was even correct in the first
place.
9. IANA Considerations
This document does not have any implications for IANA.
Watson Expires - NovemberOctober 2002 [Page 5]
Network Asserted Identity û short term requirements May 2002
10. References
[1] J. Rosenberg et al, ôSIP: Session initiation protocol," draft-
ietf-sip-rfc2543bis-09.txt, February 27th, 2002.
[2] W. Marshall et al, "SIP Extensions for Caller Identity and th Privacy", draft-ietf-sip-privacy-04.txt, February 27 , 2002.
11. Acknowledgments
12. AuthorsÆ Addresses
Mark Watson
Nortel Networks (UK)
Maidenhead Office Park (Bray House)
Westacott Way
Maidenhead,
Berkshire Tel: +44 (0)1628-434456
England Email: mwatson@nortelnetworks.com
13. 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
Watson Expires - NovemberOctober 2002 [Page 6]
Network Asserted Identity û short term requirements May 2002
ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A
PARTICULAR PURPOSE."
Watson Expires - NovemberOctober 2002 [Page 7]