RE: Implementation of Shared Key Authentication

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