Subject: Re: [MMUSIC] SAVP and SAVP in draft-ietf-mmusic-rfc2326bis-23

From: Magnus Westerlund <[email-masked]>
Date: Wed, 06 Oct 2010 16:52:40 +0200

Hi Dan,

Thanks for your comment. I agree that using MIKEY is not the greatest
fit for this and do require a certain amount of specification work that
currently is missing. I am starting to lean in the direction that
defining DTLS-SRTP for this might be actually easier. What I see needed
to be specified are:

- Use DTLS-SRTP when having negotiated that transport identifier.

- Include a DER fingerprint of the certificates that is going to be used
in the handshake, likely self signed on the client side in the transport
spec. In line with the SDP TLS fingerprint in RFC 4572

- Require that one support all 4 DTLS SRTP protection profile present in
RFC 5764. In other words SHA-1 80 or 32 bits integrity and AES 128 CM if
encryption is used.

- Recommend that for media that are already confidentiality protected
use only authentication and integrity protection.

Other comments on this?

Cheers

Magnus

Dan Wing skrev 2010-09-30 01:31:
>> -----Original Message-----
>> From: [email-masked] [mailto:[email-masked]] On
>> Behalf Of Magnus Westerlund
>> Sent: Monday, September 27, 2010 7:55 AM
>> To: Roni Even
>> Cc: 'mmusic'
>> Subject: Re: [MMUSIC] SAVP and SAVP in draft-ietf-mmusic-rfc2326bis-23
>>
>> Roni Even skrev 2010-06-07 11:19:
>>> Hi,
>>>
>>> Section C.1.4 and C.1.5 recommend using MIKEY for key exchange. I
>> think
>>> that since we now have DTLS-SRTP in RFC 5764 we should look at
>>> recommending this option.
>>
>> Hi Roni,
>>
>> This questions doesn't seem to have been answered nor commented by
>> anyone.
>>
>> I think you actually have found an issue here. First of all that
>> without
>> a mandated to implement keying mechanism this is actually
>> underspecified. The second a discussion on what keying mechanism to
>> use.
>>
>> To resolve this I will suggest that we change RECOMMEND to MUST in
>> section C.14 and C.1.5 on using MIKEY with these protocol identifiers.
>> That way we do get a fully specified security mechanism.
> 
> I am concerned about making MIKEY a MUST.
> 
> First, which of the MIKEYs are you suggesting?  MIKEY-RSA, -PSK, 
> -RSA-R, -DHHMAC, or another?  If MIKEY-PSK (which is RFC3830's 
> mandatory-to-implement mechanism), what mechanism is used for 
> the RTSP client to get that pre-shared key or would that remain 
> unspecified?  Depending on how the pre-shared key is obtained,
> MIKEY-PSK may not be sufficient to protect against attackers 
> that obtain the pre-shared key (for example, how often and 
> how is the key changed in an RTSP session?).
> 
> Even if those were resolved, I would still object because a MUST 
> requires still implementing MIKEY-(whichever) even if DTLS-SRTP is 
> implemented in the future.  Some wording such as "In the absence 
> of another mechanism, MIKEY-(whichever) MUST be implemented" at 
> least avoids that problem, and would be a reasonable escape clause.
> 
>> The only thing
>> I need to consider is if MIKEY and SRTP has at least one mandatory to
>> implement mode each so that no further about which sets of mechanism
>> must be supported.
> 
> RFC3830 (MIKEY) mandatory-to-implement is MIKEY-PSK.  RFC3711 (SRTP) is
> AES-CM with HMAC-SHA1.
> 
>> I would agree that DTLS-SRTP is a good idea for transport layer
>> security
>> if needed for RTP media streams in RTSP. However, this needs
>> specification work and some considerations. I would also like to point
>> out that this do require a bit of special muxing which should be
>> expressed in the protocol string, just like in the SDP case also in
>> RTSP. Thus I think using another profile, lower transport combination
>> than for SRTP directly on UDP is warranted for DTLS-SRTP. As this
>> require job, I think anyone interested in this should define this
>> separately so that we can finish the core RTSP 2.0 spec.
> 
> I concur with that paragraph.  FYI, there is some progress on getting
> DTLS-SRTP to work well in environments that are interesting to RTSP
> (e.g., multicast) via draft-ietf-avt-srtp-ekt which allows different
> hosts to terminate DTLS-SRTP and send SRTP (Section 4.1.1).
> 
>> I don't know if the interest is so big for transport level protection,
>> although I think we shall provide a solution. The reason is that at
>> least content protection is usually in place.
> 
> Agreed.
> 
>> Thus the need is
>> primarily for integrity and authentication between server and client.
> 
> With that in mind, should there be a recommendation to only provide
> SRTP integrity and authentication (that is, without encryption)?
> 

