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

[Harald Alvestrand <[e-mail]>]

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 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