Subject: [AVT] RE: KM approach using MIKEY and EKT

From: "Fries, Steffen" <[email-masked]>
Date: Fri, 9 Jun 2006 17:55:45 +0200

Hi David,

thanks for your explanation. I understand that enhancing EKT with this
would make it more complex. By thinking more about my initial approach I
think we could even use plain RTP with the appropriate payload type to
send the DH parameter (I have to check that), without using EKT also
gaining a secure media path. For the phase from receiving the DH half
key of the callee till receiving the final MIKEY response, there is only
the chance for the callee to provide audio. As long as the SIP response
is not received at the caller, he cannot provide the media as he does
not have a target port to send to. Thus the security decrease by using
an unauthenticated DH half key for a limited time should not be high.

Regards
	Steffen

> -----Original Message-----
> From: David McGrew [mailto:[email-masked]] 
> Sent: Tuesday, June 06, 2006 6:33 PM
> To: Fries, Steffen
> Cc: [email-masked]; AVT
> Subject: Re: KM approach using MIKEY and EKT
> 
> Hi Steffen,
> 
> I think that I understand the problems that you're solving, 
> and the hybrid approach (with the first KM message going over 
> signaling, and the second over the media) that you're 
> describing would work, but EKT is not very suitable for 
> transporting another protocol.  Currently, the EKT payloads 
> are defined in terms of the participant's SRTP context, and 
> there is a very simple protocol state machine (if an EKT 
> message authenticates properly, then the SRTP master key that 
> it conveys should be stored so that it can be used to process 
> subsequent SRTP messages).  This method is simple, and 
> results in EKT fields  
> that have small, fixed sizes.   The constant size of the fields  
> enable the SRTCP implementation to accommodate the additional 
> fields into the RTCP bandwidth calculations.
> 
> To use EKT to convey messages for an arbitrary key management 
> protocol would add a good amount of complexity to it.  The KM 
> protocol state machine, complete with retransmissions, would 
> become a factor.  It would also add the complication that the 
> (S)RTCP packet sizes would vary, which would change the 
> bandwidth allocation for SRTCP.  Also, adding support for a 
> public-key method inside of EKT could make the RTCP packets 
> quite large, which in some cases would interfere with normal 
> RTP/RTCP operation.
> 
> Another point is that EKT as defined works for 
> point-to-multipoint cases, while the MIKEY-over-EKT would be 
> restricted to point-to- point.  This is important because EKT 
> relies on SSRCs to identify sources, while SSRCs are most 
> likely not sufficient to identify sources for MIKEY.  
> (Consider the SIP forking scenario; the offerer needs to 
> track the MIKEY responders by their source addresses.  How 
> could we implement this without making EKT 'know' about source
> addresses?)
> 
> All that said, I think that it is actually possible to do 
> what you're describing with EKT as defined by the current 
> draft, by defining a new "EKT Cipher" that is in actuality an 
> interface to a key management protocol.  (This might be 
> abusing the intent of the specification, but the draft was 
> written to be general so it looks like it conforms to the 
> letter of the specification.)  From Section
> 2.3.3:
> 
>     An EKT cipher determines how the Encrypted Master Key field is
>     written, and how it is processed when it is read.  This field is
>     opaque to the other aspects of EKT processing.  EKT 
> ciphers are free
>     to use this field in any way, but they SHOULD NOT use other EKT or
>     SRTP fields as an input.  The values of the parameters L, 
> M, N, and T
>     MUST be defined by each EKT cipher, and those values MUST be
>     inferable from the EKT parameter set.
> 
> To transport an arbitrary key management protocol, you would 
> need to define an "EKT Cipher" that had a variable-length 
> payload, and which contained a field that described its 
> length.  I am not sure how the RTCP bandwidth computations 
> would be done; perhaps there would need to be an interface 
> between the EKT Cipher and the RTCP implementation that would 
> notify RTCP about the different payload sizes (so that RTCP 
> could start sending more packets once the key negotiation is 
> over).  Please understand that I'm *not* recommending using 
> EKT as a general-purpose transport here; I just want to point 
> out that there is some flexibility in the definitions that 
> might be useful.
> 
> The STUN approach to multiplexing additional protocols over 
> the RTP ports (as used in DTLS-SRTP, see Section 3.6.2 of http://
> scm.sipfoundry.org/rep/ietf-drafts/ekr/draft-mcgrew-dtls-srtp.html)
> provides better separation between the additional key 
> management protocol and the RTP implementation.  I think that 
> it is preferable over using EKT as a general-purpose 
> transport for a key management protocol.  It could be used 
> with a key management protocol that uses a 'hybrid' 
> signaling/media approach to transporting its packets.  As an 
> aside, I'm not convinced that a hybrid approach is the best 
> way to go.  Some coordination between signaling and the key 
> management protocol is needed, of course, but I suspect that 
> it is best to minimize the burden that we put on the 
> signaling plane and the properties that we expect from it.
> 
> Lastly, I should mention that I'd like to have EKT become a 
> WG item in AVT, and if the WG thinks that EKT should be able 
> to convey an arbitrary key management protocol, I'd be OK 
> with that.  However, I suspect that the reverse is true, and 
> that the WG would prefer to keep EKT simple (and keep EKT 
> field sizes fixed).  (I've added the AVT email list to the CC 
> line to solicit comments.)
> 
> David
> 
> P. S. - Sorry to take so long to respond.  The problem is 
> complex enough that there are no simple answers :-)
> 

