RFC4572 日本語訳

Network Working Group                                          J. Lennox
Request for Comments: 4572                                   Columbia U.
Updates: 4145                                                  July 2006
Category: Standards Track

Network Working Group J. Lennox Request for Comments: 4572 Columbia U. Updates: 4145 July 2006 Category: Standards Track

 Connection-Oriented Media Transport over the Transport Layer Security
        (TLS) Protocol in the Session Description Protocol (SDP)

Connection-Oriented Media Transport over the Transport Layer Security (TLS) Protocol in the Session Description Protocol (SDP)

Status of This Memo

Status of This Memo

   This document specifies an Internet standards track protocol for the
   Internet community, and requests discussion and suggestions for
   improvements.  Please refer to the current edition of the "Internet
   Official Protocol Standards" (STD 1) for the standardization state
   and status of this protocol.  Distribution of this memo is unlimited.

This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.

Copyright Notice

Copyright Notice

   Copyright (C) The Internet Society (2006).

Copyright (C) The Internet Society (2006).

Abstract

Abstract

   This document specifies how to establish secure connection-oriented
   media transport sessions over the Transport Layer Security (TLS)
   protocol using the Session Description Protocol (SDP).  It defines a
   new SDP protocol identifier, 'TCP/TLS'.  It also defines the syntax
   and semantics for an SDP 'fingerprint' attribute that identifies the
   certificate that will be presented for the TLS session.  This
   mechanism allows media transport over TLS connections to be
   established securely, so long as the integrity of session
   descriptions is assured.

This document specifies how to establish secure connection-oriented media transport sessions over the Transport Layer Security (TLS) protocol using the Session Description Protocol (SDP). It defines a new SDP protocol identifier, 'TCP/TLS'. It also defines the syntax and semantics for an SDP 'fingerprint' attribute that identifies the certificate that will be presented for the TLS session. This mechanism allows media transport over TLS connections to be established securely, so long as the integrity of session descriptions is assured.

   This document extends and updates RFC 4145.

This document extends and updates RFC 4145.

Lennox                      Standards Track                     [Page 1]

RFC 4572                Comedia over TLS in SDP                July 2006

Lennox Standards Track [Page 1]  RFC 4572 Comedia over TLS in SDP July 2006

Table of Contents

Table of Contents

   1. Introduction ....................................................3
   2. Terminology .....................................................4
   3. Overview ........................................................4
      3.1. SDP Operational Modes ......................................4
      3.2. Threat Model ...............................................5
      3.3. The Need for Self-Signed Certificates ......................5
      3.4. Example SDP Description for TLS Connection .................6
   4. Protocol Identifiers ............................................6
   5. Fingerprint Attribute ...........................................7
   6. Endpoint Identification .........................................9
      6.1. Certificate Choice .........................................9
      6.2. Certificate Presentation ..................................10
   7. Security Considerations ........................................10
   8. IANA Considerations ............................................12
   9. References .....................................................14
      9.1. Normative References ......................................14
      9.2. Informative References ....................................15

1. Introduction ....................................................3 2. Terminology .....................................................4 3. Overview ........................................................4 3.1. SDP Operational Modes ......................................4 3.2. Threat Model ...............................................5 3.3. The Need for Self-Signed Certificates ......................5 3.4. Example SDP Description for TLS Connection .................6 4. Protocol Identifiers ............................................6 5. Fingerprint Attribute ...........................................7 6. Endpoint Identification .........................................9 6.1. Certificate Choice .........................................9 6.2. Certificate Presentation ..................................10 7. Security Considerations ........................................10 8. IANA Considerations ............................................12 9. References .....................................................14 9.1. Normative References ......................................14 9.2. Informative References ....................................15

Lennox                      Standards Track                     [Page 2]

RFC 4572                Comedia over TLS in SDP                July 2006

Lennox Standards Track [Page 2]  RFC 4572 Comedia over TLS in SDP July 2006

1.  Introduction

1. Introduction

   The Session Description Protocol (SDP) [1] provides a general-purpose
   format for describing multimedia sessions in announcements or
   invitations.  For many applications, it is desirable to establish, as
   part of a multimedia session, a media stream that uses a connection-
   oriented transport.  RFC 4145, Connection-Oriented Media Transport in
   the Session Description Protocol (SDP) [2], specifies a general
   mechanism for describing and establishing such connection-oriented
   streams; however, the only transport protocol it directly supports is
   TCP.  In many cases, session participants wish to provide
   confidentiality, data integrity, and authentication for their media
   sessions.  This document therefore extends the Connection-Oriented
   Media specification to allow session descriptions to describe media
   sessions that use the Transport Layer Security (TLS) protocol [3].

The Session Description Protocol (SDP) [1] provides a general-purpose format for describing multimedia sessions in announcements or invitations. For many applications, it is desirable to establish, as part of a multimedia session, a media stream that uses a connection- oriented transport. RFC 4145, Connection-Oriented Media Transport in the Session Description Protocol (SDP) [2], specifies a general mechanism for describing and establishing such connection-oriented streams; however, the only transport protocol it directly supports is TCP. In many cases, session participants wish to provide confidentiality, data integrity, and authentication for their media sessions. This document therefore extends the Connection-Oriented Media specification to allow session descriptions to describe media sessions that use the Transport Layer Security (TLS) protocol [3].

   The TLS protocol allows applications to communicate over a channel
   that provides confidentiality and data integrity.  The TLS
   specification, however, does not specify how specific protocols
   establish and use this secure channel; particularly, TLS leaves the
   question of how to interpret and validate authentication certificates
   as an issue for the protocols that run over TLS.  This document
   specifies such usage for the case of connection-oriented media
   transport.

The TLS protocol allows applications to communicate over a channel that provides confidentiality and data integrity. The TLS specification, however, does not specify how specific protocols establish and use this secure channel; particularly, TLS leaves the question of how to interpret and validate authentication certificates as an issue for the protocols that run over TLS. This document specifies such usage for the case of connection-oriented media transport.

   Complicating this issue, endpoints exchanging media will often be
   unable to obtain authentication certificates signed by a well-known
   root certification authority (CA).  Most certificate authorities
   charge for signed certificates, particularly host-based certificates;
   additionally, there is a substantial administrative overhead to
   obtaining signed certificates, as certification authorities must be
   able to confirm that they are issuing the signed certificates to the
   correct party.  Furthermore, in many cases endpoints' IP addresses
   and host names are dynamic: they may be obtained from DHCP, for
   example.  It is impractical to obtain a CA-signed certificate valid
   for the duration of a DHCP lease.  For such hosts, self-signed
   certificates are usually the only option.  This specification defines
   a mechanism that allows self-signed certificates can be used
   securely, provided that the integrity of the SDP description is
   assured.  It provides for endpoints to include a secure hash of their
   certificate, known as the "certificate fingerprint", within the
   session description.  Provided that the fingerprint of the offered
   certificate matches the one in the session description, end hosts can
   trust even self-signed certificates.

Complicating this issue, endpoints exchanging media will often be unable to obtain authentication certificates signed by a well-known root certification authority (CA). Most certificate authorities charge for signed certificates, particularly host-based certificates; additionally, there is a substantial administrative overhead to obtaining signed certificates, as certification authorities must be able to confirm that they are issuing the signed certificates to the correct party. Furthermore, in many cases endpoints' IP addresses and host names are dynamic: they may be obtained from DHCP, for example. It is impractical to obtain a CA-signed certificate valid for the duration of a DHCP lease. For such hosts, self-signed certificates are usually the only option. This specification defines a mechanism that allows self-signed certificates can be used securely, provided that the integrity of the SDP description is assured. It provides for endpoints to include a secure hash of their certificate, known as the "certificate fingerprint", within the session description. Provided that the fingerprint of the offered certificate matches the one in the session description, end hosts can trust even self-signed certificates.

   The rest of this document is laid out as follows.  An overview of the
   problem and threat model is given in Section 3.  Section 4 gives the
   basic mechanism for establishing TLS-based connected-oriented media

