Re: Question regarding 2440:5.2.3.16

[sen_ml@xxxxxxxxxxx]

sorry for the horribly slow response.

From: "L. Sassaman" <rabbi@xxxxxxxxxxx>
Subject: Re: Question regarding 2440:5.2.3.16
Date: Mon, 10 Jul 2000 10:19:52 -0700 (PDT)
Message-ID: <Pine.LNX.4.21.QNWS_2.0007101007570.9459-100000@xxxxxxxxxxxxxxx>

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> On Mon, 10 Jul 2000 sen_ml@xxxxxxxxxxx wrote:
> 
> > so you are suggesting that proof of ownership of the corresponding
> > secret key (via an appropriate signature) should server this purpose,
> > right?
> 
> Yes, because the owner needs to prove he has the secret key, and the
> public key block that is to be added must be signed to prevent
> unauthorized signatures being added during this process.

sure, i was just making sure i followed your statements.

> > > Werner Koch and I have been discussing this, and he suggests that we put
> > > it into a clear-text signature packet. Would that be suitable? 
> > 
> > would you mind briefly describing the steps involved for the mechanism
> > you are considering (in terms like "first, the client connects to the
> > server.  then the server responds w/..." etc.)?  
> > 
> > [ i understand what you are saying about the form a signature would
> > take, but i don't see the overall flow of the process of
> > authentication. ]
> 
> The client takes the public key block, signs it, and submits this signed
> blob to the server. The server then verifies the signature, trims away
> that signature, and adds the key.

thanks for the explanation.

> Keys that are added unsigned should always be checked for the existance of
> the "no-modify" flag, and rejected if it exists.
>
> Furthermore, I suggest that we have a "modify" flag added to the spec, so
> that, if a signature is made at a later date containing this flag, it
> would superceed a preveous no-modify. But that digresses from this
> discussion. 

that makes sense.

> > also, is it necessary to consider replay attacks for this kind of
> > scenario?  alternatively, would the following scenario be of any concern:
> > 
> >   an attacker captures a session between a user and a keyserver at some
> >   point in time.  later, after the user has made several updates to the
> >   keyserver, the attacker replays the captured session to set the
> >   state of the user's key to an earlier state.
> 
> This scenerio is only partially valid. A signed key that is added to a
> server does not remove the previous key and replace it with the new
> one. It is treated like and other add, and is merged with the existing
> key. So, an attacker could not truly set the key to a previous state.

is there a reason why it is not replacement?  from the standpoint of a
user, i think i prefer replacement as that goes along w/ being able to
delete.

> What an attacker *could* do, via a replay attack, is re-add signatures or
> user-ids to a key on the server that the owner had later deleted. I see
> this as a minor annoyance, rather than an attack, so I don't think that we
> need to address it. (Though we could, through the use of server tokens or
> timestamps, etc. I just think it is more work than is necessary.)

i guess i'd prefer to have the ability to delete things and then not
have other people be able to add things back later.  whether the
annoyance is minor or major is in the eye of the beholder, imo.  i
don't consider it minor.

i would prefer to have a timestamp / server token kind of a set-up.
if some people don't care about this and others do, i suppose it could
also be expressed as policy as part of a user's key.