Subject: [rtcweb] FW: Adopting draft-muthu-behave-consent-freshness?

From: "Lijing (Jessie, Huawei)" <[email-masked]>
Date: Thu, 12 Sep 2013 07:57:40 +0000

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

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?

  "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: [email-masked] [mailto:[email-masked]] On Behalf Of Magnus Westerlund
Sent: Monday, September 09, 2013 4:37 PM
To: [email-masked]
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  +46 10 7148287
Färögatan 6                | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden| mailto: [email-masked]
----------------------------------------------------------------------

_______________________________________________
rtcweb mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/rtcweb

---

From: "Ram Mohan R (rmohanr)" <[email-masked]>
Date: Tue, 17 Sep 2013 05:10:22 +0000

Hi Please see inline

-----Original Message-----
From: Jessie <Lijing>, "Huawei)" <[email-masked]>
Date: Thursday, 12 September 2013 1:27 PM
To: "[email-masked]" <[email-masked]>
Subject: [rtcweb] FW:  Adopting draft-muthu-behave-consent-freshness?

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

Ram

---

From: Harald Alvestrand <[email-masked]>
Date: Tue, 17 Sep 2013 10:34:10 +0200

Changing subject line in order to make life easier for those who try to 
review comments on the original subject....

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

---

From: "Tirumaleswar Reddy (tireddy)" <[email-masked]>
Date: Tue, 17 Sep 2013 10:05:24 +0000

Hi Harald,

Please see inline

> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Harald Alvestrand
> Sent: Tuesday, September 17, 2013 2:04 PM
> To: [email-masked]
> Subject: [rtcweb] Continuing to assert username/password (Re: FW: Adopting
> draft-muthu-behave-consent-freshness?)
> 

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.

---

From: Harald Alvestrand <[email-masked]>
Date: Tue, 17 Sep 2013 13:33:45 +0200

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

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:

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

---

From: "Tirumaleswar Reddy (tireddy)" <[email-masked]>
Date: Tue, 17 Sep 2013 17:40:16 +0000

> From: Harald Alvestrand [mailto:[email-masked]]
> Sent: Tuesday, September 17, 2013 5:04 PM
> To: Tirumaleswar Reddy (tireddy)
> Cc: [email-masked]
> Subject: Re: [rtcweb] Continuing to assert username/password (Re: FW: Adopting
> > 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.
> >
> 

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

-Tiru.