> On May 15, 2006, at 1:08 AM, Fries, Steffen wrote:
> 
> > Hi David,
> >
> > based on the discussion we had during the last IETF meeting and the 
> > requirements discussed on the list here I would like to share some 
> > ideas regarding the interworking of EKT and MIKEY. The current EKT 
> > document does not talk about the cooperation of both in specific.
> > It rather mentions the usage of MIKEY to establish the EKT 
> key, cipher 
> > and SPI values in section 4.
> >
> > Combining EKT with MIKEY would be advanterous for the MIKEY modes 
> > needing a full roundtrip. What I have in mind are 
> specifically the DH 
> > approaches but also the rsa-r method could gain from it. Here the 
> > following may be supported with EKT, keeping in mind that 
> early media 
> > and forking are the important issues. A is sending an INVITE to B 
> > including the MIKEY I_message containing a signed DH half 
> key as well 
> > as a new payload indicating the use of EKT. Upon reciving 
> this INVITE 
> > B can use his DH half key and can calculate the DH secret, 
> derive the 
> > SRTP master key for the connection to A. B's DH half key can now be 
> > fed into EKT and send over to A via SRTCP (or even SRTP, if EKT is 
> > going to support it). Upon receiving the DH half key A can also 
> > calculate the DH secret and start to decrypt the received 
> SRTP stream. 
> > B sends the MIKEY_R message also in the signaling back to A.
> > Upon receiving this message A is in a position to verify, 
> that he got 
> > the same DH half key via EKT as he received in MIKEY. This is to 
> > provide A with the assurance that nobody performs a MitM 
> attack on the 
> > media path. EKT requires a shared key to protect the key 
> distribution, 
> > which is not in place here. One may use a signed DH to cope 
> with this 
> > or, when using an unsigned DH, start with SRTP based on the 
> received 
> > parameter and get a delayed, authenticated DH, via the signaling.
> >
> > This approach would solve both the early media and the forking.
> > Early media is ensured, as EKT is transported directly to B inside 
> > SRTCP (or even inside SRTP, if this is going to be 
> defined). Moreover 
> > the forking is eased as now, security precondition may not 
> be needed 
> > and thus the provisional responses connected with the security 
> > preconditions do not need to be sent.
> >
> > Problems I see here are the following:
> > - The caller gets the assurance about the quality of the 
> security when
> >   receiving the 200 OK. Before that he cannot be sure regarding a 
> > MitM.
> > - Fragmentation. As signed DH messages or asymmetric encrypted 
> > messages
> >   are rather large, the common path MTU boundary may be crossed.
> > Therfore
> >   the approach with the unsigned DH above.
> >
> > What's your opinion to that approach? Would that be something to 
> > include in the EKT ID when it is updated?
> >
> > Regards
> >   Steffen
> 

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

---

From: Colin Perkins <[email-masked]>
Date: Sun, 11 Jun 2006 11:48:56 +0100

Steffen,

On 9 Jun 2006, at 16:55, Fries, Steffen wrote:
> send the DH parameter (I have to check that),
...

I would strongly recommend against that. We have an RTP control  
protocol to avoid putting control into RTP data packet. Either use it  
-- which would be my preferred approach -- or multiplex a separate  
protocol onto the RTP port (as done with ICE).

Colin