Subject: Fwd: Re: [Srtp-users] [AVT] RFC 3711 - questions about cryptographic context

From: tal shahar <[email-masked]>
Date: Mon, 10 May 2004 00:22:55 -0700 (PDT)

sorry, I missed the attachment

Note: forwarded message attached.

---------------------------------
Do you Yahoo!?
Win a $20,000 Career Makeover at Yahoo! HotJobs 

Subject: Re: [Srtp-users] [AVT] RFC 3711 - questions about cryptographic context
From: tal shahar <[email-masked]>
To: "David A. McGrew" <[email-masked]>
Date: Sun, 9 May 2004 07:26:00 -0700 (PDT)

David hi and thanks a lot
as far as I understand, the key exchange protocol provides you with the <from, to> value.
so ,does the key exchange give you a bunch of <from, to> values and their corresponding keys.
another question, does this apply also to the MKI implementation, i.e. the key exchange provides you with a list of MKIs and their corresponding keys.
 
it is also not totally clear to me whether the sender triggers the re-keying or should it be triggered in the key exchange protocol, and the sender should just enforce it

"David A. McGrew" <[email-masked]> wrote:
Tal,

On May 9, 2004, at 2:03 AM, tal shahar wrote:

> hi
> in 3.2.1.  Transform-independent parameters
> 1. the RFC states that the cryptographic context should hold the the 
> master key(s)
> assuming I wish to have SRTP and SRTCP sharing the same master key, 
> what is the situation where I have more than one key

if I understand right, you are wondering why the "(s)" appears in the 
quote from the RFC. This is because there might be multiple master 
keys, each of which is used for a particular range of the packet index 
(that is, the 48-bit integer that is the concatenation of the ROC and 
the sequence number). libSRTP does not support this facility, and I 
expect that the vast majority of users won't miss it.

> 2. if I have only one master key, why do I need to hold the MKI

You don't, though you might need to store the fact that you are not 
using an MKI. libSRTP does not support MKIs as of yet. I don't think 
that it would be hard to add this feature.

David

>  
> thanks a lot
> tal
>
> Do you Yahoo!?
> Win a $20,000 Career Makeover at Yahoo! HotJobs
		
---------------------------------
Do you Yahoo!?
Win a $20,000 Career Makeover at Yahoo! HotJobs

---

From: tal shahar <[email-masked]>
Date: Wed, 12 May 2004 02:03:51 -0700 (PDT)

hi David and thanks again
I didnt define my question properly, the question is whether a key exchange will give me a list of <from, to> / MKI and their master key along. or will I get one at a time.
if I understand correct, the key exchange protocol can decide on giving me all (or some) of the keys in advance - this will require me (the SRTP implementation) to do something like switching master keys for the appropriate index - is it right ?
 
about the second question 
we were pondring this issue for quite a while
as far as I can understand the RFC does lean torward having the SRTP triggering this process
I'd like to quote a few things from the RFC, please tell me what you think
1. 8.1. SRTP senders SHALL count the amount of SRTP and SRTCP traffic being used for a master key and invoke key management to re-key if needed.
2. (9.2) That is, when 2^48 SRTP packets or 2^31 SRTCP packets have been secured
   with the same key (whichever occurs before), the key management MUST be called to provide new master key(s)
3. (11.2) If there are more than one SRTP/SRTCP stream (within the same RTP session) that share the master key, the upper limit of 2^48 SRTP packets / 2^31 SRTCP packets means that, before one of the streams reaches its maximum number of packets, re-keying MUST be triggered on ALL streams sharing the master key.  
 
thanks a lot
Tal

On May 10, 2004, at 12:22 AM, tal shahar wrote:

> From: tal shahar 
> Date: May 9, 2004 7:26:00 AM PDT
> To: "David A. McGrew" 
> as far as I understand, the key exchange protocol provides you with 
> the value.
> so ,does the key exchange give you a bunch of values and 
> their corresponding keys.
> another question, does this apply also to the MKI implementation, i.e. 
> the key exchange provides you with a list of MKIs and their 
> corresponding keys.

Yes, if you're using an MKI, then the key management protocol will need 
to supply that value along with the key. Similarly, if a 
packet index pair is associated with a key, then the pair would need to 
be communicated with the key.

This is described in Section 8.2. of RFC 3711, "Key Management 
Parameters".

>  
> it is also not totally clear to me whether the sender triggers the 
> re-keying or should it be triggered in the key exchange protocol, and 
> the sender should just enforce it

Good question, and it is clearly and important system design point. 
SRTP doesn't dictate how this is done. Clearly a key management system 
can provide new keys to an SRTP implementation, e.g. "here's a new key 
and the MKI to go with it". Also, an SRTP layer could trigger key 
management into getting new keys for it, though that is out of the 
scope of the RFC.

In libSRTP, there is an event/callback system by which SRTP can 
indicate to another system that some interesting event happened (see 
Section 4.3 of the "libSRTP 1.3 Overview and Reference Manual"). Two 
of these events are:

event_key_soft_limit An SRTP stream reached the soft key usage limit 
and will expire soon.
event_key_hard_limit An SRTP stream reached the hard key usage limit 
and has expired.

So the callback can recognize a key-expiration event and could call a 
key management function. Of course, the key management system would 
need to get the new key to all of the participants in the SRTP session.

David

> "David A. McGrew" wrote:
		
---------------------------------
Do you Yahoo!?
Yahoo! Movies - Buy advance tickets for 'Shrek 2'

---

From: "David A. McGrew" <[email-masked]>
Date: Tue, 11 May 2004 18:18:17 -0700

Tal,

On May 10, 2004, at 12:22 AM, tal shahar wrote:

> the <from, to> value.

Yes, if you're using an MKI, then the key management protocol will need 
to supply that value along with the key.  Similarly, if a <from, to> 
packet index pair is associated with a key, then the pair would need to 
be communicated with the key.

David

---

From: "David A. McGrew" <[email-masked]>
Date: Wed, 12 May 2004 14:13:46 -0700

Tal,

On May 12, 2004, at 2:03 AM, tal shahar wrote:

> I didnt define my question properly, the question is whether a key 
> exchange will give me a list of <from, to> / MKI and their master key 
> along. or will I get one at a time.
> if I understand correct, the key exchange protocol can decide on 
> giving me all (or some) of the keys in advance - this will require me 
> (the SRTP implementation) to do something like switching master 
> keys for the appropriate index - is it right ?

Yes, that's right.

> 1. 8.1. SRTP senders SHALL count the amount of SRTP and SRTCP traffic 
> being used for a master key and invoke key management to re-key if 
> needed.
>    with the same key (whichever occurs before), the key management 
> MUST be called to provide new master key(s)
> 3. (11.2) If there are more than one SRTP/SRTCP stream (within the 
> same RTP session) that share the master key, the upper limit of 2^48 
> SRTP packets / 2^31 SRTCP packets means that, before one of the 
> streams reaches its maximum number of packets, re-keying MUST be 
> triggered on ALL streams sharing the master key. 
>

Agreed.  SRTP, like RTP, relies on external signaling to set up its 
sessions, and for SRTP, this means that keys and other parameters are 
provided by some external mechanism.  But in SRTP there is also the 
strong requirement to not overuse a key, and the authors tried to 
highlight that need.

Daivd