the media streams will still be secure even if some attackers gained
knowledge of the SDP contents. Further security considerations can
be found for each key management protocol (for MIKEY these can be
found in [MIKEY]). However, if the SDP messages are not sent
integrity protected between the parties, it is possible for an active
attacker to change attributes without being detected. As the key
management protocol may (indirectly) rely on some of the session
information from SDP (e.g., address information), an attack on SDP
may have indirect consequences on the key management. Even if the
key management protocol does not rely on parameters of SDP and will
not be affected by manipulation of these, different denial-of-service
(DoS) attacks aimed at SDP may lead to undesired interruption in the
setup. See also the attacks described at the end of this section.
The only integrity-protected attribute of the media stream is, in the
framework proposed here, the set of key management protocols. For
instance, it is possible to (1) swap key management offers across SDP
messages, or (2) inject a previous key management offer into a new
SDP message. Making the (necessary) assumption that all involved key
management protocols are secure, the second attack will be detected
by replay protection mechanisms of the key management protocol(s).
Making the further assumption that, according to normal best current
practice, the production of each key management offer is done with
independent (pseudo)random choices (for session keys and other
parameters), the first attack will either be detected in the
Responder’s (now incorrect) verification reply message (if such is
used) or be a pure DoS attack, resulting in Initiator and Responder
using different keys.
It is RECOMMENDED for the identity at the SPD level to be the one
authenticated at the key management protocol level. However, this
might need to keep into consideration privacy aspects, which are out
of scope for this framework.
The use of multiple key management protocols in the same offer may
open up the possibility of a bidding-down attack, as specified in
Section 4.1.4. To exclude such possibility, the authentication of
the protocol identifier list is used. Note though, that the security
level of the authenticated protocol identifier will be as high (or
low), as the "weakest" protocol. Therefore, the offer MUST NOT
contain any security protocols (or configurations thereof) weaker
than permitted by local security policy.
Note that it is impossible to ensure the authenticity of a declined
offer, since even if it comes from the true respondent, the fact that
the answerer declines the offer usually means that he does not
support the protocol(s) offered, and consequently cannot be expected
to authenticate the response either. This means that if the
Initiator is unsure of which protocol(s) the Responder supports, we
RECOMMEND that the Initiator offers all acceptable protocols in a
single offer. If not, this opens up the possibility for a "man-in-
the-middle" (MITM) to affect the outcome of the eventually agreed
upon protocol, by faking unauthenticated error messages until the
Initiator eventually offers a protocol "to the liking" of the MITM.
This is not really a security problem, but rather a mild form of
denial of service that can be avoided by following the above
recommendation. Note also that the declined offer could be the
result of an attacker who sits on the path and removes all the key
management offers. The bidding-down attack prevention, as described
above, would not work in this case (as the answerer receives no key
management attribute). Also, here it is impossible to ensure the
authenticity of a declined offer, though here the reason is the
"peeling-off" attack. It is up to the local policy to decide the
behavior in the case that the response declines any security
(therefore, there is impossibility of authenticating it). For
example, if the local policy requires a secure communication and
cannot accept an unsecured one, then the session setup SHALL be
aborted.
9. IANA Considerations
9.1. SDP Attribute Registration
The IANA has created a new subregistry for the purpose of key
management protocol integration with SDP.
SDP Attribute Field ("att-field"):
Name: key-mgmt-att-field
Long form: key management protocol attribute field
Type of name: att-field
Type of attribute: Media and session level
Purpose: See RFC 4567, Section 3.
Reference: RFC 4567, Section 3.1
Values: See RFC 4567, Sections 3.1 and 9.3.
9.2. RTSP Registration
The IANA has created a new subregistry for the purpose of key
management protocol integration with RTSP.
Following the guidelines of [RTSP], the registration is defined as
follows:
Header name: keymgmt
Header syntax: see RFC 4567, Section 3.2
Intended usage: see RFC 4567, Section 3.2
Proxy treatment: Proxies SHALL NOT add, change, or delete the
header. The proxy does not need to read this
header.
Purpose: see RFC 4567, Section 3
The RTSP Status-Code "463" (RFC 4567), with the default string "Key
management failure", needs to be registered.
9.3. Protocol Identifier Registration
This document defines one new name space, the "SDP/RTSP key
management protocol identifier", associated with the protocol
identifier, KMPID, defined in Section 3 to be used with the above
registered attributes in SDP and RTSP.
The IANA has created a new subregistry for the KMPID parameter, with
the following registration created initially: "mikey".
Value name: mikey
Long name: Multimedia Internet KEYing
Purpose: Usage of MIKEY with the key-mgmt-att-field
attribute and the keymgmt RTSP header
Reference: Section 7 in RFC 3830
Note that this registration implies that the protocol identifier,
KMPID, name space will be shared between SDP and RTSP.
Further values may be registered according to the "Specification
Required" policy as defined in [RFC2434]. Each new registration
needs to indicate the parameter name, and register it with IANA.
Note that the parameter name is case sensitive, and it is RECOMMENDED
that the name be in lowercase letters. For each new registration, it
is mandatory that a permanent, stable, and publicly accessible
document exists that specifies the semantics of the registered
parameter and the requested details of interaction between the key
management protocol and SDP, as specified in RFC 4567.
New values MUST be registered with IANA. Registrations SHALL include
the following information:
* Contact: the contact name and email address
* Value name: the name of the value being registered (which MUST
comply with the KMPID as defined in Section 3)
* Long Name: long-form name in English
* Purpose: short explanation of the purpose of the registered name.
* Reference: a reference to the specification (e.g., RFC number)
providing the usage guidelines in accordance to Section 6 (and also
complying to the specified requirements).
10. Acknowledgements
The authors would like to thank Francois Audet, Rolf Blom, Johan
Bilien, Magnus Brolin, Erik Eliasson, Martin Euchner, Steffen Fries,
Joerg Ott, Jon Peterson, and Jon-Olov Vatn. A special thanks to
Colin Perkins and Magnus Westerlund, who contributed in many
sections.
11. References
11.1. Normative References
[MIKEY] Arkko, J., Carrara, E., Lindholm, F., Naslund, M., and K.
Norrman, "MIKEY: Multimedia Internet KEYing", RFC 3830,
August 2004.
[OAM] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model
with Session Description Protocol (SDP)", RFC 3264, June
2002.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 2434,
October 1998.
[RFC3548] Josefsson, S., "The Base16, Base32, and Base64 Data
Encodings", RFC 3548, July 2003.
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
Resource Identifier (URI): Generic Syntax", STD 66, RFC
3986, January 2005.
[RFC4234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", RFC 4234, October 2005.
[RTSP] Schulzrinne, H., Rao, A., and R. Lanphier, "Real Time
Streaming Protocol (RTSP)", RFC 2326, April 1998.
[SDPnew] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session
Description Protocol", RFC 4566, July 2006.
[SIP] 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.
11.2. Informative References
[E2M] Ono, K. and S. Tachimoto, "Requirements for End-to-Middle
Security for the Session Initiation Protocol (SIP)", RFC
4189, October 2005.
[KERB] Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The
Kerberos Network Authentication Service (V5)", RFC 4120,
July 2005.
[RFC3851] Ramsdell, B., "Secure/Multipurpose Internet Mail
Extensions (S/MIME) Version 3.1 Message Specification",
RFC 3851, July 2004.
[SDES] Andreasen, F., Baugher, M., and D. Wing, "Session
Description Protocol (SDP) Security Descriptions for Media
Streams", RFC 4568, July 2006.
[SPREC] Andreasen, F., Baugher, M., and Wing, D., "Security
Preconditions for Session Description Protocol Media
Streams", Work in Progress, October 2005.
[SRTP] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K.
Norrman, "The Secure Real-time Transport Protocol (SRTP)",
RFC 3711, March 2004.
Authors’ Addresses
Jari Arkko
Ericsson
02420 Jorvas
Finland
Phone: +358 40 5079256
EMail: jari.arkko@ericsson.com
Elisabetta Carrara
Royal Institute of Technology
Stockholm
Sweden
EMail: carrara@kth.se
Fredrik Lindholm
Ericsson
SE-16480 Stockholm
Sweden
Phone: +46 8 58531705
EMail: fredrik.lindholm@ericsson.com
Mats Naslund
Ericsson Research
SE-16480 Stockholm
Sweden
Phone: +46 8 58533739
EMail: mats.naslund@ericsson.com
Karl Norrman
Ericsson Research
SE-16480 Stockholm
Sweden
Phone: +46 8 4044502
EMail: karl.norrman@ericsson.com
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).