Network Working Group                                          M. Watson
Request for Comments: 3324                               Nortel Networks
Category: Informational                                    November 2002
        
Network Working Group                                          M. Watson
Request for Comments: 3324                               Nortel Networks
Category: Informational                                    November 2002
        

Short Term Requirements for Network Asserted Identity

网络断言身份的短期要求

Status of this Memo

本备忘录的状况

This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.

本备忘录为互联网社区提供信息。它没有规定任何类型的互联网标准。本备忘录的分发不受限制。

Copyright Notice

版权公告

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

版权所有(C)互联网协会(2002年)。版权所有。

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.

网络断言标识是最初由会话发起协议(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.

不要求UA在SIP消息中声明的身份不是用户所需的别名。

Table of Contents

目录

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  2
   2.  Definitions  . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.1 Identity . . . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.2 Network Asserted Identity  . . . . . . . . . . . . . . . . . .  3
   2.3 Trust Domains  . . . . . . . . . . . . . . . . . . . . . . . .  4
   2.4 Spec(T)  . . . . . . . . . . . . . . . . . . . . . . . . . . .  7
   3.  Generation of Networks Asserted Identity . . . . . . . . . . .  7
   4.  Transport of Network Asserted Identity . . . . . . . . . . . .  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.3 Sending of Network Asserted Identity to entities outside a
       Trust Domain . . . . . . . . . . . . . . . . . . . . . . . . .  7
   4.4 Receiving of Network Asserted Identity by a node outside the
       Trust Domain . . . . . . . . . . . . . . . . . . . . . . . . .  8
   5.  Parties with Network Asserted Identities . . . . . . . . . . .  8
   6.  Types of Network Asserted Identity . . . . . . . . . . . . . .  8
   7.  Privacy of Network Asserted Identity . . . . . . . . . . . . .  9
   8.  Security Considerations  . . . . . . . . . . . . . . . . . . .  9
   9.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 10
   10. Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 10
       Normative References . . . . . . . . . . . . . . . . . . . . . 10
       Author's Address . . . . . . . . . . . . . . . . . . . . . . . 10
       Full Copyright Statement . . . . . . . . . . . . . . . . . . . 11
        
   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  2
   2.  Definitions  . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.1 Identity . . . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.2 Network Asserted Identity  . . . . . . . . . . . . . . . . . .  3
   2.3 Trust Domains  . . . . . . . . . . . . . . . . . . . . . . . .  4
   2.4 Spec(T)  . . . . . . . . . . . . . . . . . . . . . . . . . . .  7
   3.  Generation of Networks Asserted Identity . . . . . . . . . . .  7
   4.  Transport of Network Asserted Identity . . . . . . . . . . . .  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.3 Sending of Network Asserted Identity to entities outside a
       Trust Domain . . . . . . . . . . . . . . . . . . . . . . . . .  7
   4.4 Receiving of Network Asserted Identity by a node outside the
       Trust Domain . . . . . . . . . . . . . . . . . . . . . . . . .  8
   5.  Parties with Network Asserted Identities . . . . . . . . . . .  8
   6.  Types of Network Asserted Identity . . . . . . . . . . . . . .  8
   7.  Privacy of Network Asserted Identity . . . . . . . . . . . . .  9
   8.  Security Considerations  . . . . . . . . . . . . . . . . . . .  9
   9.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 10
   10. Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 10
       Normative References . . . . . . . . . . . . . . . . . . . . . 10
       Author's Address . . . . . . . . . . . . . . . . . . . . . . . 10
       Full Copyright Statement . . . . . . . . . . . . . . . . . . . 11
        
1. Introduction
1. 介绍

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.

SIP[1]允许用户以多种方式声明其身份,例如使用From:头。但是,这些标识不要求是用户所需的别名以外的任何内容。

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.

可以使用SIP摘要身份验证(或通过其他方式)获得用户的身份验证。然而,UAs并不总是拥有必要的密钥信息来认证另一个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 document 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.

网络断言标识是最初由SIP网络中介作为身份验证过程的结果而派生的标识。这可能基于SIP摘要身份验证,也可能不基于SIP摘要身份验证。本文档描述了在安全互连的受信任节点网络内交换网络断言身份的短期要求,以及对具有此类网络安全连接的用户代理的短期要求。

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 purposes of this document. These short-term requirements provide only for the exchange of Network Asserted Identity 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 document.

在互联网上传输网络断言身份的一般要求不在本文件范围内。

2. Definitions
2. 定义
2.1 Identity
2.1 身份

An Identity, for the purposes of this document, is a sip:, sips: or tel: URI, and optionally a Display Name.

就本文档而言,标识是sip:、sips:或tel:URI,以及可选的显示名称。

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 tel: URIs), in the sense that when used as a SIP Request-URI in a request sent to that domain/number range owner, it would cause the request to be routed to the user/line that is associated with the identity, or to be processed by service logic running on that user's behalf.

