Subject: RE: [seamoby] Re: Last Call on draft-ietf-seamoby-context-transf er-problem-stat-03.txt

From: Nakhjiri Madjid-MNAKHJI1 <[email-masked]>
Date: Fri, 9 Nov 2001 12:01:34 -0600

Hi Simon,

Sorry for the delay in reply. I think Charlie brought some good
points, which are basically my questions as well.

Furthermore, even assuming that you have a centralized server
in your system for storage and transfer of keys, using this
server for transfer of security related material creates an
architecture problem, and that is:

What about the other features, such as QoS, header compression...
would you have them transferred from this centralized server or
would you have security transferred from the server, while the 
rest is transferred from the edge routers. Going down this path
means forgetting about why started to talk about context transfer
protocol in the first place: which was we wanted a generic protocol
and a generic procedure for all features, otherwise we might as well
let each feature and protocol take care of its own state and that work
would be done in the respective WG. This has been brought up before,
but obviously not the path that we have chosen for context transfer,
unless people feel differently now.

So I guess what we can do is try to address your concerns about
a lowered security "grade" at the AR and see what we need to do 
about it. 

Regards,
Madjid

-----Original Message-----
From: Charles E. Perkins [mailto:[email-masked]]
Sent: Friday, November 02, 2001 12:23 PM
To: Simon Josefsson
Cc: [email-masked]
Subject: Re: [seamoby] Re: Last Call on
draft-ietf-seamoby-context-transfer-problem-stat-03.txt

Hello Simon,

Suppose we can make the following assumptions:

1. There is a security association between two edge routers.
2. The key between the mobile node and the first
   edge router has been distributed securely.

Now suppose the mobile node moves to a new edge router.

You (Simon Josefsson) wrote:
>            ..............                _when_ you use CT of
> keying material, you should be aware that the system security might
> not be as good as when you use a centralized context server.

What would cause the security to be downgraded?

>                                                               This is
> not surprising, but I felt it should be pointed out because there may
> be situations where CT of keying material probably can't be used
> because of this problem -- when the ARs aren't physically protected
> for instance.

Does this mean that somehow the physical AR has been compromised
and its security associations revealed?  Then
1. Maybe the central server would no longer authenticate security
   messages for the mobile node?  But then, why would the previous
   AR?  Presumably, the central server would have notified its
   still-trustworthy associates about the breach in security
2. Maybe the new edge router would try to supply a key in place
   of the one derived from the previous key?  But this can be
   detected by the mobile node, I reckon, given proper encoding of
   the "real" new key...

I don't deny that there may be threats, but I don't see exactly
what they are.  Maybe we can protect against them, and make edge
security transfers as good as centralized transfers?  For that
reason, it would be good to have as complete a view of the potential
problem areas as possible.

>             I agree it is a context storage issue, and has nothing to
> do with the CT protocol actually used -- but the security of CT is not
> only about the actual protocol used.

Could you describe what you had in mind here?

Thanks!

Regards,
Charlie P.