Subject: [Insipid] Eric Rescorla's Discuss on draft-ietf-insipid-logme-marking-12: (with DISCUSS and COMMENT)

From: Eric Rescorla <[email-masked]>
Date: Mon, 13 Aug 2018 13:41:14 -0700

Eric Rescorla has entered the following ballot position for
draft-ietf-insipid-logme-marking-12: 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-insipid-logme-marking/

----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

Rich version of this review at:
https://mozphab-ietf.devsvcdev.mozaws.net/D7386

DETAIL
S 6.1.
>   6.1.  "Log Me" Authorization
>   
>      An end user or network administrator MUST give permission for a
>      terminal to perform "log me" marking.  The configuration of a SIP
>      intermediary to perform "log me" marking on behalf of a terminal MUST
>      be authorized by the network administrator.

This seems to contradict S 4.4.2, which describes how you get logging
even when the responding UA doesn't support it (and thus presumably
doesn't give permission). Perhaps you mean "at least one end user or
administrator...?

S 6.4.2.
>      store all the SIP messages that are exchanged within a given dialog.
>      SIP messages can contain the personal identifiers listed in
>      Section 6.4.1 and additionally a user identity, calling party number,
>      IP address, hostname, and other user and device related items.  The
>      SIP message bodies describe the kind of session being set up by the
>      identified end user and device.

This seems to have extremely negative consequences when security
descriptions is used. It seems like you need to prohibit their
combination or at least call this out.

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

S 3.6.
>   
>   3.6.  Format of Logged Signaling
>   
>      The entire SIP message (SIP headers and message body) MUST be logged.
>      Logging SHOULD use common standard formats such as the SIP CLF
>      defined in [RFC6873] and Libpcap.  If SIP CLF format is used, the

Reference for libpcap?

---

From: Adam Roach <[email-masked]>
Date: Mon, 13 Aug 2018 15:48:43 -0500

>>       defined in [RFC6873] and Libpcap.  If SIP CLF format is used, the

For the authors' benefit -- you can find useful information about the 
format here: 
https://www.iana.org/assignments/media-types/application/vnd.tcpdump.pcap

That's probably as close to a stable reference that can be cited for the 
format.

/a

---

From: Ben Campbell <[email-masked]>
Date: Mon, 13 Aug 2018 16:33:27 -0500

> On Aug 13, 2018, at 3:41 PM, Eric Rescorla <[email-masked]> wrote:
> 
> S 6.4.2.

Oh, that’s a really good point; thanks for catching it :-)

Authors:  Security Descriptions [RFC 4568] typically includes SRTP keys directly in the SIP SDP bodies. SRTP keys _really_ shouldn’t show up in logs, at least without extreme caution. (probably not even then.)

A specific prohibition seems reasonable,  or at least some scary-strong guidance.

Thanks!

Ben.

---

From: "Arun Arunachalam (carunach)" <[email-masked]>
Date: Tue, 14 Aug 2018 14:58:27 +0000

Hi Eric, Adam and Ben,

Thanks for your comments!

Please see inline.

On Aug 13, 2018, at 4:41 PM, Eric Rescorla <[email-masked]<mailto:[email-masked]>> wrote:

DETAIL
S 6.1.

administrator…?

The statement "An end user or network administrator MUST give permission….” is applicable for scenarios in which the terminal supports “log me” marking. Whereas the statement “The configuration of a SIP intermediary to perform…” is applicable when the terminal doesn’t support “log me” marking.

We can rephrase this paragraph as:

“Log me” marking MUST be disabled by default both at the endpoints and intermediaries and MUST be enabled only by authorized users. For example, an end user or network administrator must give permission for a terminal that supports “log me” marking in order to initiate marking. Similarly, a network administrator must enable a configuration at the SIP intermediary to perform "log me" marking on behalf of a terminal that doesn’t support “log me” marking. The permission MUST be limited to only specific calls of interest that are originated in a given time duration.

S 6.4.2.

