Re: [rtcweb] OPS-Dir review of draft-ietf-rtcweb-stun-consent-freshness-13

"Tirumaleswar Reddy (tireddy)" <tireddy@cisco.com> Thu, 28 May 2015 05:12 UTC

Return-Path: <tireddy@cisco.com>
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 93CA01A8A4A; Wed, 27 May 2015 22:12:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.511
X-Spam-Level:
X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W_4F1s1T07vw; Wed, 27 May 2015 22:12:18 -0700 (PDT)
Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 436621A8A44; Wed, 27 May 2015 22:12:18 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=15749; q=dns/txt; s=iport; t=1432789938; x=1433999538; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=oCInt/9qMNc07EkpB0fteFXFwVCq+fKq0f5yGdxc6TQ=; b=L5ahu81gWGefop8oc7zztpLZvCkFapzvieD2WIBM+ccDnSjnBYUq/i4W KHTNBIaejqrvx4bkVKNQFCL5d51sQMgvB617FdU8yGDsUmBIfdxboL2U/ oGUFEMoOLixJtzoKjH5ZBj8erAWU/OcVKBG266MkxmzexJ4Wx/vwaDesd A=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0ARBABBo2ZV/4kNJK1ZA4MQgTIGwHtmCYdRAoFHOBQBAQEBAQEBgQqEIgEBAQMBfgcEAgEIEQECAQEBAQodByERFAMGCAEBBAESCIgQAwoIzkcNhH4BAQEBAQEBAQEBAQEBAQEBAQEBAQEXizqCTYFgDRohFwYLgwaBFgWFDYFehHQrhn6IfDqDAoNxijZchwMjYYMXb4EDAR8CIYEBAQEB
X-IronPort-AV: E=Sophos;i="5.13,511,1427760000"; d="scan'208";a="2421355"
Received: from alln-core-4.cisco.com ([173.36.13.137]) by rcdn-iport-2.cisco.com with ESMTP; 28 May 2015 05:12:16 +0000
Received: from xhc-rcd-x06.cisco.com (xhc-rcd-x06.cisco.com [173.37.183.80]) by alln-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id t4S5CGfs029873 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 28 May 2015 05:12:16 GMT
Received: from xmb-rcd-x10.cisco.com ([169.254.15.253]) by xhc-rcd-x06.cisco.com ([173.37.183.80]) with mapi id 14.03.0195.001; Thu, 28 May 2015 00:12:16 -0500
From: "Tirumaleswar Reddy (tireddy)" <tireddy@cisco.com>
To: "Black, David" <david.black@emc.com>, "Ram Mohan R (rmohanr)" <rmohanr@cisco.com>, joel jaeggli <joelja@bogus.com>, "muthu.arul@gmail.com" <muthu.arul@gmail.com>, "Dan Wing (dwing)" <dwing@cisco.com>, "martin.thomson@gmail.com" <martin.thomson@gmail.com>, "ops-dir@ietf.org" <ops-dir@ietf.org>, "rtcweb@ietf.org" <rtcweb@ietf.org>
Thread-Topic: OPS-Dir review of draft-ietf-rtcweb-stun-consent-freshness-13
Thread-Index: AdCYTRwpDLI16eMpRUmkDRETmBwKqQAtFSwA
Date: Thu, 28 May 2015 05:12:15 +0000
Message-ID: <913383AAA69FF945B8F946018B75898A47860737@xmb-rcd-x10.cisco.com>
References: <CE03DB3D7B45C245BCA0D243277949364C76E4@MX104CL02.corp.emc.com>
In-Reply-To: <CE03DB3D7B45C245BCA0D243277949364C76E4@MX104CL02.corp.emc.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.65.47.79]
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: <http://mailarchive.ietf.org/arch/msg/rtcweb/ueJ-XNcJCJSfa_rY_rlaJ-rAwUA>
Subject: Re: [rtcweb] OPS-Dir review of draft-ietf-rtcweb-stun-consent-freshness-13
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.15
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: Thu, 28 May 2015 05:12:21 -0000

