dunno if this made it through the pipe before the last outage, but i've never been one to miss a chance to bore people senseless with technical babble. ;-) those not desperately interested in security protocols can probably skip this one.. it's a boat-anchor and very dry: okay.. the SKID2 procotol is a one-way identification proctocol, which runs as follows: 1) A generates a random string, Ra, and passes it to B. 2) B generates a random string, Rb, and calculates Hk(RaRbB), where Hk() is a special type of hashing function which i'll explain in a minute. 3) B sends A the sequence: RbHk(RaRbB) 4) A uses the value Rb from the message to calculate its own version of Hk(RaRbB). 5) if A's version of Hk(RaRbB) matches the one it received from B, the authentication is successful. basically, A and B encode B's name independently, then compare their results. the random number Ra is the basis of authentication, and the random number Rb provides an additional layer of security on the transmission. Hk() is what's known as a "message authentication code" or MAC. basically, a MAC is just a one-way hashing function (checksum, MD5, PGP signature, whatever) combined with a secret key. both A and B are assumed to share the same hashing algorithm and the same secret key. the reason for having a hashing function in the first place is that it lets you compare data without having to share it explicitly. if A and B want to know if they have the same data, they each calculate a hash value for that data, then compare those hash values instead of the data itself. if the hash values match, the original data must have been the same, too. if the hashes don't match, both sides know that the other guy has something different, but neither has been forced to compromise its own data to find that out. the principle of hash authentication works just as well without a secret key, but it's less restrictive. anyone who knows your hashing algorithm can compare data with yours, which leaves an opening for third-party dictionary attacks. by adding a secret key, the MAC ensures that only systems which know both the hashing algorithm *and* the key can make meaningful comparisons of data. authentication protocols can also be used, with a few modifications, as signature protocols, and that's basically what the solution is.. a signature protocol which performs a trusted introduction between systems. the login server which the user first contacts will be referred to as machine A. the secondary server, which server A shields, will be referred to as machine B. the user's computer will be referred to as machine C. the sequence begins with machine C initiating contact with machine A and passing whatever authentication scheme is required for login. at that point, machine A is assumed to trust machine C. machine A contacts machine B, and requests two pieces of information: a random string Rb, and a session identification key S. the session key is necessary because servers A and B will need to handle introductions for multiple different machines: C1, C2, C3, etc. upon contact from machine A, machine B generates Rb and S as requested, and passes both back to machine A. machine B also stores its own copy of Rb for future use, using S as the key. it's probably a good idea to place timeframe restrictions on the protocol as a whole, to prevent users from caching a validated connection and using it again later. for that reason, it would be useful to embed a timestamp in the session key. on receipt of Rb and S, machine A generates its own random string, Ra. machine A then combines Ra, Rb, the IP address of machine C, and the MAC key K. that string is hashed, and the result is Hk(RaRbC). machine A then combines the hash string with its own random string and the session key to produce SRaHk(RaRbC). machine A then passes SRaHk(RaRbC) to machine C as an introduction signature. that signature can be stored as a cookie value, or appended to the URL using the scheme i described last time. in either case, machine A redirects machine C to machine B. when machine C makes contact with machine B, it passes the introduction signature SRaHk(RaRbC). machine B splits that signature back into its components S, Ra, and Hk(RaRbC). machine B checks the timestamp embedded in S to verify that the connection has taken place within an appropriate timeframe, then uses S to retrieve Rb. machine B then combines Ra, Rb, the IP address of machine C, and the MAC key K. that string is hashed, to produce an independently calculated version of Hk(RaRbC). if machine B's independently calculated version of Hk(RaRbC) matches the version which was passed in the introduction signature, machine B can reliably assume that machine C has been authenticated by machine A within the appropriate timeframe. the IP address of machine C is encoded within Hk(RaRbC), so introduction signatures cannot be shared between different machines. the timestamp embedded in S is used to retrieve Rb, so the timestamp cannot be altered without causing the introduction to fail. neither the random string Rb nor the MAC key K can be recovered from Hk(RaRbC), so the introduction signatures cannot be used to break the protocol. the addition of random string Ra makes the protocol resistant to chosen-ciphertext attacks which could be used to retrieve K. the protocol is still vulnerable to man-in-the-middle attacks which involve IP spoofing, both of machine A and machine C. OTOH, so is almost everything related to the internet. it will be important for machine B to verify that the initial request for Rb and S does in fact come from machine A. it is also important to be sure the MAC key K is protected, or rotated on a regular basis. if you're really concerned about security, i advise you to have this protocol examined by a professional cryptographer who specializes in protocol analysis. that's out of my range of expertise. i believe this protocol to be secure, except for the attacks listed, but i can't prove it. if you need to be certain, get the proof. mike stone <[EMAIL PROTECTED]> 'net geek.. been there, done that, have network, will travel. ____________________________________________________________________ -------------------------------------------------------------------- Join The NEW Web Consultants Association FORUMS and CHAT: Register Today at: http://just4u.com/forums/ Web Consultants Web Site : http://just4u.com/webconsultants Give the Gift of Life This Year... Just4U Stop Smoking Support forum - helping smokers for over three years-tell a friend: http://just4u.com/forums/ To get 500 Banner Ads for FREE go to http://www.linkbuddies.com/start.go?id=111261 ---------------------------------------------------------------------
