Subject: [AVTCORE] Comments on SRTP EKT (cont'd)

From: Yi Cheng <[email-masked]>
Date: Mon, 11 Aug 2014 08:52:09 +0000

Another email with Cisco’s response and Ericsson’s further comments

From: Yi Cheng
Sent: den 15 maj 2014 12:26
To: 'Dan Wing'
Cc: Flemming Andreason; David McGrew; Magnus Westerlund; John Mattsson
Subject: RE: MIKEY comments by Flemming

Hi again,

When a MIKEY peer that does not understand EKT receives an SRTP policy payload with extra EKT parameters, it will return an error message with error no. 10 ( Invalid SP parameter). Since the peer saw that the intended security protocol was SRTP,  according to RFC 3830 section 5.1.2

"If the Responder does not support the set of parameters suggested by

the Initiator, the error message SHOULD include the supported

parameters",

it should include an SP payload in the error message with normal SRTP parameters. Then the initiator will know that the peer supports only SRTP and re-initiate MIKEY accordingly.

We think this is better than introducing a new security protocol type. In that case the peer will only see an unknown security protocol and get no hint on what to propose in the error message.

As RFC 4771 also added new SRTP parameters to MIKEY, we hope legacy MIKEY implementations can handle unknown SRTP parameters in a good way ;-).

Best regards,

Yi

-----Original Message-----
From: Dan Wing [mailto:[email-masked]]
Sent: den 14 maj 2014 21:17
To: Yi Cheng
Cc: Flemming Andreason; David McGrew; Magnus Westerlund; John Mattsson
Subject: Re: MIKEY comments by Flemming

On May 14, 2014, at 12:00 AM, Yi Cheng <[email-masked]<mailto:[email-masked]>> wrote:

> Hi,

> John and me have reviewed the MIKEY part of the EKT Internet Draft. We see the following issues (Flemming has similar comments in FSA 49, FSA 50 and FSA 54):

> 1)      Section 5 specifies only how the EKT parameters (i.e. cipher, key, SPI) are to be transported in the MIKEY message. How the SRTP parameters are negotiated is not mentioned.

> 2)      As currently specified in section 5.1, when EKT is used together with MIKEY, we will have a  Security Policy (SP) payload with EKT as the Prot type and EKT cipher as the parameter. But we also need another SP payload to communicate SRTP parameters. What CS ID map info shall be given in the Common Header then? It’s not possible to have two policies associated with the same CS.

> One possible solution is to include the EKT cipher and EKT SPI in the SRTP policy. So we have a single policy with both SRTP parameters and EKT parameters, avoiding the mapping problem in 2). EKT SPI can then be used to retrieve the EKT parameter set, as specified in section 2.1. If we go for this we need to add EKT SPI and cipher to the SRTP policy parameter list (section 6.10.1 of RFC 3830) and remove the EKT security policy and cipher parameter from section 5.1.

In another email, Flemming pointed out this needs to be negotiable with a MIKEY peer that does not understand EKT.

>  What do you (Cisco) think? Does it make sense to transport both EKT key and TGK in MIKEY or do you prefer to use MIKEY to transport EKT key only?

None of the three of us understand MIKEY well enough to answer very authoritatively.  However, we agree faster call set-up times are desirable, which as you mention above is achieved by sending EKT key and TGK key in MIKEY, rather than using MIKEY to transport only the EKT key.

-d

> Best regards,

> Yi Cheng

> Ericsson Research

> 16480 Stockholm

> Sweden

> From: John Mattsson

> Sent: den 5 maj 2014 13:55

> To: Yi Cheng

> Subject: FW: MIKEY comments by Flemming

> 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 +46 10 71 43 501

> SMS/MMS +46 76 11 53 501

> [email-masked]<mailto:[email-masked]>

> www.ericsson.com<http://www.ericsson.com>

> This Communication is Confidential. We only send and receive email on

> the basis of the terms set out atwww.ericsson.com/email_disclaimer

> From: Dan Wing <[email-masked]<mailto:[email-masked]>>

> Date: Friday 4 April 2014 21:25

> To: John Mattsson <[email-masked]<mailto:[email-masked]>>

> Cc: Magnus Westerlund <[email-masked]<mailto:[email-masked]>>

> Subject: Re: MIKEY comments by Flemming

> On Apr 4, 2014, at 8:44 AM, Dan Wing <[email-masked]<mailto:[email-masked]>> wrote:

> On Apr 4, 2014, at 8:07 AM, John Mattsson <[email-masked]<mailto:[email-masked]>> wrote:

> Hi Dan,

> Magnus promised that Oscar Ohlsson from Ericsson would review the MIKEY part of EKT. Oscar has now stopped working with security so I ll do the review instead. In your mail to Magnus you said:

> "Can the chairs solicit a co-author or reviewer who understands MIKEY and can ensure that EKT accurately describes EKT's operation with MIKEY.  We have some comments against the MIKEY section by Flemming but unfortunately all three of us are not familiar enough with MIKEY to satisfactorily close those comments."

> They were sent to me, as editor.  Flemming is one of the authors, which is why it didn't get posted to the list.  I'll find it later today and email it to you.

> Attached are Flemming's comments.  I cut the stuff above and below the MIKEY section, so you can simply print or review the attached.  I cut using Track Changes, so if you wanted to see Flemming's other comments for context you can still see them.

> -d

> -d

> I cannot find these comments by Flemming. Were they send in private or on some other list than AVTCORE?

> Cheers John

> <13DEFB94-F735-49B0-8196-BDB5C9017A32[4].png>

> 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 +46 10 71 43 501

> SMS/MMS +46 76 11 53 501

> [email-masked]<mailto:[email-masked]>

> www.ericsson.com<http://www.ericsson.com>

> <D377E800-0A1A-43D3-AF5E-165F697789B5[4].png>

> This Communication is Confidential. We only send and receive email on

> the basis of the terms set out atwww.ericsson.com/email_disclaimer