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

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

> -----Original Message-----
> From: Harald Alvestrand [mailto:[e-mail]]
> Sent: Tuesday, September 17, 2013 5:04 PM
> To: Tirumaleswar Reddy (tireddy)
> Cc: [e-mail]
> Subject: Re: [rtcweb] Continuing to assert username/password (Re: FW: Adopting
> draft-muthu-behave-consent-freshness?)
> 
> On 09/17/2013 12:05 PM, Tirumaleswar Reddy (tireddy) wrote:
> > 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.
> >
> 
> Are we talking past each other?
> 
> In order to perform HMAC-SHA1 validation of the MESSAGE-INTEGRITY
> attribute, the HMAC-SHA1 function takes two inputs: The key and the message.
> 
>  From RFC 5389 section 15.4:
> 
> For long-term credentials, the key is 16 bytes:
> 
>              key = MD5(username ":" realm ":" SASLprep(password))
> 
> For short-term credentials:
> 
>                            key = SASLprep(password)
> 
> In other words: A successful HMAC that produces a match with the
> MESSAGE-INTEGRITY attribute value means that the producer of the
> MESSAGE-INTEGRITY attribute knows the password, and, if long term
> credentials are used, he knows the username.
> 
> This implicitly reasserts the password (and possibly the username), and
> the words we're discussing:
> 
>    "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)."

Agreed, the above text in the draft needs to be corrected. 

-Tiru.

> 
> don't make any sense to me.
> If they don't make any sense to other people, they do not belong in the
> document.
> 
> 
> 
>