[prev in list] [next in list] [prev in thread] [next in thread] 

List:       sip-implementors
Subject:    [Sip-implementors] SDES-sRTP: When not the same Crypto Context?
From:       Alexander Traud <pabstraud () compuserve ! com>
Date:       2021-04-14 12:21:29
Message-ID: 6A3CAB5C-985E-430C-BD05-1071387D6528 () compuserve ! com
[Download RAW message or body]

RFC 4568 (mmusic-sdescriptions) talks about an SRTP Cryptographic Context and its \
parameters (inherited from RFC 3711; avt-srtp). This is important when the context \
changes because the parameter "Rollover Counter" (ROC) must be reset then. The ROC \
was increased when the RTP sequence number (SEQ) wrapped from 0xffff to 0x0000. So \
far, so easy.

My question:
What exactly is not part of the SRTP Cryptographic Context? I am facing this question \
in the Call Hold scenario from RFC 5359 (sipping-service-examples; section 2.1).

Two real-world examples:

Example 1:
I have an AVM FRITZ!OS as Bob. Alice calls Bob. Alice offers AES-128 and AES-256. Bob \
goes for AES-128 because that has the lowest tag number. Later, Bob puts Alice on \
hold. Bob takes Alice off hold and offers AES-256 and AES-128. Alice goes for AES-128 \
because (just an example) she wants to avoid the computation overhead of AES-256.

In this example, the crypto-suite and the crypto-key for AES-128 did not change. \
After the resume, just the crypto-tag in SDP changed from 1 to 2. Is the parameter \
"tag" part of the cryptographic context? If yes, the ROC must be reset to zero.

Example 2:
I have a Snom D725 as Bob. Alice calls Bob and offers HMAC_SHA1_80. Bob goes for it. \
Bob puts Alice on hold. Bob takes Alice off hold and offers HMAC_SHA1_32. That is the \
default behavior of a Snom, which can be changed in its Web interface. Anyway, if I \
am not totally misreading the RFCs, this is allowed. Now, Alice can accept that or \
not. Let us assume Alice accepts that.

In this example, the crypto-key (and crypto-tag) did not change. The crypto-suite \
changed, but not the crypto part, just the authentication tag. Is the parameter \
"authentication tag" part of the cryptographic context? If yes, the ROC must be reset \
to zero.

Current situation:
In example 1, AVM (with an upcoming FRITZ!OS 7.2x) is going to reset the ROC (because \
of another change in code). In example 2, Snom (currently firmware 10.1.64.14) does \
not reset the ROC.

In other words, does a change to the
  authentication tag length (RFC 4568 section 6.2.2) or
  tag number (RFC 4568 section 4.1)
trigger a reset of the ROC?


_______________________________________________
Sip-implementors mailing list
Sip-implementors@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors


[prev in list] [next in list] [prev in thread] [next in thread]