[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Photuris // entities



-----BEGIN PGP SIGNED MESSAGE-----

content-type: text/plain; charset=us-ascii

   So does Photuris.  There is no restriction of the number of Photuris
   exchanges that can be active at the same time.  Indeed [p 5]:
   
      When both parties initiate Photuris exchanges concurrently, or one
      party initiates more than one Photuris exchange, the Initiator
      Cookies (and UDP Ports) keep the exchanges separate.  This results in
      more than one initial SPI for each Destination.

But there is still no way for the Initiator to choose which principal
on the Responder it wishes to communicate with.

   >    So, the only possible "unauthorized" party would be the Initiator.
   >
   > I don't think that's a reasonable assumption.
   >
   >  1) Consider user-oriented network services like X and Zephyr, where
   > the "server"/"responder" is close to the user, and the "client"/"initiator
     "
   > is off on a server machine.  It's not common, but one can have multiple
   > heads, and multiple X servers, on a single multi-user machine.
   >
   So?  What stops them from each starting a Photuris exchange?

That's not the issue, the issue is how an *initiator* can select which
of several possible server identities it intends to send encrypted
data to.  You don't want to send something down an encrypted link
unless you know who on the other end has the key!
      
   Certainly.
   
   But as is carefully defined, the encryption policy is in the sender
   direction, and the authentication policy is in the receiver direction.

   A sender which desires to send encrypted data will initiate a Photuris
   exchange.  No problem there, unless it doesn't trust the kernel of the
   other node to deliver the encrypted data only to the intended "user", as
   indicated by the TCP/UDP port protected in the data.  But in that case,
   you'd be insecure no matter what you did.

Ok, so if I'm reading you correctly, you're implying that all
encryption SPI's are set up in a "user->system" mode.  There's a
fundamental weakness in this, at least for UDP.  [The vulnerability
probably also exists for TCP, but may be harder to exploit.]

Again, if I'm reading you correctly, if user A at host X wishes to
have a two-way encrypted channel with user B at host Y, then you're
suggesting that there will be two photuris exchanges (ouch -- that's 8
DH modular exponentiations before anyone gets to talk..), and the
SPI's actually used will be

	A->Y
	B->X

Now, if there's a second malicious user C at host Y, what's to stop C
from noticing when B releases his UDP port, grabbing the port,
replaying A's traffic, and thus receiving the encrypted data?  

Or do we have to mandate that transports not reuse ports within the
longest SPI lifetime they allow?

If, on the other hand, the SPI's were set up:

	A->B
	B->A

then, on receipt of the A->B packet, Y would notice that B no longer
owned the destination port, and drop the packet.  Also, the cost of
the setup is cut in half -- only 4 modular exp's instead of 8..

				- Bill




-----BEGIN PGP SIGNATURE-----
Version: 2.6.1

iQCVAwUBMIgda1pj/0M1dMJ/AQFQIwP9E62IHzjTDXP8Vk5+etkeO05yE1yDwJuV
SazjdPzYWaKSfen727O351zwiGyIX9WxtAGgHoQF3Pt+M3242CXk0d8gueRwzkfj
9re7pcx/561+WGdhEgLwYxeLLKvW21YGMnLY1nBrksuxLOII05l++U2alosAd4oB
R0FNvkLVhoI=
=1Q/u
-----END PGP SIGNATURE-----


Follow-Ups: References: