- From: Dan Simon <dansimon@microsoft.com>
- Date: Tue, 3 Dec 1996 18:15:14 -0800
- To: "'ietf-tls@w3.org'" <ietf-tls@w3.org>, "'HUGO@watson.ibm.com'" <HUGO@watson.ibm.com>
Hugo: Thanks for the free advice! (I certainly *hope* it's free....) All of your recommendations make sense, but we would obviously prefer that our extensions for shared key authentication conform as closely as possible to the main body of the TLS spec, to avoid confusion and ease implementation. Hence, if your suggestions regarding MAC and PRF as primitives (as well as the corrections to the HMAC primitive) are adopted in the TLS spec as a whole (an excellent idea that we strongly support), then we will revise our shared key authentication draft accordingly. Regarding the adaptation of the shared-key authentication response to the new primitives (assuming that they are adopted), it appears to me that if a PRF primitive is defined, the natural approach would be simply to define the authentication response as PRF(auth_write_key, data + shared_key), thus achieving both the MAC property and concealment of the shared key (assuming a good PRF). Of course, if the PRF primitive does not get incorporated into the spec, then I suppose the simplest solution would be to treat HMAC/SHA-1 as an implicit PRF, which gives us your solution (2) (which happens to be--in content, if not in form--identical to the currently specified format). Regarding solution (3), one of the reasons for generating a separate "auth_write_key" was that such a key, used for only one purpose, would be safe to reveal to the authentication service. Hence, the separation idea you suggest may be redundant. Solution (1), on the other hand, is much more interesting, since it reduces the strength of the assumption required from the MAC function, as you point out. I'm currently checking into some implementability details, and if there are no problems, we'll look at incorporating this revision as well, in the case where the PRF primitive isn't incorporated into TLS. Comments, anyone? Daniel Simon Cryptographer, Microsoft Corp. (dansimon@microsoft.com) >---------- >From: HUGO@watson.ibm.com[SMTP:HUGO@watson.ibm.com] >Sent: Monday, December 02, 1996 4:06 PM >To: Tom Stephens; Dan Simon; ietf-tls@w3.org >Subject: Implementation of Shared Key Authentication > >Ref: Your note of Mon, 2 Dec 1996 12:16:29 -0800 > >Dan, Tom, > >I hope you read my previous message on how I'd like to see MAC functions >handled in SSL. >I'd recommend that you adopt these changes already now into your shared-key >proposal (to preclude future backward compatibility problems). >This includes changing to a generic MAC definition and implementing it with >the "official" HMAC as the default transform. > >The text affected by such a change would be: > >> SharedKeyVerify.shared_key_response >> hash (auth_write_secret + pad_2 + >> hash (auth_write_secret + pad_1 + hash (handshake_messages) >> >> + SharedKeyVerify.auth_service.auth_service_name >> + SharedKeyVerify.auth_service.display_string >> + SharedKeyVerify.auth_service.challenge >> + SharedKeyVerify.identity + shared_key) ) > >It should be re-written using a generic MAC (which could be implemented as >HMAC or any other MAC). > >The problem is then how to combine in general the two keys >auth_write_secret and shared_key into the generic MAC. > >The two possibilities that come to my mind are: XOR the two keys (or hash >them together, etc.) to create one single MAC key or (as you do now) append >the shared_key to the MAC-ed text. >That is: > >1) SharedKeyVerify.shared_key_response > MAC(auth_write_secret XOR shared_key, data) > >where data = hash (handshake_messages) > + SharedKeyVerify.auth_service.auth_service_name > + SharedKeyVerify.auth_service.display_string > + SharedKeyVerify.auth_service.challenge > + SharedKeyVerify.identity > >2) SharedKeyVerify.shared_key_response > MAC(auth_write_secret, data + shared_key) > > >In the first case one would be assuming that the MAC function >uses random (unstructured) strings as keys (which is the usual case). >In the second case this assumption is not needed but instead you will be >assuming that the MAC does not leak information on its output. The latter is >not a common assumption on MAC functions. It would require the assumption >that the MAC behaves as a "pseudorandom function" which is a stronger >assumption. (In particular, I trust more HMAC as a MAC than as a pseudorandom >function). >As for later solution notice that once MAC is implemented as HMAC >then the function will be the same as you use now (except for the changes >that you need to comply with the "official" HMAC, ie, XOR of pads instead of >concatenation). > >There is a third solution: > >If you assume MAC to be pseudorandom (as is needed in solution (2)) >then you could do the following > >3) SharedKeyVerify.shared_key_response > MAC(temp_key, shared_key) > >where temp_key=MAC(auth_write_secret, data) > >One potential advantage of this method is that in pass-through authentication >the (SSL) server needs to pass to the authentication server only the >value of temp_key and not of auth_write_secret which the server may want to >keep secret only between itself and the client. I don't know how important >this may be in actual uses but sounds as a good "key separation" property. > >Hugo > >PS: even if you do not want to go at this point to a generic MAC definition >I recommend that you already switch to the official HMAC and consider >doing (1) or (3). > >
Received on Tuesday, 3 December 1996 21:15:40 UTC