Subject: [AVT] Re: SRTP and cryptographic context management

From: Mark Baugher <[email-masked]>
Date: Tue, 02 Oct 2001 11:26:36 -0700

I posted this note last June and reported under point #3, below, that we 
did not
want to use the packet index (specifically the SEQ and ROC, roll-over 
counter used
by SRTP) to identify the cryptographic context.   We (Brian Weis and I) 
preferred the
use of an SPI, just like IPsec.

We have changed our opinion and think that the use of the SRTP SEQ+ROC is
preferable to specifying both SEQ+ROC and SPI as means to change the
cryptographic context for an RTP session.  A version of the SRTP I-D that is
not yet posted had both in it.  After some discussion, we (SRTP authors, 
Brian,
and I) thought that it would be better to live with the limitations of SEQ+ROC
than to have two mechanisms that do the same thing.  Here are the drawbacks
of the two approaches.

1. SPI adds bytes to the SRTP packet that makes it unsuitable for phone and
maybe other, non-video applications.

2. SEQ+ROC ties the cryptographic context to an RTP SSRC, requires that a
SEQ+ROC interval identify the crypto context, and these two things make
sharing encryption keys and immediate revocation of receivers less 
straightforward.

"Less straightforward" is not the same as impossible and we now see ways that
key management can handle the SEQ+ROC problems of sharing keys and
immediate revocation.  The SRTP authors should describe this solution in
the next I-D.  The SEQ+ROC solution to changing crypto contexts is compelling
because it does not add any new features to SRTP but instead is a footnote
commentary for key management.

Mark

At 12:42 PM 6/7/2001 -0700, Mark Baugher wrote:
>Since the time of this thread, David McGrew, Brian Weis, and I have worked 
>on the
>problem of changing the cryptographic context, or simply the key within a 
>particular
>crypto context (which I refer to as changing the crypto context).  We're 
>following
>the suggestion that appears at the end of this note:  We use the SRTP "packet
>index," which is based on the RTP sequence number,  to mark the point at 
>which a
>new crypto context is used for the RTP session (this way we can change the key
>without disrupting the RTP session).  Thus all packets having a packet 
>index that
>is equal to or greater than the packet index associated with a crypto 
>context will
>us that crypto context until a new one is installed.
>
>Here is our status.
>
>1. We are developing a programming interface between the GDOI key management
>system and SRTP for requesting and updating keys.  We evaluated use of PF_KEY,
>the standard way to do this for IPSEC, and found that PF_KEY is unsuitable for
>application-layer security since PF_KEY requires that SRTP be run as a 
>privileged
>process to access the security association database that GDOI updates.  So we
>are doing a special-purpose interface for demo purposes rather than doing the
>architecturally correct thing, which might be to make PF_KEY work for SRTP.
>
>2. We found that using the packet index for the GDOI key-management index
>requires that (1) SRTP be co-resident with the key distribution center 
>(KDC) or that
>(2) some programming interface be implemented between SRTP and the KDC so the
>KDC can generate key management messages with the correct packet index as
>SPI.  We're taking the former (co-resident) approach. RFC 2401 defines a 
>security
>parameter index (SPI) as the means to uniquely identify a security association
>(or crypto context) when augmented with the destination transport address and
>protocol number.  This is how GDOI names a security association or crypto 
>context.
>
>3. We're not happy with the use of packet index since it only tells SRTP
>when to start using a new crypto context (or key).  In IPSEC, the SPI is a 
>32-bit
>value that does not change in the IPSEC packet until the security 
>association (SA,
>the crypto context in SRTP) changes.  In SRTP, the sequence number and 
>hence the
>packet index increase with each packet and the semantics are that all 
>packet indices
>greater than or equal to some value use a particular crypto context.  When 
>a new
>crypto context is given to SRTP by GDOI, there is another packet index 
>that identifies
>when to switch over to the new crypto context.  Thus, a new crypto context 
>is used
>when the SRTP packet index equals or exceeds that new number.  An SRTP 
>receiver,
>therefore, cannot ascertain when a problem with authenticating a packet is a
>result of using an old crypto context or a denial of service attack or 
>some other problem.
>It may happen that a new crypto context may start at the current value of 
>the packet index,
>but the SRTP receiver has somehow not received the new crypto 
>context.  That is, the
>MAC may fail to authenticate, but  the receiver won't be sure if it missed 
>a key update or
>not.
>
>4. We have two alternatives to problem #3.  First is to add an "end packet 
>index"
>so that SRTP can recognize when it's using an expired crypto context.  The
>problem with this is that there are some cases when a KDC will change the
>crypto context before the end packet-index is reached.  The second alternative
>is to use an optional 32-bit SPI just like IPSEC and some MSEC protocols 
>do.  The
>problem here is that it adds 32 bits to the RTP header, which is mitigated 
>by making
>this optional if that can be done cleanly.
>
>5. If we use RTP sequence numbers to control change in an SRTP crypto 
>context, we
>cannot use a key lifetime as IKE and IPSEC do for their SAs.
>
>We'd like to hear any opinions people may have regarding the two options in
>#4, above.
>
>Mark
>
>
>At 09:04 PM 3/13/2001 -0500, Colin Perkins wrote:
>>--> "David A. McGrew" writes:
>> >Mark,
>> >
>> >Mark Baugher wrote:
>> >>
>> >> Hi
>> >>    I think we will need the ability to alter or replace the
>> >> cryptographic context during an RTP session.   As I
>> >> read it, the cryptographic context is identified by
>> >> the SSRC of the sender and the RTP destination
>> >> transport-address.  That suggests to me that you cannot
>> >> change the crypto context during the life of an RTP session.
>> >> It may not be necessary to, say, replace an AES
>> >> key for the life of the longest RTP session imaginable.
>> >> But it is common to manage access control to
>> >> session data by managing the key.  There's no way
>> >> to do that with a fixed crypto context.
>> >>
>> >> thanks, Mark
>> >
>> >thanks for representing the multicast perspective here!  If I understand
>> >correctly, you are thinking of using SRTP encryption as an access 
>> control method
>> >in a multicast scenario.  That usage would certainly be in scope.
>> >
>> >In the current draft, there is a real need to have a unique SSRC-to-key 
>> mapping,
>> >since SRTP uses the synchronization information that's already in RTP 
>> (the SSRC
>> >is used to identify a context, and the RTP sequence number is used as 
>> well).  I
>> >suppose that it would be possible to change keys in a context as long 
>> as the new
>> >key were identified with a particular sequence number (so that all 
>> receivers
>> >would know when to start using that key).  This approach might work, 
>> though I
>> >hadn't considered it before; we've made the simplifying assumption of 
>> ssrc/key
>> >uniqueness.
>>
>>It sounds feasible, so long as it is possible to inform all receivers of
>>the new key within a single cycle of the RTP sequence number. That might
>>be a problem with high-rate streams, or with large groups.
>>
>>Colin

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

---

From: Mark Baugher <[email-masked]>
Date: Thu, 04 Oct 2001 12:28:47 -0700

Mark