Re: Implementation of Shared Key Authentication, etc.

At 11:35 AM 6/12/96 EST, Hugo wrote:
>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.

G'day!

Being new to this list, please excuse me if I have failed to find relevant past correspondence on such matters, but, in my ignorance, it appears to me that "support line"
diagnosis of user-problems could be troublesome, to say the least.  Scenario:

User:     "My Browser keeps on disconnecting with a rude message whenever I try to order a
          widget from XYZ., Inc.  Your software is lousy!"

Analyst:  "Are you using our latest and greatest, Release 18.9-k?"

User:     "Of course!  And apparently good money ill-spent!"

Analyst:  "What message are you getting?"

User:     "Something stupid like 'Protocol violation  --  invalid MAC'.  What's this got to
          do with sick hamburgers?"

Analyst:  "I don't suppose you know what software XYZ, Inc., are running?  The product and
          the version?"

User:     "You're obviously joking.  They're based in Kyzyl, Tanutuva.  You ring them up and
          find out."


Certainly an unlikely exchange if the underlying software comes from the major vendors, but still possible.  Much more likely when  --  as will inevitably happen  --  others decide to "roll their own".

I don't see a universal panacea for this problem, but at least it might help if (say) each Vendor's IP address and software-version were buried somewhere in the exchange.  Knowing where the incompatibilities lie is half the battle.

Regards,
Jim LW 

From the BBC's "Barchester Chronicles":

    "I know that ultimately we are not supposed to understand.
    But I also know that we must try."

       -- the Reverend Septimus Harding, C++ programmer

Received on Sunday, 8 December 1996 21:48:32 UTC