Subject: [AVT] Comment on Section 4.3.1 of draft-ietf-avt-ports-for-ucast-mcast-rtp-09.txt

From: Roni Even <[email-masked]>
Date: Thu, 16 Dec 2010 11:45:53 +0200

Hi,

I am not sure I understand what is the reason for having messages that
control an existing unicast session associated with  a multicast session
send a token verification message.

The control messages like CCM flow from port c2 to port P4. This is the
unicast channel opened by the request and as such the security
considerations of RAMS and  RFC 4588 for the unicast channel apply. Are we
mandating here another authentication mechanism that must be used even if
the solution complies with the security requirements for the unicast channel
specified in RAMS for example.

As a second question is about " A server might determine that other RTCP
messages also need to be  authenticated using the mechanism described in
this document.  Thus, clients need to support including a Token with any
necessary RTCP   message" . How can an application developer know which RTCP
message will need the token. Is it only based on a token verification
failure message?

Roni Even as individual

---

From: "Ali C. Begen (abegen)" <[email-masked]>
Date: Thu, 16 Dec 2010 04:18:05 -0800

Hi Roni,

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of Roni Even
> Sent: Thursday, December 16, 2010 4:46 AM
> To: [email-masked]
> Subject: [AVT] Comment on Section 4.3.1 of draft-ietf-avt-ports-for-ucast-mcast-rtp-09.txt
> 
> Hi,
> 
> I am not sure I understand what is the reason for having messages that control an existing unicast session associated with  a
> multicast session send a token verification message.
> 
> The control messages like CCM flow from port c2 to port P4. This is the unicast channel opened by the request and as such
> the security considerations of RAMS and  RFC 4588 for the unicast channel apply. Are we mandating here another
> authentication mechanism that must be used even if the solution complies with the security requirements for the unicast
> channel specified in RAMS for example.

The RAMS-T is also sent in the unicast session. If it is not authenticated, bad things might happen. It was the same motivation to include CCM in this list. Note that we are not updating the individual RFCs. We are describing the Token spec here and an implementation compliant with this spec will already know what to do.

> As a second question is about " A server might determine that other RTCP messages also need to be  authenticated using the
> mechanism describ ; Thus, clients need to support including a Token with any necessary RTCP   message" . How can an
> application developer know which RTCP message will need the token. Is it only based on a token verification failure
> message?

The current text is 7.1 says that certain RTCP messages will require a Token. This is indicated by the SDP attribute. When a token is required for proper functionality, the client needs to get one.

A client supporting this spec may prefer to get the Token before doing anything and include it in the messages. This will save him some delay in case he gets the failure message and then tries to get a token. The failure message will indicate which message required the token (hence, caused the failure message to be sent).

Beyond following the current list in 4.3.1 and the approach above, I don't think we can do more. Also consider the following case. The server may initially not require tokens for certain messages (e.g., XYZ message) but then maybe after seeing some attacks, it might to do so. So, there are other factors that might push the server to take higher security measures on the fly. Yet, after seeing the failure message, a token-capable client will know why it got that message.

-acbegen

---

From: Roni Even <[email-masked]>
Date: Thu, 16 Dec 2010 14:45:38 +0200

Ali,
What bad things can happen that are not covered by the security
considerations of the RAMS draft. What I read there is that the message need
to be authenticated but this can be done with DTLS-SRTP.

Roni Even

> From: Ali C. Begen (abegen) [mailto:[email-masked]]
> Sent: Thursday, December 16, 2010 2:18 PM
> To: Roni Even; [email-masked]
> Subject: RE: [AVT] Comment on Section 4.3.1 of draft-ietf-avt-ports-
> for-ucast-mcast-rtp-09.txt
> 
> Hi Roni,
> 
> > I am not sure I understand what is the reason for having messages
> that control an existing unicast session associated with  a
> > The control messages like CCM flow from port c2 to port P4. This is
> the unicast channel opened by the request and as such
> > the security considerations of RAMS and  RFC 4588 for the unicast
> channel apply. Are we mandating here another
> > authentication mechanism that must be used even if the solution
> complies with the security requirements for the unicast
> The RAMS-T is also sent in the unicast session. If it is not
> authenticated, bad things might happen. It was the same motivation to
> include CCM in this list. Note that we are not updating the individual
> RFCs. We are describing the Token spec here and an implementation
> compliant with this spec will already know what to do.
> 
> > As a second question is about " A server might determine that other
> RTCP messages also need to be  authenticated using the
> > mechanism describ ; Thus, clients need to support including a Token
> with any necessary RTCP   message" . How can an
> > application developer know which RTCP message will need the token. Is
> it only based on a token verification failure
> > message?
> 
> The current text is 7.1 says that certain RTCP messages will require a
> Token. This is indicated by the SDP attribute. When a token is required
> for proper functionality, the client needs to get one.
> 
> A client supporting this spec may prefer to get the Token before doing
> anything and include it in the messages. This will save him some delay
> in case he gets the failure message and then tries to get a token. The
> failure message will indicate which message required the token (hence,
> caused the failure message to be sent).
> 
> Beyond following the current list in 4.3.1 and the approach above, I
> don't think we can do more. Also consider the following case. The
> server may initially not require tokens for certain messages (e.g., XYZ
> message) but then maybe after seeing some attacks, it might to do so.
> So, there are other factors that might push the server to take higher
> security measures on the fly. Yet, after seeing the failure message, a
> token-capable client will know why it got that message.
> 
> -acbegen
> 
> 
> >
> >
> > Roni Even as individual
> >
> >

---

From: "Ali C. Begen (abegen)" <[email-masked]>
Date: Thu, 16 Dec 2010 04:57:16 -0800

If SRTCP is done, I believe the token authentication would then be not required. 

Since the token was required for the unicast session establishment, using it also for RAMS-T does not bring the client an extra cost and saves from the trouble of using SRTCP. But SRTCP could already be in place.

You raise a good point maybe we should reword that part like: unless the messages controlling the unicast session are authenticated using another mechanism, the token approach must be used.

Would that make more sense?

-acbegen

> From: Roni Even [mailto:[email-masked]]
> Sent: Thursday, December 16, 2010 7:46 AM
> To: Ali C. Begen (abegen); [email-masked]
> Subject: RE: [AVT] Comment on Section 4.3.1 of draft-ietf-avt-ports-for-ucast-mcast-rtp-09.txt
> 
> Ali,

---

From: Roni Even <[email-masked]>
Date: Thu, 16 Dec 2010 16:01:29 +0200

Hi Ali,
This will be better. RAMS has a requirement to support DTLS-SRTP and the
security issues of tampering with RAMS-T are discussed
Roni

> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Ali C. Begen (abegen)
> Sent: Thursday, December 16, 2010 2:57 PM
> Subject: Re: [AVT] Comment on Section 4.3.1 of draft-ietf-avt-ports-
> Since the token was required for the unicast session establishment,
> using it also for RAMS-T does not bring the client an extra cost and
> saves from the trouble of using SRTCP. But SRTCP could already be in
> place.
> 
> You raise a good point maybe we should reword that part like: unless
> the messages controlling the unicast session are authenticated using
> another mechanism, the token approach must be used.
> 
> > > > From: [email-masked] [mailto:[email-masked]] On
> Behalf Of
> > > Roni Even
> > > > Subject: [AVT] Comment on Section 4.3.1 of draft-ietf-avt-ports-
> for-
> > > ucast-mcast-rtp-09.txt
> > > >
> > > > Hi,
> > > >
> _______________________________________________
> Audio/Video Transport Working Group
> [email-masked]
> https://www.ietf.org/mailman/listinfo/avt