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

From: David McGrew <[email-masked]>
Date: Tue, 6 Jun 2006 09:32:33 -0700

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: "Fries, Steffen" <[email-masked]>
Date: Mon, 12 Jun 2006 16:40:07 +0200

Hi David,

> the problem with running a key management protocol over RTP 
> is that is interacts very badly with the system optimizations 
> that are in  
> place for the 'real time' aspects of the protocol.   I'll second  
> Colin here; if the key management protocol has message sizes 
> that are small and fixed (or bounded at least) then EKT over 
> RTCP would be appropriate.  Otherwise, using the STUN/ICE 
> approach to multiplexing additional protocols over the RTP or 
> RTCP port would be preferable.
[stf] okay, agreed. The message size would be fixed according to the
chosen DH parameter size

> 
> > My first concern was to see if the security properties of this 
> > approach would be acceptable.
> >
> 
> Yes, that's an interesting and quite separate question!  In 
> any system that performs keying in the 'media plane', there 
> will be the issue of whether or not the system allows media 
> to flow prior to the  
> completion of the key setup protocol.   In your Diffie-Hellman based  
> proposal, the weakness would be that the DH public key might 
> be used before it is authenticated.  I agree with you that 
> this is a relatively small weakness, though we should 
> consider what happens if an active adversary subverts the DH 
> protocol then blocks the signaling message that would show 
> the participant that an attack was in progress.  I am a bit 
> concerned that if we're not careful we'll create a system 
> that is hard to use securely.  In particular, the system has 
> both high and low security options, it must be easy for a 
> user to know which state the system is in.
[stf] also agreed. If an attacker blocks the signaling message 
containing the response container, then the caller's application 
should react appropriately, e.g., send an error message back 
and warn the user (if the message is blocked, the caller still 
could not send media as he does not have the appropriate target 
information.) This is generally to be considered, that the 
security state should be signaled to the user as unsecure till 
the final MIKEY answer has been received. After validating the 
response, the client can signal the security state toward the 
user as secure. Interesting here is that the caller's application 
should not transmit media until the final security answer (MIKEY) 
is received (more a policy thing).

Regards
	Steffen

> 
> David
> 
> 
> > Regards
> > 	Steffen
> >
> >> -----Original Message-----
> >> From: Colin Perkins [mailto:[email-masked]]
> >> Sent: Sunday, June 11, 2006 12:49 PM
> >> To: Fries, Steffen
> >> Cc: David McGrew; [email-masked]; AVT
> >> Subject: Re: [AVT] RE: KM approach using MIKEY and EKT
> >>
> >> Steffen,
> >>
> >> On 9 Jun 2006, at 16:55, Fries, Steffen wrote:
> >>> 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),
> >> ...
> >>
> >> 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
> >>
>