Re: [AVTCORE] EKT update, draft-ietf-avtcore-srtp-ekt-02

[John Mattsson <[e-mail]>]

I think the changes made to 02 seems good, I have not had time to check
them in detail.

I have some comments on Section 3 “Use of EKT with SDP Security
Description”

- Seems to be unclear if you can mix EKT with non-EKT.
- Both “EKT” and “EKT_Cipher” seems to be called SDP session parameters.
Sometimes “EKT session parameters” and “EKT parameters” is used. I think
the terminology needs consistency.
- Should SDESC always negotiate different EKT keys in the send and receive
direction?
- Are the crypto attributes uniquely identified by SPI or not?


Cheers John


---------------------------------------------------------------------------
------




-[3] One remaining “SDES" -> "SDESC"


-[3.1] "The second crypto attribute has the tag "2", the crypto-suite
F8_128_HMAC_SHA1_80, two SRTP master keys and associated salts."

It only has one SRTP master key (which I think is correct).


-[3.2] "EKT solves this problem by simply sending the master key used in
the media plane thereby avoiding the need for security preconditions."

But you still need to wait for the answer, otherwise you do not have the
EKT key, or?


-[3.2] "whereas EKT addresses the shortcomings of SDESC."

I would suggest "some of the shortcomings"


-[3.2] "If multiple crypto-suites were offered, the offerer also will not
know which of the crypto-suites offered was selected until the answer is
received. EKT solves this problem by using a correlator, the Security
Parameter Index (SPI), which uniquely identifies each crypto attribute in
the offer."

This seems strange. If you use a single SPI you could start using that
before receiving an answer but if you have unique SPI, you must still wait
for the answer.

In the example in section 3.9  both crypto-suites use the same SPI
("AAE0"). Should one of the SPI be e.g. "AAE1"?


-[3.4] "the following new SDESC session parameters are defined" ....
"EKT_Cipher, EKT Keys"

I think "EKT" is the only new SDESC session parameter. I don't know what
“EKT_Cipher” etc should be called, but they should be called something
else and section 3 should be consistant.


-[3.5.1]
"If a given crypto attribute includes more than one set of SRTP key
   parameters (SRTP master key, salt, lifetime), they MUST all use the
   same salt.  (EKT requires a single shared salt between all the
   participants in the direct SRTP session)."

Should this be deleted? Without MKI, I do not see how this is possible
except by trial-and-error?


-[3.5.1]
“For each unicast media line using Security Descriptions and where use
   of EKT is desired, the offerer MUST include one EKT_Key parameter and
   one EKT_SPI parameter in at least one "crypto" attribute (see
   [RFC4568]).”

"each offered crypto attribute contains a candidate EKT parameter set."

Seems to be unclear if you can mix EKT with non-EKT.
Can you really use several crypto attributes without MKI?

-[3.5.1]
"As EKT is not defined for use with MKI, the offer and the answer MUST
   NOT contain MKI."

Is this true also for the m-lines or crypto attributes without EKT? (if
mixing EKT and non-EKT is allowed)

-[3.5.1]
"for a particular SRTCP packet"

->"SRTP or SRTPC packet".

-[3.5.2] “For each unicast media line using SDESC, the answerer examines
the
   associated crypto attribute(s) for the presence of EKT parameters.
   If mandatory EKT parameters are included with a "crypto" attribute,
   the answerer MUST support those parameters in order to accept that
   offered crypto attribute.  If optional EKT parameters are included
   instead, the answerer MAY accept the offered crypto attribute without
   using EKT.  However, doing so will prevent the offerer from
   processing any packets received before the answer.  If neither
   optional nor mandatory EKT parameters are included with a crypto
   attribute, and that crypto attribute is accepted in the answer, EKT
   MUST NOT be used.  If a given a crypto attribute includes a mixture
   of optional and mandatory EKT parameters, or an incomplete set of
   mandatory EKT parameters, that crypto attribute MUST be considered
   invalid.

