Subject: [MMUSIC] Query regarding SRTP incorporation using RTSP/SDP Session Management

From: [email-masked]
Date: Fri, 22 Feb 2008 18:51:45 +0545

Hi,
        I have some query regarding SRTP with respect to RFC 4568 (SDP 
Security Description for media streams)

        This RFC talks with respect to two Models:

                        >>> Offer Answer Model, which requires negotiation 
between sender and receiver and

                        >>> Outside Offer Answer Model, which requires 
receiver to either accept the offer or terminate  the session.

        When using RTSP for session management, sender can communicate 
security parameters it is going to use for              RTP/RTCP packets 
to receiver in SDP text but there is no way the receiver can send the 
security parameters it  is going to use for RTCP messages to sender.
 
        Sectin from RFC 4568 talks the same as : 
 
        7.2.  SRTP-Specific Use Outside Offer/Answer

                Use of SRTP security descriptions outside the offer/answer 
model is
                not defined.
        Use of SRTP security descriptions outside the offer/answer model
        could have been defined for sendonly media streams; however, there
        would not be a way to indicate the key to use for SRTCP by the
        receiver of said media stream.

        I am looking for the way the receiver could use to send security 
parameters to sender for RTCP messages.

        If anyone has suggestion/reference to any specification, which 
talks about it then please share the knowledge with me.

Thanks and Regard,
Ankit

***********************  Aricent-Unclassified   ***********************
"DISCLAIMER: This message is proprietary to Aricent and is intended solely for the use of 
the individual to whom it is addressed. It may contain privileged or confidential information and should not be 
circulated or used for any purpose other than for what it is intended. If you have received this message in error, 
please notify the originator immediately. If you are not the intended recipient, you are notified that you are strictly
prohibited from using, copying, altering, or disclosing the contents of this message. Aricent accepts no responsibility for 
loss or damage arising from the use of the information transmitted by this email including damage from virus."
_______________________________________________
mmusic mailing list
[email-masked]
http://www.ietf.org/mailman/listinfo/mmusic

---

From: "Dan Wing" <[email-masked]>
Date: Fri, 22 Feb 2008 07:38:16 -0800

RTSP 2.0 appears to be adding an offer/answer model to RTSP, which would allow
an RTSP client to send its security parameters and SRTCP packets towards the
RTSP sender.  This is useful for Security Descriptions (RFC4568), MIKEY-*,
DTLS-SRTP, and ICE, all of which need to communicate information in both
directions.

-d

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of [email-masked]
> Sent: Friday, February 22, 2008 5:07 AM
> To: [email-masked]
> Subject: [MMUSIC] Query regarding SRTP incorporation using 
> RTSP/SDP SessionManagement
> 
> 
> Hi, 
>         I have some query regarding SRTP with respect to RFC 
> 4568 (SDP Security Description for media streams) 
> 
>                         >>> Offer Answer Model, which 
> requires negotiation between sender and receiver and 
> 
>                         >>> Outside Offer Answer Model, which 
> requires receiver to either accept the offer or terminate     
>                         the session. 
> 
>         When using RTSP for session management, sender can 
> communicate security parameters it is going to use for        
>          RTP/RTCP packets to receiver in SDP text but there 
> is no way the receiver can send the security parameters it    
>      is going to use for RTCP messages to sender. 
>         
>                    Use of SRTP security descriptions outside 
> the offer/answer model is
>                  not defined.
>         I am looking for the way the receiver could use to 
> send security parameters to sender for RTCP messages. 
> 
>         If anyone has suggestion/reference to any 
> specification, which talks about it then please share the 
> knowledge with me. 
> 
> 
> Thanks and Regard, 
> Ankit
> 
>  
> 
> 
>  
> 
> the individual to whom it is addressed. It may contain 
> privileged or confidential information and should not be 
> circulated or used for any purpose other than for what it is 
> intended. If you have received this message in error, 
> please notify the originator immediately. If you are not the 
> intended recipient, you are notified that you are strictly
> prohibited from using, copying, altering, or disclosing the 
> contents of this message. Aricent accepts no responsibility for 
> loss or damage arising from the use of the information 
> transmitted by this email including damage from virus."
> 
>

---

