RE: Implementation of Shared Key Authentication

>----------
>From: 	HUGO@watson.ibm.com[SMTP:HUGO@watson.ibm.com]

>However, SSL/TLS does not specify a unique way to do MAC but has several
>ad-hoc variants of HMAC. This means that implementers do not have a unique
>function that they can call everytime a MAC is required inthe protocol.
>SO there is no problem for you to use yet another variant (in this case
>the official HMAC which I guess/hope TLS will eventually adopt).
>So even if you do not go for a more generic presentation of the
>protocol using MAC or PRF at this time, you can already change your
>definition
>to comply with draft-ietf-ipsec-hmac-md5-01.txt.
>Moreover , you can decide on one of the options 1, 2, or 3 discussed in my
>previous message and stick to it already now.
>Since you are inviting independent implementations you want to avoid
>the compatibility and upgrade problems later.

Well, let's put it this way:  If TLS *does* end up standardizing on
something usable, I'd like shared-key authentication to use it.
Hopefully, the working group will come to a decision soon, and we can
put out a revised shared-key authentication spec immediately thereafter.

>
>If auth_write_key is *guaranteed* to be used only once for this purpose
>why not use it as a one-time pad to encrypt the challenge response
>in the way from client to TLS server?


It's a matter of appeasing the export gods.  We already spit out a long,
public-key-exchanged secret at the server end; if we also output data
that was one-time-pad encrypted with it (as opposed to some hash of the
two together), I fear the wrath of export control might well rain down
upon us.  So instead, we chant the talismanic intonation, "never will we
output strongly encrypted plaintext", and hope for the best.

(I know--you're going to ask why we don't just hash the
one-time-pad-encrypted response.  Well, we'd still like to use standard
TLS primitives, if we can; the current response format, for instance, is
modeled on one.)

			Keep those comments coming,

			Daniel Simon
			Cryptographer, Microsoft Corp.
			(dansimon@microsoft.com)

Received on Friday, 6 December 1996 18:09:14 UTC