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.)
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.
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.
8. IANA Considerations
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".
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)".
The SDP specification [1] states that specifications defining new
proto values, like the ’TCP/TLS’ proto value defined in this one,
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.
This specification creates a new IANA registry named "Hash Function
Textual Names". It will not be part of the 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].
When registering a new hash function textual name, the following
information MUST be provided:
o The textual name of the hash function.
o The Object Identifier (OID) of the hash function as used in X.509
certificates.
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.
Figure 3 contains the initial values of this registry.
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
Figure 3: IANA Hash Function Textual Name Registry
9. References
9.1. Normative References
[1] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session
Description Protocol", RFC 4566, July 2006.
[2] Yon, D. and G. Camarillo, "TCP-Based Media Transport in the
Session Description Protocol (SDP)", RFC 4145, September 2005.
[3] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS)
Protocol Version 1.1", RFC 4346, April 2006.
[4] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[5] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with
Session Description Protocol (SDP)", RFC 3264, June 2002.
[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.
[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.
[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.
[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.
[10] Crocker, D. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", RFC 4234, October 2005.
[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>.
[12] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321,
April 1992.
[13] Kaliski, B., "The MD2 Message-Digest Algorithm", RFC 1319,
April 1992.
[14] Freed, N. and J. Klensin, "Media Type Specifications and
Registration Procedures", BCP 13, RFC 4288, December 2005.
9.2. Informative References
[15] Handley, M., Perkins, C., and E. Whelan, "Session Announcement
Protocol", RFC 2974, October 2000.
[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.
[17] Ramsdell, B., "Secure/Multipurpose Internet Mail Extensions
(S/MIME) Version 3.1 Message Specification", RFC 3851, July
2004.
[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.
[19] Eastlake, D. and P. Jones, "US Secure Hash Algorithm 1 (SHA1)",
RFC 3174, September 2001.
[20] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000.
[21] Ylonen, T. and C. Lonvick, "The Secure Shell (SSH) Protocol
Architecture", RFC 4251, January 2006.
[22] Groves, C., Pantaleo, M., Anderson, T., and T. Taylor, "Gateway
Control Protocol Version 1", RFC 3525, June 2003.
[23] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K.
Norrman, "The Secure Real-time Transport Protocol (SRTP)",
RFC 3711, March 2004.
[24] Lazzaro, J., "Framing Real-time Transport Protocol (RTP) and
RTP Control Protocol (RTCP) Packets over Connection-Oriented
Transport", RFC 4571, July 2006.
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
EMail: lennox@cs.columbia.edu
Full Copyright Statement
Copyright (C) The Internet Society (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.
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.
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.
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.
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.
Acknowledgement
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).