[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
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
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Follow-Ups: