Anne & Lynn Wheeler wrote: > For pure authentication operations ... this model eliminates the whole > digtital certificate paradigm ... since the model assumes that the > originator of the authentication request already has the recipient's > public key recorded someplace. > http://www.garlic.com/~lynn/subpubkey.html#certless
so the simplified SSL using the domain name on-file public key ... still has possible replay attack potential against the server (the attacker doesn't necessarily know what the replay is doing ... but getting the server do it multiple times might result in something bad). so in another kind of authenticated connection scenario ... say Kerberos or RADIUS ... the client has registered their public key in lieu of some sort of password (for certificateless operation) http://www.garlic.com/~lynn/subpubkey.html#radius http://www.galric.com/~lynn/subpubkey.html#kerberos they contact the server asserting some userid. the server generates a random key, encrypts a time-stamp plus asserted userid plus more random data, encrypts the random key with the public key on file for that userid and responds. the user decrypts the random key with their private key, and decrypts the response. at this point their is a choice of possibly having encrypted sessions (with possibly perceived overhead issues) ... or having the client permute the unencrypted data in some way, re-encrypt just the permuted data and return it with unencrypted data. the re-encrypted data demonstrates "something you have" authentication (i.e. the client has possession and use of the appropriate private key). there are MITM vulnerabilities for the client ... since the server hasn't been authentication. to eliminate the MITM attacks against the client and replay attacks against the server ... they would have to authenticate each other .... w/o resorting to digital signatures (and opening themselves up to dual-use attack) ... each sending some random data encrypted with the other's public key .. which then can be decrypted with the appropriate private key. --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
