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

From: Simon Josefsson <[email-masked]>
Date: Fri, 02 Nov 2001 09:05:52 +0100

I believe both centralized context servers and context transfers will
be used (context transfer improves speed and reduce client complexity,
while a centralized context servers may improve administrative control
and perhaps offer increased security). Hence, my comment was not
"against" context transfers at all -- only that _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.  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.  (I assume the centralized context server is physically
protected.)  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.

Except this minor comment, I think the document looks good.

/Simon

Nakhjiri Madjid-MNAKHJI1 <[email-masked]> writes:

> 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

---

From: "Charles E. Perkins" <[email-masked]>
Date: Fri, 02 Nov 2001 10:23:18 -0800

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
> not be as good as when you use a centralized context server.

What would cause the security to be downgraded?

>                                                               This is
> 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

Could you describe what you had in mind here?

Thanks!

Regards,
Charlie P.