> -----Original Message-----
> From: Black, David [mailto:david.black@emc.com]
> Sent: Wednesday, May 27, 2015 12:47 PM
> To: Ram Mohan R (rmohanr); joel jaeggli; muthu.arul@gmail.com; Dan Wing
> (dwing); Tirumaleswar Reddy (tireddy); martin.thomson@gmail.com; ops-
> dir@ietf.org; rtcweb@ietf.org
> Cc: Black, David
> Subject: RE: OPS-Dir review of draft-ietf-rtcweb-stun-consent-freshness-13
> 
> I'll limit comments here to the two major issues.  Quick summary:
> 
> [1] Applicability: The proposed text looks generally good, but the definition
> 	of "consent" needs a couple of clarifications.
> 
> [2] Security Considerations: The proposed text isn't sufficient.  In addition
> 	to the new applicability text's reference to the WebRTC security
> 	architecture draft, a reference to the WebRTC security
> considerations
> 	draft with specific section pointers needs to be added to the security
> 	considerations section of this draft.
> 
> > >> [1] The draft seems to be missing discussion of applicability -
> > >> what environments and/or protocols is this mechanism intended for
> > >> or applicable to?
> 
> > We will add a new section ³Applicability² after the introduction section.
> 
> I think that proposed applicability section will address most of the concern.
> As part of this, the definition of consent (Section 2) needs elaboration:
> 
>    Consent:  The mechanism of obtaining permission to send to a remote
>       transport address.  Initial consent is obtained using ICE.
> 
> Two important concepts should be clearer:
> 	- Permission to send is obtained *from the recipient* of the traffic.
> 	- The traffic to which permission to send applies is *non-ICE* traffic.

NEW:
Consent:  The mechanism of obtaining permission from the remote endpoint to send non-ICE traffic to a remote transport address.  
Initial consent is obtained using ICE.

> 
> > >> [2] The security considerations appear to be incomplete.
> > >> There should be an explanation of why cryptographically strong STUN
> > >> transaction IDs are required (e.g., there are no cryptographically
> > >> strong IDs in the TCP consent mechanism noted on p.4), and there
> > >> should be a discussion of how and why replays of previous consent
> > >> responses are harmless (will be ignored by the recipient).
> >
> > Cryptographically strong STUN transaction IDs are required so that
> > off-path attacker does not replay old consent responses.
> >
> >
> >
> > >>The mechanism design
> > >> appears to be ok, but this rationale should be provided in terms of
> > >>attacks that are of concern and how they are prevented - a primary
> > >>intent appears to be to resisting off-path attacks.
> >
> > We will add the following line to Security Considerations section.
> >
> > NEW:
> >
> > Consent requires 96 bits transaction ID to be uniformly and randomly
> > chosen from the interval 0 .. 2**96-1, and be cryptographically strong.
> > This is good enough security against an off-path attacker replaying
> > old STUN consent responses.
> 
> That's good, but the actual problem is a missing reference.  The rationale
> discussion is in draft-ietf-rtcweb-security, so that draft needs to be added as
> a normative reference, plus text added to the security considerations section
> of this consent draft to call attention to sections 3.3 and 4.2 of that rtcweb-
> security draft.  

Added the following line to security considerations section
NEW:
Consent Verification to avoid attacks using browser as an
   attack platform against machines is discussed in sections 3.2 and 4.2
   of [I-D.ietf-rtcweb-security].


> This is in addition to the citation of sections
> 4.4 and 5.3 of draft-ietf-rtcweb-security-arch in the proposed new
> applicability text.

Added draft-ietf-rtcweb-security-arch and draft-ietf-rtcweb-security as normative references.

-Tiru

