Subject: [AVT] RE: MKI position in the received packet and Authentication tag le ngth dependency

From: Vavilapalli Srikanth-A19563 <[email-masked]>
Date: Wed, 22 Dec 2004 14:11:00 +0530

Mats

Thanks for your explanation.

In that case, can I assume that all the transform parameters (that are
associated to master key) described in the RFC 3711 (master-key length,
master-salt length, n_e, n_a, n_s, KDR, auth tag length) can be kept
constant through out the session unless (if any) key management modules has
some other means to sync up/communicate the sender and receiver of the
changes in these values?

Regards
Srikanth

-----Original Message-----
From: Mats Näslund [mailto:[email-masked]] 
Sent: Wednesday, December 22, 2004 1:25 AM
To: Mats Näslund
Cc: Vavilapalli Srikanth-A19563; [email-masked]; [email-masked]; David A.
McGrew; Karl Norrman (KI/EAB)
Subject: Re: MKI position in the received packet and Authentication tag
length dependency

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

Mats Näslund wrote:
> Hi
> 
> Vavilapalli Srikanth-A19563 wrote:
> 
>> 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?
> 
> 
> 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(?)
> 
>> 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.
> 
> 
> *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
> 

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

---

From: Mats Näslund <[email-masked]>
Date: Wed, 22 Dec 2004 14:33:24 +0100

Hi Srikanth,

Before answering this, I spoke with our local SRTP implementors,
since I wanted to check how they interpreted the spec.

First, to go back to the original question on how to locate the
MKI in situations where tag length *could* vary, they suggested
a different approach: rather than computing an offset from the
start of the packet, compute a negative offset from the *end* of
the packet. The length of the packet (with SRTP overhead) should
be available from the UDP level. Thus, the formula is

MKI location in rcvd packet = rcvd packet length - MKI length.

The MKI length is static. (Quote: "the value of the MKI indicator
and length MUST be kept fixed for the lifetime of the context".)
This seems to completely remove all issues on this matter.

Now to your new question.

> some other means to sync up/communicate the sender and receiver of the

The simple answer is yes, the transform parameters are either fixed,
or somehow, kept up-to-date/synched by key management. Clearly,
maintaining this synch may be non-trivial but it is not an issue for
SRTP.

Having said that, it could still have implications on the SRTP 
implementation. As it turns out, our own SRTP implementation works
(somewhat simplified) like this:

- As the first SRTP packet arrives, the crypto context is consulted
   for keys, transform parameters, etc.

- After this, the context is, for the purpose of transform parameters,
   *never* consulted again, i.e. the transform parameters are "cached"
   locally in configuration of SRTP. Keys, etc, are of course still
   occasionally needed from the context (e.g. due to MKI change).

This means that our implementors have made the (not unreasonable)
interpretation that these parameters never change, although it is not
explicitly stated in the RFC. So, even if you run our implementation
with a key mgmt that does handle transform updates, transform changes
would not be noticed by SRTP. I can to some extent agree that the RFC
is a bit underspecified on this issue. OTOH, the only way for SRTP to
"notice" transform changes is to consult the crypto context/key
management ON EVERY SINGLE PACKET, which seems to imply quite a bit
of overhead, or, to introduce a "signal" mechanism to tell SRTP to
take a peek in the context after updates.

Therefore, the question is if a future update of the RFC should specify
this, or, if it should explicitly forbid dynamic changes of anything 
except keys? I'm throwing out the question... I tried to think
of a scenario in which you would like to change e.g. encryption
algorithm in the middle of a session, but failed to do so. (Selective
encryption probably needs to be handled by other means, e.g. payload
format.) The only thing I could think of is some case where the end-user
moves from e.g. high bandwidth access to low bandwidth, in which case
there could be reason to decrease auth. tag size. Still, I have doubts
if this doesn't create more problems than it solves...

Best,

/Mats