MMUSIC Working Group H. Kaplan
Internet Draft Acme Packet
Expires: February 2007 F. Audet
Nortel Networks
August 2006
Session Description Protocol (SDP) Offer/Answer Negotiation
For Best-Effort Secure Real-Time Transport Protocol
draft-kaplan-mmusic-best-effort-srtp-00.txt
Status of this Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six
months and may be updated, replaced, or obsoleted by other documents
at any time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress".
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html
This Internet-Draft will expire on February 24, 2007.
Abstract
This document defines the requirements and a proposed solution for
an SDP Offer/Answer exchange model for negotiating best-effort SRTP
keys, i.e., in a backward-compatible manner with non-SRTP devices.
The proposed solution is a trivial interpretation of the usage of
the profile and the usage of SDP indication of [sdesc] and [kmgmt].
Kaplan Expires - February 2007 [Page 1]
Best Effort SRTP August 2006
Table of Contents
1. Introduction................................................2
2. Notational Conventions......................................4
3. Applicability...............................................4
4. Requirements................................................5
5. Solution Overview...........................................6
6. Offer/Answer Model:.........................................7
6.1. Generating the Initial Offer...........................7
6.2. Generating the Initial Answer..........................8
6.3. Processing the Initial Answer..........................9
7. Forked Offers and Multiple Answers.........................10
8. Clipping and Changing Transport Types......................10
9. Example Offer/Answer Exchange..............................10
10. Security Considerations....................................11
10.1. Security Implications vs. [sdesc] and [kmgmt].........12
11. References.................................................12
11.1. Normative References..................................12
11.2. Informative References................................13
Author's Address................................................13
Intellectual Property Statement.................................14
Disclaimer of Validity..........................................14
Copyright Statement.............................................14
Acknowledgments.................................................15
1. Introduction
The support of SRTP has been increasing recently, but its adoption
has still been relatively slow. One of the reasons for this is that
the currently defined mechanisms for exchanging SRTP keys are based
on an all-or-nothing approach, i.e., "Always secure" or "Always not
secure". If the offer indicates SRTP and the answerer cannot
support SRTP, or the particular key exchange mechanism, the entire
offer, or the actual session invitation, will fail. When the
desired policy is "Always secure", the current established mechanism
works perfectly well.
However, a need has been identified for a third policy: "Best-Effort
Security". Best Effort Security means that you prefer that SRTP be
used, but you are willing to use RTP if the other end does not
support it. There are different reasons why one may wish to use a
Best Effort policy. It could be to allow for interoperability with
many devices that may not support SRTP. In other cases, it may be as
a migration strategy or introducing new equipment that support SRTP,
cohabitating with devices that do not support SRTP until the older
equipment is replaced.
Kaplan Expires - February 2007 [Page 2]
Best Effort SRTP August 2006
Today, there is no generally accepted (and backward compatible) way
to indicate Best Effort SRTP key negotiation. Therefore, an SRTP-
capable device must either be prepared to re-attempt to establish a
media stream with RTP after failing with SRTP, or simply not offer
SRTP by default, and upgrade to SRTP when possible.
With the current mechanism, it may in the best case be possible to
start without SRTP initially (i.e., with the AVP [rtp] profile), and
then negotiate through another Offer/Answer [RFC3264] with either
[kmgmt] or [sdesc] the usage of SRTP and the session keys. This is
an extremely cumbersome process, and has the implication that every
call will use an additional Offer/Answer exchange, and will also
have the consequence that every call will start without SRTP, which
is undesirable.
Also with the current mechanism, starting with SRTP (i.e., the SAVP
profile) and downgrading to RTP is only achievable by rejecting the
whole session. However, rejecting a session in SIP (normally with a
4XX response code), has very negative implications because of the
[herfp] issue. To summarize the issue [herfp] means that the
rejection sent by the UAS, when used with forking, is very unlikely
to reach the UAC. Since that rejection is intended to cause a re-
negotiation without SRTP, the net effect is that the call fork fails
completely. In the best case scenario, another fork may answer
(e.g., a voicemail system), and in the worst case scenario, the
other forks also fails, which means that the calls fails entirely.
This is clearly unacceptable and a great impediment to the
deployment of SRTP. Note that this is an issue for both parallel
and sequential forking.
Note: Some may argue that one may reject the Offer setting the
port in the answer to zero as per [RFC3264], and then do a second
Offer/Answer; however, since the endpoints that do not support
the SAVP profile most likely do not behave this way in the first
place (they will reject the whole session), this means it would
not be backward compatible to use an Offer rejection mechanism.
Furthermore, many UAs automatically generate a BYE if they
receive an SDP answer with no accepted media lines
This document proposes a solution to Best Effort SRTP and backward
compatibility problem by introducing a third Policy to the existing
ones.
The existing supported mechanisms as of today are as follows:
* SAVP (and associated keys) means secure transport only, i.e.
"SRTP only"
* AVP means insecure transport only, i.e. "RTP only"
Kaplan Expires - February 2007 [Page 3]
Best Effort SRTP August 2006
This drafts proposes a Third mechanism:
* AVP with associated SRTP attributes means "Best-Effort SRTP"
The mechanism outlined in this document is trivial, and is defined
in order to successfully negotiate multiple mechanisms in one
offer/answer exchange, even if the answerer only supports clear/non-
secure RTP, and it is backward compatible. Examples are given for
[kmgmt] and [sdesc]. This mechanism only applies to Offer/Answer-
based applications.
The procedures described in this specification represent a technique
that has already been used and deployed in the real-world. It has
also been briefly mentioned in [sdp-neg], which lists many
techniques used today. Of all the techniques described in [sdp-neg],
it is by far the simplest one to address the "Best Effort SRTP"
problem, and the only one that does not risk "breaking" any
implementations.
It has been argued in [sdp-neg] that using "RTP/AVP" violates
[srtp]. After reviewing [srtp], the authors could not find any
justification to this claim. Rather, the authors claim that "if
SAVP is indicated, we can infer that SRTP is to be used, but the
reverse is not necessarily true, i.e., if AVP is used, it does not
mean that SRTP will not be used". In other words, there is a well-
defined encoding for using SRTP which is "SAVP", but that does not
preclude an offerer from offering "AVP" and proposing SRTP
dynamically. RFC 3407 [sim-cap] essentially already allows such a
model, whereby the backward-compatible encoded media profile may be
of one type, while the [sim-cap] offered alternate capability may
change the profile for those that understand [sim-cap]. This draft
essentially employs a similar model, but using the [sdesc] or
[kmgmt] attributes as the explicit alternate profile offer. It
should also be noted that [zrtp] already uses AVP for SRTP traffic.
2. Notational Conventions
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119. The
terminology in this document conforms to RFC 2828, "Internet
Security Glossary".
3. Applicability
This draft proposes using a [sdesc]/[kmgmt] style key exchange in a
backward-compatible manner with legacy RTP devices, for Offer/Answer
Kaplan Expires - February 2007 [Page 4]
Best Effort SRTP August 2006
exchange-based applications. This mechanism should provide a
smoother migration path, broader applicability, and more rapid
acceptance than [sdesc] or [kmgmt] mechanism used only in the "SRTP
only" mode.
The rules of this specification apply to AVP/SAVP.
OPEN ISSUE: The same technique arguably could be used with AVPF
[RFC4585]/SAVPF[savpf]. Should it? We have assumed only
AVP/SAVP, but it could easily be expanded to cover
AVPF/SAVPF.
4. Requirements
Unlike the requirements addressed in [sdpng] and [sdp-cap-neg], this
mechanism is not trying to address all the general issues with SDP
capability negotiation. Instead, it is trying to provide a solution
to a very short and defined set of requirements:
REQ-1: It MUST be possible to indicate and negotiate RTP vs. SRTP
profiles, on a per media stream basis.
REQ-2: It MUST be possible to offer SRTP profile to an RTP-only
answerer, and successfully negotiate RTP, without additional
offer/answers.
REQ-3: It MUST be possible to offer SRTP without allowing a fallback
to RTP, if the answerer does not support SRTP but the offerer only
wishes to either use SRTP or fail the negotiation.
REQ-4: The mechanism MUST be backwards compatible for SIP RTP-only
devices, without requiring them to change.
REQ-5: The mechanism MUST be media-type agnostic. (i.e., work with
any media type of any codec, etc.)
REQ-6: The mechanism MUST work in the presence of SIP forking.
REQ-7: The mechanism SHOULD support RTCP-based feedback, e.g. AVPF.
OPEN ISSUE: Should REQ-7 be a requirement?
We believe the above to be the necessary and sufficient requirements
set to achieve broad applicability and deployment of SRTP in the
near future. Below, we provide a proposed solution meeting those
requirements.
Kaplan Expires - February 2007 [Page 5]
Best Effort SRTP August 2006
5. Solution Overview
The basic concept is:
If an SRTP-capable device wishes to *only* offer SRTP and will only
accept SRTP be used, then it performs exactly the same steps as
defined in [sdesc] or [kmgmt], including indicating the SAVP
profile. The answerer would do the same. This is per current
practice.
If a device wishes to offer RTP only, then it uses the AVP profile,
and does not use [sdesc] or [kmgmt]. The answerer does the same.
This is also per current practice.
If an SRTP-capable device wishes to offer SRTP but will accept an
RTP answer if the far-end only supports that for a given media
stream, then it indicates SRTP support as an alternative, by
inserting the same media-level crypto attributes of [sdesc] or key
management attributes of [kmgmt], or both, into the offer using non-
secure transport profiles (e.g., "AVP" instead of "SAVP").
A legacy RTP-only device will ignore these unknown attributes and
answer as if they did not exist, i.e. using the "AVP" profile
without any crypto or key-mgmt attributes. The offerer then knows
they don't support it and will establish the session using regular
RTP.
A device supporting this draft and SRTP understands the attributes
indicate a willingness to use the SAVP profile instead, and responds
accordingly, by including a crypto or key-mgmt attribute in the
answer (but still using "AVP" encoding), resulting in SRTP.
* The main difficulty with offering SRTP-attributes using non-
secure transport profiles is that SRTP packets are virtually
indistinguishable from RTP packets - there is no "SRTP flag".
That means the offerer must either wait for the answer before
knowing how to handle received RTP packets, or a distinguishing
factor must be defined. This specification assumes the former:
the offerer must wait for an answer. Such is normally the case
with SRTP offers today anyway. Alternative methods for
distinguishing early media may be the subject of further study.
This specification is forward compatible with any such mechanism,
because it is expected that those mechanisms would introduce
additional encodings and negotiation procedures (at the SDP level,
and/or in-band).
Kaplan Expires - February 2007 [Page 6]
Best Effort SRTP August 2006
6. Offer/Answer Model:
This draft is based on the offer/answer method of [RFC3264] as used
by [sdesc] and [kmgmt], except the use of secure transport (e.g.,
"SAVP") type encoding in SDP is not always used, as described above
in section 6 and detailed below. This also changes some of the
offer/answer details and RTP processing behavior as described below.
6.1. Generating the Initial Offer
If a device supporting this draft wanted to mandate use of secure
transport (i.e., SRTP) for a particular media stream they MUST
continue to use the [sdesc] or [kmgmt] prescribed secure transport
encoding, i.e. "SAVP", as before.
A device supporting this draft that wishes to use secure transport
if the answerer supports it, but is willing to accept non-secure
transport otherwise (i.e., best effort SRTP), offers the same media-
level crypto attributes and parameters as [sdesc], and/or media-
level key-mgmt attributes of [kmgmt], except that it will indicate
the "RTP/AVP" profile in SDP. The purpose of this is that, should
the receiver(s) of the offer not support SRTP, or not support it for
that particular media stream, the offer will not be rejected. The
offerer can still decide to end the session at any time should it
wish to.
An offerer MAY offer both [sdesc] crypto attributes and [kmgmt] key-
mgmt attributes in the same SDP offer, for the same media sessions.
The offerer SHOULD order them in the order it prefers - the first
type offered is the most preferred, per media stream.
A potential complication is that KMGMT allows for supporting either
session level key management, media level key management or both.
When used with best-effort negotiation and in conjunction with
[sdesc], the procedures can get very cumbersome. This specification
requires that if Best Effort SRTP is used, that media-level
negotiation *only* MUST be offered. If both session-level and
media-level attributes are offered, for example a session-level key-
mgmt and media-level crypto, the secure transport "SAVP" encoding
MUST be used as per [kmgmt] and [sdesc].
Once an offer is generated with one or more crypto or key-mgmt
attributes using a non-secure transport encoding in SDP, the offerer
MUST NOT render any received media for those streams until an SDP
answer is received. This is because the offerer cannot definitively
know whether the received media is SRTP or RTP until it receives the
answer. SRTP key exchange already has this property today, for
which security pre-conditions as defined in [sec-pre] or provisional
Kaplan Expires - February 2007 [Page 7]
Best Effort SRTP August 2006
responses may be used as a solution. As mentioned in section 5,
alternative proposed methods to distinguish between RTP and SRTP
media are the subject of further study. If the offerer can
accurately determine how to interpret the received media, then it
MAY render it.
In summary, the offerer encodes a secure transport type (SAVP) for
every media stream it demands be secured, while encoding a non-
secure transport type (AVP) but with the crypto and/or key-mgmt
attributes for every media stream it would accept non-secure
transport for.
6.2. Generating the Initial Answer
If the offer contained both crypto and key-mgmt attributes, it is up
to answerer's local policy which key mechanism the answerer wishes
to use. The answerer SHOULD accept the first one in the offer it
understands and can support, per media stream. It MUST only encode
the like attribute type it chose to use for SRTP per media stream,
in the answer. In other words, it cannot choose both crypto and
key-mgmt for the same media stream.
Regardless of local-policy preference for which particular key type
to accept, the answerer MUST accept either one or the other if it
can. In other words, the offerer has indicated it wishes to use
SRTP, and the answerer MUST agree to do so if possible.
As per [sdesc] and [kmgmt], if the answerer chooses to accept crypto
attributes or key-mgmt, it MUST use the first attribute in the
offered list of attributes per media stream it can support if there
are more than one offered attributes for a given key exchange type.
For example if two crypto-style keys are offered for a given media
stream, the answerer must select the first one it supports.
If it cannot support any of the offered crypto or key-mgmt
attributes, however, it MUST treat the offer as if *no* crypto-
attributes had been offered. In other words, if the answerer's
policy allows non-secure RTP, it can accept the offer as if it had
been so. If the answerer's local policy is to only allow SRTP media
and not accept non-secure RTP, it MAY reject the offer. This lets a
key-mgmt-only offerer successfully negotiate non-secure RTP with a
crypto-only answerer, and vice-versa.
If the offer used a secure transport encoding in SDP, per [sdesc] or
[kmgmt], then it MUST operate as in [sdesc] or [kmgmt] and answer
using a secure transport encoding syntax if it can for the same
media stream, or fail the offer. Thus an answerer supporting this
draft will interoperate with an offerer supporting only legacy
[sdesc] or [kmgmt].
Kaplan Expires - February 2007 [Page 8]
Best Effort SRTP August 2006
If the offer uses best effort SRTP (using RTP/AVP profile), but
offered crypto or key-mgmt attributes which were acceptable and
answered, the answerer encodes its chosen key type and values and
MUST continue to use the insecure transport encoding, i.e., the
RTP/AVP profile.
6.3. Processing the Initial Answer
As per [sdesc] and [kmgmt], the answer is checked for matching
crypto or key-mgmt attributes and key information. If the answer
uses the RTP/AVP profile, and no crypto or key-mgmt attribute lines
are found in the answer, however, and the originally offered
transport was "AVP", then the negotiation MUST NOT be considered to
have failed. Instead, non-secure RTP is used regardless if the
original offer included any crypto or key-mgmt attributes to begin
with. This lets a Best-Effort SRTP offerer successfully negotiate
with a non-SRTP answerer, and a key-mgmt-only offerer successfully
negotiate non-secure RTP with a crypto-only answerer, and vice-
versa.
If a crypto attribute line is found in the answer, but does not have
a matching tag, included key, or contain all of the mandatory
negotiated session parameters, then the session negotiation MUST
fail. If a key-mgmt line is found in the answer, but does not pass
key management protocol processing, then the session negotiation
MUST fail. If both a crypto attribute and key-mgmt line is found in
the answer, at the media-level for the same media stream, then the
session negotiation MUST fail. If an answer contains a valid crypto
or key-mgmt attribute but they were not of the same key exchange
type as the offer for that media stream, then the session
negotiation MUST fail. These would all represent protocol failures.
If a key-mgmt line is found in the answer at the session level and a
key-mgmt or crypto attribute at the media level, and such was also
offered, then the media-level answers are used for each respective
media stream, and the session-level one used for the remaining SAVP
media streams (ones without media-level crypto or key-mgmt answers).
This is the same as best current practice today.
For each media stream which an acceptable answer is received at the
media level, and for all remaining SAVP media streams if an
acceptable session-level answer, the offerer MUST only accept SRTP
using the key and other values in the answer. It would do so as
described in [sdesc] or [kmgmt], as if the original Offer and Answer
used SAVP secure transport encoding. The offerer would then begin
generating SRTP based on the answer as per [sdesc] or [kmgmt] and
[srtp].
Kaplan Expires - February 2007 [Page 9]
Best Effort SRTP August 2006
7. Forked Offers and Multiple Answers
The generated Offer may be forked along the path, resulting in
multiple Answers. It is typically up to local-policy how to handle
such situations.
8. Clipping and Changing Transport Types
This draft relies on an Answer before processing media. Such is the
case typically for SRTP today regardless, as the offered keys are
usually the transmit keys - so an Answer has to be received to know
how to decrypt received SRTP. NAT traversal using ICE has this
limitation as well. [sdesc] and [mikey-rsa-r] also have this
limitation. Security preconditions, as defined in [sec-pre], and/or
sending the SDP answer in provisional responses as soon as possible,
are RECOMMENDED for such cases.
A second issue is changing transport types, in an updated
offer/answer. Since media typically reaches the UAC before an
answer, it may be difficult to know when to switch from RTP to SRTP
or vice-versa.
Supporting such cases is for future study.
9. Example Offer/Answer Exchange
In the following example, Alice is proposing to establish an
unsecure RTP H.263 video channel in conjunction with a Best Effort
SRTP voice channel using either G.711 or G.729, using either [kmgmt]
or [sdesc]. Note that the a=crypto and the a=key-mgmt lines are
really 2 long lines.
v=0
o=alice 2890844526 2890842807 IN IP4 192.0.2.2
s=Best effort secured discussion
e=alice@example.com (Alice)
c=IN IP4 192.0.2.2
t=2873397496 2873404696
m=video 51372 RTP/AVP 34
a=rtpmap:34 H263/9000
m=audio 49170 RTP/AVP 0 18
a=rtpmap:0 PCMU/8000
a=rtpmap:18 G729/8000
a=crypto:1 AES_CM_128_HMAC_SHA1_80
Kaplan Expires - February 2007 [Page 10]
Best Effort SRTP August 2006
inline:WVNfX19zZW1jdGwgKCkgewkyMjA7fQp9CnVubGVz|2^20|1:4
a=key-mgmt:mikey AQAFgM0XflABAAAAAAAAAAAAAAsAyONQ6gAAAAAGEE
oo2pee4hp2UaDX8ZE22YwKAAAPZG9uYWxkQGR1Y2suY29tAQAAAAAAAQA
k0JKpgaVkDaawi9whVBtBt0KZ14ymNuu62+Nv3ozPLygwK/GbAV9iemnG
UIZ19fWQUOSrzKTAv9zV
In this sample Answer below, Bob does not support SRTP, and
therefore ignores the [kmgmt] and [sdesc] attributes and selects RTP
for the voice channel, and also accepts the video channel.
v=0
o=bob 2890890210 807082634 IN IP4 192.0.2.4
s=Open discussion
e=bob@example.net (Bob)
c=IN IP4 192.0.2.4
t=2873397496 2873404696
m=video 4900 RTP/AVP 34
a=rtpmap:34 H263/9000
m=audio 32640 RTP/AVP 0
a=rtpmap:0 PCMU/8000
In this sample Answer below, Bob does support SRTP, selects [sdesc]
for the voice channel, and also accepts the video channel.
v=0
o=bob 2890890210 807082634 IN IP4 192.0.2.4
s=Secret discussion
e=bob@example.net (Bob)
c=IN IP4 192.0.2.4
t=2873397496 2873404696
m=video 4900 RTP/AVP 34
a=rtpmap:34 H263/9000
m=audio 32640 RTP/SAVP 0
a=rtpmap:0 PCMU/8000
a=crypto:1 AES_CM_128_HMAC_SHA1_80
inline:PS1uQCVeeCFCanVmcjkpPywjNWhcYD0mXXtxaVBR|2^20|1:4
10. Security Considerations
Like [sdesc], SDP using the mechanism in this draft with crypto
attributes is conveyed in an encapsulating application protocol
which MUST provide both strong eavesdropping and authentication
mechanisms. The same may be true of key-mgmt lines, depending on
the key management protocol. The security requirements in [sdesc]
and [kmgmt] MUST be followed for this draft as well.
Kaplan Expires - February 2007 [Page 11]
Best Effort SRTP August 2006
10.1. Security Implications vs. [sdesc] and [kmgmt]
The best-effort mechanism proposed in this draft may be considered
less secure than [sdesc] and [kmgmt] because it allows a bid-down
attack to establish non-secure RTP sessions, even if both ends
supported SRTP. It is however more secure than not using SRTP at
all. This is by design, however, in order to facilitate
interoperability and migration from RTP to SRTP. No mechanism
proposed so far truly can prevent a bid-down attack. The difference
is that [sdesc] and [kmgmt] would result in a failed session
negotiation, whereas this mechanism would not. The authors consider
that a benefit of this draft, not a drawback. This draft still
mandates using SAVP if the offerer *only* accepts secure transport.
If the offerer would accept less anyway, then a malicious attacker
can as easily bid-down [sdesc] or [kmgmt] simply by failing the
session, since by definition such an offerer will re-signal using
non-secure transport encoding. Therefore, this draft's mechanism is
only more susceptible to bid-down in a trivial way - namely because
it will happen in fewer messages.
Using S/MIME or signing bodies using [identity] may also prevent
bid-down attacks.
Neither party needs to accept a session using non-secure RTP: the
offerer can simply use the secure transport encoding in SDP, and the
answerer can simply reject offers which do not offer such; or either
end can terminate the session or re-offer at any time. Those are
local policy decisions which are available for any mechanism.
11. References
11.1. Normative References
[sdesc] Andreasen, F., Baugher, M., and D. Wing, "Session
Description Protocol (SDP) Security Description for Media Streams",
RFC 4568, July 2006
[kmgmt] Arkko, J., et al, "Key Management Extensions for Session
Description Protocol (SDP) and Real Time Streaming Protocol (RTSP)",
RFC 4567, July 2006
[sdp] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session
Description Protocol", RFC 4566, July 2006.
[RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model
with Session Description Protocol (SDP)", RFC 3264, June 2002.
[RFC3550] Schulzrinne, Casner, Frederick and Jacobson, "RTP: A
Transport Protocol for Real-Time Applications", RFC 3550, July 2003.
Kaplan Expires - February 2007 [Page 12]
Best Effort SRTP August 2006
[srtp] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K.
Norrman, "The Secure Real-time Transport Protocol (SRTP)", RFC 3711,
March 2004.
[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
[RFC4585] Ott, Wenger, Sato, Burmeiste, Rey, "Extended RTP Profile
for Real-time Transport Control Protocol (RTCP)-Based Feedback
(RTP/AVPF)", RFC 4585, July 2006
[sim-cap] Andreasen, "Session Description Protocol (SDP) Simple
Capability Declaration", RFC 3407, October 2002
[herfp] Mahy, "A Solution to the Heterogeneous Error Response
Forking Problem (HERFP)in the Session Initiation Protocol (SIP)",
draft-mahy-sipping-herfp-fix-01
[identity] Peterson, Jennings, "Enhancements for Authenticated
Identity Management in the Session Initiation Protocol (SIP)",
draft-ietf-sip-identity-06
[mikey-rsa-r] Ignjatic, Dondeti, Audet, Lin, "An additional mode of
key distribution in MIKEY: MIKEY-RSA-R", draft-ietf-mikey-rsa-r-07
[savpf] Ott, Carrara, "Extended Secure RTP Profile for RTCP-based
Feedback (RTP/SAVPF)", draft-ietf-avt-profile-savpf-06
[sdp-neg] Andreasen, "SDP Capability Negotiation", draft-andreasen-
mmusic-sdp-capability-negotiation-00
[sec-pre] Andreasen, Wing, "Security Preconditions for Session
Description Protocol (SDP) Media Streams", draft-ietf-mmusic-
securityprecondition-02
[zrtp] Zimmermann, "ZRTP: Extensions to RTP for Diffie-Hellman Key
Agreement for SRTP", draft-zimmermann-avt-zrtp-01
Author's Address
Hadriel Kaplan
Acme Packet
71 Third Ave.
Kaplan Expires - February 2007 [Page 13]
Best Effort SRTP August 2006
Burlington, MA 01803, USA
Email: hkaplan@acmepacket.com
Francois Audet
Nortel Networks
4655 Great America Parkway
Santa Clara, CA 95054, USA
Email: audet@nortel.com
Intellectual Property Statement
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.
Disclaimer of Validity
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.
Copyright Statement
Kaplan Expires - February 2007 [Page 14]
Best Effort SRTP August 2006
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.
Acknowledgments
The authors wish to thank Alan Johnston who first suggested the idea
(we believe). We also thank Flemming Andreasen, Dan Wing, Randell
Jessup, Andrew Zmolek, and Robert Gilman for their suggestions.
Kaplan Expires - February 2007 [Page 15]