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

Received on Wednesday, 9 October 1996 11:50:09 UTC