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

From: "Fries, Steffen" <[email-masked]>
Date: Mon, 12 Jun 2006 13:34:07 +0200

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. My first concern was to see if the security properties
of this approach would be acceptable. 

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, 12 Jun 2006 07:27:21 -0700

Hi Stefen,

On Jun 12, 2006, at 4:34 AM, Fries, Steffen wrote:

> 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

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

---

From: Randell Jesup <[email-masked]>
Date: Mon, 12 Jun 2006 11:11:44 -0400

David McGrew <[email-masked]> writes:
>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.

For in-band keying, where there's no or low security before completion,
there are two ways it can be approached.  One is to send "muted" data -
silence for audio, for example - until the connection is secure.  So media
is being exchanged, but no information is and no security issue is raised.
When talking to a non-secure endpoint (that doesn't understand the in-the-
stream key negotiation) you'd get silence.  (The same would apply, btw, to
RTCP-based negotiation.)  The other is to allow early media flows under no
or low encryption, but provide some combination of notification of
negotiation failure and/or hard shutoff if a secure channel isn't completed
within a short timeframe.  Some information can leak in that short interval
(such as who the participants are), but overall the security provided is
good in practice, doubly so if it's a call where you know you care about
security.  The time required should be at most a few RTTs, even allowing
for some level of packet loss.  If it's in-band (say via header
extensions), you can attach the handshake to all packets until ACKd by
the other side, so you don't have to do a wait-and-retransmit.  

Too bad it's not easy with current SDP to specify by payload type whether a
stream is encrypted or not.  Currently, you have to have a separate media
stream (which means all sorts of problems for TURN, for compatibility with
existing endpoints, NATs, etc, etc - not to mention that how to provide
"groupings" or alternate media streams is horribly poorly (and multiply)
defined currently.)  Or you have to get non-standard like:

m=audio 1234 RTP/AVP 96 97
a=rtpmap:96 PCMU/8000
a=ftmp:96 in-media-keying:true
a=rtpmap:97 PCMU/8000

RTCP is conceptually simpler.  Older implementations not supporting it
isn't an issue (you're not going to negotiate encryption with them
anyways).  The biggest issue would be with NATs, relays and B2BUAs that
might block or modify RTCP, and SIP servers that might remove a=rtcp SDP
lines (or not correctly update them in an SBC).

These have the same issues that any in-media-stream key negotiation has: if
it's an extension (ala ZRTP), it increases the bandwidth which in some
cases might cause problems (3G or other tightly-QOS'd channels).  This
might be possible to avoid by layering the key exchange data on top of
(certain) data protocols.  For example, you could put the negotiation into
G.711 overlaid on top of a "pure silence" signal.  To the other end, if it
didn't support this negotiation, it would appear like a small amount of
noise at the start of the conversation (and it could be encoded into
low-order bits to avoid it being loud white noise).  It could even be
encoded on top of real audio data as low-level noise ala steganography.
In-stream media protocol converters will of course interfere or block
end-to-end key negotation (whether the negotiation is by RTP or RTCP).

-- 
Randell Jesup, Worldgate (developers of the Ojo videophone), ex-Amiga OS team
[email-masked]

---

From: David McGrew <[email-masked]>
Date: Mon, 26 Jun 2006 07:17:10 -0700

Hi Randell,

On Jun 12, 2006, at 8:11 AM, Randell Jesup wrote:

>> system

This is certainly the higher-security solution, but it goes against  
the requirement to work with media-before-answer, at least in the  
case in which the SIP answer is required before the other endpoint  
can be authenticated.

I think that it would be best to not send any media packets at all  
pending the establishment of keys, so that the key establishment can  
make full use of the bandwidth.  This is what we wrote up in dtls-srtp.

> within a short timeframe.

Right, and the facility for notification is needed whenever media- 
before-answer is possible, since authentication (of the answerer)  
won't take place until the answer is received.  Ideally, the  
notification would indicate that the call is "not yet authenticated"  
during the initial stage, instead of waiting until the timeout at the  
SIP layer before notifying the user.

It's tempting to think of a background noise that could indicate the  
lack of authentication, but I bet this might interfere with some  
applications (like DTMF or fax).

> Some information can leak in that short interval
> security.

As Dan Wing pointed out, it's better than no security at all :-)

> The time required should be at most a few RTTs, even allowing

Well, when there is an attacker who blocks the SIP answer (because it  
would reveal that there is a man-in-the-middle), then the time in  
which the session would be unauthenticated is probably determined by  
the SIP timer expiration.  Of course, if that would take too long, we  
could add in a new timer just for the purpose of bounding the amount  
of time that we'd allow a session to go on without any authentication.

> anyways).

