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

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

> -----Original Message-----
> From: Black, David [mailto:[e-mail]]
> Sent: Wednesday, May 27, 2015 12:47 PM
> To: Ram Mohan R (rmohanr); joel jaeggli; [e-mail]; Dan Wing
> (dwing); Tirumaleswar Reddy (tireddy); [e-mail]; ops-
> [e-mail]; [e-mail]
> 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:[e-mail]]
> > Sent: Tuesday, May 19, 2015 11:28 AM
> > To: joel jaeggli; Black, David; [e-mail]; Dan Wing
> > (dwing); Tirumaleswar Reddy (tireddy); [e-mail];
> > [e-mail]; [e-mail]
> > 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 <[e-mail]>
> > Date: Friday, 15 May 2015 4:59 am
> > To: "Black, David" <[e-mail]>, "[e-mail]"
> > <[e-mail]>, "[e-mail]" <[e-mail]>, Cisco
> > Employee <[e-mail]>, "[e-mail]"
> <[e-mail]>,
> > "[e-mail]" <[e-mail]>, "ops-
> [e-mail]"
> > <[e-mail]>
> 
> > Cc: "[e-mail]" <[e-mail]>, "[e-mail]"
> > <[e-mail]>
> > 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
> > >> [phone]             FAX: [phone]
> > >> [e-mail]        Mobile: [phone]
> > >> ----------------------------------------------------
> > >>
> > >>
> > >>
> > >
> > >