tech-invite   World Map     

IETF     RFCs     Groups     SIP     ABNFs    |    3GPP     Specs     Gloss.     Arch.     IMS     UICC    |    Misc.    |    search     info

RFC 3830


MIKEY: Multimedia Internet KEYing

Part 4 of 4, p. 50 to 66
Prev RFC Part


prevText      Top      Up      ToC       Page 50 
7.  Transport protocols

   MIKEY MAY be integrated within session establishment protocols.
   Currently, integration of MIKEY within SIP/SDP and RTSP is defined in
   [KMASDP].  MIKEY MAY use other transports, in which case how MIKEY is
   transported over such a transport protocol has to be defined.

8.  Groups

   What has been discussed up to now is not limited to single peer-to-
   peer communication (except for the DH method), but can be used to
   distribute group keys for small-size interactive groups and simple
   one-to-many scenarios.  Section 2.1. describes the scenarios in the
   focus of MIKEY.  This section describes how MIKEY is used in a group
   scenario (though, see also Section 4.3 for issues related to

Top      Up      ToC       Page 51 
8.1.  Simple one-to-many

                            |S |
                            |  |
                      --------+-------------- - -
                      |       |      |
                      v       v      v
                    ++++    ++++   ++++
                    |A |    |B |   |C |
                    |  |    |  |   |  |
                    ++++    ++++   ++++

   Figure 8.1. Simple one-to-many scenario.

   In the simple one-to-many scenario, a server is streaming to a small
   group of clients.  RTSP or SIP is used for the registration and the
   key management set up.  The streaming server acts as the Initiator of
   MIKEY.  In this scenario, the pre-shared key or public key transport
   mechanism will be appropriate in transporting the same TGK to all the
   clients (which will result in common TEKs for the group).

   Note, if the same TGK/TEK(s) should be used by all the group members,
   the streaming server MUST specify the same CSB_ID and CS_ID(s) for
   the session to all the group members.

   As the communication may be performed using multicast, the members
   need a common security policy if they want to be part of the group.
   This limits the possibility of negotiation.

   Furthermore, the Initiator should carefully consider whether to
   request the verification message in reply from each receiver, as this
   may result in a certain load for the Initiator itself as the group
   size increases.

8.2.  Small-size interactive group

   As described in the overview section, for small-size interactive
   groups, one may expect that each client will be in charge for setting
   up the security for its outgoing streams.  In these scenarios, the
   pre-shared key or the public-key transport method is used.

Top      Up      ToC       Page 52 
                       ++++          ++++
                       |A | -------> |B |
                       |  | <------- |  |
                       ++++          ++++
                        ^ |          | ^
                        | |          | |
                        | |   ++++   | |
                        | --->|C |<--- |
                        ------|  |------

   Figure 8.2. Small-size group without a centralized controller.

   One scenario may then be that the client sets up a three-part call,
   using SIP.  Due to the small size of the group, unicast SRTP is used
   between the clients.  Each client sets up the security for its
   outgoing stream(s) to the others.

   As for the simple one-to-many case, the streaming client specifies
   the same CSB_ID and CS_ID(s) for its outgoing sessions if the same
   TGK/TEK(s) is used for all the group members.

9.  Security Considerations

9.1.  General

   Key management protocols based on timestamps/counters and one-
   roundtrip key transport have previously been standardized, for
   example ISO [ISO1, ISO2].  The general security of these types of
   protocols can be found in various articles and literature, c.f. [HAC,
   AKE, LOA].

   No chain is stronger than its weakest link.  If a given level of
   protection is wanted, then the cryptographic functions protecting the
   keys during transport/exchange MUST offer a security corresponding to
   at least that level.

   For instance, if a security against attacks with a complexity 2^96 is
   wanted, then one should choose a secure symmetric cipher supporting
   at least 96 bit keys (128 bits may be a practical choice) for the
   actual media protection, and a key transport mechanism that provides
   equivalent protection, e.g., MIKEY's pre-shared key transport with
   128 bit TGK, or RSA with 1024 bit keys (which according to [LV]
   corresponds to the desired 96 bit level, with some margin).

   In summary, key size for the key-exchange mechanism MUST be weighed
   against the size of the exchanged TGK so that it at least offers the
   required level.  For efficiency reasons, one SHOULD also avoid a

Top      Up      ToC       Page 53 
   security overkill, e.g., by not using a public key transport with
   public keys giving a security level that is orders of magnitude
   higher than length of the transported TGK.  We refer to [LV] for
   concrete key size recommendations.

   Moreover, if the TGKs are not random (or pseudo-random), a brute
   force search may be facilitated, again lowering the effective key
   size.  Therefore, care MUST be taken when designing the (pseudo-)
   random generators for TGK generation, see [FIPS][RAND].

   For the selection of the hash function, SHA-1 with 160-bit output is
   the default one.  In general, hash sizes should be twice the
   "security level", indicating that SHA-1-256, [SHA256], should be used
   for the default 128-bit level.  However, due to the real-time aspects
   in the scenarios we are treating, hash sizes slightly below 256 are
   acceptable, as the normal "existential" collision probabilities would
   be of secondary importance.

   In a Crypto Session Bundle, the Crypto Sessions can share the same
   TGK as discussed earlier.  From a security point of view, to satisfy
   the criterion in case the TGK is shared, the encryption of the
   individual Crypto Sessions are performed "independently".  In MIKEY,
   this is accomplished by having unique Crypto Session identifiers (see
   also Section 4.1) and a TEK derivation method that provides
   cryptographically independent TEKs to distinct Crypto Sessions
   (within the Crypto Session Bundle), regardless of the security
   protocol used.

   Specifically, the key derivations, as specified in Section 4.1, are
   implemented by a pseudo-random function.  The one used here is a
   simplified version of that used in TLS [TLS].  Here, only one single
   hash function is used, whereas TLS uses two different functions.
   This choice is motivated by the high confidence in the SHA-1 hash
   function, and by efficiency and simplicity of design (complexity does
   not imply security).  Indeed, as shown in [DBJ], if one of the two
   hashes is severely broken, the TLS PRF is actually less secure than
   as if a single hash had been used on the whole key, as is done in

   In the pre-shared key and public-key schemes, the TGK is generated by
   a single party (Initiator).  This makes MIKEY somewhat more sensitive
   if the Initiator uses a bad random number generator.  It should also
   be noted that neither the pre-shared nor the public-key scheme
   provides perfect forward secrecy.  If mutual contribution or perfect
   forward secrecy is desired, the Diffie-Hellman method is to be used.
   Authentication (e.g., signatures) in the Diffie-Hellman method is
   required to prevent man-in-the-middle attacks.

Top      Up      ToC       Page 54 
   Forward/backward security: if the TGK is exposed, all generated TEKs
   are compromised.  However, under the assumption that the derivation
   function is a pseudo-random function, disclosure of an individual TEK
   does not compromise other (previous or later) TEKs derived from the
   same TGK.  The Diffie-Hellman mode can be considered by cautious
   users, as it is the only one that supports so called perfect forward
   secrecy (PFS).  This is in contrast to a compromise of the pre-shared
   key (or the secret key of the public key mode), where future sessions
   and recorded sessions from the past are then also compromised.

   The use of random nonces (RANDs) in the key derivation is of utmost
   importance to counter off-line pre-computation attacks.  Note however
   that update messages re-use the old RAND.  This means that the total
   effective key entropy (relative to pre-computation attacks) for k
   consecutive key updates, assuming the TGKs and RAND are each n bits
   long, is about L = n*(k+1)/2 bits, compared to the theoretical
   maximum of n*k bits.  In other words, a 2^L work effort MAY enable an
   attacker to get all k n-bit keys, which is better than brute force
   (except when k = 1).  While this might seem like a defect, first note
   that for a proper choice of n, the 2^L complexity of the attack is
   way out of reach.  Moreover, the fact that more than one key can be
   compromised in a single attack is inherent to the key exchange
   problem.  Consider for instance a user who, using a fixed 1024-bit
   RSA key, exchanges keys and communicates during a one or two year
   lifetime of the public key.  Breaking this single RSA key will enable
   access to all exchanged keys and consequently the entire
   communication of that user over the whole period.

   All the pre-defined transforms in MIKEY use state-of-the-art
   algorithms that have undergone large amounts of public evaluation.
   One of the reasons for using the AES-CM from SRTP [SRTP], is to have
   the possibility of limiting the overall number of different
   encryption modes and algorithms, while offering a high level of
   security at the same time.

9.2.  Key lifetime

   Even if the lifetime of a TGK (or TEK) is not specified, it MUST be
   taken into account that the encryption transform in the underlying
   security protocol can in some way degenerate after a certain amount
   of encrypted data.  It is not possible to here state universally
   applicable, general key lifetime bounds; each security protocol
   should define such maximum amount and trigger a re-keying procedure
   before the "exhaustion" of the key.  For example, according to SRTP
   [SRTP] the TEK, together with the corresponding TGK, MUST be changed
   at least every 2^48 SRTP packet.

Top      Up      ToC       Page 55 
   Still, the following can be said as a rule of thumb.  If the security
   protocol uses an "ideal" b-bit block cipher (in CBC mode, counter
   mode, or a feedback mode, e.g., OFB, with full b-bit feedback),
   degenerate behavior in the crypto stream, possibly useful for an
   attacker, is (with constant probability) expected to occur after a
   total of roughly 2^(b/2) encrypted b-bit blocks (using random IVs).
   For security margin, re-keying MUST be triggered well in advance
   compared to the above bound.  See [BDJR] for more details.

   For use of a dedicated stream cipher, we refer to the analysis and
   documentation of said cipher in each specific case.

9.3.  Timestamps

   The use of timestamps, instead of challenge-responses, requires the
   systems to have synchronized clocks.  Of course, if two clients are
   not synchronized, they will have difficulties in setting up the
   security.  The current timestamp based solution has been selected to
   allow a maximum of one roundtrip (i.e., two messages), but still
   provide a reasonable replay protection.  A (secure) challenge-
   response based version would require at least three messages.  For a
   detailed description of the timestamp and replay handling in MIKEY,
   see Section 5.4.

   Practical experiences of Kerberos and other timestamp-based systems
   indicate that it is not always necessary to synchronize the terminals
   over the network.  Manual configuration could be a feasible
   alternative in many cases (especially in scenarios where the degree
   of looseness is high).  However, the choice must be made carefully
   with respect to the usage scenario.

9.4.  Identity Protection

   User privacy is a complex matter that to some extent can be enforced
   by cryptographic mechanisms, but also requires policy enforcement and
   various other functionalities.  One particular facet of privacy is
   user identity protection.  However, identity protection was not a
   main design goal for MIKEY.  Such a feature will add more complexity
   to the protocol and was therefore not chosen to be included.  As
   MIKEY is anyway proposed to be transported over, e.g., SIP, the
   identity may be exposed by this.  However, if the transporting
   protocol is secured and also provides identity protection, MIKEY
   might inherit the same feature.  How this should be done is for
   future study.

Top      Up      ToC       Page 56 
9.5.  Denial of Service

   This protocol is resistant to Denial of Service attacks in the sense
   that a Responder does not construct any state (at the key management
   protocol level) before it has authenticated the Initiator.  However,
   this protocol, like many others, is open to attacks that use spoofed
   IP addresses to create a large number of fake requests.  This may for
   example, be solved by letting the protocol transporting MIKEY do an
   IP address validity test.  The SIP protocol can provide this using
   the anonymous authentication challenge mechanism (specified in
   Section 22.1 of [SIP]).

   It is highly RECOMMENDED to include IDr in the Initiator's message.
   If not included, its absence can be used for DoS purposes (the
   largest DoS-impact being on the public key and DH methods), where a
   message intended for other entities is sent to the target.  In fact,
   the target may verify the signature correctly due to the fact that
   the Initiator's ID is correct and the message is actually signed by
   the claimed Initiator (e.g., by re-directing traffic from another

   However, in the public key method, the envelop key and the MAC will
   ensure that the message is not accepted (still, compared to a normal
   faked message, where the signature verification would detect the
   problem, one extra public key decryption is needed to detect the
   problem in this case).

   In the DH method, a message would be accepted (without detecting the
   error) and a response (and state) would be created for the malicious

   As also discussed in Section 5.4, the tradeoff between time
   synchronization and the size of the replay cache may be affected in
   case of for example, a flooding DoS attack.  However, if the
   recommendations of using a dynamic size of the replay cache are
   followed, it is believed that the client will in most cases be able
   to handle the replay cache.  Of course, as the replay cache decreases
   in size, the required time synchronization is more restricted.
   However, a bigger problem during such an attack would probably be to
   process the messages (e.g., verify signatures/MACs) due to the
   computational workload this implies.

9.6.  Session Establishment

   It should be noted that if the session establishment protocol is
   insecure, there may be attacks on this that will have indirect
   security implications on the secured media streams.  This however
   only applies to groups (and is not specific to MIKEY).  The threat is

Top      Up      ToC       Page 57 
   that one group member may re-direct a stream from one group member to
   another.  This will have the same implication as when a member tries
   to impersonate another member, e.g., by changing its IP address.  If
   this is seen as a problem, it is RECOMMENDED that a Data Origin
   Authentication (DOA) scheme (e.g., digital signatures) be applied to
   the security protocol.

   Re-direction of streams can of course be done even if it is not a
   group.  However, the effect will not be the same as compared to a
   group where impersonation can be done if DOA is not used.  Instead,
   re-direction will only deny the receiver the possibility of receiving
   (or just delay) the data.

10.  IANA Considerations

   This document defines several new name spaces associated with the
   MIKEY payloads.  This section summarizes the name spaces for which
   IANA is requested to manage the allocation of values.  IANA is
   requested to record the pre-defined values defined in the given
   sections for each name space.  IANA is also requested to manage the
   definition of additional values in the future.  Unless explicitly
   stated otherwise, values in the range 0-240 for each name space
   SHOULD be approved by the process of IETF consensus and values in the
   range 241-255 are reserved for Private Use, according to [RFC2434].

   The name spaces for the following fields in the Common header payload
   (from Section 6.1) are requested to be managed by IANA (in bracket is
   the reference to the table with the initially registered values):

   *  version

   *  data type (Table 6.1.a)

   *  Next payload (Table 6.1.b)

   *  PRF func (Table 6.1.c).  This name space is between 0-127, where
      values between 0-111 should be approved by the process of IETF
      consensus and values between 112-127 are reserved for Private Use.

   *  CS ID map type (Table 6.1.d)

   The name spaces for the following fields in the Key data transport
   payload (from Section 6.2) are requested to be managed by IANA:

   *  Encr alg (Table 6.2.a)

   *  MAC alg (Table 6.2.b)

Top      Up      ToC       Page 58 
   The name spaces for the following fields in the Envelope data payload
   (from Section 6.3) are requested to be managed by IANA:

   *  C (Table 6.3)

   The name spaces for the following fields in the DH data payload (from
   Section 6.4) are requested to be managed by IANA:

   *  DH-Group (Table 6.4)

   The name spaces for the following fields in the Signature payload
   (from Section 6.5) are requested to be managed by IANA:

   *  S type (Table 6.5)

   The name spaces for the following fields in the Timestamp payload
   (from Section 6.6) are requested to be managed by IANA:

   *  TS type (Table 6.6)

   The name spaces for the following fields in the ID payload and the
   Certificate payload (from Section 6.7) are requested to be managed by

   *  ID type (Table 6.7.a)

   *  Cert type (Table 6.7.b)

   The name spaces for the following fields in the Cert hash payload
   (from Section 6.8) are requested to be managed by IANA:

   *  Hash func (Table 6.8)

   The name spaces for the following fields in the Security policy
   payload (from Section 6.10) are requested to be managed by IANA:

   *  Prot type (Table 6.10)

   For each security protocol that uses MIKEY, a set of unique
   parameters MAY be registered.

   From Section 6.10.1.

   *  SRTP Type (Table 6.10.1.a)

   * SRTP encr alg (Table 6.10.1.b)

   * SRTP auth alg (Table 6.10.1.c)

Top      Up      ToC       Page 59 
   * SRTP PRF (Table 6.10.1.d)

   * FEC order (Table 6.10.1.e)

   The name spaces for the following fields in the Error payload (from
   Section 6.12) are requested to be managed by IANA:

   *  Error no  (Table 6.12)

   The name spaces for the following fields in the Key data payload
   (from Section 6.13) are requested to be managed by IANA:

   *  Type (Table 6.13.a).  This name space is between 0-16, which
      should be approved by the process of IETF consensus.

   *  KV (Table 6.13.b).  This name space is between 0-16, which should
      be approved by the process of IETF consensus.

   The name spaces for the following fields in the General Extensions
   payload (from Section 6.15) are requested to be managed by IANA:

   *  Type (Table 6.15).

10.1.  MIME Registration

   This section gives instructions to IANA to register the
   application/mikey MIME media type.  This registration is as follows:

   MIME media type name              : application
   MIME subtype name                 : mikey
   Required parameters               : none
   Optional parameters               : version
             version: The MIKEY version number of the enclosed message
                (e.g., 1). If not present, the version defaults to 1.
   Encoding Considerations           : binary, base64 encoded
   Security Considerations           : see section 9 in this memo
   Interoperability considerations   : none
   Published specification           : this memo

11.  Acknowledgments

   The authors would like to thank Mark Baugher, Ran Canetti, Martin
   Euchner, Steffen Fries, Peter Barany, Russ Housley, Pasi Ahonen (with
   his group), Rolf Blom, Magnus Westerlund, Johan Bilien, Jon-Olov
   Vatn, Erik Eliasson, and Gerhard Strangar for their valuable

Top      Up      ToC       Page 60 
12.  References

12.1.  Normative References

   [HMAC]    Krawczyk, H., Bellare, M., and R. Canetti, "HMAC:  Keyed-
             Hashing for Message Authentication", RFC 2104, February

   [NAI]     Aboba, B. and M. Beadles, "The Network Access Identifier",
             RFC 2486, January 1999.

   [OAKLEY]  Orman, H., "The OAKLEY Key Determination Protocol", RFC
             2412, November 1998.

   [PSS]     PKCS #1 v2.1 - RSA Cryptography Standard, RSA Laboratories,
             June 14, 2002,

   [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
             Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an
             IANA Considerations Section in RFCs", BCP 26, RFC 2434,
             October 1998.

   [SHA-1]   NIST, FIPS PUB 180-1: Secure Hash Standard, April 1995.

   [SRTP]    Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K.
             Norrman, "The Secure Real Time Transport Protocol", RFC
             3711, March 2004.

   [URI]     Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
             Resource Identifiers (URI): Generic Syntax", RFC 2396,
             August 1998.

   [X.509]   Housley, R., Polk, W., Ford, W., and D. Solo, "Internet
             X.509 Public Key Infrastructure Certificate and Certificate
             Revocation List (CRL) Profile", RFC 3280, April 2002.

   [AESKW]   Schaad, J. and R. Housley, "Advanced Encryption Standard
             (AES) Key Wrap Algorithm", RFC 3394, September 2002.

Top      Up      ToC       Page 61 
12.2.  Informative References

   [AKE]     Canetti, R. and H. Krawczyk, "Analysis of Key-Exchange
             Protocols and their use for Building Secure Channels",
             Eurocrypt 2001, LNCS 2054, pp. 453-474, 2001.

   [BDJR]    Bellare, M., Desai, A., Jokipii, E., and P. Rogaway, "A
             Concrete Analysis of Symmetric Encryption: Analysis of the
             DES Modes of Operation", in Proceedings of the 38th
             Symposium on Foundations of Computer Science, IEEE, 1997,
             pp. 394-403.

   [BMGL]    Hastad, J. and M. Naslund: "Practical Construction and
             Analysis of Pseduo-randomness Primitives", Proceedings of
             Asiacrypt 2001, LNCS. vol 2248, pp. 442-459, 2001.

   [DBJ]     Johnson, D.B., "Theoretical Security Concerns with TLS use
             of MD5", Contribution to ANSI X9F1 WG, 2001.

   [FIPS]    "Security Requirements for Cryptographic Modules", Federal
             Information Processing Standard Publications (FIPS PUBS)
             140-2, December 2002.

   [GKMARCH] Baugher, M., Canetti, R., Dondeti, L., and F. Lindholm,
             "Group Key Management Architecture", Work in Progress.

   [GDOI]    Baugher, M., Weis, B., Hardjono, T., and H. Harney, "The
             Group Domain of Interpretation", RFC 3547, July 2003.

   [GSAKMP]  Harney, H., Colegrove, A., Harder, E., Meth, U., and R.
             Fleischer, "Group Secure Association Key Management
             Protocol", Work in Progress.

   [HAC]     Menezes, A., van Oorschot, P., and S. Vanstone, "Handbook
             of Applied Cryptography", CRC press, 1996.

   [IKE]     Harkins, D. and D. Carrel, "The Internet Key Exchange
             (IKE)", RFC 2409, November 1998.

   [ISO1]    ISO/IEC 9798-3: 1997, Information technology - Security
             techniques - Entity authentication - Part 3: Mechanisms
             using digital signature techniques.

   [ISO2]    ISO/IEC 11770-3: 1997, Information technology - Security
             techniques - Key management - Part 3: Mechanisms using
             digital signature techniques.

Top      Up      ToC       Page 62 
   [ISO3]    ISO/IEC 18014 Information technology - Security techniques
             - Time-stamping services, Part 1-3.

   [KMASDP]  Arkko, J., Carrara, E., Lindholm, F., Naslund, M., and K.
             Norrman, "Key Management Extensions for SDP and RTSP", Work
             in Progress.

   [LOA]     Burrows, Abadi, and Needham, "A logic of authentication",
             ACM Transactions on Computer Systems 8 No.1 (Feb. 1990),

   [LV]      Lenstra, A. K. and E. R. Verheul, "Suggesting Key Sizes for

   [NTP]     Mills, D., "Network Time Protocol (Version 3)
             Specification, Implementation and Analysis", RFC 1305,
             March 1992.

   [OCSP]    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.

   [RAND]    Eastlake, 3rd, D., Crocker, S., and J. Schiller,
             "Randomness Requirements for Security", RFC 1750, December

   [RTSP]    Schulzrinne, H., Rao, A., and R. Lanphier, "Real Time
             Streaming Protocol (RTSP)", RFC 2326, April 1998.

   [SDP]     Handley, M. and V. Jacobson, "SDP: Session Description
             Protocol", RFC 2327, April 1998.

   [SHA256]  NIST, "Description of SHA-256, SHA-384, and SHA-512",

   [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.

   [TLS]     Dierks, T. and C. Allen, "The TLS Protocol - Version 1.0",
             RFC 2246, January 1999.

Top      Up      ToC       Page 63 
Appendix A.  MIKEY - SRTP Relation

   The terminology in MIKEY differs from the one used in SRTP as MIKEY
   needs to be more general, nor is tight to SRTP only.  Therefore, it
   might be hard to see the relations between keys and parameters
   generated in MIKEY and those used by SRTP.  This section provides
   some hints on their relation.

   MIKEY            | SRTP
   Crypto Session   | SRTP stream (typically with related SRTCP stream)
   Data SA          | input to SRTP's crypto context
   TEK              | SRTP master key

   The Data SA is built up by a TEK and the security policy exchanged.
   SRTP may use an MKI to index the TEK or TGK (the TEK is then derived
   from the TGK that is associated with the corresponding MKI), see

A.1.  MIKEY-SRTP Interactions

   In the following, we give a brief outline of the interface between
   SRTP and MIKEY and the processing that takes place.  We describe the
   SRTP receiver side only, the sender side will require analogous

   1. When an SRTP packet arrives at the receiver and is processed, the
      triple <SSRC, destination address, destination port> is extracted
      from the packet and used to retrieve the correct SRTP crypto
      context, hence the Data SA.  (The actual retrieval can, for
      example, be done by an explicit request from the SRTP
      implementation to MIKEY, or, by the SRTP implementation accessing
      a "database", maintained by MIKEY.  The application will typically
      decide which implementation is preferred.)

   2. If an MKI is present in the SRTP packet, it is used to point to
      the correct key within the SA.  Alternatively, if SRTP's <From,
      To> feature is used, the ROC||SEQ of the packet is used to
      determine the correct key.

   3. Depending on whether the key sent in MIKEY (as obtained in step 2)
      was a TEK or a TGK, there are now two cases.

      -  If the key obtained in step 2 is the TEK itself, it is used
         directly by SRTP as a master key.

Top      Up      ToC       Page 64 
      -  If the key instead is a TGK, the mapping with the CS_ID
         (internal to MIKEY, Section 6.1.1) allows MIKEY to compute the
         correct TEK from the TGK as described in Section 4.1 before
         SRTP uses it.

   If multiple TGKs (or TEKs) are sent, it is RECOMMENDED that each TGK
   (or TEK) be associated with a distinct MKI.  It is RECOMMENDED that
   the use of <From, To> in this scenario be limited to very simple
   cases, e.g., one stream only.

   Besides the actual master key, other information in the Data SA
   (e.g., transform identifiers) will of course also be communicated
   from MIKEY to SRTP.

Top      Up      ToC       Page 65 
Authors' Addresses

   Jari Arkko
   Ericsson Research
   02420 Jorvas

   Phone:  +358 40 5079256

   Elisabetta Carrara
   Ericsson Research
   SE-16480 Stockholm

   Phone:  +46 8 50877040

   Fredrik Lindholm
   Ericsson Research
   SE-16480 Stockholm

   Phone:  +46 8 58531705

   Mats Naslund
   Ericsson Research
   SE-16480 Stockholm

   Phone:  +46 8 58533739

   Karl Norrman
   Ericsson Research
   SE-16480 Stockholm

   Phone:  +46 8 4044502

Top      Up      ToC       Page 66 
Full Copyright Statement

   Copyright (C) The Internet Society (2004).  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

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

   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-


   Funding for the RFC Editor function is currently provided by the
   Internet Society.