That's a good point.

> The biggest issue would be with NATs, relays and B2BUAs that

Ugh.

David

---

From: Randell Jesup <[email-masked]>
Date: Mon, 26 Jun 2006 14:11:57 -0400

David McGrew <[email-masked]> writes:
>Randell Jesup wrote:
>> silence for audio, for example - until the connection is secure.  So
>> media is being exchanged, but no information is and no security issue is
>> raised.
>
>This is certainly the higher-security solution, but it goes against  the
>requirement to work with media-before-answer, at least in the  case in
>which the SIP answer is required before the other endpoint  can be
>authenticated.
>
>I think that it would be best to not send any media packets at all  pending
>the establishment of keys, so that the key establishment can  make full use
>of the bandwidth.  This is what we wrote up in dtls-srtp.

Bandwidth for key exchange shouldn't be that significant - there's no
reason it should be more than the equivalent of a few media packets for
audio, and less than 1 for most video.  You could even skip (recoverable/
concealable) packets on send to account for the key bandwidth, depending on
the codec.  (For video you could just skip encoding a frame.)

That said, some situations (3GPP) might have strict QoS limits on bandwidth
and might require skipping, or even limits on media packet lengths.  That's
where RTCP has an advantage - it's allowed to be variable-length and has
its own bandwidth limits (5% typically), so a somewhat longer-than-normal
initial RTCP would at worst delay when you can next send RTCP.  The
downside is that if it's lost, it's that much longer until you can try
again.

>> When talking to a non-secure endpoint (that doesn't understand the
>> in-the- stream key negotiation) you'd get silence.  (The same would
>> apply, btw, to RTCP-based negotiation.)  The other is to allow early
>> media flows under no or low encryption, but provide some combination of
>> notification of negotiation failure and/or hard shutoff if a secure
>> channel isn't completed within a short timeframe.
>
>before-answer is possible, since authentication (of the answerer)  won't
>take place until the answer is received.  Ideally, the  notification would
>indicate that the call is "not yet authenticated"  during the initial
>stage, instead of waiting until the timeout at the  SIP layer before
>notifying the user.

Yes; or (depending on the device) active notification when authenticated.
You have to be careful that you don't make active authentication spoofable
(like an audio tone or message).

>It's tempting to think of a background noise that could indicate the  lack
>of authentication, but I bet this might interfere with some  applications
>(like DTMF or fax).

You could also use an occasional beep to indicate negative authentication.
Inbound DTMF shouldn't be a significant issue, since that would normally be
to an IVR system of some sort.  Inbound FAX might be more of one, but I
think that could be dealt with in the design of the UA the analog (legacy)
fax attaches to, or allow for some level of configuration.  There are
better ways I think to send 'faxes' over secure channels, anyways.

>would reveal that there is a man-in-the-middle), then the time in  which
>the session would be unauthenticated is probably determined by  the SIP
>timer expiration.  Of course, if that would take too long, we  could add in
>a new timer just for the purpose of bounding the amount  of time that we'd
>allow a session to go on without any authentication.

That assumes auth-via-SIP as opposed to media channel.  By "ACKed by the
other side" I meant media-channel-ack, not SIP ACK.  In either case,
though, an optional (user-configured) separate timer makes sense.

>> isn't an issue (you're not going to negotiate encryption with them

You can also combine RTCP with RTP headers - if RTCP doesn't get through,
send in RTP headers (maybe do both anyways).  If that doesn't get through,
then fall back on signalling-channel (SIP) or give up (depending on how
much you trust signalling channel security).

>> lines (or not correctly update them in an SBC).

BTW, I speak from experience here....  And Ugh is right.  :-(  A major VoIP
carrier doesn't support RTCP at all, and others have 'issues'.