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

From: "Fries, Steffen" <[email-masked]>
Date: Tue, 13 Jun 2006 09:48:06 +0200

Hi David,

I just though further about your comments regarding the complexity, when
transporting an additional variable length key management. Actually, I
don't think that this would be the case here. When sending only the DH
part of the callee back using EKT, you would have a fixed size. of the
DH part. MIKEY requires the support of the OAKLEY5 group, which has a
1536 bit prime coming to a fixed size of 192 byte to be transported. I
did not intended to tranport the complete MIKEY container over EKT, is
just the DH key of the caller. 

The nice property of this approach is that it has a fall back to the
normal MIKEY DHSIGN method, in case one of the participant would not
support the in-media-path addition. 

>From the discussion on the list, I got the impression that using RTP, as
thought first, would not be acceptable as the key exchange is part of
the control of the media data, which should be handled rather by RTCP.
RTCP would be fine to transport the DH half key. As it is just a half
key I think multiplexing as done by STUN would add to much overhead.

The follwoing figure shows the general MIKEY DHSIGN approach enhanced
with the transport of DHr in the media path and should explain the
general approach:

   Initiator                                 Responder

   I_MESSAGE (inside SIP)=
   HDR, T, RAND, [IDi|CERTi],
        [IDr], {SP}, DHi, SIGNi   --->

					    <---	   Intermediate
Message over RTCP
							   containing
DHr

                                             R_MESSAGE (inside SIP)=
                                  <---        HDR, T, [IDr|CERTr],
                                               IDi, DHr, DHi, SIGNr

Any thoughts?

Regards
	Steffen  

> -----Original Message-----
> From: David McGrew [mailto:[email-masked]] 
> Sent: Monday, June 12, 2006 4:27 PM
> To: Fries, Steffen
> Cc: Colin Perkins; [email-masked]; AVT
> Subject: Re: [AVT] RE: KM approach using MIKEY and EKT
> 
> Hi Stefen,
> 
> On Jun 12, 2006, at 4:34 AM, Fries, Steffen wrote:
> 
> > Hi Colin,
> >
> > well, the approach is merely independent of RTP or RTCP. I 
> thought RTP 
> > may be more suitable as RTCP is not mandatory and requires 
> opening an 
> > additional port in intermediate devices. But you are right, 
> RTCP may 
> > be a better place.
> 
> 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.
> 
> > 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.
> 
> 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
> >>
> 

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

---

From: David McGrew <[email-masked]>
Date: Mon, 19 Jun 2006 16:25:38 -0700

Hi Steffen,

> just the DH key of the caller.

I think that many implementations would regard an extra 192 bytes  
carried by every RTCP packet as too burdensome.  That would more than  
double the packet size, in a typical scenario.

> key I think multiplexing as done by STUN would add to much overhead.

I don't think that the overhead is that high.  The RTP implementers  
value the STUN-style demuxing because it ensures that the keying has  
only minimal interference with RTP, since it won't affect the RTP/ 
RTCP session (at least not directly).  Some RTP folks had to sit me  
down in a chair and explain this to me a few times before I  
understood their point, but I think that it's a valid one ;-)

>                                   <---        HDR, T, [IDr|CERTr],

OK, now I think that I understand completely what you're thinking  
of.  I'm a bit concerned that it won't be possible to send only the  
DHr over RTP/RTCP, since other values will need to go into the key  
derivation.  (See the NIST special pub on key derivation, for  
example.)   It might be possible if ephemeral DH keys are used, and  
not static DH keys, but then again that would be a limitation because  
keys that are static (at least for short periods of time) offer a  
performance optimization.  Also, if the key derived from the DH  
exchange gets used before it is authenticated, perhaps that will open  
up a useful avenue for an attacker.

best regards,

David