GENWiki

Premier IT Outsourcing and Support Services within the UK

User Tools

Site Tools


rfc:rfc4738

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]

/data/webs/external/dokuwiki/data/pages/rfc/rfc4738.txt · Last modified: 2006/11/04 04:54 by 127.0.0.1

Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki