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

Re: PGPticket

At 03:25 PM 5/27/98 -0800, Vinnie Moscaritolo wrote:
>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)

Vinnie,  You are absolutely right.  I was led astray by the wording of 6:

  "The client signs and returns the challenge string with a
  random nonce appended."

At a glance, one could interpret this to mean "signs the challenge string"
and _then_ appends a random nonce.  This would service the needs of a
counter challenge as well, but was not what you meant.  Perhaps the words

  "The client appends a random nonce to the challenge string, and then
   signs the string and returns it to the server."

would have made it more clear.


>the Server generates a random string of bytes that are at least as long as
>challenged key's hash size,  this is sent to the client along with the key
>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
> 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 
> server.
>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 
> cleint
> 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

Tony Bartoletti                                             LL
SPI-NET GURU                                             LL LL
Computer Security Technology Center                   LL LL LL
Lawrence Livermore National Lab                       LL LL LL
PO Box 808, L - 303                                   LL LL LLLLLLLL
Livermore, CA 94551-9900                              LL LLLLLLLL
email: azb@llnl.gov   phone: 510-422-3881             LLLLLLLL

Follow-Ups: References: