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
>
>

Received on Wednesday, 9 October 1996 21:43:43 UTC