doc: Add RFC documents

1 files changed, 1067 insertions, 0 deletions

diff --git a/doc/rfc/rfc4738.txt b/doc/rfc/rfc4738.txt
new file mode 100644
index 0000000..812c61f
--- /dev/null
+++ b/doc/rfc/rfc4738.txt
@@ -0,0 +1,1067 @@
+
+
+
+
+
+
+Network Working Group                                        D. Ignjatic
+Request for Comments: 4738                                       Polycom
+Updates: 3830                                                 L. Dondeti
+Category: Standards Track                                       QUALCOMM
+                                                                F. Audet
+                                                                  P. Lin
+                                                                  Nortel
+                                                           November 2006
+
+
+          MIKEY-RSA-R: An Additional Mode of Key Distribution
+                 in Multimedia Internet KEYing (MIKEY)
+
+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.
+
+Copyright Notice
+
+   Copyright (C) The IETF Trust (2006).
+
+Abstract
+
+   The Multimedia Internet Keying (MIKEY) specification describes
+   several modes of key distribution solution that address multimedia
+   scenarios (e.g., SIP calls and Real Time Streaming Protocol (RTSP)
+   sessions) using pre-shared keys, public keys, and optionally a
+   Diffie-Hellman key exchange.  In the public-key mode, the Initiator
+   encrypts a random key with the Responder's public key and sends it to
+   the Responder.  In many communication scenarios, the Initiator may
+   not know the Responder's public key, or in some cases the Responder's
+   ID (e.g., call forwarding) in advance.  We propose a new MIKEY mode
+   that works well in such scenarios.  This mode also enhances the group
+   key management support in MIKEY; it supports member-initiated group
+   key download (in contrast to group manager pushing the group keys to
+   all members).  This document updates RFC 3830 with the RSA-R mode.
+
+
+
+
+
+
+
+
+
+
+
+Ignjatic, et al.            Standards Track                     [Page 1]
+
+RFC 4738                      MIKEY-RSA-R                  November 2006
+
+
+Table of Contents
+
+   1. Introduction ....................................................3
+      1.1. Terminology Used in This Document ..........................3
+   2. Motivation ......................................................3
+      2.1. Description of the MIKEY Modes .............................3
+      2.2. Use Case Motivating the Proposed Mode ......................5
+   3. A New MIKEY-RSA Mode: MIKEY-RSA-R ...............................5
+      3.1. Outline ....................................................5
+      3.2. Group Communication Using the MIKEY RSA-R Mode .............6
+      3.3. Preparing RSA-R Messages ...................................6
+      3.4. Components of the I_MESSAGE ................................6
+      3.5. Processing the I_MESSAGE ...................................8
+      3.6. Components of the R_MESSAGE ................................9
+      3.7. Processing the R_MESSAGE ..................................10
+      3.8. Certificate Handling ......................................10
+      3.9. Additions to RFC 3830 Message Types and Other Values ......11
+           3.9.1. Modified Table 6.1a from RFC 3830 ..................11
+           3.9.2. Modified Table 6.12 from RFC 3830 ..................12
+           3.9.3. Modified Table 6.15 from RFC 3830 ..................12
+   4. Applicability of the RSA-R and RSA Modes .......................13
+      4.1. Limitations ...............................................13
+   5. Security Considerations ........................................14
+      5.1. Impact of the Responder Choosing the TGK ..................15
+      5.2. Updates to Security Considerations in RFC 3830 ............15
+   6. IANA Considerations ............................................15
+   7. Acknowledgments ................................................16
+   8. References .....................................................16
+      8.1. Normative References ......................................16
+      8.2. Informative References ....................................16
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Ignjatic, et al.            Standards Track                     [Page 2]
+
+RFC 4738                      MIKEY-RSA-R                  November 2006
+
+
+1.  Introduction
+
+   The MIKEY protocol [RFC3830] has three different methods for key
+   transport or exchange: a pre-shared key mode (PSK), a public-key
+   (RSA) mode, and an optional Diffie-Hellman exchange (DHE) mode.  In
+   addition, there is also an optional DH-HMAC mode [RFC4650], bringing
+   the total number of modes to four.  The primary motivation for the
+   MIKEY protocol design is low-latency requirements of real-time
+   communication, and thus all the exchanges finish in one-half to 1
+   roundtrip; note that this offers no room for security parameter
+   negotiation of the key management protocol itself.  In this document,
+   we note that the MIKEY modes defined in [RFC3830] and [RFC4650] are
+   insufficient to address some deployment scenarios and common use
+   cases, and we propose a new mode called MIKEY-RSA in Reverse mode, or
+   simply MIKEY-RSA-R.  This document updates RFC 3830 with the addition
+   of this new mode to that specification.
+
+1.1.  Terminology Used in This Document
+
+   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 BCP 14, RFC 2119
+   [RFC2119].
+
+   Furthermore, this document reuses the terminology of the MIKEY
+   specification [RFC3830].
+
+2.  Motivation
+
+   As noted in the introduction, the MIKEY specification and other
+   proposals define four different modes of efficient key management for
+   real-time applications.  Those modes differ from each other in either
+   the authentication method of choice (public-key, or symmetric shared
+   key-based), or the key establishment method of choice (key download,
+   or key agreement using a Diffie-Hellman exchange).  We summarize
+   these modes below, including their advantages and shortcomings.  We
+   then discuss the use cases where these modes are unusable or
+   inefficient.
+
+2.1.  Description of the MIKEY Modes
+
+   The PSK mode requires that the Initiator and the Responder have a
+   common secret key established offline.  In this mode, the Initiator
+   selects a TEK Generation Key (TGK), encrypts it with a key derived
+   from the PSK, and sends it to the Responder as part of the first
+   message, namely, I_MESSAGE.  The I_MESSAGE is replay protected with
+   timestamps, and integrity protected with another key derived from the
+   PSK.  An optional Verification message from the Responder to the
+
+
+
+Ignjatic, et al.            Standards Track                     [Page 3]
+
+RFC 4738                      MIKEY-RSA-R                  November 2006
+
+
+   Initiator provides mutual authentication.  This mode does not scale
+   well as it requires pre-establishment of a shared key between
+   communicating parties; for example, consider the use cases where any
+   user may want to communicate to any other user in an Enterprise or
+   the Internet at large.  The RSA mode might be more suitable for such
+   applications.
+
+   In the RSA mode, the Initiator selects a TGK, encrypts and
+   authenticates it with an envelope key, and sends it to the Responder
+   as part of the I_MESSAGE.  The Initiator includes the envelope key,
+   encrypted with the Responder's public key, in the I_MESSAGE.  The
+   I_MESSAGE is replay protected with timestamps, and signed with the
+   Initiator's public key.  The Initiator's ID, Certificate (CERT), and
+   the Responder's ID may be included in the I_MESSAGE.  If the
+   Initiator knows several public keys of the Responder, it can indicate
+   the key used in the optional CHASH payload.  An optional Verification
+   message from the Responder to the Initiator provides mutual
+   authentication.  The RSA mode works well if the Initiator knows the
+   Responder's ID and the corresponding CERT (or can obtain the CERT
+   independent of the MIKEY protocol).  RFC 3830 suggests that an
+   Initiator, in the event that it does not have the Responder's CERT,
+   may obtain the CERT from a directory agent using one or more
+   roundtrips.  However, in some cases, the Initiator may not even know
+   the Responder's ID in advance, and because of that or for other
+   reasons cannot obtain the Responder's CERT.
+
+   In addition to the case where the Responder may have several IDs,
+   some applications may allow for the Responder's ID to change
+   unilaterally, as is typical in telephony (e.g., forwarding).  In
+   those cases and in others, the Initiator might be willing to let the
+   other party establish identity and prove it via an Initiator-trusted
+   third party (e.g., a Certification Authority (CA)).
+
+   The DH mode or the DH-HMAC mode of MIKEY might be useful in cases
+   where the Initiator does not have access to the Responder's exact
+   identity and/or CERT.  In these modes, the two parties engage in an
+   authenticated DH exchange to derive the TGK.  On the downside, the DH
+   modes have higher computational and communication overhead compared
+   to the RSA and the PSK modes.  More importantly, these modes are
+   unsuitable for group key distribution.  The DH-HMAC mode also
+   requires establishment of PSKs between all possible communicating
+   entities and thus has similar scaling issues as any PSK-based key
+   management protocol.
+
+   In summary, in some communication scenarios -- where the Initiator
+   might not have the correct ID and/or the CERT of the Responder --
+   none of the MIKEY modes described in [RFC3830] or [RFC4650] are
+   suitable and efficient for multimedia session key establishment.
+
+
+
+Ignjatic, et al.            Standards Track                     [Page 4]
+
+RFC 4738                      MIKEY-RSA-R                  November 2006
+
+
+2.2.  Use Case Motivating the Proposed Mode
+
+   In addition to the issues listed above, there are some types of
+   applications that motivate the new MIKEY mode design proposed in this
+   document.
+
+   Note that in the MIKEY-RSA mode (as in case of the PSK mode), the
+   Initiator proposes the session security policy and chooses the TGK.
+   However, it is also possible that the Initiator wants to allow the
+   Responder to specify the security policy and send the TGK.  Consider
+   for example, the case of a conferencing scenario where the convener
+   sends an invitation to a group of people to attend a meeting.  The
+   procedure then might be for the invitees to request group key
+   material from the convener by sending a MIKEY I_MESSAGE.  Thus, in
+   the MIKEY definition of initiators and responders, the Initiator is
+   asking the Responder for keying material.  Note that this mode of
+   operation is in line with the MSEC group key management architecture
+   [RFC4046].
+
+3.  A New MIKEY-RSA Mode: MIKEY-RSA-R
+
+3.1.  Outline
+
+   The proposed MIKEY mode requires 1 full roundtrip.  The Initiator
+   sends a signed I_MESSAGE to the intended Responder requesting the
+   Responder to send the traffic keying material.  The I_MESSAGE MAY
+   contain the Initiator's CERT or a link (URL) to the CERT, and
+   similarly the Responder's reply, R_MESSAGE, MAY contain the
+   Responder's CERT or a link to it.  The Responder can use the
+   Initiator's public key from the CERT in the I_MESSAGE to send the
+   encrypted TGK in the R_MESSAGE.  Upon receiving the R_MESSAGE, the
+   Initiator can use the CERT in the R_MESSAGE to verify whether the
+   Responder is in fact the party that it wants to communicate to, and
+   accept the TGK.  We refer to this protocol as MIKEY-RSA in the
+   reverse mode, or simply as MIKEY-RSA-R.
+
+   The MIKEY-RSA-R mode exchange is defined as follows:
+
+   Initiator                                            Responder
+   ---------                                            ---------
+
+   I_MESSAGE = HDR, T, [RAND], [IDi|CERTi], [IDr], {SP}, SIGNi
+
+   R_MESSAGE = HDR, [GenExt(CSB_ID)], T, [RAND], [IDr|CERTr], [SP],
+               KEMAC, PKE, SIGNr
+
+                    Figure 1: MIKEY-RSA-R Unicast Mode
+
+
+
+
+Ignjatic, et al.            Standards Track                     [Page 5]
+
+RFC 4738                      MIKEY-RSA-R                  November 2006
+
+
+3.2.  Group Communication Using the MIKEY RSA-R Mode
+
+   For group conferencing using MIKEY RSA-R mode, the members receive an
+   invitation to initiate MIKEY with the group key server to download
+   the secure session information.  In this case, the Responder is
+   either the group sender or group key server.  Group members request
+   group policy and keying material as MIKEY RSA-R Initiators.
+   Initiators MUST NOT send the SP payload.  The Responder sends all the
+   payloads necessary to distribute the secure group policy as well as
+   payloads used in the group key derivation: specifically, the SP
+   payload is used to convey the session policy, and the GenExt(CSB-ID),
+   TGK, and the RAND payloads selected by the Responder and included in
+   the R_Message are used to compute the Secure Realtime Transport
+   Protocol (SRTP) session keys.
+
+   MIKEY RSA-R for group communication:
+
+   Initiator                                            Responder
+   ---------                                            ---------
+
+   I_MESSAGE = HDR, T, [RAND], [IDi|CERTi], [IDr],  SIGNi
+
+   R_MESSAGE = HDR, GenExt(CSB_ID), T, RAND, [IDr|CERTr], SP,
+               KEMAC, PKE, SIGNr
+
+                    Figure 2: MIKEY-RSA-R in Group Mode
+
+   Note that the SP payload in the I_MESSAGE is not present.  In the
+   R_MESSAGE, the CSB_ID, RAND, and SP payloads are not optional.
+
+3.3.  Preparing RSA-R Messages
+
+   Preparation and parsing of RSA-R messages are as described in
+   Sections 5.2 and 5.3 of RFC 3830.  Error handling is described in
+   Section 5.1.2 and replay protection guidelines are in Section 5.4 of
+   RFC 3830.  In the following, we describe the components of RSA-R
+   messages and specify message processing and parsing rules in addition
+   to those in RFC 3830.
+
+3.4.  Components of the I_MESSAGE
+
+   MIKEY-RSA-R requires a full roundtrip to download the TGKs.  The
+   I_MESSAGE MUST have the MIKEY HDR and the timestamp payload for
+   replay protection.  The HDR field contains a CSB_ID (Crypto Session
+   Bundle ID) randomly selected by the Initiator.  The V bit MUST be set
+   to '1' and ignored by the Responder, as a response is MANDATORY in
+   this mode.  The Initiator SHOULD indicate the number of CSs
+   supported, and SHOULD fill in the CS ID map type and CS ID info
+
+
+
+Ignjatic, et al.            Standards Track                     [Page 6]
+
+RFC 4738                      MIKEY-RSA-R                  November 2006
+
+
+   fields for the RTP/RTCP streams it originates.  This is because the
+   sender of the streams chooses the SSRC that is carried in the CS ID
+   info field; see Section 6.1.1 of RFC 3830.  The exception to
+   Initiators not specifying SSRC values is to allow the Responder to
+   pick them to avoid SSRC collisions.  Initiators of MIKEY messages
+   that do not originate RTP streams MUST specify a '0' as the number of
+   CSs supported.  This typically applies to group communication and to
+   the entities in the listen-only mode.
+
+   The I_MESSAGE MUST be signed by the Initiator following the procedure
+   to sign MIKEY messages specified in RFC 3830.  The SIGNi payload
+   contains this signature.  Thus, the I_MESSAGE is integrity and replay
+   protected.
+
+   The RAND payload SHOULD be included in the I_MESSAGE when MIKEY-RSA-R
+   mode is used for unicast communication.  The reason for recommending
+   the inclusion of the RAND payload in the I_MESSAGE for unicast
+   communication is to allow the Initiator to contribute entropy to the
+   key derivation process (in addition to the CSB_ID).  When the RAND
+   payload is not included, the Initiator will be relying on the
+   Responder to supply all the entropy for SRTP key generation, which is
+   in fact similar (but with the reversal of roles) to the MIKEY-RSA
+   mode, where the Responder supplies all the entropy.
+
+   The RAND payload MAY be included when MIKEY-RSA-R is used to
+   establish group keys.  However, the RAND payload in the I_MESSAGE
+   MUST NOT be used for MIKEY key generation, in case of group
+   communication.  The Responder MUST include a RAND payload in the
+   R_MESSAGE for TEK generation from a TGK when MIKEY-RSA-R is used for
+   group communication.
+
+   IDi and CERTi SHOULD be included, but they MAY be left out when it is
+   expected that the peer already knows the Initiating party's ID (or
+   can obtain the certificate in some other manner).  For example, this
+   could be the case if the ID is extracted from SIP.  For certificate
+   handling, authorization, and policies, see Sections 4.3 and 6.7 of
+   RFC 3830.  If CERTi is included, it MUST correspond to the private
+   key used to sign the I_MESSAGE.
+
+   If the Responder has multiple identities, the Initiator MAY also
+   include the specific identity, IDr, of the Responder with whom
+   communication is desired.  If the Initiator's policy does not allow
+   acceptance of an R_MESSAGE from any entity other than one that can
+   assert a specific identity, the Initiator MUST include that specific
+   identity in an IDr payload in the I_MESSAGE.
+
+
+
+
+
+
+Ignjatic, et al.            Standards Track                     [Page 7]
+
+RFC 4738                      MIKEY-RSA-R                  November 2006
+
+
+   The Initiator MAY also send security policy (SP) payload(s)
+   containing all the security policies that it supports.  If the
+   Responder does not support any of the policies included, it SHOULD
+   reply with an Error message of type "Invalid SPpar" (Error no. 10).
+   The Responder has the option not to send the Error message in MIKEY
+   if a generic session establishment failure indication is deemed
+   appropriate and communicated via other means (see Section 4.1.2 of
+   [RFC4567] for additional guidance).
+
+   SIGNi is a signature covering the Initiator's MIKEY message,
+   I_MESSAGE, using the Initiator's signature key (see Section 5.2 of
+   RFC 3830 for the exact definition).  The signature assures the
+   Responder that the claimed Initiator has indeed generated the
+   message.  This automatically provides message integrity as well.
+
+3.5.  Processing the I_MESSAGE
+
+   Upon receiving an I_MESSAGE of the RSA-R format, the Responder MUST
+   respond with one of the following messages:
+
+   o  The Responder SHOULD send an Error message "Message type not
+      supported" (Error no. 13), if it cannot correctly parse the
+      received MIKEY message.  Error message format is as specified in
+      Section 5.1.2 of RFC 3830.  Error no. 13 is not defined in RFC
+      3830, and so RFC 3830 compliant implementations MAY return "an
+      unspecified error occurred" (Error no. 12).
+
+   o  The Responder MUST send an R_MESSAGE, if SIGNi can be correctly
+      verified and the timestamp is current; if an SP payload is present
+      in the I_MESSAGE the Responder MUST return one of the proposed
+      security policies that matches the Responder's local policy.
+
+   o  If a RAND payload is present in the I_MESSAGE, both sides use that
+      RAND payload as the RAND value in the MIKEY key computation.  In
+      case of multicast, if a RAND payload is present in the I_MESSAGE,
+      the Responder SHOULD ignore the payload.  In any case, the
+      R_MESSAGE for multicast communication MUST contain a RAND payload
+      and that RAND payload is used for key computation.
+
+   o  The rest of the error message rules are as described in Section
+      5.1.2 of RFC 3830, and message processing rules are as described
+      in Section 5.3 of RFC 3830.
+
+
+
+
+
+
+
+
+
+Ignjatic, et al.            Standards Track                     [Page 8]
+
+RFC 4738                      MIKEY-RSA-R                  November 2006
+
+
+3.6.  Components of the R_MESSAGE
+
+   The HDR payload in the R_MESSAGE is formed following the procedure
+   described in RFC 3830.  Specifically, the CSB_ID in the HDR payload
+   MUST be the same as the one in the HDR of the I_MESSAGE.  The
+   Responder MUST fill in the number of CSs and the CS ID map type and
+   CS ID info fields of the HDR payload.
+
+   For group communication, all the members MUST use the same CSB_ID and
+   CS ID in computing the traffic keying material.  Therefore, for group
+   key establishment, the Responder MUST include a General Extension
+   Payload containing a new CSB_ID in the R_MESSAGE.  If a new CSB_ID is
+   present in the R_MESSAGE, the Initiator and the Responder MUST use
+   that value in key material computation.  Furthermore, the CS ID map
+   type and CS ID map info MUST be populated by the Responder.  The
+   General Extension Payload carrying a CSB_ID MUST NOT be present in
+   case of unicast communication.
+
+   The T payload is exactly the same as that received in the I_MESSAGE.
+
+   If the I_MESSAGE did not include the RAND payload, it MUST be present
+   in the R_MESSAGE.  In case it has been included in the I_MESSAGE, it
+   MUST NOT be present in the R_MESSAGE.  In group communication, the
+   Responder always sends the RAND payload and in unicast communication,
+   either the Initiator or the Responder (but not both) generate and
+   send the RAND payload.
+
+   IDr and CERTr SHOULD be included, but they MAY be left out when it
+   can be expected that the peer already knows the other party's ID (or
+   can obtain the certificate in some other manner).  For example, this
+   could be the case if the ID is extracted from SIP.  For certificate
+   handling, authorization, and policies, see Section 4.3. of RFC 3830.
+   If CERTr is included, it MUST correspond to the private key used to
+   sign the R_MESSAGE.
+
+   An SP payload MAY be included in the R_MESSAGE.  If an SP payload was
+   in the I_MESSAGE, then the R_MESSAGE MUST contain an SP payload
+   specifying the security policies of the secure RTP session being
+   negotiated.  More specifically, the Initiator may have provided
+   multiple options, but the Responder MUST choose one option per
+   Security Policy Parameter.
+
+   The KEMAC payload contains a set of encrypted sub-payloads and a MAC:
+   KEMAC = E(encr_key, IDr || {TGK}) || MAC.  The first payload (IDr) in
+   KEMAC is the identity of the Responder (not a certificate, but
+   generally the same ID as the one specified in the certificate).  Each
+   of the following payloads (TGK) includes a TGK randomly and
+   independently chosen by the Responder (and possible other related
+
+
+
+Ignjatic, et al.            Standards Track                     [Page 9]
+
+RFC 4738                      MIKEY-RSA-R                  November 2006
+
+
+   parameters, e.g., the key lifetime).  The encrypted part is then
+   followed by a MAC, which is calculated over the KEMAC payload.  The
+   encr_key and the auth_key are derived from the envelope key, env_key,
+   as specified in Section 4.1.4. of RFC 3830.  The payload definitions
+   are specified in Section 6.2 of RFC 3830.
+
+   The Responder encrypts and integrity protects the TGK with keys
+   derived from a randomly or pseudo-randomly chosen envelope key, and
+   encrypts the envelope key itself with the public key of the
+   Initiator.  The PKE payload contains the encrypted envelope key,
+   env_key: PKE = E(PKi, env_key).  PKi denotes the Initiator's public
+   key.  Note that, as suggested in RFC 3830, the envelope key MAY be
+   cached and used as the PSK for re-keying.
+
+   To compute the signature that goes in the SIGNr payload, the
+   Responder MUST sign:
+
+   R_MESSAGE (excluding the SIGNr payload itself) || IDi || IDr || T.
+
+   Note that the added identities and timestamp are identical to those
+   transported in the ID and T payloads.
+
+3.7.  Processing the R_MESSAGE
+
+   In addition to the processing rules in RFC 3830, the following rules
+   apply to processing of the R_MESSAGE of MIKEY RSA-R mode.
+
+      If the I_MESSAGE contained a RAND payload, the Initiator MUST
+      silently discard an R_MESSAGE that contains a RAND payload.
+      Similarly, if the I_MESSAGE did not contain a RAND payload, the
+      Initiator MUST silently discard an R_MESSAGE that does not contain
+      a RAND payload.
+
+      If the SP payload contains a policy not specified in the SP
+      message, if present, in the I_MESSAGE, such an R_MESSAGE MUST be
+      discarded silently.
+
+3.8.  Certificate Handling
+
+   If a Certificate payload is present, the X.509v3 URL Cert type from
+   Table 6.7.b [RFC3830] is the default method in RSA-R mode and MUST be
+   implemented.  The HTTP URL to fetch a certificate as specified in RFC
+   2585 [RFC2585] MUST be supported.  Devices are not required to
+   support the FTP URLs.  When retrieving data from the URL,
+   application/pkix-cert MIME type with X.509 certificates DER-encoded
+   MUST be supported.
+
+
+
+
+
+Ignjatic, et al.            Standards Track                    [Page 10]
+
+RFC 4738                      MIKEY-RSA-R                  November 2006
+
+
+   The RECOMMENDED way of doing certificate validation is by using OCSP
+   as specified by RFC 2560 [RFC2560].  When OCSP is used and nextUpdate
+   time is present in the response, it defines how long the certificate
+   can be considered valid and cached.  If OCSP is not supported or
+   nextUpdate time is not present in the response, the certificate cache
+   timeout is a matter of local policy.
+
+   The communicating peers (such as SIP User Agents for instance) MAY
+   choose to create a URL pointing to certificate files residing on
+   themselves or by appending their ID and a ".cer" extension to a
+   provisioned root path to the certificate.  Other methods MAY also be
+   used, subject to local policy.
+
+3.9.  Additions to RFC 3830 Message Types and Other Values
+
+   This document introduces two new message types (Table 6.1a of RFC
+   3830), an Error no (Table 6.12 of RFC 3830), and a general extension
+   payload (Table 6.15 of RFC 3830).  This section specifies those
+   additions.
+
+3.9.1.  Modified Table 6.1a from RFC 3830
+
+   Modified Table 6.1a from RFC 3830:
+
+
+   Data type   | Value |                           Comment
+   ------------------------------------------------------------------
+   Pre-shared  |   0   | Initiator's pre-shared key message
+   PSK ver msg |   1   | Verification message of a Pre-shared key msg
+   Public key  |   2   | Initiator's public-key transport message
+   PK ver msg  |   3   | Verification message of a public-key message
+   D-H init    |   4   | Initiator's DH exchange message
+   D-H resp    |   5   | Responder's DH exchange message
+   Error       |   6   | Error message
+   DHHMAC init |   7   | DH HMAC message 1
+   DHHMAC resp |   8   | DH HMAC message 2
+   RSA-R I_MSG |   9   | Initiator's RSA-R public-key message (NEW)
+   RSA-R R_MSG |   10  | Responder's RSA-R public-key message (NEW)
+
+               Figure 3: Table 6.1a from RFC 3830 (Revised)
+
+
+
+
+
+
+
+
+
+
+
+Ignjatic, et al.            Standards Track                    [Page 11]
+
+RFC 4738                      MIKEY-RSA-R                  November 2006
+
+
+3.9.2.  Modified Table 6.12 from RFC 3830
+
+   Modified Table 6.12 from RFC 3830:
+
+         Error no          | Value | Comment
+         -------------------------------------------------------
+         Auth failure      |     0 | Authentication failure
+         Invalid TS        |     1 | Invalid timestamp
+         Invalid PRF       |     2 | PRF function not supported
+         Invalid MAC       |     3 | MAC algorithm not supported
+         Invalid EA        |     4 | Encryption algorithm not supported
+         Invalid HA        |     5 | Hash function not supported
+         Invalid DH        |     6 | DH group not supported
+         Invalid ID        |     7 | ID not supported
+         Invalid Cert      |     8 | Certificate not supported
+         Invalid SP        |     9 | SP type not supported
+         Invalid SPpar     |    10 | SP parameters not supported
+         Invalid DT        |    11 | not supported Data type
+         Unspecified error |    12 | an unspecified error occurred
+         Unsupported       |       |
+          message type     |    13 | unparseable MIKEY message (NEW)
+
+
+               Figure 4: Table 6.12 from RFC 3830 (Revised)
+
+3.9.3.  Modified Table 6.15 from RFC 3830
+
+   Modified Table 6.15 from RFC 3830:
+
+     Type       | Value | Comments
+     ---------------------------------------
+     Vendor ID  |     0 | Vendor specific byte string
+     SDP IDs    |     1 | List of SDP key mgmt IDs (allocated for use in
+                |       |   [RFC4567])
+     TESLA I-Key|     2 |   [RFC4442]
+     Key ID     |     3 | information on type and identity of keys
+                |       |   [RFC4563])
+     CSB_ID     |     4 | Responder's modified CSB_ID (group mode)
+
+               Figure 5: Table 6.15 from RFC 3830 (Revised)
+
+
+
+
+
+
+
+
+
+
+
+Ignjatic, et al.            Standards Track                    [Page 12]
+
+RFC 4738                      MIKEY-RSA-R                  November 2006
+
+
+4.  Applicability of the RSA-R and RSA Modes
+
+   MIKEY-RSA-R mode and RSA mode are both very useful: deciding on which
+   mode to use depends on the application.
+
+   The RSA-R mode is useful when you have reasons to believe that the
+   Responder may be a different party than the one to which the MIKEY
+   I_MESSAGE was sent.  This is quite common in telephony and multimedia
+   applications where the session or the call can be retargeted or
+   forwarded.  When the security policy allows it, leaving some
+   flexibility for the Initiator to see who the Responder may turn out
+   to be, before making the decision to continue or discontinue the
+   session, may be appropriate.  In such cases, the main objective of
+   the Initiator's RSA-R message is to present its public key/
+   certificate to the Responder, and wait for a Responder to present its
+   identity.
+
+   The second scenario is when the Initiator already has the Responder's
+   certificate but wants to allow the Responder to come up with all the
+   keying material.  This is applicable in conferences where the
+   Responder is the key distributor and the Initiators contact the
+   Responder to initiate key download.  Notice that this is quite
+   similar to the group key download model as specified in GDOI
+   [RFC3547], GSAKMP [RFC4535], and GKDP [GKDP] protocols (also see
+   [RFC4046]).  The catch, however, is that the participating entities
+   must know that they need to contact a well-known address as far as
+   that conferencing group is concerned.  Note that they only need the
+   Responder's address, not necessarily its CERT.  If the group members
+   have the Responder's CERT, there is no harm; they simply do not need
+   the CERT to compose the I_MESSAGE.
+
+   The RSA mode is useful when the Initiator knows the Responder's
+   identity and CERT.  This mode is also useful when the key exchange is
+   happening in an established session with a Responder (for example,
+   when switching from a non-secure mode to a secure mode), and when the
+   policy is such that it is only appropriate to establish a MIKEY
+   session with the Responder that is targeted by the Initiator.
+
+4.1.  Limitations
+
+   The RSA-R mode may not easily support 3-way calling, under the
+   assumptions that motivated the design.  An extra message may be
+   required compared to the MIKEY-RSA mode specified in RFC 3830.
+   Consider that A wants to talk to B and C, but does not have B's or
+   C's CERT.  A might contact B and request that B supply a key for a
+   3-way call.  Now if B knows C's CERT, then B can simply use the
+   MIKEY-RSA mode (as defined in RFC 3830) to send the TGK to C.  If
+   not, then the solution is not straightforward.  For instance, A might
+
+
+
+Ignjatic, et al.            Standards Track                    [Page 13]
+
+RFC 4738                      MIKEY-RSA-R                  November 2006
+
+
+   ask C to contact B or itself to get the TGK, in effect initiating a
+   3-way exchange.  It should be noted that 3-way calling is typically
+   implemented using a bridge, in which case there are no issues (it
+   looks like 3 point-to-point sessions, where one end of each session
+   is a bridge mixing the traffic into a single stream).
+
+5.  Security Considerations
+
+   We offer a brief overview of the security properties of the exchange.
+   There are two messages: the I_MESSAGE and the R_MESSAGE.  The
+   I_MESSAGE is a signed request by an Initiator requesting the
+   Responder to select a TGK to be used to protect multimedia (e.g.,
+   Secure RTP or SRTP [RFC3711]) sessions.
+
+   The message is signed, which assures the Responder that the claimed
+   Initiator has indeed generated the message.  This automatically
+   provides message integrity as well.
+
+   There is a timestamp in the I_MESSAGE, which when generated and
+   interpreted in the context of the MIKEY specification assures the
+   Responder that the request is live and not a replay.  Indirectly,
+   this also provides protection against a denial of service (DoS)
+   attack in that the I_MESSAGE must itself be signed.  The Responder,
+   however, would have to verify the Initiator's signature and the
+   timestamp, and thus would spend significant computing resources.  It
+   is possible to mitigate this by caching recently received and
+   verified requests.
+
+   Note that the I_MESSAGE in this method basically equals DoS
+   protection properties of the DH method and not the public-key method
+   as there are no payloads encrypted by the Responder's public key in
+   the I_MESSAGE.  If IDr is not included in the I_MESSAGE, the
+   Responder will accept the message and a response (and state) would be
+   created for the malicious request.
+
+   The R_MESSAGE is quite similar to the I_MESSAGE in the MIKEY-RSA mode
+   and has all the same security properties.
+
+   When using the RSA-R mode, the Responder may be a different party
+   than the one to which the MIKEY I_MESSAGE was sent.  It is the
+   responsibility of the Initiator to verify that the identity of the
+   Responder is acceptable (based on its local policy) if it changes
+   from the party to which the MIKEY I_MESSAGE was sent, and to take
+   appropriate action based on the outcome.  In some cases, it could be
+   appropriate to accept a Responder's identity if it can be strongly
+   authenticated; in other cases, a blacklist or a whitelist may be
+   appropriate.
+
+
+
+
+Ignjatic, et al.            Standards Track                    [Page 14]
+
+RFC 4738                      MIKEY-RSA-R                  November 2006
+
+
+   When both unicast and multicast streams need to be negotiated, it is
+   RECOMMENDED to use multiple instances of MIKEY-RSA-R rather than a
+   single instance in group mode.  This is to avoid potential key reuse
+   with counter mode.
+
+5.1.  Impact of the Responder Choosing the TGK
+
+   In the MIKEY-RSA or PSK modes, the Initiator chooses the TGK, and the
+   Responder has the option to accept the key or not.  In the RSA-R mode
+   for unicast communication, the RECOMMENDED mode of operation is for
+   the Initiator and the Responder to contribute random information in
+   generating the TEK (RAND from the Initiator and the TGK from the
+   Responder).  For group communication, the sender (MIKEY Responder)
+   will choose the TGK and the RAND; note that it is in the interest of
+   the sender to provide sufficient entropy to TEK generation since the
+   TEK protects data sent by the Responder.
+
+   Thus, in case of unicast communication, the RSA-R mode is slightly
+   better than the RSA mode in that it allows the Initiator as well as
+   the Responder to contribute entropy to the TEK generation process.
+   This comes at the expense of the additional message.  However, as
+   noted earlier, the new mode needs the additional message to allow
+   simpler provisioning.
+
+5.2.  Updates to Security Considerations in RFC 3830
+
+   MIKEY requires clock synchronization, and a secure network clock
+   synchronization protocol SHOULD be used, e.g., [ISO3] or secure NTP
+   [NTPv4].
+
+   RFC 3830 has additional notes on the security properties of the MIKEY
+   protocol, key derivation functions, and other components.
+
+6.  IANA Considerations
+
+   The following IANA assignments were added to the MIKEY registry:
+
+      Added to "Error payload name spaces:"
+
+         Unsupported message type ------- 13
+
+      Added to "Common Header payload name spaces:"
+
+         RSA-R I_MSG ------------- 9
+         RSA-R R_MSG ------------- 10
+
+
+
+
+
+
+Ignjatic, et al.            Standards Track                    [Page 15]
+
+RFC 4738                      MIKEY-RSA-R                  November 2006
+
+
+      Added to "General Extensions payload name spaces:"
+
+         CSB_ID ----------------- 4
+
+7.  Acknowledgments
+
+   Many thanks to Mark Baugher, Steffen Fries, Russ Housley, Cullen
+   Jennings, and Vesa Lehtovirta for their reviews of earlier version of
+   this document.
+
+8.  References
+
+8.1.  Normative References
+
+   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
+              Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+   [RFC2560]  Myers, M., Ankney, R., Malpani, A., Galperin, S., and C.
+              Adams, "X.509 Internet Public Key Infrastructure Online
+              Certificate Status Protocol - OCSP", RFC 2560, June 1999.
+
+   [RFC2585]  Housley, R. and P. Hoffman, "Internet X.509 Public Key
+              Infrastructure Operational Protocols: FTP and HTTP",
+              RFC 2585, May 1999.
+
+   [RFC3830]  Arkko, J., Carrara, E., Lindholm, F., Naslund, M., and K.
+              Norrman, "MIKEY: Multimedia Internet KEYing", RFC 3830,
+              August 2004.
+
+8.2.  Informative References
+
+   [RFC3547]  Baugher, M., Weis, B., Hardjono, T., and H. Harney, "The
+              Group Domain of Interpretation", RFC 3547, July 2003.
+
+   [RFC3711]  Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K.
+              Norrman, "The Secure Real-time Transport Protocol (SRTP)",
+              RFC 3711, March 2004.
+
+   [RFC4046]  Baugher, M., Canetti, R., Dondeti, L., and F. Lindholm,
+              "Multicast Security (MSEC) Group Key Management
+              Architecture", RFC 4046, April 2005.
+
+   [RFC4650]  Euchner, M., "HMAC-Authenticated Diffie-Hellman for
+              Multimedia Internet KEYing (MIKEY)", RFC 4650, September
+              2006.
+
+
+
+
+
+
+Ignjatic, et al.            Standards Track                    [Page 16]
+
+RFC 4738                      MIKEY-RSA-R                  November 2006
+
+
+   [RFC4535]  Harney, H., Meth, U., Colegrove, A., and G. Gross,
+              "GSAKMP:  Group Secure Association Key Management
+              Protocol", RFC 4535, June 2006.
+
+   [GKDP]     Dondeti, L., "GKDP: Group Key Distribution Protocol", Work
+              in Progress, March 2006.
+
+   [RFC4567]  Arkko, J., Lindholm, F., Naslund, M., Norrman, K., and E.
+              Carrara, "Key Management Extensions for Session
+              Description Protocol (SDP) and Real Time Streaming
+              Protocol (RTSP)", RFC 4567, July 2006.
+
+   [RFC4442]  Fries, S. and H. Tschofenig, "Bootstrapping Timed
+              Efficient Stream Loss-Tolerant Authentication (TESLA)",
+              RFC 4442, March 2006.
+
+   [RFC4563]  Carrara, E., Lehtovirta, V., and K. Norrman, "The Key ID
+              Information Type for the General Extension Payload in
+              Multimedia Internet KEYing (MIKEY)", RFC 4563, June 2006.
+
+   [NTPv4]    Burbank, J., "The Network Time Protocol Version 4 Protocol
+              Specification", Work in Progress, May 2006.
+
+   [ISO3]     ISO, "ISO/IEC 18014 Information technology - Security
+              techniques - Time-stamping services, Part 1-3", 2002.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Ignjatic, et al.            Standards Track                    [Page 17]
+
+RFC 4738                      MIKEY-RSA-R                  November 2006
+
+
+Authors' Addresses
+
+   Dragan Ignjatic
+   Polycom
+   1000 W. 14th Street
+   North Vancouver, BC  V7P 3P3
+   Canada
+
+   Phone: +1 604 982 3424
+   EMail: dignjatic@polycom.com
+
+
+   Lakshminath Dondeti
+   QUALCOMM
+   5775 Morehouse drive
+   San Diego, CA  92121
+   US
+
+   Phone: +1 858 845 1267
+   EMail: ldondeti@qualcomm.com
+
+
+   Francois Audet
+   Nortel
+   4655 Great America Parkway
+   Santa Clara, CA  95054
+   US
+
+   Phone: +1 408 495 3756
+   EMail: audet@nortel.com
+
+
+   Ping Lin
+   Nortel
+   250 Sidney St.
+   Belleville, Ontario  K8P3Z3
+   Canada
+
+   Phone: +1 613 967 5343
+   EMail: linping@nortel.com
+
+
+
+
+
+
+
+
+
+
+
+Ignjatic, et al.            Standards Track                    [Page 18]
+
+RFC 4738                      MIKEY-RSA-R                  November 2006
+
+
+Full Copyright Statement
+
+   Copyright (C) The IETF Trust (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, THE IETF TRUST,
+   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 currently provided by the
+   Internet Society.
+
+
+
+
+
+
+Ignjatic, et al.            Standards Track                    [Page 19]
+