URI必须对URI中标识的域(在sip:或sips:URI的情况下)或E.164号码的所有者(在tel:URI的情况下)有意义,即当在发送给该域/号码范围所有者的请求中用作sip请求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.

如果URI是sip:或sips:URI,则根据URI中标识的域的本地策略,URI可以标识某些特定实体,例如人。

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.

如果URI是tel:URI,则根据电话号码所在的号码范围所有者的本地策略,该号码可以标识某些特定实体,例如电话线。但是,应该注意的是,与识别拥有sip:或sips:URI的域相比,识别号码范围的所有者不是一个简单的过程。

2.2 Network Asserted Identity
2.2 网络断言身份

A Network Asserted Identity is an identity derived by a SIP network entity as a result of an authentication process, which identifies the authenticated entity in the sense defined in Section 2.1.

网络断言标识是由SIP网络实体作为身份验证过程的结果而派生的标识,该身份验证过程按照第2.1节中定义的含义来标识身份验证实体。

In the case of a sip: or sips: URI, the domain included in the URI MUST be within the Trust Domain.

对于sip:或sips:URI,URI中包含的域必须位于信任域内。

In the case of a tel: URI, the owner of the E.164 number in the URI MUST be within the Trust Domain.

对于tel:URI,URI中E.164号码的所有者必须在信任域内。

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的语言中,它在规范(T)中定义。

2.3 Trust Domains
2.3 信任域

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.

出于网络断言身份的目的,信任域是一组SIP节点(UAC、UAS、代理或其他网络中介),它们被信任以交换下文所述意义上的网络断言身份信息。

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.

一个节点可以是信任域T的成员,只有当知道该节点符合一组特定的规范Spec(T),Spec(T)描述了信任域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:

我们说域中的节点a被节点B“信任”(或“B信任a”),当且仅当:

1. there is a secure connection between the nodes, AND

1. 节点之间存在安全连接,并且

2. B has configuration information indicating that A is a member of the Trust Domain.

2. B具有表示A是信任域成员的配置信息。

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).

请注意,B可能是也可能不是信任域的成员。例如,B可以是信任给定网络中介a(例如,其归属代理)的UA。

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).

在此上下文中,“安全连接”意味着第三方无法读取消息,第三方无法在未经检测的情况下修改消息,并且B可以确保消息确实来自A。所需的安全级别是信任域的一个功能,即,它在规范(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).

在该上下文中,一个节点从其信任的节点接收的SIP信令信息已知已经根据特定规范集Spec(T)的过程生成并通过网络传递,因此可以已知是有效的,或者至少与规范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).

同样,节点可以确保传递给其信任的节点的信令信息将根据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.

为了使这些功能有用,规范(T)必须包含有关如何生成网络断言身份、如何保护其隐私以及如何在网络中传递时保持其完整性的要求。然后,Spec(T)的读取器可以对从信任域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 (1) and (2) above.

诸如“当一个节点从它信任的另一个节点接收到信息时…”之类的语句是有效的,应该根据上述标准(1)和(2)进行解释。

The above relationships are illustrated in the following figure:

下图说明了上述关系:

                                        +------+
                                        |      |
                                        |  F   |
                                        |      |
                                        +------+
                                            x
              ..............................x.........
              .                             x        .
              .    +------+             +------+     .    +------+
              .    |      |             |      |     .    |      |
              .    |  A   |             |  B   |-----.----|  E   |
              .    |      |             |      |     .    |      |
              .    +------+             +------+     .    +------+
              .       \\                   /         .
              .         \\    +------+   //          .
              .           \\  |      | //            .
              .             \ |  C   |/              .
              .               |      |               .
              .               +------+               .
              .                   |      Trust Domain.
              ........................................
                                  |
                                  |
                              +------+
                              |      |
                              |  D   |
                              |      |
                              +------+
        
                                        +------+
                                        |      |
                                        |  F   |
                                        |      |
                                        +------+
                                            x
              ..............................x.........
              .                             x        .
              .    +------+             +------+     .    +------+
              .    |      |             |      |     .    |      |
              .    |  A   |             |  B   |-----.----|  E   |
              .    |      |             |      |     .    |      |
              .    +------+             +------+     .    +------+
              .       \\                   /         .
              .         \\    +------+   //          .
              .           \\  |      | //            .
              .             \ |  C   |/              .
              .               |      |               .
              .               +------+               .
              .                   |      Trust Domain.
              ........................................
                                  |
                                  |
                              +------+
                              |      |
                              |  D   |
                              |      |
                              +------+
        
          xxxxxx   Insecure connection
          ------   Secure connection
        
          xxxxxx   Insecure connection
          ------   Secure connection
        
          ......
          .    .All boxes within the dotted line
          ......are part of the same Trust Domain
        
          ......
          .    .All boxes within the dotted line
          ......are part of the same Trust Domain
        

o A, B and C are part of the same trust domain

o A、 B和C是同一信任域的一部分

o A trusts C, but A does not trust B

o A信任C,但A不信任B

o since E knows that B is inside of the trust domain, E

o 因为E知道B在信任域内,所以E

o trusts B, but B does not trust E

o 信任B,但B不信任E

o B does not trust F, F does not trust B

o B不信任F,F不信任B

2.4 Spec(T)
2.4 规格(T)

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 specifications generally referred to as Spec(T). Spec(T) is not a specification in the sense of a written document; rather, its an agreed upon set of information that all elements are aware of. Proper processing of the asserted identities requires that the elements know what is actually being asserted, how it was determined, and what the privacy policies are. All of that information is characterized by Spec(T).

信任域定义的一个方面是,该域中的所有元素都符合通常称为Spec(T)的一组配置和规范。规范(T)不是书面文件意义上的规范;相反,它是所有元素都知道的一组商定的信息。正确处理断言的身份要求元素知道实际断言的内容、如何确定以及隐私策略是什么。所有这些信息都以Spec(T)为特征。

3. Generation of Networks Asserted Identity
3. 网络身份的生成

A Network Asserted Identity is generated by a network intermediary following an Authentication process which authenticates the entity (UA) to be identified.

网络断言标识由网络中介在认证过程之后生成,该认证过程认证要识别的实体(UA)。

The Authentication process(es) used are a characteristic feature of the Trust Domain, and MUST be specified in Spec(T).

所使用的身份验证过程是信任域的特征,必须在规范(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.

UA应能够向网络中介提供优选身份,该优选身份可用于根据信任域的策略通知网络断言身份的生成。

4. Transport of Network Asserted Identity
4. 网络身份的传输
4.1 Sending of Networks Asserted Identity within a Trust Domain
4.1 在信任域内发送网络断言的身份

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 within a Trust Domain
4.2 在信任域内接收网络断言的身份

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

4.3 向信任域之外的实体发送网络断言标识

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, if allowed by the privacy policies of the user that has been identified, and the trust domain.

如果信任域内的节点a受到信任域外的节点B的信任,则如果已识别用户的隐私策略和信任域允许,则a可以安全地向B发送网络断言的身份。

This is most often used to pass a Network Asserted Identity directly to a UA.

这通常用于将网络断言标识直接传递给UA。

4.4 Receiving of Network Asserted Identity by a node outside the Trust Domain

4.4 信任域之外的节点接收网络断言的身份

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.)

一个节点从其不信任的节点接收到的网络断言身份信息不能保证真实性或完整性,因为不知道是否遵循了规范(T)中的程序来生成和传输信息。不得使用此类信息。(即,不得向用户显示、传递给其他节点、用作服务的输入数据等)

5. Parties with Network Asserted Identities
5. 具有网络断言身份的当事人

A Network Asserted Identity identifies the originator of the message in which it was received.

网络断言标识标识接收到该标识的消息的发起者。

For example,

例如

a Network Asserted Identity received in an initial INVITE (outside the context of any existing dialog) identifies the calling party.

在初始邀请中接收的网络断言标识(在任何现有对话框的上下文之外)标识呼叫方。

a Network Asserted Identity received in a 180 Ringing response to such an INVITE identifies the party who is ringing.

在对这样的邀请的180振铃响应中接收到的网络断言标识识别正在振铃的一方。

a Network Asserted Identity received in a 200 response to such an INVITE identifies the party who has answered.

在对这样的邀请的200响应中接收到的网络断言身份识别已应答的一方。

6. Types of Network Asserted Identity
6. 网络断言标识的类型

It shall be possible to assert multiple identities associated with a given party (in a given message), provided that these are of distinct types.

可以断言与给定方(在给定消息中)关联的多个身份,前提是这些身份具有不同的类型。

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 not required to transport both a sip: and sips: URI.

支持的标识类型应为sip:、sips:和tel:URI,所有这些标识均按照第2.1节所述识别用户。不需要同时传输sip:和sips:URI。

It shall be possible for the capability to transport additional types of identity associated with a single party to be introduced in future.

将来应能够传输与一方相关的其他类型的身份。

7. Privacy of Network Asserted Identity
7. 网络身份的隐私性

The means by which any privacy requirements in respect of the Network Asserted Identity are determined are outside the scope of this document.

确定与网络断言身份相关的任何隐私要求的方法不在本文件的范围内。

It shall be possible to indicate within a message containing a Network Asserted Identity that this Network Asserted Identity is subject to a privacy requirement which prevents it being passed to other users. This indication should not carry any semantics as to the reason for this privacy requirement.

应能够在包含网络断言身份的消息中指出,该网络断言身份受隐私要求的约束,该隐私要求防止将其传递给其他用户。此指示不应包含任何关于此隐私要求原因的语义。

It shall be possible to indicate that the user has requested that the Network Asserted Identity be not passed to other users. This is distinct from the above indication, in that it implies specific user intent with respect to the Network Asserted Identity.

应能够指示用户已请求不将网络断言的身份传递给其他用户。这与上述指示不同,因为它暗示了与网络断言标识相关的特定用户意图。

The mechanism shall support Trust Domain policies where the above two indications are equivalent (i.e., the only possible reason for a privacy requirement is a request from the user), and policies where they are not.

该机制应支持上述两个指示等效的信任域策略(即,隐私要求的唯一可能原因是用户的请求),以及不等效的策略。

In this case, the Network Asserted Identity specification shall 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. However, the mechanism of Section 4.3 MAY be used to transfer the identity within the trusted network.

在这种情况下,网络断言的身份规范应要求不得使用第4.3节的机制,即受信任节点不得将身份传递给其不信任的节点。然而,第4.3节的机制可用于在可信网络内传输身份。

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. Security Considerations
8. 安全考虑

The requirements in this document 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.

相反,目的是说明在已知遵守机制规范(Spec(T))且在其之间存在安全连接的装置社区内使用的机制的要求。这样的社区在这里称为信任域。

The requirements on the mechanisms used for security and to initially derive the Network Asserted Identity must be part of the specification Spec(T).

对用于安全和最初派生网络断言标识的机制的要求必须是规范Spec(T)的一部分。

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
9. IANA考虑

This document does not have any implications for IANA.

本文件对IANA没有任何影响。

10. Acknowledgments
10. 致谢

Thanks are due to Jon Peterson, Cullen Jennings, Allison Mankin and Jonathan Rosenberg for comments on this document.

感谢Jon Peterson、Cullen Jennings、Allison Mankin和Jonathan Rosenberg对本文件的评论。

Normative References

规范性引用文件

[1] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M. and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, June 2002.

[1] Rosenberg,J.,Schulzrinne,H.,Camarillo,G.,Johnston,A.,Peterson,J.,Sparks,R.,Handley,M.和E.Schooler,“SIP:会话启动协议”,RFC 3261,2002年6月。

Author's Address

作者地址

Mark Watson Nortel Networks Maidenhead Office Park Westacott Way Maidenhead, BERKS SL6 3QH UK

Mark Watson Nortel Networks Maidenhead Office Park Westacott Way Maidenhead,伯克斯SL6第三季度英国

   EMail: mwatson@nortelnetworks.com
        
   EMail: mwatson@nortelnetworks.com
        

Full Copyright Statement

完整版权声明

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

版权所有(C)互联网协会(2002年)。版权所有。

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.

RFC编辑功能的资金目前由互联网协会提供。