Re: Closing on shared-key authentication

I did not cast a vore against forward compatibility in general at all.
Actually the current shared secret proposal does not solve that either,
in the sense that to incorporate kerberos or some other auth mechanism
we need to add yet other messages.

I was not under the impression that we were after designing forward
compatibilty in the TLS protocol. If that is the case, we could do the
split document thing and work on an extensible handshake.

Taher



Don Schmidt wrote:
> 
> I am delighted to see the last two postings from Taher and Barb getting
> back to the point.  That is the utility of a TLS standard.  If after all
> we design something that is secure but does not meet customer
> requirements -- and so is not widely adopted -- then why bother?
> 
> Many (if not most) of the arguments against incorporating shared-secret
> auth in TLS (the transport vs app layer arguments) could apply equally
> to PK-based auth.
> 
> Many of the obvious interoperability benefits of incorporating a
> standard PK-based auth into TLS could equally apply to shared-secret
> auth.
> 
> The point here is not whether PK-based auth is more secure than
> shared-secret auth, or whether it provides non-repudiation, or ...
> 
> The relevant facts here are:
> - This working group is chartered to develop a transport layer security
> standard.
> 
> - Rough consensus has decreed that SSL3 is the best starting point.
> 
> - Everyone recognizes the value of the robust key exchange, auth,
> integrity and encryption capabilities that derive from PK technology.
> 
> - Real consumers of products to be built according to the TLS standard
> have stated that the infrastructure, key management and portability
> issues associated with PK technology are acceptable on the server side.
> But they also have clearly stated their need to support millions of
> end-users who currently use passwords and are not ready to switch
> wholesale to private keys and certs.
> 
> - Real customers want the benefits of a single standard for Transport
> layer security but with their choice of auth technology.  In fact, they
> will most likely have to support both shared-secret auth and PK-based
> auth in parallel for some time, probably a couple of years at least.
> 
> - If the TLS standard were to support both auth mechanisms then it would
> be possible to provide implementations which prevent applications from
> having to know or care what kind of credentials were used to
> authenticate the end-user.  Applications could be written to a single
> interface and could be upgraded just once to support legacy client auth
> (shared-secret) and still migrate to admittedly superior client auth
> (PK-based).
> 
> Why is there such resistance to this line of reasoning?  If rough
> concensus holds that the TLS standard cannot support both shared-secret
> and PK-based auth, then fine, take them both out and put them both in
> the application layer.  But give me one standard so that applications
> developers, customers and end-users don't have to be hamstrung by the
> differences in authentication technology.
> 
> Don Schmidt
> Program Manager
> Microsoft Corp
> 
> >----------
> >From:  Barb Fox
> >Sent:  Wednesday, October 09, 1996 5:01 PM
> >To:    Dan Simon; 'elgamal@netscape.com'
> >Cc:    'ietf-tls@w3.org'; 'treese@OpenMarket.com'; 'david.brownell@Eng.Sun.COM'
> >Subject:       RE: Closing on shared-key authentication
> >
> >>Taher:
> >>
> >>I just have to jump in here to clarify a couple of things.
> >>
> >>Yes, password authentication is a customer requirement.  Many companies tell
> >>us that they want a migration path from passwords to certificate-based
> >>systems within the TLS protocol standard.  This has been the sole reason we
> >>have been pushing so hard for password authentication...customer need.  The
> >>business side of this argument has already been comprehensively presented by
> >>John Macko (Compuserve) in an earlier posting (7/22) so I don't want to
> >>start
> >>that chain again here.
> >>
> >>But Dan's comment about forward compatibilty in SSL has nothing to do with
> >>passwords per se.  Fact: there is no generic extensibility mechanism in SSL3
> >- and that's something we need to acknowledge and fix as soon as we can.
> >> The goal of this working group, after all, should be to create an
> >>architecturally-sound, extensible standard.  I admit that this will cause us
> >>all some pain as we find ourselves having to change our fielded
> >implementations to prepare for future advances in the protocol.  But if
> >>we bite the bullet and design the protocol correctly now, it shouldn't be
> >>such a big deal as we go incrementally forward.
> >
> >>Barb
> >>
> >>----------
> >>From:         elgamal@netscape.com[SMTP:elgamal@netscape.com]
> >>Sent:         Wednesday, October 09, 1996 8:49 AM
> >>To:   Dan Simon
> >>Cc:   'ietf-tls@w3.org'; 'treese@OpenMarket.com';
> >>'david.brownell@Eng.Sun.COM'
> >>Subject:      Re: Closing on shared-key authentication
> >>
> >>Dan,
> >>
> >>You bring an interesting point. In the design of SSL3.0, we did not
> >>expect that the protocol would have to support weaker authentication
> >>techniques, actually going backwards if you think about it. The idea of
> >>SSL3.0 was not to support everything that may exist or everything anyone
> >>can think of. So, you cannot really accuse SSL of not being forward
> >>compatible because it assumes a good authentication method rather than
> >>duplicate old ones that everyone has already implemented in any
> >>interesting application protocol. The only reason for me to entertain
> >>this password thing is that a customer thinks it is useful, not really
> >>because it adds anything to the protocol, on the contrary, it makes it
> >>less attractive since the level of authentication is not defined.
> >>
> >>Taher
> >>
> >>
> >>Dan Simon wrote:
> >>>
> >>> >From:  david.brownell@Eng.Sun.COM[SMTP:david.brownell@Eng.Sun.COM]
> >>> >
> >>> >I'll have to go back and look at the comments from last
> >>> >week's proposal (ssl-talk is where I saw most of it),
> >>> >but this proposal really doesn't seem "cooked" to me.
> >>> >
> >>> >   - Internationalization issues arise.  In what character
> >>> >     set do "display_string" and "challenge" appear?  How
> >>> >     is the language which the end user knows specified?
> >>> >
> >>> >     I don't like seeing application layer issues intrude
> >>> >     on transport layer protocols.
> >>>
> >>> The "display_string" field is opaque; that is, TLS simply transports it
> >>> without examining its content.  It is entirely the next level's
> >>> responsibility to figure out what to do with it (or even if it should be
> >>> sent in the first place).  Why is this an "intrusion" into the transport
> >>> layer, any more than, say, the presence of the opaque application data
> >>> which is passed through TLS as part of its basic function?
> >>> >
> >>> >   - Neither "rough consensus" nor (multiple instances of)
> >>> >     "working code" exists, as has been pointed out.
> >>> >
> >>> >     Many of us don't see a technical benefit to making TLS
> >>> >     be incompatible with SSLv3 in this respect, so I doubt
> >>> >     that a realistic "consensus" on this point can exist.
> >>>
> >>> Well, the real problem is that virtually *any* difference between TLS
> >>> and SSL 3.0 would make TLS incompatible with SSL 3.0, because SSL 3.0
> >>> simply lacks a mechanism for forward compatibility.  If we do nothing
> >>> else, we absolutely *must* prevent this problem from grandfathering its
> >>> way into TLS.  (The fix that's been suggested as least painful to SSL
> >>> 3.0 implementers is to specify that unrecognized handshake message types
> >>> be ignored--hence our use of new handshake message types to implement
> >>> shared-key authentication.  If someone has a better way to permit
> >>> extensibility, then I'd be happy to hear about it.)
> >>> >
> >>> >   - It's unclear just where in the handshake these new
> >>> >     messages would go.  Or are they even part of the
> >>> >     regular handshake protocol?  Do they go after the
> >>> >     "Finished" messages are exchanged, are they an
> >>> >     independent handshake, or what?
> >>>
> >>> The posted document specifies where the extra messages should go.
> >>> >
> >>> >   - Given that the amount of keying material to be built
> >>> >     is derived from the negotiated cipher spec, what's
> >>> >     the change needed in the definition of a cipher spec?
> >>> >     It needs to know it must generate CipherSpec.hash_size
> >>> >     (times two?) bytes of keying data.
> >>>
> >>> In SSL 3.0 (and presumably TLS), the actual keying material is not
> >>> included in the cipher_spec, but rather as part of the general
> >>> connection state.  Implementations that don't support shared-key
> >>> authentication can, of course, ignore the extra keying material
> >>> altogether.
> >>> >
> >>> >   - There's a new requirement, to ignore unrecognized
> >>> >     handshake messages rather than treat them as errors.
> >>> >     I prefer protocols to be fully specfied.
> >>>
> >>> If it's preferable, the specification can certainly require that
> >>> implementations recognize the extra handshake messages.  Of course, the
> >>> real problem here is SSL 3.0's lack of an extensibility mechanism; see
> >>> my comments above.
> >>> >
> >>> >I could raise more questions, but the fact that there are
> >>> >this many (after this much discussion!) says to me that the
> >>> >proposal should not be deemed "cooked" enough to incorporate
> >>> >into an IETF standard.
> >>>
> >>> To my mind, the problems with the proposal, as enumerated by David, cast
> >>> a worse light on SSL 3.0 than on the proposal itself.
> >>>
> >>>                                 Daniel Simon
> >>>                                 Cryptographer, Microsoft Corp.
> >>>                                 dansimon@microsoft.com
> >>>
> >>> >
> >>> >
> >>> >
> >>
> >>--
> >>Taher Elgamal     elgamal@netscape.com
> >>Chief Scientist, Netscape Communications
> >>(T) 415 937 2898, (F) 415 428 4054
> >>
> >>
> >

-- 
Taher Elgamal	    elgamal@netscape.com
Chief Scientist, Netscape Communications
(T) 415 937 2898, (F) 415 428 4054

Received on Thursday, 10 October 1996 11:44:31 UTC