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

Re: Nodes and Users

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

At 11:15 10/22/95, William Allen Simpson wrote:
>> From: smb@research.att.com
>>        Bill has expressed to me in private mail that he thinks that the
>>        question of certificates, certificate formats and naming can wait, but
>>        frankly I don't think it can because we don't have a usable system
>>        without it.
>>
>> I agree very strongly with Perry about this.  I tried raising the
>> issue a few months ago; it met with a resounding silence.  We need
>> to settle this immediately, if not sooner.  It is, as far as I'm
>> concerned, an absolute show-stopper -- without some resolution, I
>> would vote against -- well, not precisely vote in the IETF, but you
>> know what I mean -- Photuris, on those grounds alone.
>>
>I have responded to this thread several times.  (The title is mine)
>
>Very good, then I am sure that the Chairs will count this as opposing
>Photuris submission as a Proposed Standard.  If there is insufficient
>support, I will submit it as Experimental instead.  Thank you.

Oh come on! We were able to move forward with ESP and AH without having
a firm automated key management infrastructure installed. We can move
forward with Photuris just as well.

If we wait until we have a fully fleshed out architecture with complete
consensus of the whole IETF before move forward, we will never get
anywhere (this has been the yoke of the Security Area for years).

I believe that all Photuris needs to specify is the format of the public
keys it expects to have available. These keys can always be manually
configured if necessary. Personally I favor an approach based on using
PGP keys, but that is my personal preference based on the wide
deployment of PGP in the community (ok, so I am probably biased a little
as well...).  However the point is that Photuris doesn't have to specify
exactly where these keys come from.

Now I'll admit here that I am not completely up to date on the latest
Photuris drafts (though I certainly will be by Dallas!), however the
requirement of user to user keying probably implies that when an initiator
wishes to establish an association with some party at a destination, there
needs to be a way to communicate this information to the destination host.

The following "mappings" have to happen:

Entity "A" wishes to communicate with entity "B".

1) A has to map "B" into "B@somehost.somedomain" (ie. this is the service
location problem).

2) A's host has to initiate an association with somehost.somedomain and
   specify that the permanent key to use is associated with "B".

3) A's host uses A's keying material and somehost.somedomain uses B's
   keying material and the Photuris protocol can commence, generating
   SPID's and session keys and attributes as appropriate.

4) A at "host" communicates with "B" at somehost.somedomain in an
   authenticated and/or confidential fashion.

Problem [1] is the service location problem and is well beyond the scope of
Photuris.

Problem [4] is what is addressed by AH and ESP.

Problem [2,3] is what Photuris should do. However Photuris doesn't have to
specify where the keys for A and B come from. Ultimately we have to solve
this problem, but Photuris isn't the place to solve it.

The contenders (from my point of view) are:

o Secure DNS [This is moving along]
o PGP        [Available today but not "standardized" (though that is being
              worked on). Appropriateness of Web of Trust is debatable]
o X.509/X.500 [Some will argue that this is *the* way to do all of this.
               Problem is that it doesn't mix well with DNS names and has
               had years to come into existence, but hasn't]

Finally there is the whole issue of the availability of the various public
key crypto systems. As I am sure you are all aware, this whole situation is
in a state of flux here in the U.S. and I hope it will stabilize shortly.

                                -Jeff

-----BEGIN PGP SIGNATURE-----
Version: 2.6.2

iQCVAwUBMIqXA8UtR20Nv5BtAQHF8QP/dLsT8UtMxfoFOLYYFAGRY7qyh6ybAKXh
4UPfht4XRN9rOxlgRstgpU1d78s9vO4tQhWk7X0ktcgKNnymMpE2uyI52W1uuo2X
PggIi94bLK95RKGGXuStipNp8jswUQmYbtMII04gcm4wEJ+DttPj1c9N6kvOE1Q4
5aDjcdytjb8=
=kZ9K
-----END PGP SIGNATURE-----