[Ecrit] Benjamin Kaduk's Discuss on draft-ietf-ecrit-data-only-ea-21: (with DISCUSS and COMMENT)
Benjamin Kaduk via Datatracker <noreply@ietf.org> Tue, 03 March 2020 01:16 UTC
Return-Path: <noreply@ietf.org>
X-Original-To: ecrit@ietf.org
Delivered-To: ecrit@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 453293A155A; Mon, 2 Mar 2020 17:16:43 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Benjamin Kaduk via Datatracker <noreply@ietf.org>
To: The IESG <iesg@ietf.org>
Cc: draft-ietf-ecrit-data-only-ea@ietf.org, ecrit-chairs@ietf.org, ecrit@ietf.org, Allison Mankin <allison.mankin@gmail.com>, draft-ietf-ecrit-data-only-ea@ietf.org, allison.mankin@gmail.com
X-Test-IDTracker: no
X-IETF-IDTracker: 6.119.0
Auto-Submitted: auto-generated
Precedence: bulk
Reply-To: Benjamin Kaduk <kaduk@mit.edu>
Message-ID: <158319820318.27328.12390339422433838277@ietfa.amsl.com>
Date: Mon, 02 Mar 2020 17:16:43 -0800
Archived-At: <https://mailarchive.ietf.org/arch/msg/ecrit/pmMTduau7DjIlx3_xyP5S0jbwY0>
Subject: [Ecrit] Benjamin Kaduk's Discuss on draft-ietf-ecrit-data-only-ea-21: (with DISCUSS and COMMENT)
X-BeenThere: ecrit@ietf.org
X-Mailman-Version: 2.1.29
List-Id: <ecrit.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ecrit>, <mailto:ecrit-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ecrit/>
List-Post: <mailto:ecrit@ietf.org>
List-Help: <mailto:ecrit-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ecrit>, <mailto:ecrit-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 03 Mar 2020 01:16:44 -0000
Benjamin Kaduk has entered the following ballot position for draft-ietf-ecrit-data-only-ea-21: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-ecrit-data-only-ea/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- I support Roman's Discuss (and comment) and will expound on his first point some more. The use of URIs to refer to remote content, potentially hosted on a third party, has numerous security considerations, some better known than others. We need to reference the security considerations of RFC 3986 to get some coverage of these, such as the "reliability and consistency" point. One of the more subtle security considerations of using a URI to a remote resource as part of a request in cases such as this, is that the binding between the identity of the entity referring to the remote URI and the identity of the site providing the corresponding resource (i.e., the authority compoent of the URI) is not always clear. Although RFC 7852 requires TLS mutual authentication and HTTPS transport for information provided by reference, it makes no statement requiring the TLS server certificate to correspond to the SIP initiator, or any other indication of authorization that the indicated resource makes sense as part of the indicated request. I also have two other Discuss-level points: We discuss the use of timestamps in protocol elements for detecting replay; this requires that all participants have (secure and) accurate time. We need to document this dependency on accurate time, and optionally point out that common internet time protocols such as NTP are not particularly secure at present. I'm also not sure where there's existing treatment of using SIP MESSAGEs as a DoS attack vector; that seems particularly pronounced in the emergency-services case since emergency messages may receive preferential treatment from the network. ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Introduction (and Abstract?) medical monitors. These messages may be one-shot alerts to emergency authorities and do not require establishment of a session. These type of interactions are called 'non-interactive emergency calls'. Is this an existing/widespread definition or one new to this document? It may be worth providing a reference or rewording to clarify that it is a new definition. Section 2 CID is Content InDirection [RFC2392] The string "InDirection" does not appear in RFC 2392. Section 4.1 A CAP message may be sent in the initial message of any SIP transaction. However, this document only addresses sending a CAP message in a SIP MESSAGE transaction for a one-shot, non-interactive emergency call. Behavior with other transactions is not defined. I suggest rephrasing to "A CAP message is sent in the initial message of a SIP transaction" to avoid potential concerns about inconsistency between "may be sent" and "not defined". the CAP message. Alternatively, the Call-Info header field may contain a Content Indirect url [RFC2392] and the CAP message included nit: "Indirect" here vs. "InDirection" in Section 2 Section 4.2 field. If there is a need to copy the PIDF-LO structure referenced by 'geolocation' to <area>, implementers must be aware When might this occur? (It seems almost out of scope for this document based on my limited understanding.) that <area> is limited to a circle or polygon, and conversion of other shapes will be required. Points SHOULD be converted to a circle with a radius equal to the uncertainty of the point. Arc- bands and ellipses SHOULD be converted to an equivalent polygon. 3D locations SHOULD be converted to their equivalent 2D forms. nit: what is an "equivalent" polygon to an ellipse or arc-band? In a mathematical sense it might mean "strict equivalence" or a large-n limit of an n-gon, or perhaps there is a corresponding uncertainty on the ellipse/arc-band that the polygon must stay within? Rewording to "corresponding" might be an easy fix. Section 5.1 The 425 response code is a rejection of the request due to its included alert content, indicating that it was malformed or not satisfactory for the recipient's purpose. A SIP intermediary can also reject an alert it receives from a User Agent (UA) when it detects that the provided alert is malformed. (I assume there's an implicit "reject with this code" in here.) It is only appropriate to generate a 425 response when the responding entity has no other information in the request that is usable by the responder. I'm not sure I'm parsing this sentence correctly. My best guess is that it's saying "if there's anything in the request that you can respond to, don't use 425, even if there's some malformed CAP", but that doesn't really seem to be what the actual words are saying. [Section 5.2 seems to support my guess.] Section 5.2 message-header /= AlertMsg-Error ; (message-header from 3261) nit: mybe "RFC3261" to match the later comments? wrong with the alert in the request. This error code has a pedantic nit: the ABNF has 1-to-3-digit standardized -- meaning an operator can change the strings -- but MUST NOT change the meaning of the error code. Similar to how RFC 3261 specifies, there MUST NOT be more than one string per error code. RFC 3261 is ... pretty long. Maybe throw us a bone with a section reference? Also, I assume this "MUST NOT be more than one" is within a single AlertMsg-Error construction, since a truly global interpretation would mean that (since this document assigns strings) there cannot actually be changes made to the strings by an operator, which we just said is possible. This document defines an initial list of AlertMsg-Error values for any SIP response, including provisional responses (other than 100 Trying) and the new 425 response. There MUST be no more than one AlertMsg-Error code in a SIP response. AlertMsg-Error values sent in Is this redundant with the "MUST NOT" I was asking about above? Additionally, if an entity cannot or chooses not to process the alert message from a SIP request, a 500 (Server Internal Error) SHOULD be used with or without a configurable Retry-After header field. I don't think I understand when it's recommended to use 500 vs 425 (and vice versa). Section 7 It's probably worth mentioning RFC 3428's note about: % The size of MESSAGE requests outside of a media session MUST NOT % exceed 1300 bytes, unless the UAC has positive knowledge that the % message will not traverse a congestion-unsafe link at any hop, or % that the message size is at least 200 bytes less than the lowest MTU % value found en route to the UAS since that seems to still apply here. Section 8 I'd consider using a more recent date than 2008-11-19 for the example <sent> time. Also, why is the timestamp in the additional information 2010-11-14, almost two years later? <gml:pos>32.86726 -97.16054</gml:pos> Is that ... someone's house? Maybe some different coordinates would be more appropriate. Figure 3 has "Content-Disposition: by-reference;handling=optional" but Figure 4 does not; is that significant? Section 9 In any case, for alerts initiated by sensors, the identity could play an important role in deciding whether to accept or ignore an incoming alert message. With the scenario shown in Figure 1 it is very likely that only authenticated sensor input will be processed. For this reason, it needs to be possible to refuse to accept alert messages from an unknown origin. Two types of information elements can be used for this purpose: 1. SIP itself provides security mechanisms that allow the verification of the originator's identity, such as P-Asserted- Identity [RFC3325] or SIP Identity [RFC8224]. The latter provides a cryptographic assurance while the former relies on a chain of trust model. These mechanisms can be reused. 2. CAP provides additional security mechanisms and the ability to carry further information about the sender's identity. Section 3.3.4.1 of [cap] specifies the signing algorithms of CAP documents. I'd consider adding a note that "the specific policy and mechanisms used in a given deployment are out of scope for this document", since the actual requirements in practice are so broad that we cannot really make detailed recommendations here. In addition to the desire to perform identity-based access control, the classic communication security threats need to be considered, including integrity protection to prevent forgery or replay of alert messages in transit. To deal with replay of alerts, a CAP document contains the mandatory <identifier>, <sender>, <sent> elements and an optional <expire> element. Together, these elements make the CAP document unique for a specific sender and provide time restrictions. An entity that has already received a CAP message within the indicated timeframe is able to detect a replayed message and, if the content of that message is unchanged, then no additional security Is *able* to detect, sure. But is it recommended to do so? Required? vulnerability is created. Additionally, it is RECOMMENDED to make use of SIP security mechanisms, such as the SIP Identity PASSporT [RFC8225], to tie the CAP message to the SIP message. To provide Not required? Please describe the risks of not doing so (whether directly or by reference). protection of the entire SIP message exchange between neighboring SIP entities, the usage of TLS is REQUIRED. Just to check: this is a 100% always, for everyone, "REQUIRED", not just in the subset of cases where protection of the entire exchange is desired? Note that none of the security mechanism in this document protect against a compromised sensor sending crafted alerts. Privacy provided for any emergency calls, including non-interactive messages, is subject to local regulations. I suggest using "confidentiality protection" rather than "privacy" (unless it's a term of art in this field), to avoid confusion with... Privacy considerations for alerts (e.g., generated by sensors) that should be discussed. RFC 7852 has some extensive privacy considerations that can be referenced to do the bulk of the work here. I'd also consider reiterating the opportunistic nature of cryptographic protection on emergency messages, as discussed in 6443 (since insecure emergency messaging is preferred to no emergency messaging), but this is not strictly speaking required. Section 12.2 RFC 8225, as a RECOMMENDED feature, is more properly listed as a normative reference, per https://www.ietf.org/about/groups/iesg/statements/normative-informative-references/
- [Ecrit] Benjamin Kaduk's Discuss on draft-ietf-ec… Benjamin Kaduk via Datatracker
- Re: [Ecrit] Benjamin Kaduk's Discuss on draft-iet… Brian Rosen
- Re: [Ecrit] Benjamin Kaduk's Discuss on draft-iet… Benjamin Kaduk
- Re: [Ecrit] Benjamin Kaduk's Discuss on draft-iet… Brian Rosen