-- 

Magnus Westerlund

----------------------------------------------------------------------
Multimedia Technologies, Ericsson Research EAB/TVM
----------------------------------------------------------------------
Ericsson AB                | Phone  +46 10 7148287
Färögatan 6                | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden| mailto: [email-masked]
----------------------------------------------------------------------

---

From: Magnus Westerlund <[email-masked]>
Date: Fri, 22 Oct 2010 17:47:03 +0200

Hi,

I was planning on doing DTLS-SRTP key management but I realized that it
would take to much time and I was still uncertain that I would get it
correct. Thus I did do what I could get local support with. A solution
using MIKEY. It is defined as the default for SAVP and SAVPF profiles.
But there is room to define alternatives.

Also I do expect DTLS to get a different transport spec identifier that
include dtls due to the multiplexing in the transport port. So that
should easily be separated.

Please see below for the suggested text in the different sections:

15.4.31. 466 Key Management Error	
			
   This indicates that there has been an error in a Key Management	
   function used in conjunction with a request. For example usage of	
   MIKEY according to Appendix C.1.4.1 may result in this error.

16.52 Transports

   MIKEY:  This parameter is used in conjunction with transport
         specifications that can utilize MIKEY for security context
         establishment.  So far only the SRTP based RTP profiles SAVP
         and SAVPF can utilize MIKEY and this is defined in
         Appendix C.1.4.1.  This parameter can be included both in
         request and response messages.  The binary MIKEY message SHALL
         be BASE64 [RFC4648] encoded before being included in the value
         part of the parameter.

20.2.3:

trns-parameter      = (SEMI ( "unicast" / "multicast" ))
                    / (SEMI "interleaved" EQUAL channel [ "-" channel ])
                    / (SEMI "ttl" EQUAL ttl)
                    / (SEMI "layers" EQUAL 1*DIGIT)
                    / (SEMI "ssrc" EQUAL ssrc *(SLASH ssrc))
                    / (SEMI "mode" EQUAL mode-spec)
                    / (SEMI "dest_addr" EQUAL addr-list)
                    / (SEMI "src_addr" EQUAL addr-list)
                    / (SEMI "setup" EQUAL contrans-setup)
                    / (SEMI "connection" EQUAL contrans-con)
                    / (SEMI "RTCP-mux")
                    / (SEMI "MIKEY" EQUAL MIKEY-Value)
                    / (SEMI trn-param-ext)

MIKEY-Value         = base64

C.1.4.  SAVP/UDP

   The RTP profile "The Secure Real-time Transport Protocol (SRTP)"
   [RFC3711] is an RTP profile (SAVP) that MAY be used in RTSP sessions
   using RTP.  All that is defined for AVP MUST also apply for SAVP.

   The usage of SRTP requires that a security context is established.
   The default key-management unless otherwise signalled shall be MIKEY
   in RSA-R mode as defined in Appendix C.1.4.1, and not according to
   the procedure defined in "Key Management Extensions for Session
   Description Protocol (SDP) and Real Time Streaming Protocol (RTSP)"
   [RFC4567].  The reason is that RFC 4567 sends the initial MIKEY
   message in SDP, thus both requiring the usage of the DESCRIBE method
   and forcing the server to keep state for client performing DESCRIBE
   in anticipation that they might require key management.

   MIKEY is selected as default method for establishing security
   association within an RTSP session as it can be embedded in the RTSP
   messages, while still ensuring confidentiality of content of the
   keying material, even when using hop-by-hop TLS security for the RTSP
   messages.  This method does also support pipelining of the RTSP
   messages.

