Re: Blocks of SPIs

[David_A Wagner <daw@CS.Berkeley.EDU>]

> One of Ran's suggestions that came up in discussion was allocating
> entire blocks of SPIs (and therefore keys) with the same attributes.
   [...]
> Also, these SPIs could be used when a large number of sessions are
> needed between 2 hosts, to obscure traffic analysis.  The policy
> management could choose randomly from the SPI list, obscuring both types
> of traffic and number of users.

That's a really bad idea unless all the users trust each other.
Let Alice be a honest user, and Eve a malicious user on the same host.

If the session uses just encryption but not authentication, then
Eve can simply replay messages (changing the dest. port) to read 
destined for Alice.

Also smb's cut-and-paste attack might work. (?)

Alternatively, Eve can wait till Alice relinquishes her port,
bind to it herself, and replay the earlier messages.

Finally, the receiving host has no way to authenticate incoming
messages -- the dest. host can't determine which user sent it!
(Port numbers don't tell the receiver anything: see above.)

Mutually suspicious users require distinct keys for each session.

In general, I believe a design principle is suggested here:
treat incoming messages as coming from a key (or a SPI), not
from a host or a user@host!

---

• Prev by Date: Blocks of SPIs
• Next by Date: replay attacks
• Prev by thread: Blocks of SPIs
• Next by thread: replay attacks
• Index(es):
  • Main
  • Thread