Integrity Transform Carrying Roll-Over Counter for the Secure Real-time Transport Protocol (SRTP)
RFC 4771
Document | Type |
RFC - Proposed Standard
(January 2007; Errata)
Was draft-lehtovirta-srtp-rcc (individual in sec area)
|
|
---|---|---|---|
Authors | Karl Norrman , Mats Naslund , Vesa Lehtovirta | ||
Last updated | 2020-01-21 | ||
Stream | IETF | ||
Formats | plain text html pdf htmlized with errata bibtex | ||
Stream | WG state | (None) | |
Document shepherd | No shepherd assigned | ||
IESG | IESG state | RFC 4771 (Proposed Standard) | |
Consensus Boilerplate | Unknown | ||
Telechat date | |||
Responsible AD | Russ Housley | ||
Send notices to | ldondeti@qualcomm.com |
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.Show full document text