Yes, I'm proposing that clients protect themselves by creating self-signed
security certificates, and that servers engage in due dillegence to ensure
connections are MITM free.
Widespread deployment of DANE registries of server certificates is also
required.
If the client wishes to operate on multiple devices, they would need their
public/private key pairs installed on each device.
The login to upstream applications is mostly independent of the TLS connection,
except for a new interface where the upstream application can participate in
rejecting the TLS connection if they have no record of the client certificate
belonging to any acccounts in the server's control.
Karl
________________________________
From: Oliver Gasser <[email protected]>
To: Karl Malbrain <[email protected]>
Cc: Leif Johansson <[email protected]>; "[email protected]" <[email protected]>
Sent: Friday, September 13, 2013 3:02 PM
Subject: Re: [perpass] proposed enhancement to TLS strong authentication
protocol
On 09/13/2013 11:48 PM, Karl Malbrain wrote:
> Sorry, I mis-read your "browser-vendor" concern section as "server" vendor.
>
> The browser should be able to cache the TLSA record on the local machine.
>
> Karl
>
>
>
> *From:* Karl Malbrain <[email protected]>
> *To:* Leif Johansson <[email protected]>
> *Cc:* "[email protected]" <[email protected]>
> *Sent:* Friday, September 13, 2013 2:30 PM
> *Subject:* Re: [perpass] proposed enhancement to TLS strong
> authentication protocol
>
> Great news. Then all that is needed is a post connection exchange
> comparison in the client between the server certificate used by TLS and
> the one obtained from DANE.
>
> As to simple HTTP content servers, the use of the client authentication
> interface is optional. If there is no interface handler installed, the
> TLS package goes ahead and allows the connection.
>
> Note, for HTTP content servers that desire to authenticate client
> connections as MITM free themselves, the in-page-rendering lookup is not
> to an external source -- it's to the servers own account record where a
> secure hash of the client certificate is stored during account creation.
>
> However for servers that act as client agents over some domain, the
> server will track whether the authenticated user certificate "owns" the
> account or is an unrecognized user, and preclude hacking the server by
> guessing account names and passwords, etc.
If I understand correctly, you want to dynamically create client
certificates and then check the client certificate information in
combination with a user's login name and password.
What happens if a user accesses a site from different devices/clients?
What about sites where users don't log in at all?
>
> Yes, with DANE in place, this proposal is now entirely focused on
> authentication by the server of clients.
>
> Karl
>
>
>
> *From:* Leif Johansson <[email protected]>
> *To:* Karl Malbrain <[email protected]>
> *Cc:* Randy Bush <[email protected]>; "[email protected]" <[email protected]>
> *Sent:* Friday, September 13, 2013 2:05 PM
> *Subject:* Re: [perpass] proposed enhancement to TLS strong
> authentication protocol
>
> On 09/13/2013 10:40 PM, Karl Malbrain wrote:
>> I'm not familiar with DANE. Is it operational? Does it include
>> changes to TLS to accept/compare the server's certificate obtained
>> from DANE? If so, then that part of the proposal can be mooted in
>> favor of DANE.
>>
> The DNS is quite operational and nothing stops anyone from publishing
> TLSA records right this second.
>> Yes, it would be simpler to offload the certificate sourcing
>> management to DNS. However, I'm proposing changes to be implemented
>> entirely within TLS, that are transparent on the client side. Only
>> the server side would require an additional interface to accept/reject
>> client connections.
> There have been credible arguments from browser vendors against any
> scheme that involves
> an in-page-rendering lookup to an external service that takes more than
> a few milliseconds
> because of the adverse effect on usability.
>
> Granted, TLS is about much more than the web but its still a major use-case.
>
> I suspect that any scheme that will have any chance of success must
> involve pre-computing
> some form of proof on the server-side that can be stapled onto the TLS
> connection.
>
> Also you seem to focus on the client authenticating to the server which
> quite frankly could make the
> privacy story worse.
>>
>> Karl
>>
>> *From:* Randy Bush mailto:[email protected]
>> *To:* Karl Malbrain mailto:[email protected]
>> *Cc:* Leif Johansson mailto:[email protected]
>> *Sent:* Friday, September 13, 2013 1:24 PM
>> *Subject:* Re: [perpass] proposed enhancement to TLS strong
>> authentication protocol
>>
>> [ off lst ]
>>
>> > I've dropped the idea of including both client and server public
>> > certificates in the directory in favor of a server certificate only
>> > repository with an additional TLS interface to authorize access by
>> > clients.
>>
>> so why is this a win over dane?
>>
>> randy
>>
>>
>
>
> _______________________________________________
> perpass mailing list
> [email protected] <mailto:[email protected]>
> https://www.ietf.org/mailman/listinfo/perpass
>
>
>
> _______________________________________________
> perpass mailing list
> [email protected] <mailto:[email protected]>
> https://www.ietf.org/mailman/listinfo/perpass
>
>
>
>
> _______________________________________________
> perpass mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/perpass
>
_______________________________________________
perpass mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/perpass
_______________________________________________
perpass mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/perpass
