Subject: [seamoby] Security Considerations - new wording

From: "Gary Kenward" <[email-masked]>
Date: Mon, 4 Jun 2001 15:21:38 -0400

Below is a possible new wording for section 9 of the problem statement
draft. I have *tried* to write it so that it identifies the concern over
ct security, and the intent to investigate requirements, while asserting
that ct will use what is available first, and only if justified, attempt
to develop new security solutions.

Opinions welcome - contributed text preferred, please!

Gary

=========================================================================

9	Security Considerations

	Some of the considerations for context transfer security include:

	        - information privacy: the context may contain information 
	          which the end user would prefer to keep hidden from
	          unauthorized viewers.

	        - transfer legitimacy: a false or purposely corrupted
	          context transfer could have a severe impact upon the
	          operation of the receiving forwarding node, and therefore
	          could potentially effect the operation of the access
	          network itself; context transfer must only occur between
	          forwarding nodes that have an established trust 
	          relationship.
	        
	        - security preservation: part of the context transfer may
	          include information pertinent to a security association 
	          established between the mobile node and another entity on 
	          the network; for this security association to be preserved
	          during handover, the transfer of the security context 
	          must include the appropriate security measures.

	It is expected that the measures used to secure the transport of
	information between peers in an IP network should be sufficient for
	context transfer. However, given the above considerations, there 
	may be reason to provide for additional security measures beyond the
	available IETF solutions. 

	The context transfer investigation must identify any novel security 
	measures required for context transfer that exceed the capabilities 
	of the existing or emerging IETF solutions.

---

From: [email-masked]
Date: Tue, 5 Jun 2001 13:01:19 +0300

Hi Gary,

I think that we need to cover DOS attacks here.  I don't
think we need to go into deep detail about it, but I 
can envision some problems with CT w.r.t. DOS attacks.

The CT protocol itself might not assume any state, but
if a bad guy could send context (i.e. - state) to an AR,
it might be able to overrun the ARs buffers.  

Alternatively, we need to ensure a third party cannot
re-direct context as well.

These two subjects could fall under the 'transfer legitimacy' 
bullet.  

So, text might be:

	- prevention of DOS-style attacks.  Context transfer
	MUST NOT create any new opportunities for denial of 
	service (DOS) attacks.  These include (but are not 
	limited to): flooding of bogus context in order 
	to overrun the capacity of the target node; and the 
	redirection of context in order to prevent the 
	successful completion of the context transfer.

How's that?

---

From: "Gary Kenward" <[email-masked]>
Date: Tue, 5 Jun 2001 11:49:35 -0400

John:

  Good suggestions. I was actually referring to DOS and other
similar attacks with the euphemism "transfer legitimacy". Not
being a security guru myself, I wasn't sure if there was an
acceptable general term, so I created one.

  I was purposely trying to avoid being too specific in the problem
statement. I worry that we could end up with a shopping list of
potential threats. 

Given the direction we are going, I suspect that we will have to 
enumerate the various threats in the requirements draft anyway, as
we are attempting to do with reliability (although, my preference 
would be to defer such a list until a proper threat analysis could
be performed on the protocol design). Either way, the analysis will
be done at least once, and more likely many, many times.

Anyway, that was my thinking. Of course, if the dt wants, it can
all be changed. Comments?

Gary

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
> Sent: Tuesday, June 05, 2001 6:01 AM
> To: Kenward, Gary [WDLN2:AN10:EXCH]; [email-masked]
> Cc: [email-masked]; [email-masked];
> [email-masked]
> Subject: RE: [seamoby] Security Considerations - new wording
> Sensitivity: Confidential
> 
> 
> Hi Gary,
>

---

From: [email-masked]
Date: Wed, 6 Jun 2001 11:29:17 +0300

Hi Gary,
 
  Good suggestions. I was actually referring to DOS and other 
similar attacks with the euphemism "transfer legitimacy". Not 
being a security guru myself, I wasn't sure if there was an 
acceptable general term, so I created one. 
[<JAL> ] That's what I thought, I just thought additional
text would be good to add.

  I was purposely trying to avoid being too specific in the problem 
statement. I worry that we could end up with a shopping list of 
potential threats. 
[<JAL> ] Hopefully, it should be enough that we list some
possible security threats that CT might cause (or at least
open the possibility for bad guys to do bad things). 

>       successful completion of the context transfer. 

[<JAL> ] Further comment:  The text I proposeed does sound
like a requirement.  If we change the 2nd sentence to:

    Context transfer may create new opportunities for DOS ...

br,

John

---

From: [email-masked]
Date: Fri, 8 Jun 2001 08:47:51 +0300

Hi Madjid,

I think DoS is a bottomless pit and we can never get around to list every
possible DoS and protection against it in such texts.

[<JAL> ] Of course, but if CT can introduce new DOS attacks (or 
novel at least) I believe the Problem Statement needs to mention
what sorts of novel DOS may occur because of CT.
 
John

---

From: Nakhjiri Madjid-MNAKHJI1 <[email-masked]>
Date: Fri, 8 Jun 2001 10:14:25 -0500

Gary,

This is good wording, expect the last sentence (below).
 However, although I think it covers a lot of things,