The rest of this document is laid out as follows. An overview of the problem and threat model is given in Section 3. Section 4 gives the basic mechanism for establishing TLS-based connected-oriented media

Lennox                      Standards Track                     [Page 3]

RFC 4572                Comedia over TLS in SDP                July 2006

Lennox Standards Track [Page 3]  RFC 4572 Comedia over TLS in SDP July 2006

   in SDP.  Section 5 describes the SDP fingerprint attribute, which,
   assuming that the integrity of SDP content is assured, allows the
   secure use of self-signed certificates.  Section 6 describes which
   X.509 certificates are presented, and how they are used in TLS.
   Section 7 discusses additional security considerations.

in SDP. Section 5 describes the SDP fingerprint attribute, which, assuming that the integrity of SDP content is assured, allows the secure use of self-signed certificates. Section 6 describes which X.509 certificates are presented, and how they are used in TLS. Section 7 discusses additional security considerations.

2.  Terminology

2. Terminology

   In this document, the key words "MUST", "MUST NOT", "REQUIRED",
   "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY",
   and "OPTIONAL" are to be interpreted as described in RFC 2119 [4] and
   indicate requirement levels for compliant implementations.

In this document, the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as described in RFC 2119 [4] and indicate requirement levels for compliant implementations.

3.  Overview

3. Overview

   This section discusses the threat model that motivates TLS transport
   for connection-oriented media streams.  It also discusses in more
   detail the need for end systems to use self-signed certificates.

This section discusses the threat model that motivates TLS transport for connection-oriented media streams. It also discusses in more detail the need for end systems to use self-signed certificates.

3.1.  SDP Operational Modes

3.1. SDP Operational Modes

   There are two principal operational modes for multimedia sessions:
   advertised and offer-answer.  Advertised sessions are the simpler
   mode.  In this mode, a server publishes, in some manner, an SDP
   session description of a multimedia session it is making available.
   The classic example of this mode of operation is the Session
   Announcement Protocol (SAP) [15], in which SDP session descriptions
   are periodically transmitted to a well-known multicast group.
   Traditionally, these descriptions involve multicast conferences, but
   unicast sessions are also possible.  (Connection-oriented media,
   obviously, cannot use multicast.)  Recipients of a session
   description connect to the addresses published in the session
   description.  These recipients may not previously have been known to
   the advertiser of the session description.

There are two principal operational modes for multimedia sessions: advertised and offer-answer. Advertised sessions are the simpler mode. In this mode, a server publishes, in some manner, an SDP session description of a multimedia session it is making available. The classic example of this mode of operation is the Session Announcement Protocol (SAP) [15], in which SDP session descriptions are periodically transmitted to a well-known multicast group. Traditionally, these descriptions involve multicast conferences, but unicast sessions are also possible. (Connection-oriented media, obviously, cannot use multicast.) Recipients of a session description connect to the addresses published in the session description. These recipients may not previously have been known to the advertiser of the session description.

   Alternatively, SDP conferences can operate in offer-answer mode [5].
   This mode allows two participants in a multimedia session to
   negotiate the multimedia session between them.  In this model, one
   participant offers the other a description of the desired session
   from its perspective, and the other participant answers with the
   desired session from its own perspective.  In this mode, each of the
   participants in the session has knowledge of the other one.  This is
   the mode of operation used by the Session Initiation Protocol (SIP)
   [16].

Alternatively, SDP conferences can operate in offer-answer mode [5]. This mode allows two participants in a multimedia session to negotiate the multimedia session between them. In this model, one participant offers the other a description of the desired session from its perspective, and the other participant answers with the desired session from its own perspective. In this mode, each of the participants in the session has knowledge of the other one. This is the mode of operation used by the Session Initiation Protocol (SIP) [16].

Lennox                      Standards Track                     [Page 4]

RFC 4572                Comedia over TLS in SDP                July 2006

Lennox Standards Track [Page 4]  RFC 4572 Comedia over TLS in SDP July 2006

3.2.  Threat Model

3.2. Threat Model

   Participants in multimedia conferences often wish to guarantee
   confidentiality, data integrity, and authentication for their media
   sessions.  This section describes various types of attackers and the
   ways they attempt to violate these guarantees.  It then describes how
   the TLS protocol can be used to thwart the attackers.

Participants in multimedia conferences often wish to guarantee confidentiality, data integrity, and authentication for their media sessions. This section describes various types of attackers and the ways they attempt to violate these guarantees. It then describes how the TLS protocol can be used to thwart the attackers.

   The simplest type of attacker is one who listens passively to the
   traffic associated with a multimedia session.  This attacker might,
   for example, be on the same local-area or wireless network as one of
   the participants in a conference.  This sort of attacker does not
   threaten a connection's data integrity or authentication, and almost
   any operational mode of TLS can provide media stream confidentiality.

The simplest type of attacker is one who listens passively to the traffic associated with a multimedia session. This attacker might, for example, be on the same local-area or wireless network as one of the participants in a conference. This sort of attacker does not threaten a connection's data integrity or authentication, and almost any operational mode of TLS can provide media stream confidentiality.

   More sophisticated is an attacker who can send his own data traffic
   over the network, but who cannot modify or redirect valid traffic.
   In SDP's 'advertised' operational mode, this can barely be considered
   an attack; media sessions are expected to be initiated from anywhere
   on the network.  In SDP's offer-answer mode, however, this type of
   attack is more serious.  An attacker could initiate a connection to
   one or both of the endpoints of a session, thus impersonating an
   endpoint, or acting as a man in the middle to listen in on their
   communications.  To thwart these attacks, TLS uses endpoint
   certificates.  So long as the certificates' private keys have not
   been compromised, the endpoints have an external trusted mechanism
   (most commonly, a mutually-trusted certification authority) to
   validate certificates, and the endpoints know what certificate
   identity to expect, endpoints can be certain that such an attack has
   not taken place.

More sophisticated is an attacker who can send his own data traffic over the network, but who cannot modify or redirect valid traffic. In SDP's 'advertised' operational mode, this can barely be considered an attack; media sessions are expected to be initiated from anywhere on the network. In SDP's offer-answer mode, however, this type of attack is more serious. An attacker could initiate a connection to one or both of the endpoints of a session, thus impersonating an endpoint, or acting as a man in the middle to listen in on their communications. To thwart these attacks, TLS uses endpoint certificates. So long as the certificates' private keys have not been compromised, the endpoints have an external trusted mechanism (most commonly, a mutually-trusted certification authority) to validate certificates, and the endpoints know what certificate identity to expect, endpoints can be certain that such an attack has not taken place.

   Finally, the most serious type of attacker is one who can modify or
   redirect session descriptions: for example, a compromised or
   malicious SIP proxy server.  Neither TLS itself nor any mechanisms
   that use it can protect an SDP session against such an attacker.
   Instead, the SDP description itself must be secured through some
   mechanism; SIP, for example, defines how S/MIME [17] can be used to
   secure session descriptions.

Finally, the most serious type of attacker is one who can modify or redirect session descriptions: for example, a compromised or malicious SIP proxy server. Neither TLS itself nor any mechanisms that use it can protect an SDP session against such an attacker. Instead, the SDP description itself must be secured through some mechanism; SIP, for example, defines how S/MIME [17] can be used to secure session descriptions.

3.3.  The Need for Self-Signed Certificates

3.3. The Need for Self-Signed Certificates

   SDP session descriptions are created by any endpoint that needs to
   participate in a multimedia session.  In many cases, such as SIP
   phones, such endpoints have dynamically-configured IP addresses and
   host names and must be deployed with nearly zero configuration.  For
   such an endpoint, it is for practical purposes impossible to obtain a
   certificate signed by a well-known certification authority.

