[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

A new I-D on authorization issues in IPv6

[My aplogies for sending this to three separage
lists, but IMHO this is really relevant to all of them.]

A have submitted a new I-D concerning a number of 
authorization issues in IPv6 related signalling,
including Mobile IPv6 Binding Updates.  The purpose
of the I-D is to summarize and clarify the situation
from this specific security point of view.  As it
has not appeared in the archieves yet, it is also
available at

  http://www.nomadiclab.com/~pnr/publications/\
draft-nikander-ipng-address-ownership-00.txt

I hope that the draft can act as one input to the
the forthcoming Mobile IPv6 discussion to be held
at Minneapolis, and clarify some issues related to
using IPsec in IPv6 to protect various kinds of
signalling messages.

For your convenience, I've included the draft abstract
below.  

--Pekka Nikander


Abstract

   This document seeks to clarify a number of problems related to
   authorization of changing local routing information in the current
   IPv6 architecture.  This document does not (currently) cover actual
   routing protocols.  Instead, in IPv6, there are a number of
   additional mechanisms that allow local routing information to be
   changed.  Some mechanisms are meant to be used only locally, while
   someof them allow changes to be initiated from a remote location;
   in the latter case, IPsec is used to protect the relevant
   signalling messages.  However, the current specifications are
   partially obscure about the actual authorization requirements that
   must be met in order to be actually secure.  The purpose of this
   document is to clarify the situation, and foster understanding of
   the potential attacks and required countermeasures.

   In this document, we first collect together and summarize the
   non-routing-protocol mechanisms that allow routing information to
   be changed.  After that, we classify the mechanisms using a couple
   of orthogonal dimensions.  Finally, we discuss the authorization
   requirements for the different mechanisms.

   It is important to note that the security problems discussed in
   this document become relevant only when we start to consider
   multiple security domains.  As long as the mechanisms are used only
   within a single security domain, where all nodes are equally
   trusted, the problem does not exist.  However, if several security
   domains are connected together, or if anything like "opportunistic
   IPsec", as promoted by John Gilmore, becomes reality, the problems
   discussed in this document will become very real.

   An other way of expressing the scope of the problems is to say that
   the attacks can be characterized as insider attacks.  In general,
   the IPsec architecture, as it stands today, is relatively good in
   keeping outsiders out.  However, it is currently not nearly as good
   at dealing with attacks from within.  In a way, when IPsec is used
   to protect application level traffic, the applications are assumed
   to take care of their specific protection needs, e.g., in the form
   of user names, passwords, and application or operating system
   access control lists.  Unfortunately, when IPsec is used to protect
   traffic signalling, as discussed in this document, the controls do
   not seem to be adequate.  Basically, this is an authorization
   problem.