Tech-invite3GPPspaceIETFspace
96959493929190898887868584838281807978777675747372717069686766656463626160595857565554535251504948474645444342414039383736353433323130292827262524232221201918171615141312111009080706050403020100
in Index   Prev   Next

RFC 3830

MIKEY: Multimedia Internet KEYing

Pages: 66
Proposed Standard
Errata
Updated by:  47386309
Part 4 of 4 – Pages 50 to 66
First   Prev   None

Top   ToC   RFC3830 - Page 50   prevText

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 authorization).
Top   ToC   RFC3830 - 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   ToC   RFC3830 - 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   ToC   RFC3830 - 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
   MIKEY.

   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   ToC   RFC3830 - 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   ToC   RFC3830 - 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   ToC   RFC3830 - 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 session). 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 request. 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   ToC   RFC3830 - 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   ToC   RFC3830 - 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
   IANA:

   *  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   ToC   RFC3830 - 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 feedback.
Top   ToC   RFC3830 - 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 1997. [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, www.rsalabs.com [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   ToC   RFC3830 - 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   ToC   RFC3830 - 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),
             18-36.

   [LV]      Lenstra, A. K. and E. R. Verheul, "Suggesting Key Sizes for
             Cryptosystems", http://www.cryptosavvy.com/suggestions.htm

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

   [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",
             http://csrc.nist.gov/encryption/shs/sha256-384-512.pdf

   [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   ToC   RFC3830 - 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 below.

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 interfacing. 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   ToC   RFC3830 - 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   ToC   RFC3830 - Page 65

Authors' Addresses

Jari Arkko Ericsson Research 02420 Jorvas Finland Phone: +358 40 5079256 EMail: jari.arkko@ericsson.com Elisabetta Carrara Ericsson Research SE-16480 Stockholm Sweden Phone: +46 8 50877040 EMail: elisabetta.carrara@ericsson.com Fredrik Lindholm Ericsson Research SE-16480 Stockholm Sweden Phone: +46 8 58531705 EMail: fredrik.lindholm@ericsson.com Mats Naslund Ericsson Research SE-16480 Stockholm Sweden Phone: +46 8 58533739 EMail: mats.naslund@ericsson.com Karl Norrman Ericsson Research SE-16480 Stockholm Sweden Phone: +46 8 4044502 EMail: karl.norrman@ericsson.com
Top   ToC   RFC3830 - 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
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

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.