Subject: [Ecrit] Benjamin Kaduk's Discuss on draft-ietf-ecrit-data-only-ea-21: (with DISCUSS and COMMENT)

From: Benjamin Kaduk via Datatracker <[email-masked]>
Date: Mon, 02 Mar 2020 17:16:43 -0800

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/

---

From: Brian Rosen <[email-masked]>
Date: Tue, 3 Mar 2020 10:27:38 -0500

It will be very common for the entity sending the message to not be the entity hosting the referenced document.  For example, a device may send the MESSAGE, but some service that the device’s mfg operates hosts the CAP.  So we make NO assumptions that there is any connection between them.  The same is true for the Additional Data from 7852. 

Proposed text (revises the text I previously suggested to Roman)
This document describes potential retrieval of information by dereferencing URIs found in a Call Info header of a SIP MESSAGE.  These may include a CAP message as well as other Additional Data (RFC7852) blocks.  The domain of the device sending the SIP MESSAGE, the domain of the server holding the CAP message, if sent by reference, and the domain of other Additional Data blocks, if sent by reference, may all be different.  No assumptions can be made that there are trust relationships between these entities.  Recipients MUST take precautions in retrieving any Additional Data blocks passed by reference, including the CAP message, because the URI may point to a malicious actor.  The considerations in handling URIs in RFC3986 apply.  

With respect to your DISCUSS on timestamps.  Can I add:
Use of timestamps to prevent replay is subject to the availability of accurate time at all participants.  Because emergency event notification via this mechanism is relatively low frequency and generally involves human interaction, implementations may wish to consider messages with times within small number of seconds of each other to be effectively simultaneous for the purposes of detecting replay.  Implementations may also wish to consider that most deployed time distribution protocols likely to be used by these systems are not presently secure.

With regard to DoS, the only thing that makes this different from any emergency call situation is that there is no two way media with a human, and so you immediately assume a bot rather than a human, and therefore probably more likely to be a DoS source.

OTOH, there isn’t anything we can do with that information.  If I can generate large numbers of malicious SIP transactions, whether they are INVITE or MESSAGE doesn’t matter.  If I can compromise a device, whether it’s a phone that generates INVITE or an IOT device that generates MESSAGE, then I can misuse it.  I’m at a loss to know what to say.  I can supply the advice that the emergency authorities have always offered: automated devices have increased probability to generate false positive emergency calls/messages.  This is a burden on the emergency services which has to respond to all calls/messages.  In some jurisdictions, there are legal restrictions on automated emergency calls/messages, and in others, there are penalties for repeated false positive calls/messages.

I’ll work on the comments and reply if I have any issues as I update in response to them. 

Brian

> On Mar 2, 2020, at 8:16 PM, Benjamin Kaduk via Datatracker <[email-masked]> wrote:
>

---

From: Benjamin Kaduk <[email-masked]>
Date: Thu, 5 Mar 2020 09:35:51 -0800

Hi Brian,

> It will be very common for the entity sending the message to not be the entity hosting the referenced document.  For example, a device may send the MESSAGE, but some service that the device’s mfg o…

I was not trying to imply that they had to be the same entity, but rather
that (for the case when they are not), we might reasonably expect there to
be some policy relationship between them, such that the entity sending the
message can be reasonably assured that the content referred to will remain
stable and as-intended, and in the reverse direction to have the content
hosting service give some indication of what entities are expected (or
authorized) to refer to that content.  Depending on the scenario and how
important it is to the consuming application to enforce the desired
semantics in this space, we might also construct protocol mechanisms to
effectuate the desired enforcement, e.g., including a hash of the expected
content alongside the URI to the content.  Even if we don't deem the risk
significant to merit protocol mechanisms, we should still document the
risk, including the possibility for an attacker to send a notification with
a URI to a server that was expecting that resource to be accessed in a
different context and for an attacker to compromise the service hosting
URIs that legitimate clients refer to.

> This document describes potential retrieval of information by dereferencing URIs found in a Call Info header of a SIP MESSAGE.  These may include a CAP message as well as other Additional Data (RFC…

I think we should say "malicious actor or entity not expecting to be
referred to for this purpose" (or similar).
(I assume this is in addition to a reference to the full 3986
considerations.)

> Use of timestamps to prevent replay is subject to the availability of accurate time at all participants.  Because emergency event notification via this mechanism is relatively low frequency and gen…

That seems to cover the salient points; thanks.

> OTOH, there isn’t anything we can do with that information.  If I can generate large numbers of malicious SIP transactions, whether they are INVITE or MESSAGE doesn’t matter.  If I can compromise a…

I confess I did not have anything concrete in mind in terms of text to add,
when I wrote this, so thank you for thinking it through with me.  I
probably would supply that standard advice, though I don't think I would
insist upon it.

> I’ll work on the comments and reply if I have any issues as I update in response to them. 

Thanks!

-Ben

---

From: Brian Rosen <[email-masked]>
Date: Mon, 9 Mar 2020 13:55:53 -0400

> I don't think I understand when it's recommended to use 500 vs 425 (and
In SIP and HTTP, 400 series errors are used when the client sends you something the server doesn’t accept
500 series errors are used when the server itself has a problem.

If the server cannot or will not process the alert even though the request is valid, then 500 is appropriate.
Do I really need to say that?

> since that seems to still apply here.
This is a SIP extension, 3261 has stuff about mtu, and SIP implementations battle mtu issues all the time.  There are no special considerations here, just worth pointing out that the CAP message could add to their woes.

> Is *able* to detect, sure.  But is it recommended to do so?  Required?
It says “no additional vulnerability is created”.  It could happen legitimately, so normative text is needed.  But the information COULD be used to detect bad guys.  I don’t see what text I could add that would help.

> directly or by reference).
The risks are listed at the beginning of this paragraph.  STIR isn’t widely deployed yet, you can’t require it, and even if deployed, it may not be passed to the PSAP.  I think the RECOMMENDED is correct