SDP session descriptions are created by any endpoint that needs to participate in a multimedia session. In many cases, such as SIP phones, such endpoints have dynamically-configured IP addresses and host names and must be deployed with nearly zero configuration. For such an endpoint, it is for practical purposes impossible to obtain a certificate signed by a well-known certification authority.

Lennox                      Standards Track                     [Page 5]

RFC 4572                Comedia over TLS in SDP                July 2006

Lennox Standards Track [Page 5]  RFC 4572 Comedia over TLS in SDP July 2006

   If two endpoints have no prior relationship, self-signed certificates
   cannot generally be trusted, as there is no guarantee that an
   attacker is not launching a man-in-the-middle attack.  Fortunately,
   however, if the integrity of SDP session descriptions can be assured,
   it is possible to consider those SDP descriptions themselves as a
   prior relationship: certificates can be securely described in the
   session description itself.  This is done by providing a secure hash
   of a certificate, or "certificate fingerprint", as an SDP attribute;
   this mechanism is described in Section 5.

If two endpoints have no prior relationship, self-signed certificates cannot generally be trusted, as there is no guarantee that an attacker is not launching a man-in-the-middle attack. Fortunately, however, if the integrity of SDP session descriptions can be assured, it is possible to consider those SDP descriptions themselves as a prior relationship: certificates can be securely described in the session description itself. This is done by providing a secure hash of a certificate, or "certificate fingerprint", as an SDP attribute; this mechanism is described in Section 5.

3.4.  Example SDP Description for TLS Connection

3.4. Example SDP Description for TLS Connection

   Figure 1 illustrates an SDP offer that signals the availability of a
   T.38 fax session over TLS.  For the purpose of brevity, the main
   portion of the session description is omitted in the example, showing
   only the 'm' line and its attributes.  (This example is the same as
   the first one in RFC 4145 [2], except for the proto parameter and the
   fingerprint attribute.)  See the subsequent sections for explanations
   of the example's TLS-specific attributes.

Figure 1 illustrates an SDP offer that signals the availability of a T.38 fax session over TLS. For the purpose of brevity, the main portion of the session description is omitted in the example, showing only the 'm' line and its attributes. (This example is the same as the first one in RFC 4145 [2], except for the proto parameter and the fingerprint attribute.) See the subsequent sections for explanations of the example's TLS-specific attributes.

   (Note: due to RFC formatting conventions, this document splits SDP
   across lines whose content would exceed 72 characters.  A backslash
   character marks where this line folding has taken place.  This
   backslash and its trailing CRLF and whitespace would not appear in
   actual SDP content.)

(Note: due to RFC formatting conventions, this document splits SDP across lines whose content would exceed 72 characters. A backslash character marks where this line folding has taken place. This backslash and its trailing CRLF and whitespace would not appear in actual SDP content.)

   m=image 54111 TCP/TLS t38
   c=IN IP4 192.0.2.2
   a=setup:passive
   a=connection:new
   a=fingerprint:SHA-1 \
          4A:AD:B9:B1:3F:82:18:3B:54:02:12:DF:3E:5D:49:6B:19:E5:7C:AB

m=image 54111 TCP/TLS t38 c=IN IP4 192.0.2.2 a=setup:passive a=connection:new a=fingerprint:SHA-1 \ 4A:AD:B9:B1:3F:82:18:3B:54:02:12:DF:3E:5D:49:6B:19:E5:7C:AB

       Figure 1: Example SDP Description Offering a TLS Media Stream

Figure 1: Example SDP Description Offering a TLS Media Stream

4.  Protocol Identifiers

4. Protocol Identifiers

   The 'm' line in SDP specifies, among other items, the transport
   protocol to be used for the media in the session.  See the "Media
   Descriptions" section of SDP [1] for a discussion on transport
   protocol identifiers.

The 'm' line in SDP specifies, among other items, the transport protocol to be used for the media in the session. See the "Media Descriptions" section of SDP [1] for a discussion on transport protocol identifiers.

   This specification defines a new protocol identifier, 'TCP/TLS',
   which indicates that the media described will use the Transport Layer
   Security protocol [3] over TCP.  (Using TLS over other transport
   protocols is not discussed in this document.)  The 'TCP/TLS' protocol
   identifier describes only the transport protocol, not the upper-layer
   protocol.  An 'm' line that specifies 'TCP/TLS' MUST further qualify

This specification defines a new protocol identifier, 'TCP/TLS', which indicates that the media described will use the Transport Layer Security protocol [3] over TCP. (Using TLS over other transport protocols is not discussed in this document.) The 'TCP/TLS' protocol identifier describes only the transport protocol, not the upper-layer protocol. An 'm' line that specifies 'TCP/TLS' MUST further qualify

Lennox                      Standards Track                     [Page 6]

RFC 4572                Comedia over TLS in SDP                July 2006

Lennox Standards Track [Page 6]  RFC 4572 Comedia over TLS in SDP July 2006

   the protocol using a fmt identifier to indicate the application being
   run over TLS.

the protocol using a fmt identifier to indicate the application being run over TLS.

   Media sessions described with this identifier follow the procedures
   defined in RFC 4145 [2].  They also use the SDP attributes defined in
   that specification, 'setup' and 'connection'.

Media sessions described with this identifier follow the procedures defined in RFC 4145 [2]. They also use the SDP attributes defined in that specification, 'setup' and 'connection'.

5.  Fingerprint Attribute

5. Fingerprint Attribute

   Parties to a TLS session indicate their identities by presenting
   authentication certificates as part of the TLS handshake procedure.
   Authentication certificates are X.509 [6] certificates, as profiled
   by RFC 3279 [7], RFC 3280 [8], and RFC 4055 [9].

Parties to a TLS session indicate their identities by presenting authentication certificates as part of the TLS handshake procedure. Authentication certificates are X.509 [6] certificates, as profiled by RFC 3279 [7], RFC 3280 [8], and RFC 4055 [9].

   In order to associate media streams with connections and to prevent
   unauthorized barge-in attacks on the media streams, endpoints MUST
   provide a certificate fingerprint.  If the X.509 certificate
   presented for the TLS connection matches the fingerprint presented in
   the SDP, the endpoint can be confident that the author of the SDP is
   indeed the initiator of the connection.

In order to associate media streams with connections and to prevent unauthorized barge-in attacks on the media streams, endpoints MUST provide a certificate fingerprint. If the X.509 certificate presented for the TLS connection matches the fingerprint presented in the SDP, the endpoint can be confident that the author of the SDP is indeed the initiator of the connection.

   A certificate fingerprint is a secure one-way hash of the DER
   (distinguished encoding rules) form of the certificate.  (Certificate
   fingerprints are widely supported by tools that manipulate X.509
   certificates; for instance, the command "openssl x509 -fingerprint"
   causes the command-line tool of the openssl package to print a
   certificate fingerprint, and the certificate managers for Mozilla and
   Internet Explorer display them when viewing the details of a
   certificate.)

A certificate fingerprint is a secure one-way hash of the DER (distinguished encoding rules) form of the certificate. (Certificate fingerprints are widely supported by tools that manipulate X.509 certificates; for instance, the command "openssl x509 -fingerprint" causes the command-line tool of the openssl package to print a certificate fingerprint, and the certificate managers for Mozilla and Internet Explorer display them when viewing the details of a certificate.)

   A fingerprint is represented in SDP as an attribute (an 'a' line).
   It consists of the name of the hash function used, followed by the
   hash value itself.  The hash value is represented as a sequence of
   uppercase hexadecimal bytes, separated by colons.  The number of
   bytes is defined by the hash function.  (This is the syntax used by
   openssl and by the browsers' certificate managers.  It is different
   from the syntax used to represent hash values in, e.g., HTTP digest
   authentication [18], which uses unseparated lowercase hexadecimal
   bytes.  It was felt that consistency with other applications of
   fingerprints was more important.)

