[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