Subject: [AVT] MKI position in the received packet and Authentication tag length dependency

From: Vavilapalli Srikanth-A19563 <[email-masked]>
Date: Tue, 21 Dec 2004 21:37:17 +0530

Hi

RFC 3711 states the values of "n_tag" (and n_a, SRTP_PREFIX_LENGTH) MUST be
fixed for any particular fixed value of the key.

Does this mean that authentication tag length could be different for
different master keys in a SRTP session which uses more than one master key?

In such scenarios (i.e. a SRTP session using more than one master key and
using MKI mechanism to determine the master key), when a SRTP receiver
receives a packet, how does it determine the MKI value (or MKI position) in
the received packet, if auth tag length depends on the master key used at
the SRTP sender side? 

The MKI location in the received packet = 
Received packet start location + (received packet length - auth tag length -
MKI length)

Please clarify me.

Regards
Srikanth

_______________________________________________
Audio/Video Transport Working Group
[email-masked]
https://www1.ietf.org/mailman/listinfo/avt

---

From: Mats Näslund <[email-masked]>
Date: Tue, 21 Dec 2004 19:50:10 +0100

Hi

> different master keys in a SRTP session which uses more than one master 

Theoretically, yes. But, in practice it would require a
change of transform parameters in the middle of an ongoing session,
which I do not think many (if any) key mgmt protocols support(?)

> Received packet start location + (received packet length - auth tag 

*If* you have a key mgmt protocol that can keep the SRTP cryptographic
context updated with dynamically varying auth tag lengths, then it
should be no problem to use your formula on a per packet basis.

I think the question is: if something is not explicitly forbidden,
does that imply that it is allowed/useful?

In this case, yes, it is allowed, but would be a bit complicated
to realize, but the complications are purely key mgmt issues, and
SRTP should not bother with it.

To motivate why we have the "MUST" as above, the reason is that the
only time when it seems at all feasible/secure to change those
parameters are in combination with a key managment operation. Still, it
does not imply that we recommend to change the parameters during the
session, but if for some reason somebody wants to (and can manage)...

Hope this answers

cheers

/Mats

---

From: Mats Näslund <[email-masked]>
Date: Tue, 21 Dec 2004 20:54:39 +0100

Hi again,

Just as I sent the previous mail (copied below), some things occurred to
me that are probably worth another mail...

In SRTP, the MKI is a bit different from e.g. an IPsec SPI, since
it is explicitly stated that the SRTP MKI identifies *only* the key,
and not the crypto context (as the SPI does in other protocols). Hence,
a conferment SRTP implementation *could* in principle be implemented in
such a way  that a change of MKI/key does not enable a simultaneous
change of transform parameters, simply because a change of MKI does not
imply anything to SRTP, except that it expects a new key. Conversely,
if you have a key mgmt protocol running in the background that keeps the
crypto context updated, you could in theory change the auth tag
length *without* simultaneous change of MKI. The MKI is not
synched with anything except the key(s).

For the same reason, the MKI is NOT needed to deduce the auth tag
length, so a "formula" (like the one you suggested) is still possible
to find. I.e. there is no "Catch-22" problem, which might have been
the case if the MKI had determined the tag length, and the tag length
in turn had determined the location of the MKI, etc...

Moreover, since SRTP supports varying tag lengths (at least from
session to session) a formula like the one you suggested is *needed*
in order to be able to correctly parse all possible SRTP packets.
Given that, I arrive at the same conclusion as before: if the key
mgmt can keep sender/reciver synched on auth. tag length, it is
in principle possible to let it vary during the session, but it does
not seem very useful(?)

Best,

/Mats