Subject: [secdir] Secdir review of draft-ietf-mif-problem-statement-07

From: "Joseph Salowey (jsalowey)" <[email-masked]>
Date: Mon, 23 Aug 2010 13:10:03 -0700

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.

This document discusses a problem statement about a single host
supporting multiple interfaces and configuration associated with those
interfaces.   The document does have a security considerations section,
however I think it could benefit from more security discussion.  Here
are a few suggestions:

1) Lower layer authentication and encryption

It's possible that some interfaces may have link layer or IP layer
encryption and authentication.  Its possible that this characteristic
might be used in determining how configuration parameters are processed.
Some connection managers may already do this to a certain extent.  I
think this should be listed as a consideration in the appropriate
sections of the document (3.1, 3.6,5)

2) I think the security considerations can be expanded

It discusses that information may be leaked from one network to another
which seems to be talking about generic data.  This is true, but it
seems that would be worthwhile to talk specifically about the
information discussed in the document.  For example it seems that it is
at least possible for one interface to send configuration parameters
that will cause a denial of service on another interface.  It may also
be possible for one host to set configuration parameters which cause
certain traffic to be forwarded to an attacker.  

The last paragraph is also not very clear.  What I think you are trying
to say is that the information that is used by the connection manager
may be vulnerable to spoofing and forgery if it is unprotected.  In
general its not possible to protect this information in all cases, so it
is not clear what you are recommending.  

Cheers,

Joe

---

From: Jari Arkko <[email-masked]>
Date: Thu, 26 Aug 2010 01:20:50 -0400

Joe,

Thanks for your review!

> sections of the document (3.1, 3.6,5)

This seems reasonable. Authors, can you suggest some text and update the 
draft?

> certain traffic to be forwarded to an attacker.  

OK.

> is not clear what you are recommending.  

I agree that configuration information is unlikely to be fully secured, 
at least if "secured" means communications security or authentication.

Here's what I would say in that paragraph:

Additional security concerns raise up when information is provided to
the host so that it could make a more intelligent decision (e.g.
provide selection policies to the connection manager). This
additional information should be protected in some manner.
=>
Additional security concerns are raised by possible future mechanisms that
provide additional information to the host so that it can make a more
intelligent decision with regards to the issues discussed in this document.
Such future mechanisms may themselves be vulnerable and may not be
easy to protect in the general case.

Jari