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