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

Re: PGPticket

On 5/27/98, Men from Black Helicopters forced Tony Bartoletti to write:

> A minor nit.  See Protocol description, paragraph 5, below.
>> >>
> >>   Server to Client
> >>   5.  The server checks validity of ticket, which entails
> >>   verifying the admin signature and expiration date of ticket.
> >>   The server then generates a random challenge string and
> >>   sends the challenge to the client requesting that it be
> >>   signed by the key specified in the ticket.
> The recent and timely thread "Key Usage for Authentication and
> Digital Signature", although X.509-oriented, discusses a possible
> security problem when a server is able to form a "challenge" to be
> signed by the auth-requesting client.  Specifically, a nefarious
> server may trick the client into signing a substantial "message"
> rather than (say) a random challenge.  Perhaps the protocol could
> force the challenge to incorporate data supplied, at least in part,
> by the client as well.
> ___tony___

good point , but read the next paragraph..

> >>   Client to server
> >>   6. The client signs and returns the challenge string with a
> >>   random nonce appended. The server then checks the clients
> >>   signature and if successful grants access with the
> >>   authorizations specified in the ticket

A client should never sign a challenge on it's own. the challenge should 
have a client random nonce  appended to it, then sign that. the nonce
can in fact be used as a counter challenge for the server to sign (whereby
it also attaches a random nonce)

to be specific:

the Server generates a random string of bytes that are at least as long as the 
challenged key's hash size,  this is sent to the client along with the key fingerprint.

S: KeyFP:Challenge

The client looks up it's key database to see if it has a key that matches that fp.
It takes a hash of the challenge string, it thens generates another random string
 of (hash size) and continues to hash  that.. it then calculates  a signature for 
 the hash and the given key...  the clients random string and the sig is sent to the 
C: Counterchallenge:Sig

 the server takes a hash of it's original challenge, continues with the 
 nonce string and calculates a sig also. the two sigs are then compared..
 if they are valid, the server then creates another random string and
 hashes that plus the clients nonce and signs that. this is sent to the 
 S: serverNonce:serverSig
 the client can then perform a check for server validity...
 this is why I want to write this as a real spec..

Vinnie Moscaritolo
Wordwide Developer Technical Support

Apple Computer, Inc.                      email:  vinnie@apple.com
3 Infinite Loop, MS: 303-2T               phone:      408.974.5560
Cupertino, CA 95014                       fax:        408.862.7602
Fingerprint:     0AAF 9A74 113F 7FDD 97E6 04BD 1D7A 2D86 6F17 2A0A