A fingerprint is represented in SDP as an attribute (an 'a' line). It consists of the name of the hash function used, followed by the hash value itself. The hash value is represented as a sequence of uppercase hexadecimal bytes, separated by colons. The number of bytes is defined by the hash function. (This is the syntax used by openssl and by the browsers' certificate managers. It is different from the syntax used to represent hash values in, e.g., HTTP digest authentication [18], which uses unseparated lowercase hexadecimal bytes. It was felt that consistency with other applications of fingerprints was more important.)

   The formal syntax of the fingerprint attribute is given in Augmented
   Backus-Naur Form [10] in Figure 2.  This syntax extends the BNF
   syntax of SDP [1].

The formal syntax of the fingerprint attribute is given in Augmented Backus-Naur Form [10] in Figure 2. This syntax extends the BNF syntax of SDP [1].

Lennox                      Standards Track                     [Page 7]

RFC 4572                Comedia over TLS in SDP                July 2006

Lennox Standards Track [Page 7]  RFC 4572 Comedia over TLS in SDP July 2006

   attribute              =/ fingerprint-attribute

attribute =/ fingerprint-attribute

   fingerprint-attribute  =  "fingerprint" ":" hash-func SP fingerprint

fingerprint-attribute = "fingerprint" ":" hash-func SP fingerprint

   hash-func              =  "sha-1" / "sha-224" / "sha-256" /
                             "sha-384" / "sha-512" /
                             "md5" / "md2" / token
                             ; Additional hash functions can only come
                             ; from updates to RFC 3279

hash-func = "sha-1" / "sha-224" / "sha-256" / "sha-384" / "sha-512" / "md5" / "md2" / token ; Additional hash functions can only come ; from updates to RFC 3279

   fingerprint            =  2UHEX *(":" 2UHEX)
                             ; Each byte in upper-case hex, separated
                             ; by colons.

fingerprint = 2UHEX *(":" 2UHEX) ; Each byte in upper-case hex, separated ; by colons.

   UHEX                   =  DIGIT / %x41-46 ; A-F uppercase

UHEX = DIGIT / %x41-46 ; A-F uppercase

   Figure 2: Augmented Backus-Naur Syntax for the Fingerprint Attribute

Figure 2: Augmented Backus-Naur Syntax for the Fingerprint Attribute

   A certificate fingerprint MUST be computed using the same one-way
   hash function as is used in the certificate's signature algorithm.
   (This ensures that the security properties required for the
   certificate also apply for the fingerprint.  It also guarantees that
   the fingerprint will be usable by the other endpoint, so long as the
   certificate itself is.)  Following RFC 3279 [7] as updated by RFC
   4055 [9], therefore, the defined hash functions are 'SHA-1' [11]
   [19], 'SHA-224' [11], 'SHA-256' [11], 'SHA-384' [11], 'SHA-512' [11],
   'MD5' [12], and 'MD2' [13], with 'SHA-1' preferred.  A new IANA
   registry of Hash Function Textual Names, specified in Section 8,
   allows for addition of future tokens, but they may only be added if
   they are included in RFCs that update or obsolete RFC 3279 [7].
   Self-signed certificates (for which legacy certificates are not a
   consideration) MUST use one of the FIPS 180 algorithms (SHA-1,
   SHA-224, SHA-256, SHA-384, or SHA-512) as their signature algorithm,
   and thus also MUST use it to calculate certificate fingerprints.

A certificate fingerprint MUST be computed using the same one-way hash function as is used in the certificate's signature algorithm. (This ensures that the security properties required for the certificate also apply for the fingerprint. It also guarantees that the fingerprint will be usable by the other endpoint, so long as the certificate itself is.) Following RFC 3279 [7] as updated by RFC 4055 [9], therefore, the defined hash functions are 'SHA-1' [11] [19], 'SHA-224' [11], 'SHA-256' [11], 'SHA-384' [11], 'SHA-512' [11], 'MD5' [12], and 'MD2' [13], with 'SHA-1' preferred. A new IANA registry of Hash Function Textual Names, specified in Section 8, allows for addition of future tokens, but they may only be added if they are included in RFCs that update or obsolete RFC 3279 [7]. Self-signed certificates (for which legacy certificates are not a consideration) MUST use one of the FIPS 180 algorithms (SHA-1, SHA-224, SHA-256, SHA-384, or SHA-512) as their signature algorithm, and thus also MUST use it to calculate certificate fingerprints.

   The fingerprint attribute may be either a session-level or a media-
   level SDP attribute.  If it is a session-level attribute, it applies
   to all TLS sessions for which no media-level fingerprint attribute is
   defined.

The fingerprint attribute may be either a session-level or a media- level SDP attribute. If it is a session-level attribute, it applies to all TLS sessions for which no media-level fingerprint attribute is defined.

Lennox                      Standards Track                     [Page 8]

RFC 4572                Comedia over TLS in SDP                July 2006

Lennox Standards Track [Page 8]  RFC 4572 Comedia over TLS in SDP July 2006

6.  Endpoint Identification

6. Endpoint Identification

6.1.  Certificate Choice

6.1. Certificate Choice

   An X.509 certificate binds an identity and a public key.  If SDP
   describing a TLS session is transmitted over a mechanism that
   provides integrity protection, a certificate asserting any
   syntactically valid identity MAY be used.  For example, an SDP
   description sent over HTTP/TLS [20] or secured by S/MIME [17] MAY
   assert any identity in the certificate securing the media connection.

An X.509 certificate binds an identity and a public key. If SDP describing a TLS session is transmitted over a mechanism that provides integrity protection, a certificate asserting any syntactically valid identity MAY be used. For example, an SDP description sent over HTTP/TLS [20] or secured by S/MIME [17] MAY assert any identity in the certificate securing the media connection.

   Security protocols that provide only hop-by-hop integrity protection
   (e.g., the sips protocol [16], SIP over TLS) are considered
   sufficiently secure to allow the mode in which any valid identity is
   accepted.  However, see Section 7 for a discussion of some security
   implications of this fact.

Security protocols that provide only hop-by-hop integrity protection (e.g., the sips protocol [16], SIP over TLS) are considered sufficiently secure to allow the mode in which any valid identity is accepted. However, see Section 7 for a discussion of some security implications of this fact.

   In situations where the SDP is not integrity-protected, however, the
   certificate provided for a TLS connection MUST certify an appropriate
   identity for the connection.  In these scenarios, the certificate
   presented by an endpoint MUST certify either the SDP connection
   address, or the identity of the creator of the SDP message, as
   follows:

In situations where the SDP is not integrity-protected, however, the certificate provided for a TLS connection MUST certify an appropriate identity for the connection. In these scenarios, the certificate presented by an endpoint MUST certify either the SDP connection address, or the identity of the creator of the SDP message, as follows:

   o  If the connection address for the media description is specified
      as an IP address, the endpoint MAY use a certificate with an
      iPAddress subjectAltName that exactly matches the IP in the
      connection-address in the session description's 'c' line.
      Similarly, if the connection address for the media description is
      specified as a fully-qualified domain name, the endpoint MAY use a
      certificate with a dNSName subjectAltName matching the specified
      'c' line connection-address exactly.  (Wildcard patterns MUST NOT
      be used.)

o If the connection address for the media description is specified as an IP address, the endpoint MAY use a certificate with an iPAddress subjectAltName that exactly matches the IP in the connection-address in the session description's 'c' line. Similarly, if the connection address for the media description is specified as a fully-qualified domain name, the endpoint MAY use a certificate with a dNSName subjectAltName matching the specified 'c' line connection-address exactly. (Wildcard patterns MUST NOT be used.)

   o  Alternately, if the SDP session description of the session was
      transmitted over a protocol (such as SIP [16]) for which the
      identities of session participants are defined by uniform resource
      identifiers (URIs), the endpoint MAY use a certificate with a
      uniformResourceIdentifier subjectAltName corresponding to the
      identity of the endpoint that generated the SDP.  The details of
      what URIs are valid are dependent on the transmitting protocol.
      (For more details on the validity of URIs, see Section 7.)

o Alternately, if the SDP session description of the session was transmitted over a protocol (such as SIP [16]) for which the identities of session participants are defined by uniform resource identifiers (URIs), the endpoint MAY use a certificate with a uniformResourceIdentifier subjectAltName corresponding to the identity of the endpoint that generated the SDP. The details of what URIs are valid are dependent on the transmitting protocol. (For more details on the validity of URIs, see Section 7.)

   Identity matching is performed using the matching rules specified by
   RFC 3280 [8].  If more than one identity of a given type is present
   in the certificate (e.g., more than one dNSName name), a match in any
   one of the set is considered acceptable.  To support the use of
   certificate caches, as described in Section 7, endpoints SHOULD

Identity matching is performed using the matching rules specified by RFC 3280 [8]. If more than one identity of a given type is present in the certificate (e.g., more than one dNSName name), a match in any one of the set is considered acceptable. To support the use of certificate caches, as described in Section 7, endpoints SHOULD

Lennox                      Standards Track                     [Page 9]

RFC 4572                Comedia over TLS in SDP                July 2006

Lennox Standards Track [Page 9]  RFC 4572 Comedia over TLS in SDP July 2006

   consistently provide the same certificate for each identity they
   support.

consistently provide the same certificate for each identity they support.

6.2.  Certificate Presentation

6.2. Certificate Presentation

   In all cases, an endpoint acting as the TLS server (i.e., one taking
   the 'setup:passive' role, in the terminology of connection-oriented
   media) MUST present a certificate during TLS initiation, following
   the rules presented in Section 6.1.  If the certificate does not
   match the original fingerprint, the client endpoint MUST terminate
   the media connection with a bad_certificate error.

In all cases, an endpoint acting as the TLS server (i.e., one taking the 'setup:passive' role, in the terminology of connection-oriented media) MUST present a certificate during TLS initiation, following the rules presented in Section 6.1. If the certificate does not match the original fingerprint, the client endpoint MUST terminate the media connection with a bad_certificate error.

   If the SDP offer/answer model [5] is being used, the client (the
   endpoint with the 'setup:active' role) MUST also present a
   certificate following the rules of Section 6.1.  The server MUST
   request a certificate, and if the client does not provide one, or if
   the certificate does not match the provided fingerprint, the server
   endpoint MUST terminate the media connection with a bad_certificate
   error.

If the SDP offer/answer model [5] is being used, the client (the endpoint with the 'setup:active' role) MUST also present a certificate following the rules of Section 6.1. The server MUST request a certificate, and if the client does not provide one, or if the certificate does not match the provided fingerprint, the server endpoint MUST terminate the media connection with a bad_certificate error.

   Note that when the offer/answer model is being used, it is possible
   for a media connection to outrace the answer back to the offerer.
   Thus, if the offerer has offered a 'setup:passive' or 'setup:actpass'
   role, it MUST (as specified in RFC 4145 [2]) begin listening for an
   incoming connection as soon as it sends its offer.  However, it MUST
   NOT assume that the data transmitted over the TLS connection is valid
   until it has received a matching fingerprint in an SDP answer.  If
   the fingerprint, once it arrives, does not match the client's
   certificate, the server endpoint MUST terminate the media connection
   with a bad_certificate error, as stated in the previous paragraph.

Note that when the offer/answer model is being used, it is possible for a media connection to outrace the answer back to the offerer. Thus, if the offerer has offered a 'setup:passive' or 'setup:actpass' role, it MUST (as specified in RFC 4145 [2]) begin listening for an incoming connection as soon as it sends its offer. However, it MUST NOT assume that the data transmitted over the TLS connection is valid until it has received a matching fingerprint in an SDP answer. If the fingerprint, once it arrives, does not match the client's certificate, the server endpoint MUST terminate the media connection with a bad_certificate error, as stated in the previous paragraph.

   If offer/answer is not being used (e.g., if the SDP was sent over the
   Session Announcement Protocol [15]), there is no secure channel
   available for clients to communicate certificate fingerprints to
   servers.  In this case, servers MAY request client certificates,
   which SHOULD be signed by a well-known certification authority, or
   MAY allow clients to connect without a certificate.

If offer/answer is not being used (e.g., if the SDP was sent over the Session Announcement Protocol [15]), there is no secure channel available for clients to communicate certificate fingerprints to servers. In this case, servers MAY request client certificates, which SHOULD be signed by a well-known certification authority, or MAY allow clients to connect without a certificate.

7.  Security Considerations

7. Security Considerations

   This entire document concerns itself with security.  The problem to
   be solved is addressed in Section 1, and a high-level overview is
   presented in Section 3.  See the SDP specification [1] for security
   considerations applicable to SDP in general.

This entire document concerns itself with security. The problem to be solved is addressed in Section 1, and a high-level overview is presented in Section 3. See the SDP specification [1] for security considerations applicable to SDP in general.

   Offering a TCP/TLS connection in SDP (or agreeing to one in SDP
   offer/answer mode) does not create an obligation for an endpoint to
   accept any TLS connection with the given fingerprint.  Instead, the

Offering a TCP/TLS connection in SDP (or agreeing to one in SDP offer/answer mode) does not create an obligation for an endpoint to accept any TLS connection with the given fingerprint. Instead, the

Lennox                      Standards Track                    [Page 10]

RFC 4572                Comedia over TLS in SDP                July 2006

Lennox Standards Track [Page 10]  RFC 4572 Comedia over TLS in SDP July 2006

   endpoint must engage in the standard TLS negotiation procedure to
   ensure that the TLS stream cipher and MAC algorithm chosen meet the
   security needs of the higher-level application.  (For example, an
   offered stream cipher of TLS_NULL_WITH_NULL_NULL SHOULD be rejected
   in almost every application scenario.)

endpoint must engage in the standard TLS negotiation procedure to ensure that the TLS stream cipher and MAC algorithm chosen meet the security needs of the higher-level application. (For example, an offered stream cipher of TLS_NULL_WITH_NULL_NULL SHOULD be rejected in almost every application scenario.)

   Like all SDP messages, SDP messages describing TLS streams are
   conveyed in an encapsulating application protocol (e.g., SIP, Media
   Gateway Control Protocol (MGCP), etc.).  It is the responsibility of
   the encapsulating protocol to ensure the integrity of the SDP
   security descriptions.  Therefore, the application protocol SHOULD
   either invoke its own security mechanisms (e.g., secure multiparts)
   or, alternatively, utilize a lower-layer security service (e.g., TLS
   or IPsec).  This security service SHOULD provide strong message
   authentication as well as effective replay protection.

すべてのSDPメッセージのように、TLSストリームについて説明するSDPメッセージが要約アプリケーション・プロトコル(例えば、SIP、メディアゲートウェイControlプロトコル(MGCP)など)で伝えられます。 それは要約プロトコルがSDPセキュリティ記述の保全を確実にする責任です。 したがって、アプリケーション・プロトコルSHOULDはそれ自身のセキュリティー対策(例えば、安全な「マルチ-部品」)を呼び出すか、またはあるいはまた、下層セキュリティー・サービス(例えば、TLSかIPsec)を利用します。 このセキュリティー・サービスSHOULDは有効な反復操作による保護と同様に強い通報認証を提供します。

   However, such integrity protection is not always possible.  For these
   cases, end systems SHOULD maintain a cache of certificates that other
   parties have previously presented using this mechanism.  If possible,
   users SHOULD be notified when an unsecured certificate associated
   with a previously unknown end system is presented and SHOULD be
   strongly warned if a different unsecured certificate is presented by
   a party with which they have communicated in the past.  In this way,
   even in the absence of integrity protection for SDP, the security of
   this document's mechanism is equivalent to that of the Secure Shell
   (ssh) protocol [21], which is vulnerable to man-in-the-middle attacks
   when two parties first communicate, but can detect ones that occur
   subsequently.  (Note that a precise definition of the "other party"
   depends on the application protocol carrying the SDP message.)  Users
   SHOULD NOT, however, in any circumstances be notified about
   certificates described in SDP descriptions sent over an integrity-
   protected channel.

しかしながら、そのような保全保護はいつも可能であるというわけではありません。 これらのケースのために、終わりのシステムSHOULDは、このメカニズムを使用することで相手が以前に提示した証明書のキャッシュを維持します。 可能なユーザSHOULDであるなら、以前に未知のエンドシステムに関連している非機密保護している証明書が提示されて、SHOULDが強く通知されるときには、警告されて、異なった非機密保護している証明書が過去に彼らと交信したパーティーによって提示されるなら、通知されてください。 このように、このドキュメントのメカニズムのセキュリティは、SDPのための保全保護がないときでさえ2回のパーティーが最初に交信するとき介入者攻撃に被害を受け易いSecureシェル(セキュアシェル (SSH))プロトコル[21]のものに同等ですが、次に起こるものを検出できます。 (「相手」の厳密な定義がSDPメッセージを伝えるアプリケーション・プロトコルによることに注意してください。) ユーザSHOULD NOT、しかしながら、保全の保護されたチャンネルの上に送られたSDP記述で説明された証明書に関してどんなことがあっても通知されてください。

   To aid interoperability and deployment, security protocols that
   provide only hop-by-hop integrity protection (e.g., the sips protocol
   [16], SIP over TLS) are considered sufficiently secure to allow the
   mode in which any syntactically valid identity is accepted in a
   certificate.  This decision was made because sips is currently the
   integrity mechanism most likely to be used in deployed networks in
   the short to medium term.  However, in this mode, SDP integrity is
   vulnerable to attacks by compromised or malicious middleboxes, e.g.,
   SIP proxy servers.  End systems MAY warn users about SDP sessions
   that are secured in only a hop-by-hop manner, and definitions of
   media formats running over TCP/TLS MAY specify that only end-to-end
   integrity mechanisms be used.

相互運用性と展開を支援するために、ホップだけごとに保全保護(例えば、一口は[16]について議定書の中で述べます、TLSの上のSIP)を提供するセキュリティプロトコルはどんなシンタクス上有効なアイデンティティも証明書で受け入れられるモードを許容できるくらい安全であると考えられます。 現在一口が中期に不足するところの配布しているネットワークに最も使用されそうな保全メカニズムであるので、この決定をしました。 しかしながら、このモードで、SDP保全は感染しているか悪意があるmiddleboxes、例えば、SIPプロキシサーバで攻撃に被害を受け易いです。 エンドシステムは、TCP/TLS MAYが、終わりから終わりへの保全メカニズムだけが使用されると指定するとホップごとの方法、およびあふれるメディア形式の定義だけで保証されるSDPおよそセッションユーザに警告するかもしれません。

Lennox                      Standards Track                    [Page 11]

RFC 4572                Comedia over TLS in SDP                July 2006

レノックス規格は2006年7月にSDPのTLSの上でRFC4572Comediaを追跡します[11ページ]。

   Depending on how SDP messages are transmitted, it is not always
   possible to determine whether or not a subjectAltName presented in a
   remote certificate is expected for the remote party.  In particular,
   given call forwarding, third-party call control, or session
   descriptions generated by endpoints controlled by the Gateway Control
   Protocol [22], it is not always possible in SIP to determine what
   entity ought to have generated a remote SDP response.  In general,
   when not using authenticity and integrity protection of SDP
   descriptions, a certificate transmitted over SIP SHOULD assert the
   endpoint's SIP Address of Record as a uniformResourceIndicator
   subjectAltName.  When an endpoint receives a certificate over SIP
   asserting an identity (including an iPAddress or dNSName identity)
   other than the one to which it placed or received the call, it SHOULD
   alert the user and ask for confirmation.  This applies whether
   certificates are self-signed, or signed by certification authorities;
   a certificate for sip:bob@example.com may be legitimately signed by a
   certification authority, but may still not be acceptable for a call
   to sip:alice@example.com.  (This issue is not one specific to this
   specification; the same consideration applies for S/MIME-signed SDP
   carried over SIP.)

SDPメッセージがどう送られるかによって、リモート証明書に示されたsubjectAltNameがリモートパーティーのために予想されるかどうか決定するのはいつも可能であるというわけではありません。 ゲートウェイControlプロトコル[22]によって制御された終点によって生成された自動転送、第三者呼び出しコントロール、またはセッション記述を考えて、どんな実体がリモートSDP応答を生成したはずであるかを決定するのはSIPでいつも特に、可能であるというわけではありません。 信憑性と保全保護を使用しないとき、SDP記述、SIP SHOULDの上に伝えられた証明書では一般に、uniformResourceIndicator subjectAltNameとして終点のRecordのSIP Addressについて断言してください。 終点はそれが電話をしたか、または受けたものを除いて、アイデンティティが(iPAddressを含んでいるか、dNSNameのアイデンティティ)であると断言するSIPの上に証明書を受け取ります、それ。いつ、SHOULDはユーザを警告して、確認を求めるか。 証明書が証明当局によって自己に署名されるか、または署名されることにかかわらずこれは適用されます。 一口のための証明書: bob@example.com は証明権威によって合法的に署名されるかもしれませんが、ちびちび飲むという要求において、まだ許容できていないかもしれません: alice@example.com 。 (この問題はこの仕様に特定の1つではありません; 同じ考慮はSIPの上まで運ばれたMIMEでS/署名しているSDPに申し込みます。)

   This document does not define any mechanism for securely transporting
   RTP and RTP Control Protocol (RTCP) packets over a
   connection-oriented channel.  There was no consensus in the working
   group as to whether it would be better to send Secure RTP packets
   [23] over a connection-oriented transport [24], or whether it would
   be better to send standard unsecured RTP packets over TLS using the
   mechanisms described in this document.  The group consensus was to
   wait until a use-case requiring secure connection-oriented RTP was
   presented.

このドキュメントは、接続指向のチャンネルの上にしっかりとRTPとRTP Controlプロトコル(RTCP)パケットを輸送するためにどんなメカニズムも定義しません。 本書では説明されたメカニズムを使用することで標準のunsecured RTPパケットをTLSの上に送る接続指向の輸送[24]の上でパケット[23]をSecure RTPに送るほうがよいだろうかどうか、またはそれが、より良いだろうかどうかに関するワーキンググループにおけるコンセンサスが全くありませんでした。 グループコンセンサスはケースを使用している必要さ安全な接続指向のRTPを寄贈するまで待つことでした。

   TLS is not always the most appropriate choice for secure connection-
   oriented media; in some cases, a higher- or lower-level security
   protocol may be appropriate.

TLSは安全な接続指向のメディアのためのいつも最も適切な選択ではありません。 いくつかの場合、より高いか低レベルセキュリティプロトコルは適切であるかもしれません。

8.  IANA Considerations

8. IANA問題

   This document defines an SDP proto value: 'TCP/TLS'.  Its format is
   defined in Section 4.  This proto value has been registered by IANA
   under "Session Description Protocol (SDP) Parameters" under "proto".

このドキュメントはSDP proto値を定義します: 'TCP/TLS'。 書式はセクション4で定義されます。 このproto値は"proto"の下の「セッション記述プロトコル(SDP)パラメタ」の下でIANAによって示されました。

   This document defines an SDP session and media-level attribute:
   'fingerprint'.  Its format is defined in Section 5.  This attribute
   has been registered by IANA under "Session Description Protocol (SDP)
   Parameters" under "att-field (both session and media level)".

このドキュメントはSDPセッションとメディアレベル属性を定義します: '指紋を採取します'。 書式はセクション5で定義されます。 この属性は「att-分野(セッションとメディアレベルの両方)」の下における「セッション記述プロトコル(SDP)パラメタ」の下でIANAによって示されました。

   The SDP specification [1] states that specifications defining new
   proto values, like the 'TCP/TLS' proto value defined in this one,

仕様が新しいprotoを定義して、'TCP/TLS'のようにこれで定義されたproto値を評価する仕様[1]が述べるSDP

Lennox                      Standards Track                    [Page 12]

RFC 4572                Comedia over TLS in SDP                July 2006

レノックス規格は2006年7月にSDPのTLSの上でRFC4572Comediaを追跡します[12ページ]。

   must define the rules by which their media format (fmt) namespace is
   managed.  For the TCP/TLS protocol, new formats SHOULD have an
   associated MIME registration.  Use of an existing MIME subtype for
   the format is encouraged.  If no MIME subtype exists, it is
   RECOMMENDED that a suitable one be registered through the IETF
   process [14] by production of, or reference to, a standards-track RFC
   that defines the transport protocol for the format.

それらのメディア形式(fmt)名前空間が管理される規則を定義しなければなりません。 TCP/TLSプロトコルのために、新しい形式SHOULDには、関連MIME登録があります。 既存のMIME「副-タイプ」の形式の使用は奨励されます。 MIMEがない「副-タイプ」が存在しているなら、適当なものがIETFプロセス[14]を通して生産で示されるのが、RECOMMENDEDである、参照、形式のためにトランスポート・プロトコルを定義する標準化過程RFC。

   This specification creates a new IANA registry named "Hash Function
   Textual Names".  It will not be part of the SDP Parameters.

この仕様は「ハッシュ関数の原文の名」という新しいIANA登録を作成します。 それはSDP Parametersの一部でなくなるでしょう。

   The names of hash functions used for certificate fingerprints are
   registered by the IANA.  Hash functions MUST be defined by standards-
   track RFCs that update or obsolete RFC 3279 [7].

証明書指紋に使用されるハッシュ関数の名前はIANAによって登録されます。 規格道のRFCsそのアップデートか時代遅れのRFC3279[7]はハッシュ関数を定義しなければなりません。

   When registering a new hash function textual name, the following
   information MUST be provided:

新しいハッシュ関数原文の名を登録するとき、以下の情報を提供しなければなりません:

   o  The textual name of the hash function.

o ハッシュ関数の原文の名前。

   o  The Object Identifier (OID) of the hash function as used in X.509
      certificates.

o X.509証明書で同じくらい中古のハッシュ関数のObject Identifier(OID)。

   o  A reference to the standards-track RFC, updating or obsoleting RFC
      3279 [7], defining the use of the hash function in X.509
      certificates.

o X.509証明書におけるハッシュ関数の使用を定義して、RFC3279[7]をアップデートするか、または時代遅れにする標準化過程RFCの参照。

   Figure 3 contains the initial values of this registry.

図3はこの登録の初期の値を含んでいます。

   Hash Function Name     OID                         Reference
   ------------------     ---                         ---------
   "md2"                  1.2.840.113549.2.2          RFC 3279
   "md5"                  1.2.840.113549.2.5          RFC 3279
   "sha-1"                1.3.14.3.2.26               RFC 3279
   "sha-224"              2.16.840.1.101.3.4.2.4      RFC 4055
   "sha-256"              2.16.840.1.101.3.4.2.1      RFC 4055
   "sha-384"              2.16.840.1.101.3.4.2.2      RFC 4055
   "sha-512"              2.16.840.1.101.3.4.2.3      RFC 4055

ハッシュ関数名前OID参照------------------ --- --------- 「md2"1.2.840.113549.2.2RFC3279、「md5"1.2.840.113549.2.5RFC3279「sha-1インチの1.3.14.3.2.26RFC3279"sha-224"2.16.840.1.101.3.4.2.4RFC4055"sha-256"2.16.840.1.101.3.4.2.1RFC4055"sha-384"2.16.840.1.101.3.4.2.2RFC4055"sha-512"2.16.840.1.101.3.4.2.3RFC4055」

            Figure 3: IANA Hash Function Textual Name Registry

図3: IANAのハッシュ関数の原文の名前登録

Lennox                      Standards Track                    [Page 13]

RFC 4572                Comedia over TLS in SDP                July 2006

レノックス規格は2006年7月にSDPのTLSの上でRFC4572Comediaを追跡します[13ページ]。

9.  References

9. 参照

9.1.  Normative References

9.1. 引用規格

   [1]   Handley, M., Jacobson, V., and C. Perkins, "SDP: Session
         Description Protocol", RFC 4566, July 2006.

[1] ハンドレー、M.、ジェーコブソン、V.、およびC.パーキンス、「SDP:」 「セッション記述プロトコル」、RFC4566、2006年7月。

   [2]   Yon, D. and G. Camarillo, "TCP-Based Media Transport in the
         Session Description Protocol (SDP)", RFC 4145, September 2005.

[2] あそこのものとD.とG.キャマリロ、「セッション記述プロトコル(SDP)におけるTCPベースのメディア輸送」、RFC4145、2005年9月。

   [3]   Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS)
         Protocol Version 1.1", RFC 4346, April 2006.

