[secdir] secdir review of draft-korhonen-mip4-service-07
Tom Yu <tlyu@MIT.EDU> Tue, 06 January 2009 22:13 UTC
Return-Path: <secdir-bounces@ietf.org>
X-Original-To: secdir-archive@ietf.org
Delivered-To: ietfarch-secdir-archive@core3.amsl.com
Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CF4763A69D2; Tue, 6 Jan 2009 14:13:54 -0800 (PST)
X-Original-To: secdir@core3.amsl.com
Delivered-To: secdir@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B493A3A69B1; Tue, 6 Jan 2009 14:13:53 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.028
X-Spam-Level:
X-Spam-Status: No, score=-6.028 tagged_above=-999 required=5 tests=[AWL=0.571, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QXtqxiFrLMJm; Tue, 6 Jan 2009 14:13:52 -0800 (PST)
Received: from biscayne-one-station.mit.edu (BISCAYNE-ONE-STATION.MIT.EDU [18.7.7.80]) by core3.amsl.com (Postfix) with ESMTP id AEE923A67AC; Tue, 6 Jan 2009 14:13:52 -0800 (PST)
Received: from outgoing.mit.edu (OUTGOING-AUTH.MIT.EDU [18.7.22.103]) by biscayne-one-station.mit.edu (8.13.6/8.9.2) with ESMTP id n06MDWtl022362; Tue, 6 Jan 2009 17:13:32 -0500 (EST)
Received: from cathode-dark-space.mit.edu (CATHODE-DARK-SPACE.MIT.EDU [18.18.1.96]) (authenticated bits=56) (User authenticated as tlyu@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.6/8.12.4) with ESMTP id n06MDTo1009182 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 6 Jan 2009 17:13:31 -0500 (EST)
Received: (from tlyu@localhost) by cathode-dark-space.mit.edu (8.12.9.20060308) id n06MDThB002402; Tue, 6 Jan 2009 17:13:29 -0500 (EST)
To: secdir@ietf.org, iesg@ietf.org, jouni@gmail.com, ulf.s.nilsson@teliasonera.com
From: Tom Yu <tlyu@MIT.EDU>
Date: Tue, 06 Jan 2009 17:13:28 -0500
Message-ID: <ldvocykulpz.fsf@cathode-dark-space.mit.edu>
Lines: 29
MIME-Version: 1.0
X-Scanned-By: MIMEDefang 2.42
Subject: [secdir] secdir review of draft-korhonen-mip4-service-07
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/pipermail/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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: secdir-bounces@ietf.org
Errors-To: secdir-bounces@ietf.org
This document seems largely parallel to RFC 5149. (Which, incidentally, does not appear to have come up for secdir review, at least according to my mail archives.) The Security Considerations section appears to adequately describe considerations for the confidentiality protection for the service identifier. There may be denial of service vulnerabilities due to the requirements that the parties terminate an existing binding upon experiencing an authorization failure of a registration attempt that requests a change of service selection. An attacker capable of forging a registration request selecting a service for which the purported user lacks authorization could maliciously terminate an existing binding. If the request is authenticated (with a sufficiently strong mechanism) prior to the processing of the service selection, this is not a problem. I did not extensively research whether any current IPv4 Mobility authentication mechanisms are sufficiently strong to thwart this sort of attack, though I expect that at least some of the mechanisms are sufficiently strong. It would be nice to have some additional text emphasizing that the sort of authorization process that may result in the home agent's termination of the binding should only occur after the home agent successfully authenticates the content of the request. I think it is not a strong requirement to include such text, because a creator of a quality implementation could probably infer the need for this behavior from existing text in the document. _______________________________________________ secdir mailing list secdir@ietf.org https://www.ietf.org/mailman/listinfo/secdir