Subject: [seamoby] security for CT was [RE: Comments ct problem statement]

From: Nakhjiri Madjid-MNAKHJI1 <[email-masked]>
Date: Thu, 7 Jun 2001 15:28:49 -0500

Allison,

I am Sending comments on the security concerns:

We did have a section on security considerations originally, until
we were advised to remove it, since CT was not considered an existing
 protocol. 
I don't want to argue that decision;
I am just wondering what the procedure is.

Anyway, the security considerations sounds mostly like security
requirements, do we want to have security requirements in a
problem statement? The reason I am saying this is that,
in the security requirements, we did include a requirement
for mutual authentication of CT-peer ARs so that each side
authenticate the other side in order to prevent DoS attacks
by illegitimate ARs.

For reference I send portions of the security text that I
originally sent for problem statement and I guess for the sake
of conciseness did not make it in the draft (note the MUSTs and
Shoulds might be subject to debate now).
The first section is about security considerations
of CT and the second about security being
another reason why CT is beneficial

Security considerations

    Security services can be categorized into two groups, those provided
   To fulfill the security requirements of the MH (mobile host), and those
   provided to fulfill the security requirements of the network.
   Examples of security services provided to an MH are: user data
   encryption, user data integrity protection, and MH location privacy
   protection. While, examples of network security requirements are:
   protection of network topology and policy information.

   The mechanisms for establishing trust between the two parties involved
   in context transfer in order to transfer context data securely
  (as described below) should be provided.
   Prior to the process of context transfer, a mutual authentication
   Between the CT peers should happen (this could utilize the AAA
   Hierarchy, in case AAA admin domains are present). During this
   Authentication, the party receiving the context and the party
   transmitting the context, each provides proof of legitimacy to
   the other side. Data integrity protection should provided, so that
   the context information is protected from tampering by a third party.

   Encryption of context data might be necessary, in case MH location
   privacy and network topology and policy protection are required.
   In case security and AAA context are being transferred, the context
   Data must be encrypted. 

   The mobile node must ultimately retain control over whether it moves
   or not, and under what conditions it consents to have a network
   based move done on its behalf. In particular, the mobile node must
   have the ability to veto a move that could happen transparently, but
   may result in higher access charges, unexpected service degradation,
   loss of privacy, or other policy based exclusions. 

2- Other security reasons for a context transfer protocol

Context transfer, besides facilitating for mobility, can increase
The protecting the integrity of networks. With existence of a standard
approach such as context transfer, prior to which the peer networks
establish a secure channel by mutual authentication, and other security
measures (see requirements) if we choose to secure selected portions of
context,  we would be able to do so in a logically (maybe not physically)
central manner, i.e. at the same instance as context transfer and without
requiring multiple security requirements for various feature contexts.
As an example, policy context, QoS context, mobile's service profiles
and other data can all be secured at one stop point and transferred through
one already secure channel (between CT peers), without compromising
secret policy, network topology, user information, location, etc. to
unwanted men-in the middle attempting denial of service attacks or
simply tampering with the integrity of data that is being signaled.

Regards,
Madjid

-----Original Message-----
From: Allison Mankin [mailto:[email-masked]]
Sent: Friday, June 01, 2001 8:21 PM
To: Gary Kenward
Cc: 'seamoby'; 'Pat Calhoun'; [email-masked]
Subject: Comments Re: [seamoby] ct problem statement

Hi, Gary,

> Pat:
> 
>  I'm afraid to ask, but I must. What's up with the ct problem statement?
> 
> Gary

Since Pat said he'd consult the ADs to answer this:

I note that the WG last call on the CT problem statement ended two
days ago.  Were there issues brought up to any of the authors or
in the design team mailing list?  The working group list did not surface
any, that I saw, so I'll surface some that should be addressed before
we put the draft forward for advancement:

1. The draft is very concise and easy to read - you want to spoil
   us in the IESG by continuing this good trend by Seamoby (in the
   footsteps of the paging problem statement)?  [Needless
   to say, this is _not_ an issue :> ]

2. I would like to see some discussion of the problem space of
   how to evaluate when Internet CT makes sense and when it might
   not.  For instance, the point that if a feature context has
   information that took many exchanges and/or computation to set
   up, it is a better candidate.  Frequency of change of features
   would affect when CT is a good choice.   The goal is not
   to make any evaluations, but to give a problem space for the
   protocol design work to come. 

   How can the problem be described so that designers and eventual
   deployers can distinguish between optimizations that provide benefits
   only in narrowly constrained network circumstances and designs
   that provide broad enough benefits to be used at Internet level.

3. Security considerations - the point about the sensitivity of
   information carried in the CT is good, but the point about
   CT not raising new security concerns is too much of a leap. 
   Even with the good design point of having the MN work but just
   have a slower handoff when CT fails, there are risks to net and
   nodes.  Examples thought of quickly: 

     Malicious context transferrors that give incorrect but
     information that is not malformed, and damage/alter the MN's
     connectivity

     Malicious CT requests causing DoS to the Forwarding Nodes that
     have to process them.

   These are from quick thought.  A safer comment would be that CT
   probably will have novel security and requirements and design will
   have to address.  Check out draft-rescorla-cons-03.txt for more
   ideas for the requirements phase.

Thanks,

Allison