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

Re: Photuris // entities



> From: rivest@theory.lcs.mit.edu (Ron Rivest)
> I'm still confused about how the entities communicated are to be identified.
> Here is a specific concern, using the terminology of version 5 of the
> Photuris draft:
>
> 	When the Initiator initiates a connection, all he specifies
> 	regarding the identity of the desired responder is the IP
> 	address of the node he sends his Cookie_Request to.
>
> 	However, later on, he may receive an Identification_Message
> 	from the (purported) responder that has an Identification field
> 	that is, in the current draft, unconstrained.
>
> 	*** When is the Responder's Identification field (un)acceptable? ***
>
Current text reads:

    Early implementations may wish to keep their own trusted key
    databases, such as the Pretty Good Privacy web of trust, and accept
    only those users whose identification is found there.

So, if either the Initiator or Responder isn't found in the database,
that's a failure, and the Verification Failed Error_Message is sent.

Eventually, with X.509 or DNS-SIG, if they aren't found in the external
database, they would likewise fail.


> 	For example, is an Identification from a specific user
> 	at the responder's site unacceptable?  (I should think so, since
> 	the Initiator didn't -- and couldn't -- have requested communication
> 	with that specific user in his initial Cookie_Request or
> 	Exchange_Request.)
>
First of all, in most cases, this will be router (firewall) to router,
or host to router, or single-user host to single-user host.

In those cases, as to either Initiator or Responder, I would say that
_any_ valid identity which correctly signs/MACs/whatever is good enough.

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.

So, the only possible "unauthorized" party would be the Initiator.
Photuris merely handles the identity exchange, and successfully
completes.  Assuming the secure system has any degree of Access Control,
it "knows" which Initiators are valid.  The access control would be
handled by higher layers -- for example, not allow Telnet but allow
anonymous FTP.

Current text reads:

    Each party implements local policy that determines what access, if
    any, is granted to the holder of a particular identity.

And of course, in the Attributes section itself:

    Authentication policy is in the SPI Owner (receiver) direction.


> 	I think that the protocol definition should define
> 	all possible error conditions, and specify what the appropriate
> 	actions are for the detector of the error.
>
I think that it does.  It just has fewer error conditions than you seem
to want, because it does _not_ handle Access Control.

The appropriate action is already listed:

    If identity verification fails, the users are notified, an
    Error_Message is sent, and the Security Association is destroyed.


> 	It is "buggy" if it the Initiator is supposed to accept ANY
> 	correct Identification and Verification information from the
> 	Responder.  At the minimum, one would hope that there be a
> 	constraint that the identification specify either the node with
> 	the original IP address requested or a user at that node.
>
I think that will be very implementation dependent, and outside the
scope of the specification.

But we could list some more of the possibilities in the Appendix:

 - It could be a user@node.site, of course.
 - It could be the hostmaster@site, or hostmaster@node.site.

In the Extensions draft:

 - It could be a DNS-SIG for the node or the site.
 - It could be a configured PGP key (already mentioned).
 - It could be many forms of X.509, and I'll leave the X.509 advocates
   to submit language.


> 	It "contains a gap in its specification" if there is more than
> 	one Identification that is permissible for the Responder to send,
> 	but the Initiator may reasonably prefer one instead of the others.
> 	The gap is that the Initiator should be allowed to specify in his
> 	original request (the Exchange_Request, I suppose, or else the
> 	Cookie_Request) the identity or identities of the parties with
> 	whom he wishes to set up a Security Association.
>
I am totally against this.  The list could have thousands or tens of
thousands of identities and preferences.  It would be an administrative
and protocol nightmare.  And would assist in defeating privacy.

Any authentic Identification is as good as another for the purposes of
preventing a man-in-middle attack.  Access Control is outside the scope.

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: