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(_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
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
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(_at_)llnl(_dot_)gov phone: 510-422-3881 LLLLLLLL