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

["David A. McGrew" <mcgrew at cisco.com>]

Tal,

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

sorry, I missed the attachment

Note: forwarded message attached.

Do you Yahoo!?

Win a $20,000 Career Makeover at Yahoo! HotJobs

> From: tal shahar <morgentuo@yahoo.com>
> Date: May 9, 2004 7:26:00 AM PDT
> To: "David A. McGrew" <mcgrew@cisco.com>
> Subject: Re: [Srtp-users] [AVT] RFC 3711 - questions about cryptographic context
>
>
> 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.

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.  

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" <mcgrew@cisco.com> 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