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

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

Return-Path: <benl@google.com>
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id 276BC21F88C4 for <secdir@ietfa.amsl.com>; Thu, 10 Jan 2013 03:55:19 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.977
X-Spam-Status: No, score=-102.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id wZS5zXlYGQ1p for <secdir@ietfa.amsl.com>; Thu, 10 Jan 2013 03:55:18 -0800 (PST)
Received: from mail-we0-f169.google.com (mail-we0-f169.google.com []) by ietfa.amsl.com (Postfix) with ESMTP id 7165821F88AE for <secdir@ietf.org>; Thu, 10 Jan 2013 03:55:17 -0800 (PST)
Received: by mail-we0-f169.google.com with SMTP id t49so218059wey.28 for <secdir@ietf.org>; Thu, 10 Jan 2013 03:55:16 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:date:message-id:subject:from:to :content-type; bh=1BwLxG1Ijyq0UZgMZhk7cx7O11T2sQ4S+UBGr26CXyM=; b=bLO556UKfQH+cLN1OwuRtHl0ZhSimNC27Hv0UHVtKPw/eJUQl6hRXhLoEvy2oz4CwA wrJF10rsKCQ0+k9X39c+j0LIxoq+551bf1Sf9fmmREd5fXEd9Y5YOadfFr5cy09c33ys fne1DU2N/7ekKZmtGFjdaTsVdxCmLc2e5xj8Ll6RtCLcrYJfe9Y/aE2cnDSPxUL7h3YO SbcS/HwPjE4oVysMj3LiVXdRglJAH5aJgGIzRdOkXPXwT4I0o6iOKTsB5x/DnSuVr+fO HJreln0vWdt8CWZOpPQxxZ30L+NiAprGDMoDzVwGBdXt6EiJ3WKSWY93APaOTzCofk6G HDCQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:date:message-id:subject:from:to :content-type:x-gm-message-state; bh=1BwLxG1Ijyq0UZgMZhk7cx7O11T2sQ4S+UBGr26CXyM=; b=nDSvxgByuOE0oq0W1hlPIHY69HqdKHxnlxSrcA8UDaLpYxXQdOfTGgneuGCMF1jtv+ SEKe4il3t5bMfAHSDQqLATH2W1AhcRZrhxpfJQjXx7ecAMB/hZ3SG3RN8Q2vqpEIZOAL Z0yIhHf/5nVkeEOQUjCstz8KHqF7xc/z0YedqmrosPMJBTab2VpaCQ4QHWc9PPsSON93 Pep24yNLhaWtBjBgBNtnKu68ab7MVBgJ7w2MpqBVJc0PeyUA7n3GkMsIETdn6VMBbxk4 uSF5caeNZJ7SuibE3SnKY8y6rkC+T8rLWSC/YuOmyssmW0ndMkIBKEbCCA2v5tBKsVm+ qC7A==
MIME-Version: 1.0
X-Received: by with SMTP id b1mr8670858wiz.26.1357818916276; Thu, 10 Jan 2013 03:55:16 -0800 (PST)
Received: by with HTTP; Thu, 10 Jan 2013 03:55:16 -0800 (PST)
Date: Thu, 10 Jan 2013 11:55:16 +0000
Message-ID: <CABrd9SRw9uuS2FA7K1VEzJ=H5P2WJQy2hO=WCLzdGKH2OCAMuw@mail.gmail.com>
From: Ben Laurie <benl@google.com>
To: iesg@ietf.org, secdir@ietf.org, draft-ietf-ipfix-information-model-rfc5102bis.all@tools.ietf.org
Content-Type: text/plain; charset=ISO-8859-1
X-Gm-Message-State: ALoCoQnmpR2A3AbyYVYC+guQur0cUuOCgfzGMkjYqAOaY5e/oibbHHvtiEUNflzIj8wAggqMV5sYKE7IaaMIwnSkFk/OF/HnHFnhtZLmqRPgO7T2xLavtUb9f50LMEozNAtKwPA/oEtd5EFG3j4iZyWeK3H6Ud9SzmW02oyUlD4eRaN2xg9r2b2C75435yZDkfx3M/EQbzTW
Subject: [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: Thu, 10 Jan 2013 11:55:19 -0000

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. 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, nor about access control. Given
that flow information is potentially quite sensitive, this is
surprising. The document itself seems OK, with 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.