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

Re: Photuris // entities

> From: Bill Sommerfeld <sommerfeld@apollo.hp.com>
> 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!
>
First of all, as I've pointed many times before, this nothing to so with
the most common use of Photuris.  This is _only_ for MLS workstations.

Second, as already stated, it is the responsibility of the sender
(whether that sender was the Initiator or Responder), to select among
the identities with which it _has_ an association.  These implementation
details are certainly outside the scope of Photuris.  We are _not_
specifying APIs here.

Third, by the time the Initiator sends any data, it does in fact _know_
whom it is sending the data.  The signing/verification has been
completed.


>    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.]
>
There is no weakness, unless the receiving system implementation is weak.


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

User A has _NO_ say as to whether a "channel" is encrypted "two-way".
Encryption policy is in the sender direction only.

This is a design principle of Photuris.


> then you're
> suggesting that there will be two photuris exchanges (ouch -- that's 8
> DH modular exponentiations before anyone gets to talk..),

For this extremely rare and ungainly association, it takes two exchanges.

But of course, as is repeated at least twice in the specification, when
multiple exchanges occur and the exchange-values are the same, the
shared-secret is the same.  No additional calculation is needed.


> 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?
>
Your scenario is also applicable to manual keying.

If your implementation is that poorly done, I don't consider that a
"secure" workstation.  As our IP Security Architecture clearly states:

   Users need to understand that the quality of the security provided by
   the mechanisms provided by these two IP security mechanisms depends
   completely on ... the correct implementation of IP and the
   several security mechanisms in all of the participating systems.  The
   security of the implementation is in part related to the security of
   the operating system which embodies the security implementations.


> Or do we have to mandate that transports not reuse ports within the
> longest SPI lifetime they allow?
>
Whatever it takes for your implementation to not have a failure mode.

This is outside the scope of Photuris.  IP Security is _not_ a transport
layer security mechanism.  There are no "ports".

If you think this is terribly important, even as an implementation note,
then you need to get it included in the next revision of the IP Security
Architecture.

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: