< draft-ietf-sipping-nai-reqs-01.txt		draft-ietf-sipping-nai-reqs-02.txt >
			A new Request for Comments is now available in online RFC libraries.
	Internet Draft Mark Watson		RFC 3324
	Document: draft-ietf-sipping-nai-reqs-01.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
	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
	1. Introduction...................................................2
	2. Definitions....................................................2
	2.1 Identity...................................................2
	2.2 Network Asserted Identity..................................3
	2.3 Trust Domains..............................................3
	3. Generation 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.2 Receiving of Network Asserted Identity withing a Trust Domain
	...............................................................5
	4.3 Sending of Network Asserted Identity to entities outside a
	Trust Domain...................................................5
	4.4 Receiving of Network Asserted Identity by a node outside the
	Trust Domain...................................................5
	5. Parties with Network Asserted Identities.......................6
	6. Types of Network Asserted Identity.............................6
	7. Privacy of Network Asserted Identity...........................6
	8. Next steps.....................................................7
	9. Security considerations........................................7
	10. IANA Considerations...........................................7
	11. References....................................................8
	12. Acknowledgments...............................................8
	13. AuthorsÆ Addresses............................................8
	14. Full Copyright Statement......................................8
	1. Introduction
	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 Digest
	Authentication (or by other means). However, UAs do not always have
	the necessary key information to authenticate another UA. .
	A Network Asserted Identity is an identity initially derived by a SIP
	network intermediary as a result of an authentication process. This
	may or may not be based on SIP Digest 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 and we
	present a strict definition of trust and Trust Domain for the
	purposes of this draft. These short-term requirements provide only
	for the exchange of Network Asserted Identitied within a Trust Domain
	and to an entity directly connected to the trust domain.
	General requirements for transport of Network Asserted Identities on
	the Internet are out of scope of this draft.
	2. Definitions
	2.1 Identity
	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
	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
	of the domain identified in the URI, the URI MAY identify some
	specific entity, such as a person.
	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
	number MAY identify some specific entity, such as a telephone line.
	However, it should be noted that identifying the owner of the number
	range is a less straightforward process than identifying the domain
	which owns a sip: or sips: URI.
	2.2 Network Asserted Identity
	A Network Asserted Identity is an identity derived by a SIP network
	entity as a result of an authentication process.
	The authentication process used, or at least it's
	reliability/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 defined in Spec(T).
	2.3 Trust Domains
	A Trust Domain for the purposes of Network Asserted Identity is a set
	of SIP nodes (UAC, UAS, proxies or other network intermediaries) that
	are trusted to exchange Network Asserted Identity information in the
	sense described below.
	A node can be a member of a Trust Domain, T, only if the node is know
	to be compliant to a certain set of specifications, Spec(T), which
	characterize the handling of Network Asserted Identity within the
	Trust Domain, T.
	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
	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
	æB trusts AÆ) if and only 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.
	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
	read by third parties, cannot be modified by third parties without
	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
	Domain i.e. it is defined in Spec(T).
	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.
	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.
	3. Generation of Network Asserted Identity
	A Network Asserted Identity is generated by a network intermediary
	following an Authentication process which authenticates the entity
	(UA) to be identified.
	The Authentication process(es) used are a characteristic feature of
	the Trust Domain, and MUST be specified in Spec(T).
	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
	the Network Asserted Identity according to the policies of the Trust
	Domain.
	4. Transport of Network Asserted Identity
	4.1 Sending of Network Asserted Identity within a Trust Domain
	It shall be possible for one node within a Trust Domain to securely
	send a Network Asserted Identity to another node that it trusts.
	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
	Network Asserted identity from another node that it trusts.
	4.3 Sending of Network Asserted Identity to entities outside a Trust
	Domain
	If a node, A, within the Trust Domain, is trusted by a node, B,
	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
	to a UA.
	4.4 Receiving of Network Asserted Identity by a node outside the Trust
	Domain
	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 received in this way may be considered
	valid, and used for display to the user, input data for services etc.
	Network Asserted Identity information received by one node from a
	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
	followed to generate and transport the information. Such information
	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.
	5. Parties with Network Asserted Identities
	A Network Asserted Identity identifies the originator of the message
	in which it was received.
	For example,
	o a Network Asserted Identity received in an initial INVITE
	(outside the context of any existing dialog) identifies the
	calling party.
	o a Network Asserted Identity received in a 180 Ringing response
	to such an INVITE identifies the party who is ringing.
	o a Network Asserted Identity received in a 200 response to such
	an INVITE identifies the party who has answered.
	6. 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.
	7. 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.
	It shall be possible to indicate that the user has requested that the
	Network Asserted Identity be not passed to other users.
	The mechanism shall support Trust Domain policies where the above two
	indications are equivalent, and policies where they are not.
	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
	require functionality in addition to the above handling of Network
	Asserted Identities. Such additional functionality is out of the
	scope of this document.
	8. Next steps
	It is has been agreed to adopt draft-jennings-sipping-nai-00 [2] as a
	working group item to implement the requirements of this draft.
	9. 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 (Spec(T)) and between which there are
	secure connections. Such a community is known here as a Trust Domain.
	The requirements on the mechanisms used for security and to initially
	derive the Network Asserted Identity must be part of the
	specification Spec(T).
	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.
	10. IANA Considerations		Title: Short Term Requirements for Network Asserted
			Identity
			Author(s): M. Watson
			Status: Informational
			Date: November 2002
			Mailbox: mwatson@nortelnetworks.com
			Pages: 11
			Characters: 21964
			Updates/Obsoletes/SeeAlso: None
	This document does not have any implications for IANA.		I-D Tag: draft-ietf-sipping-nai-reqs-02.txt
	11. References		URL: ftp://ftp.rfc-editor.org/in-notes/rfc3324.txt
	[1] J. Rosenberg et al, ôSIP: Session initiation protocol," draft-		A Network Asserted Identity is an identity initially derived by
	ietf-sip-rfc2543bis-09.txt, February 27th, 2002.		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.
	[2] C.Jennings, ôNetwork Asserted Identity headerö, draft-jennings-		There is no requirement for identities asserted by a UA in a SIP
	sipping-nai-00, May 2002, work in progress.		message to be anything other than the user's desired alias.
	12. Acknowledgments		This document is a product of the Session Initiation Proposal
			Investigation Working Group of the IETF.
	Thanks are due to Jon Peterson, Cullen Jennings and Allison Mankin		This memo provides information for the Internet community. It does
	for comments on this draft.		not specify an Internet standard of any kind. Distribution of this
			memo is unlimited.
	13. AuthorsÆ Addresses		This announcement is sent to the IETF list and the RFC-DIST list.
			Requests to be added to or deleted from the IETF distribution list
			should be sent to IETF-REQUEST@IETF.ORG. Requests to be
			added to or deleted from the RFC-DIST distribution list should
			be sent to RFC-DIST-REQUEST@RFC-EDITOR.ORG.
	Mark Watson		Details on obtaining RFCs via FTP or EMAIL may be obtained by sending
	Nortel Networks (UK)		an EMAIL message to rfc-info@RFC-EDITOR.ORG with the message body
	Maidenhead Office Park (Bray House)		help: ways_to_get_rfcs. For example:
	Westacott Way
	Maidenhead,
	Berkshire Tel: +44 (0)1628-434456
	England Email: mwatson@nortelnetworks.com
	14. Full Copyright Statement		To: rfc-info@RFC-EDITOR.ORG
			Subject: getting rfcs
	Copyright (C) The Internet Society (2002). All Rights Reserved.		help: ways_to_get_rfcs
	This document and translations of it may be copied and furnished to		Requests for special distribution should be addressed to either the
	others, and derivative works that comment on or otherwise explain it		author of the RFC in question, or to RFC-Manager@RFC-EDITOR.ORG. Unless
	or assist in its implementation may be prepared, copied, published		specifically noted otherwise on the RFC itself, all RFCs are for
	and distributed, in whole or in part, without restriction of any		unlimited distribution.echo
	kind, provided that the above copyright notice and this paragraph are		Submissions for Requests for Comments should be sent to
	included on all such copies and derivative works. However, this		RFC-EDITOR@RFC-EDITOR.ORG. Please consult RFC 2223, Instructions to RFC
	document itself may not be modified in any way, such as by removing		Authors, for further information.
	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."
End of changes. 14 change blocks.
	347 lines changed or deleted		37 lines changed or added
This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/