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