it does it implicitly (or maybe I read it the way I like to :) ).
I actually can go as far as saying that
your first bullet covers the third one as well, if you want.
However, since we have entered a stage of iterations of
deleting and then adding text back on again. We might as well wait 
and see if this satisfies IESG concerns for security and if it
does not, then we can be less implicit.

As far as the last sentence, I agree with Henrik, I think
it promises more than intended. I would say either change
"must" to "may" or write it in a way that does not mean
we turn seamoby into a security WG :)

Madjid

-----Original Message-----
From: Gary Kenward [mailto:[email-masked]]
Sent: Monday, June 04, 2001 2:22 PM
To: 'seamoby'
Cc: 'seamoby-context'; 'Pat Calhoun'; 'Allison Mankin'
Subject: [seamoby] Security Considerations - new wording
Sensitivity: Confidential

Gary

---

From: "Gary Kenward" <[email-masked]>
Date: Fri, 8 Jun 2001 13:00:13 -0400

John:

  I understand your concern, and certainly this is echoed by Allison,
but I hope that we don't have to perform the threat analysis for the 
problem statement. We don't have the protocols yet, how can we?

Gary

> Sent: Friday, June 08, 2001 1:48 AM
> To: [email-masked]; [email-masked]
> Cc: [email-masked]
> Subject: [seamoby-context] RE: [seamoby] Security Considerations - new
> wording

---

From: "Gary Kenward" <[email-masked]>
Date: Fri, 8 Jun 2001 12:58:27 -0400

Sounds good Pat, I ask is the text that I posted sufficient, and
if not, what change would you propose?

Gary

> From: Pat Calhoun [mailto:[email-masked]]
> Sent: Thursday, June 07, 2001 4:51 PM
> To: Nakhjiri Madjid-MNAKHJI1
> Cc: Kenward, Gary [WDLN2:AN10:EXCH]; [email-masked]';
> [email-masked]; [email-masked]
> Subject: Re: [seamoby-context] RE: [seamoby] Security Considerations -
> new wording
> 
> 
> On Thu, Jun 07, 2001 at 03:35:40PM -0500, Nakhjiri 
> Madjid-MNAKHJI1 wrote:
> > John,
> >  
> > I agree with Gary, considering that this is only problem 
> statement, his
> > mention of corrupted context transfer covers this.
> > In requirement draft we have a requirement on mutual 
> authentication between
> > CT peers and that should cover this.
> >  
> btw, all the IESG cares about is that we don't introduce new 
> DoS possibilities,
> so perhaps text along these lines would be sufficient?
> 
> PatC
> >  
> > Regards,
> > Madjid
> > 
> > Sent: Tuesday, June 05, 2001 10:50 AM
> > To: [email-masked]'; [email-masked]
> > Subject: [seamoby-context] RE: [seamoby] Security 
> Considerations - new wording
> > > From: [email-masked] [ 
> mailto:[email-masked] <mailto:[email-masked]> ]

---

From: "Gary Kenward" <[email-masked]>
Date: Fri, 8 Jun 2001 14:35:30 -0400

Thanks Madjid. 

Your comment on bullet three is interesting. I was trying hard in all of
this
to imply that we would undertaken security solutions only if we absolutely
have
to. Obviously, bullet three needs to be fixed to make this more clear. I
will work 
on it.

Gary

> From: Nakhjiri Madjid-MNAKHJI1 [mailto:[email-masked]]
> Sent: Friday, June 08, 2001 11:14 AM
> To: Kenward, Gary [WDLN2:AN10:EXCH]; 'seamoby'

---

From: Nakhjiri Madjid-MNAKHJI1 <[email-masked]>
Date: Fri, 8 Jun 2001 15:29:46 -0500

Pat, John,

comments on DoS below:

From Pat> btw, all the IESG cares about is that we don't introduce new DoS
possibilities,
so perhaps text along these lines would be sufficient?

MN>> I think we originally talked about mutual authentication between CT
peers,
and then in the interest of timeliness for security, we assumed
pre-established
security association between CT peers. This seemed to be viable when CT
peers are
ARs. Now there are a couple of issues here:

1- If we really want to have all DoS scenarios covered, we need to see
whether we want to allow any other network elements besides ARs to do CT.
and see whether other non-AR-AR CT scenarios exist, say in case we assume
a fall back case where MN negotiates its own context with newAR exists,
too many optimizations might lead to DoS, but are we considering such 
cases?

2-If we now say that only ARs can do CT, assuming pre-established SAs
eliminates most of CT-DoS scenarios and the rest are not just specific to 
CT. Assume the following:
	(This is inspired by Melinda's farm example on close the door
	behind you;) 
	If all of sudden one AR goes nuts and starts sending a lot of
	junk to another AR (or to many ARs) and pretending it is doing
	CT, then you have a problem. 
However, this is more of "do an authorization for each CT session
and then cease the authorization afterward"  problem.
Not only this introduces timing issues, but also I don't 
see how this problem is specific to CT and not
the same for Mobile IP or any other protocol. 

If it is really necessary, we can expand on Gary's second bullet 
(transfer legitimacy) to be more explicit about DoS protection.

Regards,
Madjid