Re: [secdir] Secdir review of draft-ietf-sipcore-refer-explicit-subscription-02

Vincent Roca <vincent.roca@inria.fr> Tue, 23 June 2015 08:03 UTC

Return-Path: <vincent.roca@inria.fr>
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 78C6F1A9069; Tue, 23 Jun 2015 01:03:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.559
X-Spam-Level:
X-Spam-Status: No, score=-6.559 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] 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 kVe7AI-jG8oo; Tue, 23 Jun 2015 01:02:59 -0700 (PDT)
Received: from mail3-relais-sop.national.inria.fr (mail3-relais-sop.national.inria.fr [192.134.164.104]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 63B351A9055; Tue, 23 Jun 2015 01:02:45 -0700 (PDT)
X-IronPort-AV: E=Sophos;i="5.13,664,1427752800"; d="asc'?scan'208,217";a="137447316"
Received: from geve.inrialpes.fr ([194.199.24.116]) by mail3-relais-sop.national.inria.fr with ESMTP/TLS/DHE-RSA-AES256-SHA; 23 Jun 2015 10:02:43 +0200
Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\))
Content-Type: multipart/signed; boundary="Apple-Mail=_27313A55-C36F-4A3F-BAC1-93724AEEE8F0"; protocol="application/pgp-signature"; micalg=pgp-sha512
X-Pgp-Agent: GPGMail 2.5
From: Vincent Roca <vincent.roca@inria.fr>
In-Reply-To: <55882D28.3020701@nostrum.com>
Date: Tue, 23 Jun 2015 10:02:42 +0200
Message-Id: <DCB97AA2-6243-4266-B145-B6B6834AE627@inria.fr>
References: <2E90B73E-0309-4C49-B208-C2E30A0B6B22@inria.fr> <55882D28.3020701@nostrum.com>
To: Robert Sparks <rjsparks@nostrum.com>
X-Mailer: Apple Mail (2.2098)
Archived-At: <http://mailarchive.ietf.org/arch/msg/secdir/sewSMvMa0F0-YdBzEAaTKlgbM-I>
Cc: draft-ietf-sipcore-refer-explicit-subscription@tools.ietf.org, IESG <iesg@ietf.org>, secdir@ietf.org
Subject: Re: [secdir] Secdir review of draft-ietf-sipcore-refer-explicit-subscription-02
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/secdir/>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 23 Jun 2015 08:03:02 -0000

Hello Robert,

I have merged the two emails.

>>> I have several questions and suggestions WRT the Security Section.
>>> 
>>> It is said that: « With this update, there may multiple subscribers to any given refer event state."
>>> So what? What are the implications from a security point of view?
>> Hmm. I wonder if sentence order made this less clear than it should have been?
>> 
>> The paragraph that sentence appears in discusses exactly what the implications are - specifically that there is a new authorization consideration.
>> The paragraph that follow talks about how we deal with having that new consideration.

VR: Previous sentences of this paragraph explain that the authorization for a SUBSCRIBE is now decoupled from
the REFER mechanism. And then, the last sentence mentions the possibility of having **multiple** subscribers
which is not discussed previously, hence my remark. I don’t think it’s a matter of sentence order. And the paragraph
that follows does not mention nor discuss explicitly this idea of **multiple** subscribers. I don’t know if this notion
of **multiple** subscribers is difficult to handle or not, if it creates risks or not. Can you clarify the text?


>>> IMHO, the third paragraph does not make an appropriate use of the normative vocabulary.
>>> For instance, it is said:
>>>  "the URI should be constructed so that it is not easy to guess, and should be protected against eavesdroppers"
>>> Shouldn’t the author use « SHOULD » on both occasions?
>>> The following sentence is ambiguous. It says:
>>>  "For instance, SIP messages containing this URI SHOULD be sent using TLS or DTLS..."
>>> "SHOULD" and "For instance" are contradictory. I suggest removing "For instance".
>>> Similarly, next sentence says: "can redirect". I think "SHOULD" redirect is more appropriate.
>>> Finally the same remark (i.e. use « SHOULD") can be done for the next two sentences about additional authorization
>>> mechanisms.
>> Ben made a similar comment. The first 2119 requirement you point to needs to move up into the protocol definition part of the document.
>> The second is restating text that’s in RFC3261, and we don't need to repeat the 2119 here - I'll clarify the language to say "use the mechanisms the base specification provides".

VR: IMHO repeating normative vocabulary is not an issue as long as it is used homogeneously in the whole document,
whereas the opposite would be an issue.

>>> In the 4th paragraph, it is not clear to me why it is said that there is « a factor of 11 amplification due to retransmissions
>>> of the request ». What are the foundations for this « 11 » factor?
>> This is base SIP behavior. The non-INVITE transaction state machine retransmits 11 times before giving up if something on the other end doesn't talk back
>> (which is what will happen if the other endpoint is not SIP aware).

VR: okay, I see. I’ll let you judge whether it’s appropriate or not to justify this figure in the document.

>>> And what happens if the victim is SIP aware?
>> It will send an appropriate response, so there won't be the retransmissions of the request. In other words, sending this as raw traffic towards a sip aware element is no different than sending any other sip request towards a sip aware element.

VR: okay. Same remark as above.


>> Additionally, I have concerns about backward compatibility.
>> The mechanisms introduced by this extension may not be backward compatible with RFC 3515 (see section 7).
>> However I don’t see any discussion in the current document.
>> There are some guidelines in RFC 6656 (8.3.1) concerning the 202 response code, but what is described in the first
>> paragraph is new to this document.
> Our AD already noted that the second paragraph should actually be removed from this document - it is covered in refer-clarifications.

VR: ok

> For the first paragraph - backwards compatibility is ensured by the base SIP extension mechanism.
> An implementation of 3515 that is not aware of this extension (and the update to 3515 established by this document) would reject any requests that tried to invoke the extension (if either of the tokens defined here appeared in a Require: header field, that implementation would reject them with a 420 response.

VR: ok, I understand. But is « MAY accept » the appropriate? I don’t think so. What about:

NEW:
   The requirement in section 2.4.4 of [RFC3515] to reject out-of-dialog
   SUBSCRIBE requests to event 'refer' is removed.  An element MUST
   process a SUBSCRIBE request to event ‘refer', following the
   requirements and guidance in this document, since REFER is no longer the
   only mechanism that can create a subscription to event ‘refer’.

Cheers,

   Vincent