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

Re: Photuris // entities

> From: Bill Sommerfeld <sommerfeld@apollo.hp.com>
>    In the MLS target scenario, the Responder isn't a "user", it is a
>    "secure system".   I don't know any incoming processes that are
>    identified with "users".  I don't think of FTP as a "user", even though
>    it might run in user space, as it isn't individually controlled by a
>    human being.
>
> I think this is an unfortunately limited view of the possibilities.
> Kerberos allows you to have multiple distinct "server principals" on a
> server, each with a separate cryptographic identity.
>
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.


> Sophisticated applications can and do pick which one they want to talk
> to.
>
Correct.  As they can in Photuris.  But that picking is not part of
Photuris, it is part of the "security architecture".  Even without
Photuris, something somewhere has to choose among multiple SPIs for a
given Destination, so that the correct one is used for the TCP/UDP Port
pair connection that is running.


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


>  2) If a TCP connection is idle, no packets need to flow.
>     If the active security association expires, *either* end might
> need or want to recreate it.
>
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.

A receiver which requires authentication will send an ICMP message when
it receives an unauthenticated datagram, and the sender will initiate a
Photuris exchange to authenticate itself.  Again, no problem.

I think this pretty well covers it all!

Bill.Simpson@um.cc.umich.edu
          Key fingerprint =  2E 07 23 03 C5 62 70 D3  59 B1 4F 5E 1D C2 C1 A2
Follow-Ups: