Re: [secdir] Security review of draft-ietf-ipfix-information-model-rfc5102bis-09

Ben Laurie <benl@google.com> Fri, 11 January 2013 10:33 UTC

Return-Path: <benl@google.com>
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 888D621F88C7 for <secdir@ietfa.amsl.com>; Fri, 11 Jan 2013 02:33:37 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.677
X-Spam-Level:
X-Spam-Status: No, score=-102.677 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_41=0.6, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vyV56XksqaHq for <secdir@ietfa.amsl.com>; Fri, 11 Jan 2013 02:33:36 -0800 (PST)
Received: from mail-wi0-f178.google.com (mail-wi0-f178.google.com [209.85.212.178]) by ietfa.amsl.com (Postfix) with ESMTP id 8C7BD21F88D6 for <secdir@ietf.org>; Fri, 11 Jan 2013 02:33:32 -0800 (PST)
Received: by mail-wi0-f178.google.com with SMTP id hn3so926810wib.5 for <secdir@ietf.org>; Fri, 11 Jan 2013 02:33:31 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=PzisIdnmyfKCd0xSPFSM8/C8RaB1ljnvtrgdAr0CgEY=; b=lAW4Px7hIL26skOkHg9DHzhGH1bUR5IHK6IGr0yqA1I2+fHHL7T36OhvtLv8CM2NoT aLJs7r/MSEX0E1/hyae1d39wGKLq3LDe5zgOTmoRZ1iu9LEDMsswkKqSGMfx0XlFakQW qE9m4XHAN1RwLR0p+ftVEp96K4A3kig7f+AQXyHVkH5I9pbYa5QBz/nZnUVYTx/20cCj fM3u6s+rDwDuIEvHGa3Ija71w0VD4yv81rWfZWzyPnT9CpQGSCuhf+R/XhnBy3UcYNiU OEyQSkrYf74MlyMqolkJP4eNVSZ2SHorYwj5//vSRA0b30v1QAbZNJM6D0CiGVpYuJJ9 6PQg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding:x-gm-message-state; bh=PzisIdnmyfKCd0xSPFSM8/C8RaB1ljnvtrgdAr0CgEY=; b=JAxbGB7Xz/BKmZzngb6hOS9+qX8NVbF4wdvPFAzX3bSfPxL0Wik7nStnbChY6RanXT jNrKWCnqFeYiKpZ6jfzh8IVEv2KaQ48mA/C+ucSyX9317T+GuJPvijzbUixrCLR53JWi wGIX4e4zpufeJvnQX/whFj543a82YEqdnlZ1TtY/8KVNeg4swSN2qDt+yFOMAfBsqtKd 1EoWcgJRX98EBDTgNvYtObjvA6Q7EygJ/V/Sggs0/KB3Hh6Zy+BDZxDF3Fve7/lgICcn GOUUmtOsg1S7K79zvSnacYCEOEap/YGUn3kQhnxrjzKC7mat4HiCD0HRSA63Ejl1i+Nk 5BLQ==
MIME-Version: 1.0
Received: by 10.180.77.68 with SMTP id q4mr14470656wiw.10.1357900411497; Fri, 11 Jan 2013 02:33:31 -0800 (PST)
Received: by 10.194.234.134 with HTTP; Fri, 11 Jan 2013 02:33:31 -0800 (PST)
In-Reply-To: <8DCB34ED-F075-47C6-BE07-4B40B1A242F9@tik.ee.ethz.ch>
References: <CABrd9SRw9uuS2FA7K1VEzJ=H5P2WJQy2hO=WCLzdGKH2OCAMuw@mail.gmail.com> <8DCB34ED-F075-47C6-BE07-4B40B1A242F9@tik.ee.ethz.ch>
Date: Fri, 11 Jan 2013 10:33:31 +0000
Message-ID: <CABrd9SSrhuWd4PQW8f_mh4F6CvE8a8Lj5JpO-Q+-QuzV315UHQ@mail.gmail.com>
From: Ben Laurie <benl@google.com>
To: Brian Trammell <trammell@tik.ee.ethz.ch>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
X-Gm-Message-State: ALoCoQl4e1iSxsn92mklJ1/H+I70LX9qf4tTxoiGuLAP/kWh/xm6QhBrH5Vr9ei8J1xJoqm0htvLZudyaKoyEEsaIi9TGONACPzHJhYve9Z/r/2p/WAyhcOHhtQgGq0O5xZ0/OaKYCRLpeJlMb2+1oJ4aU045JCcSLn6O+0LCmxhXJ6ubHo8TP9DE7h8jw2WciiQYZ8JBWzN
Cc: draft-ietf-ipfix-information-model-rfc5102bis.all@tools.ietf.org, The IESG <iesg@ietf.org>, "ipfix@ietf.org Working Group" <ipfix@ietf.org>, secdir@ietf.org
Subject: Re: [secdir] Security review of draft-ietf-ipfix-information-model-rfc5102bis-09
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.12
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: <http://www.ietf.org/mail-archive/web/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: Fri, 11 Jan 2013 10:33:37 -0000

