Re: Bellovin's attack

[Danny.Nessett@eng.sun.com (Dan Nessett)]

Phil,

Your suggested solution to Steve's attack, i.e.,

>  
>  2. SOLUTION: Proper key-separation
>  
>   $M_k$ should NOT be using the same key to to protect the communications 
>   between distinct $(U_i, U_j)$'s.  Instead, for host-pair keying, you have a 
>   SINGLE host-pair SESSION key $a$ between hosts $M_1$ and $M_2$; but then 
>   the OPERATIONAL key used for communication from $U_i$ to $U_j$ should be 
>   a KEY VARIANT $h(U_1,U_2)$ -- not the session key $a$.
>  
>   Actually, to ensure proper mechanism independence, the operational 
>   key for transform $T$ used for communication from $U_1$ to $U_2$ should be 
>   key variant $h(T,U_1,U_2)$.  Here, $T$ is a registered identifier associated to
>   the transform (and also including parameter values for the transform); and
>   $h$ is something like a cryptographic hash function (e.g., MD5).  The key 
>   distribution mechanism should not worry about its users, and the transforms should 
>   not worry about theirs.  This simplify is accomplished with key separation.

does not work in certain operational configurations. For example, if an
application, such as NFS, effectively multiplexes user traffic to file systems
over a single "session", separate session keys per user isn't possible.
Another example of this occurs when an encrypting security gateway is used to
front-end private LANs so that their inter-LAN traffic may be encrypted as it
travels over the internet.

The fix that Steve suggests, i.e., require that encrypted data is always
integrity checked, prevents his attack and also solves the operational
problems described above.

Regards,

Dan

---

• Prev by Date: Bellovin's attack
• Next by Date: IPSEC Comments
• Prev by thread: Bellovin's attack
• Next by thread: Re: Bellovin's attack
• Index(es):
  • Main
  • Thread