New authentication protocol, was Re: Tinc's response to "Linux's answer to MS-PPTP"

[Anne & Lynn Wheeler]

On Mon, 2003-09-29 at 06:07, Guus Sliepen wrote:

> TLS makes a distinction between a client and a server. If possible I
> wish to avoid making that distinction. If possible, I would also like to
> continue to be able to use an RSA public/private keypair. This made me
> *sketch* the following _authentication_ protocol:
> 
... snip ...
> 
> Some questions:
> 
> - Some people keep saying that "you shouldn't send the same kinds of
>   messages". TLS sends different kinds of messages depending on its role
>   (client or server). Is there a reason behind this?
> 
> - Would it be nice to move all the cryptographic parameters exchanged in
>   step 1 into the encrypted message in step 2? That way an attacker
>   cannot see which encryption and digest algorithms will be used, which
>   might make an attack less feasible.
> 
> - Did I miss something?

1) TLS both authenticates the server and establishes an encrypted
session in the server part of the transaction. 

2) The original SSL somewhat assumed that the business requirements are
different for server authentication (and encrypted session) vis-a-vis
client authentication. The original SSL requirement a) was to give some
level of confidence to the client that "the server that the client thot
it was talking to" was actually "the server it was talking to" and b)
provide an encrypted session. There wasn't actually a threat model
requiring proving who you are ... just a threat model that the server
prove that it was who the client supposedly thot it was. 

3) SSL was being deployed with a requirement for encrypted session in an
environment where client authentication:

  a) might not be required
  b) was not required as part of the transport protocol
  c) was used to webize/tunnel an existing legacy application
      where the client might use userid/password or other 
      authentication previously established
  d) wouldn't be public key based because the clients were not
     expected to have public/private key pairs and certificates

Some web'ized legacy applications were adopted from a private network
environment ... where the client as part of making the connection "knew"
that it was talking to the correct server. The minimum required to move
that to the wide-open web ... was to provide server authentication and
encrypted session ...  and then tunnel the legacy app thru the encrypted
session. The business requirement and threat model wasn't to invent a
brand new environment from scratch ... but to adapt existing business
operations to the wide-open web.

"Mutual" authentication was somewhat an add-on of client authentication
to the base infrastructure. In fact, I think that we were the first to
specify and required the first implementation as part of the back-end of
this thing that has come to be called electronic commerce.

random electronic commerce refs:
http://www.garlic.com/~lynn/aadsm5.htm#asrn2
http://www.garlic.com/~lynn/aadsm5.htm#asrn3

The trivial e-commerce is that the merchant server didn't really care
who the client was ... just that the client bought something and the
merchant was going to get paid. The merchant needed to provide some
assurance that the credit card transaction being passed thru to the
financial infrastructure was protected. The merchant relied on the
financial infrastructure authenticating the credit card transaction ...
and, in fact, any mutual authentication that might be done as part of
the SSL transaction had no impact on the credit card transaction. 

To some extent, both VPN and SSL come into existence about the same time
to satisfy specific business requirement(s) (and in part because it was
taking so long to see any progress with ipsec).

-- 
Anne & Lynn Wheeler -  http://www.garlic.com/~lynn/ 

---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com