Re: [rtcweb] Continuing to assert username/password (Re: FW: Adopting draft-muthu-behave-consent-freshness?)
Harald Alvestrand <harald@alvestrand.no> Tue, 17 September 2013 11:33 UTC
Return-Path: <harald@alvestrand.no>
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A741911E81A4 for <rtcweb@ietfa.amsl.com>; Tue, 17 Sep 2013 04:33:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -110.256
X-Spam-Level:
X-Spam-Status: No, score=-110.256 tagged_above=-999 required=5 tests=[AWL=-0.257, BAYES_00=-2.599, J_CHICKENPOX_72=0.6, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LBUJVVHpUjU7 for <rtcweb@ietfa.amsl.com>; Tue, 17 Sep 2013 04:33:51 -0700 (PDT)
Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id 4165111E8100 for <rtcweb@ietf.org>; Tue, 17 Sep 2013 04:33:51 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 2DD9539E4EB; Tue, 17 Sep 2013 13:33:50 +0200 (CEST)
X-Virus-Scanned: Debian amavisd-new at eikenes.alvestrand.no
Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VcE6g31F5zQA; Tue, 17 Sep 2013 13:33:46 +0200 (CEST)
Received: from hta-hippo.lul.corp.google.com (unknown [IPv6:2620:0:1043:1:7646:a0ff:fe90:e2bb]) by eikenes.alvestrand.no (Postfix) with ESMTPSA id 0BCD339E240; Tue, 17 Sep 2013 13:33:46 +0200 (CEST)
Message-ID: <52383E19.2070107@alvestrand.no>
Date: Tue, 17 Sep 2013 13:33:45 +0200
From: Harald Alvestrand <harald@alvestrand.no>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130804 Thunderbird/17.0.8
MIME-Version: 1.0
To: "Tirumaleswar Reddy (tireddy)" <tireddy@cisco.com>
References: <E92E67B176B8B64D8D3A8F5E44E9D8F41FF743A0@xmb-aln-x05.cisco.com> <52381402.8070400@alvestrand.no> <913383AAA69FF945B8F946018B75898A190793B0@xmb-rcd-x10.cisco.com>
In-Reply-To: <913383AAA69FF945B8F946018B75898A190793B0@xmb-rcd-x10.cisco.com>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
Cc: "rtcweb@ietf.org" <rtcweb@ietf.org>
Subject: Re: [rtcweb] Continuing to assert username/password (Re: FW: Adopting draft-muthu-behave-consent-freshness?)
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list <rtcweb.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/rtcweb>
List-Post: <mailto:rtcweb@ietf.org>
List-Help: <mailto:rtcweb-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 17 Sep 2013 11:33:56 -0000
On 09/17/2013 12:05 PM, Tirumaleswar Reddy (tireddy) wrote: > Hi Harald, > > Please see inline > >> -----Original Message----- >> From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf Of >> Harald Alvestrand >> Sent: Tuesday, September 17, 2013 2:04 PM >> To: rtcweb@ietf.org >> 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)" <lijing80@huawei.com> >>> Date: Thursday, 12 September 2013 1:27 PM >>> To: "rtcweb@ietf.org" <rtcweb@ietf.org> >>> 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)." don't make any sense to me. If they don't make any sense to other people, they do not belong in the document.
- [rtcweb] Adopting draft-muthu-behave-consent-fres… Magnus Westerlund
- Re: [rtcweb] Adopting draft-muthu-behave-consent-… Simon Perreault
- Re: [rtcweb] Adopting draft-muthu-behave-consent-… Harald Alvestrand
- Re: [rtcweb] Adopting draft-muthu-behave-consent-… Christer Holmberg
- [rtcweb] Consent freshness in the light of no-SDE… Harald Alvestrand
- Re: [rtcweb] Consent freshness in the light of no… Christer Holmberg
- Re: [rtcweb] Adopting draft-muthu-behave-consent-… Alfred E. Heggestad
- Re: [rtcweb] Adopting draft-muthu-behave-consent-… Bernard Aboba
- Re: [rtcweb] consent freshness vs. circuit breake… Bernard Aboba
- Re: [rtcweb] Adopting draft-muthu-behave-consent-… Charles Eckel (eckelcu)
- Re: [rtcweb] Consent freshness in the light of no… Martin Thomson
- Re: [rtcweb] Consent freshness in the light of no… Martin Thomson
- Re: [rtcweb] Adopting draft-muthu-behave-consent-… Martin Thomson
- Re: [rtcweb] Adopting draft-muthu-behave-consent-… Gonzalo Salgueiro (gsalguei)
- Re: [rtcweb] Adopting draft-muthu-behave-consent-… Victor Pascual
- Re: [rtcweb] Adopting draft-muthu-behave-consent-… Timothy B. Terriberry
- Re: [rtcweb] Adopting draft-muthu-behave-consent-… Eric Rescorla
- Re: [rtcweb] Adopting draft-muthu-behave-consent-… Mishra, Sanjay
- Re: [rtcweb] consent freshness vs. circuit breake… Dan Wing
- Re: [rtcweb] Adopting draft-muthu-behave-consent-… Muthu Arul Mozhi Perumal (mperumal)
- Re: [rtcweb] Adopting draft-muthu-behave-consent-… Lijing (Jessie, Huawei)
- Re: [rtcweb] Adopting draft-muthu-behave-consent-… Mishra, Sanjay
- [rtcweb] FW: Adopting draft-muthu-behave-consent-… Lijing (Jessie, Huawei)
- Re: [rtcweb] FW: Adopting draft-muthu-behave-cons… Ram Mohan R (rmohanr)
- [rtcweb] Continuing to assert username/password (… Harald Alvestrand
- Re: [rtcweb] Adopting draft-muthu-behave-consent-… Magnus Westerlund
- Re: [rtcweb] Continuing to assert username/passwo… Tirumaleswar Reddy (tireddy)
- Re: [rtcweb] Continuing to assert username/passwo… Harald Alvestrand
- Re: [rtcweb] Continuing to assert username/passwo… Tirumaleswar Reddy (tireddy)