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

["Black, David" <[e-mail]>]

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.

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

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]>, "[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]
> >> ----------------------------------------------------
> >>
> >>
> >>
> >
> >