Anne & Lynn Wheeler
Sun, 10 Feb 2008 08:25:47 -0800
re: http://www.garlic.com/~lynn/aadsm28.htm#30 Fixing SSL so lots of the AADS http://www.garlic.com/~lynn/x959.html#aads scenarios are that every place a password might appear, have a public key instead. for various of the cookie authentication operations ... also think kerberos tickets. recent reference http://www.garlic.com/~lynn/2008c.html#31 Kerberized authorization service part of the scenario for cookie/ticket encryption ... involving servers, is brute force attack on the server secret key. the cookie instead of all encrypted data ... has some sort of client registration value ... analogous to an account number or userid. the cookie caries the registration value followed by the server encrypted data. the encryption part uses a derived key ... formed by combination of the server's secret key and the client's registration value. these derived key scenarios are also found in transit system operation (both magstripe and memory chip) as well as financial transactions. the issue then is initial registration ... the part where the user chooses their userid (and/or the client registration value is otherwise selected) and supplies a password (but in this case a public key). m'soft and others have been using CAPTCHA to weed-out the non-humans, but this has come under attacks. reference to recent news itemshttp://www.garlic.com/~lynn/2008d.html#2 Spammer' bot cracks Microsoft's CAPTCHA
the ticket/cookie carries the clients public key (and whatever other characteristics) ... which then can be used by the server(s) to perform dynamic authentication (digital signing of some server supplied, random data, countermeasure to replay attacks). this is in lieu of server having to maintain the client account record ... ala a RADIUS scenario where public key has been registered in lieu of a password (some sort of online access to RADIUS account records). various RADIUS public key in lieu of password postings: http://www.garlic.com/~lynn/subpubkey.html#radius the ticket/cookie scenario (with derived key encryption) is cross between dynamic server-side account record data (say RADIUS repository) and stale, static digital certificate scenario. as in the transit gate operation, the ticket/cookie could also be retrieved, decrypted, updated, re-encrypted, and returned as part of the operation. initial server hand-shakes can include server sending some random challenge data. The client returns the digital signature and their previously obtained cookie. in the straight RADIUS public key handshake scenario, just the digital signature and client userid/account-number is returned since the rest of the cookie/ticket equivalent info is online in the RADIUS account repository. The straight RADIUS scenario would be to combine the server-side random challenge data and combine it with the client registration value (account number, userid) and whatever else the client-side digital signing requires ... and return the userid/account-number any other data and digital signature (i.e. server-side has to be able to reconstruct what the client actually digitally signed as part of verifying the digital signature). In the straight RADIUS scenario, the public key (and any associated permissions, authorization, etc) is obtained from the RADIUS repository. In cookie/ticket scenario, it is obtained from the cookie/ticket appended to the message. The business process still has the initial registration phase ... where the original cookie is created (or in the RADIUS scenario, where the userid definitiion is initially created) and the public key is supplied (in lieu of a password). This is also effectively the original certificateless pk-init scenario for kerberos (aka public key in lieu of password) http://www.garlic.com/~lynn/subpubkey.html#kerberos The cookie scenario is standard client/server ... attempting to eliminate the server having to retain the account record on behalf of every client (as in either the RADIUS and/or KERBEROS scenario). Encrypting of the cookie data is standard ... although transit systems and financial transactions have gone to derived key for the situation ... as countermeasure to brute force attack on the infrastructure secret key. --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]