"What is “EKT parameters”, is that the whole
“EKT=AESKW_128|VHdvTG92ZWx5RUtUa2V5cw|AAE0”? But then there should be at
maximum one per crypto attribute...

-[3.9]
The SDP example still includes MKI. I assume you should also remove the
second key in tag 2


-[3.9]
The SDP example does not have a Figure caption (i.e. Figure X: )



-----------------------------------------------------------------------

JOHN MATTSSON
MSc Engineering Physics, MSc Business Administration and Economics
Ericsson IETF Security Coordinator
Senior Researcher, Security

Ericsson AB
Security Research
Färögatan 6
SE-164 80 Stockholm, Sweden
Phone [phone]
SMS/MMS [phone]
[e-mail]
www.ericsson.com <http://www.ericsson.com/>







On 15/02/14 01:30, "Dan Wing" <[e-mail]> wrote:

>We just posted draft-ietf-avtcore-srtp-ekt-02,
>http://tools.ietf.org/html/draft-ietf-avtcore-srtp-ekt-02.
>
>It contains a brief summary of changes,
>http://tools.ietf.org/html/draft-ietf-avtcore-srtp-ekt-02#section-1.1,
>  In draft-ietf-avtcore-srtp-ekt-02 (this document), SRTP master keys
>  have to be always generated randomly and never shared, MKI is no
>  longer allowed with EKT (as MKI duplicates some of EKT's functions),
>  and text clarifies that EKT must be negotiated during call setup.
>  Some text was consolidated and re-written, notably Section 2.6
>  ("Timing and Reliability").
>
>Additionally, -02 removed the ability to re-direct DTLS-SRTP handshake to
>another host ("Scaling to Large Groups" which introduced the SDP
>attribute dtls-srtp-host).  This was removed because the only interested
>person never responded to my emails, and because proper support really
>needs ICE- or ICE-like handling for NAT traversal.  If interest grows,
>this can be done in a separate draft, and may have value even without EKT.
>
>
>As you may recall, there were a bunch of great comments from Magnus,
>Michael, and John.  Almost all of those were integrated into -02, with
>the exception of those I was hoping to get feedback from the working
>group, which I had discussed in [1], "changes planned for EKT" where I
>summarized some planned changes.  In that post, I had written:
>
>> 1. Only use EKT over SRTP, and remove the ability to send EKT over
>>SRTCP.  As you may recall, EKT originally worked only over SRTCP, then
>>added support for both SRTP and SRTCP.  Our desire to abandon SRTCP is
>>because of several deficiencies with carrying EKT over SRTCP compared to
>>carrying EKT over SRTP, specifically:
>> - SRTCP compound packet problem described in Magnus' review (his point
>>"G2").  See URL to his review below.
>> - lack of fate sharing between SRTCP (signaling the new SRTP master
>>key) and SRTP (using the new SRTP master key).
>> - RTCP rate limits for AVP and AVPF profiles, which prevent sending EKT
>>in SRTCP as aggressively as one might like when rekeying or when joining
>>a session as a new sender.
>> - unsure how we might handle ISN (initial sequence number) for the key
>>protecting SRTCP (immediately or later), because RTCP does not have a
>>sequence number.
>> - implementations would have to support EKT over RTP and RTCP.
>
>
>Due to unidirectional audio (recvonly, sendonly), limiting EKT to only
>RTP means we need to send an RTP packet.  While my confidence was high
>that we would never need or want to change the SRTCP key when using EKT
>(and hence not need to ever send an RTP packet with EKT), I admit this
>does not seem to be consensus.
>
>The authors were unable to resolve the SRTCP compound packet issue
>noticed by Magnus.  Details of the issue are in Magnus' review, see URL
>below.  I believe the best we can do is document this problem in the
>specification, and provide an additional encouragement to use
>EKT-over-SRTP.  Comments or feedback or better ideas?  I have some
>candidate text pointing out the problem and providing further
>encouragement to use EKT-over-SRTP (rather than EKT-over-SRTCP), but I am
>not yet happy with the text (see [2], below).
>
>The other points in the bulleted list (fate sharing, RTCP rate limits,
>ISN) were added to draft-ietf-avtcore-srtp-ekt-02.
>
>
>> 2. require SRTP master keys to always be randomly generated and never
>>shared between sessions, ever.
>
>New text in draft-ietf-avtcore-srtp-ekt-02,
>
>  All SRTP master keys MUST NOT be re-used, MUST be randomly generated
>  according to [RFC4086], [and] MUST NOT be equal to or derived from other
>  SRTP master keys.
>
>
>> 3. Remove MKI support from EKT, as they are duplicative functions.  As
>>a reminder, MKI (master key index) is defined in SRTP (RFC3711) and
>>allows to pre-stage a key using call setup key signaling (e.g., Security
>>Descriptions, MIKEY, DTLS-SRTP, etc.), whereas EKT has its own mechanism
>>to perform a similar function (ISN, initial sequence number, which is
>>when a pre-staged key will be used).  Currently the EKT draft has a weak
>>discussion of how these interact, and instead of improving this text and
>>imposing the implementation burden for MKI support on EKT endpoints, we
>>would like to declare MKI with EKT as unsupported and out of scope.
>
>MKI is now prohibited with EKT in draft-ietf-avtcore-srtp-ekt-02.
>
>
>> 4. Require EKT to be negotiated during call setup, and require
>>endpoints to wait until receiving the EKT Full Field packet (containing
>>the decryption key) before attempting to authenticate packets (to avoid
>>doubling authentication effort).  This avoids new joiners attempting to
>>authenticate two packets when they join an EKT session (the first
>>attempt using the SRTP master key from normal key-management (MIKEY,
>>SDESC, DTLS-SRTP, whatever) and if that fails the second attempt from
>>the EKT-provided SRTP master key).
>
>EKT is now required to be negotiated during call set-up in
>draft-ietf-avtcore-srtp-ekt-02.
>
>
>> 
>> Review URLs:
>> Magnus Westerlund review,
>>http://www.ietf.org/mail-archive/web/avt/current/msg16109.html
>> Michael Peck review,
>>http://www.ietf.org/mail-archive/web/avt/current/msg16107.html
>> John Mattsson review,
>>http://www.ietf.org/mail-archive/web/avt/current/msg16095.html
>> 
>> 
>
>
>[1] http://www.ietf.org/mail-archive/web/avt/current/msg16129.html
>
>[2] candidate text providing further incentive for EKT-over-SRTCP:
>
>  2.5.  Transport
>
>  EKT SHOULD be used over SRTP, and MAY be used over SRTCP.  SRTP is
>  preferred because it shares fate with transmitted media, because SRTP
>  rekeying can occur without concern for RTCP transmission limits, and
>|  because of SRTCP compound packets with RTP translators and mixers.
>|  This specification requires the EKT SSRC match the SSRC in the RTCP
>|  header, but Section 6.1 of [RFC3550] encourages creating SRTCP
>|  compound packets:
>|
>|     It is RECOMMENDED that translators and mixers combine individual
>|     RTCP packets from the multiple sources they are forwarding into
>|     one compound packet whenever feasible in order to amortize the
>|     packet overhead (see Section 7).
>|
>|  These compound SRTCP packets might have an SSRC that does not match
>|  the EKT SSRC.  There is no good solution to handling these SRTCP
>|  compound packets, except hoping the mixer or translator round robin
>|  between the SSRCs, but this would require several SRTCP packets,
>|  further delaying receipt of EKT over RTCP.  This impact of RTP
>|  translators and mixers, and the inability to realibly determine an
>|  RTP translator or mixer might be involved in an RTP session, provides
>|  further incentive to send EKT over RTP.
>
>-d
>
>
>
>
>_______________________________________________
>Audio/Video Transport Core Maintenance
>[e-mail]
>https://www.ietf.org/mailman/listinfo/avt