Re: Layering and Shared-key authentication

Jeff Williams wrote:
> 
> 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.
unsubscribe

Received on Tuesday, 8 October 1996 19:26:02 UTC