> 
> Thanks,
> --David
> 
> > -----Original Message-----
> > From: Ram Mohan R (rmohanr) [mailto:rmohanr@cisco.com]
> > Sent: Tuesday, May 19, 2015 11:28 AM
> > To: joel jaeggli; Black, David; muthu.arul@gmail.com; Dan Wing
> > (dwing); Tirumaleswar Reddy (tireddy); martin.thomson@gmail.com;
> > ops-dir@ietf.org; rtcweb@ietf.org
> > Subject: Re: OPS-Dir review of
> > draft-ietf-rtcweb-stun-consent-freshness-13
> >
> > Hi David/Joel,
> >
> > Please see inline for my responses.
> >
> >
> > -----Original Message-----
> > From: joel jaeggli <joelja@bogus.com>
> > Date: Friday, 15 May 2015 4:59 am
> > To: "Black, David" <david.black@emc.com>, "muthu.arul@gmail.com"
> > <muthu.arul@gmail.com>, "dwing@cisco.com" <dwing@cisco.com>, Cisco
> > Employee <rmohanr@cisco.com>, "tireddy@cisco.com"
> <tireddy@cisco.com>,
> > "martin.thomson@gmail.com" <martin.thomson@gmail.com>, "ops-
> dir@ietf.org"
> > <ops-dir@ietf.org>
> 
> > Cc: "rtcweb@ietf.org" <rtcweb@ietf.org>, "ietf@ietf.org"
> > <ietf@ietf.org>
> > Subject: Re: OPS-Dir review of
> > draft-ietf-rtcweb-stun-consent-freshness-13
> >
> > >Thanks David,
> > >
> > >I'll be looking with interest for the addressing of items 1/2.
> > >
> > >joel
> > >
> > >On 5/14/15 4:21 PM, Black, David wrote:
> > >> I have reviewed this document as part of the Operational
> > >> directorate's ongoing effort to review all IETF documents being
> processed by the IESG.
> > >> These comments were written with the intent of improving the
> > >> operational aspects of the IETF drafts. Comments that are not
> > >> addressed in last call may be included in AD reviews during the
> > >> IESG review.  Document editors and WG chairs should treat these
> > >> comments just like any other last call comments.
> > >>
> > >> Document: draft-ietf-rtcweb-stun-consent-freshness-13
> > >> Reviewer: David Black
> > >> Review Date: May 14, 2015
> > >> IETF LC End Date: May 15, 2015 (on -11)
> > >>
> > >> Summary: This draft is on the right track, but has open issues
> > >>  		described in the review.
> > >>
> > >> This draft describes use of STUN to obtain ongoing consent to send
> > >> in a fashion that is secured by the use of cryptographically strong
> > >> nonces as STUN transaction IDs.
> > >>
> > >> -- Major issues --
> > >>
> > >> [1] The draft seems to be missing discussion of applicability -
> > >> what environments and/or protocols is this mechanism intended for
> > >> or applicable to?  Is this generally applicable wherever ICE and
> > >> STUN are used?  I don't see any RFCs listed as updated by this
> > >> draft, so I'm guessing that this is not intended to promulgate new
> > >> requirements for all uses of ICE and STUN, but this should be
> > >> clarified.  The shepherd writeup implies that this draft is intended
> primarily for WebRTC.
> >
> > This document defines what it takes to obtain, maintain, and lose
> >    consent to send using ICE. This draft does not restrict on what
> > applications should use Consent. Currently on webRTC applications use
> > Consent, however any other application that has Similar security
> > requirements can use this mechanism. We will add a new section
> > ³Applicability² after the introduction section.
> >
> > <snip>
> > 2. Applicability
> >
> > This document defines what it takes to obtain, maintain, and lose
> > consent to send using ICE.Verification of peer consent before sending
> > traffic is necessary in deployments like WebRTC to ensure that a
> > malicious JavaScript cannot use the browser as a platform for
> > launching attacks.Section 4.4 and section 5.3 of
> > [I-D.ietf-rtcweb-security-arch] explains why webRTC application needs
> consent.
> >
> > Other Applications that have similar security requirement where it is
> > required to verify peer's consent before sending non-ICE packets can
> > use the consent mechanism described in this draft.
> >
> >
> > </snip>
> >
> >
> > Also we will modify para 3 of Intro to make it clearer.
> >
> > OLD:
> > This document defines what it takes to obtain, maintain, and lose
> >    consent to send.  Consent to send applies to a single 5-tuple.  How
> >    applications react to changes in consent is not described in this
> >    document.
> >
> >
> >
> > NEW:
> > This document defines what it takes to obtain, maintain, and lose
> > consent to send. Consent  to send applies to a single 5-tuple.  How
> > applications react to changes in consent is not
> >   described in this document. The consent mechanism does not update
> > the ICE procedures defined in [RFC 5245].
> >
> >
> >
> >
> >
> >
> > >>
> > >> [2] The security considerations appear to be incomplete.
> > >> There should be an explanation of why cryptographically strong STUN
> > >> transaction IDs are required (e.g., there are no cryptographically
> > >> strong IDs in the TCP consent mechanism noted on p.4), and there
> > >> should be a discussion of how and why replays of previous consent
> > >> responses are harmless (will be ignored by the recipient).
> >
> > Cryptographically strong STUN transaction IDs are required so that
> > off-path attacker does not replay old consent responses.
> >
> >
> >
> > >>The mechanism design
> > >> appears to be ok, but this rationale should be provided in terms of
> > >>attacks that are of concern and how they are prevented - a primary
> > >>intent appears to be to resisting off-path attacks.
> >
> > We will add the following line to Security Considerations section.
> >
> > NEW:
> >
> > Consent requires 96 bits transaction ID to be uniformly and randomly
> > chosen from the interval 0 .. 2**96-1, and be cryptographically strong.
> > This is good enough security against an off-path attacker replaying
> > old STUN consent responses.
> >
> >
> >
> > >>
> > >> -- Minor Issues --
> > >>
> > >> [3] In Section 1, please explain what ICE-lite is.  A suitable
> > >> reference should suffice.
> >
> > Yes we will add reference to RFC5245 that describes ICE-lite
> >
> >
> >
> > >>
> > >> [4] In Section 4.1, please explain or provide a reference for what
> > >>"paced"
> > >> means in "paced STUN connectivity checks or responses."
> >
> > Pacing is explained in the same section below. Let us know if this is
> > not sufficient/not clear.
> >  <snip>
> >     To prevent expiry of consent, a STUN binding request can be sent
> >     periodically.  To prevent synchronization of consent checks, each
> >     interval MUST be randomized from between 0.8 and 1.2 times the basic
> >     period.  Implementations SHOULD set a default interval of 5 seconds,
> >     resulting in a period between checks of 4 to 6 seconds.
> > </snip>
> >
> >
> >
> > >>
> > >> -- Nits/Editorial Comments --
> > >>
> > >> The SRTP paragraph in Section 8 (Security Considerations) feels out
> > >>of place
> > >> - this looks like design rationale material that would be better
> > >>located in  Section 3.
> >
> > Okay, will move this paragraph to Section 3.
> >
> >
> >
> > >>
> > >> idnits 2.13.02 found an unused reference:
> > >>
> > >>   == Unused Reference: 'I-D.ietf-rtcweb-overview' is defined on
> > >>line 320, but
> > >>      no explicit reference was found in the text
> > >>
> > >> That reference is likely to be useful to address the absence of
> > >>discussion of  applicability (major issue [1], above).
> >
> > This reference is not needed. Once we add applicability section we
> > will reference rtcweb-security-arch draft.
> >
> > >>
> > >> --- Selected RFC 5706 Appendix A Q&A for OPS-Dir review ---
> > >>
> > >> This mechanism is an incremental modification to the STUN and ICE
> > >>protocols,  and can be implemented by one party to a communication
> > >>session; ordinary  response generation behavior (already required)
> > >>reflects the cryptographically  strong STUN transaction IDs on which
> > >>the mechanism is based.  As a result, the  mechanism can be deployed
> > >>at one end of a two-party communication session  without impact on
> > >>the other party.  This is implied by section 3 of the draft,  but
> > >>would be useful to state explicitly.
> >
> > We will add a new applicability section proposed above and also
> > modified para 3 of Intro to make it clearer that this draft does not
> > change ICE procedures. Please let us know if this solves the comment
> above.
> >
> >
> > >>  [A.1.1 - deployment]
> > >>
> > >> The mechanism has been defined to limit the amount of added traffic
> > >>and to  shut down unwanted traffic, plus contains a facility to
> > >>desynchronize  independent users of this protocol.  Some rationale
> > >>should be added for  the choice of the 30 second timeout period.
> >
> > 30 second timeout period was selected so that consent checks could be
> > sent between 7 to 5 times (to handle packet loss).
> >
> >
> > >> [A.1.5 - network impact]
> > >>
> > >> There is an obvious fault condition, namely that consent is lost or
> > >>revoked  causing immediate cessation of traffic.  While the details
> > >>depend on the  environment in which this mechanism is used, it'd be
> > >>helpful to add a sentence  or two on reporting of the state of STUN
> > >>consent-based connectivity and how  that reporting should or may
> > >>relate to reporting of the state of other forms  of connectivity
> > >>(e.g., TCP, SRTP/SRTCP) that are mentioned in this draft.
> >
> > We specifically discussed in WG about how applications should handle
> > changes in Consent and it was decided to keep it outside the scope of
> > this draft. Para 3 of introduction already has a text that says the same.
> > There can be many possibilities if consent is lost or failed depending
> > on what the application wants.
> >
> >
> > >> [A.1.8 - fault and threshold conditions]
> > >>
> > >> This mechanism is a simple extension to existing protocols, and
> > >>should fit  into existing configuration and management for those
> > >>protocols. [A.1.9 -  configuration, A.2 - Management (in general)]
> > >>
> > >> It might be useful to mention the utility of tracking frequency and
> > >>duration  of loss and re-establishment of consent-based
> > >>connectivity, as such information  has operational value.  In
> > >>particular, a discussion of how a server could infer  loss of
> > >>connectivity with a client that is using this mechanism might be
> > >>useful  to add, as the operational concerns may be more significant
> > >>for servers and  related networks than clients. [A.2.2 - management
> > >>information, A.2.3 - fault  management].
> >
> > This again seems some thing outside the scope of this draft as it is
> > trying to specify application behavior. Is there some thing that you
> > want us to add in the draft for this?
> >
> > Regards,
> > Ram
> >
> > >>
> > >> The primary operational impact of this protocol should be reduction
> > >>in unwanted  traffic, which is a benefit - the consent check traffic
> > >>added by this protocol  should not have significant impacts.  The
> > >>writeup indicates that implementers  have reviewed the draft and
> > >>implementations are in progress. [A.3 - Documentation]
> > >>
> > >> Thanks,
> > >> --David
> > >> ----------------------------------------------------
> > >> David L. Black, Distinguished Engineer EMC Corporation, 176 South
> > >> St., Hopkinton, MA  01748
> > >> +1 (508) 293-7953             FAX: +1 (508) 293-7786
> > >> david.black@emc.com        Mobile: +1 (978) 394-7754
> > >> ----------------------------------------------------
> > >>
> > >>
> > >>
> > >
> > >