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(_at_)apple(_dot_)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
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~