[3] Dierks、T.、およびE.レスコラ、「トランスポート層セキュリティ(TLS)は2006年4月にバージョン1.1インチ、RFC4346について議定書の中で述べます」。

   [4]   Bradner, S., "Key words for use in RFCs to Indicate Requirement
         Levels", BCP 14, RFC 2119, March 1997.

[4] ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、1997年3月。

   [5]   Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with
         Session Description Protocol (SDP)", RFC 3264, June 2002.

[5] ローゼンバーグとJ.とH.Schulzrinne、「セッション記述プロトコル(SDP)がある申し出/答えモデル」、RFC3264、2002年6月。

   [6]   International Telecommunications Union, "Information technology
         - Open Systems Interconnection - The Directory: Public-key and
         attribute certificate frameworks", ITU-T Recommendation X.509,
         ISO Standard 9594-8, March 2000.

[6] 国際Telecommunications Union、「情報技術--オープン・システム・インターコネクション--ディレクトリ:、」 「公開鍵と属性証明書フレームワーク」、ITU-T Recommendation X.509、ISO Standard9594-8、2000年3月。

   [7]   Bassham, L., Polk, W., and R. Housley, "Algorithms and
         Identifiers for the Internet X.509 Public Key Infrastructure
         Certificate and Certificate Revocation List (CRL) Profile",
         RFC 3279, April 2002.

