[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.
Thanks.
____tony____
>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
> 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
>N&C/Hardware
>
>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: