doc: Add RFC documents

1 files changed, 675 insertions, 0 deletions

diff --git a/doc/rfc/rfc4771.txt b/doc/rfc/rfc4771.txt
new file mode 100644
index 0000000..3048b05
--- /dev/null
+++ b/doc/rfc/rfc4771.txt
@@ -0,0 +1,675 @@
+
+
+
+
+
+
+Network Working Group                                      V. Lehtovirta
+Request for Comments: 4771                                    M. Naslund
+Category: Standards Track                                     K. Norrman
+                                                                Ericsson
+                                                            January 2007
+
+
+             Integrity Transform Carrying Roll-Over Counter
+           for the Secure Real-time Transport Protocol (SRTP)
+
+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 (2007).
+
+Abstract
+
+   This document defines an integrity transform for Secure Real-time
+   Transport Protocol (SRTP; see RFC 3711), which allows the roll-over
+   counter (ROC) to be transmitted in SRTP packets as part of the
+   authentication tag.  The need for sending the ROC in SRTP packets
+   arises in situations where the receiver joins an ongoing SRTP session
+   and needs to quickly and robustly synchronize.  The mechanism also
+   enhances SRTP operation in cases where there is a risk of losing
+   sender-receiver synchronization.
+
+Table of Contents
+
+   1. Introduction ....................................................2
+      1.1. Terminology ................................................3
+   2. The Transform ...................................................3
+   3. Transform Modes .................................................5
+   4. Parameter Negotiation ...........................................5
+   5. Security Considerations .........................................7
+   6. IANA Considerations ............................................10
+   7. Acknowledgements ...............................................10
+   8. References .....................................................10
+      8.1. Normative References ......................................10
+      8.2. Informative References ....................................10
+
+
+
+
+
+Lehtovirta, et al.          Standards Track                     [Page 1]
+
+RFC 4771          Roll-Over Counter Carrying Transform      January 2007
+
+
+1.  Introduction
+
+   When a receiver joins an ongoing SRTP [RFC3711] session, out-of-band
+   signaling must provide the receiver with the value of the ROC the
+   sender is currently using.  For instance, it can be transferred in
+   the Common Header Payload of a MIKEY [RFC3830] message.  In some
+   cases, the receiver will not be able to synchronize his ROC with the
+   one used by the sender, even if it is signaled to him out of band.
+   Examples of where synchronization failure will appear are:
+
+   1. The receiver receives the ROC in a MIKEY message together with a
+      key required for a particular continuous service.  He does not,
+      however, join the service until after a few hours, at which point
+      the sender's sequence number (SEQ) has wrapped around, and so the
+      sender, meanwhile, has increased the value of ROC.  When the user
+      joins the service, he grabs the SEQ from the first seen SRTP
+      packet and prepends the ROC to build the index.  If integrity
+      protection is used, the packet will be discarded.  If there is no
+      integrity protection, the packet may (if key derivation rate is
+      non-zero) be decrypted using the wrong session key, as ROC is used
+      as input in session key derivation.  In either case, the receiver
+      will not have its ROC synchronized with the sender, and it is not
+      possible to recover without out-of-band signaling.
+
+   2. If the receiver leaves the session (due to being out of radio
+      coverage or because of a user action), and does not start
+      receiving traffic from the service again until after 2^15 packets
+      have been sent, the receiver will be out of synchronization (for
+      the same reasons as in example 1).
+
+   3. The receiver joins a service when the SEQ has recently wrapped
+      around (say, SEQ = 0x0001).  The sender generates a MIKEY message
+      and includes the current value of ROC (say, ROC = 1) in the MIKEY
+      message.  The MIKEY message reaches the receiver, who reads the
+      ROC value and initializes its local ROC to 1.  Now, if an SRTP
+      packet prior to wraparound, i.e., with a SEQ lower than 0 (say,
+      SEQ = 0xffff), was delayed and reaches the receiver as the first
+      SRTP packet he sees, the receiver will initialize its highest
+      received sequence number, s_l, to 0xffff.  Next, the receiver will
+      receive SRTP packets with sequence numbers larger than zero, and
+      will deduce that the SEQ has wrapped.  Hence, the receiver will
+      incorrectly update the ROC and be out of synchronization.
+
+   4. Similarly to (3), since the initial SEQ is selected at random by
+      the sender, it may happen to be selected as a value very close to
+      0xffff.  In this case, should the first few packets be lost, the
+      receiver may similarly end up out of synchronization.
+
+
+
+
+Lehtovirta, et al.          Standards Track                     [Page 2]
+
+RFC 4771          Roll-Over Counter Carrying Transform      January 2007
+
+
+   These problems have been recognized in, e.g., 3GPP2 and 3GPP, where
+   SRTP is used for streaming media protection in their respective
+   multicast/broadcast solutions [BCMCS][MBMS].  Problem 4 actually
+   exists inherently due to the way SEQ initialization is done in RTP.
+
+   One possible approach to address the issue could be to carry the ROC
+   in the MKI (Master Key Identifier) field of each SRTP packet.  This
+   has the advantage that the receiver immediately knows the entire
+   index for a packet.  Unfortunately, the MKI has no semantics in RFC
+   3711 (other than specifying master key), and a regular RFC 3711
+   compliant implementation would not be able to make use of the
+   information carried in the MKI.  Furthermore, the MKI field is not
+   integrity protected; hence, care must be taken to avoid obvious
+   attacks against the synchronization.
+
+   In this document, a solution is presented where the ROC is carried in
+   the authentication tag of a special integrity transform in selected
+   SRTP packets.
+
+   The benefit of this approach is that the functionality of fast and
+   robust synchronization can be achieved as a separate integrity
+   transform, using the hooks existing in SRTP.  Furthermore, when the
+   ROC is transmitted to the receiver it needs to be integrity protected
+   to avoid persistent denial-of-service (DoS) attacks or transmission
+   errors that could bring the receiver out of synchronization.  (A DoS
+   attack is regarded as persistent if it can last after the attacker
+   has left the area; in this particular case, an attacker could modify
+   the ROC in one packet and the victim would be out of synchronization
+   until the next ROC is transmitted).  The above discussion leads to
+   the conclusion that it makes sense to carry the ROC inside the
+   authentication tag of an integrity transform.
+
+1.1.  Terminology
+
+   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 RFC 2119 [RFC2119].
+
+2.  The Transform
+
+   The transform, hereafter called Roll-over Counter Carrying Transform
+   (or RCC for short), works as follows.
+
+   The sender processes the RTP packet according to RFC 3711.  When
+   applying the message integrity transform, the sender checks if the
+   SEQ is equal to 0 modulo some non-zero integer constant R.  If that
+   is the case, the sender computes the MAC in the same way as is done
+   when using the default integrity transform (i.e., HMAC-SHA1(auth_key,
+
+
+
+Lehtovirta, et al.          Standards Track                     [Page 3]
+
+RFC 4771          Roll-Over Counter Carrying Transform      January 2007
+
+
+   Authenticated_portion || ROC)).  Next, the sender truncates the MAC
+   by 32 bits to generate MAC_tr, i.e., MAC_tr is the tag_length - 32
+   most significant bits of the MAC.  Next, the sender constructs the
+   tag as TAG = ROC_sender || MAC_tr, where ROC_sender is the value of
+   his local ROC, and appends the tag to the packet.  See the security
+   considerations section for discussions on the effects of shortening
+   the MAC.  In particular, note that a tag-length of 32 bits gives no
+   security at all.
+
+   If the SEQ is not equal to 0 mod R, the sender just proceeds to
+   process the packet according to RFC 3711 without performing the
+   actions in the previous paragraph.
+
+   The value R is the rate at which the ROC is included in the SRTP
+   packets.  Since the ROC consumes four octets, this gives the
+   possibility to use it sparsely.
+
+   When the receiver receives an SRTP packet, it processes the packet
+   according to RFC 3711 except that during authentication processing
+   ROC_local is replaced by ROC_sender (retrieved from the packet).
+   This works as follows.  In the step where integrity protection is to
+   be verified, if the SEQ is equal to 0 modulo R, the receiver extracts
+   ROC_sender from the TAG and verifies the MAC computed (in the same
+   way as if the default integrity transform was used) over the
+   authenticated portion of the packet (as defined in [RFC3711]), but
+   concatenated with ROC_sender instead of concatenated with the
+   local_ROC.  The receiver generates MAC_tr for the MAC verification in
+   the same way the sender did.  Note that the session key used in the
+   MAC calculation is dependent on the ROC, and during the derivation of
+   the session integrity key, the ROC found in the packet under
+   consideration MUST be used.  If the verification is successful, the
+   receiver sets his local ROC equal to the ROC carried in the packet.
+   If the MAC does not verify, the packet MUST be dropped.  The
+   rationale for using the ROC from the packet in the MAC calculation is
+   that if the receiver has an incorrect ROC value, MAC verification
+   will fail, so the receiver will not correct his ROC.
+
+   If the SEQ is not equal to 0 mod R, the receiver just proceeds to
+   process the packet according to RFC 3711 without performing the
+   actions in the previous paragraph.
+
+   Since Secure Real-time Transport Control Protocol (SRTCP) already
+   carries the entire index in-band, there is no reason to apply this
+   transform to SRTCP.  Hence, the transform SHALL only be applied to
+   SRTP, and SHALL NOT be used with SRTCP.
+
+
+
+
+
+
+Lehtovirta, et al.          Standards Track                     [Page 4]
+
+RFC 4771          Roll-Over Counter Carrying Transform      January 2007
+
+
+3.  Transform Modes
+
+   The above transform only provides integrity protection for the
+   packets that carry the ROC (this will be referred to as mode 1).  In
+   the cases where there is a need to integrity protect all the packets,
+   the packets that do not have SEQ equal to 0 mod R MUST be protected
+   using the default integrity transform (this will be referred to as
+   mode 2).
+
+   Under some circumstances, it may be acceptable not to use integrity
+   protection on any of the packets; this will be referred to as mode 3.
+   Without integrity protection of the packets carrying the ROC, a DoS
+   attack, which will prevail until the next correctly received ROC, is
+   possible.  Make sure to carefully read the security considerations in
+   Section 5 before using mode 3.
+
+   In case no integrity protection is offered, i.e., mode 3, the
+   following applies.  The receiver's SRTP layer SHOULD ignore the ROC
+   value from the packet if the application layer can indicate to it
+   that the local ROC is synchronized with the sender (hence, the packet
+   would be processed using the local ROC).  Note that the received ROC
+   still MUST be removed from the packet before continued processing.
+   In this scenario, the application layer feedback to the SRTP layer
+   need not be on a per-packet basis, and it can consist merely of a
+   boolean value set by the application layer and read by the SRTP
+   layer.
+
+   Thus, note the following difference.  Using mode 2 will integrity
+   protect all RTP packets, but only add ROC to those having SEQ
+   divisible by R.  Using mode 1 and setting R equal to one will also
+   integrity protect all packets, but will in addition to that add ROC
+   to each packet.  Modes 1 and 2 MUST compute the MAC in the same way
+   as the pre-defined authentication transform for SRTP, i.e., HMAC-
+   SHA1.
+
+   To comply with this specification, mode 1, mode 2, and mode 3 are
+   MANDATORY to implement.  However, it is up to local policy to decide
+   which mode(s) are allowed to be used.
+
+4.  Parameter Negotiation
+
+   RCC requires that a few parameters are signaled out of band.  The
+   parameters that must be in place before the transform can be used are
+   integrity transform mode and the rate, R, at which the ROC will be
+   transmitted.  This can be done using, e.g., MIKEY [RFC3830].
+
+
+
+
+
+
+Lehtovirta, et al.          Standards Track                     [Page 5]
+
+RFC 4771          Roll-Over Counter Carrying Transform      January 2007
+
+
+   To perform the parameter negotiation using MIKEY, three integrity
+   transforms have been registered -- RCCm1, RCCm2, and RCCm3 in Table
+   6.10.1.c of [RFC3830] -- for the three modes defined.
+
+                  Table 1.  Integrity transforms
+
+                      SRTP auth alg | Value
+                      --------------+------
+                      RCCm1         |     2
+                      RCCm2         |     3
+                      RCCm3         |     4
+
+   Furthermore, the parameter R has been registered in Table 6.10.1.a of
+   [RFC3830].
+
+              Table 2.  Integrity transform parameter
+
+        Type | Meaning                     | Possible values
+        -----+-----------------------------+----------------
+         13  | ROC transmission rate       |  16-bit integer
+
+   The ROC transmission rate, R, is given in network byte order.  R MUST
+   be a non-zero unsigned integer.  If the ROC transmission rate is not
+   included in the negotiation, the default value of 1 SHALL be used.
+
+   To have the ability to use different integrity transforms for SRTP
+   and SRTCP, which is needed in connection to the use of RCC, the
+   following additional parameters have been registered in Table
+   6.10.1.a of [RFC3830]:
+
+                    Table 3.  Integrity parameters
+
+        Type | Meaning                     | Possible values
+        -----+-----------------------------+----------------
+         14  | SRTP Auth. algorithm        | see below
+         15  | SRTCP Auth. algorithm       | see below
+         16  | SRTP Session Auth. key len  | see below
+         17  | SRTCP Session Auth. key len | see below
+         18  | SRTP Authentication tag len | see below
+         19  | SRTCP Authentication tag len| see below
+
+   The possible values for authentication algorithms (types 14 and 15)
+   are the same as for the "Authentication algorithm" parameter (type 2)
+   in Table 6.10.1.a of RFC 3830 with the addition of the values found
+   in Table 1 above.
+
+
+
+
+
+
+Lehtovirta, et al.          Standards Track                     [Page 6]
+
+RFC 4771          Roll-Over Counter Carrying Transform      January 2007
+
+
+   The possible values for session authentication key lengths (types 16
+   and 17) are the same as for the "Session Auth. key length" parameter
+   (type 3) in Table 6.10.1.a of RFC 3830.
+
+   The possible values for authentication tag lengths (types 18 and 19)
+   are the same as for the "Authentication tag length" parameter (type
+   11) in Table 6.10.1.a of RFC 3830 with the addition that the length
+   of ROC MUST be included in the "Authentication tag length" parameter.
+   This means that the minimum tag length when using RCC is 32 bits.
+
+   To avoid ambiguities when introducing these new parameters that have
+   overlapping functionality to existing parameters in Table 6.10.1.a of
+   RFC 3830, the following approach MUST be taken: If any of the
+   parameter types 14-19 (specifying behavior specific to SRTP or SRTCP)
+   and a corresponding general parameter (type 2, 3, or 11) are both
+   present in the policy, the more specific parameter SHALL have
+   precedence.  For example, if the "Authentication algorithm" parameter
+   (type 2) is set to HMAC-SHA-1, and the "SRTP Auth. Algorithm" (type
+   14) is set to RCCm1, SRTP will use the RCCm1 algorithm, but since
+   there is no specific algorithm chosen for SRTCP, the more generally
+   specified one (HMAC-SHA-1) is used.
+
+5.  Security Considerations
+
+   An analogous method already exists in SRTCP (the SRTCP index is
+   carried in each packet under integrity protection).  To the best of
+   our knowledge, the only security consideration introduced here is
+   that the entire SRTP index (ROC || SEQ) will become public since it
+   is transferred without encryption.  (In normal SRTP operation, only
+   the SEQ-part of the index is disclosed.)  However, RFC 3711 does not
+   identify a need for encrypting the SRTP index.
+
+   It is important to realize that only every Rth packet is integrity
+   protected in mode 1, so unless R = 1, the mechanism should be seen
+   for what it is: a way to improve sender-receiver synchronization, and
+   not a replacement for integrity protection.
+
+   The use of mode 3 (NULL-MAC) introduces a vulnerability not present
+   in RFC 3711; namely, if an attacker modifies the ROC, the
+   modification will go undetected by the receiver, and the receiver
+   will lose cryptographic synchronization until the next correct ROC is
+   received.  This implies that an attacker can perform a DoS attack by
+   only modifying every Rth packet.  Because of this, mode 3 MUST only
+   be used after proper risk assessment of the underlying network.
+   Besides the considerations in Section 9.5 and 9.5.1 of RFC 3711,
+   additional requirements of the underlying transport network must be
+   met.
+
+
+
+
+Lehtovirta, et al.          Standards Track                     [Page 7]
+
+RFC 4771          Roll-Over Counter Carrying Transform      January 2007
+
+
+   o  The transport network must only consist of trusted domains.  That
+      means that everyone on the path from the source to the destination
+      is trusted not to modify or inject packets.
+
+   o  The transport network must be protected from packet injection,
+      i.e., it must be ensured that the only packets present on the path
+      from the source to the destination(s) originate from trusted
+      sources.
+
+   o  If the packets, on their way from the source to the
+      destination(s), travel outside of a trusted domain, their
+      integrity must be ensured (e.g., by using a Virtual Private
+      Network (VPN) connection or a trusted leased line).
+
+   In the (assumed common) case that the last link to the destination(s)
+   is a wireless link, the possibility that an attacker injects forged
+   packets here must be carefully considered before using mode 3.
+   Especially, if used in a broadcast setting, many destinations would
+   be affected by the attack.  However, unless R is big, this DoS attack
+   would be similar in effect to radio jamming, which would be easier to
+   perform.
+
+   It must also be noted that if the ROC is modified by an attacker and
+   no integrity protection is used, the output of the decryption will
+   not be useful to the upper layers, and these must be able to cope
+   with data that appears random.  In the case integrity protection is
+   used on the packets containing the ROC, and the ROC is modified by an
+   attacker (and the receiver already has an approximation of the ROC,
+   e.g., by getting it previously), the packet will be discarded and the
+   receiver will not be able to decrypt correctly.  Note, however, that
+   the situation is better in the latter case, since the receiver now
+   can try different ROC values in a neighborhood around the approximate
+   value he already has.
+
+   As RCC is expected to be used in a broadcast setting where group
+   membership will be based on access to a symmetric group key, it is
+   important to point out the following.  With symmetric-key-based
+   integrity protection, it may be as easy, if not easier, to get access
+   to the integrity key (often a combination of a low-cost activity of
+   purchasing a subscription and breaking the security of a terminal to
+   extract the integrity key) as being able to transmit.
+
+   A word of warning regarding the choice of length of the
+   authentication tag:  Note that, in contrast to common MAC tags, there
+   is a clear distinction made between the RCC authentication tag and
+   the RCC MAC.  The tag is the container holding the MAC (and for some
+   packets also the ROC), and the MAC is the output from the MAC-
+   algorithm (i.e., HMAC-SHA1).  The length of the authentication tag
+
+
+
+Lehtovirta, et al.          Standards Track                     [Page 8]
+
+RFC 4771          Roll-Over Counter Carrying Transform      January 2007
+
+
+   with the RCC transform includes the four-octet ROC in some packets.
+   This means that for a tag-length of n octets, there is only room for
+   a MAC of length n - 4, i.e., a tag-length of n octets does not
+   provide a full n-octet integrity protection on all packets.  There
+   are five cases:
+
+      1. RCCm1 is used and tag-length is n.  For those packets that
+         SEQ = 0 mod R, the ROC is carried in the tag and occupies four
+         octets.  This leaves n - 4 octets for the MAC.
+
+      2. RCCm1 is used and tag-length is n.  For those packets that
+         SEQ != 0 mod R, there is no ROC carried in the tag.  For RCCm1
+         there is no MAC on packets not carrying the ROC, so neither the
+         length of the MAC nor the length of the tag has any relevance.
+
+      3. RCCm2 is used and tag-length is n.  For those packets that
+         SEQ = 0 mod R, the ROC is carried in the tag and occupies four
+         octets.  This leaves n - 4 octets for the MAC (this is
+         equivalent to case 1).
+
+      4. RCCm2 is used and tag-length is n.  For those packets that
+         SEQ != 0 mod R, there is no ROC carried in the tag.  This
+         leaves n octets for the MAC.
+
+      5. RCCm3 is used.  RCCm3 does not use any MAC, but the ROC still
+         occupies four octets in the tag for packets with SEQ = 0 mod R,
+         so the tag-length MUST be set to four.  For packets with
+         SEQ != 0 mod R, neither the length of the MAC nor the length of
+         the tag has any relevance.
+
+   The conclusion is that in cases 1 and 3, the length of the MAC is
+   shorter than the length of the authentication tag.  To achieve the
+   same (or less) MAC forgery success probability on all packets when
+   using RCCm1 or RCCm2, as with the default integrity transform in RFC
+   3711, the tag-length must be set to 14 octets, which means that the
+   length of MAC_tr is 10 octets.
+
+   It is recommended to set the tag-length to 14 octets when RCCm1 or
+   RCCm2 is used, and the tag-length MUST be set to four octets when
+   RCCm3 is used.
+
+
+
+
+
+
+
+
+
+
+
+Lehtovirta, et al.          Standards Track                     [Page 9]
+
+RFC 4771          Roll-Over Counter Carrying Transform      January 2007
+
+
+6.  IANA Considerations
+
+   According to Section 10 of RFC 3830, IETF consensus is required to
+   register values in the range 0-240 in the SRTP auth alg namespace and
+   the SRTP Type namespace.
+
+   The value 2 for RCCm1, the value 3 for RCCm2, and the value 4 for
+   RCCm3 have been registered in the SRTP auth alg namespace as
+   specified in Table 1 in Section 4.
+
+   The value 13 for ROC transmission rate has been registered in the
+   SRTP Type namespace as specified in Table 2 in Section 4.
+
+   The values 14 to 19 have been registered in the SRTP Type namespace
+   according to Table 3 in Section 4.
+
+7.  Acknowledgements
+
+   We would like to thank Nigel Dallard, Lakshminath Dondeti, and David
+   McGrew for fruitful comments and discussions.
+
+8.  References
+
+8.1.  Normative References
+
+   [RFC3830]  Arkko, J., Carrara, E., Lindholm, F., Naslund, M., and K.
+              Norrman, "MIKEY: Multimedia Internet KEYing", RFC 3830,
+              August 2004.
+
+   [RFC3711]  Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K.
+              Norrman, "The Secure Real-time Transport Protocol (SRTP)",
+              RFC 3711, March 2004.
+
+   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
+              Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+8.2.  Informative References
+
+   [MBMS]     3GPP TS 33.246, "3G Security; Security of Multimedia
+              Broadcast/ Multicast Service (MBMS)", October 2006.
+
+   [BCMCS]    3GPP2 X.S0022-0, "Broadcast and Multicast Service in
+              cdma2000 Wireless IP Network", February 2005.
+
+
+
+
+
+
+
+
+Lehtovirta, et al.          Standards Track                    [Page 10]
+
+RFC 4771          Roll-Over Counter Carrying Transform      January 2007
+
+
+Authors' Addresses
+
+   Vesa Lehtovirta
+   Ericsson Research
+   02420 Jorvas
+   Finland
+
+   Phone:  +358 9 2993314
+   EMail:  vesa.lehtovirta@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
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Lehtovirta, et al.          Standards Track                    [Page 11]
+
+RFC 4771          Roll-Over Counter Carrying Transform      January 2007
+
+
+Full Copyright Statement
+
+   Copyright (C) The IETF Trust (2007).
+
+   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.
+
+
+
+
+
+
+
+Lehtovirta, et al.          Standards Track                    [Page 12]
+