Re: Layering and Shared-key authentication

EKR,

  Please read below your comments.

At 11:30 AM 10/8/96 -0700, you wrote:
>A lot of the arguments against shared secret client authentication
>seem to be layering arguments. Specifically, the argument seems to 
>be that shared secret style authentication properly belongs at the
>application layer. While I feel that this argument has some force
>in principle, it seems to me to be deeply problematic in this specific
>case, for a number of reasons:
>
>1. The security services that TLS provides to the application layer
>are inadequate for this purpose. The obvious approach to layering
>protocols which require shared secret authentication over TLS 
>is simply to pass the shared secret directly over the TLS channel,
>using TLS as TCP has always been used. However, in the common case, 
>TLS application layer data is encrypted with a 40 bit keyspace,
>which means that that's all the protection provided for the
>shared secret. Consequently, we either have to accept this limitation
>or the application needs to provide it's own protection for
>the shared secret. 

  I think that the latter is going to win out in the long haul.  The reason is
that 40 bit keyspace is really not adaquate for modern day buisnesses and
applications.  Another approach would be to modify that keyspace to
128, which would quiet alot of commercial concerns.  Otherwise providing for
that level(128 bit) will be done in a non-standerd manner by those 
commercial buisnesses for providing their customers better "Adaquate" 
protection of their data.
>
>
>2. Forcing applications to provide their own security argues against
>the purpose of TLS. Much of the argument for TLS is that applications
>can then be largely security oblivious while still taking advantage
>of security services. While data confidentiality for the data on the
>channel is important, there is a lot of historical evidence that the
>primary security need for e.g. telnet is actually access control, not
>data confidentiality, and this is typically provided via a shared secret.
>If TLS can't serve this need in an adequate way, then securing them
>will require a lot more work than just layering them on top of
>TLS--at which point one might easily imagine providing an application
>specific protocol which would meet that application's precise security
>needs in a single package.

  I would agree that forcing applications to provide their own security is
contrary to the TLS perposal, it may very well become a common practice
with respect to the weakness of 40 bit common keysize.  I don't agree that
TLS should only address access security per say.  Buisnesses need to feel
safe that they believe and can trust that their data is secure, which agrues in
favor of layering, IE application layer.  I think the idea of an application
spicific protocol, is a intresting thought, except I think I would carry it out
to a more generic or encompassing protocol, with a common interface. 
>
>
>3. There are a large number of common internet protocols which require
>shared secret style authentication, including but not limited to telnet,
>the Berkeley r-protocols, NNTP under certain circumstances... So,
>we're going to be reinventing this wheel a lot of times. This still
>doesn't make it TLS's job, but it's hard to see who's job it is,
>then.

  I agree that it is not TLS's job.  But I would look at at least providing
an exit for and interface for TLS, not to mention SSL, Berkeley r-protocols,
and any other shared secret protocols. 
>
>
>4. We've already violated this layering boundary. Public key style
>client authentication isn't really a necessary part of TLS service
>provision and could be easily handled at the application layer. This
>layering argument would be a lot more convincing if we hadn't
>already gone against it.

  Well that is history now.  The real question is how do we handlee it?

Reguards,

>
>-Ekr
>
>
>
>
>
>
>
>
>
>
>
>
>
>
Jeffrey A. Williams
SR.Internet Network Eng. 
CEO., IEG., INC. Representing PDS .Ltd.
Web: http://www.pds-link.com
Phone: 214-793-7445 (Direct Line)
Fax: 214-447-1900
Director of Network Eng. and Development IEG. INC.

Received on Tuesday, 8 October 1996 17:28:14 UTC