[asterisk-dev] SRTP key lifetime bug

Thu Sep 5 14:46:17 CDT 2013

5 sep 2013 kl. 21:34 skrev Matthew Jordan <mjordan at digium.com>:

> 
> On Thu, Sep 5, 2013 at 12:28 PM, James Cloos <cloos at jhcloos.com> wrote:
> >>>>> "OEJ" == Olle E Johansson <oej at edvina.net> writes:
> 
> OEJ> even if the lifetime is 2^31 packets which is quite a long call,
> OEJ> spanning decades, with a rate of 50 packets per second.
> 
> Side note:  2^31 packets at 50 packets/s == 497.1 days.
> 
> OEJ> We do not have to answer with any attributes on our key. The key
> OEJ> attributes are just declarative, not an offer/answer item.
> 
> Given that,
> 
> OEJ> assume no calls will be that long or that if they are, the other end
> OEJ> will start a key reset.
> 
> and the possibility of assuming that the other side will start a reset
> when the advisory timeout which they specified occurs, it seems like it
> would be enough just to accept the nego w/o bothering to confirm that
> the other side holds to their advised key timeout, yes?
> 
> Ie, do nothing more than a verbose() or debug() call with the timeout
> info and proceed as though it were not speficied?
> 
> OTOH, for performance and quality reasons, rejecting nego when the
> timeout is less than a few seconds seems useful.  For some definition
> of a few.
> 
> So, I'll start with "how should this behave" and move on from there.
> 
> First, we should never ignore a lifetime request. Either we support it, or we don't.
You always do, but you may not signal it.

> Yes, most endpoints send a ludicrously high lifetime request - which by itself should inform us all about how worthwhile this particular feature is - but if it sends us a key lifetime, we need to honor it. We could go down the road of parsing the lifetime and, if it is suitably high, lie to the UA and say that we do support it; if it is suitably low, respond with a 488. However, that road feels fraught with peril. What is the magic level that Asterisk allows? Do we make that configurable as well?
> 
> (And let's face it, someone will run a SIP device connected to Asterisk for 480 some odd days. Then there's a bug report of no audio.)
> 
> To date, all patches [1] have been of the 'ignore' variety; hence why they haven't received a very high priority. It doesn't feel like the correct solution.
> 
> If we do implement key lifetimes, I would assume we would behave in the following way:
> 
> 1. When we receive a key lifetime, we set limits on the number of packets we'll receive.
SEND! We receive a key and the lifetime for that key when we encrypt with it and send to the other side.

> After we hit that limit - for both SRTP and SRTCP - we just start dropping the packets on the floor, preferably with a nice WARNING. If we get a re-INVITE that refreshes the master key, we reset the counter. We do not issue a re-INVITE ourselves.
THis is for the lifetime we send - which we might not do. 
When we hit the other side's lifetime we should stop sending. But before that, we should send a re-INVITE to hint that we need a new key. That part doesn't seem well documented.
> 
> 2. If we send a key lifetime, we also enable period transmits that refresh the master key. Those periodic retransmits should be based on the key lifetime, and set up to ensure that we generate a new key before the old key expires. This will probably require some tweaking in the rtp_engine and res_srtp, as how keys are associated with an RTP stream is a bit tricky (particularly since we use wild card policies for remote keys and stream specific policies for local keys). We could rely on RFC 4028 support; however, there's nothing that says that you must have SIP session timer support in order to support re-freshing the master key. I'd prefer the two to be independent myself.
> 
> Now, is this a bug?
> 
> I'll quote myself here:
> 
> {quote}
> This is not a bug but a feature request.
> 
> Asterisk at this time does not support lifetime for cryptographic keys (which is the part after the | in the key). As such, this issue will be closed out unless a patch is provided which actually adds support in Asterisk for lifetime.
> {quote} 
> 
> And now I shall sort of disagree with myself.
> 
> Most phones I've run into support disabling lifetime of keys (SNOMs, in particular). There are some devices out there, however, that do not and this does become a compatibility issue for those devices. We've certainly done heavy lifting in the SRTP support for compatibility problems in the past (most notably when certain devices would changes the keys on re-INVITEs, regardless of having a lifetime parameter in the negotiation). I'd lay it out this way:
> 
> * Any solution should be backwards compatible with Asterisk itself, such that Asterisk with lifetime support can send an INVITE request with an SDP containing SDES-SRTP keys to another Asterisk instance without that support and have the call work.
We don't have to send. If we don't the default applies.
> 
> * Any solution should actually -support- key lifetimes.
Yes.
> 
> * Tests verifying lifetime support would be needed to ensure that it's actually functional and doesn't introduce any regressions. Since most endpoints don't send lifetimes that are realistic, the only way you can verify that Asterisk will actually kill SRTP packets if a lifetime is violated or re-fresh the key appropriately is if the lifetime is set to something low.
Yes.
> 
> If we hit all three of those points, I'm good with it going into 1.8 and 11.
Ok, then we agree. 
Now we need coders and funding for them.

/O
> 
> [1] https://issues.asterisk.org/jira/browse/ASTERISK-17899
> 
> Matt
> 
> -- 
> Matthew Jordan
> Digium, Inc. | Engineering Manager
> 445 Jan Davis Drive NW - Huntsville, AL 35806 - USA
> Check us out at: http://digium.com & http://asterisk.org
> --
> _____________________________________________________________________
> -- Bandwidth and Colocation Provided by http://www.api-digital.com --
> 
> asterisk-dev mailing list
> To UNSUBSCRIBE or update options visit:
>   http://lists.digium.com/mailman/listinfo/asterisk-dev

---
* Olle E Johansson - oej at edvina.net
* Cell phone +46 70 593 68 51, Office +46 8 96 40 20, Sweden

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-dev/attachments/20130905/19e6d5d9/attachment.htm>