On 11 January 2013 09:24, Brian Trammell <trammell@tik.ee.ethz.ch>; wrote:
> Hi, Ben,
>
> Many thanks for the review. Comments/questions thereon inline.
>
> On Jan 10, 2013, at 12:55 PM, Ben Laurie <benl@google.com>; wrote:
>
>> I have reviewed this document as part of the security directorate's
>> ongoing effort to review all IETF documents being processed by the
>> IESG.  These comments were written primarily for the benefit of the
>> security area directors.  Document editors and WG chairs should treat
>> these comments just like any other last call comments.
>>
>> Summary: this document is part of a series of documents describing the
>> protocol, and only deals with data elements. As such, most security
>> considerations are dealt with elsewhere.
>
> (I'll address the following as comments on 5101 / 5101bis, specifically section 11, which I assume you're referring to...)

Right.

>
>> However, I note that whilst a
>> good deal of attention is paid to integrity and authentication of the
>> data in those other documents, as far as I can see nothing is said
>> about authentication of the requester,
>
> As IPFIX is a push protocol designed for operation within a network management infrastructure there is no "requester" per se. There are only exporters and collectors, the former configured (out of band) to send information to the latter, the latter to accept information from the former. Section 11.3 of rfc5101(-bis) addresses authentication of exporters and collectors....

Ah, that was not clear to me, thanks for the explanation. It might be
nice to at least mention that the out of band configuration is also
security sensitive (and perhaps mention the push nature of the
protocol in the security considerations to make it clearer for the
non-expert).

>
>> nor about access control.
>
> ...however, while the intention of section 11.3 of RFC5101(-bis) was to state that collectors/exporters should only establish sessions with peers that they could authenticate using TLS mutual authentication, on rereading I see that this isn't explicitly stated in that section. We should fix that.
>
> Section 11 is also a little outdated (at least with respect to terminology for doing DNS-ID lookups) and appears to be needlessly restrictive (e.g., TLS-PSK is not allowed although it would be useful in this case). We should review this as well.

I didn;t intend to review 5101 as well, but anyway re-reading this
section raises some questions

1. What is meant by "Each of the IPFIX Exporting and Collecting
Processes MUST verify the identity of its peer against its authorized
certificates" is a little unclear - does it mean the cert must match
an authorized cert, or that it must chain from one?

2. There's a requirement to match the DNS name - but the server end of
the connection may not have access to the client's (relevant) DNS
name. Presumably there's some more complex process involving DNS
lookups you have in mind here? (And if you introduce PSK, there's no
cert).

3. As it stands it would be perfectly OK for an exporter to connect to
a collector and then send it data for flows it is not configured to
send (but are expected from another exporter).

>
>
>> Given
>> that flow information is potentially quite sensitive, this is
>> surprising. The document itself seems OK, with nits.
>
>> Nits:
>>
>> "3.1.14. string
>>
>>   The type "string" represents a finite-length string of valid
>>   characters from the Unicode character encoding set
>>   [ISO.10646-1.1993].  Unicode allows for ASCII [ISO.646.1991] and many
>>   other international character sets to be used."
>>
>> RFC 5610 says this is encoded using UTF-8. UTF-8 can have security
>> issues, e.g. sending a string with an incomplete UTF-8 encoded
>> character, which then swallows part of a following string, or causes
>> errors in parsers. Although this document may not be the right place
>> for it, it is unfortunate this potential problem is not mentioned.
>
> This is good point. Would you know of an existing description of this problem, ideally with mitigation strategies at the receiver, that we could reference here? Again, I think this would be something to address in 5101bis, as 5102bis is concerned with _abstract_ data types, and 5101bis presents the IPFIX-compatible encoding of those data types.

"Unicode Security Considerations"
(http://www.unicode.org/reports/tr36/#UTF-8_Exploit) has a good
discussion.