[anonsec] 3401 and highjacking
kent at bbn.com
Wed Feb 15 13:27:42 PST 2006
At 11:56 PM -0600 2/13/06, Nicolas Williams wrote:
>On Mon, Feb 13, 2006 at 04:29:33PM -0500, Stephen Kent wrote:
>> I'm getting too old to remember message exchanges 2 months ago :-).
>> Nonetheless, using your airport lounge example, if Karen gets my old
>> address, and if she successfully creates a new IKE SA, then she can
>> have that addresses in parallel with me, in some circumstances. the
>> addresses we're discussing here are unprotected ones, not the
>> protected ones inside tunnel headers that are used by RWs to access
>> SGs back at enterprise HQ. Thus they never are used for access
>> control purposes, relative to the SPD or SAD. So, in the tunnel mode
>> case, I think we're OK, even from the DoS concerns you raised. But,
>> in transport mode (not applicable to the RW scenario), I agree that
>> there could be DoS problems. Also, if Karen asserts the same inner
>> address as me, and it is within an address range that is approved for
>> BTNS use, then we do have a problem.
>Yes, the assumption is that Karen could get the same inner address as
>you had. Often it's easier to not do static address assignments to
sorry, I forgot the context from last year, and it was not explicitly
re-stated in Mike's message.
>> This seems to be a good reason to be very careful in claiming what
>> modes and in what contexts BTNS will work, as you suggest.
>But you missed the point -- this is a problem with use of wildcards in
>PAD entries, not with BTNS; BTNS merely makes the scope wider (from,
>e.g., all principals in a given PKI to practically *anyone*; given a
>sufficiently large PKI the distinction isn't all that large).
If a sys admin creates a PAD entry with wildcard values for source
addresses, and matches it with an SPD entry that is address (vs.
name) based, then the sys admin is asserting that the entities who
are associated with the PAD entry are all viewed as equivalent for
security purposes. If the PAD and SPD entries are name-based, then
access control should work as expected, but there might still be a
conflict over the inner addresses.
An obvious question is how such addresses are assigned. If they are
static, and the RWs don't modify them, then all should be OK. If they
are DHCP assigned, as is typical for an RW-SG context, again, there
should be non collisions. All of this seems reasonable for non-BTNS
BTNS makes life complex, because the PAD entries are not being used
for IPsec-level authenticated communication, yet there can be
IPsec-level address conflicts. To me this seems to be an indication
of a problem we are creating for ourselves, by applying security
measures at layer 3 (which use layer 3 IDs, i.e., IP addresses),
while relying on layer 7 to manage authentication.
More information about the ANONSEC