Integrity Transform Carrying Roll-Over Counter for the Secure Real-time Transport Protocol (SRTP)
RFC 4771

• Status
• IESG evaluation record
• IESG writeups
• Email expansions
• History

• Versions
• 06

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.