C.1.4.1.  MIKEY Key Establishment

   This method for using MIKEY to establish the security context for
   SRTP is initiated in the client's SETUP request, and the servers
   response to the SETUP carries the MIKEY response.  Thus ensuring that
   the Security context establishment happens simultaneously with the
   establishment of the media stream being protected.  By using MIKEY's
   RSA-R mode [RFC4738] the client can be initiator and still allow the
   server to set the parameters in accordance with the actual media
   stream.

   The Security Context Establishment is done according to the following
   process:

   1.   The client determines that SAVP or SAVPF shall be used from
        media description format, e.g.  SDP.  If no other key management
        method is explicitly signalled, then MIKEY SHALL be used as
        defined here in.  This specification does not specify an
        explicit method for indicating this security context
        establishment method, but future specifications may.

   2.   The client SHALL establish a TLS connection for RTSP messages,
        directly or hop by hop with the server.  If hop-by-hop TLS
        security is used, the User method SHALL be indicated in the
        Accept-Credentials header.  We do note that using hop-by-hop
        does allow the proxy to insert itself as a man in the middle
        also in the MIKEY exchange by providing one of its certificates,
        rather than the server's in the Connection-Credentials header.
        The client shall therefore validate the server certificate.

   3.   The client retrieves the servers certificate from a direct TLS
        connection, or if hop by hop from Connection-Credentials header.
        The client then checks that the server certificate is valid and
        belongs to server.

   4.   The client forms the MIKEY Initiator message using RSA-R mode in
        unicast mode as specified in [RFC4738].  The client SHOULD use
        the same certificate for TLS and in MIKEY to enable server to
        bind the two together.  The client's certificate SHALL be
        included in the MIKEY message.  The client SHALL indicate its
        SRTP capabilities in the message.

   5.   The MIKEY message from the previous step is base64 [RFC4648]
        encoded and becomes the value of the MIKEY parameter that are
        included in the transport specification(s) that specifies a SRTP
        based profile (SAVP, SAVPF) in the SETUP request.

   6.   Any proxy encountering the MIKEY parameter SHALL forward it
        without modification.  A proxy requiring to understand transport
        specificaation which doesn't support SAVP/SAVPF with MIKEY will
        discard the whole transport specification.  Most types of proxy
        can easily support SAVP and SAVPF with MIKEY.  If possible
        bypassing the proxy should be tried.

   7.   The server upon receiving the SETUP request, while need to
        decide upon the transport specification to use, if multiple are
        included by the client.  In the determination of which transport
        specifications that are supported and preferred, the server
        should decode the MIKEY message to take the embedded SRTP
        parameters into account.  If all transport specs require SRTP
        but no MIKEY parameter or other supported keying method is
        included, the server shall respond with 403.

   8.   Upon generating a response the following outcomes can occur:

        *  A transport spec not using SRTP and MIKEY is selected.  Thus
           the answer will not contain any MIKEY parameter.

        *  A transport spec using SRTP and MIKEY is selected but an
           error is encountered in the MIKEY processing.  In that case
           an RTSP error response code of 466 "Key Management Error"
           SHALL be used.  A MIKEY message describing the error MAY be
           included.

        *  A transport spec using SRTP and MIKEY is selected and a MIKEY
           response message can be created.  The server SHOULD use the
           same certificate for TLS and in MIKEY to enable client to
           bind the two together.  If a different certificate is used it
           SHALL be included in the MIKEY message.  It is RECOMMENDED
           that the envelope key cache type is set to 'Cache' and that a
           single envelope key is reused for all MIKEY messages to the
           client.  That message is included in the MIKEY parameter part
           of the single selected transport specification in the SETUP
           response.  The server will set the SRTP parameters as
           preferred for this media stream within the supported range by
           the client.

   9.   The server transmits the SETUP response back to the client.

   10.  The client receives the SETUP response and if the response code
        indicates a successful request it decodes the MIKEY message and
        establish the security context from the parameters in the MIKEY
        response.

   In the above method the client's certificate may be self-signed in
   cases where the client's identify is not necessary to establish and
   the security goal is only to ensure that the RTSP signalling client
   is the same as the one receiving the SRTP security context.

C.1.5.  SAVPF/UDP

   The RTP profile "Extended Secure RTP Profile for RTCP-based Feedback
   (RTP/SAVPF)" [RFC5124] is an RTP profile (SAVPF) that MAY be used in
   RTSP sessions using RTP.  All that is defined for AVP MUST also apply
   for SAVPF.

   The usage of SRTP requires that a security association is
   established.  The RECOMMENDED mechanism for establishing that
   security association is to use MIKEY[RFC3830] with RTSP as defined in
   RFC 4567 [RFC4567].

-- 

Magnus Westerlund

---

From: Magnus Westerlund <[email-masked]>
Date: Fri, 22 Oct 2010 17:58:11 +0200

Hi,

There was a bit of an error in the C.1.5 part which should read:

C.1.5.  SAVPF/UDP

   The usage of SRTP requires that a security association is
   established.  The default mechanism for establishing that security
   association is to use MIKEY[RFC3830] with RTSP as defined
   Appendix C.1.4.1.

I also included a paragraph in C.2.2:

   The usage of SRTP, i.e. either SAVP or SAVPF profiles requires that a
   security association is established.  The default mechanism for
   establishing that security association is to use MIKEY[RFC3830] with
   RTSP as defined Appendix C.1.4.1.

Cheers

Magnus

-- 

Magnus Westerlund

---

From: "Dan Wing" <[email-masked]>
Date: Mon, 25 Oct 2010 18:02:13 -0700

Thank you, this works for me.

I will send you some nits off-list.

-d

> Sent: Friday, October 22, 2010 8:47 AM
> To: Dan Wing
> Cc: 'mmusic'
> _______________________________________________
> mmusic mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mmusic