We can add the following lines to Section 8.4.2

When the SIP SDP message body contains security descriptions in the “crypto” attribute [RFC4568], the attribute value MUST be masked with a dummy value prior to storing the message in a log file. For example, the attribute value can be replaced with a string of special characters like “X”, “*” and “#” as shown in the example below.

a=crypto:XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

S 3.6.

Reference for libpcap?

We can use the reference provided by Adam.

Modified text:

"defined in [RFC6873] and Libpcap [application/vnd.tcpdump.pcap<https://www.iana.org/assignments/media-types/application/vnd.tcpdump.pcap>].  If SIP CLF format is used, the….”

Thanks!
Peter & Arun

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 14 Aug 2018 10:49:33 -0700

On Tue, Aug 14, 2018 at 7:58 AM, Arun Arunachalam (carunach) <
[email-masked]> wrote:

> On Aug 13, 2018, at 4:41 PM, Eric Rescorla <[email-masked]> wrote:
>
> The statement "An end user or network administrator MUST give
> permission….” is applicable for scenarios in which the terminal supports
> “log me” marking. Whereas the statement “The configuration of a SIP
> intermediary to perform…” is applicable when the terminal doesn’t support
> “log me” marking.
>
> “Log me” marking MUST be disabled by default both at the endpoints and
> intermediaries and MUST be enabled only by authorized users. For example,
> an end user or network administrator must give permission for a terminal
> that supports “log me” marking in order to initiate marking. Similarly, a
> network administrator must enable a configuration at the SIP intermediary
> to perform "log me" marking on behalf of a terminal that doesn’t support
> “log me” marking. The permission MUST be limited to only specific calls of
> interest that are originated in a given time duration.
>

Sure.

S 6.4.2.
> When the SIP SDP message body contains security descriptions in the
> “crypto” attribute [RFC4568], the attribute value MUST be masked with a
> dummy value prior to storing the message in a log file. For example, the
> attribute value can be replaced with a string of special characters like
> “X”, “*” and “#” as shown in the example below.
>

That would be OK. It would be useful perhaps, to go through all the
possible contents of SIP messages and sort out which contents would a
problem if disclosed.

-Ekr

> "defined in [RFC6873] and Libpcap [application/vnd.tcpdump.pcap
> <https://www.iana.org/assignments/media-types/application/vnd.tcpdump.pcap>
> ].  If SIP CLF format is used, the….”
>
> Thanks!
> Peter & Arun
>
>
>
>
>
>

---

From: "Arun Arunachalam (carunach)" <[email-masked]>
Date: Wed, 15 Aug 2018 16:16:20 +0000

Thanks Eric!

Please see inline of an updated text.

On Aug 14, 2018, at 1:49 PM, Eric Rescorla <[email-masked]<mailto:[email-masked]>> wrote:

On Tue, Aug 14, 2018 at 7:58 AM, Arun Arunachalam (carunach) <[email-masked]<mailto:[email-masked]>> wrote:
Hi Eric, Adam and Ben,

Please see inline.

DETAIL
S 6.1.

Sure.

S 6.4.2.

That would be OK. It would be useful perhaps, to go through all the possible contents of SIP messages and sort out which contents would a problem if disclosed.

We can broaden the statement by using the text below:

If the SIP SDP parameters [sdp-parameters<https://www.iana.org/assignments/sdp-parameters/sdp-parameters.xhtml>] contain sensitive security information (e.g., encryption keys),  such as crypto [RFC4568], 3GPP-Integrity-Key, 3GPP-SRTP-Config [RFC6064] attributes, then the attribute value MUST be masked with a dummy value prior to storing the message in a log file. For example, the “crypto” attribute value can be replaced with a string of special characters like “X”, “*” and “#” as shown in the example below.

Please let us know whether this addresses your comment.

Thanks!
Peter & Arun

-Ekr

S 3.6.

Reference for libpcap?

Modified text:

Thanks!
Peter & Arun