From: Rémi Denis-Courmont <[email-masked]>
Date: Fri, 22 Feb 2008 19:58:46 +0200

Le Friday 22 February 2008 17:38:16 ext Dan Wing, vous avez écrit :
> RTSP 2.0 appears to be adding an offer/answer model to RTSP, which would
> allow an RTSP client to send its security parameters and SRTCP packets
> towards the RTSP sender.  This is useful for Security Descriptions
> (RFC4568), MIKEY-*, DTLS-SRTP, and ICE, all of which need to communicate
> information in both directions.

I remember reading this in some email threads. Still, it does not seem to 
match the current I-D at all, which seems to simply reuse/fix the RTSP/1.0 
declarative. So what's actually happening?

Also, I am not sure if MIKEY or DTLS bootstrapping would allow RTSP servers to 
use the same session key with different client. This could have obvious 
performance gain in case of broadcasting (or if the data were somehow 
pre-SRTP-encrypted on the server storage??). In any case, if RTSP/2.0 still 
supports multicasting (does it?), that same key SRTP for all clients of the 
same media model needs to be supported.

I wonder if it would not make more sense to adapt plain Security Descriptions 
for declarative SDP over RTSP/TLS, and pass the (plain) SRTCP-RR keying 
material as a SETUP parameter, or something similar?

-- 
Rémi Denis-Courmont

---

From: "Dan Wing" <[email-masked]>
Date: Fri, 22 Feb 2008 10:32:16 -0800

> > (RFC4568), MIKEY-*, DTLS-SRTP, and ICE, all of which need 
> > to communicate information in both directions.
> 
> I remember reading this in some email threads. Still, it does 
> not seem to match the current I-D at all, which seems to simply 
> reuse/fix the RTSP/1.0 declarative. So what's actually 
> happening?

I am not an author and my knowledge of RTSP is insufficient
to comment intelligently.

> Also, I am not sure if MIKEY or DTLS bootstrapping would 
> allow RTSP servers to use the same session key with different 
> client. 

For RTSP, I don't know, either.  I do not believe using the same
SRTP key is a requirement, however; there are RTSP applications
that are entirely point-to-point unicast.

But for DTLS-SRTP, my draft draft-wing-avt-dtls-srtp-key-transport-01 
is a step in the direction to allow the same SRTP key to be used 
for multiple receivers.

> This could have obvious 
> supports multicasting (does it?), that same key SRTP for all 
> clients of the same media model needs to be supported.
> 
> I wonder if it would not make more sense to adapt plain 
> Security Descriptions for declarative SDP over RTSP/TLS, and pass 
> the (plain) SRTCP-RR keying material as a SETUP parameter, or 
> something similar?

As a co-author of Security Descriptions, I would prefer to use
DTLS-SRTP for two reasons:  Security Descriptions is not suitable, 
as is, for multicast (which is mentioned several times in the 
RFC4568 itself); and Security Descriptions requires encrypted 
signaling.  At least with RTSP, the signaling is already carried 
over TCP so adding TLS is 'easy' (compared to SIP's pervasive 
UDP signaling).

-d

---

From: Magnus Westerlund <[email-masked]>
Date: Mon, 25 Feb 2008 13:47:23 +0100

> DTLS-SRTP, and ICE, all of which need to communicate information in both

No, RTSP 2.0 doesn't not add offer/answer model. It also is not part of 
the plan.

MIKEY already have a defined solution on how to exchange the MIKEY 
messages in RTSP (RFC 4567). ICE is under specification, draft with much 
more details than previously will be submitted later today.

In fact, there is no problem of moving information both ways in RTSP, 
you simply need to use headers instead of squeezing things into SDP. I 
actually think there are clear benefits to this model as it allows one 
to have much more explicit error handling.

Cheers

Magnus Westerlund

IETF Transport Area Director & TSVWG Chair
----------------------------------------------------------------------
Multimedia Technologies, Ericsson Research EAB/TVM
----------------------------------------------------------------------
Ericsson AB                | Phone +46 8 4048287
Torshamsgatan 23           | Fax   +46 8 7575550
S-164 80 Stockholm, Sweden | mailto: [email-masked]
----------------------------------------------------------------------