Re: [TLS] User Defined Key Pair

["OMAR HASSAN (RIT Student)" <[e-mail]>]

Hi Alex,

* Password-authenticated

UDKP is key-authenticated, it's based on signing a message by the user's
private key, and getting it validated by the user's public key, which is
stored on the server.
That will make it easy for supporting TLS termination as mentioned in the
section 5.2 of the draft, which is not easy to be supported by the TLS-SRP,
and that's one of the reasons it's not yet implemented in browsers.

* Do not involve CAs at all

If it's to be used in the browsers for websites, it will have to depend on
CA to secure the registration of the user credential on the server, and
that is also the case with UDKP.

* Do not allow a compromised server to impersonate the user
    - Zero-knowledge password proofs are rather useful

If the server is compromised, offline and dictionary attack will be
possible against the verifier, the attack will be in the password entropy.
In UDKP the authentication is done using public/private key, the server
will only contains the public key which will not be useful to impersonate
the user. The key generation should be based on at least the password, and
the security question/answer pair, for applications that require more
security the key generation will be based on a file that the user will
select, or the key generation will be based on a smart card or a hardware
token (more details on that will be in the coming version of the draft).

* Are designed to work with TLS, rather than replace it wholesale
Actually I have been advised to make it compatible with TLS, and I am
thinking of that seriously.


Thank You
Best Regards



On Fri, Jul 12, 2013 at 2:37 PM, OMAR HASSAN (RIT Student)
<[e-mail]>wrote:

> Hi Dan,
>
> I believe that your protocol will better suit for customized applications,
> but when it comes to websites you will definitely face those issues that I
> took about.
>
>
>
> It's very common that a SQL injection attack against the website would
> give the attacker the opportunity to steal database records, which will
> allow the attacker to impersonate the client (I think TLS-SRP adds a little
> complexity to protect against that scenario, I am sure you can improve this
> part in your protocol)
>
>
>
> Also TLS termination is very important, and must be supported by the
> protocol, and the first challenge in that regard is that the load balancer
> where the TLS connection should be terminated will not have access to the
> server database, and I think without access to the server database you will
> not be able to terminate the encrypted connection.
>
>
>
> Regarding UDKP, I believe that the only valid attack against it is during
> the registration. In that case using an initial TLS authenticated
> connection will solve this issue, and for all later usages there is no need
> to be dependent on certificate authorities.
>
>
>
> In UDKP, if the server data has been stolen, the attacker will get only
> the public key, and he will not be able to impersonate the client as he
> will need the private key. And regarding TLS termination, the load
> balancer could use the user public key to terminate the encrypted
> connection, and the let the server authenticate the user. You can refer to
> section 5.2 in the draft:
>
> http://tools.ietf.org/html/draft-omar-tls-udkp-01#section-5.2
>
> In the coming version of the draft I will put a detailed analysis for the
> attack scenarios.
>
>
> On Thu, Jul 11, 2013 at 6:22 PM, Dan Harkins <[e-mail]> wrote:
>
>>
>>   Hi Omar,
>>
>> On Thu, July 11, 2013 2:42 am, OMAR HASSAN (RIT Student) wrote:
>> > Hi Dan,
>> >
>> > I had a quick look at your work item, and I have some questions:
>> >
>> > What will be the consequences if the server data has be stolen? will the
>> > attacker be able to impersonate as the user?
>>
>>   Successfully stealing records from the server's password file will
>> enable the thief to impersonate the client (back to the hacked server)
>> for all stolen records.
>>
>> > How will the password be stored in the server initially?
>>
>>   That is completely up to the server.
>>
>> > How will you handle TLS termination that is used many websites to
>> > centralize the related measurements and protection against the common
>> SSL
>> > attacks in one place, and to allow the application firewalls to validate
>> > and check the incoming requests for application-level attacks such as
>> SQL
>> > injection and cross-site scripting?
>>
>>   This is really an operational question. At the risk of sounding flippant
>> I guess I'd just say it will be handled in the best way possible.
>>
>>   You claim in your draft that "UDKP aims to completely replace the TLS
>> protocol." That is a much more ambitious goal and you will need to handle
>> these sorts of issues. The tls-pwd draft just defines certificate-less
>> ciphersuites that are resistant to dictionary attack (and are better than
>> the various PSK ciphersuites) for use with the existing TLS protocol.
>>
>>   regards,
>>
>>   Dan.
>>
>> > Thanks
>> >
>> >
>> >
>> > On Wed, Jul 10, 2013 at 8:49 PM, Dan Harkins <[e-mail]>
>> wrote:
>> >
>> >>
>> >> On Mon, June 24, 2013 11:34 am, Salz, Rich wrote:
>> >> [snip]
>> >> > If you are trying to avoid CA's, then why not just use self-signed
>> >> > certificates or similar like PGP?
>> >>
>> >>   Or why not use a protocol that is already a work item of the
>> >> TLS working group:
>> >>
>> >>      http://tools.ietf.org/html/draft-ietf-tls-pwd-00
>> >>
>> >>   Dan.
>> >>
>> >>
>> >>
>> >>
>> >
>>
>>
>