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

From: Nakhjiri Madjid-MNAKHJI1 <[email-masked]>
Date: Wed, 31 Oct 2001 11:31:44 -0600

Hi Simon,

See my comments in line:

-----Original Message-----
From: Simon Josefsson [mailto:[email-masked]]
Sent: Monday, October 29, 2001 4:44 AM
To: [email-masked]
Subject: [seamoby] Re: Last Call on
draft-ietf-seamoby-context-transfer-problem-stat-03.txt

"James kempf" <[email-masked]> writes:

> Folks,
> 
> Working Group Last Call on
draft-ietf-seamoby-context-transfer-problem-stat-03.txt starts tomorrow,
Oct. 26, and runs for two weeks until Nov. 9. Please submit comments
> to the list before Nov. 9.

I am new to this group and have not followed the development of this
draft, and my concerns may be specific to 802.11 Wireless LANs and
when the context includes encryption keying material, but nevertheless
I have a comment on the security considerations:

Even when context transfers between network entities (access points in
802.11 terminology) are secured via IPSEC or similar, I believe the
complete system is less secure than compared with when context
transfer is not used, and instead one backend server handles roaming
which sends the necessary context (including encryption keys) to each
access point.

Madjid>> Centralized context servers, versus context tranfer between ARs
was discussed early on and I don't want to get into pros and cons of it.

Madjid>>Just in this case, you would still have a problem when the MN moves
between
administrative domains using separate policy/authentication... servers.
And this is general AAA, security, key management issues with lots of things
 involved such as AAA brokers, CAs , you name it.

Madjid>>We need to secure the context transfer channel propoerly to not
compromise the information (including the keys) going through.
Unless you are completely against context transfer.

The reasons is that, if one of the access points is compromised, the
context received may be used to sniff the network even after the
mobile node left the compromised network entity.  Compromising a
access point when context transfer is not used does not make this
possible.  So the system security has been reduced from having the
backend server a single-point-of-failure to having
multiple-point-of-failures, the security is reduced 1:N.

If you agree (discussion welcome), I'd suggest that something like the
following text is added to the security considerations:

      The compromise of only one of the network entities that contain
      context may be sufficient to reduce the security of the whole
      system, if for example the context includes encryption keying
      material.  When the host moves from the compromised network
      entity to a uncompromised network entity, the compromised
      context may be used to decrypt the communication channel.  When
      context transfer is not used, a compromise of only one network
      entity only gives access to what that network entity can see.
      This means that network entities must have similar physical
      and software protection as the backend server.

Madjid>>
1- I agree with James, it is access routers not access points.
2- we are dealing with a communications security problem, 
not a storage security problem, are we not?
We need to secure the communication of context, not how securely it stored,
that is the issue of access security.
Secure storage of keying material is not limited to context transfer.

3- context transfer is intended to happen between ARs, how it is gathered
at old AR, and how the old context is dumped at old AR after transfer, was
defined as out of scope. 

Again, I don't quite see this as a problem for context transfer, but rather
a 
context storage problem.

Are you advocating a more secure context transfer, or more secure storage
of keying material used for context transfer?

Hope this is not too far out in the woods,
Madjid

-- 
Simon Josefsson
RSA Security