Implementation of Shared Key Authentication

Ref:  Your note of Tue, 3 Dec 1996 18:15:14 -0800 (attached)

 > Hugo:  Thanks for the free advice!  (I certainly *hope* it's free....)

Free indeed (a joke here would fit well but I know Microsoft may not be
joking about this...)

 > 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.

I hope they will...
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.

 > 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.

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?

Thanks for considering the changes.


Received on Friday, 6 December 1996 11:38:05 UTC