[7] Bassham、L.、ポーク、W.、およびR.Housley、「インターネットX.509公開鍵暗号基盤証明書と証明書取消しのためのアルゴリズムと識別子は(CRL)プロフィールをリストアップします」、RFC3279、2002年4月。

   [8]   Housley, R., Polk, W., Ford, W., and D. Solo, "Internet X.509
         Public Key Infrastructure Certificate and Certificate
         Revocation List (CRL) Profile", RFC 3280, April 2002.

[8]Housley、R.、ポーク、W.、フォード、W.、および一人で生活して、「インターネットX.509公開鍵暗号基盤証明書と証明書失効リスト(CRL)は輪郭を描く」D.、RFC3280(2002年4月)。

   [9]   Schaad, J., Kaliski, B., and R. Housley, "Additional Algorithms
         and Identifiers for RSA Cryptography for use in the Internet
         X.509 Public Key Infrastructure Certificate and Certificate
         Revocation List (CRL) Profile", RFC 4055, June 2005.

[9]Schaad、J.、Kaliski、B.、R.Housley、および「中のインターネットX.509公開鍵暗号基盤CertificateとCertificate Revocation List(CRL)が輪郭を描く使用のためのRSA Cryptographyのための追加AlgorithmsとIdentifiers」、RFC4055(2005年6月)

   [10]  Crocker, D. and P. Overell, "Augmented BNF for Syntax
         Specifications: ABNF", RFC 4234, October 2005.

