Internet DRAFT - draft-kaplan-best-srtp-keys
draft-kaplan-best-srtp-keys
Internet Draft H. Kaplan
Document: draft-kaplan-best-srtp-keys-00.txt Acme Packet
Expires: January 2007 July 2006
Best-case End-to-end SRTP Technique for
Key Exchange interoperabilitY (BEST-KEY)
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 cite them other than as "work in progress".
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/lid-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html
Copyright Notice
Copyright (C) The Internet Society (2006).
Abstract
This document defines an opportunistic SRTP key exchange mechanism to
get the best-case SRTP keys, using a slightly modified version of
Security Descriptions model [secdes], followed by a second-stage
media-plane key exchange based on [XXX]. There are several distinct
advantages to this mechanism over others; these benefits are
documented herein. The main goal of this draft is to put forth a
strawman proposal to perform a 2-stage key-exchange, first via a
[secdes] style mechanism, then through a media-plane mechanism.
Kaplan Expires - January 2007 [Page 1]
draft-kaplan-best-srtp-keys-00.txt July 2006
Table of Contents
1. Introduction................................................2
2. Notational Conventions......................................3
3. Applicability...............................................3
4. Benefits and Drawbacks of BEST-KEY..........................4
5. Changes to Security Descriptions for BEST-KEY...............5
6. Offer/Answer Model for BEST-KEY: Stage 1....................5
6.1 Generating the Initial Offer...............................6
6.2 Generating the Initial Answer..............................6
6.3 Processing the Initial Answer..............................7
7. Media-Plane Key Update for BEST-KEY – Stage 2...............8
8. Formal Syntax...............................................9
9. Security Considerations.....................................9
9.1 Security Implications vs. RFC 4568 [secdes]................9
9.2 Security Implications vs. Media-plane Mechanisms Alone....10
References.......................................................11
Author's Address.................................................11
Intellectual Property Statement..................................11
Disclaimer of Validity...........................................12
Copyright Statement..............................................12
Acknowledgments..................................................12
1. Introduction
There are currently 11 proposed mechanisms for exchanging and
negotiating keys for Secure Real-time Transport Protocol (SRTP)
[srtp], none of which interoperate. Some of these are signaling-
plane mechanisms, meaning the key exchange mechanism is handled in
SDP carried in session signaling messages; other mechanisms are
media-plane, meaning the key exchange is performed end-to-end between
the originator and terminator of the SRTP streams. Of the signaling-
plane mechanisms, the most popular is the RFC 4568 Security
Descriptions mechanism [secdes]. Of the media-plane mechanisms,
there is no clear leader currently. [Note to editor: change previous
sentence to be the one media-plane mechanism chosen by the group].
The [secdes] mechanism has several benefits which make it attractive
for a particular class of equipment: is incurs very little processing
burden per session, and is the least complicated. But it also has
several security weaknesses which make it less secure than other
mechanisms. In general, stronger security typically costs more to
implement and is only necessary for a smaller community, while weaker
security generally costs less and is sufficient for a larger
community; thus this author believes the popularity of the [secdes]
model is unavoidable. Meanwhile, the security drawbacks are equally
unpalatable for a significant set of use cases, and thus media-plane
end-to-end mechanisms are more desirable. It also has the
Kaplan Expires - January 2007 [Page 2]
draft-kaplan-best-srtp-keys-00.txt July 2006
unfortunate characteristic that the other end must support [secdes]
or else a new offer/answer must be performed.
Therefore, this document proposes both: sessions begin with Security
Descriptions (slightly modified), and after becoming established,
attempt a media-plane key exchange mechanism. If both ends support
the media-plane mechanism, then the SRTP keys are updated and the
media session ends up with stronger security; if either end only
supports Security Descriptions, then the weaker SECDES-based keys are
used, which is still better than not performing SRTP at all; if one
side only supports RTP, then RTP is used without having to perform a
new offer/answer exchange.
The changes to Security Descriptions outlined in this document are
fairly minor, and are defined in order to successfully negotiate
multiple mechanisms in one offer/answer exchange, even if the
answerer only supports clear/non-secure RTP. These changes may be
better defined in a separate draft, but are done here temporarily to
expedite matters (namely, discussion in RTPSEC group). The main goal
of this draft is to put forth a straw-man proposal to perform a 2-
stage key-exchange, first via a [secdes] style mechanism, then
through a media-plane mechanism.
2. Notational Conventions
The key words "MUST", "MUST NOT", "REQUIRED", "SHOULD", "SHOULD NOT",
"RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be
interpreted as described in [RFC2119]. The terminology in this
document conforms to [RFC2828], "Internet Security Glossary".
The term 'media-plane mechanism' is used throughout this document to
represent whatever end-to-end key exchange mechanism is chosen as the
primary one by the RTPSEC group or RAI area WG. It is not intended
to signify the chosen mechanism will be based on any particular
proposed mechanism, nor whether it uses RTP packets, RTCP packets, or
some other packets/protocol to perform the key exchange.
The term 'signaling-plane mechanism' is used in this document to
represent SRTP key exchange performed through SDP carried in an
application protocol, such as SIP or MGCP. Such a mechanism follows
the signaling path, getting transferred hop-by-hop by signaling
intermediaries, such as proxies.
3. Applicability
RFC 4568 [secdes] offers a similar type of key exchange method, since
this draft uses it with some minor modification. In contrast, this
Kaplan Expires - January 2007 [Page 3]
draft-kaplan-best-srtp-keys-00.txt July 2006
draft proposes using a [secdes] style key exchange in a backward-
compatible manner with legacy RTP devices in a first stage, and
trying to update the keys with a media-plane mechanism if both ends
support it in a second stage. This mechanism should provide a
smoother migration path, broader applicability, and more rapid
acceptance than [secdes] or a media-plane mechanism alone.
4. Benefits and Drawbacks of BEST-KEY
The BEST-KEY mechanism provides several valuable benefits over using
[secdes] or a media-plane mechanism alone:
1. It allows two ends to negotiate the strongest SRTP key
possible, without multiple SDP offers/answers.
2. It is backwards-compatible, meaning a BEST-KEY offer to a
non-BEST-KEY receiver still results in a successful session
with media, although one using non-secure RTP.
3. It does not rely on signaling-plane security, if both ends
support a media-plane mechanism which does not rely on it.
4. It supports the largest/broadest set of device performance
classes: including devices which cannot afford the resource
penalty of per-call media-plane key exchange mechanisms, and
devices which can. In other words, it should achieve broad
use because it is not limited in applicability.
5. It is a fairly trivial change from [secdes], which has
already been implemented in some devices. Therefore it
should not be too burdensome to modify the implementations in
use. In fact, a BEST-KEY answerer will interoperate with a
legacy [secdes] offerer. (but not vice-versa)
6. It is fully compliant with SDP RFC 4566 [sdp], and does not
change the ABNF syntax of [secdes].
7. It works for any application protocol which carries SDP and
follows the offer/answer mechanism of [RFC3264].
8. It should provide a way to achieve end-to-end SRTP even in
mixed application signaling environments, as well as hop-by-
hop for environments that require that.
9. It provides for a migration path from RTP to SRTP based on
[secdes] style keys, and to SRTP based on end-to-end keys.
It is this author's opinion that a migration path with broad
applicability is critical to the success of any mandated IETF
SRTP key exchange mechanism. There are already millions of
RTP-capable devices in deployment that will not be replaced
overnight on a "flag-day", and must be interoperated with,
with as little pain as possible.
The drawbacks to BEST-KEY are:
1. A successful bid-down attack will result in non-secure
RTP, if neither end supports a media-plane mechanism. See
the security section 9 for a discussion on this.
Kaplan Expires - January 2007 [Page 4]
draft-kaplan-best-srtp-keys-00.txt July 2006
2. For devices which can handle media-plane exchange
mechanisms, BEST-KEY adds a bit of overhead/work since it
mandates a [secdes] style key exchange as well. Since
such devices are typically not resource-constrained, that
should not be an issue.
3. It may provide a false sense of security to users if the
User Interface is not properly handled. For example, if
there is a single lock-icon which is on regardless of how
the keys were exchanged, users will not realize a call
which only uses a signaling-plane key is less secure than
a media-plane one. This is debatable, however, as even
the media-plane mechanisms are not perfectly secure, and
at least BEST-KEY provides a migration path so that
there's a reason to create a lock-icon in the UI.
5. Changes to Security Descriptions for BEST-KEY
The ABNF syntax and protocol mechanics described in RFC 4568 SDP
Security Descriptions for Media Streams [secdes] are adopted by this
draft, with the following exceptions/changes:
1. The transport type encoded in SDP MUST NOT be the SRTP
transport defined in [srtp] of "RTP/SAVP" or "RTP/SAVPF", unless the
offerer wishes to *only* allow SRTP answers. Instead, this draft
requires the transport encoding type MUST be the same one used if RTP
were not secured (e.g., "RTP/AVP"). If the offerer wishes the offer
to fail if the far-end does not support SRTP, then she would continue
to use the same transport encoding mandated by [secdes] and [srtp].
[Note: that can already be done per [secdes] and does not require
this draft at all, does it?] The purpose of this draft is to provide
the best-case with call success, even if that results in non-secure
RTP media.
2. BEST-KEY is defined to interoperate with legacy RTP devices,
and thus some of the protocol rules are modified, as described later
in this document.
3. Depending on the final media-plane SRTP key mechanism chosen
by the RTPSEC BOF or RAI, there may be a need to provide an
indication or identifying data (e.g., fingerprint) for the media-
plane mechanism in SDP. Such content is expected to be encoded along
with the crtypo attributes of [secdes], on separate attribute lines.
Since the media-plane mechanism is not chosen yet, those details are
not yet known.
6. Offer/Answer Model for BEST-KEY: Stage 1
Kaplan Expires - January 2007 [Page 5]
draft-kaplan-best-srtp-keys-00.txt July 2006
BEST-KEY is based on the offer/answer method as defined by RFC 4568
SDP Security Descriptions for Media Streams [secdes], except the use
of SAVP or SAVPF transport type encoding in SDP is not typically
used, as described above in section 5. This also changes some of the
offer/answer details and RTP processing behavior as described below.
6.1 Generating the Initial Offer
A device supporting this draft offers the same crypto attributes and
parameters as [secdes] except using a non-secure transport encoding
in SDP, such as "RTP/AVP". The purpose for this is so that, should
the receiver(s) of the offer not support SRTP, the offer will not be
rejected. The offerer can still decide to end the session at any
time should it wish to, of course, but if the offerer wanted to
mandate use of SRTP they MUST continue to use the [secdes] encoding
of SAVP or SAVPF as before. There is no advantage (or difference) to
using this draft over [secdes] in that case.
Once an offer is generated with one or more crypto attributes using a
non-secure transport encoding in SDP, the offerer MUST be ready to
receive non-secure RTP if it would have done so had it not offered
any crypto attributes. This is necessary for compatibility with
receivers/answerers of the offer that do not support this draft, or
do not support SRTP, and simply follows the basic model defined
previously in RFC 3264.
6.2 Generating the Initial Answer
As per [secdes], the answerer MUST accept one of the offered crypto
attributes it can support, and the first one in the list it can
support if there are more than one. If it cannot support any,
however, it MUST accept the offer as if no crypto-attributes had been
offered. In other words, if the answerer's local policy is to only
allow SRTP media and not accept non-secure RTP, it may reject the
offer. If the answerer's policy allows non-secure RTP, it can accept
the offer as if it had been so.
If the offer used an SAVP or SAVPF transport encoding in SDP, per
[srtp] and [secdes], then it MUST operate as in [secdes] and answer
using an SAVP or SAVPF encoding syntax. Thus an answerer supporting
this draft will interoperate with an offerer supporting only legacy
[secdes]. The answerer must then generate SRTP as it would have done
in [secdes], and may optionally include an MKI in the SRTP per
[secdes].
If the offer uses a non-secure transport encoding in SDP, but offered
crypto attributes which were acceptable and answered, the answerer
Kaplan Expires - January 2007 [Page 6]
draft-kaplan-best-srtp-keys-00.txt July 2006
MUST generate SRTP packets using the answered information. The
answerer MUST also include an MKI in the SRTP packets, but MAY stop
doing so when it has an indication the offerer has received the
answer. For example, receiving an SRTP packet from the offerer
implies the offerer has received and processed the answer. If the
answerer does not wish to continue using an MKI for the duration of
the session, it MAY choose not to encode the MKI and length in the
SDP attribute. In such a case, it MUST use an MKI value of 1 and
length of 4 in the SRTP packets if it adds them. The reason for
doing this is described in the next section.
6.3 Processing the Initial Answer
As per [secdes], the answer is checked for matching crypto attributes
and key information. If no crypto attribute lines are found in the
answer, however, and the offered transport was a non-secure type
(i.e., not SAVP) then the negotiation MUST NOT be considered to have
failed. Instead, non-secure RTP is used as if the offer had not
included any crypto attributes to begin with.
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 negotiation MUST fail. This
would represent a protocol failure.
If a crypto attribute line is found in the answer, with a matching
tag, valid key, and contains all the necessary negotiated session
parameters, then the offerer MUST stop accepting non-secure RTP media
and only accept SRTP using the key and other values in the answer, as
described in [secdes]. The offerer would then begin generating SRTP
as per [secdes] and [srtp].
An interesting property of the above rule is that it allows a call to
start with non-secure RTP and "upgrade" to secdes-based SRTP without
a second, updated offer being generated by the offerer – only an
updated answer need be received. For example, using SIP, the Invite
would offer this draft's SDP encoding, a 183 would contain a non-
crypto answer in SDP, and the 200 ok would contain a crypto final
answer. Such a case could be useful for rich-ringtone and early-
announcement services in use today, which probably don't need secure
RTP for ringtone. (unless it's a DRM issue :)
Note: one would think this may cause a short period of no media, and
degrade the service, but that is not the case. If non-secure RTP
were actually being sent by the far-end, it means they received the
offer and do not actually support SRTP or this draft; otherwise they
would be using their key to transmit SRTP. Since the keys offered in
[secdes] are the transmit keys, an offerer cannot truly process
Kaplan Expires - January 2007 [Page 7]
draft-kaplan-best-srtp-keys-00.txt July 2006
received SRTP until an answer is received regardless. Therefore this
draft makes the situation no worse than [secdes], while still
supporting non-secure early media for cases where the far-end does
not support SRTP.
A problem with accepting non-secure RTP before the answer, or
upgrading to SRTP on a second answer, is that the SRTP media will
most likely reach the offerer before the SDP answer indicating SRTP
is accepted (and what the key is). Since SRTP packets follow the RTP
packet format, such early packets would actually be decoded as RTP
and possibly rendered, resulting in illegible audio tones and video
display. This would not have occurred in [secdes] because non-secure
RTP would not be accepted at all in that mechanism, and this new
behavior is probably not acceptable in general.
Therefore, per section 6.2, a device supporting BEST-KEY will add the
MKI tag to SRTP packets when it is the answerer and the offer did not
specify a secure transport. It is possible, though, that it does not
encode the MKI value and length in the answer, if it did not wish to
use an MKI for the duration of the session. In such a case it would
use an MKI value 1 and a length of 4, and the offerer MUST recognize
such as SRTP packets. The MKI is thus used as a RTP vs. SRTP
differentiator, and a BEST-KEY offerer MUST NOT attempt to render
such marked packets as un-encrypted RTP until it has received the
decrypt key in the answer and handles it as SRTP.
[Note: is this complexity worth it? Forcing MKI may raise the bar too
much for easy changes to secdes-based devices. Maybe we should not
support RTP until the answer.]
7. Media-Plane Key Update for BEST-KEY – Stage 2
After negotiating the initial SRTP keys through the offer/answer
model using crypto attributes as described previously, the media-
plane key exchange mechanism is initiated. Depending on the primary
media-plane mechanism chosen by the IETF, this may only occur if the
SDP included appropriate information to do so.
If the media-plane mechanism chosen includes sufficient information
in the SDP which could negotiate without using the crypto attribute
provided keys, the crypto-attribute keys provided through SDP MUST be
used if the media-plane mechanism fails to negotiate successfully.
The only exception to this is if either end has a local policy to
reject such a case, in which case the session MUST be explicitly
terminated. The SDP exchange and key exchange per this draft is
considered to have succeeded, so session signaling must be used to
end the session. [Note: this will probably depend on the mechanism
chosen in the end, so this will be cleaned up later]
Kaplan Expires - January 2007 [Page 8]
draft-kaplan-best-srtp-keys-00.txt July 2006
If the media-plane mechanism chosen does not include sufficient
information in the SDP to immediately exchange SRTP media, the
crypto-attribute provided keys MUST be used for RTP while the media-
plane mechanism is attempted. This is necessary in case the far-end
does not support the media-plane mechanism, and for early media
support.
Assuming the media-plane mechanism supports it, regardless of whether
the received SDP offer or answer contained indication for BEST-KEY
and SRTP, the media-plane mechanism MUST be attempted. This is to
try to overcome any bid-down attack in the signaling-plane. This
assumes the media-plane mechanism chosen is such that it can be
attempted blindly without causing interoperability problems for
legacy SRTP or RTP devices. [Note: that's a big assumption, maybe we
shouldn't try this if signaling didn't agree]
8. Formal Syntax
[Note: I'm not sure any formal syntax is warranted, is it? No ABNF
changes from [secdes] anyway, though IANA registry might need a
change]
9. Security Considerations
Like [secdes], SDP using the mechanism in this draft is conveyed in
an encapsulating application protocol which MUST provide both strong
eavesdropping and authentication mechanisms. The security
requirements in [secdes] MUST be followed for this draft as well.
[Note: I'm considering relaxing that a bit, because it's (a) going to
be ignored anyway, (b) not necessary for some situations, and (c) may
not be necessary depending on the media-plane mechanism chosen. I'll
have to think on it some more.]
9.1 Security Implications vs. RFC 4568 [secdes]
The BEST-KEY mechanism proposed in this draft is less secure than
[secdes] because it allows a bid-down attack to establish non-secure
RTP sessions, even if both ends supported SRTP and BEST-KEY. This is
by design, however, in order to facilitate interoperability. No
mechanism proposed so far truly prevents a bid-down attack, as far as
this author knows. The difference is that [secdes] and some other
mechanisms would result in a failed session negotiation, whereas this
mechanism would not. The author considers that a benefit of BEST-
KEY, not a drawback. Neither party needs to accept a session using
non-secure RTP: the offerer can simply use the [secdes] offer model
of secure transport encoding in SDP, and the answerer can simply
Kaplan Expires - January 2007 [Page 9]
draft-kaplan-best-srtp-keys-00.txt July 2006
reject offers which do not offer a BEST-KEY or [secdes] offer; or
either end can terminate the session or re-offer at any time. Those
are local policy decisions which are available for any mechanism.
A second issue is that this draft opens the possibility for a middle-
man snooper to send non-secure RTP to the offerer, before the answer
is received indicating SRTP should be used. Thus, even if the
middle-man cannot view the SRTP-specific information in the SDP, he
may be able to inject false RTP for a short time by guessing the
media port (it's typically not hard to guess, as it's often a fixed
offset from one used in a device's previous session). That is
essentially unavoidable if we allow early media.
9.2 Security Implications vs. Media-plane Mechanisms Alone
Like [secdes], BEST-KEY has specific security weaknesses. Unlike
[secdes], BEST-KEY has the ability to use a more-secure key exchange
mechanism if both ends can, while still providing SRTP support for
those that cannot perform the media-plane mechanism, and fallback to
RTP support for those that cannot perform SRTP at all.
In particular, the following are recognized weaknesses of BEST-KEY
and [secdes]:
1. The use of S/MIME is incredibly rare, SIPS is uncommon, and
there is virtually no way to guarantee all the hops along the
signaling path use TLS or IPSEC; even using TLS or IPSEC, if the SDP
is passed through intermediate systems (proxies, b2bua's, etc.)
without SDP-level encryption, then the intermediate systems have
access to the keys, can modify them, etc. This is likely still more
secure than sending them in the clear, but is an obvious point of
vulnerability. The benefit of BEST-KEY is this only affects the
media exchanged before a media-plane mechanism updates the keys, if a
media-plane mechanism is available.
2. If the SDP is provided to more than one party, for example in
a forked SIP request, then even the party which did not answer has
access to the keys for media being generated by the offerer. This is
similar to (1) above, and the benefit of BEST-KEY is the same as for
(1) above. Furthermore, the offerer is free to create an updated
offer with new keys at any time after session establishment, if she
so wishes.
3. Unlike some other mechanisms which use the signaling-plane, it
is not sufficient to only integrity protect BEST-KEY and [secdes],
without also encryption. This means use of a mechanism such as sip-
identity [zzzz] is not sufficient, because it leaves the SDP as
cleartext. An eavesdropper need only see the SDP to be able to
decrypt the SRTP streams, or even inject her own. Proponents of
Kaplan Expires - January 2007 [Page 10]
draft-kaplan-best-srtp-keys-00.txt July 2006
other signaling-based or media-plane-based mechanisms argue this
makes an [secdes] style mechanism inferior. It should be noted,
however, that sip-identity is neither ubiquitous today, nor would it
actually provide end-to-end integrity protection. Sip-identity is
expected to be typically signed by an intermediate system, such as
the first-hop proxy, and possibly verified and re-signed by a last-
hop proxy. Those systems can modify the contents of SDP at will; for
example, SBCs are such intermediate systems.
References
[secdes] Andreasen, F., Baugher, M., and D. Wing, "Session
Description Protocol (SDP) Security Description for Media Streams",
RFC 4568, 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.
[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.
[Note: I'm sure I forgot some... will add later if this gets taken as
anything more than a straw-man]
Author's Address
Hadriel Kaplan
Acme Packet
71 Third Ave.
Burlington, MA 01803
Email: hkaplan@acmepacket.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
Kaplan Expires - January 2007 [Page 11]
draft-kaplan-best-srtp-keys-00.txt July 2006
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
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 author of this draft did not personally conceive the two-stage
approach. He has been unable to find the originator of it, and so
decided to write this draft as a straw-man for the RTPSEC focus group
to move the process along. If you are the originator, and wish to
take over editorial control, feel free to contact the current author;
he will be more than happy to give credit and editorial
responsibility to another. The "BEST-KEY" acronym however, is solely
the author's fault.
Kaplan Expires - January 2007 [Page 12]
