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

"Arun Arunachalam (carunach)" <carunach@cisco.com> Wed, 15 August 2018 16:16 UTC

Return-Path: <carunach@cisco.com>
X-Original-To: insipid@ietfa.amsl.com
Delivered-To: insipid@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 250E0130FF7; Wed, 15 Aug 2018 09:16:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.509
X-Spam-Level:
X-Spam-Status: No, score=-14.509 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com
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 7x0xlNjhmwpp; Wed, 15 Aug 2018 09:16:23 -0700 (PDT)
Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0BF9C130FA0; Wed, 15 Aug 2018 09:16:23 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=25446; q=dns/txt; s=iport; t=1534349783; x=1535559383; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=lRBilSS2Hpv0o+LNtLBxfSnnz/T/Z5hoporcpK+G4gU=; b=FkMu3RrHmD2333mS7VIA5d021sL8MVsP2xhQnWWRUWQNZWfngIYgBh1n FPrvBiaNLfa02pdjpND5P5JixUscq7oBp7sARbi3s3n+PXW/bSDSelzkx GA5sqES0YNOojbN5dVDWxUPFOBqDoGihkbWFgAdf72CEc97vJ4nXBan7l A=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0ChAAAXUXRb/5RdJa1TCRkBAQEBAQE?= =?us-ascii?q?BAQEBAQEHAQEBAQGCV3hjfygKgyQ/iAqMM5ggFIFmCyWDEIE3AheDHSE0GAE?= =?us-ascii?q?CAQECAQECbRwMhTgGDBdWEAIBBgIOMQMCAgIwFBECBA4FgyIBgR1kD49mm0u?= =?us-ascii?q?BLoQqAYY0BYdTgUEXggCBEicfgkyBQYFaAgECAYEqAQgDBwFVgksxgiQCiAW?= =?us-ascii?q?EbYVIiDEJAoYjgnOGQw8GgTqELohEiwiFGIJaAhEUgSQdOGFYEQhwFWUBgj6?= =?us-ascii?q?BdSsRHIgNO4U+bwEBi2YPF4EIgRsBAQ?=
X-IronPort-AV: E=Sophos;i="5.53,243,1531785600"; d="scan'208,217";a="435354115"
Received: from rcdn-core-12.cisco.com ([173.37.93.148]) by rcdn-iport-7.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 15 Aug 2018 16:16:21 +0000
Received: from XCH-RCD-006.cisco.com (xch-rcd-006.cisco.com [173.37.102.16]) by rcdn-core-12.cisco.com (8.15.2/8.15.2) with ESMTPS id w7FGGLlO020650 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 15 Aug 2018 16:16:21 GMT
Received: from xch-aln-015.cisco.com (173.36.7.25) by XCH-RCD-006.cisco.com (173.37.102.16) with Microsoft SMTP Server (TLS) id 15.0.1320.4; Wed, 15 Aug 2018 11:16:21 -0500
Received: from xch-aln-015.cisco.com ([173.36.7.25]) by XCH-ALN-015.cisco.com ([173.36.7.25]) with mapi id 15.00.1320.000; Wed, 15 Aug 2018 11:16:20 -0500
From: "Arun Arunachalam (carunach)" <carunach@cisco.com>
To: Eric Rescorla <ekr@rtfm.com>
CC: Adam Roach <adam@nostrum.com>, Ben Campbell <ben@nostrum.com>, The IESG <iesg@ietf.org>, "draft-ietf-insipid-logme-marking@ietf.org" <draft-ietf-insipid-logme-marking@ietf.org>, "insipid@ietf.org" <insipid@ietf.org>, "Gonzalo Salgueiro (gsalguei)" <gsalguei@cisco.com>, "insipid-chairs@ietf.org" <insipid-chairs@ietf.org>, "Dawes, Peter, Vodafone Group" <Peter.Dawes@vodafone.com>, "Arun Arunachalam (carunach)" <carunach=40cisco.com@dmarc.ietf.org>
Thread-Topic: Eric Rescorla's Discuss on draft-ietf-insipid-logme-marking-12: (with DISCUSS and COMMENT)
Thread-Index: AQHUM0X8B5cM/gFFi0219JgYT2QnfKS/q8UAgAAv0YCAAXhIgA==
Date: Wed, 15 Aug 2018 16:16:20 +0000
Message-ID: <E8BDE219-9D8C-44A0-BF1C-7BEF938A22CE@cisco.com>
References: <153419287407.25053.6083538589111644157.idtracker@ietfa.amsl.com> <331AD917-D401-4B85-AD52-5A6607226823@cisco.com> <CABcZeBO2vGB4oVEhsjhJ2+p66tLBEecpaX3DmYk6Z5br1itoeQ@mail.gmail.com>
In-Reply-To: <CABcZeBO2vGB4oVEhsjhJ2+p66tLBEecpaX3DmYk6Z5br1itoeQ@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.150.54.205]
Content-Type: multipart/alternative; boundary="_000_E8BDE2199D8C44A0BF1C7BEF938A22CEciscocom_"
MIME-Version: 1.0
X-Outbound-SMTP-Client: 173.37.102.16, xch-rcd-006.cisco.com
X-Outbound-Node: rcdn-core-12.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/insipid/YY61ifYIAr4BKXrTGbORxtU6Tio>
X-Mailman-Approved-At: Wed, 15 Aug 2018 09:55:35 -0700
Subject: Re: [Insipid] Eric Rescorla's Discuss on draft-ietf-insipid-logme-marking-12: (with DISCUSS and COMMENT)
X-BeenThere: insipid@ietf.org
X-Mailman-Version: 2.1.27
Precedence: list
List-Id: SIP Session-ID discussion list <insipid.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/insipid>, <mailto:insipid-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/insipid/>
List-Post: <mailto:insipid@ietf.org>
List-Help: <mailto:insipid-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/insipid>, <mailto:insipid-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 15 Aug 2018 16:16:26 -0000

Thanks Eric!

Please see inline of an updated text.

On Aug 14, 2018, at 1:49 PM, Eric Rescorla <ekr@rtfm.com<mailto:ekr@rtfm.com>> wrote:



On Tue, Aug 14, 2018 at 7:58 AM, Arun Arunachalam (carunach) <carunach@cisco.com<mailto:carunach@cisco.com>> wrote:
Hi Eric, Adam and Ben,

Thanks for your comments!

Please see inline.

On Aug 13, 2018, at 4:41 PM, Eric Rescorla <ekr@rtfm.com<mailto:ekr@rtfm.com>> wrote:

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…?


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.

Sure.

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.


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

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.

a=crypto:XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX


Please let us know whether this addresses your comment.

Thanks!
Peter & Arun






-Ekr



----------------------------------------------------------------------
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?

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