[10] クロッカー、D.、およびP.Overell、「構文仕様のための増大しているBNF:」 "ABNF"、2005年10月のRFC4234。

   [11]  National Institute of Standards and Technology, "Secure Hash
         Standard", FIPS PUB 180-2, August 2002, <http://csrc.nist.gov/
         publications/fips/fips180-2/fips180-2.pdf>.

[11]米国商務省標準技術局、「安全なハッシュ規格」、FIPS PUB180-2、2002年8月、<http://csrc.nist.gov/刊行物/fips/fips180-2/fips180-2.pdf>。

   [12]  Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321,
         April 1992.

[12] 1992年4月、最もRivestなR.、「MD5メッセージダイジェストアルゴリズム」RFC1321。

Lennox                      Standards Track                    [Page 14]

RFC 4572                Comedia over TLS in SDP                July 2006

レノックス規格は2006年7月にSDPのTLSの上でRFC4572Comediaを追跡します[14ページ]。

   [13]  Kaliski, B., "The MD2 Message-Digest Algorithm", RFC 1319,
         April 1992.

[13]Kaliski、B.、「MD2メッセージダイジェストアルゴリズム」、RFC1319、1992年4月。

   [14]  Freed, N. and J. Klensin, "Media Type Specifications and
         Registration Procedures", BCP 13, RFC 4288, December 2005.

