ROC
Click on the red underlined text to get to the source
... 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
...
... 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.
...
...
1. The receiver receives the ROC in a MIKEY message together with a
key required for a particular continuous service ...
... 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 ...
... 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 ...
... non-zero) be decrypted using the wrong session key, as ROC is used
as input in session key derivation. In either case, the receiver ...
... 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 ...
... sender generates a MIKEY message
and includes the current value of ROC (say, ROC = 1) in the MIKEY
message. The MIKEY message ...
... MIKEY message
and includes the current value of ROC (say, ROC = 1) in the MIKEY
message. The MIKEY message reaches the receiver ...
... 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 ...
... 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,
...
...
One possible approach to address the issue could be to carry the ROC
in the MKI (Master Key Identifier ...
... synchronization.
In this document, a solution is presented where the ROC is carried in
the authentication tag of a special integrity transform ...
... integrity
transform, using the hooks existing in SRTP. Furthermore, when the
ROC is transmitted to the receiver it needs to be integrity protected
...
... 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 ...
... 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 ...
... 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 ...
... ROC_sender is the value of
his local ROC, and appends the tag to the packet. See the security
considerations section for discussions ...
... 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
...
... 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.
...
... 3711prop except that during authentication processing
ROC_local is replaced by ROC_sender (retrieved from the packet).
...
... authentication processing
ROC_local is replaced by ROC_sender (retrieved from the packet).
This works as follows. In the step where integrity protection ...
... SEQ is equal to 0 modulo R, the receiver extracts
ROC_sender from the TAG and verifies the MAC ...
... authenticated portion of the packet (as defined in [RFC3711]), but
concatenated with ROC_sender instead of concatenated with the
local_ROC ...
... ROC_sender instead of concatenated with the
local_ROC. The receiver generates MAC_tr for the MAC verification ...
... session key used in the
MAC calculation is dependent on the ROC, and during the derivation of
the session integrity ...
... the session integrity key, the ROC found in the packet under
consideration MUST be used. If the verification is successful, the
...
... verification is successful, the
receiver sets his local ROC equal to the ROC carried in the packet.
If the MAC ...
... 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
...
... 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 ...
... MAC calculation is
that if the receiver has an incorrect ROC value, MAC verification
will fail, so the receiver ...
... 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,
...
... 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
...
... 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
...
... following applies. The receiver's SRTP layer SHOULD ignore the ROC
value from the packet if the application layer can indicate to it
...
... 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 ...
... 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 ...
... 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.
...
... 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
...
... 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
...
... 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 ...
... Type | Meaning | Possible values
-----+-----------------------------+----------------
13 | ROC transmission rate | 16-bit integer ...
... be a non-zero unsigned integer. If the ROC transmission rate is not
included in the negotiation ...
... 11) in Table 6.10.1.a of RFC 3830prop with the addition that the length
of ROC MUST be included in the "Authentication tag length" parameter.
This means that the minimum tag length ...
... security consideration introduced here is
that the entire SRTP index (ROC || SEQ) will become public since it
is transferred without encryption ...
... in RFC 3711prop; 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 ...
... perform.
It must also be noted that if the ROC is modified by an attacker and
no integrity protection ...
... 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 ...
... 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 ...
... 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 ...
... 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.
...
... tag is the container holding the MAC (and for some
packets also the ROC), and the MAC is the output from the MAC-
...
...
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
...
... 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 ...
... tag-length is n. For those packets that
SEQ != 0 mod R, there is no ROC carried in the tag. For RCCm1
...
... RCCm1
there is no MAC on packets not carrying the ROC, so neither the
length of the MAC nor the length of the tag ...
... 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 ...
... 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 ...
... RCCm3 is used. RCCm3 does not use any MAC, but the ROC still
occupies four octets in the tag for packets with SEQ ...
... specified in Table 1 in Section 4.
The value 13 for ROC transmission rate has been registered in the
SRTP ...