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

From: "James kempf" <[email-masked]>
Date: Thu, 25 Oct 2001 16:59:26 -0700

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.

                    jak

---

From: Simon Josefsson <[email-masked]>
Date: Mon, 29 Oct 2001 11:43:45 +0100

> 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.

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.

-- 
Simon Josefsson
RSA Security

---

From: "James kempf" <[email-masked]>
Date: Mon, 29 Oct 2001 08:53:40 -0800

Simon,

> 802.11 terminology) are secured via IPSEC or similar, I believe the

Actually, it would be access routers, not access points. Context transfer
is really only necessary when the mobile node moves between subnets.
Any intrasubnet movement should be handled by the L2 protocol, which
is IAPP in 802.11.

> multiple-point-of-failures, the security is reduced 1:N.

Good point. However, I think the issue is somewhat mitigated by the
fact that if an access router is compromised, then the attacker can
also inject false routes into the network, and thus start stealing traffic
in a major way. This threat is there regardless of whether context
transfer is implemented or not. So, to the extent that context transfer
security can leverage off the necessary routing security,
the practical implications of the threat are perhaps less serious
than they seem on the surface.

>       and software protection as the backend server.

I will add this text, modulo something about using routing security to
mitigate the threat, unless there are any objections.

            jak