Re: [TLS] Working Group Last Call for draft-ietf-tls-pwd

["Dan Harkins" <[e-mail]>]

  Hi Oscar,

On Tue, November 19, 2013 3:15 am, [e-mail] wrote:
> May I add that it's not clear which elements are to be presented to the
> user for visual (or automated) inspection and in which form. I can handle
> long random string for visual inspection, but I wonder if this is to be
> expected from all users. If I've understood the spec correctly the
> fingerprint of the public key and the domain names, i.e. the subject alt
> names, are to be presented to the user. This could turn out to be quite a
> bit of data per certificate.
>
> Also, if the fingerprint is tied to public key exclusively I wonder what
> the UAs are expected to do when subject alt names have changed in the
> certificates when the public key is preserved.

  Very interesting questions... for the web sec WG; this is TLS. And this
is a thread dealing with a draft that does certificate-less authentication.

  regards,

  Dan.

> Oscar Koeroo
> Red Team / Ethical Hacker
> Chief Information Security Office
> KPN
> Tel: [phone]
> Fingerprint: 3D5F 5BA5 AF84 BBE1 3D60 8621 0DCD 74C3 A211 B654
>
>
> Van: TLS [mailto:[e-mail]] Namens Ralf Skyper Kaiser
> Verzonden: dinsdag 19 november 2013 11:16
> Aan: Dan Harkins
> CC: [e-mail]
> Onderwerp: Re: [TLS] Working Group Last Call for draft-ietf-tls-pwd
>
> Hi Dan,
> The security risk lies within the implementation.
>
> The capable client will always offer TLS-PWD.
>
> Simplified, this is how pinning will be implemented: The client receives
> the server's certificate. The client checks if the server's certificate
> (or better the SPKI) is already known to the client (e.g. pinned) and if
> the server's certificate is different to the pinned certificate then the
> connection fails.
> The draft assumes that certificate based server authentication is the only
> authentication that exists.
> The draft does not discuss the scenario where TLS-PWD is used.
> In such a case I'm concerned that the part of the client source code that
> checks for pinning is not triggered and by-passed. The client goes into
> the TLS-PWD mode.
>
> Instead what should be pinned is the SPKI _and_ that certificate based
> server-authentication must be used. E.g. once a client has pinned a
> certificate for a host it should not allow TLS-PWD.
> This is obvious to us but not obvious to the developer and should be
> explicitly mentioned.
> (It could be mentioned in websec-rfc as you say but that's beyond draft
> status and additions are no longer practical). Mentioning it in the
> TLS-PWD draft will hopefully prevent an insecure implementation.
>
> regards,
>
> Ralf
>
>
> On Mon, Nov 18, 2013 at 9:51 PM, Dan Harkins <[e-mail]> wrote:
>
>   Hi Ralf,
>
> On Tue, November 12, 2013 2:28 am, Ralf Skyper Kaiser wrote:
>> Hi,
>>
>> could not find it in the draft:
>>
>> the interoperability with draft-ietf-websec-key-pinning-08 should be
>> mentioned explicitly to prevent
>> an attack scenario. (e.g. user has pinned certificate for google.com.
>> Attacker MITM forces
>> client to do tls-pwd. Client should not allow this). E.g. once a host is
>> pinned no other server-side
>> auth mechanism should be allowed.
>   If the client doesn't want to do TLS-pwd then it won't include the
> mandatory extension in its client hello and it won't include any TLS-pwd
> ciphersuites. I don't see how this attack happens.
>
>   Perhaps the necessary requirements to deal with pinning certificates
> for websec should be dealt with in the draft you mention.
>
>   regards,
>
>   Dan.
>
>
>
>