解放された[14]とN.とJ.Klensin、「メディアは仕様と登録手順をタイプする」BCP13、RFC4288、2005年12月。

9.2.  Informative References

9.2. 有益な参照

   [15]  Handley, M., Perkins, C., and E. Whelan, "Session Announcement
         Protocol", RFC 2974, October 2000.

[15] ハンドレーとM.とパーキンス、C.とE.ウィーラン、「セッション発表プロトコル」、RFC2974、2000年10月。

   [16]  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.

[16] ローゼンバーグ、J.、Schulzrinne、H.、キャマリロ、G.、ジョンストン、A.、ピーターソン、J.、スパークス、R.、ハンドレー、M.、およびE.学生は「以下をちびちび飲みます」。 「セッション開始プロトコル」、RFC3261、2002年6月。

   [17]  Ramsdell, B., "Secure/Multipurpose Internet Mail Extensions
         (S/MIME) Version 3.1 Message Specification", RFC 3851, July
         2004.

Ramsdell(B.)が「/マルチパーパスインターネットメールエクステンション(S/MIME)バージョン3.1メッセージ仕様であると機密保護する」[17]、RFC3851、2004年7月。

   [18]  Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S.,
         Leach, P., Luotonen, A., and L. Stewart, "HTTP Authentication:
         Basic and Digest Access Authentication", RFC 2617, June 1999.

[18] フランクス、J.、ハラム-ベイカー、P.、Hostetler、J.、ローレンス、S.、リーチ、P.、Luotonen、A.、およびL.スチュワート、「HTTP認証:」 「基本的、そして、ダイジェストアクセス認証」、RFC2617、1999年6月。

   [19]  Eastlake, D. and P. Jones, "US Secure Hash Algorithm 1 (SHA1)",
         RFC 3174, September 2001.

[19] イーストレークとD.とP.ジョーンズ、「米国安全なハッシュアルゴリズム1(SHA1)」、RFC3174 2001年9月。

   [20]  Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000.

[20] レスコラ(E.、「TLSの上のHTTP」、RFC2818)は2000がそうするかもしれません。

   [21]  Ylonen, T. and C. Lonvick, "The Secure Shell (SSH) Protocol
         Architecture", RFC 4251, January 2006.

[21]YlonenとT.とC.Lonvick、「セキュア・シェル(セキュアシェル (SSH))プロトコルアーキテクチャ」、RFC4251、2006年1月。

   [22]  Groves, C., Pantaleo, M., Anderson, T., and T. Taylor, "Gateway
         Control Protocol Version 1", RFC 3525, June 2003.

[22] 木立とC.とPantaleoとM.とアンダーソン、T.とT.テイラー、「ゲートウェイ制御プロトコルバージョン1インチ、RFC3525、2003年6月。」

   [23]  Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K.
         Norrman, "The Secure Real-time Transport Protocol (SRTP)",
         RFC 3711, March 2004.

2004年の[23]Baugher、M.、マグリュー、D.、ジーター、M.、カラーラ、E.、およびK.Norrman、「安全なリアルタイムのトランスポート・プロトコル(SRTP)」、RFC3711行進。

   [24]  Lazzaro, J., "Framing Real-time Transport Protocol (RTP) and
         RTP Control Protocol (RTCP) Packets over Connection-Oriented
         Transport", RFC 4571, July 2006.

[24] Lazzaro、J.、「縁どりのリアルタイムのトランスポート・プロトコル(RTP)とRTPコントロールは接続指向の輸送の上で(RTCP)パケットについて議定書の中で述べます」、RFC4571、2006年7月。

Lennox                      Standards Track                    [Page 15]

RFC 4572                Comedia over TLS in SDP                July 2006

レノックス規格は2006年7月にSDPのTLSの上でRFC4572Comediaを追跡します[15ページ]。

Author's Address

作者のアドレス

   Jonathan Lennox
   Columbia University Department of Computer Science
   450 Computer Science
   1214 Amsterdam Ave., M.C. 0401
   New York, NY  10027
   US

ジョナサンレノックスコロンビア大学コンピュータサイエンス学部450コンピュータサイエンス1214アムステルダムAve、M.C.0401ニューヨーク10027ニューヨーク(米国)

   EMail: lennox@cs.columbia.edu

メール: lennox@cs.columbia.edu

Lennox                      Standards Track                    [Page 16]

RFC 4572                Comedia over TLS in SDP                July 2006

レノックス規格は2006年7月にSDPのTLSの上でRFC4572Comediaを追跡します[16ページ]。

Full Copyright Statement

完全な著作権宣言文

   Copyright (C) The Internet Society (2006).

Copyright(C)インターネット協会(2006)。

   This document is subject to the rights, licenses and restrictions
   contained in BCP 78, and except as set forth therein, the authors
   retain all their rights.

このドキュメントはBCP78に含まれた権利、ライセンス、および制限を受けることがあります、そして、そこに詳しく説明されるのを除いて、作者は彼らのすべての権利を保有します。

   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
   ENGINEERING TASK FORCE DISCLAIM 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.

このドキュメントと「そのままで」という基礎と貢献者、その人が代表する組織で提供するか、または後援されて、インターネット協会とインターネット・エンジニアリング・タスク・フォースはすべての保証を放棄します、と急行ORが含意したということであり、他を含んでいて、ここに含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。

Intellectual Property

知的所有権

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

IETFはどんなIntellectual Property Rightsの正当性か範囲、実装に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 または、それはそれを表しません。どんなそのような権利も特定するどんな独立している取り組みも作りました。 BCP78とBCP79でRFCドキュメントの権利に関する手順に関する情報を見つけることができます。

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at
   http://www.ietf.org/ipr.

IPR公開のコピーが利用可能に作られるべきライセンスの保証、または一般的な免許を取得するのが作られた試みの結果をIETF事務局といずれにもしたか、または http://www.ietf.org/ipr のIETFのオンラインIPR倉庫からこの仕様のimplementersかユーザによるそのような所有権の使用のために許可を得ることができます。

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at
   ietf-ipr@ietf.org.

IETFはこの規格を実装するのに必要であるかもしれない技術をカバーするかもしれないどんな著作権もその注目していただくどんな利害関係者、特許、特許出願、または他の所有権も招待します。 ietf-ipr@ietf.org のIETFに情報を扱ってください。

Acknowledgement

承認

   Funding for the RFC Editor function is provided by the IETF
   Administrative Support Activity (IASA).

RFC Editor機能のための基金はIETF Administrative Support Activity(IASA)によって提供されます。

Lennox                      Standards Track                    [Page 17]

レノックス標準化過程[17ページ]