Re: [rtcweb] Continuing to assert username/password (Re: FW: Adopting draft-muthu-behave-consent-freshness?)

["Tirumaleswar Reddy (tireddy)" <[e-mail]>]

Hi Harald,

Please see inline

> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]] On Behalf Of
> Harald Alvestrand
> Sent: Tuesday, September 17, 2013 2:04 PM
> To: [e-mail]
> Subject: [rtcweb] Continuing to assert username/password (Re: FW: Adopting
> draft-muthu-behave-consent-freshness?)
> 
> Changing subject line in order to make life easier for those who try to
> review comments on the original subject....
> 
> On 09/17/2013 07:10 AM, Ram Mohan R (rmohanr) wrote:
> > Hi Please see inline
> >
> > -----Original Message-----
> > From: Jessie <Lijing>, "Huawei)" <[e-mail]>
> > Date: Thursday, 12 September 2013 1:27 PM
> > To: "[e-mail]" <[e-mail]>
> > Subject: [rtcweb] FW:  Adopting draft-muthu-behave-consent-freshness?
> >
> >> Hi all,
> >>
> >> As a newcomer to RTCWEB, I have some doubts after I have read the draft.
> >>
> >> 1. in "4.  Solution Overview", may be it would be better to clarify when
> >> to send a STUN Binding Request(in the middle of a media session or before
> >> sending traffic, during sending traffic or only during silence periods)
> >> and which side to send the request(controlling agent or both sides)?
> > The introduction section explains when consent is needed. During the
> > initial call setup ICE connectivity checks are used. This mechanism
> > described in this document is for periodic consent after initial sessions
> > is setup.
> >
> >> 2. in " 7.  Security Considerations", there are the following words. As
> >> when one agent receives STUN Binding Request, unlike the processing of
> >> indication message, it have to do more processes to send the Response
> >> message, I am not sure whether it is appreciate not to authenticate the
> >> source and respond directly. Is it more open to malicious attacks?
> > I am not clear on what you asking here. The below text just tells that
> > there is no need to re-asserting the username/password that was sent
> > initially during ICE checks. Are you saying this can lead to attacks ? If
> > yes can you explain on what you meant in detail ?
> 
> The text below is wrong.
> 
> If, as is commonly the case, an attacker has the ability to inject
> packets on the wire with the same IP address as the victim, the attacker
> can forge ICE packets.
> 
> If the victim's correspondent checks MESSAGE-INTEGRITY (which implicitly
> checks username and password), he will detect that these packets don't
> have the correct authorization, and throw them away.
> 
> If the victim's correspondent does not check MESSAGE-INTEGRITY, the
> attacker can keep renewing any consent to receive as long as he wants,
> even though the victim wanted to stop consenting.

Since each endpoint contributes at least 24 bits of randomness to the ice-ufrag which provides 48 bits of randomness. It would not be possible for off-path attacker to guess those 48 bits to cause the endpoint to perform HMAC-SHA1 validation of the MESSAGE-INTEGRITY attribute. Hence my understanding is for consent freshness checking MESSAGE-INTEGRITY is not be required, only checking IP address and USERNAME attribute looks sufficient to handle off-path attacks.

-Tiru.

> 
> Since the whole purpose of consent-freshness is to allow the potential
> victim to stop consenting to receiving traffic, checking
> MESSAGE-INTEGRITY (which implictily checks username and password) is
> necessary.
> 
> This whole paragraph should be deleted from the "Security
> Considerations" section and replaced with text properly describing the
> situation.
> 
> >
> > Ram
> >
> >>   "Once that connection to the remote
> >>    peer has been established with ICE, the consent to continue sending
> >>    traffic does not benefit from re-asserting that same username and
> >>    password, so long as the senders and receiver's IP addresses remain
> >>    the same (as they usually do)."
> >>
> >> Neglect my words, if my understandings are wrong.
> >>
> >> Best regards,
> >>
> >> Jessie
> >>
> >> -----Original Message-----
> >> From: [e-mail] [mailto:[e-mail]] On Behalf
> >> Of Magnus Westerlund
> >> Sent: Monday, September 09, 2013 4:37 PM
> >> To: [e-mail]
> >> Subject: [rtcweb] Adopting draft-muthu-behave-consent-freshness?
> >>
> >> WG,
> >>
> >> This is a call for WG adoption of STUN Usage for Consent Freshness
> >> (draft-muthu-behave-consent-freshness-04). This document defines a STUN
> >> usage for consent freshness. As this requires no protocol extensions we
> >> as intended users can define this usage in our WG. Such work also
> >> matches our charter. The draft-ietf-rtcweb-security-arch-07 is
> >> normatively dependent on this STUN usage.
> >>
> >> Document:
> >> https://datatracker.ietf.org/doc/draft-muthu-behave-consent-freshness/
> >>
> >> WG, please indicate your support or issues with adopting this document
> >> as WG item with a proposed milestone:
> >>
> >> Mar 2014 Send STUN Usage for Consent Freshness to IESG for publication
> >> as proposed standard.
> >>
> >> Cheers
> >>
> >> Magnus Westerlund
> >>
> >> ----------------------------------------------------------------------
> >> Multimedia Technologies, Ericsson Research EAB/TVM
> >> ----------------------------------------------------------------------
> >> Ericsson AB                | Phone  [phone]
> >> Färögatan 6                | Mobile [phone]
> >> SE-164 80 Stockholm, Sweden| mailto: [e-mail]
> >> ----------------------------------------------------------------------
> >>
> >> _______________________________________________
> >> rtcweb mailing list
> >> [e-mail]
> >> https://www.ietf.org/mailman/listinfo/rtcweb
> >> _______________________________________________
> >> rtcweb mailing list
> >> [e-mail]
> >> https://www.ietf.org/mailman/listinfo/rtcweb
> > _______________________________________________
> > rtcweb mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/rtcweb
> 
> _______________________________________________
> rtcweb mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/rtcweb